# Controls

## Using Controls Effectively

GNOME provides a set of controls, also known as widgets, which allow users to interact with your applications. Using these controls appropriately and not altering their standard behavior is important. This allows users to predict the effects of their actions, and thus learn to use your application more quickly and efficiently. Controls that behave in non-standard ways break the user's mental model of how your application works, and dilute the meaning of the interface's visual language.

## Terminology

Although they are known as "widgets" in the GNOME APIs and developer documentation, do not use this term in your user interface or user documentation. Refer to them by their specific names (for example, "buttons" or "menus"), or by the generic name "controls".

## Sensitivity

Sometimes it does not make sense to allow the user to interact with a control in the current context, for example, to press a Paste button when the clipboard is empty. At these times, make the control insensitive to minimize the risk of user error. While a control is insensitive, it will appear dimmed and will not be able to receive the focus, although assistive technologies like screenreaders will still be able to detect and report it.

It is usually better to make a control insensitive than to hide it altogether. This way, the user can learn about functionality they may be able to use later, even if it is not available right now.

### Two check boxes: sensitive (top) and insensitive (bottom)

Screenshot showing the visual appearance of sensitive and insensitive check box controls

### Locked Controls

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:

- Settings that, if set wrongly, could prevent the application from functioning at all. For example, proxy settings in a network application.

- Settings that could refer to networked resources. For example, the Templates directory in an office application, where shared stationery such as fax cover sheets might be stored.

- Settings that customize the user interface, other than those required for accessibility. For example, certain menu, keyboard or toolbar customization options.

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.

#### Sample code fragment showing how to make a GConf-locked control insensitive

    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:

#### Example of a dialog with locked controls

Screenshot showing disabled proxy controls in a web browser's property dialog, under the caption "Only the system administrator can change these settings"

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

## Text Entry Fields

Text entry fields are used for entering one or more lines of plain text. In GTK 2, the GtkEntry control is used for single-line text entry, and GtkTextView for multiple-line text entry.

### Single and multi-line entry fields

Screenshot of part of a dialog, containing both single and multi-line entry fields

## Guidelines

- 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:

  ### Text entry field with static text prompt

  A text entry field in which the user must input a time, with the label "hh:mm" beside it to indicate the required format

- 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:

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

  A text entry field in which the user must input a date, with a button labelled "Choose" beside it that opens 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.

### Behavior of Return key

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.

#### Note

Gtk does not currently move focus to the next control when Return is pressed and either `activates-default=FALSE`, or there is no default button in the window. For now, Return does nothing in these situations, so remember to implement the focus change behavior yourself.

### Behavior of Tab key

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.

## Spin Boxes

A spin box is a text box that accepts a range of values. It incorporates two arrow buttons that allow the user to increase or decrease the current value by a fixed amount.

### Example of a spin box

A simple spin box used to specify the spacing between applets on a panel

## Guidelines

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

## Sliders

A slider allows the user to quickly select a value from a fixed, ordered range, or to increase or decrease the current value. The control looks like the type of slider that you might find on an audio mixing desk or a hi-fi's graphic equalizer. In gtk, you implement a slider using the GtkHScale or GtkVScale controls, for horizontal or vertical sliders respectively.

### A simple slider control

A slider control used to change the stereo audio balance between left and right speakers

## Guidelines

- Use a slider when:

  - adjusting the value relative to its current value is more important than choosing an absolute value. For example, a volume control: the average user will usually think about turning the volume up or down to make a sound louder or quieter, rather than setting the peak output to a specific decibel value.

  - it is useful for the user to control the rate of change of the value in real time. For example, to monitor the effects of a color change in a live preview window as they drag the RGB sliders.

- 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 controls-slider-figure.

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

  ### Slider controls with linked spin boxes

  Three slider controls used to change RGB values, each with a spinbox beside them to facilitate direct numeric entry

## Buttons

A button initiates an action when the user clicks it.

### Typical buttons in a modal dialog

OK and Cancel buttons as found in a modal dialog

## Guidelines

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

In a dialog, one button may be made the default button, which is shown with a different border and is activated by pressing Return. Often this will be the OK or equivalent button. However, if pressing this button by mistake could cause a loss of data, do not set a default button for the window. Do not make Cancel the default button instead. See default-buttons for more information.

If it does not make sense to have a default button until several fields in the dialog have been correctly completed—for example, both the Username and Password fields in a login dialog—do not set the default button until they have both been completed.

## Check Boxes

Check boxes are used to show or change a setting. Its two states, set and unset, are shown by the presence or absence of a checkmark in the labelled box.

### A typical group of check boxes

A typical group of five check boxes in a dialog

## Guidelines

- 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:

  ### Ambiguous check box (top), radio buttons work better in this case (bottom)

  Two images: one showing a single check box ambiguously labelled "Progress bar in left of statusbar", the other making the choice explicit with radio buttons labelled "Left" and "Right" under the heading "Status bar progress indicator position:"

  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:

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

  Check boxes showing the Hidden, Readable and Writeable states of two selected files in Nautilus. Both files are hidden, neither are writeable, but one is readable. The Readable check box is therefore shown in its mixed state.

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

  When a check box is in its mixed state:

  - clicking the box once should check the box, applying that setting (when confirmed) to all the selected objects

  - clicking the box a second time should uncheck the box, removing that setting (when confirmed) to all the selected objects

  - clicking the box a third time should return the box to its mixed state, restoring each selected object's original value for that setting (when confirmed)

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

## Radio Buttons

Radio buttons are used in groups to select from a mutually exclusive set of options. Only one radio button within a group may be set at any one time. As with check boxes, do not use radio buttons to initiate actions.

### A typical group of radio buttons

A typical group of three radio buttons in a dialog

## Guidelines

- 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:

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

  Radio buttons showing the Thick, Thin and Dashed drawing styles of two selected shapes in a drawing application. One shape is drawn in the thick style, the other in the dashed style. The Thick and Dashed radio buttons are therefore shown in their mixed state, and the Thin radio button is unset.

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

## Toggle Buttons

Toggle buttons look similar to regular Buttons, but are used to show or change a state rather than initiate an action. A toggle button's two states, set and unset, are shown by its appearing "pushed in" or "popped out" respectively.

### A typical group of toggle buttons

A group of four toggle buttons representing a choice of measurement units: inches, centimeters, feet and meters

## Guidelines

- 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:

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

  Toggle buttons showing the Thick, Thin and Dashed drawing styles of two selected shapes in a drawing application. One shape is drawn in the thick style, the other in the dashed style. The Thick and Dashed toggle buttons are therefore shown in their mixed state, and the Thin toggle button is unset.

## Drop-down Lists

Drop-down lists are used to select from a mutually exclusive set of options. They can be useful when there is insufficient space in a window to use a group of radio buttons or a single-selection list, with which they are functionally equivalent.

### A drop-down list showing current selection (left) and the list of available choices when clicked on (right)

Two images, one of a drop-down list displaying its current setting, and the other showing its popup menu of available choices when clicked on

Recommendations:

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

You should normally use radio buttons or a list instead of drop-down lists, as those controls present all the available options at once without any further interaction. However, drop-down lists may be preferable in a window where:

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

Drop-down lists can also be useful on toolbars, to replace a group of several mutually-exclusive toggle buttons.

## Drop-down Combination Boxes

Drop-down combination boxes combine a text entry field and a dropdown list of pre-defined values. Selecting one of the pre-defined values sets the entry field to that value.

### A drop-down combination box before and after its dropdown list is displayed

Two images, one of a drop-down combination box entry field displaying its current selection, and the other showing its dropdown list of available choices when clicked on

## Guidelines

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

## Scrollbars

Often an object (such as a document or a list) will not be fit within the confines of its viewer control. In these cases a scrollbar can be affixed to the viewer control. The scrollbar alters which part of the object is currently visible inside the viewer control: it slides the view across the object in one axis (horizontal or vertical).

## Guidelines

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

## Lists

A list control allows the user to inspect, manipulate or select from a list of items. Lists may have one or more columns, and contain text, graphics, simple controls, or a combination of all three.

### A simple two column list

Picture of list control containing two unsorted columns of text

## Guidelines

- 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:

  - the list has more than one column, or

  - the list has only one column, but the user may wish to re-order the list. (This is rarely useful with single column lists).

  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:

  ### A simple check box list

  Picture of list control with two columns. The first column consists of check boxes showing whether or not the corresponding item in the second column is selected for further action.

  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.

### Sortable Lists

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.

### Guidelines

- Indicate which column is currently sorted by showing an upward or downward facing arrow in its header:

  Sort Order | Arrow Direction | Example
  Natural | Down | Alphabetical; smallest number first; earliest date first; checked items first
  Reverse | Up | Reverse alphabetical; largest number first; most recent date first; unchecked items first)

- Clicking an unsorted column header sorts the column in natural order, indicated by showing a down arrow in its header.

- Clicking a column header sorted in natural order re-sorts it in reverse order, indicated by showing an up arrow in its header.

  #### Un-sorting lists

  Occasionally, an unsorted state may be useful, for example to show items in the order in which the user added them to the list. In such cases, clicking a column sorted in reverse order should un-sort it, indicated by removing the arrow from the column header.

  Usually, however, this is better achieved by adding an extra column that the user can sort in the usual way, such as a sequence number column in this example.

