an image of a file folder suggests a container into which documents can be placed

a waste basket suggests a container into which items can be placed when they are no longer needed

Assign your application to only one category on the Applications menu

For application suites that wrap a number of smaller sub-applications into a single window, such as Evolution or OpenOffice.org, add a menu item for each sub-application. For example, the mail, calendar, and tasklist in Evolution should each have their own menu item.

Short Descriptions should be short, less than 8 words, describing the purpose of the key

Long Description should be complete in describing the possible values of the key and the effects that those values have on the application

It is often better to use the progress bar contained in many primary windows' statusbar rather than a progress window. See Section 7.4.2.1.1, “Progress Windows vs. the Statusbar” for details on choosing between the two.

Progress windows should use primary and secondary text like an alert. See Section 3.4.1, “Alert Text”

The progress bar text should provide an idea of how much work has been completed. It is better to provide specific information rather than a unitless percentage. For example, "13 of 19 images rotated" or "12.1 of 30 MB downloaded" rather than "13% complete".

If possible, an estimate of the time left until the operation is complete should also be included in the progress bar text. Indicate that the "time left" is an estimate using the word "about".

Immediately beneath the progress bar, place italicized text indicating the current sub-operation being performed. This might be a step in a sequence, "Contacting control tower for permission to land", or it could be the current object being operated on in a bulk operation, "Rotating MonaLisa.png", "Rotating StarryNight.png".

If the operation in progress is potentially hazardous (destructive, costly, etc) or heavily taxes a limited resource for more than ten seconds (network bandwidth, hard disk, CPU, etc), consider placing a Pause toggle button to the right of the Cancel button. When paused, the italicized current sub-operation text should have " (Paused)" appended. This will allow users to perform important tasks requiring that resource, or give them time to think whether they want to procede with a dangerous operation they inadvertantly triggered.

Provide a menubar in each primary application window, containing at least a File and a Help menu.

Organize menu titles in the standard order— see Section 4.4, “Standard Menus”

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.

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 WindowOptions) or hyphens (such as Window-Options) to circumvent this guideline.

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.

Place application-specific menus after the Format menu and before the Go menu

Place application-specific menu items towards the middle of a standard menu, unless they logically fit with one of the standard groups already on the menu.

Place only the most commonly-used application functions on your toolbars. Don't just add buttons for every menu item.

By default, have your toolbars appear directly below the main menu bar.

Allow toolbars to be turned on and off in your application's Preferences dialog and by using the View → Toolbar menu item. If there is more than one toolbar, they are turned on and off by individual entries in the View → Toolbar submenu.

All functions that appear on your toolbars must also accessible via the main menu bar, either directly (i.e. an equivalent menu item) or indirectly (e.g. in the Options → Settings dialog).

Arrange toolbar buttons in the same order and groupings as their equivalents on the main menu bar. In particular, always group sets of mutually-exclusive toolbar buttons.

Don't add buttons for Help, Close or Quit to your toolbar by default, as these are rarely used and the space is better used for more useful controls. Similarly, only provide buttons for Undo, Redo and the standard clipboard functions if there is space on the toolbar to do so without sacrificing more useful, application-specific controls.

Provide options to show toolbar buttons as text, graphics or both— see Figure 5.2, “Example View menu fragments for applications with one toolbar (left), two or three toolbars (middle), or four or more toolbars (right)” for the menus to use for controlling toolbar display. Also provide an option to return all toolbars in your application to the control center default for this setting.

Allow users to configure toolbars to contain their own selection of commands, in whatever order they choose. Provide an option in the configuration dialog to return the toolbars to their default configuration.

Save your application's toolbar position and contents as part of the application configuration, and restore them when the application is restarted.

Allow the user to override the control center toolbar defaults for your particular application in the application's Preferences dialog. In particular, ensure that the user can:

If your application has a single toolbar, allow the user to turn it on or off with a View → Toolbar check box menu item.

If your application has two or three toolbars, allow the user to turn them on or off individually by placing a menu item for each one on the application's View menu. For example, Main Toolbar, Drawing Toolbar, Formatting Toolbar. Place the items together in a single group on the menu, with Main Toolbar first (if your application has one), followed by the others in alphabetical order.

