Difference between revisions of "Projects/Usability/HIG/Messages"

< Projects‎ | Usability‎ | HIG
Jump to: navigation, search
(New page: __NOTOC__ =Warning and Error Messages= Warning and error messages appear when a problem or error has occurred. ''Language'' Warning dialogs should be: * Understandable: Phrase your mess...)
 
(Warning and Error Messages)
Line 4: Line 4:
 
Warning and error messages appear when a problem or error has occurred.
 
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.
 
* 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.
 
* 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.
 
* 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.
 
* 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 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).
 
*  Use info panels for non-critical messages which do not require any further user interaction (typically dialogs with a single "OK" or "Close" button).

Revision as of 16: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).

KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal