GNOME.org
 

[gnome-devel-docs] HIG - incorporate feedback from Michael Catanzaro

commit 33340f4563e996a7b22759c59010243c76977980
Author: Allan Day <allanpday gmail com>
Date:   Wed Sep 17 12:01:47 2014 +0100

    HIG - incorporate feedback from Michael Catanzaro

 hig/C/application-menus.page |   48 ++++++++++++++++++++++++++++--------------
 hig/C/menu-bars.page         |    8 +++---
 hig/C/sliders.page           |    2 +
 hig/C/spin-boxes.page        |    6 +---
 hig/C/tabs.page              |   20 +++++------------
 hig/C/toolbars.page          |    2 +-
 6 files changed, 47 insertions(+), 39 deletions(-)
---
diff --git a/hig/C/application-menus.page b/hig/C/application-menus.page
index ef45178..4c35a62 100644
--- a/hig/C/application-menus.page
+++ b/hig/C/application-menus.page
@@ -24,28 +24,44 @@
 
 </section>
 
-<section id="menu-items">
-<title>Menu items</title>
-
-<p>Only include menu items that relate to the application as a whole, such as application preferences. 
Actions that are specific to a particular window or view, or which act on content within an application 
window, should not be included.</p>
-
-<p>Common application menu items include New Window, Preferences, Help, About and Quit.</p>
+<section id="general-guidelines">
+<title>General guidelines</title>
 
 <list>
-<item><p>If your application has user help, you should include a <gui>Help</gui> item.</p></item>
-<item><p>Every application menu should include <gui>About</gui> and <gui>Quit</gui>.</p></item>
-<item><p>If there are items other than <gui>Help</gui>, <gui>About</gui> and <gui>Quit</gui>, separate them 
into their own group at the bottom of the menu.</p></item>
+<item><p>Follow the standard <link xref="menus">guidance for menus</link>.</p></item>
+<item><p>Only include menu items that relate to the application as a whole, such as application preferences. 
Actions that are specific to a particular window or view, or which act on content within an application 
window, should not be included.</p></item>
+<item><p>If an item from the application menu is frequently used, consider moving it to a more accessible 
location.</p></item>
 </list>
 
 </section>
 
-<section id="additional-guidance">
-<title>Additional Guidance</title>
-
-<list>
-<item><p>Follow the standard <link xref="menus">design guidance for menus</link>.</p></item>
-<item><p>If an item from the application menu is frequently used, consider moving it to a more accessible 
location.</p></item>
-</list>
+<section id="standard-menu-items">
+<title>Standard Menu Items</title>
+
+<p>Common application menu items include <gui>New Window</gui>, <gui>Preferences</gui>, <gui>Help</gui>, 
<gui>About</gui> and <gui>Quit</gui>. <gui>Help</gui>, <gui>About</gui> and <gui>Quit</gui> should be 
contained within their own group at the bottom of the menu.</p>
+
+<table>
+<tr>
+<td><p><gui>New Window</gui></p></td>
+<td><p>Opens a new window. Only <link xref="primary-windows#application-types">multiple instance 
applications</link> should include this menu item. If the new window contains a specific type of content 
item, or simultaneously performs an action, rename it to be less generic. For example: <gui>New 
Connection</gui> or <gui>New Document</gui>.</p></td>
+</tr>
+<tr>
+<td><p><gui>Preferences</gui></p></td>
+<td><p>Opens the application's preferences dialog. Only show this menu item if your application has a 
preferences dialog.</p></td>
+</tr>
+<tr>
+<td><p><gui>Help</gui></p></td>
+<td><p>Opens your application's user documentation in the <app>Help</app> application. Only show this menu 
item if your application has user documentation.</p></td>
+</tr>
+<tr>
+<td><p><gui>About</gui></p></td>
+<td><p>Opens the application's about dialog. Every application menu should include this item.</p></td>
+</tr>
+<tr>
+<td><p><gui>Quit</gui></p></td>
+<td><p>Closes the application, including all application windows. Every application menu should include this 
item.</p></td>
+</tr>
+</table>
 
 </section>
 
