[Contents] [Index] [Next] [Previous]

DialogBox Design


When designing a DialogBox, you should follow all the same layout principles as for other applications areas. DialogBoxes are usually transitory. The user usually wants to simply respond and get back to the primary tasks of the application. To help the user respond quickly, there are a number of common DialogBox actions. By using and ordering these actions consistently, you provide the user with cues to quickly respond to each DialogBox.

When a DialogBox is displayed, all components within the DialogBox should reflect the current state of the application. For example, if the DialogBox is used for changing the current font in a text editor, the DialogBox should be initially displayed with the current font. If the DialogBox is modeless, then any changes to the application should be updated in the DialogBox.

DialogBoxes can limit how a user can interact with other windows in order to force the order of interaction. These limitations, which are called modes, are described in the following text.

Modeless
Allows interaction with the secondary window and all other windows.
Primary modal
Does not allow interaction with any ancestor of the window.
Application modal
Does not allow interaction with any window created by the same application even if the application has multiple primary windows.
System modal
Does not allow interaction with any window on the screen. This includes windows from all other applications and any icon box. To indicate a system modal secondary window, the pointer should change shape to a caution pointer whenever it leaves the system modal secondary window.

Remember that the guidelines presented in this section, like all the guidelines in this guide, apply only in a left-to-right language environment in an English-language locale. You need to make the appropriate changes for other locales.

Common DialogBox Actions

While your application can sometimes require special DialogBox actions, most share common actions. The common actions provide a consistent means for the user to quickly respond to DialogBoxes and get back to the primary application tasks. The common actions should be presented in a horizontal collection of PushButtons at the bottom of the DialogBox, separated from the rest of the DialogBox by a Separator.

No DialogBox will contain all of the common actions in the following list. You should use the ones appropriate to your application or determine new actions so they do not conflict with the common actions listed. If you create a new action, you should give it an active-voice label that indicates its purpose. An active-voice label describes the action that pressing the button causes. The actions are listed in the approximate sequence in which they should appear in DialogBoxes as follows:

Yes
Must indicate an affirmative response to a question posed in the DialogBox and then close the window. While Yes is not an active-voice label, it implies a positive response to a question in a QuestionDialog or a WarningDialog. Only use Yes if it is a clear answer to the question.
No
Must indicate a negative response to a question posed in the DialogBox and then close the window. While No is not an active-voice label, it implies a negative response to a question in a QuestionDialog. Only use No if it is a clear answer to the question.
OK
Must cause the application to apply any changes and perform related actions specified by the components in the DialogBox and then dismiss the DialogBox. While OK is not an active-voice label, its usage is too common to change.
Close
Should cause the current DialogBox to be closed without performing any of the actions specified by the components in the DialogBox. This action is usually only available in a DialogBox that provides status information, such as a WorkingDialog. This Label can also be used if the actions in the DialogBox cannot be reversed, in which case this Label replaces Cancel after the first irreversible action is performed.
Apply
Must apply any changes and perform related actions specified by the components in the DialogBox.
Retry
Must cause the task in progress to be attempted again. This action is commonly found in message boxes that report an error.
Stop
Must end the task in progress at the next possible breaking point. This action is commonly found in a WorkingDialog.
Pause
Must cause the task in progress to pause. This action is commonly found in a WorkingDialog and should be used in combination with Resume.
Resume
Must cause a task that has previously paused to resume. This action is commonly found in a WorkingDialog and should be used in combination with Pause.
Reset
Must cancel any user changes that have not been applied to the application. It must also reset the status of the DialogBox to the state since the last time the DialogBox action was applied or to the initial state of the DialogBox.
Cancel
Must close the DialogBox without performing any DialogBox actions not yet applied to the application. Pressing anywhere in the DialogBox, except during a cancelable drag operation, must perform the action of this button.
Help
Must provide any help for the DialogBox.

If a DialogBox action causes an error, the DialogBox should not be dismissed before the error is displayed. Instead, the DialogBox should remain available after the error is dismissed to give the user a chance to correct the error and reuse the DialogBox. If the actions to be performed by OK or Apply depend on the state, then these Labels should be replaced by ones that indicate the action to be performed.

Arranging Common Actions

You should arrange PushButton actions in DialogBoxes in the same way you arrange other PushButtons, according to order and frequency of use. The common action PushButtons should be ordered as presented in the previous section. Positive responses to the DialogBox should be presented first, followed by negative responses, and canceling responses. Help should always be the last action on the right.

The following rules should be used when determining what default buttons to place in a DialogBox:

Determining DialogBox Location and Size

Your application determines the size and location of its DialogBoxes. You should size and place DialogBoxes so that they do not obscure important information in other windows of your application. The initial size of a DialogBox should be large enough to contain the dialog components without crowding or visual confusion, but otherwise should be as small as possible. DialogBoxes should follow the same rules for resizing as a MainWindow as described above.

You should place DialogBoxes on the screen so they are completely visible.

In general, you should place DialogBoxes close to either the component that caused it to be displayed, the current action, or the information needed to respond to it. When a DialogBox relates to an item in an underlying window, you should position the DialogBox to the right of the item. If there is not enough room to the right of the item, try to position the DialogBox to the left, below or above the item, in that order, depending on screen space available. You should only obscure related information as a last resort.

If a DialogBox does not relate to items in the underlying windows, the DialogBox should be placed centered in the application's work area.

If two DialogBoxes need to overlap, you should offset the top DialogBox to the right and below the title of the lower DialogBox. Use your best judgement, knowing that the screen area for DialogBoxes is limited.

While the previous suggestions seem simple enough, they cannot always be followed completely. Therefore, DialogBoxes, once displayed, should be movable so that the user can relocate them as needed to see information in underlying windows.