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

< Projects‎ | Usability‎ | HIG
Jump to: navigation, search
(Added Implementation section)
(Guidelines)
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Introduction ==
+
__NOTOC__
  
Messages include warnings, error messages, confirmation dialogs, and info messages.
+
== Purpose ==
 +
If the processing has reached an unexpected condition that needs interaction, a disruptive message alerts the user of a problem. Not any disruptive message concerns a serious problem. Sometimes, the user is just notified that proceeding is dangerous. A typical example is the “Save changes before closing?” alert box that appears when a user tries to close a module with modified content. The adequate presentation method for disruptive information is a ''modal message dialog''.
  
== Language ==
+
A modal dialog is a secondary window that interrupts user's current activity and blocks interaction until user either simply acknowledge the information by clicking Ok or decides how to proceed (e.g. Yes/No). Effective error messages inform users that a problem occurred, explain why it happened, and provide a solution so users can fix the problem. Users should either perform an action or change their behavior as the result of an error message.
 +
Modal dialogs are error-prone. An alert dialog that appears unexpectedly or which is dismissed automatically (because the user has developed a habit) will not protect from the dangerous action.
  
Messages should be:
+
== Examples ==
* ''Understandable''. Phrase your messages clearly, in non-technical terms and avoid obscure error codes.
+
* ''Readable'' — user has to be able to read the message in his/her own pace, think about it, understand it. Adding countdown timers (visible or not) and forcing user to read&understand the message in X seconds is not acceptable,
+
* ''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 ==
+
== Guidelines ==
When no further input is required:
+
* Avoid disruptive messages; workflow maintenance and, therefore, the prevention of errors should be the primary objective.
* 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 modal dialogs only for critical or infrequent, one-off tasks that require completion before continuing. Don’t use modal error message dialogs at the normal work flow to inform or warn the user.
 
+
* Use [[Projects/Usability/HIG/MessageWidget|message panel]] for non-critical messages which do not require any further user interaction (typically dialogs with a single "OK" or "Close" button).
When further interaction is required:
+
* Create specific, actionable, user-centered error messages. Users should either perform an action or change their behavior as the result of the message.
* 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".
+
 
+
== 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.
+
=== Dialogs in general ===
 +
* Don’t apply dialog boxes that require the use of a scroll bar.
 +
* Don’t include a menu bar or status bar in dialogs.
 +
* Don’t display more than one owned choice dialog at a time from an owner choice dialog.  
  
== Dialog vs. Info Panel ==
+
=== Language ===
* Use dialogs for critical error messages, and when you need to make sure that the user sees the message.
+
Messages should be:
 +
* Informative and constructive:
 +
** Tell the user the reason for a problem and
 +
** help on how to solve the problem.
 +
* Understandable:
 +
** Phrase your messages clearly, in non-technical terms and avoid obscure error codes.
 +
* Readable:
 +
** User has to be able to read the message in his/her own pace, think about it, understand it.
 +
** It is not acceptable to add countdown timers (visible or not) or to force user to read and understand the message within a few seconds.
 +
* 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.
 +
* Polite, non-terrifying and non-blaming:
 +
** Avoid wording that terrifies the user ("fatal", "illegal"), blames him for his behavior, and be polite.
  
* Use info panels for non-critical messages which do not require any further user interaction (typically dialogs with a single "OK" or "Close" button).
+
=== Confirmation Button Labels ===
 +
* When no further input is required:
 +
** 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.
 +
* When further interaction is required:
 +
** 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".
  
 
== Implementation ==
 
== Implementation ==
 
* [http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKMessageBox.html KMessageBox]
 
* [http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKMessageBox.html KMessageBox]

Revision as of 17:53, 9 July 2013


Purpose

If the processing has reached an unexpected condition that needs interaction, a disruptive message alerts the user of a problem. Not any disruptive message concerns a serious problem. Sometimes, the user is just notified that proceeding is dangerous. A typical example is the “Save changes before closing?” alert box that appears when a user tries to close a module with modified content. The adequate presentation method for disruptive information is a modal message dialog.

A modal dialog is a secondary window that interrupts user's current activity and blocks interaction until user either simply acknowledge the information by clicking Ok or decides how to proceed (e.g. Yes/No). Effective error messages inform users that a problem occurred, explain why it happened, and provide a solution so users can fix the problem. Users should either perform an action or change their behavior as the result of an error message. Modal dialogs are error-prone. An alert dialog that appears unexpectedly or which is dismissed automatically (because the user has developed a habit) will not protect from the dangerous action.

Examples

Guidelines

  • Avoid disruptive messages; workflow maintenance and, therefore, the prevention of errors should be the primary objective.
  • Use modal dialogs only for critical or infrequent, one-off tasks that require completion before continuing. Don’t use modal error message dialogs at the normal work flow to inform or warn the user.
  • Use message panel for non-critical messages which do not require any further user interaction (typically dialogs with a single "OK" or "Close" button).
  • Create specific, actionable, user-centered error messages. Users should either perform an action or change their behavior as the result of the message.
  • Provide only a short error message and complement it by a Details button that provides more a detailed explanation in the same error dialog.

Dialogs in general

  • Don’t apply dialog boxes that require the use of a scroll bar.
  • Don’t include a menu bar or status bar in dialogs.
  • Don’t display more than one owned choice dialog at a time from an owner choice dialog.

Language

Messages should be:

  • Informative and constructive:
    • Tell the user the reason for a problem and
    • help on how to solve the problem.
  • Understandable:
    • Phrase your messages clearly, in non-technical terms and avoid obscure error codes.
  • Readable:
    • User has to be able to read the message in his/her own pace, think about it, understand it.
    • It is not acceptable to add countdown timers (visible or not) or to force user to read and understand the message within a few seconds.
  • 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.
  • 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

  • When no further input is required:
    • 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.
  • When further interaction is required:
    • 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".

Implementation


Content is available under Creative Commons License SA 4.0 unless otherwise noted.