Guidelines for System Tray icons
Mark McLoughlin <[email protected]> 13 Mar 2003 14:59:53 +1300
| Newsgroups | gmane.linux.xdg.devel,gmane.comp.hci.open |
|---|---|
| Message-ID | <[email protected]> |
Hi all,
We've been discussing some guidelines on the GNOME lists for System
Tray icons in an effort to build consistency. The discussion has
included details like "should single-clicking or double-clicking present
a the interface" and higher level discussions about exactly which types
of systray entries are a good idea.
I'd really like to continue some of the discussion here and get a feel
for whether or not a general agreement on a cross-desktop set of
guidelines could be reached.
From reading the KDE guidelines, one difference in opinion that is
obvious is that in GNOME we're tending towards the idea that an
application should always quit once you've closed all windows - it
should never remain "loaded" in the systray as this overloads the
meaning of the close window button and leads to a confusion over what
the button does.
I've appended my notes on our discussion so far (apologies for the
difference in terminologies - GNOME seems to have gone with
"Notification Area" instead of "System Tray").
Anyway, comments very welcome.
Thanks,
Mark
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[1].
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.
Teminology
==========
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"
section[2].
For the moment lets assume the following terms:
Notification Area:
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.
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.
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
current application "status", e.g. the number of unread
emails, and applications which display a new icon when the
application "status" changes, e.g. new mail arrived.
Applications generally wouldn't do both - i.e. in the
example above if you want to display an icon with the number
of unread mails the arrival of a new mail would be indicated
by the icon blinking and/or a balloon message.
+ Status monitors as described above.
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
itself.
+ 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[2].
+ 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
discussion.
Suggested:
+ Only icons or combinations an icon and a small label (e.g.
percentge battery remaining) should be in the Notification
Area. No buttons, toggles etc.
+ Single-clicking on the icon or pressing Enter/Space when the
icon has focus (this of course requires that the icons are
focusable) 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 as well as displaying an alert.
+ Right click or Shift-F10 should display a context
containing:
o A "Remove Icon" option - this should basically be a
shortcut for an applications "show status in the
notification area" preference.
o A "Preferences" option if the icon behaviour may be
customized.
+ Icon's should have tooltips with a short summary of the
icon status.
+ If the notification area goes away, the icon should be
re-displayed when a new notification area appears.
Discussion:
+ We need guidelines on what else applications should put in
the popup menu.
+ The icon blinking should time out. After how long?
+ Need guidelines for the types of information balloon
messages should contain. Also need a recommended timeout for
balloon messages.
Related Links
=============
[1] The System Tray specification:
http://www.freedesktop.org/standards/systemtray.html
[2] The Documentation Style Guide's "Recommended Terminology" section:
http://developer.gnome.org/documents/style-guide/wordlist.html
[3] KDE systray guidelines:
http://developer.kde.org/documentation/standards/kde/style/basics/systray.html
[4] Some information about providing status icons for the Windows
status area:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_int/shell_int_programming/taskbar.asp