Attributes of a Good Error Message

A good error message has a surprising number of attributes. The most important attribute is that the error message must be necessary. The best error message is no error message at all. Your first choice should always be to prevent the problem in the first place. Your second choice should be to try to work around the problem without bothering the user. A good third choice is to notify the user in a way that doesn't require the user to respond, such as putting information on the status bar. See Chapter 23, "Unnecessary Message Boxes Are Pure Evil" for a detailed discussion of avoiding unnecessary error message boxes.

An error message must provide enough information so that the user can understand the problem and know what to do about it. Typically this means that the error message needs to provide:

• A notification The user needs to know that a problem occurred.
• An explanation The user needs to know why the problem occurred.
• A solution The user needs to know how to solve the problem.

Providing this information makes error messages complete and self-explanatory. However, providing all of this information does not necessarily mean that a good error message is long and involved. If you can present the user with the information in a single short sentence, by all means do so. Users don't want to read long error messages. Rather, the error message should be:

• Brief Make the message as short as possible but no shorter. Use progressive disclosure when necessary (as described later).
• Clear Make sure that the user can understand the message. Use plain language and terminology that your target user understands. Avoid meaningless error numbers and technical mumbo jumbo.
• Consistent Make sure that error messages within the program are consistent and their terminology is consistent with the rest of the user interface.
• Specific Vague wording is a common problem in error messages. Give the specific names and locations of the objects involved in the error.