Be Specific

Make your error messages as specific as possible, even if this eliminates some unimportant options. For example, this error message is famous for causing technical support problems:

Why is this message a technical support problem? The problem is that many users call tech support to ask where the "Any Key" is. Since it doesn't matter which key the user presses, why not be specific and choose one?

On the other hand, don't be so specific that you eliminate important options. For example, consider the infamous critical error message in Microsoft Windows:

This is possibly the most hated error message ever created. Windows allows you to provide your own message for critical errors by calling the SetErrorMode API function with the SEM_FAILCRITICALERRORS parameter, which is automatically done in MFC but not when you are programming using the Windows API directly. One program handles the critical error with this error message:

Does this error message bother you? It certainly bothers me. While the Abort, Retry, and Ignore options are as awkward as they get, I can always abort the command and save my file elsewhere, such as another hard disk or a network drive. With the "improved" version, I no longer have this choice or, at least, I no longer appear to. What if I am using a laptop without a floppy drive? What if my file is too large to fit on a floppy disk? Now I have two options: I can lose my file, or I can lose my file. Definitely not cool! The real way to improve the critical error message is to present the specific options the user really has—which are to retry the save, select a path on another drive, or cancel the save—and to give these option in plain English:

TIP
Make the error message as specific as possible. There is no harm in eliminating unimportant options, but never eliminate important ones.

Being specific also means providing different error messages for the different causes of a problem. For example, if there are several reasons why a file cannot be saved or an object cannot be created, provide a specific message for each condition that the user can understand. (You don't need to give specific explanations that the user is not able to understand.) Avoid using generic, catchall error messages, since such error messages don't help the user understand the problem.

TIP
If an error can occur as the result of several conditions, provide a specific error message for each condition.

Lastly, try to provide the specific names and locations of the objects involved in an error. For example, once while I was trying to install a program on an old computer of mine, the setup program indicated that it couldn't install because it needed at least 8 MB of hard disk space. I was installing to the C: drive, so I checked that drive and, sure enough, I didn't have enough space. I freed some space and tried again but got the same error message. I freed 20 MB and tried yet again but still no luck. At this point, I was about to call technical support when I realized what the problem was. While I was installing to the C: drive on my old multidrive computer, my system folder was on my E: drive, which didn't have 8 MB free. Had the error message said that it was drive E: that needed at least 8 MB of hard disk space, there wouldn't have been a problem. Note how unhelpful the error message I received was and how easy it would have been to make it helpful by simply making it a bit more specific.



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