Dialog Box Design Concepts

Dialog Boxes

Dialog Box Usage Patterns

When properly used, dialog boxes are a great way to give power and flexibility to your program. When misused, dialog boxes are an easy way to annoy users, interrupt their flow, and make the program feel indirect and tedious to use. Modal dialog boxes demand users' attention. Dialog boxes are often easier to implement than alternative user interfaces (UIs), so they tend to be overused.

Designing effective dialog boxes

A dialog box is most effective when its design characteristics match its usage. A dialog box's design is largely determined by its purpose (to offer options, ask questions, provide information or feedback), type (modal or modeless), and user interaction (required, optional response, or acknowledgement). Its usage is largely determined by the context (user or program initiated), probability of user action, and frequency of display.

Dialog box characteristics

Modal dialog boxes have these characteristics:

●Are displayed in a window that is separate from the user's current activity.

●Require interaction—users must close before continuing with the owner window.

●Can break users' flow.

●Use a delayed commit model; changes aren't made until explicitly committed.

●Have command buttons that commit to task.

●Best used for critical or infrequent, one-off tasks that require completion before continuing. Modeless dialog boxes have these characteristics:

●Can be displayed in context using a task pane or with an independent window.

●Don't require interaction—users can switch between the dialog box or pane and the calling window as desired.

●Can use an immediate commit model; changes are made immediately.

●Have command buttons that close the window.

●Best used for frequent, repetitive, or on-going tasks.

Dialog box interactions

Dialog boxes also have different types of user interaction:

●Response required. Users must respond to provide required input. For example, a Replace command requires displaying a dialog box so users can specify the Find and Replace strings.

●Response optional. Users might respond to provide optional input, but the default values are usually acceptable. For example, while users might make changes in a Print dialog box, they usually accept the default options.

●Acknowledgement only. Users' only interaction is to acknowledge the dialog box by reading and closing it.

Dialog box contexts

Dialog boxes are displayed in different contexts:

●User initiated. A dialog box is displayed as the direct or indirect result of a user interaction.

●System or program initiated. A dialog box is displayed independently of any user interaction.

Creating effective dialog boxes

Consider these effective examples:

● A modal dialog box is an excellent choice for user initiated, one-off tasks that require a response:

● A modal dialog box is an excellent choice for infrequent system or program initiated, one-off tasks that require a response:

● A modeless dialog box is an excellent choice for user initiated, on-going tasks:

● A modal dialog box is a good choice for critical or infrequent, program initiated messages that are likely to change user behavior:

Now consider these ineffective examples:

●A modal dialog box is a poor choice for frequent tasks to provide options that users don't have to change. Instead, use the default options without asking, but allow users to make changes later.

Incorrect:

Correct:

In the correct example, Microsoft® Word 2007 correctly displays a modeless UI instead of a modal dialog when users paste text. That way, users aren't required to respond.

●A modal dialog box is a poor choice for messages that are unlikely to change user behavior. Instead, consider using a notification or a status bar, or even doing nothing.

Incorrect:

Correct:

Using a modal dialog box for status is annoying. In the correct example, Microsoft Outlook® correctly uses the status bar for this purpose, instead.

●A modal dialog box is often a poor choice for displaying important options. Instead, display essential options either directly with inplace UI, or on demand using progressive disclosure.

Incorrect:

Correct:

In this example, the search options could be set in an owned dialog box, but Word correctly uses progressive disclosure instead.

●A modal dialog box is a poor choice for giving feedback of minor importance, because it requires acknowledgement.

Incorrect:

In this example, Word uses a modal dialog to indicate that it has finished searching a document, which forces users to click the OK button to acknowledge. Modeless feedback would be a better choice.

If you do only one thing...

Make sure that your dialog box design (determined by its purpose, type, and user interaction) matches its usage (determined by its context, probability of user action, and frequency of display).

Improving ineffective dialog boxes

Often the best solution to a bad modal dialog box is either to eliminate the dialog or to redesign it in a way that isn't modal. Some people have concluded that this means all modal dialog boxes are bad and should be eliminated. This is not a correct conclusion (except for Web-based applications, which really should try to avoid pop-up blockers). For example, it is perfectly acceptable to interrupt users with a model dialog box for tasks that require interaction. Modal dialog boxes are the right choice in many circumstances. Trying to eliminate every modal dialog box can reduce the quality of your overall UI.

If you have a dialog box that isn't effective, consider these alternatives:

●If the dialog box is modal but doesn't have to be, consider using a modeless dialog box, task pane, or other modeless UI.

●If the dialog box is for acknowledgement only, consider adding commands to make it actionable. For example, if the dialog box is presenting a problem, consider also providing solutions to the problem.

●Review Is this the right user interface? to determine if there is a better solution.

●If the user experience isn't harmed by removing the dialog box, consider just removing it.

Using the Don't show this <item> again option

Sometimes optional modal dialog boxes turn out to be annoying, especially when displayed often. Such dialog boxes typically strive to inform users about a recurring situation or a feature that addresses such situations. A common solution to this problem is to provide a Don't show this <item> again option that suppresses the dialog box in the future:

In this example, the dialog box attempts to educate users about a recurring situation. Selecting Don't show this <item> again prevents the dialog box from being displayed in the future.

This solution has problems. It assumes that users:

●Make rational decisions about which dialog boxes to suppress based on their future needs and not on their emotions ("Stop pestering me!").

