[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-usability
Subject: Re: Guidelines for System Tray icons
From: "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date: 2003-03-19 4:58:42
[Download RAW message or body]
-----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-----
_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic