That Evil Default Button
Default buttons in dialog boxes make our lives easier by making handling a dialog box more efficient. Just hitting the return or enter key instead of having to click a button or using some keyboard short cut chord to invoke the default action, is a welcome user interface feature.
François Joseph de Kermadec points out, however, that these default buttons have an inherent drawback: “we all want to click on [the default button] to just regain control of our machines”, which leads François to wonder whether dialog boxes are “too easy.” Referring to the SSH command line tool, he suggests a solution to the Default Button Problem: provide a dialog box without any buttons and have the user type “yes” or “no” into a text field, instead.
Although I do agree with François on the problem as such, I disagree on the cause of that problem: it is not a question of button vs. text field, but, rather, of good UI design vs. bad UI design. There are two key UI design aspects applicable to buttons that play a role here: properly labeling those buttons, and chosing the appropriate default button.
“Yes or no?” — “Yes or no what?!”
Here’s what the Dialogs section of Apple’s own Human Interface Guidelines state on button labels (aka button names):
Button names should correspond to the action the user performs when pressing the button—for example, Erase, Save, or Delete.
Don’t we all just hate those “Yes”/”No” button combos and their “OK”/”Cancel” twins? Frankly speaking, using those instead of following the guideline above is proof-positive that the developer was either lazy or incompetent. Here’s an example for such a dialog box straight from Apple Mail 2:
You must read the entire text in the dialog box to be absolutely sure that you won’t make the wrong choice, because you can’t possibly guess if “No” means “No, don’t delete those. I may still need them.”, or if it means “No, I don’t want to keep those messages. Delete them.” Yeah, right, there will hardly be anyone who wants to keep those $&%*ing spam messages. But consider those “Save changes?” dialogs that you may see when you quit an application, and the problem will become more obvious: some applications ask if, before shutting down the application, you want to save changes, others ask if you want to discard changes. Click the default buton on impulse, and you may be in for the “data surprise du jour.”
The solution is painfully obvious: re-label the “OK” button “Erase,” and there’d be no more ambiguity, and as long as you’re aware just what action you just invoked, you wouldn’t even have to read the dialog box text to decide which button to click.
Safety first
Apart from screwing up in the button labeling department, the developer who designed that dialog also managed to choose the wrong default button. Apple’s HIG are pretty clear on this topic, too (emphasis is mine):
The default button should be the button that represents the action that the user is most likely to perform if that action isn’t potentially dangerous.
Even if the user will most definitely erase those junk mail messages if she chooses that item from Mail’s “Mailbox” menu, the action will lead to data loss of some kind, and the dialog box clearly points out that this action “cannot be undone.” In other words, that is a “potentially dangerous” action. Again, since I can’t really picture any of you readers caring much about spam emails, let’s look at another dialog box that is just as badly designed.
Emptying the trash is a “potentially even more dangerous” action, since it is much more likely that a valuable file will inadvertantly end up in the trash than in Mail’s spam trap. For a company that is as outspoken about usability as Apple, the choice of default button in both dialogs is a serious, unexcusable design flaw of massive proportions. I mean, even the designers at Apple apparently know just how “dangerous” the “Empty Trash” command is: hitting a shortcut like Command-Shift-Backspace by mistake would border on a freak accident. Then why throw away the extra protection by not choosing the “Cancel” button as the default in the confirmation dialog? Oh, and make that “Empty” instead of “OK”, too, please.
In-House Button Benchmark
Making matters worse is the fact that are must be other UI designers at Apple who know just How It Should Be Done™. Take this dialog box from Safari, for example:
As soon as your eyes pick out the two words “reset Safari” at the end of the bold text bit and the labels “Cancel” and “Reset” on the buttons, that’s all you need to know. The rest of the text in the dialog box may provide some useful additional information, especially if you’re confronted with that specific dialog box for the first time, but it is anything but a must-read. What’s more, even if you hit the return key in a fit of “natural geek reflexes:” no problem, nothing damaged, courtesy of your Competent Coder who chose the proper default button for that dialog.
When a Button Click is Not Optional
For some applications and in some contexts, even that may not be enough, so Apple provides a UI design suggestion for when you must make absolutely, positively sure that the user is forced to consciously click a button in a dialog, instead of just cooly dismissing the dialog box by smacking the return key:
Don’t use a default button if the most likely action is dangerous—for example, if it causes a loss of user data. When there is no default button, pressing Return or Enter has no effect; the user must explicitly click a button.
It’s pretty ironic that the most common use within Mac OS X that I’ve seen so far does not have much to do with data protection, but has a lot to do with legal protection: it’s this dialog sheet from the Installer application:
Easy Remedy
By applying just these two principles — proper button labels and proper choice of default button — to the design of their software, developers should be able to ensure that a user cannot inadvertantly hit the wrong button in a dialog box, so that there should be no need for deploying François’s text-field-only alternative. Now, if only Apple would lead by good example by following their own guidelines across their whole range of software products…
2 Readers have commented on this article:
Subscribe to this article's comments
Daniel J. Wilson 24 March 2007 at 19:01
The buttons on Mail’s spam deletion confirmation dialog definitely should be relabeled, but I think the dialog itself is enough of a failsafe that making Erase the default would be acceptable.
Ideally, a lot of these confirmation dialogs should be replaced by Undo support.
Jochen Wolters 24 March 2007 at 21:50
Daniel:
I agree that Undo is the best safeguard against user error or user change-of-mind. However, that is exactly why I would advocate for changing the default button in that Mail deletion dialog, because this dialog appears at a step beyond which Undo is no longer available. But I concede to being annoyingly fussy in that regard…