Re: [Usability]Notification Area guidelines

[Rodney Dawes <dobey free fr>]

I definately agree that we need some kind of standardization. Rather
than having this in the HIG though, it may make sense to include it as
an addendum/extension to the System Tray Spec, as this is something that
affects cross-desktop applications, rather than just GNOME. Doing so
would help GNOME docklets look better in KDE, and vice versa. Anyway,
extraneous thoughts follow below. :)

On Tue, 2003-03-11 at 17:59, Mark McLoughlin wrote:
>   Status Icon:
> 
> 	This is a window embedded in the Notification Area. This need
> not neccessarily be an icon (any window may be embedded) so, depending
> on the guidlines agreed upon, this term may cover any widget (or group
> of widgets) docked in the Notification Area by an application.
> 
>   Status Monitor:
> 
> 	An application whose sole function is to monitor some system
> or global level activity and display status on this activity in the
> Notification Area. E.g. a battery power or weather monitor.

Why should these two be referred to as separate things? To the user,
they do the same, which is provide a simple status icon in the tray.
The only difference is the underlying backend code. The behavioural
differences are very minor.

> Defining the Use Cases
> ======================
> 
> 	There are many different ways in which application developers
> can make use of the Notification Area. However, in the interests of
> not having the Notification Area cluttered with many static icons we
> should try and the recommended use cases.
> 
>   Some cases which make sense:
> 
> 	+ Applications which display an icon to inform the user of
> 	  some change in the application's "status". E.g. a new mail
> 	  arrives, or a new instant message has arrived. Some
> 	  applications may remove the icon again for some transient
> 	  status (e.g. when there are no unread messages), whereas
> 	  others may always display an icon where the current status
> 	  is always of interest.
> 
> 	+ Status monitors.

Again, there is no real difference here in terms of UI.

> 	+ An application adds an icon to the tray when it starts. The
> 	  only "status" the icon shows is that the application is
> 	  currently running and the main purpose of the icon is
> 	  essentially to provide a shortcut to various application
> 	  operations without switching back to the application
> 	  itself.

This may make sense in a very small amount of use cases. I wouldn't
throw the things out entirely which may be useful in a very minute
number of cases.

> 	+ Some particularily large applications that take a long time
> 	  to load may not actually quit when all its windows are
> 	  closed and the Notification Area essentially provides a way
> 	  for these applications to remain "loaded". The icon would
> 	  not display any status other than that the application is
> 	  running and you can make the application quit by removing
> 	  the icon. The popup menu may also provide shortcuts to
> 	  application level operations e.g. "New Document".

This is just wrong. Nothing should do that, that is evil.

> 	Both of these sound like cases where custom applets would be
> more suitable. However, both of these cases seem to be recommended by
> the KDE guidelines[2].

Custom applets are really annoying usually. It is even very annoying
that the Notification Area is an applet, as the alignment on the panel
doesn't affect the resizing when icons are added/removed. The
notification area is also something that should really just *always*
be on the panel. As with sounds, it should also be said that the
notification area is not the *only* way you should notify users of
important events. Doing so is bad UI. If the event is extremely
important, it is probably best to also create a modal dialog, or
the like, to notify the user, as well as play an emergency sound of
some sort (not the "oh my god you are going to die if you don't do this
right now" kind like the breaking glass sound in gnome-audio though).

>   A debatable case:
> 
> 	+ A daemon or background process which performs some function.
> 	  The icon may or may not actually display some "status"
> 	  related to the daemon other than the fact that the daemon is
> 	  running.  Clicking on the icon provides a dialog by which
> 	  the daemon's behaviour can be configured.
> 
> 	In this case the Notification Area may be the only way of
> letting the user know the background process is running.  However,
> this may be indicative of a design problem with the application. If
> the daemon should always be running, the user should not need to have
> to check this. If the user regularily wants to stop/start this service
> maybe it should not be a background process at all.

Rather than having an icon always existing when the daemon/bg process is
running, it is usually best to provide notification to the user when it
*stops* running or some other error occurs. I think you're "debate" of
thise case makes perfect sense. If a constantly running process that is
in the background needs to notify the user of something, then it should,
otherwise it should leave the user alone.

> Defining the Behaviour
> ======================
> 
> 	The behaviour of status icons should be closely defined in the
> HIG. See http://bugzilla.gnome.org/show_bug.cgi?id=99175 for some
> discussion.
> 
>  Suggested:
> 
> 	+ Only icons or labels or a combination of both should be in
> 	  the Notification Area. No buttons, toggles etc.

I'd suggest that labels shouldn't go here either. The Notification Area
should be for a *minimal* amount of necessary notification, with as much
affect as you can get out of it. If your status icon needs text beside
it to display anything useful, and the tooltip isn't enough, it probably
should not be an icon in the status tray.

> 	+ Single-clicking on the icon or pressing Enter/Space when the
> 	  icon has focus should present a dialog with further
> 	  information on the status currently displayed. The dialog
> 	  may optionally also the user to control the status.

Are the individual icons in the tray focusable? They don't seem to be to
me. If they are supposed to be, this is probably a bug in the applet. I
don't understand your last sentence here, it is incomplete.

> 	+ An icon may blink to indicate some change in status which
> 	  not caused by a user action. E.g. the arrival of a new email.
> 	  Where appropriate, an icon may also blink to indicate an
> 	  error condition instead of displaying an alert.

I would say s/instead of/along with/ depending on the severity of the
error. It is best to notify the user of errors and other things in
multiple ways. IE, people that are hard of hearing typically need more
visual notification, while people who are hard of seeing (or those of
us hackers who typically have their eyes on code rather than everything
else in the desktop), might appreciate some audible notification a
little better. Notification should be suitable for all users, as it is
typically something important. If it's not important, you shouldn't be
bothering the user with your problems.

> 	+ Right click or Shift-F10 should display a context
> 	  containing:
> 	    o A "Remove Icon" option - see below.
> 	    o A "Preferences" option if the icon behaviour may be
> 	      customized.

These seem to assume that the status icon is a separate process from
the main application process, which is typically not true. Otherwise
it seems that you would like to enforce a "display status icon" option
for all the applications that use the status tray. The best solution is
to avoid having docklets for things that don't belong there. If you are
using an application, and don't want the status icon for it in the tray,
you probably don't want the tray on your panel, and won't have it anyway
(or the application sucks and is doing status notification in a horrible
manner). If your status icon needs preferences for the status icon
itself, then you are doing something wrong. A "Preferences" option in
the right click menu to load the application's preferences, makes sense.
If you have a status icon with preferences for the behaviour of the
icon, then it probably shouldn't be an icon, but maybe an applet (or an
application), instead.

