Re: Notification Area and applets

[Sean Middleditch <elanthis awesomeplay com>]

On Thu, 2002-11-28 at 01:33, James Henstridge wrote:
> Sean Middleditch wrote:
> 
> >I think this would be great.  Granted, I hate almost all applets and
> >plug status docklets every chance I get, but... it's for a good reason. 
> >~,^  notification area makes much much more sense for applets that don't
> >really "extend" or interact with the panel directly (i.e., just about
> >everything that isn't adding a missing feature).
> >
> >/me wonders how much hate mail he'll get for making this comment, again
> >  
> >
>  From my understanding, the way to decide whether something should be a 
> status docklet or applet is to think about who should be in control.
> 
> If you want the control to be a permanent fixture on the panel, with its 
> lifecycle controlled by the panel (ie. it starts with the panel, and 
> closes with the panel), then an applet is the right choice.  The panel 
> clock is an example of this.

note: since I'm touching a lot on usability stuff, I'm cc'ing the
usability list, so they can aid you in telling me what an idiot I am :-)

Things like the Quicklounge applet make sense as applets - they extended
the functionality of the panel (even if this is a crack-UI feature the
HIG will hopefully get rid of some day, when people can grow up and live
with a useful desktop, versus a toy desktop</rant>).  Really, tho, if
the app doesn't have much to do with the panel, and it's just using the
panel as an interface to the user (either for convenience, laziness, or
"coolness") it's likely better off as a status dock.  Full separate
applications with complicated cores/logic and large/detailed UI's should
not be a part of the panel like an applet, but instead simply have an
interface in a well defined and controlled area.  Users (and that
includes me) can deal with that a lot easier.

If one looks at my panel now, it's mostly icons; launchers, status
items, volume control, and the window-list icon that's part of the menu
panel.

The problem here is that, altho all the icons "look alike" (i.e., they
are similarily sized little pictures with no borders/backgrounds sitting
on the panel), they react differently to user interaction.  The
launchers and volume control have simple properties/movement on
right-click.  Thankfully the status items on there also react similarily
to right-click.  The menu-list just opens the menu, as if I
left-clicked; why doesn't it offer preferences like every other icon on
the panel?  It should, like the other icons, have a way of at least
removing it (assuming the menu panel becomes configurable), showing an
about box for the panel, or perhaps even allowing the basic panel
actions like adding a new launcher or creating a new panel or whatnot.

Left-clicking also produces different results: the launchers and status
items both bring up windows; launchers bring up "new" windows for their
respective application (galeon, abiword, etc.) and status docks bring up
windows for their application; either way, left-clicking activates an
application window.  The volume control, on the other hand, brings up a
little volume slider.  From what I've "learned" from the other icons so
far, it should be opening an application window.  Indeed, I've noticed
that I have a habit of clicking on a panel icon, and moving my mouse
towards the middle of the screen to begin working with whichever
application window opens.  The volume control is not only inconsistant,
but also "breaks" habit (which seems to be something the HIG is largely
based on).  I can't say all users do what I do, but perhaps a usabiliy
study could include that detail next time one is run (being the click on
panel icon, move mouse to middle of screen behaviour).

The volume control applet would probably be better served by opening up
the mixer app, or having a mini-mixer window (say with just the name of
the sound device, and one or two basic sliders and a mute checkbox) that
pops up, like one expects other icons to do.  The same can be said for
the window-list; it's behaviour is inconsistant with every other icon
(save the volume control) and left-click.  Opening up system monitor, or
a simple window with the window list, would be more consistant, versus
the current menu list in the corner of the screen.  Alternatively, if it
is truly intended that it *should* act like a menu, it shouldn't look
just like a launcher/status-item.  SOmething about it should denote it
as being a menu-like item.  Adding little areas or whatnot doesn't
really work, since it could easily just end up looking like part of the
icon - I don't know how it could be "visually defined" any better,
tho...

I could also point out that right-clicking on the menu titles on the
menu bar doesn't bring up a context menu, which is also inconsistant
with the panel; but then, in all apps, right-clicking on menu items just
opens the menu, so it's consistant with applications.  I would argue for
giving right-click a context-menu on the menu panel, both because
*everything* else on it (save the current window list) has a context
menu, and also because it would be a place to put the panel menu on
"full" panels (and avoid the "I acn't click anywhere on my panel"
problem, at least for menu panels).  that might not be a good enough
reason, tho.

second note: yes, I probably shouldn't've used the "usability correct"
terms vs. right/left-click, but it's late, and I dun really care.  So :P

And sorry for the long drawn-out message, but it's late, and I babble
when tired.

> 
> If the control is associated with another app, and its functionality 
> only makes sense while the app is running, then it should probably be a 
> status docklet.  Examples of this would be a new mail notification icon 
> for evolution or mozilla, or an icon for an IM program, etc.  These 
> controls are created when the application starts, and removed when the 
> application exits.  The lifecycle of the application that created the 
> status docklet is not related to the panel (in fact, for most uses of 
> docklets, the app will run fine if there is no status dock to display 
> the docklet).
> 
> In gnome-1.4, there were some applications that created applets, and 
> this caused lifecycle problems.  For example, xchat had a way to create 
> an applet (from memory, it couldbe used to get notification of new 
> messages, and use it to open new windows).  If you right clicked on the 
> applet and chose the "remove from panel" menu item, it would kill your 
> xchat session with it.  If you left xchat open when logging out, the 
> panel would try and start the xchat.  This behaviour was clearly not 
> what the user would expect: the lifecycle of the applet should have been 
> controlled by the application rather than the panel.
> 
> At least, this is my understanding of the distinction :)
> 
> James.
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.