GNOME Human Interface Guidelines 2.2.2

Accessibility (sometimes called a11y) means enabling people with disabilities of some kind to participate in life's activities: in this case, specifically to use your software. For example:

Your software should also be usable with voice interfaces, screen readers such as Gnopernicus, alternate input devices, and other assistive technologies. The standard GNOME libraries do most of this work for you, but with a little extra effort you can make your application every bit as useful to users who rely on those technologies as to those who don't.

GNOME has excellent inbuilt support for accessibility by means of the ATK and GAIL libraries, which in many cases can do most of the work for you. More information on accessibility in GNOME can be found at the GNOME Accessibility Project.

Internationalization means designing software so that it can function in different language environments. Localization is the process of actually translating the messages, labels, and other interface elements of an application into another language.

GNOME has excellent support for both internationalization (also referred to as i18n) and localization (also referred to as l10n). In most cases, simply using standard GNOME APIs for displaying text and messages will allow you or others to localize your application for other locales. For more information on how to make your application localizable, see the Pango project home page (Pango is the GNOME library for rendering internationalized text), the GNOME Translations page, and the GNOME Translation Project page.

Sensitivity to cultural and political issues is also an important consideration. Designing icons and sounds, and even choosing colors requires some understanding of the connotations they might have to a user from a different part of the world.

Examples of elements it is best to avoid for these reasons include:

Tooltips help provide users with enough information to run the right application. Many users use tooltips to explore a new environment.

Provide a tooltip for each Application menu item you add, following these guidelines:

You should probably write an applet instead of using the notification area if:

Icons should respond to the these user actions. (Keypresses apply only when the icon has focus, of course)

Give every window a title (with the exception of alerts and toolboxes). A good window title contains information that is relevant to the user, and distinguishes a particular window from other open windows. Omit information that does not assist in this selection, for example the application's version number or vendor name.

Figure 3-1 Example of a window title

See the description of each particular window type for title formats.

Most windows have borders, except certain shaped windows and some torn-off windows. Do not attempt to draw your own window borders, but instead provide hints to the window manager for the desired border type.

Different window commands are appropriate to different types of window. See the description of each particular window type for a list of appropriate window commands. These are the possible window commands:

A non-modal window does not restrict the user's interaction with other open windows on the desktop in any way. Using non-modal windows gives the user maximum flexibility to perform tasks within your application in any order and by whichever means they choose.

An application modal window, while it is open, prevents the user from interacting with other windows in the same application.

A system modal window, while it is open, prevents the user from interacting with any other window in any application, including the desktop itself.

Focus is the means by which the user designates which window should receive data from the keyboard, mouse or other input device. If using a screen reader or similar assistive technology, focus may also designate the window that the user wants to receive information about. The focused window is considered the window the user is currently "working with".

Ensure your application functions properly with the three different mechanisms by which windows can receive focus in GNOME:

How your application shows and hides windows can greatly affect the user's perception of your application, particularly its performance.

The most important element of a document-based application's window title is the name of the open document. For other applications, it usually the name of the application.

While document names are most pertinent to users, we understand that application developers may want to increase recognition of their application. If you plan to include your application's name in the title of a primary window, use the following format: Document Name - Application Name. This will ensure that the document name appears in limited space situations such as the system window list.

Close, Maximize/Restore, Minimize, Roll-up/Unroll

For windows that allow the user to change values or settings, such as property and preference windows, update those values or settings immediately to reflect the changes made in the window. This is known as "instant apply". Do not make the user press an OK or Apply button to make the changes happen, unless either:

If either these conditions affect only a few of the controls in your window, arrange those controls together into one or more groups, each with its own Apply button. Leave the rest of the controls as instant apply.

If most of the controls in your window are not suitable for instant apply, consider making the whole window "explicit apply". An explicit apply window has these three buttons in its button box, plus an optional Help button:

Figure 3-5 Buttons in an explicit apply window

