Re: Guidelines for System Tray icons

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi all...

been an unexpectedly busy few weeks for me, but thought i'd weigh in on the 
systemtray issue ... i'm replying to Mark's email, but it's going to be more 
of a summary of the entire thread, because i'm lazy like that ;-)

On Thursday 13 March 2003 04:03, Mark McLoughlin wrote:
> 	"The Notification Area is only for status information"
>
> 	but rather
>
> 	"The Notification Area's primary purpose is for status"

these are semantics which don't help us answer the real question: what would a 
user find to fit the principle of least surprise?

the threads on this topic so far seem to have the following memes in them, 
which i'll address in my usual long-winded way one-by-one. and i'm going to 
use the term systray rather than Notification Area because it's way, way 
shorter and i know you all understand what "systray" means.

 o the systray should be used only, or at least primarily, for status 
information. 

the question of "what is status information" doesn't seem to be really 
answered well yet, though. is the fact that my alarm program is running 
status information? is the CD player being available status information? 
that's the problem with trying to define correct behaviour through semantics: 
we'll end up cutting out useful cases, where useful is defined as "users find 
it handy". i'd rather allow us to figure out what is useful and falls into 
the category of "reasonable expectations" on a case-by-case basis and simply 
define the simple mechanics of the systray, rather than have an ideologically 
well defined systray that sucks part or most of the time.

side-thought: we don't tell application writers what happens when a user 
presses a button in their app, but we do tell app writers how to display that 
button in a standard way and what "pressing a button" means. mechanics vs 
meaning.

 o systray icons should be transient with application windows. 

again, principle of least surprise. to most users an app window and a systray 
icon are two different UI elements seperated by time and space, so they 
should behave independently. whether that means the programmer writes a 
separate daemon for the systray icon or just keeps the main application 
around is an implementation detail, but there is simply not enough of a cue 
between a given window floating about on the desktop and a systray icon to 
make one hinge on the other. 

well, in most cases. there are situations where it seems unsurprising when 
quitting a program means the systray icon goes away too. an email application 
may be one example, since people often have interval checking turned on in 
their email application and when they are offline they want to quit checking 
email and so close the email application. the systray status icon should go 
as well in this case since that more likely reflects the user's desires. but 
this is a corner case where "least surprise" may well trump "common 
mechanics"

the only problem i see in the the common case is resource usage of 
applications that don't ever quit but hang out in the background ;-) it would 
be nice if there was a generic systray daemon program that was small and 
light and could be started and communicated with via DCOP (or whatever 
lightweight IPC you've got available to you). such an app would allow 
defining a menu and icons and transmit events via signal over DCOP. this 
would allow applications to quit completely (better resource usage) without 
requiring the app developer to code an entire daemon just for the systray 
(which i consider an onerous expectation to place on developers just to get a 
persistent icon in the systray). to the user it would work the same way as 
ever: closing a window means the systray icon remains, opening the app from 
the app menu means the app window appearing, clicking on the systray does the 
same, etc... no surprises for the user.

for applications like a CD player, though, what makes the most sense is to 
simply hide when closed with its only UI representation being the systray 
icon. the CD continues to play, control of that continues to be conveniently 
available via the systray, as does the main interface. a daemon, even a 
handily available one, is likely to be overkill.

 o functionality should be provided in small applets. 

why? people have noted several disadvantages and the only advantage i've heard 
is that it keeps some sort of intellectual purity of function in the systray. 
but this seems absurd since if we want both functionality and status we'd 
need two separate representations on the panel (both automatically addable 
and removable, which means reinventing the systray for applets) which means 
we'd now have an application represented in FOUR places (main window, 
systray, applet, taskbar) and require the user to figure out what each one 
does and why each doesn't do the other.

additional functionality could be provided via the taskbar (right click on an 
entry) but this still overloads the meaning, requires the taskbar to be 
around (not everyone does) and doesn't answer the question for non-windowed 
apps. so while this may be generally useful, it isn't a Solution with a 
capital 'S'. 

the distinction between "this belongs in an applet" vs "this belongs in a 
systray" have been thus far completely academic and not sympathetic to what 
users actually need and want: a concise and easily identifiable place on the 
desktop which allows them to see what's going on and have minimal interaction 
with that something.

 o complicate the window manager with concepts like "minimize to systray"

