Re: [Usability]Re: Notification area (was: Music player UI)

[Mark McLoughlin <mark skynet ie>]

Hey,

On Mon, 2003-02-24 at 15:21, Sean Middleditch wrote:
> On Sun, 2003-02-23 at 19:46, Jeff Waugh wrote:

> Consistancy is also definitely something not done correctly atm.  Some
> notification icons open a window when clicked.  Of those, only some hide
> the window when clicked again.  Some offer context-menues, others
> don't.  That definitely needs to be a part of afore-mentioned policy.

	I'm going to work on getting this policy defined and expanding the API
to make conforming to the policy a lot easier along with some other
notification area improvements. Just not right now - maybe in a week or
two.

	I've attached a short doc on my thoughts from first looking at it -
there's probably not too much point in discussing whats in it yet as I
haven't researched it fully - I just want to make sure there isn't
someone else duplicating the effort ...

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 common behaviour. Furthermore, in the interests of ease of
development, an API which makes implementing this common behaviour
should be provided.

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 should be in the Notification Area. No buttons,
	  labels 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 The default action.
	    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.

 Further questions:

	+ Should simple labels beside an icon be allowed?

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

	+ Should the icon blinking time out?

	+ 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 KDE guidelines[2] suggest that the tray should be used
	  as a method by which applications area "loaded". i.e. the
	  application will not exit, and hence the icon will be
	  visible, until you select "Quit" from the popup menu on the
	  icon.

	  Perhaps this type of operation should be limited to "Status
	  Monitor" type applications.  By status monitor I mean a
	  standalone application whose sole purpose is to monitor some
	  status and display a status icon. For example a gweather
	  type status icon.

Enabling/Disabling Status Icons
===============================

	It is preferable that icon's should support their removal.

	However, we need some way of consolidating this. Each
application could implement the behaviour itself - e.g. when you
remove the icon, the way to re-add the icon is to re-enable "Display
Status in the Notification Area" application preference.

	It might be much better if we could support this in the
notification area itself. If you remove an icon you actually request
the notification area to remove the icon and it will retain the
knowledge not to display the icon in future. Re-enabling it would be
possible through a "Manage Icons" dialog associated with the
Notification Area.

	A corollary of this is that it should be possible to enable
any available status monitor. One way of doing this might be for each
status monitor to install a .desktop file and a list of those made
available in the preferences dialog.

	This might present some confusion in the preferences dialog.
You have essentially two lists "Disabled application status icons" and
"Available status monitors". E.g. you might see something like this:

	[x] - Acme
	[x] - Battery
	[ ] - CD Player
	[ ] - Network
	[x] - Weather

	Both acme and gnome-cd would be currently running, but the
gnome-cd icon is disabled. You also have the battery and weather
status monitors enabled. However if you close gnome-cd you now see:

	[x] - Acme
	[x] - Battery
	[ ] - Network
	[x] - Weather

	i.e. you only see application status icons listed if the
application is actually running, but you always see status monitor
icons even if they aren't running.

	The problem is that users may see that Notification Area
preferences dialog as the place to add or remove icons from the
Notification Area. The subtlety that you can't add the CD Player icon
without first running gnome-cd would be very confusing.

	Maybe applications (as opposed to status monitors) should also
install a .desktop file (or add a flag to their .desktop file) to
indicate that they provide a status icon.

Defining an API
===============

	EggTrayIcon is a misnomer - it should really be called
EggTrayControl or something the way it is currently implemented - i.e.
you can plug anything into the Notification Area. EggTrayIcon should
provide a simple API to dock actual *icons* into the tray.

	Some requirements for a better API:

	o Provide a list of possible icons and a method to switch
	  between them. What's the best way to do this? A list of
	  stock ids, a list of icon names which can be looked up
	  according to the icon theme or a list of pixbufs.

	o A "clicked" signal.

	o Need to be able to add items to the icon's context menu.

	o Icons should respect the panel's size.

	o The icon should be focusable.

	o API to support blinking.

	o The icon should be automatically re-added if the tray goes
	  away and re-appears.

Defining the Terminology
========================

	The terminology for the Notification Area is a bit messy at
the moment. Both Notification Area and System Tray are bandied around
as meaning the same thing. Terms that need to be defined:

	+ Notification Area and/or System Tray
	+ Status Icon
	+ Status Monitor

Related Documents
=================

[1] The System Tray specification:
      http://www.freedesktop.org/standards/systemtray.html

[2] KDE systray guidelines:
      http://developer.kde.org/documentation/standards/kde/style/basics/systray.html

[3] 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

[4] Mac OSX Notification Manager (not sure how relevant this is)
    http://developer.apple.com/techpubs/mac/Processes/Processes-105.html