When designing a dialog or utility window, you can assign the Return key to activate a particular button in the window. GNOME indicates this button to the user by drawing a different border around it. For example, the OK button in Figure 3-5.

Choose the default button to be the most likely action, such as a confirmation action or an action that applies changes in a utility window. Do not make a button the default if its action is irreversible, destructive or otherwise inconvenient to the user. If there is no appropriate button in your window, to designate as the default button, do not set one.

In particular, it is currently not recommended to make the Close button the default in an instant apply window, as this can lead to users closing the window accidentally before they have finished using it.

Property windows allow the user to view and change the characteristics of an object such as a document, file, drawing, or application launcher.

Figure 3-6 Example of a property window

Preferences windows allow the user to change the way an application looks or behaves.

Figure 3-7 Example of a preferences window

	(o) Use font from theme
	(o) Use this font: [ Font selector ]

	(o) Use colors from theme
	(o) Use these colors:
		Background: [ color selector ]
		Foreground: [ color selector ]
		

A toolbox provides convenient access to a set of actions and toggles through a set of small toolbar-like buttons. Toolboxes can be used to provide a specialized group of tools to augment a toolbar containing more universal items such as Save and open. A single toolbox can be shared between multiple documents to save screen space.

Figure 3-8 An example of a toolbox

3.3.6.1. Toolbox Categories

While categories may not be as visually appealing as a toolbox homogenously filled with beautiful icons, they make an unwieldy large toolbox more managable. Picking a small icon from more than fifteen other items is a difficult task. Additionally, categories allow users to hide sets of tool items that are not relevant to their current task.

Figure 3-9 A large toolbox broken into categories

Guidelines

• Break toolboxes with more than sixteen items into categories. The best size for a category is between four and ten items.
• Give each category a label (in title caps) and a collapsing arrow. Clicking the label or the arrow toggles the category between a collapsed and uncollapsed state.

An alert may contain both primary and secondary text. The primary text briefly summarizes the situation. The secondary text provides additional information.

Make both the primary and secondary text selectable. This makes it easy for the user to copy and paste the text to another window, such as an email message.

Figure 3-11 Primary and Secondary Text Placement

Denote primary text with the pango markup:

<span weight="bold"
      size="larger">Primary Text</span>

Give all alerts an affirmative button that dismisses the alert and performs the action suggested in the primary text. Provide a Cancel button for all alerts displayed in response to a user actions, such as Quit. If the alert warns of a technical problem or other situation that could result in data loss, provide a Help button that provides more information on the particular situation and explains the user's options. You may also provide buttons to perform alternate actions that provide another possible solution, fix potential problems, or launch related dialogs or programs.

Figure 3-12 Button ordering and placement for alerts

Using clear, consistent spacing in alerts makes the message easier to digest and the available responses more obvious.

Figure 3-13 Spacing inside an alert

Use an information alert when the user must know the information presented before continuing, or has specifically requested the information. Present less important information by other means such as a statusbar message.

Figure 3-14 An information alert

Display an error alert when a user-requested operation cannot be sucessfully completed. Present errors caused by operations not requested by the user by another means, unless the error could result in data loss or other serious problems. For example, an error encountered during an email check initiated by the user clicking a toolbar button should present an error alert. However, an error encountered in an automated periodic email check would more appropriately report failure with a statusbar message.

Figure 3-15 An error alert

Present a confirmation alert when the user's command may destroy their data, create a security risk, or take more than 30 seconds of user effort to recover from if it was selected in error.

Figure 3-16 A confirmation alert

3.4.6.1. Save Confirmation Alerts

Save confirmation alerts help ensure that users do not lose document changes when they close applications. This makes closing applications a less dangerous operation.

Figure 3-17 A save confirmation alert

Primary Text

Save changes to document Document Name before closing?

You may replace “document” with a more appropriate description, for example “image” or “diagram” if the document in question is not primarily text.

Secondary Text

