Interface: Dialog Windows
Dialog boxes are used to ask the user for input or information. They should not be used frequently — only for operations that are important enough to warrant their own windows. Here are a few dialog box guidelines.
1. The User Isn't Stupid
Don't try to protect your users from themselves, you'll simply come across as trying to insult their intelligence. Some apps assume that the user is a security risk and that data should be protected by requiring the user to type in a message, usually a variant of "Yes" or "Delete", to proceed with the command the user has initiated. Not only does this really slow down users, it also makes them feel less trusting of the program they're working in.
Requiring unorthodox input methods to dismiss dialogs — such as keyboard input or voice recognition — is most likely to focus the user's attention on the act of dismissing the dialog rather than the dialog's purpose, especially if the dialog doesn't give sufficient information (MIT CSAIL (pdf)).
2. Favor Verb-based Button Labels
The faster the user can figure out what message a dialog window is asking or what message it is trying to convey, the faster they can dismiss it and continue with their work. The classic dialog box flaw is to ask the user a question and provide "Yes" and "No" buttons as means to answer.
Faced with a Yes or No question, the user will slow down as they are forced to read the dialog window's message very carefully. If the dialog text contains any negatives (or worse, double negatives), it'll take the user more than just a few moments to figure out what they're agreeing or disagreeing to.
The above examples are the standard OS-provided confirmation windows that Windows XP and Mac OS X display when attempting to close any file that has unsaved changes.
Without seeing the actual dialog box message text, the combination of Yes, No and Cancel makes no sense. Meanwhile buttons labeled with verbs such as "Save" don't require any explanation at all — merely glancing at the buttons themselves makes it immediately obvious what the outcome will be when pressing each one.
If the user interface action cannot be described by a verb or a relatively short phrase suitable for a pushbutton label, don't simply resort to Yes and No. More appropriate would be "OK" — or "Confirm" — and "Cancel". Such phrasing makes it clear that pressing Cancel will back out of whatever user interface command initiated the dialog window, while the other alternative will go through with the action.
If a command associated with a dialog window's button could result in irreversible data loss, it is generally a good idea to make one of the less destructive choices the default button (responding to shortcuts such as the Return key). This isn't a hard and fast rule, however; if the user is expected to have to replace old files with new ones frequently, having the command for overwriting old data be the default option might make sense.
3. Be Informative, but Not Overly So
If the user doesn't understand the dialog window, the interface has failed to do its job. In general, each dialog box that is not a standard Save or Open dialog should feature a message element that explains the user what they're about to do and what the consequences of that action could be. The interface shouldn't assume that the user is necessarily aware of what action they've triggered — simply asking "are you sure?" is in most cases insufficient. The user might have misclicked a button or menu item, expecting a different dialog window to appear. Not giving enough information about the command that's about to be performed might lead the user into dismissing the dialog thinking something else entirely is about to happen.
Conversely it's very possible to overdo descriptive dialog window messages. It's bad to not tell the user what is going on, but it's almost just as bad to give them too much information. Long messages are slower to read through than short, concise ones, and long messages are also more vulnerable to being frustratingly confusing.
Try to make sure your dialog window consists of buttons, menu items and other elements labeled in such ways that they can't be read in many different ways. For instance, a button named "Logging On" might mean:
- Turn Logging On — logging is currently off and will be turned on, or
- Logging Is On — logging is currently on and will be turned off.
For this reason, try not to omit verbs, as phrases and commands based on verbs are the easiest to recognize. Name your user interface elements logically: don't mix negative and positive statements together, and use the same kind of language throughout. Earn your user's trust.
4. Use Meaningful Spacing
If the dialog box you are designing features more than two pushbuttons or other controls, use spacing to convey meaning. Consider the Mac OS X file closing confirmation from section 1 again:
The set of buttons in this dialog window makes very effective use of spacing. Clicking Cancel will simply return the user to the document without closing it, while clicking Save will write a copy of the file to disk and then close it. However, clicking Don't Save will both close the document and discard any unsaved changes. Of the three buttons, only one can directly cause irreversible data loss, and as such, it is neither the default choice nor placed near the "safe" alternatives.
The spacing makes it clear that the "Don't Save" button has a value and meaning very different from the other two, and this button arrangement also makes it much harder to accidentally click the wrong choice than if the spacing between buttons was equal.