[gnome-devel-docs/gnome3-hig] hig3: make mobile work on pre3 and other high density devices. content.
- From: Jakub Steiner <jimmac src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [gnome-devel-docs/gnome3-hig] hig3: make mobile work on pre3 and other high density devices. content.
- Date: Mon, 13 Feb 2012 20:04:41 +0000 (UTC)
commit 49463caad3b212e3f71d9b66d470120dc020c588
Author: Jakub Steiner <jimmac gmail com>
Date: Mon Feb 13 21:03:54 2012 +0100
hig3: make mobile work on pre3 and other high density devices. content.
hig3/site/stylesheets/hig.css | 2 +-
hig3/src/pages/basics-content-area.haml | 113 ++++++++++++++++++++
hig3/src/pages/basics-notifications.haml | 8 ++
hig3/src/pages/basics-primary-toolbar.haml | 49 +++++++++
hig3/src/pages/basics-primary-windows.haml | 45 ++++++++
hig3/src/pages/color.haml | 9 ++
hig3/src/pages/dark-theme.haml | 3 +
hig3/src/pages/design_principles.haml | 151 ++++++++++++++++++++++++++
hig3/src/pages/design_strategies.haml | 91 ++++++++++++++++
hig3/src/pages/keyboard_input.haml | 154 +++++++++++++++++++++++++++
hig3/src/pages/pointer_and_touch_input.haml | 9 ++
hig3/src/pages/system_shell.haml | 9 ++
hig3/src/pages/visual_layout.haml | 72 +++++++++++++
hig3/src/pages/writing_style.haml | 137 ++++++++++++++++++++++++
hig3/src/stylesheets/hig.scss | 2 +-
15 files changed, 852 insertions(+), 2 deletions(-)
---
diff --git a/hig3/site/stylesheets/hig.css b/hig3/site/stylesheets/hig.css
index 14d4b62..7d9172a 100644
--- a/hig3/site/stylesheets/hig.css
+++ b/hig3/site/stylesheets/hig.css
@@ -566,7 +566,7 @@ hr.footerart {
}
/* MOBILE VERSION BELOW */
- media screen and (max-width: 960px) {
+ media screen and (max-width: 960px), screen and (-webkit-min-device-pixel-ratio: 1.5) {
/* line 414 */
.gnomelink {
display: none;
diff --git a/hig3/src/pages/basics-content-area.haml b/hig3/src/pages/basics-content-area.haml
new file mode 100644
index 0000000..5705726
--- /dev/null
+++ b/hig3/src/pages/basics-content-area.haml
@@ -0,0 +1,113 @@
+%h1 Primary Toolbars
+
+.note
+ This is draft content for the next version of
+ %a{:href => 'http://design.gnome.org'} GNOME Human Interface Guidelines.
+
+%h1#grid-view
+ Grid View
+%p
+ An area that contains a grid of images that represent individual items of content. Each item typically has a label beneath it. A scrollbar enables the grid to be moved up and down when the number of items becomes too big for the available space.
+
+%h2
+ When to use
+%p
+ The grid view is one of the principal ways of presenting bodies of content in GNOME 3 applications. It can be used to present relatively small numbers of items or very large numbers. Examples of the grid view can be seen in the Documents, Music, Clocks and Boxes apps.
+
+.columns
+ =img "figures/content-grid.png"
+ %p
+ Since the grid view utilises an image for each item it presents, it is best suited to content that has a visual component. It is also well suited to content where each item has an image that is specific to it, rather than having images that are shared by multiple items of content.
+
+%p
+ As a general design strategy, it is worth thinking about ways in which you can generate unique images for each of the content items that you want to present. Unique images vastly help identification and can bring life to what would otherwise be a dull or uninteresting application. GNOME Clocks is an excellent example of this - by marrying each world clock with an image of a city, it aids identification and provides a richer experience than would be enabled by text and numbers only.
+
+%h2
+ Guidelines
+%p
+ Be consistent with the implementations found in the core GNOME 3 applications. Ensure that the layout of the grid is the same.
+
+.columns
+ =img "figures/grid-spacing.png"
+ %ul
+ %li
+ Order the items in the grid according to what will be most useful to people using your application, as well as conventions for the type of application that you designing.
+ %li
+ Selecting an item in the grid will typically switch to a dedicated view of it.
+ %li
+ Use chunking.
+ %li
+ The standard [[Design/HIG/Search|search]] design pattern should be used to allow people to filter the content of the grid.
+
+%h2
+ Elaborations
+%p
+ The grid view is a flexible pattern that can be elaborated depending on your requirements. The following are a number of optional additions to the grid pattern that can be used:
+
+%ul
+ %li
+ Use the
+ = link "checkmark selection", "selectmode-checkmark.html"
+ mechanism if it is necessary to provide the ability to select and modify items within the grid.
+ %li
+ If the items in the grid have several useful properties, an alternative
+ =link "list view", "#list-view"
+ can be provided. Switching between a grid and list view is typically facilitated by a set of radio button items in the
+ =link "app menu", "basics-appmenu.html"
+ \.
+ %li
+ Grid views can contain collections.
+ %li
+ ''Emblems'' can indicate a variety of states, including whether an item is being shared.
+ %li
+ Grid items can display a range of ''status information'', such as progress or whether they are active. This is particularly useful if the items in the grid have dynamic properties. GNOME Boxes provides examples of a number of these states displayed within the grid design pattern.
+ %li
+ Inactivity can be indicated by â
+ %li
+ Progress can be indicated by â
+
+%h1#list-view
+ List View
+%p
+ An area that is populated by a list of items. A list can incorporate multiple columns of both text and images. The list can be vertically scrolled and can be filtered by using search functionality.
+
+%h2
+ When to use
+%p
+ List views can be used to present and give access to bodies of content. They are appropriate if content items have a name or other text-based identifier.
+.columns
+ =img "figures/content-list.png"
+ %p
+ List views often accompany
+ =link "grid views", "#grid-view"
+ and offer a different perspective on the content that they present. In particular, a list view allows additional information about each item of content through the use of multiple columns of text.
+
+%h2
+ Guidelines
+%p
+ Be consistent with the list views found in the core GNOME 3 applications.
+
+=img "figures/list-spacing.png"
+#ul
+ %li
+ Specify the width of each column according to the anticipated length of its contents, but also ensure that the most important columns are prominent within the overall layout.
+ %li
+ Provide a search facility in order to allow people to filter the contents of the list. See the [[Design/HIG/Search|search design pattern]] for more information on this.
+ %li
+ Combine scrolling with chunking when there are a high number of items in the list view.
+ %li
+ Selecting an item from the list will typically open it.
+ %li
+ Ensure that you follow the guidelines on using [[/Design/HIG/TextAndLabels|text]].
+ %li
+ When presenting multiple columns of text, use color to draw attention to the most important column. Making the text of less important columns lighter will make the list easier to read.
+
+%h2
+ Elaborations
+
+%p
+ Like grid views, list views can be combined with additional design patterns:
+%ul
+ %li
+ =link "checkmark selector", "selectmode-checkmark.html"
+
diff --git a/hig3/src/pages/basics-notifications.haml b/hig3/src/pages/basics-notifications.haml
new file mode 100644
index 0000000..d9eb3f9
--- /dev/null
+++ b/hig3/src/pages/basics-notifications.haml
@@ -0,0 +1,8 @@
+%h1
+ Notifications
+
+.note
+ This is draft content for the next version of
+ %a{:href => 'http://design.gnome.org'} GNOME Human Interface Guidelines.
+
+FIXME
diff --git a/hig3/src/pages/basics-primary-toolbar.haml b/hig3/src/pages/basics-primary-toolbar.haml
new file mode 100644
index 0000000..0e1eaed
--- /dev/null
+++ b/hig3/src/pages/basics-primary-toolbar.haml
@@ -0,0 +1,49 @@
+%h1 Primary Toolbars
+
+.note
+ This is draft content for the next version of
+ %a{:href => 'http://design.gnome.org'} GNOME Human Interface Guidelines.
+
+%p
+ A horizontal toolbar that is located at the top of a window, beneath its titlebar (in windowed mode).
+=img "figures/primary-toolbar-example.png"
+
+%h2
+ When to use
+
+%p
+ A primary toolbar should be used within any
+ =link "primary window", "basics-primary-windows.html"
+ \.
+%h2
+ Guidance
+
+%ul
+ %li
+ The primary toolbar should contain the dominant controls in the window - the controls contained within the toolbar should be for key operations that affect the content below.
+ %li
+ Keep the toolbar contents to a minimum - work to ensure that a small amount of essential functionality is included
+ %li
+ Arrange the toolbar contents according to the three alignment points described in [[Design/HIG/VisualLayout|the Visual Layout guidelines]] - left, centre and right alignment
+ %li
+ The most dominant controls should be left aligned
+ %li
+ Controls relating to filtering should be centre aligned
+ %li
+ Follow the lead of the core GNOME 3 applications and repeat the conventions that they establish. Place common toolbar elements, such as [[Design/HIG/CheckMarkButtons|Check Mark Buttons]], [[Design/HIG/FilterButtons|Filter Buttons]] and [[Design/HIG/BackButtons|Back Buttons]] in consistent positions.
+ %li
+ The content of a primary toolbar can update based on the context. When using multiple [[Design/HIG/Views|Views]], you should add and remove controls depending on which view is being displayed.
+
+%h2
+ Maximizing Windows
+
+%p
+ If the window containing the toolbar is a maximizing window (see
+ =link "primary windows", "basics-primary-windows.html"
+ ), the Primary Toolbar needs to have certain features:
+
+%ul
+ %li
+ The content name/title should be displayed, so that the window's titlebar can be dispensed with. This can either be done either by placing a text label in the toolbar, or by including a control which indicates the content that is displayed below, such as filter buttons. The latter approach can be seen in the core Music application.
+ %li
+ Dragging the toolbar down while the window is maximized should unmaximize it
diff --git a/hig3/src/pages/basics-primary-windows.haml b/hig3/src/pages/basics-primary-windows.haml
new file mode 100644
index 0000000..0b7c24a
--- /dev/null
+++ b/hig3/src/pages/basics-primary-windows.haml
@@ -0,0 +1,45 @@
+%h1
+ Primary Windows
+
+.note
+ This is draft content for the next version of
+ %a{:href => 'http://design.gnome.org'} GNOME Human Interface Guidelines.
+
+%p
+ Primary windows are the principal container for application interfaces. If its primary window(s) is closed any supplementary windows, such as [[Design/HIG/UtilityWindows|Utility Windows]] and [[Design/HIG/Dialogs|Dialogs]], will also close. Closing an application's primary windows will typically stop that application from functioning altogether.
+
+%p
+ The top of a primary window is headed by a titlebar that contains a centered window title and a close button in the right-hand corner.
+%p
+ Primary windows can contain a wide variety of content and control elements. They can also contain multiple [[Design/HIG/Views|views]] that can be navigated between.
+
+%h2
+ When to Use
+%p
+ Primary windows are a standard part of GNOME 3 applications, and most applications will utilise one or more of them. The exception to this is applications that are always presented in full screen mode, such as games.
+
+%h2
+ Guidance
+%p
+ Give the window a short, informative title. Since window titles can be truncated, ensure that the most important part of the title is at the beginning.
+%p
+ There are two types of primary windows:
+
+%ol
+ %li
+ Maximizing - these are the standard variety of primary window, and are used by application that allow the browsing, viewing or editing of content.
+ %ul
+ %li
+ The window is maximized by default and loses its titlebar when maximized
+ %li
+ The window title should be a short description of the window's content, and should not include the application name
+ %li
+ Maximizing primary windows will typically (though not always) contain a [[Design/HIG/PrimaryToolbar|Primary Toolbar]]. Primary windows can also present multiple [[Design/HIG/Views|views]] or be split according to the [[Design/Hig/ListPane|List Pane]] design pattern. See the other design patterns and existing applications for examples of how your primary windows can be structured.
+ %li
+ Non-maximizing - these are relatively uncommon and are best suited to small utility applications that might want to be used in conjunction with other primary windows.
+ %ul
+ %li
+ The window is not maximized by default and should not lose its titlebar when maximized
+ %li
+ The window title should be the application name
+
diff --git a/hig3/src/pages/color.haml b/hig3/src/pages/color.haml
new file mode 100644
index 0000000..52c265b
--- /dev/null
+++ b/hig3/src/pages/color.haml
@@ -0,0 +1,9 @@
+%h1
+ Color
+
+.note
+ This is draft content for the next version of
+ %a{:href => 'http://design.gnome.org'} GNOME Human Interface Guidelines.
+
+
+FIXME: palette, dark/light themes, background colors for content
diff --git a/hig3/src/pages/dark-theme.haml b/hig3/src/pages/dark-theme.haml
new file mode 100644
index 0000000..bf6d39b
--- /dev/null
+++ b/hig3/src/pages/dark-theme.haml
@@ -0,0 +1,3 @@
+%h1 Dark Application Theme
+
+FIXME
diff --git a/hig3/src/pages/design_principles.haml b/hig3/src/pages/design_principles.haml
new file mode 100644
index 0000000..19ebb93
--- /dev/null
+++ b/hig3/src/pages/design_principles.haml
@@ -0,0 +1,151 @@
+%h1
+ GNOME 3 Design Principles
+
+.note
+ This is draft content for the next version of
+ %a{:href => 'http://design.gnome.org'} GNOME Human Interface Guidelines.
+
+%p
+ These design principles describe the high-level aims and strategies that should be followed when designing a GNOME 3 application.
+
+%h2
+ Give each window or view a clear focus
+
+%p
+ Every extra piece of information or interface control competes with what is truly relevant to the user and distracts them from important information, so don't clutter your interface and don't overload it with buttons, icons, or irrelevant information.
+
+%p
+ Break down your application into different activities and provide a different, dedicated view for each one. There might be a browsing view and a reading view, for example. Dividing your application in this way will make it easy and satisfying to use.
+
+If a control or information is not essential for a view, do not include it.
+
+%h2
+ Require as little user input as possible
+
+%p
+ An application that is laborious to use can become the source of irritation, so strive to make your software work for your users, not the other way around.
+
+%p
+ Reduce the number of button presses and other forms of input that your application requires, and avoid mandatory configuration steps if you can. Make your application be as automatic as possible; manual 'management' functionality should not be necessary for the vast majority of applications.
+
+%h2
+ Prioritise and elevate content
+
+%p
+ Content can take many forms, including text, video, images and sound. People care about content and it is what they are interested in, so take care to present content in the best possible way, so that it can be experienced and enjoyed with ease.
+
+%p
+ Ensure that content takes center stage in your application by positioning it prominently and by not distracting attention from it with superfluous interface elements.
+
+%p
+ It is easy to overload a view with too much content, so be selective about how much you present at any one time. Resist the temptation to include information just because you have access to it (this is particularly important when presenting text and metadata): instead, think about what is useful and important to users.
+
+%p
+ You might want to provide a dedicated view for displaying or working with individual items of content.
+
+%p
+ Finally, ensure that you present visual content in order to make it look as good as possible. Follow the guidance on color and layout, and consider using the
+ = link "dark application theme", "dark-theme.html"
+ \.
+
+%h2
+ Donât interrupt the user
+
+Nobody likes being interrupted, particularly if the interruption demands something from them. A key principal of GNOME 3 is to avoid interrupting users when they are focused on a task.
+
+Remember that the job of your application is to work for the people that use it. It should stay out of the way when it is not required but be on hand when needed.
+
+Use system notifications with restraint and make effective use of the different types of GNOME 3 notifications. You should also avoid confirmation dialogs where possible. These break someone's flow and can become a source of irritation. Instead, offer the opportunity to [[Design/HIG/Undo|undo]] destructive actions.
+
+%h2
+ Go beyond the local
+
+People's content is increasingly located online, as are many of the services that are important to them. Think about how you can enable them to connect with these services and content through your application.
+
+This enables them to access the same things across a range of devices, and it facilitates sharing and collaboration. When designing your application, think beyond the local from the very beginning and consider incorporating online services and content. This will enable you to provide truely social experiences.
+
+If your application uses online facilities, you may be able to take advantage of GNOME Online Accounts.
+
+%h2
+ Reduce the presence of windows
+
+Windows produce a number of management tasks that create work for people wanting to use your application. Reducing the presence of windows that need managing means that applications involve less work, make the full use of the screen space that is available to them, and that provide a seamless experience.
+
+Your application's [[Design/HIG/PrimaryWindows|primary windows]] should typically be maximized by default and their title bars hidden. Multiple views can be used to replace the need for several windows.
+
+%h2
+ Create a clear hierarchy
+
+People âreadâ an interface from top to bottom. Within each view or window, you should order your interface elements according to this movement. Place interface elements according to when they should be encountered, so that elements that need to be read first are placed above other elements. Placing headings above the content that they describe is one obvious example of this.
+
+Interface elements should also be positioned according to their dominance in the view or window. Controls should be placed above and to the left of other controls or content that they have an affect on: filter buttons and search boxes should be found above the content that they control, for example. Placing elements in this order makes their importance and function clear to people using your application.
+
+%h2
+ Donât make people burrow too deep
+
+Following a path through successive layers of interfaces can be confusing. Avoid locating functionality within deeply nested navigation points, such as multiple windows or views, by keeping navigation structures shallow.
+
+Always make it easy for users to find their way back to where they started. You can do this by using back buttons consistently when providing multiple views. Home buttons, such as those found within the System Settings panel and Web application can also be used.
+
+%h2
+ Facilitate sociability
+
+Functionality that allows people to share content and communicate with others is highly attractive, and is something that is expected from a high quality piece of software.
+
+If your application handles content, consider adding sharing and sending actions so that people can pass it on it to their friends, family and colleagues. Since these actions are important, you might want to make them prominent in your user interface. The core GNOME 3 applications utilise design patterns that can be used for this purpose.
+
+%h2
+ Make it beautiful
+
+Appearances matter - beautiful things bring joy and happiness, and people will enjoy using your application more if it looks good.
+
+Generally, an application that is easy to use and understand will also look good, and many of the other design guidelines will help you to produce a beautiful design. However, take the time to ensure that the controls and information you present create a harmoneous and balanced appearance.
+
+Reproduce the standard GNOME 3 layouts and color schemes. Ensure that you use the default GNOME icon sets and follow the guidelines regarding icon usage. If you do need additional visual assets, make sure that they are high quality and consistent with GNOMEâs guidelines.
+
+%h2
+ Provide quick and effective search
+
+Search is an important design pattern in GNOME 3. People should be able to expect to be able to use search whereever it might be useful to them and for search to quickly provide the results they are looking for.
+
+Applications that present large amounts of content, including any long list, should provide the ability to search. Make search as fast and immediate as possible, and utilise the standard search design patterns for consistency.
+
+%h2
+ Use configuration options sparingly
+
+If you give your application a clear focus and design it around that focus, you will be able to cater to the needs of the vast majority of potential users without the need for multiple configuration options. Minimising the presence of settings in your application will make it easier to use. It will also make it easier for you to focus on providing the best quality core functionality. Remember that most people will never use settings, so it is important that your application works for them without the need for configuration.
+
+%h2
+ Use language that is familiar to your users
+
+Always use words, phrases, and concepts that are familiar to the people who will be using your application, rather than terms from the underlying system. Use terms that relate to the tasks your application supports. For example, in medicine, the paper folder that contains all information about a specific patient is called a "chart." Hence, a medical application might refer to a patient record that contains the same information as a paper chart as a "patient chart" rather than as a "patient database record."
+
+%h2
+ Give your application an instructive name and an attractive icon
+
+Your applicationâs name and icon are two of the most expressive things about it, so design them in order to communicate its function and identity.
+
+Do not pick an application name that users will not associate with its purpose, so avoid obscure cultural references, in jokes and acronyms. Instead, make sure that people can quickly make the connection between your applicationâs name and what it does. Short, concise names are easier to remember and will look better in the interfaces where it is present.
+
+Also ensure that you provide a recognisable, high-resolution application icon. This will be one of the main ways that people will recognise your application when using it in GNOME 3.
+
+%h2
+ Donât expose users to the filesystem
+
+Storing and retrieving content using the filesystem provides a poor user experience. It is hard work, difficult to use and is error prone. It cannot be easily tailored to the different use cases and scenarios encountered by users, and it does not work well with online integration.
+
+Avoid letting the filesystem have an obvious presence in the design of your application. Instead, make it quick and easy for people to access the content they are interested in by using the standard GNOME 3 design patterns and by leveraging the built in GNOME 3 content services. These take the work out of finding content and will allow you to integrate with relevant online services. The GNOME 3 core applications provide examples that you can follow.
+
+%h2
+ Accommodate different types of devices
+
+GNOME 3 is targetted at a range devices. These vary in terms of screen size and orientation and the ways in which people interact with them. Following the GNOME 3 application design patterns will allow you to produce an application that copes with these variations. Nevertheless, it is important that you evaluate your application design against requirements. In particular:
+
+%ul
+ %li
+ Ensure that your application is effective on screens as small as 1024x600.
+ %li
+ Design for changes in screen rotation, so your application works well in both portrait and landscape views.
+ %li
+ Consider both touch and pointer-based input.
+
diff --git a/hig3/src/pages/design_strategies.haml b/hig3/src/pages/design_strategies.haml
new file mode 100644
index 0000000..8503d99
--- /dev/null
+++ b/hig3/src/pages/design_strategies.haml
@@ -0,0 +1,91 @@
+%h1
+ Application Design Strategies
+
+.note
+ This is draft content for the next version of
+ %a{:href => 'http://design.gnome.org'} GNOME Human Interface Guidelines.
+
+%p
+ These application design strategies provide some introductary advice on how to approach the process of designing a GNOME 3 application. It is not intended to be a complete or thorough guide to UX design, and should not be relied on as the sole source of guidance on this topic. There are numerous ways to approach the application design process, and you are encouraged to learn about these various methodologies as a part of developing your own design practice.
+
+ This guidance is primarily intended for those who are new to UX design.
+
+%h2
+ Define Scope and Goals Early
+
+%p
+ Establishing ''what'' your application will do is possibly the most important part of the design process. Here, your aim should be to ensure that the goals for your application are clear and focused. Your application should do one thing and do it well, and you should not attempt to cater to incompatible use cases and requirements within the same application. Resist the temptation to try and please everybody and instead aim for excellence in one particular area.
+
+%p
+ Scope can be defined in terms of key functionality and use cases. Here, it is important to think about the contexts in which your application will be used and who will be using it. Understanding the needs and desires of the people who you want to use your application is key here, as well as the various situations in which they might find themselves. Where will they use your application? How will they use it? What are the challenges that they face and what can you do to give them a positive experience?
+
+%p
+ It is important to pay attention to user experience when you are establishing the goals for your application design. Consider how you want your application to feel and what kinds of emotional reactions you want it to generate. These will often be the same user experience goals that are contained within the GNOME 3
+ =link "Design Principles"
+
+%p
+ Determining what your application will not do is just as important as determining what it will do. Identifying scenarios, functionality and use cases that you do not intend to accomodate within your design will assist you in creating a focused application. Take care to document any use cases that you have excluded from your scope as well as those what you have included.
+
+%h2
+ Research Existing Approaches
+
+%p
+ Take the time to find existing designs that are relevant to your goals, and work to identify a small set of inspirational relevant art. This will often include application designs that are similar in scope to your own, but you should not limit your search to either application designs. Include the full range of UX design in your research including designs for different types of devices, websites, games and even print design.
+
+%p
+ Limit your relevant art to examples that are inspiring or interesting, and seek out design excellence. Do not look to poor quality designs that appear relevant because their scope is similar to that of your application. When designing a music player, do not include any music player you can find, for example. Instead, seek out software that presents music and other content in delightful and elegant ways, or which provides novel solutions to the design challenges that you face.
+
+%p
+ Evaluate and assess the examples of relevant art that you have found. Test it if you can, either yourself or by conducting user testing. Identify what you like about the relevant art that you have collected and assess whether the approaches that it contains are appropripate for your own application. Also investigate if there are any design or usability problems with your relevant art.
+
+%p
+ Make sure that you study the core GNOME 3 applications and the HIG design patterns within your research activities. This will help you determine which of the existing GNOME 3 design approaches will be useful to your in your application design.
+
+%p
+ Researching relevant art can be highly productive; you should use it as a tool to widen your horizons and to introduce new design approaches into your process. By the same token, do not let your relevant art impose limits on the possibilities you are considering. Research is there to supplement your design thinking rather than restrict it.
+
+%h2
+ Use Low Fidelity Mockups
+
+%p
+ Once you have established the scope of your application design and evaluated relevant art, you can start thinking about what your application will look like and how it will work. Be careful not to begin this stage of the design process too early; you should concentrate on high level design goals before concerning yourself with the details of what your user interface should be like.
+
+%p
+ Low fidelity mockups or sketches are a good way to document and develop concepts for your interface (once you are ready to design it). Generic graphics software or special purpose mockup applications can be used for this purpose, but so can pencil and paper.
+
+%p
+ Choose your mockup tools in order to enable you to quickly try out ideas. It is important to try different interface designs at this stage, and you should be prepared to throw ideas away. Whatever tool you choose, ensure that you do not invest too much time rendering your ideas. This will help to stop you from becoming too attached to them.
+
+%p
+ Pay attention to interaction flow in early designs. Visualize the sequences of actions that will be involved in using your software. Paper cut outs, flow diagrams or graphics software with layering capabilities can all be useful for this.
+
+%p
+ Evaluate and critique each of the designs that you come up with until you have a robust design that fulfils the goals you have set out. This part of the design process can be lengthy: time your time and make sure that you don't select a UI design prematurely.
+
+%h2
+ Prototype and 'Dog Food'
+
+%p
+ Work to test your designs througout the design process, both on yourself and others.
+ There are many quick and low cost ways that you can explore your designs. Static images displayed on the screen can be used as a kind of prototype, and can give you an impression of how your application will look, work and feel. Paper prototying can also be used to explore interaction flows with others. Showing mockups to others without the aid of notes or explanation will help you to establish that the interface you have designed is easy to interpret.
+
+%p
+ It is especially important to test your design if it includes novel approaches. Throwaway software prototypes are an excellent way to do this and can save you a huge amount of time in the long run.
+
+%p
+ Once implemtation of your application has begun, ensure that you regularly use development versions of the software in order to identify design bugs.
+
+%h2
+ High Fidelity Mockups
+
+%p
+ Low fidelity mockups can be used to communicate and develop many aspects of your user interface, including visual layout, interaction flow, text and labels.
+
+%p
+ However, visual rendering and aesthetics are an important part of application design, and this requires higher fidelity visual designs to be created in the form of detailed high resolution mockups. If your application utilises novel controls or visual elements, these should be designed in advance of implementation. Artist expertise will often need to be enlisted in order to address this aspect of the design.
+
+%h2
+ Iterate
+
+%p
+ A UX design is rarely finished, if ever. There are always improvements that can be made, and it is important to continually assess your design. Expect to have to make changes to your design as it is implemented, and work to refine it as application development proceeds.
diff --git a/hig3/src/pages/keyboard_input.haml b/hig3/src/pages/keyboard_input.haml
new file mode 100644
index 0000000..c67624a
--- /dev/null
+++ b/hig3/src/pages/keyboard_input.haml
@@ -0,0 +1,154 @@
+%h1
+ Keyboard Input
+
+.note
+ This is draft content for the next version of
+ %a{:href => 'http://design.gnome.org'} GNOME Human Interface Guidelines.
+
+%p
+ Keyboards are a common input device for those using GNOME 3, so it is important that you design your application with them in mind. The keyboard can be a quick and effective effective input method. Allowing people to use a keyboard instead of a pointing device can save them time and effort and can be convenient for many operations. The keyboard is also important for visually-impaired people or those with mobility impairments.
+
+.important
+ Search is an important part of the way that people interact with GNOME 3. Make sure that you are familiar with the search design pattern and follow it wherever it is relevant.
+
+%h2
+ Keyboard Navigation
+
+%p
+ Ensure that all the functionality provided by your application can be accessed using a keyboard, including toolbars, links and buttons. Trying to use your application only with a keyboard is a great way to test this.
+
+%ul
+ %li
+ The tab key is the standard way of navigating through a GNOME user interface using the keyboard. Make sure that all the parts of your application can be accessed in this manner.
+ %li
+ Use a logical keyboard navigation order. When navigating around a window with the Tab key, keyboard focus should move between controls in a predictable order. In Western locales, this is normally left to right and top to bottom.
+ %li
+ Ensure correct tab order for controls whose enabled state is dependent on check box, radio button or toggle button state. When such a button is selected, all its dependent controls should be enabled, and all the dependent controls of any other button in the group should be disabled. When the user selects a check box, radio button or toggle button that has dependent controls, do not automatically give focus to the first dependent control, but instead leave the focus on the button.
+
+%h2
+ Access Keys
+%p
+ Access keys allow someone to operate labelled controls by using the Alt modifier key.
+
+%ul
+ %li
+ Give all labelled components an access key (underlined letter), with the exception of toolbar controls which would use up too many access key combinations.
+ %li
+ Choose access keys to be as easy to remember as possible. Normally, this means using the first letter of the label. However, in complex windows, the choice can become more difficult. Here are some simple rules:
+ %li
+ Assign access keys to the most frequently-used controls first. If it's not clear which controls will be the most frequently used, assign access keys from left to right, top to bottom (for Western locales).
+ %li
+ Use the first letter of the label, or of one of its other words if it has more than one. If another letter provides a better association (e.g. "x" in Extra Large) however, consider using that letter instead.
+ %li
+ If the first letter is not available, choose an easy to remember consonant from the label, for example, "p" in Replace.
+ %li
+ If no such consonants are available, choose any available vowel from the label.
+ %li
+ If duplication of access keys in a window is unavoidable, you should still refrain from duplicating the access keys for any of these buttons that appear in the same window: OK, Cancel, Close, Apply or Help.
+ %li
+ It is better not to assign access keys to "thin" letters (such as lowercase i or l), or letters with descenders (such as lowercase g or y) unless it is unavoidable. The underline does not show up very well on those characters in some fonts.
+ %li
+ Applications using a non-Roman writing system in conjunction with a standard keyboard can have control labels prefixed with Roman characters as access keys.
+
+%h2
+ Shortcut Keys
+
+%p
+ Shortcut keys are a good way to provide quick and convenient access to common operations. Be sure to use the standard GNOME shortcut keys (see below) if your application supports those functions. This ensures consistency between GNOME applications and aids discoverability.
+
+%p
+ Guidance on assigning your own shortcut keys:
+
+%ul
+ %li
+ Try and be consistent with other GNOME applications, particularly the core applications, and take the time to find out what shortcut keys they have defined.
+ %li
+ Only assign shortcut keys to the most commonly-used actions in your application. Do not try to assign a shortcut keys to everything.
+ %li
+ Do not use any of the standard GNOME shortcut keys for your own purposes, even if your application doesn't support those functions. This helps reinforce consistency between all GNOME applications.
+ %li
+ Use Ctrl+letter in preference to other combinations when choosing new shortcut keys and Shift+Ctrl+letter for functions that reverse or extend another function. For example, Ctrl+Z and Shift+Ctrl+Z for Undo and Redo.
+ %li
+ Choose new shortcut keys to be as mnemonic as possible, as these will be easier to learn and remember. For example, Ctrl+E would be a good shortcut for a menu item called Edit Page.
+ %li
+ Shortcuts that can be easily used with one hand are preferable for common operations, but try not to assign awkward reaches for shortcuts that may be frequently used.
+ %li
+ Do not use Alt+key combinations for shortcut keys, as these may conflict with window manager shortcuts or access keys.
+
+%h2
+ Standard GNOME Shortcut Keys
+
+%p
+ Include these where you can:
+
+%table
+ %tr
+ %th
+ Function
+ %th
+ Shortcut
+ %th
+ Description
+ %tr
+ %td
+ New
+ %td
+ %span.shortcut
+ Ctrl+N
+ %td
+ Create a new document
+ %tr
+ %td
+ Open
+ %td
+ %span.shortcut
+ Ctrl+O
+ %td
+ Open a document
+ %tr
+ %td
+ Save
+ %td
+ %span.shortcut
+ Ctrl+S
+ %td
+ Save the current document
+ %tr
+ %td
+ â
+ %td
+ %span.shortcut
+ Ctrl+â
+ %td
+ â
+
+%h2
+ System Reserved Shortcut Keys
+%p
+ These ones are ours.
+
+%table
+ %tr
+ %th
+ Function
+ %th
+ Shortcut
+ %th
+ Description
+ %tr
+ %td
+ â
+ %td
+ â
+ %td
+ â
+
+
+%h2
+ Comments
+
+%ul
+ %li
+ Other prominent shortcuts that should be mentioned here: F11 - fullscreen, Ctrl-X/Ctrl-C/Ctrl-V for cut/copy/paste
+ %li
+ I'd really like to see some guidance on global shortcuts here - people have a tendency to write small things that hide in the statusbar and install global shortcuts to make something happen. We should really advise against that, since global shortcuts are a scarce resource. If a global shortcut is needed at all, it '''must''' be coordinated with the rest of the system by integrating in the keyboard shortcuts control-center functionality.
diff --git a/hig3/src/pages/pointer_and_touch_input.haml b/hig3/src/pages/pointer_and_touch_input.haml
new file mode 100644
index 0000000..fe6a769
--- /dev/null
+++ b/hig3/src/pages/pointer_and_touch_input.haml
@@ -0,0 +1,9 @@
+%h1
+ Pointer and Touch input
+
+.note
+ This is draft content for the next version of
+ %a{:href => 'http://design.gnome.org'} GNOME Human Interface Guidelines.
+
+
+FIXME
diff --git a/hig3/src/pages/system_shell.haml b/hig3/src/pages/system_shell.haml
new file mode 100644
index 0000000..4fa1739
--- /dev/null
+++ b/hig3/src/pages/system_shell.haml
@@ -0,0 +1,9 @@
+%h1
+ System Shell
+
+.note
+ This is draft content for the next version of
+ %a{:href => 'http://design.gnome.org'} GNOME Human Interface Guidelines.
+
+
+FIXME: introduction to the top bar, activities overview, messaging tray and system settings
diff --git a/hig3/src/pages/visual_layout.haml b/hig3/src/pages/visual_layout.haml
new file mode 100644
index 0000000..08fae90
--- /dev/null
+++ b/hig3/src/pages/visual_layout.haml
@@ -0,0 +1,72 @@
+%h1
+ Visual Layout
+
+.note
+ This is draft content for the next version of
+ %a{:href => 'http://design.gnome.org'} GNOME Human Interface Guidelines.
+
+A clean layout is crucial to creating a smooth visual flow of information for the user and a beautiful aesthetic. The positioning of controls and content on the screen conveys important information and makes your application easy to understand.
+
+.note
+ Further information on layout can be found in the individual design patterns that make up the HIG. The Grid and List patterns describe how to organize layouts of content, for example.
+
+%h2
+ General Guidance
+
+%ul
+ %li
+ Keep visual complexity low by using ample whitespace. Ensure that the visual elements in your interface are not placed too tightly together so that they have space to breathe. This will ensure that your application feels light and elegant. It will also ensure that people using it can easily understand the information that is being presented to them.
+
+ %li
+ Communicate that visual elements and controls are related by placing them close to one another. Groups of visual elements can be distinguished by separating them using spacing, for instance.
+
+ %li
+ Minimize the number of alignment points in your window or view. An alignment point is an imaginary vertical or horizontal line through your window that touches the edge of one or more labels or controls in the window. The fewer alignment points, the cleaner and simpler your layout will appear, and the easier it will be for people to understand.
+
+ %li
+ Align content and controls in your layout exactly. The eye is very sensitive to aligned and unaligned objects. If nothing lines up with anything else, it will be very hard for someone to scan the contents and find the information he/she wants. Two things do not quite line up are equally distracting.
+
+ %li
+ Be consistent. Use the same amounts of spacing and component sizes. Reuse the same amounts of spacing throughout.
+
+%h2
+ Layout Schemas
+
+%ul
+ %li
+ Organize windows and views from top-to-bottom and left-to-right. This is the direction that people from western locales tend to read an interface, so that the items at the top-left will be encountered first.
+
+FIXME: Visual order diagram
+
+%ul
+ %li
+ This ordering gives interfaces a hierarchy: those components that are viewed first are perceived to have priority over those that come after them. For this reason, you should place dominant controls above and to the left of the controls and content that they affect. In [[Design/HIG/PrimaryWindows|Primary Windows]], this can be typically be achieved by using a [[Design/HIG/PrimaryToolbar|Primary Toolbar]].
+
+FIXME: Alignment points diagram
+
+%ul
+ %li
+ Utilise the key GNOME 3 alignment points. The GNOME 3 top panel provides three alignment points that you can use to create layouts that are in harmony with the GNOME 3 shell and are consistent with other GNOME 3 applications.
+
+%h2
+ Laying Out Groups of Controls
+
+FIXME: Spacing diagram
+
+%ul
+ %li
+ As a basic rule of thumb, leave space between elements in increments of 6 pixels, going up as the relationship between related elements becomes more distant. For example, between icon labels and associated graphics within an icon, 6 pixels are adequate. Between labels and associated components, leave 12 horizontal pixels. For vertical spacing between groups of components, 18 pixels is adequate. A general padding of 12 pixels is recommended between the contents of a dialog window and the window borders.
+
+FIXME: Justification diagram
+
+%ul
+ %li
+ Right justification within groups or the overall window looks good. If the combination of controls in your layout do not permit this arrangement, left justification should be used.
+ %li
+ Indent group members 12 pixels to denote hierarchy and association.
+ %li
+ When a user is scanning a complex preferences dialog consisting of many labels and corresponding check boxes, text fields, and drop-down combination boxes, it is easy to see how she can quickly become hindered by poor layout in the visual design.
+ %li
+ Right justification is particularly appropriate if control labels greatly differ in length - this will ensure that the controls do not end up too far away from their corresponding labels.
+ %li
+ Avoid using frames with visible borders to separate groups of controls - use spacing and headers instead.
diff --git a/hig3/src/pages/writing_style.haml b/hig3/src/pages/writing_style.haml
new file mode 100644
index 0000000..8cd61f5
--- /dev/null
+++ b/hig3/src/pages/writing_style.haml
@@ -0,0 +1,137 @@
+%h1
+ Writing Style
+
+.note
+ This is draft content for the next version of
+ %a{:href => 'http://design.gnome.org'} GNOME Human Interface Guidelines.
+
+Text is an important part of user interfaces. Take the time to ensure that any text that is presented to users is clearly written and easy to understand. Text also has an important visual role; it is important to ensure that you use the correct sizes, weights and positioning in order to produce a beautiful and effective interface.
+
+%h2
+ Writing Text for Your User Interface
+
+%p
+ Ensuring that text is quick and easy to understand is an important part of designing your application.
+
+%ul
+ %li
+ Keep text short and to the point. This improves speed of comprehension for the user. It also reduces the expansion of text when translated (remember that translated English text can expand up to 30% in some languages).
+ %li
+ Do not shorten your text to the point of losing meaning, however. A three-word label that provides clear information is better than a one-word label that is ambiguous or vague. Try to find the fewest possible words to satisfactorily convey the meaning of your label.
+ %li
+ Ensure that you use language that is familiar to your users and that is specific to the context of your application. Avoid using technical terminology or terminology from the underlying system.
+ %li
+ Use the standard GNOME terms when referring to parts of the user interface, such as âpointerâ and âwindowâ. You can find a full list of these in the GNOME Documentation Style Guide, Recommended Terminology.
+ %li
+ Avoid repetition where possible. Remember the context of the text you are writing and try to avoid having the repetitive use of the same phrases and terms in the same view or window.
+
+%h2
+ Labels
+
+%p
+ Labels are the text that accompanies individual controls in your interface. Some controls have them placed alongside, such as switches, checkboxes and radio buttons. Others, such as menu items and buttons, have the label placed directly on the control itself.
+
+%ul
+ %li
+ Use the recommended standard labels for menu items, where they exist. Do not use synonyms such as Exit instead of Quit.
+ %li
+ Ensure that a label with a mnemonic is associated with the control it labels.
+ %li
+ If a label precedes the control or text that it refers to, use a lighter color [needs specific guidance on which color to use. do we have named colors yet?] to differentiate it (this rule does not apply to headings). In these cases a colon at the end of the label is not necessary.
+
+%h2
+ Capitalization
+
+%p
+ Two styles of capitalization are used in GNOME user interface elements: header capitalization and sentence capitalization.
+
+%h2
+ Header Capitalization
+%p
+ Capitalize all words in the element, with the following exceptions:
+ %ul
+ %li
+ Articles: a, an, the.
+ %li
+ Conjunctions of three or fewer letters: and, but, for, not, so, yet ...
+ %li
+ Prepositions of three or fewer letters: at, for, by, in, to ...
+
+%p
+ Use for:
+
+%ul
+ %li
+ Button labels
+ %li
+ Column heading labels
+ %li
+ Group box or frame labels
+ %li
+ Menu items
+ %li
+ Menu items in applications
+ %li
+ Menu titles in applications
+ %li
+ Tabbed notebook titles
+ %li
+ Titlebar labels
+ %li
+ Webpage titles and navigational elements
+
+%h2
+ Sentence Capitalization
+
+%p
+ Capitalize the first letter of the first word, and any other words normally capitalized in sentences, such as application names.
+
+%p
+ Use for:
+
+%ul
+ %li
+ Check box labels
+ %li
+ Dialog messages
+ %li
+ Drop-down combination box labels
+ %li
+ Drop-down list box labels
+ %li
+ Field labels
+ %li
+ Filenames
+ %li
+ Graphic equivalent text: for example, Alt text on web pages
+ %li
+ Items in drop-down combination boxes, drop-down list boxes, and list boxes
+ %li
+ List box labels
+ %li
+ Radio button labels
+ %li
+ Slider labels
+ %li
+ Spin box labels
+ %li
+ Text box labels
+ %li
+ Tooltips
+
+%h2
+ Text Styles
+
+%ul
+ %li
+ If you are presenting different kinds of text based information closely together, use different sizes weights and colours to differentiate them. (Be sure to consult the relevant design patterns for further guidance on this.)
+ %li
+ Do not use more than two or three different text styles in your application. Too many textsizes, colors and weights will make the interface look complex, making it unattractive and difficult to understand.
+ %li
+ Do not use graphical backdrops or "watermarks" behind text. These interfere with the contrast between the text and its background. This can cause difficulty for users with visual impairments, who will therefore normally choose themes that always use plain backdrops.
+
+%h2
+ Comments
+
+%p
+Should perhaps mention the potential for confusion with 'disabled' controls when discussing uses of text color. Maybe the 'consult design patterns for further guidance' is supposed to address that...
diff --git a/hig3/src/stylesheets/hig.scss b/hig3/src/stylesheets/hig.scss
index d7d5be4..518b044 100644
--- a/hig3/src/stylesheets/hig.scss
+++ b/hig3/src/stylesheets/hig.scss
@@ -408,7 +408,7 @@ hr.footerart {
}
/* MOBILE VERSION BELOW */
- media screen and (max-width: 960px) {
+ media screen and (max-width: 960px),screen and (-webkit-min-device-pixel-ratio: 1.5) {
$total-width: 100%;
.gnomelink {
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