If you close without saving, changes from the last Time Period will be discarded

The secondary text provides the user with some context about the number of changes that might be unsaved.

Buttons

Close without Saving, Cancel, Save

When a confirmation alert is needed, present it immediately. If the user confirms closing without saving, hide the alert and the document or application window immediately, before doing any necessary internal clean-up. If the user chooses to save before closing, hide the alert immediately but show the document window until the document is saved, in case an error occurs. Then hide the document window immediately after it has been saved successfuly.

Authentication alerts prompt the user for information necessary to gain access to protected resources, such as their username or password. Authentication alerts are a special kind of alert because they are both routine and largely unavoidable. Every attempt should be made to retain information entered into an authentication alert as long as is possible within security constraints.

Figure 3-18 An authentication alert

Occasionally a procedure is comprised of a series of user performable actions. In these cases, particularly when it is desirable that the user acquire some familiarity with the actions involved in a procedure, checklist windows may be used.

Figure 3-21 An example checklist window (Ready to Start)

Figure 3-22 An example checklist window (In Progress)

Figure 3-23 An example checklist window (Completed)

You can include other buttons in a dialog's main button area in addition to the affirmative button and Cancel, but any more than one or two such buttons will make the dialog appear complicated and difficult to use. As with any other button, keep the labels as concise as possible to minimize this effect.

A clean, logical dialog layout helps the user to quickly understand what information is required from them.

See Chapter 8 ― Visual Design for more detailed information on arranging controls in dialogs.

See Section 6.16 ― Tabbed Notebooks for information on using tabbed notebook controls in dialogs.

The gtk and GNOME libraries provide standard dialogs for many common tasks, including opening and saving files, choosing fonts and colors, and printing. Always use these when the user is performing one of these tasks. You may modify the dialogs to reflect the needs of your particular application (for example, adding preview Play and Stop buttons to the Open File dialog in an audio application), but do not change or remove features so much as to make them unrecognizable.

The first page provides the user with the "big picture". Place the title of the assistant in the window's title bar and the assistant's title area, along with an optional picture. Beneath this, state the goal of the assistant, and, if it is not obvious, where the user can find the information the assistant will be asking for.

Figure 3-25 Example of the first page of an assistant

Content pages contain the actual settings of the assistant. Summarize the type of setting present on each content page in its title area. For example, Mail Server.

The last page should summarize the settings that will be changed by the assistant, and how the user can modify them later.

Figure 4-2 A typical drop-down menu

A drop-down menu appears when the user clicks on its title in a menubar, or focuses the title and presses Return.

Figure 4-3 A drop-down menu with a submenu

A submenu appears when the user clicks its title, which is indicated by a small arrow symbol beside its label. You can save space on long menus by grouping related commands onto a single submenu.

Figure 4-4 A popup menu for a mail folder

Popup menus provide shortcuts to those menu items that are applicable only to the currently selected object. As such, they are sometimes known as "context menus" or "shortcut menus". A popup menu is shown when the user right-clicks on an object, or selects the object and presses Shift+F10.

Be aware that popup menus are used primarily by intermediate and advanced users. Even some users who have used graphical desktops for many years do not know about popup menus until somebody shows them.

Figure 4-5 Items grouped on a menu with separators

Menu separators are the horizontal dividing lines that visually separate groups of related items on a drop-down menu, submenu, or popup menu. For example, the separators in Figure 4-5 divide the menu into five functionally-related groups. Good use of separators helps to "chunk" the information on a menu and make it easier to scan and memorize.

The File menu contains commands that operate on the current document. It is the left-most item in the menubar because of its importance and frequency of use, and because it is a relevant menu in many applications. Historically, because most applications already had this menu, and because the distinction between closing documents and closing windows became blurred over time, the File menu has also become the standard location for Quit.

The items on the File menu are generally ordered by locality, closest first. That is, items to save or load from file, followed by printing, followed by sending to a remote user. Try to maintain this ordering if you have to add new items to the menu.

