Dialogs are secondary windows that appear over a primary, parent window. They are used to present additional information or controls, including preferences, properties, or to present messages or questions.
GTK+ provides a number of stock dialogs that can be used, such as for printing or color selection.
There are three basic types of dialog design.
When to use
Dialogs are a commonly recognized design pattern, and there are established conventions for the different types of dialogs that you might want to use. The guidelines on each type of dialog provides further information on this.
While dialogs can be an effective way to disclose additional controls or information, they can also be a source of interruption for the user. For this reason, always question whether a dialog is necessary, and work to avoid the situations in which they are required.
There are many ways to avoid using dialogs. Examples include:
Inline composition for new messages, records or contacts.
In-application notifications are an alternative to message dialogs.
can be a way to display additional controls or options in a less disruptive manner.
Message dialogs are the simplest type of dialog. They present a message or question, along with 1-3 buttons with which to respond. They are always modal, meaning that they prevent access to their parent window. Message dialogs are an appropriate choice when it is essential that the user sees and responds to a message.
Confirmation dialogs use a message dialog to check - or confirm - that the user wants to carry out an action. They have two buttons: one to confirm that the action should be carried out and one to cancel the action.
Confirmation dialogs will often be accidentally or automatically acknowledged, and will not always prevent mistakes from happening. It is often better to provide undo functionality instead.
Error dialogs present an error message to the user. They often include a single button that allows the user to acknowledge and close the dialog.
Error dialogs should generally be a last resort. You should design your application so that errors do not occur, and to automatically recover if something does go wrong.
Action dialogs present options and information about a specific action before it is carried out. They have a heading (which typically describes the action) and two buttons which allow the action to be carried out or cancelled.
The user may be required to choose options or content items before an action can be carried out. In these cases, the affirmative action button should be insensitive before the required steps have been performed in the dialog itself.
Buttons in action dialogs should be labelled with imperative verbs, for example Save, Print. This allows users to select an action with less hesitation.
Many of the stock GTK+ dialogs are action dialogs. The print dialog is a good example: it is displayed in response to the user using the print action, and presents information and options for that print action. The two header bar buttons allow the print action to either be cancelled or carried out.
Presentation dialogs present information or controls. Like action dialogs, they have a header bar and a subject. However, instead of prefixing an action, their content relates to an application or content item.
Preferences and properties are both examples of presentation dialogs, and both present information and settings in relation to a specific entity (either an application or a content item). Properties dialogs are a good example of how dialogs can be used to disclose additional information which is not always needed in the main application window.
Resist the temptation to provide a preference window for your application. Always question whether additional settings are really necessary. Most people will not bother to investigate the preferences that you provide, and configuration options will contribute to the complexity of your application. Make an effort to ensure that your application design works for everybody without the need to change its settings.
Instant and Explicit Apply
Presentation dialogs are either instant or explicit apply. In instant apply dialogs, changes to settings or values are immediately updated. In contrast, explicit apply dialogs include a button for applying changes.
Instant apply should be used wherever possible. Instant apply presentation dialogs have a close button in their header bar.
Explicit apply is only necessary if changes in the dialog have to be applied simultaneously in order to have the desired behaviour. Explicit apply dialogs include a Cancel and a Done button (Cancel resets all values in the dialog to the state before it was opened and Done applies all changes and closes the window).
Dialog windows should never pop up unexpectedly, and should only ever be displayed in immediate response to a deliberate user action.
Dialogs should always have a parent window.
Follow thewhen designing the content of windows.
Useor to break up controls and information.
Avoid stacking dialog windows on top of one another. Only one dialog window should be displayed at a time.
When an affirmative button is included, label it with its actual action. Print is a better label than OK or Done, for example.
Do not enable the OK or equivalent button until all fields that require input have been attended to by the user.
When opening a dialog, provide initial keyboard focus to the component that you expect users to operate first. This focus is especially important for users who must use a keyboard to navigate your application.