Projects/Usability/HIG/Messages

    From KDE TechBase
    < Projects‎ | Usability‎ | HIG
    Revision as of 15:39, 1 August 2008 by Seele (talk | contribs)
    The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

    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).