If your application does not operate on documents, name this item for the type of object it displays. For example, many games should have a Game instead of a File menu. However, place the Quit menu item last on this menu nonetheless.

Figure 4-10 A generic File menu

The Edit menu contains items relating to editing both the document (clipboard handling, search and replace, and inserting special objects) and the user's preferences. Preferences are edited here rather than on a Settings menu, because:

Figure 4-11 A generic Edit menu

The View menu contains only items that affect the user's view of the current document. Do not place any items on the View menu that affect the the content of the current document. (Exception: View ▸ Reload may change the current contents if, for example, the document is a webpage that has been recently updated on the server).

Figure 4-12 A generic View menu

The Insert menu lists the type of special objects that can be inserted into the document at the current caret position, for example images, links, page breaks or GUI objects. Only provide this menu if you have more than about six types of object that can be inserted, otherwise place individual items for each type on the Edit menu.

Figure 4-13 A generic Insert menu

The types of object will vary between applications, but the table below shows some common types that may be applicable.

A Format menu contains commands to change the visual appearance of the document. For example, changing the font, color, or line spacing of a text selection.

The difference between these commands and those on the View menu is that changes made with Format commands are persistent and saved as part of the document, for example as HTML or RTF tags.

Figure 4-14 A generic Format menu

Items found on the Format will be very application-specific, but some common items are listed in the table below.

Provide a Bookmarks menu in any application that allows the user to browse files and folders, help documents, web pages or any other large information space.

Figure 4-15 A generic Bookmarks menu

A Go menu provides commands for quickly navigating around a document or collection of documents, or an information space such as a directory structure or the web.

The contents of the menu will vary depending on the type of application. Different standard menus are presented here for browser-based and document-based applications , but your application may require a combination of both.

Figure 4-16 A generic Go menu for a browser application

Figure 4-17 A generic Go menu for document-based applications

The Windows menu contains commands that apply to all of the application's open windows. Only use a Windows menu in multiple document interface (MDI) applications.

You may also label this menu Documents, Buffers, or similar according to the type of document handled by your application.

The last items on this menu are a numbered list of the application's primary windows, for example 1shoppinglist.abw. Selecting one of these items raises the corresponding window.

Figure 4-18 A generic Windows menu

The Help menu provides access to all online documentation for your application. This includes both the user guide, and the About window which includes a brief description of your application's functionality.

Figure 4-19 A generic Help menu

In general, don't use vertical toolbars. The eye does not scan vertically as well as it does horizontally, groups of mutually exclusive buttons are less obvious when arranged vertically, and showing button labels is more awkard and less space-efficient. Also, some toolbar controls just cannot be used vertically, such as dropdown lists.

Only consider using a vertical toolbar if:

If you must use a vertical toolbar, ensure the user can configure it to appear horizontally if they prefer.

Many applications are able to play sound or video clips. For consistency, always present the buttons that control playback in the same order and with the same stock icons.

In a network-managed environment, like a computer lab, system administrators usually want to "lock down" the values of certain settings, or remove them from the user interface altogether. This makes it easier for them to troubleshoot any problems that their users may encounter. In GNOME, the correct way for the system administrator to do this is by restricting write access to the GConf keys corresponding to those settings.

When you are designing your application, consider which settings a system administrator might want to make unavailable to users. These may typically include:

Your application needs to decide every time these controls are displayed whether or not they are available for editing, depending on the writeable state of the GConf key that holds its value. In the simplest case, your code for each control could look like that in the example below.

if (!gconf_key_is_writable (http_proxy))
        gtk_widget_set_sensitive (http_proxy_field, FALSE);

Include a section for system administrators in your user guide, explaining which settings they can lock, and their corresponding GConf keys.

Explain to the user why these controls cannot be edited at this time. You can do this with static text, tooltips or online help, depending on the situation. For example:

Figure 6-2 Example of a dialog with locked controls

