Re: Notification Area guidelines

[Havoc Pennington <hp redhat com>]

On Fri, Mar 14, 2003 at 12:12:09AM -0500, John wrote: 
> Maybe I'm being silly, but I think that programs should only have an
> icon in the notification widget if they actually have something to
> notify the user about. :)  (I'd like it to behave more like an event
> queue for the user.)
> 
> I envisage icons appearing if new mail or instant messages arrive,
> a calendar alarm comes due, or an incoming call is detected by
> GnomeMeeting.  When such an event occurs, then the appropriate
> subdued and elegant icon would pop up on the notification area if
> it is not already there.  Once the user responds to the event, it
> would disappear from the notification area.

I've thought the same thing. It seems very simple and easy to
understand.

It seems like the idea of the notification area in XP is:

 - notify the user of events without being as obtrusive as a dialog

However, Microsoft seems to have decided (probably after user testing)
that if you just slide in an icon, no one will see it. So they slide
in an icon and then pop up a balloon. However, I'm unconvinced that
the balloon is less obtrusive than a dialog. So what's the point...
How can you have notification that users notice, yet isn't obtrusive?
Maybe a subtle blinking effect? It seems like sort of an oxymoronic
goal.

I guess balloons are slightly different from dialogs in that they
don't take keyboard focus and can't get "buried" underneath other
windows. So perhaps they are useful.

On X11, my impression is that we're using the notification icons
because applets can't come and go sanely (they push around your other
applets, etc., and perhaps can't be in the same process as a main
application without "issues"). So notification icons almost become
"applets that are self-managing instead of manually added and
positioned."

I'm not sure that's right at all, seems like a workaround for a
suboptimal applet system, or something.

> If we stuck to this rule, red spinning police lights on each of the
> icons would be unnecessary, as would goofy Clippy-cousin balloon
> notes. :)  What _might_ be useful is the equivalent of the "master
> alarm" on a spacecraft...  if a new event arrives, then one main
> throbber would activate, for instance, and/or a single note from a
> bell would sound, depending on the user's desires.  The master alarm
> would stop throbbing when any event on the queue is clicked or
> otherwise acted on.  The throbber (or whatever it is) could
> conveniently double as the handle for the notification area widget.

Indeed.
 
> Anyway, those are my thoughts, and maybe I'm nuts for thinking them.
> But, I like the idea of having a central place for events to be sent
> from background programs to the user, rather than having to pop
> dialogs up.

I like that we could actually explain how the notification area is
different from applets if it's basically an event notification
service.

This whole conversation seems slightly broken to me - we have this
wacky implementation detail, which is an applet that can contain
arbitrary icons, and we're trying to figure out some way to use it
that doesn't suck. But we aren't even sure what the problem is to be
solved or why we have the thing in the first place. ;-)

The less-annoying-than-dialogs event notification idea does seem like
a nail we could hit with our hammer-we-aren't-sure-what-to-do-with.

Though, I think the hammer is a bit malformed for an event
notification service, i.e. the spec could be beefed up and enhanced to
support the right kinds of properties and events on the notification
icons.

I guess I'm just making this whole thread inconclusive - sorry. ;-)

Havoc