Chapter 23 -- Unnecessary Message Boxes Are Pure Evil

Chapter 23

Unnecessary message boxes are a variation of unnecessary dialog boxes, but they are even more irritating and far more common. A simple way to turn a good interface into an unusable one is to ask the user to confirm every action he does. Unnecessary message boxes are pure evil.

Programs have unnecessary dialog boxes and unnecessary message boxes for significantly different reasons. Unnecessary dialog boxes are used primarily because the alternatives, such as direct manipulation, are fairly hard to implement. The alternative to unnecessary message boxes is often to do nothing at all, which is clearly easier. One of the reasons programmers create unnecessary message boxes is that they think they are doing the user a favor.

A good example of an unnecessary message box is one confirming a program exit. While it might seem like a good idea to make sure the user wants to exit the program, doing so is nothing but irritating. Such message boxes exist because programmers are afraid that users will exit the program accidentally and become upset that they have to reload the program to continue their work. Let's consider the benefit of this confirmation. Suppose I accidentally exit Microsoft Visual C++. On my computer, it takes about 10 seconds to load Visual C++ the first time but only about three seconds to reload it. Furthermore, Visual C++ is one of my slowest loading programs. Microsoft Internet Explorer takes about a second to reload.

Now let's consider the cost of this confirmation. The user has to read the message, think it over for a second (not having to think it over is a clear indication of a useless message), possibly move his hand from the keyboard to the mouse, move the mouse cursor to a message box button, click the button, and then resume his work. This whole process may take several seconds and completely disrupts the user's train of thought. This is why users hate unnecessary message boxes.

If you assume that the user correctly selects the exit command far more often than he incorrectly selects it, this is a very poor trade-off. A far better solution to this problem is to ask the user to save any unsaved work (which you should be doing anyway), save the current program state (which you should be doing anyway if that state is difficult to re-create), and exit the program without further user interaction. Instead of making it difficult to exit, a good program makes it easy to pick up where the user left off.



Developing User Interfaces for Microsoft Windows
Developing User Interfaces for Microsoft Windows
ISBN: 0735605866
EAN: 2147483647
Year: 2005
Pages: 334

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net