Jump to content

Https://community.kde.org/Get Involved/design/HCI/Checklists/ErrorMessages: Difference between revisions

From KDE Community Wiki
New page: == Warning and Error Messages == '''Language''' Warning dialogs should be: * '''Understandable'''. Clearly phrased messages, non-technical terms and no obscure error codes should not b...
 
*>Predator106
grammatical fixes
Line 6: Line 6:
Warning dialogs should be:
Warning dialogs should be:


* '''Understandable'''. Clearly phrased messages, non-technical terms and no obscure error codes should not be used.
* '''Understandable'''. Clearly phrased messages, do not use technical terms or obscure error codes.


* '''Specific instead of general.''' If the message is reporting a problem concerning a specific object or application, the object or application name should be used when referring to it.
* '''Specific instead of general.''' If the message is reporting a problem concerning a specific object or application, the object or application name should be used when referring to it.


* '''Informative and constructive.''' The reason for a problem should be given, and hints how to solve it.
* '''Informative and constructive.''' The reason for a problem should be given, and hints on how to solve it.


* '''Polite, non-terrifying and non-blaming.''' Wording that terrifies the user ("fatal", "illegal") shouldn't be used, users shouldn't be blamed for their behavior, and the message should be polite.  
* '''Polite, non-terrifying and non-blaming.''' Wording that terrifies the user ("fatal", "illegal") shouldn't be used, users shouldn't be blamed for their behavior, the message should be polite.  





Revision as of 16:38, 10 January 2009

Warning and Error Messages

Language

Warning dialogs should be:

  • Understandable. Clearly phrased messages, do not use technical terms or obscure error codes.
  • Specific instead of general. If the message is reporting a problem concerning a specific object or application, the object or application name should be used when referring to it.
  • Informative and constructive. The reason for a problem should be given, and hints on how to solve it.
  • Polite, non-terrifying and non-blaming. Wording that terrifies the user ("fatal", "illegal") shouldn't be used, users shouldn't be blamed for their behavior, the message should be polite.


Confirmation buttons

  • When the user has the choice between two options, descriptive labels should be used instead of yes/no buttons.
  • When the message does not require further user input, the confirmation button should be labeled "Close" (instead of "OK").


Details on demand

  • If there are more than three sentences of explanation, they should be provided in a "Details" section. In the dialog, there should be only a short message.
  • Error codes and other technical information should be provided in a "Details" section.


Info panels

  • panels instead of dialogs may be used to display non-critical messages which do not require any further user interaction (typically dialogs with a single "OK" or "Close" button).


For examples, see Examples