Configuration

Configuration allows users to modify the behaviour and appearance of their software.

Status

Experimental: if you use this pattern, you may have to remove or replace it in a future release of your software to remain consistent with other GNOME applications.

When to Use

'using preferences as a band-aid is the root of much UI evil.'

Havoc Pennington

As far as possible, applications should be designed in order to not require manual configuration. Generally, a well-designed interface does not require configuration and will operate effectively with no modification of preferences for both different use cases and users. That said, configuration options can be presented for a number of different reasons:

Essential settings: eg. email account details.
Some applications require user configuration in order to operate. This may require configuration options to be presented when an application is first run.
Personalisation: eg. wallpaper.
This kind of configuration allows users to develop a personal relationship with their systems and can also be used to make a UI interface fun to use. This kind of configuration should be used extremely sparingly, if at all.
To cater for different user groups and varieties of usage.
This reason for adding configuration options should be treated with caution: ideally, software should work for virtually all kinds of users without the need for configuration. Nevertheless, this kind of configuration may sometimes be unavoidable.

Description

Configuration options can be provided via a number of kinds of interface components:

Menu items

Menu screenshot

Menus can contain check boxes and radio buttons for configuration options.

Toolbars

Toolbar screenshot

Configuration options can be provided via toggle buttons and combo boxes in toolbars.

Preferences windows

Preference window screenshot

Configuration tools

Eg: toolbar editors

Assistants

See Assistants.

Guidelines

Configuration should be done automatically wherever possible.
Configuration options should be kept to a minimum: the more options that are added, the more likely it will be for a user to ignore them.
It is vital to provide a good set of default options which work for the vast majority of use cases.
Preferences should be saved between sessions.

Preferences Windows

It is not always necessary to provide a preference window, and they should be avoided if possible. Only use one when the number of necessary configuration options cannot be contained within other interface elements.
Preferences windows should be accessible through the Preferences entry in the Edit menu, should one be provided.
Only configuration options which are infrequently changed should be contained within a preferences window.
Options should be grouped into sections and/or tabs in order to make the interface easy to understand. These groups should be organized by topic rather than level of ability or frequency of use. 'Advanced', 'Options' and 'General' are common group and tab labels which are uninformative and should be avoided.
Where possible, the most commonly used options should be displayed towards the top of the window and in the first tab.
Avoid nested tabs like the plague.

Instant Apply

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

the change will take more than about one second to apply, in which case applying the change immediately could make the system feel slow or unresponsive, or
the changes in the window have to be applied simultaneously to prevent the system entering a potentially unstable state. For example, the hostname and proxy fields in a network properties window.

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

Do not attempt to validate or apply changes caused by editing a text field control until the user has moved focus to a different control in the window, or the window is closed. Validating after each keypress is usually annoying and unnecessary. 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.
When the user moves focus to a different control, do not indicate an invalid entry by displaying an alert or undoing the change the user made. Both of these methods are particularly disruptive for focus-follows-mouse users, for whom focus may leave the control more often than it does for a click-to-focus user.

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

Apply: applies all the settings in the window, but does not close the window in case the user wishes to change their mind.
Cancel: resets all settings in the window to those that were in force when the window was opened. Note: this must undo the effects of all applications of the Apply since the window was opened, not just the most recent one.
OK: 'Applies all settings in the window and closes the window.

Current Usage

Evince provides an excellent example of minimal configuration options.