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

< Projects‎ | Usability‎ | HIG
Jump to: navigation, search
(Added Implementation section)
(Guidelines)
(2 intermediate revisions by one 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 18: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


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