From KDE-HIG_Wiki

Warning and Error Messages

Warning and error messages pop up when a problem or error occurred.

Guidelines

Language

Warning dialogs 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 give hints how to solve it.
• Polite, non-terrifying and non-blaming:
  Avoid wording that terrifies the user ("fatal", "illegal"), blames him for his behavior, and be polite.

Confirmation buttons

• 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 sometimes get confused if they are to confirm an error.
• When the user has to choose between two actions, use descriptive button labels instead of Yes and No buttons. For example, if the user has the choice to continue or stop an action, provide the buttons "Continue" and "Cancel".

Details on demand

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

Choosing the right widget

Sample Info Panel

• Use dialogs for critical error messages, and when you need to make sure that the user sees the message.
• Use info panels to display non-critical messages which do not require any further user interaction (typically dialogs with a single "OK" or "Close" button).

Examples

Insufficient Permissions

In this example, the user tried to copy a folder named "warning" to the root directory. The following error message was given:

"Access denied to /warnings"

Make it

• less terrifying by avoiding the term "denied",
• more specific by referring to the action in question,
• more informative by explaining the reason for the denial of access,
• more constructive by linking to the help pages about "Permissions",
• more polite by using "Please".

"You do not have the permissions to copy to the Root folder. Please check your permissions."

File Type not Supported

Here, a user tried to open an unsupported file type:

"Could not open file Reason: Parsing error"

While a reason was given, it is of little help for the user ("Parsing error"). Make the message

• more specific by referring to the file,
• more informative by using the user's language,
• more constructive by offering alternatives (if known).

"Could not open home/me/picture.kra. Gwenview cannot open files of this type. Use Krita instead."

Implementation Suggestions

Accessibility Notes

See Also

Related To

Keywords