this just moves the burden of organization to the user, who are far less 
capable of sorting such things out than a logical system can. things should 
"just work" when possible, especially for trivial things like the systray. 
the systray is not a big decision making factor for users, in fact it's whole 
point is to be unobtrusively useful. we should not make it intrusive. not to 
mention that window managers are already complex enough and that they already 
have standard definitions for available actions.

 o overload the icon meanings in the panel so that a launched application can 
show the status in the panel icon (ala the MacOS X dock). 

this requires a standard place to put icons (since we have the possibility of 
multiple panels, this raises issues), and enough room to put them. it also 
means turning the panel into a taskbar of sorts as well as a launch bar 
(since running apps that want to show status would need to pop an icon on the 
panel if there isn't one there already). this ruins the learnability of icon 
ordering on the panel as icons appear and disapear rather randomly and 
overloads their meaning. reality is that it simply relocates the systray 
problem by making "the panel" a dynamic roaming ground for application icons.

this is one of the biggest mistakes in MacOS X, IMO, and not one i'd like see 
us duplicate.

 o systray icons are too small to show things like how many emails you have.

funny. i have a systray icon that shows i have 234 unread emails right now 
(*sigh*). when i left click on it i get my email interface. when i right 
click on it i can send new mails, jump to a folder that has mail in it, 
configure my email set up and more. obvious, simple, no surprises.

 o Left Click vs Double Left Click vs Right Click all in Context

we can't require users to have black belts in mouse judo as a prerequisite to 
using the systray. the differentiation between left and right clicking should 
obviously remain (activation vs context menus) since that is a well known 
concept that is used throughout the modern desktop. but changing the meaning 
of left clicks based on the type of app or context the user is in (probably 
quite unknown to them), or single vs double clicking doing different things 
is all more complex than necessary. KISS: left click does <fill in blank>, 
right click does <fill in blank>.

> 	i.e. you only provide an icon in the Notification Area if there is some
> genuinely useful status information you want to provide to the user.
> Inherent in this, you will most likely provide quick access to
> functionality related to that status .... but the primary purpose isn't
> to provide quick access to your application.
>
> 	I think that's fairly sane. Static icons communicating no status
> information (other than that the application is running) seems rather
> useless to me.

aesthetically useless or functionally useless? aesthetically, yes, they aren't 
providing status info so why are they there? but functionally they are handy: 
they let users get a task accomplished quickly in a simple and predictable 
way. that's what really matters IMHO.

> 	(By custom applet, I just mean an arbitrary group of widgets that you
> can add to the panel which is related to an application. E.g. a mail
> program could provide an applet which is a "New" button with a drop down
> list to choose between "New Message", "New Appointment", "New Contact"
> etc. I don't think this is something that belongs in the systray.
> Indeed, this is a pretty special purpose applet which only hard code
> users of the application would want on their panel.)

and those "hard core" users would probably say something like: why the hell 
does it use up both space in my system tray AND my panel? why do i have to 
clutter up my panel with 15 applets just to get the functionality i want when 
it would fit really nicely as a context meny in the system tray?!

non-power users wouldn't care, of course. unless the applet automagically 
appears, in which case we've put them in a pickle: "how do i remove that 
thing?! i didn't ask for that applet!" but if the applet doesn't 
automagically appear, we've lost an important aspect of the systray 
functionality AND we've put even more onus on the power user to know what is 
available to them and to set it up.

so in the best case we don't help anyone and only disturb power users. in the 
worst case (automagically appearing helper applets) we will piss off people 
across the spectrum of users.


IMHO, the systray should be a place where icons appear for apps. they should 
be persistent regardless of window closing/showing, with allowances for 
corner cases. left clicking should bring up the main interface (making it 
easy for all to get to), and that can mean either a main window, or if there 
is no  window a menu or other such device. right clicking should bring up a 
menu allowing termination, configuration and access to commonly used 
functionality.

if that sounds a lot like the KDE systray guidelines as they stand, it's 
merely coincidental that Waldo and the others involved in that spec did such 
a good job of writing it in the first place ;-)



hrm. that was longer than i expected. =) i have to scamper off to another 
meeting =( but will hopefully be around more in the very near future again.

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE: The 'K' is for 'kick ass'
http://www.kde.org       http://promo.kde.org/3.1/feature_guide.php
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+d/kC1rcusafx20MRAksDAJ9QTRxRpmsIBZBTv7CPmUP4VYKFDACfQbMg
ckQ8TWWWOdH5ygH0U4Gr8Kk=
=uyHN
-----END PGP SIGNATURE-----



-- 
open-hci mailing list
[email protected]
https://listman.redhat.com/mailman/listinfo/open-hci