If your application has more than three toolbars, allow the user to turn them on or off individually by placing a menu item for each one in a Toolbars sub-menu on the application's View menu. Place the Main Toolbar item first (if your application has one), followed by the others in alphabetical order.

Figure 5.2. Example View menu fragments for applications with one toolbar (left), two or three toolbars (middle), or four or more toolbars (right)

For buttons that correspond directly to menu items, make the text label the same as the menu item, but without any trailing ellipsis. For example, Open, Save.

Do not provide access keys for toolbar buttons. Since toolbars are in the same keyboard focus context as the menubar, it would be too difficult to provide unique access keys for every menu title and toolbar control. Toolbars are primarily intended as a shortcut for mouse users, although they are keyboard-navigable for accessibility reasons.

If your toolbar is configured to show labels below button icons, show a label for every control on the toolbar. For example:

Figure 5.3. Toolbar with labels under all buttons

If your toolbar is configured to show labels beside button icons rather than below them (using the "priority text" setting), do not show labels for every button. Show labels only for the buttons that will be most-frequently used. Choose no more than four such icons on any one toolbar, otherwise the effect will be diluted and the toolbar will become very wide. For example:

Figure 5.4. Toolbar with "priority text" labels beside the first few buttons only

If you are unsure which buttons will be most frequently used, choose the first few buttons on your toolbar and provide labels for those only.

Ensure all toolbar controls have tooltips. The tooltip should be more descriptive than the corresponding menu item, if it has one, but still concise. For example, Create new document for the Open toolbar button. Use sentence capitalization for tooltips—see Section 8.3.2, “Capitalization” for more information.

Label the entry field with a text label above it or to its left, using sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the entry field.

Right-justify the contents of entry fields that are used only for numeric entry, unless the convention in the user's locale demands otherwise. This is useful in windows where the user might want to compare two numerical values in the same column of controls. In this case, ensure the right edges of the relevant controls are also aligned.