## Trees

A tree control allows the user to inspect, manipulate or select from a hierarchichal list of items. Trees may have one or more columns, and contain text, graphics, simple controls, or a combination of all three.

### Use trees with care!

Because of their complexity compared to other controls, novice and some intermediate users often have problems using and understanding tree controls. If your application is designed for that type of user, you might want to consider alternative ways of presenting the information, such as the Nautilus list or icon view, or the hierarchical browser lists found in GNUstep's File Viewer.

### A simple tree control with one level of hierarchy

Picture of tree control showing months of the year as top level nodes, and public holidays in those months as their children

## Guidelines

- 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:

  - the tree has more than one column

  - the tree has only one column, but the user may wish to re-order the tree. This should rarely be true of single column trees.

  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:

  ### A simple check box tree

  Picture of tree control with two columns. The first column consists of check boxes showing whether or not the corresponding item in the second column is selected for further action.

  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.

### Sortable Trees

As with lists, the user may find it useful to sort long or multi-column trees. See the guidelines in controls-lists-sortable for more information.

## Tabbed Notebooks

A tabbed notebook control is a convenient way of presenting related information in the same window, without having to display it all at the same time. It is analagous to the divider tabs in a ring binder or a file cabinet.

### A typical notebook control with three tabs

Picture of notebook control with three tabs

## Guidelines

- 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:

  ### Fixed- and proportional-width tabs (preferred)

  Side-by-side comparison of one notebook whose tabs are all the same width, and one whose tabs are only wide enough to accommodate the tab labels. The latter takes up around 33% less screen space.

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

If you have more than about six tabs in a notebook, use a list control instead of tabs to switch between the pages of controls. For example:

### Use of list control where there would be too many tabs to fit comfortably in a notebook

Part of a window including a list control with 7 items, each item representing a category of settings such as "Appearance" and "Navigation". The controls in the rest of the window change depending on which item is selected in the list.

As in this example, place the list control on the left-hand side of the window, with the dynamic portion of the window immediately to its right.

### Status Indicators

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.

## Progress Bars

Progress bars are visual indicators of the progress of a task being carried out by the application, and provide important feedback. For information on using a progress bar within a progress window, see windows-progress.

You can use two main types of progress bars in your application— measured-progress bars and indeterminate-progress bars (the kind that bounce back and forth). In addition there are are three types of measured progress bars.

## Guidelines

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

### Time-remaining Progress Indicator

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.

#### A simple 'time remaining' progress bar

A simple time-remaining progress dialog

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.

### Typical-time Progress Indicator

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.

#### A simple 'typical time remaining' progress bar

A simple 'typical time remaining' progress dialog

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.

### Indeterminate-progress indicator

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.

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

A simple 'indeterminate time' progress dialog, showing a slider moving back and forth until the operation is complete

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

## Statusbars

A statusbar is an area at the bottom of a window that can be used to display brief information about the status of the application.

### A simple statusbar

A statusbar at the bottom of a document window, showing current zoom level and a status message indicating that the document has been modified since it was last saved

## Guidelines

- 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:

  - general information about the document or application. For example, current connection status in a network application, or the size of the current document in a text editor.

  - information about the task the user is currently performing. For example, while using the selection tool in a drawing application, "Hold Shift to extend the selection"

  - progress of a background operation. For example, "Sending to printer", "Printing page 10 of 20", "Printing Complete".

  - a description of the control or area of the window under the mouse pointer. For example, "Drop files here to upload them"

  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:

  - Inlaid appearance for areas that respond to a double click

  - Flat appearance for areas that are not interactive

  In status-bar-figure, 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.

  ### An interactive statusbar

  A statusbar with a text panel that responds to a double click, a button that responds to a single click, and a non-interactive progress area

  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.

## Frames and Separators

A frame is a box with a title that you can draw around controls to organise them into functional groups. A separator is a single horizontal or vertical line that you can use to divide windows into functional groups.

Frames with a border around their perimeter have traditionally been used for denoting groups of related controls. This is advantageous because it physically seperates disimilar controls, and also avoids repitition of the frame's label in individual member control labels. Unfortunately, they add visual noise that can both make a window appear more complex than it really is, and reduce the ability to quickly scan window elements.

Rather than using bordered frames, use frames without borders, bold labels to make the categories stand out, and indented contents. This, combined with good layout and spacing, is usually a better alternative to bordered frames.

### Preferred frame style, using bold labels, spacing and indentation

Frame showing the preferred style described above

### Traditional frame style, using borders (deprecated)

Frame showing the traditional style described above

## Guidelines

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