[Usability]Notification Area guidelines

[Mark McLoughlin <mark skynet ie>]

Hi,
	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
these guidelines.

	Anyway, my notes are below.

Good Luck,
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
	  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
	  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 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
discussion.

 Suggested:

	+ 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
	  containing:
	    o A "Remove Icon" option - see below.
	    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.

	+ 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.

	+ 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.

	+ 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.

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