diff --git a/hig/C/menu-bars.page b/hig/C/menu-bars.page
index 8af0803..f77f504 100644
--- a/hig/C/menu-bars.page
+++ b/hig/C/menu-bars.page
@@ -26,8 +26,6 @@
 
 <p>A menu bar incorporates a strip of drop-down menus. It is typically located at the top of a primary 
window, below a window title bar.</p>
 
-<p>The menubar is normally visible at all times and is always accessible from the keyboard, so make all the 
commands available in your application available on the menubar.</p>
-
 <media type="image" mime="image/svg" src="figures/ui-elements/menu-bar.svg"/>
 
 <section id="when-to-use">
@@ -35,7 +33,7 @@
 
 <p>Menu bars increase the vertical footprint of an application’s user interface, introduce a large number of 
disclosure points, and function as a fixed set of inflexible options. For these reasons, <link 
xref="header-bars">header bars</link> and <link xref="header-bar-menus">header bar menus</link> are generally 
recommended over menu bars, along with other design patterns for exposing controls on demand, such as <link 
xref="selection-mode">selection mode</link>, <link xref="action-bars">action bars</link>, and <link 
xref="popovers">popovers</link>.</p>
 
-<p>At the same time, menu bars can still be an appropriate choice, particularly for applications that 
already incorporate a header bar. Some platforms also incorporate space for a menu bar in their user 
environment, and a menu model can be desirable for cross-platform integration purposes.</p>
+<p>At the same time, it can be appropriate for complex applications that already include a menu bar to 
retain it. Additionally, some platforms also incorporate space for a menu bar in their user environment, and 
a menu model can be desirable for cross-platform integration purposes.</p>
 
 </section>
 
@@ -43,6 +41,8 @@
 <title>General guidelines</title>
 
 <list>
+<item><p>The menubar is normally visible at all times and is always accessible from the keyboard, so make 
all the commands available in your application available on the menubar. (This guideline is unique to menu 
bars - other menus should not seek to reproduce functionality that is made available by other 
controls).</p></item>
+<item><p>Treat <link xref="application-menus">application menus</link> as part of the menu bar - it is not 
necessary to reproduce items from the application menu in other menus.</p></item>
 <item><p>Do not disable menu titles. Allow the user to explore the menu, even though there might be no 
available items on it at that time.</p></item>
 <item><p>Menu titles on a menubar are single words with their first letter capitalized. Do not use spaces in 
menu titles, as this makes them easily-mistaken for two separate menu titles. Do not use compound words (such 
as <gui>WindowOptions</gui>) or hyphens (such as <gui>Window-Options</gui>) to circumvent this 
guideline.</p></item>
 <item><p>Do not provide a mechanism for hiding the menubar, as this may be activated accidentally. Some 
users will not be able to figure out how to get the menu bar back in this case.</p></item>
@@ -232,7 +232,7 @@
 <tr>
 <td><p><gui>Quit</gui></p></td>
 <td><p><keyseq><key>Ctrl</key><key>Q</key></keyseq></p></td>
-<td><p>Closes the application. If there are unsaved changes in any open documents, present the user with a 
confirmation alert for each affected document, giving the option to save the changes, discard them, or 
cancel. If there are no unsaved changes, close the application immediately without presenting any further 
messages or dialogs.</p>
+<td><p>Closes the application, including all application windows. If there are unsaved changes in any open 
documents, present the user with a confirmation alert for each affected document, giving the option to save 
the changes, discard them, or cancel. If there are no unsaved changes, close the application immediately 
without presenting any further messages or dialogs.</p>
 <p>In particular, non-document based applications, for example a game or a calculator, should save their 
state and exit immediately. This state should be restored the next time the application is started.</p></td>
 </tr>
 </tbody>