Note that although they cannot be edited, the settings are still visible and selectable, and may be copied to the clipboard.

Normally, pressing Return in a dialog should activate the dialog's default button, unless the focused control uses Return for its own purposes. You should therefore set the activates-default property of most entry fields to TRUE. (Note that GtkTextView does not have such a setting— pressing Return always inserts a new line.).

However, if your dialog contains several entry fields that are usually filled out in order, for example Name, Address and Telephone Number, consider setting the activates-default property on those entry fields to FALSE. Pressing Return should then move focus on to the next control instead. Doing this will help prevent the user from accidentally closing the window before they have entered all the information they wanted to.

As a further safeguard, remember not to set the default button in a dialog until the minimum amount of required information has been entered, for example, both a username and a password in a login dialog. Again, in this case you should move focus to the next control when the user presses Return, rather than just ignoring the keypress.

If you need to provide a keyboard shortcut that activates the default button while a GtkTextView control has focus, use Ctrl+Return.

Normally, pressing Tab in a single-line entry field should move focus to the next control, and in a multi-line entry field it should insert a tab character. Pressing Ctrl+Tab in a multi-line entry field should move focus to the next control.

If you need to provide a keyboard shortcut that inserts a tab character into a single line entry field, use Ctrl+Tab. You are unlikely to find many situations where this is useful, however.

Users often prefer to sort long lists, either alphabetically or numerically, to make it easier to find items. Allow users to sort long or multi-column lists by clicking on the column header they want to sort.

As with lists, the user may find it useful to sort long or multi-column trees. See the guidelines in Section 6.14.1 ― Sortable Lists for more information.

In some tabbed windows, such as preference windows, it might be desirable to indicate the status of a particular tab. This can be used to notify the user that a web page that is still loading or has been loaded, a new message is waiting in a particular instant messasing conversation, or that a document has not been saved. Such a status indicator should be an icon that is placed directly to the left of the tab label. Additionally, the tab label's color might be changed to indicate a certain status. Do not simply rely on a different coloring scheme for status indication.

An animation consisting of a bar whose changing length indicates how much time remains in an operation, and text stating how much time remains before the operation will be complete. Time-remaining bars are the most useful type of progress bar.

Figure 6-26 A simple 'time remaining' progress bar

Use a time-remaining bar if your application will display an initial estimate of an operation's remaining time and then periodically display updated estimates. Each updated estimate should be based on changes that have occurred and that will cause the operation to finish more quickly or more slowly. If the operation will finish more slowly, your application can display an updated estimate that is greater than the estimate previously displayed.

A bar whose changing length indicates how much time remains if an operation takes as long as it typically does. Typical-time bars are the least precise type of measured-progress bar, but they are more useful than indeterminate-progress bars.

Figure 6-27 A simple 'typical time remaining' progress bar

For some operations, you cannot estimate the time remaining or the proportion of work completed. However, if you can estimate the typical time for that operation, you can provide feedback with a typical-time bar.

If your application overestimates the completed amount of work, the length of the bar can indicate "almost complete" until the operation is complete. If your application underestimates how much work is complete, the application can fill the remaining portion of the bar when the operation is complete.

An animated bar indicating only that an operation is ongoing, not how long it will take. One example is the "throbber" in a web browser. Indeterminate-progress bars are the least precise type of progress bar.

Figure 6-28 A simple 'indeterminate time' progress bar; the slider moves from left-to-right and back again until the operation is complete

Use an indeterminate-progress bar to provide feedback only for operations whose duration you cannot estimate at all.

Pointer feedback changes the shape of the pointer. For example, a busy pointer indicates that an operation is in progress and that the user cannot do other tasks. A busy-interactive pointer indicates that an operation is in progress but the window is still interactive.

Figure 7-1 Busy pointer (left) and Busy-Interactive pointer (right)