When the user gives focus to an entry field using the keyboard, place the text cursor at the end of the existing text and highlight its contents (but don't overwrite the existing PRIMARY clipboard selection). This makes it easy to immediately overtype or append new text, the two most common operations performed on entry fields.

Size text entry fields according to the likely size of the input. This gives a useful visual cue to the amount of input expected, and breaks up the dialog making it easier to scan. Don't make all the fields in the dialog the same width just to make everything line up nicely.

In an instant-apply property or preference window, validate the contents of the entry field when it loses focus or when the window is closed, not after each keypress. Exception: if the field accepts only a fixed number of characters, such as a hexadecimal color code, validate and apply the change as soon as that number of characters have been entered.

Provide a static text prompt for text boxes that require input in a particular format or in a particular unit of measurement. For example:

Figure 6.4. Text entry field with static text prompt

Where possible, provide an additional or alternative control that limits the required input to the valid range. For example, provide a spinbox or slider if the required input is one of a fixed range of integers, or provide access to a GtkCalendar control if the user has to enter a valid date:

Figure 6.5. Text entry field requiring a date as input, with a button beside it to pop up a GtkCalendar control to simplify the task

This is less error-prone than expecting the user to format their text input in some arbitrary format. You may still want to provide the entry field control as well, however, for expert users who are familiar with the required format.

If you implement an entry field that accepts only keystrokes valid in the task context, such as digits, play the system warning beep when the user tries to type an invalid character. If the user types three invalid characters in a row, display an alert that explains the valid inputs for that textfield.

The cursor blink rate is globally defined by the XSettings "gtk-cursor-blink" and "gtk-cursor-blink-time". Standard toolkit controls use these and they must not be altered in applications by any means. New controls with text cursors must respect these global values.

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.

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 control instead.

Label the spin box with a text label above it or to its left, using sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the spin box.

Right-justify the contents of spin boxes, unless the convention in the user's locale demands otherwise. This is useful in windows where the user might want to compare two numerical values in the same column of controls. In this case, ensure the right edges of the relevant controls are also aligned.

Use a slider when:

Label the slider with a text label above it or to its left, using sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the slider.

Mark significant values along the length of the slider with text or tick marks. For example the left, right and center points on an audio balance control in Figure 6.7, “A simple slider control”.

For large ranges of integers (more than about 20), and for ranges of floating point numbers, consider providing a text box or spin box that is linked to the slider's value. This allows the user to quickly set or fine-tune the setting more easily than they could with the slider control alone.

Figure 6.8. Slider controls with linked spin boxes

Label all buttons with imperative verbs, using header capitalization. For example, Save, Sort or Update Now. Provide an access key in the label that allows the user to directly activate the button from the keyboard.

After pressing a button, the user should expect to see the result of their action within 1 second. For example, closing the window or opening another. See Chapter 7, Feedback for guidance on what to do if your application cannot respond this quickly.

Use an ellipsis (...) at the end of the label if the action requires further input from the user before it can be carried out. For example, Save As... or Find.... Do not add an ellipsis to commands like Properties, Preferences, or Settings, as these open windows that do not require further input.

Once a dialog is displayed, do not change its default button from one button to another. You may add or remove default status from the same button if it helps prevent user error, however. Changing the default from one button to another can be confusing and inefficent, especially for users relying on assistive technologies.

If your button can display text, an icon, or both, choose which label to display at runtime according to the user's preference in the GNOME Menus and Toolbars Preferences dialog. However, you may over-ride this preference when there is no suitable icon to describe the button's action graphically, for example.

Do not use more than one or two different widths of button in the same window, and make all of them the same height. This will help give a pleasing uniform visual appearance to your window that makes it easier to use.

Do not assign actions to double-clicking or right-clicking a button. Users are unlikely to discover these actions, and if they do, it will distort their expectations of other buttons on the desktop.

Make invalid buttons insensitive, rather than popping up an error message when the user clicks them.

Do not initiate an action when the user clicks a check box. However, if used in an instant-apply property or preference window, update the setting represented by the check box immediately.

Clicking a check box should not affect the values of any other controls. It may sensitize, insensitize, hide or show other controls, however.

If toggling a check box affects the sensitivity of other controls, place the check box immediately above or to the left of the controls that it affects. This helps to indicate that the controls are dependent on the state of the check box.

Use sentence capitalization for check box labels, for example Use custom font.

Label check boxes to clearly indicate the effects of both their checked and unchecked states, for example, Show icons in menus. Where this proves difficult, consider using two radio buttons instead so both states can be given labels. For example:

Figure 6.11. Ambiguous check box (top), radio buttons work better in this case (bottom)

The single check box in this example is ambiguous, as it is not clear where the "progress indicator" will go if the box is unchecked. Two radio buttons are better in this case, as they make the options clear.

Provide an access key in all check box labels that allows the user to set or unset the check box directly from the keyboard.

If the check box represents a setting in a multiple selection that is set for some objects in the selection and unset for others, show the check box in its mixed state. For example:

Figure 6.12. Check boxes (right) showing properties for a multiple selection of files in Nautilus (left)

In this example, both selected files are hidden (since their filenames start with "."), and the emblems on their icons show that neither file is writeable, but one is readable. The Readable check box is therefore shown in its mixed state. At time of writing, the exact visual appearance of a mixed state check box in gtk was undecided.

When a check box is in its mixed state:

Label a group of check boxes with a descriptive heading above or to the left of the group.

Use a frame around the group if necessary, but remember that blank space often works just as well and results in a less visually-cluttered dialog.

Do not place more than about eight check boxes under the same group heading. If you need more than eight, try to use blank space, heading labels or frames to divide them into smaller groups. Otherwise, consider using a check box list instead— but you probably also need to think about how to simplify your user interface.

Try to align groups of check boxes vertically rather than horizontally, as this makes them easier to scan visually. Use horizontal or rectangular alignments only if they greatly improve the layout of the window.

Only use radio buttons in groups of at least two, never use a single radio button on its own. To represent a single setting, use a check box or two radio buttons, one for each state.

Exactly one radio button should be set in the group at all times. The only exception is when the group is showing the properties of a multiple selection, when one or more of the buttons may be in their mixed state.

Do not initiate an action when the user clicks a radio button. However, if used in an instant-apply property or preference window, update the setting represented by the radio button immediately.

Clicking a radio button should not affect the values of any other controls. It may sensitize, insensitize, hide or show other controls, however.

If toggling a radio button affects the sensitivity of other controls, place the radio button immediately to the left of the controls that it affects. This helps to indicate that the controls are dependent on the state of the radio button.

Use sentence capitalization for radio button labels, for example Switched movement. Provide an access key in the label that allows the user to set the radio button directly from the keyboard.

If the radio button represents a setting in a multiple selection that is set for some objects in the selection and unset for others, show the radio button in its mixed state. For example:

Figure 6.14. Radio buttons (right) showing properties for a multiple selection of shapes in a drawing application (left)

At time of writing, the exact visual appearance of a mixed state radio button in gtk was undecided. In this situation, clicking any radio button in the group should set the clicked button, and unset all the others. Thereafter, the group should behave like a normal radio button group— there is no way to reset a radio button to its mixed state by clicking on it. Provide a Reset button or equivalent in the window that allows the previous mixed settings to be restored without closing the window or cancelling the dialog.

Label a group of radio buttons with a descriptive heading above or to the left of the group.

Use a frame around the group if necessary, but remember that blank space often works just as well and results in a less visually-cluttered dialog.

Do not place more than about eight radio buttons under the same group heading. If you need more than eight, consider using a single-selection list instead— but you probably also need to think about how to simplify your user interface.

Try to align groups of radio buttons vertically rather than horizontally, as this makes them easier to scan visually. Use horizontal or rectangular alignments only if they greatly improve the layout of the window.

Do not use groups of toggle buttons in dialogs unless space constraints force you to do so, or you need to provide consistency with a toolbar in your application. Check boxes or radio buttons are usually preferable, as they allow more descriptive labels and are less easily-confused with other types of control.

Only use toggle buttons in groups, so they are not mistaken for regular buttons. Make the group behave like either a group of check boxes or a group of radio buttons, as required.

Provide an access key in the label of all toggle buttons that allows the user to set or unset the button directly from the keyboard.

Label a group of toggle buttons with a descriptive heading above or to the left of the group, as you would with a group of check boxes or radio buttons.

Use a frame around the group of buttons if necessary, but remember that blank space often works just as well and results in a less visually-cluttered dialog.

Try to align groups of toggle buttons horizontally rather than vertically. This is how toggle buttons normally appear on a toolbar, so the user will be more familiar with this arrangement.

Do not leave any space between toggle buttons in a group, otherwise they may look unrelated or may be mistaken for regular buttons.

Use header capitalization for toggle button labels, for example No Wallpaper, Embossed Logo.

If your toggle button can display text, an icon, or both, choose which to display at runtime according to the user's setting in the GNOME Menus and Toolbars preference dialog.

Use the same text or graphical label for a toggle button whether it is set or unset.

If the toggle button represents a setting in a multiple selection that is set for some objects in the selection and unset for others, show the button in its mixed state. For example:

Figure 6.16. Toggle buttons (right) showing properties for a multiple selection of shapes in a drawing application (left)

At time of writing, the exact visual appearance of mixed state toggle buttons was undecided. A mixed state toggle button should behave exactly as a mixed state check box or radio button, depending on whether the toggle button choices are independent or mutually exclusive, respectively.

Do not use drop-down lists with fewer than three items, or more than about ten. To offer a choice of two options, use radio buttons or toggle buttons. To offer a choice of more than ten options, use a list.

Do not initiate an action when the user selects an item from an drop-down list. However, if used in an instant-apply property or preference window, update the setting that the menu represents immediately.

Selecting an item from a drop-down list should not affect the values of any other controls. It may sensitize, insensitize, hide or show other controls, however.

Label the drop-down list with a text label above it or to its left, using sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the drop-down list.

Use sentence capitalization for drop-down list items, for example Switched movement

Assign an access key to every drop-down list item. Ensure each access key is unique within the enclosing window or dialog, not just within the menu.

Do not assign shortcut keys to drop-down list items by default. The user may assign their own shortcut keys in the usual way if they wish, however.

Do not use a drop-down list in a situation where it may have to show a property of a multiple selection, as drop-down lists have no concept of mixed state. Use a group of radio or toggle buttons instead, as these can show set, unset or mixed states.

Do not use submenus on a drop-down list.

there is little available space

the list of options may change over time

the contents of the hidden part of the menu are obvious from its label and the one selected item. For example, if you have an option menu labelled "Month:" with the item "January" selected, the user might reasonably infer that the menu contains the 12 months of the year without having to look.

Only use a drop-down combination box instead of a list, drop-down list or radio button group when it is important that the user be able to enter a new value that is not already amongst the list of pre-defined choices.

Do not initiate an action when the user selects an item from the list in a drop-down combination box. If used in an instant-apply property or preference window, update the setting represented by the drop-down combination box immediately if possible. If this isn't possible due to the contents of the entry field being invalid while the user is still typing into it, update the related setting when the drop-down combination box loses focus instead.

If the user types a value into the drop-down combination box that is not already in the drop-down list, add it to the list when the drop-down combination box loses focus so they can select it next time.

Interpret user input into a drop-down combination box in a case-insensitive way. For example, if the user types blue, Blue and BLUE into the same drop-down combination box on different occasions, only store one of these in the combo's dropdown list, unless your application makes a distinction between the different forms (which is usually a bad idea).

Label the drop-down combination box with a text label above it or to its left, using sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the drop-down combination box.

Use sentence capitalization for the dropdown list items, for example Switched movement.

Only display scrollbars when they are required for sliding the view. If an object fits inside the viewer control, don't draw scrollbars. If you are using a GtkScrolledWindow, call gtk_scrolled_window_set_policy setting the appropriate axis (or axes) to GTK_POLICY_AUTOMATIC.

Do not use scrollbars as a replacement for a slider. Scrollbars should only be used affixed to a view that they actively alter, not used as a generic continuous input control.

Affix scrollbars to the right side of a viewer control (to slide the view vertically), or to the bottom side (to slide the view horizontally). Do not affix scrollbars on the top or left sides of a viewer control.

Scrollbars should be aligned in both directions with the view they are affixed to on the axis they control. In other words, horizontal scrollbars should span the full length of the viewer control, and vertical scrollbars should span the full height of the viewer control.

If both horizontal and vertical scrollbars are acting upon a view, alignment will require that small rectangle in the lower right corner where the horizontal and vertical scrollbars meet will be blank. This is OK.

Scrollbars should affect the view to which they are affixed in realtime: as the user drags or clicks the view should change. Time lag will be disconcerting and negatively impact a users ability to navigate content inside the view.

Always give list controls a label, positioned above or to the left of the list, in sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the list.

Make the list control large enough that it can show at least four items at a time without scrolling. For lists of ten or more items, increase this minimum size as appropriate.

If the list appears in a dialog or utility window, consider making the window and the list within it resizable so that the user can choose how many list items are visible at a time without scrolling. Each time the user opens this dialog, set its dimensions to those that the user last resized it to.

Do not use lists with less than about five items, unless the number of items may increase over time. Use check boxes, radio buttons or an drop-down list if there are fewer items.

Only use column headers when:

In most other situations, column headers take up unnecessary space, and the extra label adds visual clutter.

Always label column headers when used. If the column is too narrow for a sensible label, provide a tooltip for the column instead. Apart from its obvious use, this will help ensure that assistive technologies can describe the use of the column to visually impaired users.

Consider using a check box list for multiple-selection lists, as these make it more obvious that multiple selection is possible:

Figure 6.20. A simple check box list

If you do this, you should normally set the list control itself to be single-selection, but this depends on the particular task for which it will be used.

For multiple selection lists, show the number of items currently selected in a static text label below the list, for example, Names selected: 3. Such a label also makes it more obvious that multiple selection is possible.

Consider providing Select All and Deselect All buttons beside multiple selection lists, if appropriate.

Always give tree controls a label, positioned above or to the left of the tree, in sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the tree.

Use column headers when:

In most other situations, column headers take up unnecessary space, and the extra label adds visual clutter.

Always label column headers when used. If the column is too narrow for a sensible label, provide a tooltip for the column instead. Apart from its obvious use, this will help ensure that assistive technologies can describe the use of the column to visually impaired users.

Consider using a check box tree for multiple-selection trees, as these make it more obvious that multiple selection is possible:

Figure 6.22. A simple check box tree

If you do this, you should normally set the tree control itself to be single-selection, but this depends on the particular task for which it will be used.

For multiple selection trees, show the number of items currently selected in a static text label below the tree, for example, Names selected: 3. Such a label also makes it more obvious that multiple selection is possible.

Consider providing Select All and Deselect All buttons beside multiple selection trees, if appropriate to the task.

Do not put too many pages in the same notebook. If you cannot see all the tabs without scrolling or splitting them into multiple rows, you are probably using too many and should use a list control instead. See the example below.

Label tabs with header capitalization, and use nouns rather than verbs, for example Font or Alignment. Try to keep all labels in a notebook the same general length.

Do not assign access keys to tab labels, as this means you cannot use those access keys for any other control on any of the notebook pages without conflict. Even if you are able to assign access keys that would not conflict, it is better not to as it may be impossible to avoid the conflict when your application is translated to other languages. Assign an access key to every other control on each page, however.

Do not design a notebook such that changing controls on one page affects the controls on any other page. Users are unlikely to discover such dependencies.

If a control affects only one notebook page, place it on that notebook page. If it affects every page in the notebook, place it outside the notebook control, for example beside the window's OK and Cancel buttons.

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 fit into the notebook without scrolling. For example:

Figure 6.24. Fixed- and proportional-width tabs (preferred)

Although the contents of each page in a notebook will take up a different amount of space, do not use larger than normal spacing around the controls in the "emptier" pages, and do not center the controls on the page.

If your tab labels include icons, choose whether or not to show the icons at runtime based on the user's preference in the GNOME Menus and Toolbars desktop preferences dialog. Always show the text part of the label, however.

Always use a measured progress bar when the length of a task can be precisely or approximately predicted. Otherwise, use an indeterminate progress indicator or a checklist window.

Ensure that a measured-progress bar measures an operation's total time or total work, not just that of a single step. An exception is a progress bar that measures the total time or work of the current step in a progress checklist.

Use statusbars only in application or document windows. Do not use them in dialogs, alerts or other secondary windows.

Only place a statusbar along the bottom of a window.

Only use statusbars to display non-critical information. This might include:

Remember that statusbars are normally in the user's peripheral vision, and can even be turned off altogether using the application's View → Status Bar menu item. The user may therefore never see anything you display there, unless they know when and where to look for it.

When there is no interesting status to report, leave a status bar panel blank rather than displaying something uninformative like "Ready". This way, when something interesting does appear in the statusbar, the user is more likely to notice it.

If you want to make all or part of your statusbar interactive, use the following conventions:

In Figure 6.30, “An interactive statusbar”, the appearance indicates that the left area would respond to a double click (perhaps by saving the document), and the progress indicator on the right is non-interactive.

Figure 6.30. An interactive statusbar

Ensure that double-clicking in the status area does not provide any functionality that is not also available in the main application menu bar, or by some other accessible means.

Provide a drag handle in the bottom right corner of the status bar of resizeable windows. Subclasses of GtkStatusbar should use the drag handle provided by that class. A reimplementation of a status bar, which is discouraged, should also reimplement the GtkStatusbar drag handle in both appearance and function.

Before you add a frame with a visible border or separator to any window, consider carefully if you really need it. It is usually better to do without, if the groups can be separated by space alone. Do not use frames and separators to compensate for poor control layout or alignnment.

Do not mix framed and unframed groups in the same window.

Do not nest one frame inside another. This results in visual clutter.

If all the items in a group are disabled, disable the group title too.

They give immediate feedback to users, even when they cannot fulfill their requests immediately.

They handle queued requests as users would expect, discarding requests that are no longer relevant and reordering requests according to users' probable priorities.

They let users do other work while long operations proceed to completion— especially operations not requested by users— such as reclaiming unused memory or other "housekeeping" operations.

They provide enough feedback for users to understand what they are doing, and organize feedback according to users' abilities to comprehend and react to it.

They let users know when processing is in progress.

They let users know or estimate how long lengthy operations will take.

They let users set the pace of work, when possible, and they let users stop requested tasks that have started but not finished.

They provide late feedback— or no feedback— for users' requests, leaving users wondering what the application has done or is doing.

When performing extended operations, they prevent users from doing other work or cancelling the extended operation.

They fail to display estimates of how long extended operations will last, forcing users to wait for unpredictable periods.

They ignore users' requests while doing unrequested "housekeeping", forcing users to wait at unpredictable times— often without feedback.

Verify that your application provides feedback within 100 milliseconds (0.1 second) after each key press, movement of the mouse, or other physical input from the user.

Verify that your application provides feedback within 100 milliseconds (0.1 second) after each change in the state of controls that react to input from the user— for example, displaying menus or indicating drop targets.

Verify that your application takes no longer than 1 second to display each progress indicator, complete each ordinary user command, or complete each background task.

Verify that your application takes no longer than 10 seconds to accept and process all user input to any task—including user input to each step of a multistep task, such as a wizard.

Display feedback as soon as possible.

If you cannot display all the information that a user has requested, display the most important information first.

Save time by displaying approximate results while calculating finished results.

If users are likely to repeat a time-consuming command in rapid succession, save time by faking the command's effects instead of repeatedly processing the command. For example, if a user adds several rows to a table stored in a database, you might display each new row immediately but delay actually creating each new row in the database until the user finished adding all the rows.

Work ahead. Prepare to perform the command that is most likely to follow the current command. That is, use idle time to anticipate users' probable next requests. For example, as the user of an email application reads the currently displayed new message, the application might prepare to display the next new message.

Use background processing. Perform less important tasks —such as housekeeping— in the background, enabling users to continue working.

Delay work that is not urgent. Perform it later, when more time is available.

Discard unnecessary operations. For example, to move back several pages in a web browser, a user might click the browser's Back button several times in rapid succession. To display the final requested page more quickly, the browser might not display the pages visited between the current page and that final page.

Use dynamic time management. At run time, change how your application prioritizes user input and other processing, based on the application's current state. For example, if a user is typing text in one word-processing document while printing another, the word-processing application might delay the printing task if the user shifts to an editing task (such as cutting and pasting text) that requires greater resources.

In your application, display an estimate of how long each lengthy operation will take.

Whether your application can provide an estimate of the operation's progress.

Whether the operation blocks the user from issuing further commands in your application.

Whether your application has a dedicated space, such as a status bar, for indicating the status of operations.

Use a busy pointer whenever users are blocked from interaction with your application for 1 second or longer. Display the busy pointer less than 1 second after the operation begins.

If a command will likely take 10 seconds or longer to finish, provide a Stop or Cancel button, which can also be activated by pressing Esc, that lets users terminate the command's processing even if your application cannot undo the command's effects. See Section 7.6, “Allowing Interruptions”.

When using an external animation, leave the window containing the animation on-screen for at least 1 second after the operation has completed, with a successful completion message. Change the Stop or Cancel button to an OK button during this period— pressing this button should close the window immediately.

Place a Stop or Cancel button, which can also be activated by pressing Esc, near the progress animation for the interruptable command.

Label the button Cancel if the whole operation can be cleanly abandoned with no side effects, leaving the system in the state it was in prior to the operation beginning. Terminate the command immediately when the user presses this button.

Label the button Stop if the command can be interrupted, but its effects up to that point cannot (or should not) be reversed. When the user presses this button, open an alert box that warns of the potential side effects of stopping the command. The alert box should have only two buttons: one for continuing the command's processing, and one for immediately terminating it.

There is no progress animation for the command, or

The progress animation is in a window's status area or in another location that lacks space for a Stop or Cancel button.

strengthen a desktop's look and feel by enhancing a theme

accent a dynamic alert in a system management application

emphasize an element in a long list to expedite scanning

add aesthetically pleasing details to an icon

Design Functionally Suggestive Icons.  Icons should be suggestive of the functionality with which they are associated. The best icon will suggest to the user the primary purpose of the program or operation without having to read accompanying text. Users recognize functionally suggestive icons more rapidly than other forms because they directly associate with a physical object or action.

Figure 9.3. A functionally suggestive icon for a word processor

Figure 9.4. A functionally suggestive icon for underline

Make Icon Silhouettes Distinct.  It is important to make it easy to visually distinguish icons that will be used together, for example toolbar icons and document icons. The human visual system is excellent at making rapid distinctions between items based on shape, thus a good way to help your users sort through a large number of icons is to use different shapes. You can see the shape of an icon most clearly by turning it into a silhouette: blacken all areas of the icon which are not transparent.

Example 9.1. Distinct silhouettes from the GNOME icon theme

a high contrast theme

an inverse high contrast theme

a large print theme

a high contrast large print theme

an inverse high contrast large print theme

a low contrast theme

a low contrast,large print theme