Re: Notification Area guidelines

[Alex Duggan <aldug astrolinux com>]

Recently gaim and gnomeicu have both implimented "status icons" in the
notification area that act in very different ways.  

The gaim main window pops up with a single click on the icon while the
gnomeicu program pops up with a double click.  Closing the gaim main
window keeps gaim running in the notification area while closing
gnomeicu completely exits the program and removes it from the
notification area.  

If programs like gaim and gnomeicu are going to utilize the notification
area, which from your notes below seems like they really shouldn't,
something should be added to the hig about appropriate restore/close
behavior for apps using the notification area.  Also see
http://bugzilla.gnome.org/show_bug.cgi?id=98145

Alex


On Tue, 2003-03-11 at 17:59, Mark McLoughlin wrote:
> 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
> 
> 
> 
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list