Https://community.kde.org/Get Involved/design/HCI/Checklists/ErrorMessages: Difference between revisions
(New page: == Warning and Error Messages == '''Language''' Warning dialogs should be: * '''Understandable'''. Clearly phrased messages, non-technical terms and no obscure error codes should not b...) |
m (Jucato moved page Https://community.kde.org/Get Involved/design/Development/Guidelines/HCI/Checklists/ErrorMessages to Https://community.kde.org/Get Involved/design/HCI/Checklists/ErrorMessages without leaving a redirect) |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{Proposed_move_to_community|Archive under HIG, old HCI}} | |||
== Warning and Error Messages == | == Warning and Error Messages == | ||
| Line 6: | Line 8: | ||
Warning dialogs should be: | Warning dialogs should be: | ||
* '''Understandable'''. Clearly phrased messages, | * '''Understandable'''. Clearly phrased messages, do not use technical terms or obscure error codes. | ||
* '''Specific instead of general.''' If the message is reporting a problem concerning a specific object or application, the object or application name should be used when referring to it. | * '''Specific instead of general.''' If the message is reporting a problem concerning a specific object or application, the object or application name should be used when referring to it. | ||
* '''Informative and constructive.''' The reason for a problem should be given, and hints how to solve it. | * '''Informative and constructive.''' The reason for a problem should be given, and hints on how to solve it. | ||
* '''Polite, non-terrifying and non-blaming.''' Wording that terrifies the user ("fatal", "illegal") shouldn't be used, users shouldn't be blamed for their behavior, | * '''Polite, non-terrifying and non-blaming.''' Wording that terrifies the user ("fatal", "illegal") shouldn't be used, users shouldn't be blamed for their behavior, the message should be polite. | ||
Latest revision as of 10:11, 16 May 2019
Template:Proposed move to community
Warning and Error Messages
Language
Warning dialogs should be:
- Understandable. Clearly phrased messages, do not use technical terms or obscure error codes.
- Specific instead of general. If the message is reporting a problem concerning a specific object or application, the object or application name should be used when referring to it.
- Informative and constructive. The reason for a problem should be given, and hints on how to solve it.
- Polite, non-terrifying and non-blaming. Wording that terrifies the user ("fatal", "illegal") shouldn't be used, users shouldn't be blamed for their behavior, the message should be polite.
Confirmation buttons
- When the user has the choice between two options, descriptive labels should be used instead of yes/no buttons.
- When the message does not require further user input, the confirmation button should be labeled "Close" (instead of "OK").
Details on demand
- If there are more than three sentences of explanation, they should be provided in a "Details" section. In the dialog, there should be only a short message.
- Error codes and other technical information should be provided in a "Details" section.
Info panels
- panels instead of dialogs may be used to display non-critical messages which do not require any further user interaction (typically dialogs with a single "OK" or "Close" button).
For examples, see Examples