> 	+ Icon's should have tooltips with a short summary of the
> 	  icon status.

Agreed. A textual representation of the status belongs in a tooltip.

> 	+ If the notification area goes away, the icon should be
> 	  re-displayed when a new notification area appears.

This needs to be automated in the implementation of the tray stuff
somehow. It is a pain in the ass to do this correctly, and shouldn't
require extra app-specific code. It would be better if rather than
destroying the "tray icons", it would just unembed them somehow, so
that they are still resident but not visible.

>  Discussion:
> 
> 	+ We need guidelines on what else applications should put in
> 	  the popup menu.

It should be a simple context menu for the application. For example, in
an IM client, change of status, preferences, and a quick way to signoff
or exit the application makes sense. This really depends on the app that
is being thrown in the status tray.

> 	+ Simple labels beside icons sound like a good idea under
> 	  certain circumstances where an icon cannot clearly convey
> 	  the status in enough detail - e.g. percentage battery power
> 	  remaining.

Again... if it needs text to display the status, it should probably be
an applet or some kind of desktop status thing instead. The status tray
should be minimal. For battery status, people typically want to know
from a quick glance if it's on AC power, charged, charging, or an
approximation of the amount of battery life. For an exact percentage, a
tooltip should contain that info. I really think we should keep text
out of the status tray if at all possible. Perhaps setting a standard
for the maximum width/height of the icon area for each icon.

> 	+ Should single-click or double-click activate the icon?
> 	  KDE uses single-click, Windows recommends single-click
> 	  popping up the dialog and double-click invoking the default
> 	  popup menu action[3].
> 
> 	  An argument for single-click might be that forcing a user to
> 	  double click when single-click serves no other useful
> 	  purpose is just making life unneccessarily harder.

The way windows does it seems to be the best way to do this. It really
depends on if we want win32/kde or osx style tray icons. In osx, the
tray icon widget behaves somewhat like a menuitem. I kind of like the
windows way better, but it wouldn't be hard to do it the osx way either.

> 	+ Should the icon blinking time out? After how long?

I would say that rather than "time out", it would just blink for N
seconds, and if no action has been taken, a still status icon displaying
something relevent to what the blinking was for, should be used.  For
instance, if you receive a new IM, you may want to blink between the
user's availability status and an icon to represent a message, and after
a number of seconds, just keep the icon set to the message icon.

> 	+ When/why should balloon messages be used? What types of
> 	  information should they contain?

Examples would be "Foo has logged on to Jabber", "New Mail From: Foo",
etc... It should contain quick notification messages relevent to the
application using them. You may want to pop up balloon messages to
tell the user that the battery is fully charged, or is getting low, or
to remind them that should take a typing break soon.

> 	+ Balloon messages should always have a timeout. Need to
> 	  define the timeout length.

Definately.


-- dobey