Re: [Usability]Re: Notification area (was: Music player UI)



On Sun, 2003-02-23 at 20:21, Sean Middleditch wrote:
> On Sun, 2003-02-23 at 19:46, Jeff Waugh wrote:
> > <quote who="Sean Middleditch">
> 
> > > On a home machine, you can't stop it no matter what.  If people install
> > > Crap(tm), Crap(tm) will run.  If not a status docklet, then an applet, if
> > > not an applet, a whole new panel, etc.  At the office, well - users
> > > shouldn't be able to install Crap(tm).  
> > 
> > But in the GNOME Desktop release we need a standard, and in the HIG we need
> > guidelines.
> 
> Yes, definitely.  That doesn't help with stupid apps, tho, is my point. 
> Just like we have a HIG and I still see all sorts of apps that don't
> follow it (altho I bug the authors to hell and back about it ;-)
> 
> > 
> > > A user does *not* need a command-line on the their panel, nor do they need
> > > to see their CPU usage graphed, etc.
> > 
> > Seeing what your CPU is doing, at a glance, can be incredibly important.
> 
> Depending on your technical experience, sure.  But does it belong on the
> panel?
> 
> > 
> > > The few good ones (volume control, as an example) could either continue
> > > to be exposed, or made into status icons (the status of my volume).
> > 
> > Go back and rewrite the sentence using the correct terminology, and see if
> > it makes sense, ie. swap 'status' for 'notification'. Now compare the Mac OS
> > X volume control and the Windows volume control.
> 
> Yes, right, 'notification area'.  Terminology always has been my weak
> point. ;-)  I don't have access to a Mac, how does it handle the volume
> control?  (In comparison to Windows/GNOME)
> 
Volume control is one of the only top panel buttons. (You can also put a
power and monitor button in there if you need to). It works the same way
as the windows and gnome volume controls. 

This "Status" (The apple IG has a special term for it) button is
different from the program's section on the dock. Also, programs notify
users by jumping up and down in the dock for a short period of time and
displaying a dialog when the user clicks on them. Then the notification
period is over.

Also, all loaded programs stay in the left side of the dock (and have a
black triangle beneath their icons) while they are running. Services
(such as file sharing, etc.) do not have status icons, but are
configurable (and start/stopable) through the control panel).

Hope that paints a clear picture.

> > 
> > > Most the other applets we have are either a) useless (geyes, oo boy,
> > > there's something we need)
> > 
> > Tell that to:
> > 
> >   a) the notebook owner who often can't see her mouse cursor due to the slow
> >   updates of LCD screens (geyes + the press-control-to-find-cursor feature
> >   are both helpful)
> > 
> >   b) the stock trader trying to look for his mouse cursor which is hiding
> >   somewhere on one of his six screens (the directional hint from geyes is
> >   very useful here)
> 
> Hmm, point.  /me has new respect for geyes.  ~,^
> 
> > 
> > > b) duplicated elsewhere (dictionary lookup, for example).
> > 
> > Nice to have a spot to paste/type words to do the lookup, accessible from
> > everywhere. If you find words important, it's very handy (but sure, it could
> > also be relegated to something like geektoys).
> > 
> 
> Well, I personally see all applets save the core-stuff as such geektoys,
> but then, that's just me, apparantly.  ~,^
> 
> > > I'd be all for removing the concept of applet altogether, personally,
> > > but I guess enough l337 h4c|<3r5 would be against the idea of not being
> > > able to have a cdplayer applet or something (which is silly, given that
> > > gnome-cd now has a status icon ;-)
> > 
> > Which requires a click to get a menu, rather than providing buttons and
> > 'status' right there in front of you. The CD player notification icon is
> > another misuse of the notification area.
> 
> The notification area also kinda sucks for notification.  A little icon
> on your panel changing is completely not noticable.  If the balloon
> popups were used (those are still part of the spec, no?) it might be a
> lot better; I haven't seen an app that uses those yet tho.
> 
> If applets *are* the way to go for controlling apps from the panel, then
> maybe something like quicklounge for applets would be a good idea. 
> (I.e., a panel on a panel).  Then you could "group" applets together,
> and management of panel space gets a lot easier.
> 
> > 
> > > Most of the applets I've seen are things that would work quite well as a
> > > status icon, tho. 
> > 
> > s/status/notification/ -> no, they would not be appropriate.
> 
> > We don't need to remove applets altogether - we need to improve how they
> > operate and define where they're relevant, and make sure the notification
> > area is used as it was designed. Then we can avoid the mistakes other
> > platforms have made in this area.
> 
> Well, if the notification area is *only* for notification, then
> something for monitoring status of *apps* (not permanent panel fixtures,
> a.k.a. applets) should be thought up.  It makes sense to me at least
> that the notification area could serve both purposes.
> 
> Consistancy is also definitely something not done correctly atm.  Some
> notification icons open a window when clicked.  Of those, only some hide
> the window when clicked again.  Some offer context-menues, others
> don't.  That definitely needs to be a part of afore-mentioned policy.
> 
> As you say, definition of what applets are for and how they should be
> used is definitely important.  I'm also curious to see some definitions
> on what the panels themselves are, and how they should be used - are
> they just the place to stuff everything we want to always be visible? 
> Our general application launching, desktop controlling, notification
> viewing, application monitoring, menu managing, "thing" ?  Does all this
> stuff belong in the panels?
> 
> > 
> > - Jeff
> 
> _______________________________________________
> Usability mailing list
> Usability gnome org
> http://mail.gnome.org/mailman/listinfo/usability
-- 
Wesley Leggette <wleggette gate net>




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