diff --git a/hig/C/sliders.page b/hig/C/sliders.page
index 3661fa9..7dd37f8 100644
--- a/hig/C/sliders.page
+++ b/hig/C/sliders.page
@@ -40,6 +40,8 @@
 <item><p>It is useful for the user to control the rate of change of the value in real time.</p></item>
 </list>
 
+<p>If the range of values does not have a fixed maximum and/or minimum, a <link xref="spin-boxes">spin 
box</link> can be used.</p>
+
 </section>
 
 <section id="guidelines">
diff --git a/hig/C/spin-boxes.page b/hig/C/spin-boxes.page
index c4de5c2..77ed9ca 100644
--- a/hig/C/spin-boxes.page
+++ b/hig/C/spin-boxes.page
@@ -31,11 +31,9 @@
 <section id="when-to-use">
 <title>When to use</title>
 
-<p>Use spin boxes for numerical input only. Use a list or option menu when you need the user to select from 
fixed data sets of other types.</p>
+<p>Use spin boxes to allow users to select numeric values, but only when those values are meaningful or 
useful for users to know. If they aren't, a <link xref="sliders">slider</link> might be a better choice.</p>
 
-<p>Use a spin box if the numerical value is meaningful or useful for the user to know, and the valid input 
range is unlimited or fixed at one end only. For example, a control for specifying the number of iterations 
of some action, or a timeout value. If the range is fixed at both ends, or the numerical values are arbitrary 
(for example, a volume control), use a slider instead.</p>
-
-<p>If the exact value in the spin button is not relevant to a user, a slider might be a better choice of 
control.</p>
+<p>Use spin boxes for numerical input only. For non-numeric sets of options, a <link 
xref="lists">list</link> or <link xref="drop-down-list">drop-down list</link> can be used instead.</p>
 
 </section>
 
diff --git a/hig/C/tabs.page b/hig/C/tabs.page
index 3183a69..633c6f3 100644
--- a/hig/C/tabs.page
+++ b/hig/C/tabs.page
@@ -24,14 +24,16 @@
 
 <title>Tabs</title>
 
-<p>Tabs provide a way to break down a window into a series of views. They come in two primary forms: fixed 
and dynamic. Fixed tabs provide an immutable set of defined views that are built into a user interface, 
primarily dialog windows. Dynamic tabs allow a user to view multiple documents or locations within an 
application’s primary window.</p>
+<p>Tabs provide a way to break down a window into a series of views. They come in two primary forms: fixed 
and dynamic.</p>
+
+<p>Fixed tabs provide an immutable set of predefined views, and are primarily used in dialog windows. 
Dynamic tabs allow a window to contain mutable selection of content items, such as pages, documents or 
images. They are primarily used within <link xref="primary-windows">primary windows</link>, as a part of 
editor or browser applications.</p>
 
 <media type="image" mime="image/svg" src="figures/ui-elements/tabs.svg"/>
 
 <section id="when-to-use">
 <title>When to use</title>
 
-<p>Use fixed tabs when a dialog contains too many controls (or too much information) to comfortably present 
them at the same time.</p>
+<p>Use fixed tabs when a <link xref="dialogs">dialog window</link> contains too many controls (or too much 
information) to be comfortably presented at once.</p>
 
 <p>Dynamic tabs are primarily useful for browser or editor applications, where a user might want to use 
several locations or content items simulatenously.</p>
 
@@ -45,7 +47,7 @@
 <item><p>Label tabs with <link xref="writing-style#capitalization">header capitalization</link>, and use 
nouns rather than verbs, for example <gui>Font</gui> or <gui>Alignment</gui>. Try to give tab labels a 
similar length.</p></item>
 <item><p>Do not design tabs such that changing controls on one page affects the controls on any other page. 
Users are unlikely to discover such dependencies.</p></item>
 <item><p>If a control affects every tab, place it outside the tabs.</p></item>
