Re: [Usability]Re: Notification Area guidelines

On Fri, 2003-03-14 at 00:19, Havoc Pennington wrote:
> 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
> _______________________________________________
> Usability mailing list
> Usability gnome org

What you're saying makes sense.

Wesley Leggette <wleggette gate net>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]