Revision as of 15:59, 17 June 2008

Warning and Error Messages

Warning and error messages appear when a problem or error has occurred.

Warning and error messages should be:

Understandable. Phrase your messages clearly, in non-technical terms and avoid obscure error codes.
Specific instead of general. If the message is reporting a problem concerning a specific object or application, use the object or application name when referring to it.
Informative and constructive. Tell the user the reason for a problem and help on how to solve the problem.
Polite, non-terrifying and non-blaming. Avoid wording that terrifies the user ("fatal", "illegal"), blames him for his behavior, and be polite.

Confirmation Button Labels

To close a warning or error message that does not require further user interaction, provide a Close button. Do not use an OK button. Users may get confused if they are asked to confirm an error.
Use buttons which match the type of statement or question made in the warning or error message. For example, do no ask a Yes/No question but then provide OK/Cancel buttons.
When the user must choose between two actions to continue, use descriptive button labels instead of standard Yes/No or OK/Cancel buttons. For example, if the user must choose to continue or stop an action, provide the buttons "Continue" and "Cancel".

Error Details

Provide only a short error message and complement it by a Details button that provides more a detailed explanation in the same error dialog.
If it makes sense for this kind of error, link from the error dialog to the corresponding page in the help system. Provide a Help button then.

Dialog vs. Info Panel

Use dialogs for critical error messages, and when you need to make sure that the user sees the message.
Use info panels for non-critical messages which do not require any further user interaction (typically dialogs with a single "OK" or "Close" button).

@@ Line 4: / Line 4: @@
 Warning and error messages appear when a problem or error has occurred.
-''Language''
+Warning and error messages should be:
+* ''Understandable''. Phrase your messages clearly, in non-technical terms and avoid obscure error codes.
+* ''Specific instead of general''. If the message is reporting a problem concerning a specific object or application, use the object or application name when referring to it.
+* ''Informative and constructive''. Tell the user the reason for a problem and help on how to solve the problem.
+* ''Polite, non-terrifying and non-blaming''. Avoid wording that terrifies the user ("fatal", "illegal"), blames him for his behavior, and be polite.
-Warning dialogs should be:
-* Understandable: Phrase your messages clearly, in non-technical terms and avoid obscure error codes.
-* Specific instead of general: If the message is reporting a problem concerning a specific object or application, use the object or application name when referring to it.
-* Informative and constructive: Tell the user the reason for a problem and help on how to solve the problem.
-* Polite, non-terrifying and non-blaming: Avoid wording that terrifies the user ("fatal", "illegal"), blames him for his behavior, and be polite.
+'''Confirmation Button Labels'''
-''Confirmation buttons''
 * To close a warning or error message that does not require further user interaction, provide a Close button. '''Do not use an OK button.''' Users may get confused if they are asked to confirm an error.
 * Use buttons which match the type of statement or question made in the warning or error message.  For example, do no ask a Yes/No question but then provide OK/Cancel buttons.
@@ Line 19: / Line 17: @@
-''Details on demand''
+'''Error Details'''
 * Provide only a short error message and complement it by a Details button that provides more a detailed explanation in the same error dialog.
 * If it makes sense for this kind of error, link from the error dialog to the corresponding page in the help system. Provide a Help button then.
-''Which widget to use''
+'''Dialog vs. Info Panel'''
 * Use dialogs for critical error messages, and when you need to make sure that the user sees the message.
 *  Use info panels for non-critical messages which do not require any further user interaction (typically dialogs with a single "OK" or "Close" button).