-<item><p>Use tabs that are proportional to the width of their labels. Don’t just set all the tabs to the 
same width, as this makes them harder to scan visually, and limits the number of tabs you can display without 
scrolling.</p></item>
+<item><p>With fixed tabs, make the width of each tab proportional to the width of its label. Don’t just set 
all the tabs to the same width, as this makes them harder to scan visually, and limits the number of tabs you 
can display without scrolling.</p></item>
 </list>
 
 </section>
@@ -57,18 +59,8 @@
 <item><p>Tabs often have a constrained width, so ensure that tab labels are short and concise, and that the 
most useful part of the label is displayed first. This ensures that the label continues to be useful even 
when ellipsized.</p></item>
 <item><p>If the content of a tab changes or requires attention, a visual hint can be displayed.</p></item>
 <item><p>Provide a context menu on each tab. This menu should only include actions for manipulating the tab 
itself, such as <gui>Move Left</gui>, <gui>Move Right</gui>, <gui>Move to New Window</gui>, and 
<gui>Close</gui>.</p></item>
+<item><p>If tabs are an important part of the application, a new tab button can be placed in the header bar 
or toolbar. Do not show a new tab button in applications where tabs will not always be used - keyboard 
shortcuts and/or menu items are sufficient in these cases.</p></item>
 </list>
 
-<section id="full-and-partial-integration">
-<title>Full and partial integration</title>
-
-<p>If tabs are an important part of the application, make the tab bar permanently visible, so that the first 
tab is visible when the application is launched. A new tab button can also be placed in the header bar or 
toolbar.</p>
-
-<p>Dynamic tabs can also be used in cases where tabs will not always be used, or do not form a core part of 
the application’s functionality. In these cases, tabs provide an additional extra function for those users 
who want to use them, without introducing superfluous controls for those who only view a single location or 
content item within each window.</p>
-
-<p>In these cases, the tab bar should only be displayed when two or more tabs are open, and a new tab button 
should not be displayed in the header bar or toolbar. Keyboard shortcuts or menu items should be used to 
allow new tabs to be opened.</p>
-
-</section>
-
 </section>
 </page>
diff --git a/hig/C/toolbars.page b/hig/C/toolbars.page
index 1f6c355..b8e8d00 100644
--- a/hig/C/toolbars.page
+++ b/hig/C/toolbars.page
@@ -42,7 +42,7 @@
 
 <list>
 <item><p>Only include controls for the most important functions. Having too many toolbar controls reduces 
their efficiency by making them harder to find, and too many rows of toolbars reduces the amount of screen 
space available to the rest of the application.</p></item>
-<item><p>Utilize conventions for toolbars to increase familiarity. For example, the main toolbar in an 
office application will nearly always have New, Open and Save as its first three toolbar buttons. Similarly, 
the first few buttons in a browser application should always include Back, Forward, Stop and Reload, in that 
order.</p></item>
+<item><p>Utilize conventions for toolbars to increase familiarity. For example, the main toolbar in an 
office application will nearly always have new, open and save as its first three toolbar buttons. Similarly, 
the first buttons in a browser application should be back and forward.</p></item>
 <item><p>Place only the most commonly-used application functions on your toolbars. Don’t just add buttons 
for every menu item.</p></item>
 <item><p>If you are using a <link xref="menu-bars">menu bar</link>, ensure that it includes all the 
functions that appear on you toolbar, either directly (i.e. an equivalent menu item) or indirectly (e.g. in 
the <guiseq><gui>Options</gui><gui>Settings</gui></guiseq> dialog).</p></item>
 <item><p>Toolbars shouldn’t include buttons for <gui>Help</gui>, <gui>Close</gui> or <gui>Quit</gui>, as 
these are rarely used and the space is better used for more useful controls. Similarly, only provide buttons 
for <gui>Undo</gui>, <gui>Redo</gui> and the standard clipboard functions if there is space on the toolbar to 
do so without sacrificing more useful, application-specific controls.</p></item>
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]