●Can accurately recognize the reoccurring situations in the future.

●Can remember and apply the information from the previous instance of the dialog box, no matter how long ago it was displayed.

If users fail in any of these steps, they won't see the dialog box in their moment of need, and there is no obvious way to get the dialog box back once suppressed.

If you think your dialog box needs a Don't show this <item> again option, that is a clear sign that it is annoying and potentially unnecessary. Before adding this option, consider the following alternatives:

●Change the design to eliminate the need for the message.

●Make the hard design decision: do users really need to see this dialog box? Will bad things happen if users don't know this information? If so, always display it; if not, never display it.

Incorrect:

In this example, users don't need this confirmation because dismissing Outlook reminders has no adverse consequences. This confirmation shouldn't be displayed at all.

● Use less intrusive solutions, such as in-place UI, progressive disclosure, modeless UI (such as balloons or tooltips), or notifications.

Do the right thing by default. Don't force users to configure their way out of a bad initial experience. Keep in mind that littering your program with unnecessary modal dialog boxes is more likely to foster outrage than user education. At a certain point, users tend to dismiss such dialog boxes without reading them.

If you are convinced that users really need to see the information for a while and a dialog box is the best solution, only then should you use the Don't show this <item> again option. If users may need to restore these dialog boxes, provide a Restore messages command in the program's Options dialog box.

Tip: When running your own program, don't change any of the Don't show this <item> again defaults. Doing so helps you evaluate your program's experience the same way your users will.

Dialog Box Usage Patterns

Dialog Boxes

Dialog Box Design Concepts

Dialog boxes have several usage patterns:

Question dialogs (using buttons)

Ask users a single question, and provide simple responses in horizontally arranged command buttons.

In this example, Windows® Internet Explorer® asks if the user wants to open or save a file.

Type: Modal.

Main instruction: The question being asked (could be phrased as an instruction).

Icon: Program, feature, object, warning icon (if potential loss of data or system access), security warning, or none. Commit buttons: One of the following sets of concise commands: Yes/No, Yes/No/Cancel, [Do it]/Cancel, [Do it]/ [Don't do it], [Do it]/[Don't do it]/Cancel, where [Do it] and [Don't do it] are specific responses to the main instruction.

Other controls: There may be supplemental explanations to help users make informed decisions, a chevron control to show more information, and a Don't show this <item> again option if the question can be suppressed in the future.

Annoyance factor: High, if default response can be safely assumed, there really isn't a choice, or the differences among the choices aren't clear.

While confirmations are presented as questions, they are covered specifically in Confirmations.

Question dialogs (using command links)

Ask users a single question or to select a task to perform, and provide detailed responses in vertically arranged command links.

In this example, Windows asks the user to install a device. Using command links instead of command buttons allows for more complete responses.

In contrast to the version with command buttons, these dialogs may have several responses or responses that require more text to describe.

Type: Modal.

Main instruction: The question being asked (could be phrased as an instruction).

Icon: Program, feature, object, warning icon (if potential loss of data or system access), security warning, or none. Command links: Two or more complete, specific responses to the main instruction.

Commit buttons: Cancel.

Other controls: There may be supplemental explanations to help users make informed decisions, and a chevron to show more information.

Annoyance factor: High, if default response can be safely assumed, there really isn't a choice, or the differences among the choices aren't clear.

While confirmations are presented as questions, they are covered specifically in Confirmations.

Choice dialogs

Presents users with a set of choices, usually to specify a command more completely. Unlike question dialogs, choice dialogs can ask multiple questions.

In this example, Microsoft Word presents options to specify the Insert Break command in a modal dialog box.

In this example, Word presents options to specify the Find and Replace command in a modeless dialog box.

In this example, Microsoft Outlook® presents options to specify the Find command in a task pane. By not using a separate window, the command feels more direct and contextual.

Type: Modal, modeless, and task pane.

Main instruction: An optional imperative instruction that tells users what to do.

Icon: None.

Commit buttons: One of the following:

●Modal dialogs: OK/Cancel or [Do it]/Cancel, where [Do it] is a specific response to the main instruction.

●Modeless dialogs: Close button on dialog box and title bar.

●Task pane: Close button on title bar.

Other controls: There may be supplemental explanations to help users make choices, and a chevron to show infrequently used options.

Annoyance factor: Normally low, because user initiated and needs a response, but could be high if users rarely change default values.

Progress dialogs If the operation is a long-running task (over 30 seconds) and can be performed in the background, use a modeless Presents users progress dialog so that users can continue to use your program while waiting.

with progress feedback during a lengthy operation (longer than five seconds), along with a command to cancel or stop the operation.

In this example, a modeless progress dialog box is used provide feedback while users continue to use the program.

Type: Modal and modeless.

Main instruction: A gerund phrase briefly explaining the operation in progress, ending with an ellipsis. Example: Downloading...

Icon: None (but may have an animation).

Commit buttons: Use Cancel if returns the environment to its previous state (leaving no side effect); otherwise, use Stop.

Annoyance factor: Low, if user needs to know when operation is complete, but high if unnecessarily modal or operation isn't significant.

Informational dialogs

Display information requested by the user.

In this example, Word uses a modal dialog box to display word count information.

Type: Modal.

Main instruction: A sentence that describes the information.

Icon: None.

Commit buttons: Close

Other controls: There may be a chevron to show more information.

Annoyance factor: Low, if information is relevant and requested by the user.