Polytropia

A Programmer’s View on Default Buttons

Musings from 30 August 2005 on UI Design

In my previous article about That Evil Default Button, I accused programmers who use “Yes”/”No” or “OK”/”Cancel” buttons (instead of “[Action]”/”Cancel”) in their dialog boxes of being “lazy or incompetent”. Maybe we should find out if that judgement is as harsh as it sounds by viewing the topic from a programmer’s perspective.

“Yes”/”No” on Windows

While working on “That Evil Default Button,” I remembered that I had once sent an email to Joel Spolsky, the guy behind the fabulous Joel on Software website, about just that topic. Joel had published an online version of his book on “User Interface Design for Programmers,” which, to my surprise, did not address the issue of the “Yes”/”No” button annoyance.

Here’s an excerpt from the email I sent to Joel, back in September 2001:

Why do programmers and GUI designers choose this route when those dialogs’ usability could be improved considerably so easily: just follow the rule from the Mac HIG and label the buttons with the correlating tasks: instead of Yes - No - Cancel, use Discard Changes - Save - Cancel. Now, you only have to read what the buttons say and you can be sure to hit the right choice all the time. […] Is it really so difficult to add the proper labels to those buttons?

And here’s Joel’s reply:

You’re right. The reason this happens is because on windows, making a “yes/no” dialog is a hundred times easier than making a dialog with other words on the buttons.

Remember that this statement dates back to 2001, and I have no idea if this still applies to today’s Windows APIs, since I have no experience with software development under Windows. But what’s the situation with modern application development under Mac OS X , then? Let’s have a look.

The One-Line-of-Code Convenience

Designing custom dialogs in Xcode, Apple’s development environment, is a drag-n-drop affair: Xcode includes an application called Interface Builder, with which developers create all user interface items of an application by selecting widgets — windows, dialogs, sheets, buttons, sliders, text fields, etc. — from palettes, laying them out visually, and hooking them up with the app’s source code. In other words, Interface Builder is for application UI design what Quark Xpress or Adobe InDesign are for print document design.

By building a dialog box from scratch, there are (almost) no limits with regards to labeling buttons and placing them within the confines of a dialog box window. However, since dialog boxes are used so often, Cocoa, the programming library for native Mac OS X applications, provides a convenient class called NSAlert for handling alert dialogs in a standardized manner.

To make it even easier still, there is a single-line function in Cocoa that, by utilizing the NSAlert class, creates a standard alert dialog box with buttons, shows it on screen, waits for the user to click one of the buttons, closes the dialog box, and reports back to the application which button the user clicked:

int NSRunAlertPanel(NSString *title, 
                    NSString *msg, 
                    NSString *defaultButton, 
                    NSString *alternateButton,
                    NSString *otherButton, 
                    ...)

There are two twin functions called NSRunInformationalAlertPanel() and NSRunCriticalAlertPanel() to cover all three flavors of alert dialog boxes: informational alert, alert, and critical alert, and there are three more for handling sheets, i.e., dialogs that are attached to a document window.

Even if you’re not a programmer, you can probably make out what the variables that are passed to the function mean: the title and msg variables hold the dialog’s title and the dialog’s text message, and the others hold the labels for the three buttons.

A dialog such as this…

… can, thus, be created in just a single line of code (let’s not get into the detail of how the actual document title is inserted into the info text; coders know how it works and users shouldn’t need to ):

buttonPressed = NSRunAlertPanel(
    @"Do you want to save the changes " &
    @"you made in the document “untitled”?", 
    @"Your changes will be lost if you don't save them."
    @"Save...", 
    @"Don't Save",
    @"Cancel")

The Missing Argument

NSRunAlertPanel() has one flaw, though: you cannot freely assign a default button, because the “default button,” “alternate button,” and “other button,” are defined by their position in the dialog box. As stated in the API reference on NSAlert:

For languages that read left to right, the buttons are laid out on the lower-right corner of the sheet or dialog, with defaultButton on the right, alternateButton on the left, and otherButton in the middle.

In other words, there is no option that would allow defining, say, the Cancel button as the default button, in case that confirming the action would cause a data loss, as in this dialog box:

Guilty As Charged

With regards to selecting an appropriate default, though, it shouldn’t be too much of a challenge for an experienced Cocoa programmer to write her own version of that function based on using the NSAlert class, if there is a need for assigning another default button than the right-most one. And, unaffected by that little flaw in NSRunAlertDialog(), providing appropriate, meaningful button labels is just as easy as providing the lesser “OK”/”Cancel” variety.

Now that we know the underlying technical details, we see that there is only a weak excuse for programmers to not define appropriate default buttons; and there is just no excuse whatsoever for using “Yes”/”No” or “OK”/”Cancel” buttons anywhere in a Cocoa application. Case closed. But, then again…

When “OK” is OK, After All

Is there really no use for an “OK” button? Well, there is one special case where labeling a button “OK” makes perfect sense.

In our daily “analog” lives, we use “OK” as a confirmation — in the sense of a “spoken check mark”– only, and not as an action verb, while “Cancel” is, indeed, an action verb in its own right: “Cancel my request!”, “Cancel that order!”

In that sense, when the user is presented with a dialog like the one about resetting Safari above, what the computer is actually “saying” is: “Here’s what happened. Now, what do you want me to do?” And, by clicking one of the buttons, the users replies “No, don’t reset anthing. Cancel that action!” or “Yup, go ahead. Reset the application!”

With informational dialogs, though, there is no alternative. All the user can do is confirm that she has seen that dialog box. In the example below, it’s like the computer’s “saying”: “I’ve finished your request. Here’s the result.” and the user just replies “OK, thanks for telling me.” without giving any instructions as to what the computer should do next.

As a matter of fact, using anything but “OK” in this case may even be misleading. What if the button label were “Dismiss” or “Close”? Without any reference to that action(!) in the dialog’s text, what will be dismissed or closed? If the dialog box in question was actually a sheet attached to a document window, will clicking the “Close” button close the document window?

“OK” is a much better choice here, as it does not imply triggering any action beyond closing the dialog box or sheet.

The Button, umh, Bottom Line

If developers made a clear distinction between action buttons — in dialogs where the user has a choice of options — and the “OK” button — if there’s only a single button in the dialog –, and chose an appropriate default button that prevented inadvertent data loss, dialog boxes would be just that little bit safer and easier to use. And it ain’t rocket science, either.

Share this: del.icio.us • Digg • reddit