About Face 2.0(c) The Essentials of Interaction Design

Every modal dialog box has one or more terminating commands. Most modal dialog boxes have three: the OK and Cancel buttons and the Close box on the title bar. The OK button means, "Accept any changes I have made and then close the dialog." The Cancel button means, "Reject any changes I have made and then close the dialog." This is such a simple and obvious formula, such a well-established standard, that it is inconceivable that anyone would vary from its familiar, trustworthy, well-trod path. Yet, for inexplicable reasons, many user interface designers do diverge from this simple formula, always to the detriment of their product and the despair of their users.

The modal dialog box makes a contract with the user that it will offer services on approval—the OK button—and a simple way to get out without hurting anything—the Cancel button. These two buttons cannot be omitted without violating the contract, and doing so deflates any trust the user might have had in the program. It is extremely expensive in terms of stretching the user's tolerance. Never omit these two buttons or change their legends.

A colleague countered this tip by suggesting that a dialog box asking if the user wants to Cancel Reservation? would cause problems when it appears with an OK and Cancel button. What does it mean to say "Cancel" to Cancel? Good question, and the solution to the problem is never to ask questions like that. If you ever need to ask a question like that—and you shouldn't—don't express it using the same words that are standard to termination controls. With a Cancel Reservation? query, users must respond with the word Cancel to avoid canceling. Confusing? You bet! Instead, the question should be stated like this: Remove the Reservation? Better yet, we'll talk about how to eliminate confirmation dialogs entirely in Part VII.

The design tip "Offer OK and Cancel buttons on all modal dialog boxes" applies to function and property dialogs. Bulletin dialogs reporting errors—those hateful things—can get away with just an OK button (as if the user wants to collude in the program's failure!). Process dialogs only need a Cancel button so the user can end a time-consuming process.

The OK and Cancel buttons are the most important controls on any dialog box. These two buttons must be immediately identifiable visually, standing out from the other controls on the dialog box, and particularly from other action buttons. This means that lining up several identical-looking buttons, including OK and Cancel, is not the right thing to do, regardless of how frequently it is done. Even from companies who should know better, the OK and Cancel buttons are buried in groups of other, unrelated buttons, and their familiar legends change with depressing frequency.

The Cancel button, in particular, is crucial to the dialog box's capability to serve its pedagogic purpose. As the new user browses the program, he will want to examine the dialogs to learn their scope and purposes and then cancel them so as not to get into any trouble. For the more experienced user, the OK button begins to assume greater import than the Cancel button. The user calls the dialog box, makes his changes, and exits with a confirming push of the OK button.

For a while, Microsoft adopted a new standard for terminating buttons. It demanded that the OK button be in the upper-right corner of the dialog and that the Cancel button be positioned immediately below it, with the Help button below that. Thank goodness recent releases of Windows have abolished this misstep. The majority of users read from upper-left to lower-right, so the terminating buttons make more sense in the lower-right of the dialog box. Microsoft has also gone for the executive gray look, and the terminating buttons are not visually identified by any unique color, shape, or even a unique typeface or type size. They blend right in with the other buttons on the dialog—too bad.

The OK button should be placed in the lower-right corner of the dialog box, and the Cancel button should be placed immediately to its left. The user can then dependably know that an affirmative ending of the dialog can be had by going to the extreme lower-right corner. To their credit, the folks at Apple have gotten this right from the beginning. Why do so many other companies continue to have such trouble with it?

The Close box

Because dialog boxes are windows with title bars, they have another terminating idiom. Clicking the Close box in the upper-right corner (or the upper-left corner on the Mac) terminates the dialog box. The problem with this idiom is that the disposition of the user's changes is unclear: Were the changes accepted or rejected? Was it the equivalent of an OK or a Cancel? Because of the potential for confusion, there is only one possible way for programs to interpret the idiom: as Cancel. Unfortunately, this conflicts with its meaning on a modeless dialog, where it is the same as a Close command. The Close box is needed on a modeless dialog but not on a modal dialog box. So, to avoid confusion, the close box should not be included in modal dialogs.

If the user expects an OK and gets a Cancel, he will be surprised and will have to do the work over—and he will learn. On the other hand, if the user expects a Cancel and gets an OK, he will still have to do the work over, but this time he will be angry. Don't let this situation arise.

The Help button

The Help button is often presented as a button on par with OK and Cancel. It requests context-sensitive help but doesn't terminate the dialog, so it isn't a terminating button. It is so often grouped with the terminating buttons that it has assumed the same importance by association. Online help, however, is not as important as the terminating commands. Putting Help adjacent to them is weak, but not harmful, and it has the power of a familiar standard. Help would be better placed as a control on dialog title bars. In many of their recent application versions, Microsoft is showing that it understands this issue. As you can see in Figure 31-3, Microsoft has moved Help away from the OK and Cancel terminating buttons, and put it on the title bar. Up there, it is on an area common to all dialogs, but clearly separated from the very special terminating commands (except, of course, the Close box).

Figure 31-3: This Properties modal dialog box from Windows XP shows how Microsoft has finally realized that Help is not a terminating command. It removed it from the suite of terminating buttons and put it on the title bar near the Close box. This is certainly an improvement, but then Microsoft went ahead and added another control to the terminating-button row: Apply. There is no use for an Apply function on this tab pane, but it is applicable on the Sharing pane. Why not put the Apply button on the pane where it means something and keep it out of the way of the terminating buttons?