[kde-guidelines] Styleguide: Notifications (Was: KStyleguide)

[David Edmundson]

Sorry for the incredibly late reply:

On Wed, Nov 27, 2013 at 2:56 PM, Heiko Tietze
<heiko.tietze at user-prompt.com> wrote:
> I applied the new structure and removed questionable items.
>
> User Assistance > System triggered notification
> * Use a notification as system-triggered message to acknowledge about events
> out of the current context.
>
> http://techbase.kde.org/Projects/Usability/HIG/Notifications
>
> == 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
> [[Projects/Usability/HIG/Tooltip|tool-tips]] for short information, or refer
> to [[Projects/Usability/HIG/HelpSystem|help system]] for extended text).
> * Do not use notifications for context relevant information that might
> interfere with the actual workflow (consider to use a
> [[Projects/Usability/HIG/Messages|message dialog]]).
>

++

Maybe a limit on the number of actions, the API allows you to set an
infinite amount. Anything more than 2 is rather silly.

> === Behavior ===
> * Notifications disappear after a short period automatically (unless the
> cursor hovers over them), but can be closed by the user at any point.
> * Stack multiple notifications vertically.
> * Provide access to the configuration for each notification per button next
> to the close button.
>
I don't think there is any need to this section.

There are two sides to notifications.
A client (the app sending notifications) and the server that displays them.

The client does not display the notification itself.

There are many many clients so we need to have guidelines, we don't
need to have guidelines on how the server works because there's only
one of them in Plasma. (well 2 if you count the frickin' awesome
Colibri)

It's also very possible that the KDE application is run from within
Gnome/Unity/Whatever where we do not have any knowledge of or power
over the notification server.

> === 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.").
>
++

>From looking at the API we want to explain one more thing:

 -  When (and when not) to use the Persistent flag
http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKNotification.html#ad9430ebe5109e91358334f6e20599774

Which matches up with your first point in "behaviour".

> == Implementation ==
>
> [[Category:Usability]][[Category:Behavior]][[Category:User_Assistance]][[Category:User-driven_assistance]]
>
>
> _______________________________________________
> kde-guidelines mailing list
> kde-guidelines at kde.org
> https://mail.kde.org/mailman/listinfo/kde-guidelines
>