Tips

In the following sections, I'll offer miscellaneous tips that I hope will help you create good error messages.

Error Message Appearance

• Carefully select the right message box type Use the Warning message box with Yes, No, and possibly a Cancel button to ask a question or alert the user to a condition or situation that requires the user's input before proceeding. Use the Critical message box to inform the user of a problem that requires correction before work can continue.
• Do not use the Question message box type The question mark symbol (MB_ICONQUESTION) is no longer recommended for message boxes because it is now used consistently within Windows 98 to signify context-sensitive help.
• Ask questions with yes or no answers When asking the user a question, use the Yes and No buttons instead of the OK and Cancel buttons. Using these buttons make the question easier to understand. Unlike in dialog boxes, the OK and Cancel buttons are rarely used together in message boxes.
• Make sure the message box option buttons match the text For example, never give Yes and No as responses to nonquestions. Also, don't give multiple option buttons that have the same effect. For example, don't give both No and Cancel button options unless they have different results. The No button should perform the operation, whereas Cancel should cancel the operation.
• Carefully select the default button Make the safest or most frequent option the default button. For more information on selected default buttons, see Chapter 29, "Check Your Dialog Boxes"
• Avoid unhelpful help Don't provide a Help button unless you can provide additional information that really is helpful. Don't supplement a meaningless message box with meaningless help.
• Consider using system-modal message boxes for critical errors Use system-modal message boxes to notify the user of serious, potentially damaging errors that require immediate attention. A system-modal message box is the same as an application modal message box except that the message box has the WS_EX_TOPMOST style. Unlike in 16-bit Windows, being system modal has no effect on the user's ability to interact with other programs.

Error Message Text

• Establish high standards Try to establish high error message standards at the start of the project. If the early error messages are poorly written, it is easy to justify continuing to create new messages of poor quality.
• Avoid error numbers Never give error numbers unless the user can actually do something useful with the number.
• Avoid blaming the user Avoid using the words you or your in the error message text. If necessary, use the passive voice when referring to user actions. It's better to say the equivalent of "mistakes were made" than the equivalent of "you screwed up."
• Avoid offensive language Avoid violent terms such as fatal, execute, kill, terminate, and abort.
• Avoid hostile language Avoid using the terms bad, caution, error, fatal, illegal, invalid, and warning in the error message text. Try to use more specific, descriptive terms instead. Try to explain what exactly is wrong.
• Use plain English in the error message text Be brief, clear, consistent, and specific. Never use words with all uppercase letters unless the word is an acronym. This makes it look like you are shouting at the user. Use full sentences and the simple present or past tense. Avoid abbreviating words.
• Explain unusual meanings If the error message option buttons (that is, OK, Cancel, Yes, and No) have unusual meanings, explicitly describe those meanings in the text. For example:



• Avoid trying to be funny or clever in the error message text Users do not find error messages funny, and any attempt at humor will not be well received.

Presentation

• Consolidate error messages A single problem (for example, a bad network connection) should result in only a single error message. A good solution to this problem is to handle all errors at the highest level code, such as where the commands are handled, and have lower level routines detect problems but not report them.
• Report a single problem just once Don't report the same error over and over again.
• Allow the user to suppress noncritical error messages For noncritical errors that occur often, give the user an option to suppress the error message in the future.

Resources

• Use string resources The entire process of creating error messages is simplified if all error message text is in string resources.
• Consolidate error message resources Assign all error message resource IDs together so that they are easy to review.