Projects/Usability/HIG/Messages

From KDE TechBase
< Projects‎ | Usability‎ | HIG
Revision as of 15:30, 27 June 2013 by Agateau (talk | contribs) (Added Implementation section)
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.

Introduction

Messages include warnings, error messages, confirmation dialogs, and info messages.

Language

Messages should be:

  • 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

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

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

Implementation