Projects/Usability/HIG/Notifications: Difference between revisions

From KDE TechBase
< Projects‎ | Usability‎ | HIG
(Added guideline for persistent notifications)
(One intermediate revision by one other user not shown)
Line 14: Line 14:
=== Behavior ===
=== Behavior ===
* Notifications disappear automatically after a short period (unless the cursor hovers over them), but can be closed by the user at any point (KNotification::NotificationFlag == CloseOnTimeout).
* Notifications disappear automatically after a short period (unless the cursor hovers over them), but can be closed by the user at any point (KNotification::NotificationFlag == CloseOnTimeout).
* Stack multiple notifications vertically.
* A notification can be set as "persistent" which, under Plasma, makes it go into a notification queue where it stays for 10 minutes unless the user removes it actively use persistent notifications only to inform about events which are both '''very important''' and '''unexpected'''. For example, do ''not'' use a persistent notification to inform about a completed file transfer, but use one to inform about a failed transfer.
* Provide access to the configuration for each notification per button next to the close button.
* Do not add more than three actions to a particular notification. And take care about limited space for labels. For instance, ''Skip'', ''Info'', and ''Buy'' in case of Amarok's "Now playing" notification.
* Do not add more than three actions to a particular notification. And take care about limited space for labels. For instance, ''Skip'', ''Info'', and ''Buy'' in case of Amarok's "Now playing" notification.



Revision as of 14:57, 18 July 2016


Purpose

A notification is an information that is not directly relevant to the user's current task. It is displayed via a certain notification mechanism on a panel above/below the taskbar notification area. Notifications inform users about non-critical problems, but they don't prevent them.

Examples

Guidelines

Is this the right control

  • Use a notification to inform about a non-critical problem that is not directly relevant to the user's current task.
  • Do not use notifications for user assistance (consider to use tool-tips for short information, or refer to help system for extended text).
  • Do not use notifications for context relevant information that might interfere with the actual workflow (consider to use a message dialog).

Behavior

  • Notifications disappear automatically after a short period (unless the cursor hovers over them), but can be closed by the user at any point (KNotification::NotificationFlag == CloseOnTimeout).
  • A notification can be set as "persistent" which, under Plasma, makes it go into a notification queue where it stays for 10 minutes unless the user removes it actively use persistent notifications only to inform about events which are both very important and unexpected. For example, do not use a persistent notification to inform about a completed file transfer, but use one to inform about a failed transfer.
  • Do not add more than three actions to a particular notification. And take care about limited space for labels. For instance, Skip, Info, and Buy in case of Amarok's "Now playing" notification.

Appearance

  • Make sure to make the origin of the notification clear from the notification title. For instance: "Amarok: Now playing" or "Konsole: Event".
  • Keep the notification content concise (no more than about three simple sentences).
  • Provide actionable information (e.g. "Low battery power: Approximately 13 min (2%) capacity remaining.").

Implementation