UX Tip of the Week: Why Message Boxes Are Evil

I recently purchased a new hard disk. Eager to free up space on my crowded system drive, I dragged hundreds of files from their existing locations to the new drive. “67 Minutes Remaining,” Windows said. I went off to read a book (who am I kidding? I watched TV) while the computer did its thing.

An hour or so later, I went to check on the computer’s progress. I expected it to be almost finished, but instead I saw this:

 

Thanks, Windows!

Here’s why message boxes are evil and you should avoid them:

• They're modal. Message boxes put the program into a mode that must be dealt with before the program can return to its normal state and the user can continue with the task at hand.

• Users don’t read them.

If message boxes are such a bad idea, why do we continue to use them?

• They’re easy. Most programming languages allow you to create a message box with one line of code.
• They’re placeholders. “I’ll replace it with something better before we ship.” Right.
• Management insists. You want to do the right thing, but your manager tells you there’s no time in the schedule. “A message box is good enough!”
• They’re all we know. The program needs to communicate with the user. How is it supposed to do that if we don’t use a message box?

To answer that last question, let’s consider four contexts in which programmers commonly use message boxes:

Confirmations. Those infamous “Are you sure?” prompts. Confirmation dialogs are generally ineffective because they quickly become routine: the user learns that to perform some action (say, to delete an item), she must click the Delete button and then click “Yes” on the confirmation dialog. The one time in 100 she doesn’t intend to delete the item, her fingers are faster than her brain.

A better solution is to provide an undo function. Simply perform the action the user requests, then make it easy to reverse the action if she changes her mind.

Status updates. “I have successfully completed a task! Click OK if you’re proud of me.” It’s fine to keep the user informed as to your program’s status, but is it really necessary to make her pat you on the head?

As its name suggests, the status bar was invented for precisely this purpose. If you’re concerned that your users won’t notice status bar messages, please use a non-modal way to display your status. Here’s how Outlook does it:

Internet Explorer uses an animated Information Bar:

Google uses an ingenious method to display status and expose the undo option:

Options. “Do you want to do X?” When thinking about how a program should behave, I like to imagine it as my administrative assistant. If I ask my assistant to make a travel reservation, do I want him to interrupt me with every option: “Excuse, me, sir. Do you prefer a window or aisle seat? In the front, middle or back of the plane? Would you rather leave in the morning or the afternoon? Do you want to fly through Chicago, Denver or Minneapolis?” Of course not! I’d like my assistant to make educated guesses about my reservation, then present it to me for approval. If I make any changes, I’d like him to note my preference for next time.

Similarly, rather than displaying a message box for each option, software should use intelligent defaults. Choose default options that will satisfy most users, and offer a straightforward way for more advanced users to change them.

Errors. This is the context most likely to warrant a message box, but only if it tells the user precisely how to correct the problem (“Please insert a blank disc into drive E:”) or if the error is so severe that the program cannot continue.

If the user can’t do anything about the error, there’s no need to bother her with it; simply log it, perhaps notify the development team, and move on. If the error is caused by something the user did, such as entering invalid data, there are non-modal ways to tell her about it. The best solution is to help the user avoid making the mistake in the first place.

In future columns, I’ll discuss each of these situations in more detail and provide sample code demonstrating my suggestions. My hope is that someday, it will be as quick and easy to do the right thing as it is to use a message box!

Please feel free to subscribe to my Usability category to be notified when I publish new columns in this series.