Progress animations show either how much of an operation is complete, or only that an operation is ongoing. Normally, these take the form of either a progress bar or a progress checklist.

7.4.2.2. Checklist Windows

A checklist window shows the sequence of stages in an operation. See Section 3.5.1 ― Checklist Windows.

Figure 7-2 A Checklist Window

A 32-color palette has been developed for the GNOME desktop. The palette may be downloaded from http://developer.gnome.org/projects/gup/images/ximian-palette. To use it in The GIMP, save it to your ~/.gimp_1.2/palettes folder, and restart The GIMP. A single, consistently-used palette helps give a unified look and feel to the desktop while minimizing visual distractions. If you need a color that is darker or lighter than the colors in this basic palette (e.g., for anti-aliasing), choose a color that is closest to the hue you need, then darken or lighten as required.

Figure 8-1 The basic GNOME 32-color palette

Table 8-1 RGB and hexadecimal values for the basic palette

Color	Description	RGB	Hex	Color	Description	RGB	Hex
	Basic 3D Hilight	234 232 227	#EAE8E3		Basic 3D Medium	186 181 171	#BAB5AB
	Basic 3D Dark	128 125 116	#807D74		3D Shadow	86 82 72	#565248
	Green Hilight	197 210 200	#C5D2C8		Green Medium	131 166 127	#83A67F
	Green Dark	93 117 85	#5D7555		Green Shadow	68 86 50	#445632
	Red Hilight	224 182 175	#E0B6AF		Red Medium	193 102 90	#C1665A
	Red Dark	136 70 49	#884631		Red Shadow	102 56 34	#663822
	Purple Hilight	173 167 200	#ADA7C8		Purple Medium	136 127 163	#887FA3
	Purple Dark	98 91 129	#625B81		Purple Shadow	73 64 102	#494066
	Blue Hilight	157 184 210	#9DB8D2		Blue Medium	117 144 174	#7590AE
	Blue Dark	75 105 131	#4B6983		Blue Shadow	49 78 108	#314E6C
	Face Skin Hilight	239 224 205	#EFE0CD		Face Skin Medium	224 195 158	#E0C39E
	Face Skin Dark	179 145 105	#B39169		Face Skin Shadow	130 102 71	#826647
	Accent Red	223 66 30	#DF421E		Accent Red Dark	153 0 0	#990000
	Accent Yellow	238 214 128	#EED680		Accent Yellow Dark	209 148 12	#D1940C
	Accent Green	70 160 70	#46A046		Accent Green Dark	38 199 38	#267726
	White	255 255 255	#ffffff		Black	0 0 0	#000000

Users with vision disorders, such as color-blindness or low vision, require alternatives to default settings. A good user interface anticipates these needs by providing customizable preferences and support for accessible themes. Even better is an application that is already configured with carefully-chosen color and contrast defaults.

An estimated 11% of the world population has some sort of color-blindness. Those affected typically have trouble distinguishing between certain hues such as red and green (deuteranopia or protanopia), or blue and yellow (tritanopia). Therefore it is necessary to allow the user to customize colors in any part of your application that conveys important information. This means that your application must effectively convey information using just the colors from any theme that the user chooses.

A useful tool for reviewing information about color-blindness and checking legibility of images for color-blind users is Vischeck, an online tool that simulates the way an image or a website might appear to a user who has deuteranopia, protanopia, or tritanopia.

