Projects/Usability/HIG/Messages: Difference between revisions

    From KDE TechBase
    < Projects‎ | Usability‎ | HIG
    (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...)
     
    (12 intermediate revisions by 5 users not shown)
    Line 1: Line 1:
    __NOTOC__
    __NOTOC__
    =Warning and Error Messages=


    Warning and error messages appear when a problem or error has occurred.
    == 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.


    Warning dialogs should be:
    == Examples ==
    * 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.


    == 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 [[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).
    * 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.


    ''Confirmation buttons''
    === Dialogs in general ===
    * 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.
    * Don’t apply dialog boxes that require the use of a scroll bar.
    * 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.
    * Don’t include a menu bar or status bar in dialogs.
    * 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".
    * 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.


    ''Details on demand''
    === Confirmation Button Labels ===
    * Provide only a short error message and complement it by a Details button that provides more a detailed explanation in the same error dialog.
    * When no further input is required:
    * 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.
    ** 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".


    ''Which widget to use''
    == Implementation ==
    * Use dialogs for critical error messages, and when you need to make sure that the user sees the message.
    * [http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKMessageBox.html KMessageBox]
    *  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 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