Re: [Usability] Proposal for notification area

[Rodney Dawes <dobey free fr>]

Il mar, 2003-09-16 alle 19:45, Magnus Bergman ha scritto:
> I have never really liked the idea of a notification area to begin with.
> In windows (where it all started) it has been more abused than used in a
> useful way. It's behaviour is also inconsistence and gives me the
> creeps. Still I must admit that it has one (and only one) usage and that
> it solves one (and only one) problem. So I tough a lot about it and came
> up with this proposal which will magically make it useful, consistent
> and foremost make all the abuse go once and for all. =)
> 
> I though it would be a better idea to post it here than at bugzilla so
> more people get the opportunity to criticise it.
> 
> Purpose
> =======
> 
> The problem this feature is useful for solving is to let applications
> call for the users attention. If an application has an icon on displays
> an icon in the notification area it is saying "hey user, i have
> something I just have to let  you know". And that is *as long as the
> icon is on display*. When the user responds to this and says "yes, Mr
> Application, that is it that you want" and then icon goes away. If the
> notification is no longer valid the icon should also go away. If an
> application displays an icon, it is screaming for the users attention.
> If the application don't intend to scream for the users attention it
> shouldn't have an icon in the notification area.

I'd say it's more subtly asking for attention. If it were screaming, it
should probably be a modal dialog. :) I sure would not want to wait to
see flames because a tiny icon popped up in the corner of my screen that
I didn't see, because I was busy doing something else, and my focal
point was very distant from the notifcation area, to avoid having a
dialog pop up in my face. It really wouldn't matter if it stole keyboard
focus, if your keyboard was about to melt with your fingers attached to
it.

> Misuse
> ======
> 
> The following things are misuse and must be forbidden:
> 
> o Minimising to notification area
> 
>   I suggest death penalty for this.

You need to realize the difference between minimizing and closing the
window and leaving an icon to show that you are online/messages have
been received/etc...

> o Displaying an icon if there is nothing new to tell
> 
>   This will just take the users attention away from things that she
>   really needs to pay attention to. There is no need to let the user
>   know that things are still as they used to be.

At least you are halfway right here. Having an icon in the panel is
hardly something that will take the user's attention away, especially
if it is there all the time. If it were always there and blinking and
making awful noises, then maybe. Either way, the notification system
is incomplete (at least, implementation-wise), and needs a lot of work.
And because you forbid something, doesn't mean people won't do it. It
really is only an issue for "core" gnome apps or such. Then there is
the issue of other toolkits. They may have completely different ideas
about the HIG, or how things behave, and we can't control them.

> o Displaying status
> 
>   This is a *different problem* and needs a *different solution*.
>   It's up to the user to decide what she wants to monitor. If she
>   wants to monitor a variable such as the battery status or the new
>   mail count, she should  explicitly add such a monitor (as an applet
>   or as a gkrellm plug-in). This problem is already solved.

You are confusing status with persistent display of a device's state.
If I am downloading something, I probably want to see an icon displaying
that status in the notification area, until the download is complete.

>   The current solution doesn't work between different GUI:s. Well,
>   then *that* is the real problem. And the solution is to come up with
>   a standard for monitor applets between GUI:s. Then Gnome panel can
>   support this standard and integrate it with the native applets in
>   a nice way.

Your solution does work between different "Desktop Environments",
because they all have their own battery monitors and such. I would
much prefer to get rid of the battery and wireless applets on my
panel, in favor of something more robust, perhaps a "daemon" to alert
me when the battery is low, or similar hardware events. Then again, I
could justify "network status" by stating that the icon is persistent
only by virtue of the fact that there is continuous activity on the
network, so the icon changes state constantly (as is how the network
icons in the win2k/xp systray work).

>   If the status changes, that can justify the need to get the users
>   attention and the placement of an icon in the notification area.
>   Because that is something new and needs the users attention (and if it
>   doesn't, the application shuts up of course).

As I stated above, it is justifiable, but it's not necessarily the
correct solution. :)

> How it works
> ============
> 
> That I called icons earlier is really a button. It works like any
> other  button does, nothing special. For simplicity I suggest that
> only icons may be supplied by the application (and put on a button by
> the notification area), not labels or something else.
> 
> A single click sends a callback to the application and the icon is
> automatically removed. Then the application takes adequate
> action,typically showing a dialog.
> It doesn't have a context menu since one isn't needed.

I'm guessing this should probably be an EventBox, rather than a Button.
There can be special cases for everything and we shouldn't exclude the
need for a context menu, double click, or other similar actions.

> A tool-tip might be handy and that could contain the applications name
> and  a brief summary.

If it's not immediately obvious what application the notification is
from, then it probably shouldn't be using the notification panel, or
a bug should be filed, and it should be fixed so that it is obvious.

> The application could have a possibility include information about how
> to make extra noise, like animating/flashing the icon or playing sound.
> But it's up to notification area (and ultimately the user) decide
> whatever to do this or not, and also exactly how to do it. All in a
> uniform way. For example the notification area could choose to only
> cycle the background colour when it contains icons.

Flashing of the icon can't be in the container, it has to be in the
child. This is due to the fact that one can theoretically use any UI
toolkit to create and display the icon. Sound playback can't really
work properly until we have a standard for sound themes and such, so
that different environments, using different methods for sound playback
(aRts vs. esd, for example), and other such limitations, can be avoided.
Then again, it would be better if we standardized the sound device
access proxy method, rather than trying to play sounds through different
toolkits in only a limited set of cases. And changing the background
color won't work so well, or at least, too easily. See the bug where the
background of notification area icons is different than the icewm panel,
because they are all written in a different toolkit. I'm not sure this
problem exists in the kde/gnome/xfce case, but it probably does in many
cases. This of course could probably be resolved assuming the XSetting
color stuff goes into gtk+ 2.4 and whatever next versions of QT/etc...
there will be.

> And yes, you heard me right; *everything* in the notification area
> flashes and screams *all the time* as long as long as the notification
> area isn't empty. Just like fire alarms, telephones and children does
> then they consider your attention to be required. But the normal 
> condition is that your attention isn't required and then everything is
> peaceful and quiet and the notification area is empty.

This is why <blink> was so successful on web pages. Really. If you can't
choose an appropriate icon/sound/tooltip/balloon text entry/etc... for
your "notification", you probably shouldn't be doing it in the first
place. It also needs to be accessible. This is a series of separate
problems though.

> If they user doesn't want to be notified of certain things there
> should be an option in the application to turn it off. Having a filter
> that ignore certain  events in the notification area is to work around a
> problem, and the need for it would be a failure.
> 
> Perhaps there should also be a well defined severity for
> notifications.

If it's too severe for a simple notification icon, it probably shouldn't
be one.

-- dobey