Re: [Usability] Proposal for notification area

[Magnus Bergman <magnusbe algonet se>]

On Tue, 16 Sep 2003 21:51:44 -0400
Rodney Dawes <dobey free fr> wrote:

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

Yes, in some cases an application would really need to scream, in
other cases a subtle whisper is enough, and in most cases something in
between. This is why I suggested a severity level so that the
notification area could choose to throw a modal dialog in face of the
user or maybe run an external program if it is considered to be
appropriate (and if such an action is taken or not should be decided by
the notification and ultimately the user, not the application). But this
is a minor concern of mine and not really a part of the "core idea".

But the main reason I used the word *scream* was to underline my opinion
that applications should think twice before calling for the users
attention. If it doesn't have anything important and interesting enough
to say it should just shut up. If the application has no idea about what
the user finds important and interesting it should let the user decide
that (but I guess that this is a rare case).

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

Closing an applications window should exit the application. If closing
the window leaves the application running with an icon in notification
area, that is fits perfectly into my definition of "minimising to
notification area". And I still believe that the punishment for doing
so should be death or worse.

The user might very well want to hide the window, but the solution for
this is to minimise it. Notifications about if the user is on-line
and if there are any new messages only needs to be issued when something
really happens that changes the status. The normal state is that
everything is as it usually is, and the user doesn't have to be told
about that.

If the user is a monitor freak or slightly paranoid and really REALLY
wants to see the status all the time, then a *monitor* (not a
notification) is the right solution. Gkrellm should be enough to satisfy
any monitor freak. Most users should not need to monitor things all the
time, instead they should trust that everything *just works*. And if
someone just wants to check the status once in a while, she can just
switch to the application in question and take a look.

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

If there is an icon in the notification area it *should* attract the
users attention (and it's the notification areas responsibility to make
this happen). If the users attention isn't needed, the notification
area *must* be empty. If *any* application misuses this it will (and
should) upset the user. The user will complain about the obvious misuse
and the application must be fixed. I believe this behaviour will
efficiently put an and to the current nightmare once and for all. Of
course this requires a new standard and that it's not used only by
Gnome.

I think most people think the way it currently works is far from good
enough and that something new new that makes the nightmare go away is
required. Not only Gnome users. I think our goal *must* be a solution
that permanently solves the problem, not just works around it (like
Microsoft's solution does for example).

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

I don't agree. The notification area could be used then the download is
complete to inform the user about it. I definitely don't want to see the
status of every download all the time. If the user starts a download she
should be able to trust that it's going on until it's complete (if an
error occurs maybe that's important enough to tell the user).
Applications could supply some kind of monitor applet or similar for
control freaks (see above).

In short:

* Applications may choose to notify the user when something happen.

* The user may explicitly choose to monitor something.

What you refer to as "status display" I would call "temporary monitor".
I did think about this and took it in consideration but came to the
conclusion that they are not a good thing. But please try to make me
change opinion.

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

A daemon which notifies the user then the battery is low it totally in
line with my proposal. This is *exactly* the kind of stuff that the
notification area is useful for.

For network status a *monitor* solution is appropriate. If you connect
to the net you are connected until you disconnect, you don't have to be
told about it. Like if you connect a telephone to a telephone jack it
doesn't tell you it has been connected, and that it is connected until
you disconnect it. You can check if it is connected picking it up and
listen, but usually that is not needed. These things should *just
work* and I think they do. Do not bother the user. (See above about
control freaks.)

> >   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. :)

Absolutely! In these kind of cases it *might* be the correct solution
(but not necessarily). But in all the other cases mentioned it is
*never* the correct solution and it should be forbidden.

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

I don't agree. Why should double clicking be needed in any imaginable
case? How could be user be able to know about it and what it does. It
only introduces unnecessary strangeness in the environment. I'm not all
against context menus, I just don't see any use for them here. But
please convince me and I might very well change opinion.

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

Yes, you are absolutely right about that. In most cases the user don't
even need to care. Like if the battery is low, the user is not the least
interested in knowing which application (or daemon or whatever) is
telling her this.

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

My idea is that it's completely up to the notification area to do the
flashing and screaming and decide exactly how it's done. The user should
also have a chance affect the choice of behaviour. This could vary a
great deal between different environments, and that is OK. The
application decides which icon should be displayed. The rest is only
*suggestions* from the application. It could be additional icons (to
create a simple animation) or names of sounds to be played. Flashing the
background and/or playing a default sound is something that the
notification area could do on its own (if it wants to) and nothing the
application even knows about.

In the case of sounds it obviously needs a standard, but my idea works
without sound too. When a standard for sound is present, sound will work
too (by adding code of course no no changes needs to be done to the
standard specs). But perhaps a cross-environment sound standard will be
present before a standard for this anyway, who knows.

> > 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 one notification blinks and screams more than the others, that
benefits all the notifications currently in the notification area. If
there are more than one icon, they all need attention. It is not the
case of one trying to steal attention from the others (which is a
potential problem I tried to avoid with this proposal). The choice of
inappropriate icons and such if naturally a problem (but a different one
that I don't really find related). If people who doesn't know how to do
things, do things, that is naturally also a problem (very common and
widespread). I don't see any reason why it shouldn't be at least as
accessible as anything else in the panel (or similar in other
environments). But I'm quite sure I missed your point here. Can you
please clarify it?

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

You are probably right. It might very well be more misused than used
adequately anyway.