[Usability]Notification Area guidelines
- From: Mark McLoughlin <mark skynet ie>
- To: usability gnome org, desktop-devel-list gnome org
- Subject: [Usability]Notification Area guidelines
- Date: 12 Mar 2003 11:59:31 +1300
Erwann and I recently worked hacked together a prototype Network Status
Monitor which displayed an icon in the notification area somewhat
similar to the same thing in windows. I found both the lack of
guidelines and the fact that EggTrayIcon is just generic docking widget
to be really unhelpful.
So, I've taken some time to write down how these icons should behave.
I'd like to discuss these and hopefully get some conclusions into the
HIG sometime soon. Once we have come to some sort of an agreement on the
behaviour I want to extend EggTrayIcon to make it an implementation of
Anyway, my notes are below.
Improving the Notification Area
The Notification Area provides an area on the screen which
applications may use to display some status information in an
unobstrusive manner. The mechanism by which the application may dock
an icon into the Notification Area is described in the freedesktop.org
System Tray specification.
By conforming to the System Tray specification tray icons
provided by GNOME applications are guaranteed to work correctly under
KDE and vice versa. However, in the specification there is no
definition of what a tray icon is or how it should behave.
Applications are free to embed any UI element in the tray and
implement virtually any behaviour.
In the interests of consistent operation it would be desirable
to define a guidelines on what applications should make use of the
notification area and how each tray icon should behave. Furthermore,
in the interests of ease of development, an API which makes
implementing this common behaviour should be provided.
The terminology relating to the Notification Area is a bit
confused and several different terms are commonly used to vaguely mean
the same thing. For the sake of consitency in the UI and documentation
its very important that that this terminology is agreed upon and
defined in Documentation Style Guide's "Recommended Terminology"
For the moment lets assume the following terms:
This is the current name for the applet which implements the
System Tray specification and was previously called the System Tray.
Depending on the discussion below, not all use cases are neccessarily
about "notification" the term may be a little misleading.
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.
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.
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.
Both of these cases make important status information
available to the user at a glance.
Some cases which don't:
+ 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
+ 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".
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.
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.
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
+ Only icons or labels or a combination of both should be in
the Notification Area. No buttons, toggles etc.
+ 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.
+ 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.
+ Right click or Shift-F10 should display a context
o A "Remove Icon" option - see below.
o A "Preferences" option if the icon behaviour may be
+ Icon's should have tooltips with a short summary of the
+ If the notification area goes away, the icon should be
re-displayed when a new notification area appears.
+ We need guidelines on what else applications should put in
the popup menu.
+ 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
+ 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.
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.
+ Should the icon blinking time out? After how long?
+ When/why should balloon messages be used? What types of
information should they contain?
+ Balloon messages should always have a timeout. Need to
define the timeout length.
 The System Tray specification:
 The Documentation Style Guide's "Recommended Terminology" section:
 KDE systray guidelines:
 Some information about providing status icons for the Windows
] [Thread Prev