Figure 8-2 How the earth looks to a user with normal color vision (left), deuteranopia (middle), and tritanopia (right). (Images from http://www.vischeck.com).

Other users have more problems with contrast levels rather than hue on their screen. Some users require a high level of contrast between background and foreground colors, such as black on white, white on black, or some other high-contrast combination. Others can experience discomfort unless they use low-contrast settings, such as gray text on a lighter gray background.

You can meet these needs by ensuring your application supports the accessible GNOME themes (found in the gnome-themes module in cvs), which include high and low contrast themes, and large print themes. This means you must supply default and large sizes of high-, low- and regular-contrast icon sets with your application.

Placement of visual components in an application is important because relationships between elements are indicated by their positions. This is called "layout" in interface design.

A clean layout is crucial to creating a smooth visual flow of information for the user. This section describes the proper component placement and spacing to use in GNOME applications. The major components discussed will be labels, icons, radio buttons and check boxes, text fields, command buttons, and drop-down menus.

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. For information on laying out Alerts, see Section 3.4.3 ― Spacing and Positioning Inside Alerts

Figure 8-3 Improved window layout

In Figure 8-3, the dialog on the left presents labels which are not left-aligned. The user's eye is not given a proper anchor to scan the dialog quickly.

As the labels are all similar in length, they should be left-aligned. Now the user has a firm left margin to anchor the eye and scan the list of items vertically more easily. If most of the labels in a group greatly differ in length, right-align them instead, so that the controls do not end up too far away from their corresponding labels.

Using frames with visible borders to separate groups within a window is deprecated. Use spacing and bold headers instead. This is more effective because there are fewer gratuitous lines to distract the user from the main content in the window. See Section 6.19 ― Frames and Separators for more details.

Try to keep components consonant with each other in terms of size and alignment. This is particularly important within a group of controls, so that the user's ability to quickly scan information is not sacrificed. Minimize as much as possible the need for the user's eye to jump around when scanning a layout.

Figure 8-4 Layout specifications

Provide adequate space between controls and groups of controls. This white space will make it easier for the user to find the information they need.

Use spacing and alignment of text uniformly throughout your application. A basic rule of thumb is to put space between user interface components in increments of 6 pixels, going up as the relationship between related elements becomes more distant.

Table 8-2 Alignment and spacing for different Text elements

Element	Placement	Example
Large Icons (file browser)	Horizontally centered with and (6 pixels, if specification necessary)below large icon
Small icons (toolbar)	Vertically centered with and (6 pixels, if specification necessary) to the right of small icons
List control label	6 pixels above and horizontally left aligned with list control or 12 pixels to the left of and horizontally top aligned with list control
Radio button and check box labels	6 pixels to the right of and vertically center aligned with radio button
Text field labels	6 pixels to the left of and vertically center aligned with textfield control
Button labels	12 pixels of padding to either side of centered text (and any accompanying graphic). If appearing in a group of buttons, longest button label sets button size, center all other button labels and accompanying graphics in same-sized buttons
Other component labels (e.g., spin boxes, text fields	12 pixels between the longest text label and its associated component, all other text labels in component grouping left aligned with the longest label. All labels vertically center aligned with associated components

Two styles of capitalization are used in GNOME user interface elements:

The following table indicates the capitalization style to use for each type of user interface element.

Icons should use colors based on the basic thirty-two color palette, darkening or lightening the colours to achieve the desired look. See Section 8.1.1 ― Palette

If possible, document icons should convey the type of the file using a physical object. For example a good icon for MPEG video would be a movie reel. Failing the existence of an appropriate object, when a document type corresponds to a specific application, another option is to use a piece of paper with the corresponding application's icon overlayed it as the document icon. This may be appropriate for a document type such as an application's settings files.

Application's that handle documents should reflect the kind of document they handle in the icon. If an application's predominant purpose is to edit a particular kind of document, it should use this document's icon as its icon.

The idea of a toolbar as a shelf filled with tools should be reflected in toolbar icons. Toolbar icons should have the perspective of being viewed head on, as if they were actually sitting on a shelf at eye-level. Some design guides refer to this perspective as "flush".

Principles of toolbar icon design should be followed with menu icons, just at a smaller size. Where a corresponding toolbar icon exists, a menu icon should mirror its design.

For accessibility reasons, you should create high and low contrast and large print versions of all icons, in addition to the regular size and contrast icon. A suggested process for conveniently integrating this into your icon design is as follows:

High contrast icons are greatly simplified versions of an application's existing regular icons. They are drawn with two colors, black and white, and thicker borders. This style allows high contrast icons to be distinguishable when viewed by a user with a visual impairment. Below is an approximation of what well-designed high contrast icons look like when viewed by someone with a visual impairment.

Table 9-3 Simulation of low vision user viewing high contrast icons

Description	High Contrast Icon	Simulated Appearance
Book
CD-ROM
Copy

If a regular icon uses a simple, straightforward metaphor the corresponding high contrast icon can often use the same metaphor. In many cases the same metaphor will need to be drawn differently to create a simplified high contrast icon.

Figure 9-14 Simplified representation of metaphors for high contrast icons

High contrast icons are created in a vector drawing program. Black and white shapes are layered to create a simplified icon. The process feels like layering black and white pieces of construction paper, as if you were assembling a collage.

Figure 9-15 Layered technique for high contrast icons

The goal of low contrast themes is to eliminate, as much as possible, light values (e.g. a large 'V' value in HSV). To achieve this, the colors in low contrast icons are compressed toward the middle value range, i.e. dark colors are lightened and light colors are darkened.

Low contrast icons are generated from the existing regular icons by adjusting the levels in GIMP. The Input Levels are set to 100, 1.25, 200 and the Output Levels are set to 100, 160, as shown in the Levels dialog below. Large numbers of regular icons can be quickly converted to low contrast by using GIMP's scripting facilities.

Figure 9-16 Levels dialog in GIMP showing correct levels for generating low contrast icons

Figure 10-1 A plethora of pointing devices: mouse, trackball, foot-operated mouse, joystick, trackpad, and a finger-mounted pointing device.

For most users, the mouse provides the main way of interacting with graphical user interfaces. The term "mouse" is used in this chapter to include other pointing devices that can be used to move the pointer around the screen, such as trackballs, trackpads, spaceballs, graphics tablets, or assistive technology devices that emulate a mouse.

For right-handed users, the left button on a conventional mouse is used for the majority of mouse actions. We therefore call it the left button here, even though that may not physically be the case. For this reason, you may sometimes see this button referred to in code or documentation as "Button 1" or the "Selection Button".

Similarly for right-handed users, the right button on a conventional mouse is used for operations involving pop-up menus. We therefore call it the right button in this chapter. You may sometimes see this button referred to in code or documentation as "Button 3" or the "Menu Button".

A conventional mouse with three buttons normally has its third button (or a scrollwheel that acts as a button when pushed) between the left and right buttons. We therefore call it the middle button, but you may sometimes see this referred to in code or documentation as "Button 2" or the "Transfer Button".

Drag and drop is a direct manipulation technique, where you perform actions on selected objects by moving them around the screen with the mouse. You "drag" an object by clicking it, then holding the button while you move the pointer to the object's target location. The object is "dropped" at that location by releasing the mouse button.

10.1.3.2. Mouse Pointers to Use for Drag and Drop

Use the default GTK drag and drop pointers for the standard transfer operations listed below. This consistency helps ensure the user will know exactly what to expect when they release the mouse button. If you have to design a pointer for a non-standard transfer action not listed here, follow the style of the standard pointers.

Table 10-4 Mouse Pointers for Drag and Drop

Pointer Shape	Meaning
	Move selection. The dragged selection will be moved to the drop location, removing it from its previous location.
	Copy selection. The dragged selection will be copied to the drop location, leaving the original intact.
	Link selection. A link to the selection will be inserted at the drop location. How the link appears will be application-dependent, it may be a hyperlink, an icon, or a duplicate of the orignal selection, for example.
	Middle button or Alt-left button drag. A pop-up menu will be posted at the drop location to ask whether the user wants to Move, Copy, or Link the selection, or Cancel the operation.
	Can't drop here. Show this pointer while the mouse is over an area where the selection cannot be dropped.

All objects on the desktop must behave consistently. Despite their specialized nature, applets are no exception.