Re: [Usability]Notification Area guidelines

[Rodney Dawes <dobey free fr>]

On Tue, 2003-03-11 at 21:20, Jeff Waugh wrote:
> <quote who="Rodney Dawes">
> > > 	+ An application adds an icon to the tray when it starts. The only
> > > 	"status" the icon shows is that the application is currently running
> > > 	and the main purpose of the icon is essentially to provide a
> > > 	shortcut to various application operations without switching back to
> > > 	the application itself.
> > 
> > This may make sense in a very small amount of use cases. I wouldn't throw
> > the things out entirely which may be useful in a very minute number of
> > cases.
> 
> Do you have any example use cases in which this approach would make sense?
> Many Windows programs do this (as does acme), reducing the value of the
> notification area as a useful tool for the user -> overloaded with icons =
> too much information.

VirtuaGirl, an RandR docklet if we had one (similar thing in windows
exists).

> > > 	Both of these sound like cases where custom applets would be more
> > > 	suitable. However, both of these cases seem to be recommended by the
> > > 	KDE guidelines[2].
> > 
> > Custom applets are really annoying usually. It is even very annoying that
> > the Notification Area is an applet, as the alignment on the panel doesn't
> > affect the resizing when icons are added/removed. The notification area is
> > also something that should really just *always* be on the panel.
> 
> I agree. I have a proposal to post later on about how to implement the
> notification area in a different way, which would hopefully solve some of
> its problems due to being an applet.

I had a proposal, but it seems foobar is no more, so that one is down
the drain. The issue now remains that the panel should handle gravity
inside of it correctly for applets instead. Personally, I only use the
foobar, so now I'm left with no choice but to salvage that code for my
use. The normal panel just can't provide the same interface that the
foobar does, no matter how many menu applets you write and embed on it.

> I don't believe that applets are 'evil' and should be crushed at all costs,
> however. They certainly have their place. We just need to define it better.

I didn't say applets were evil. I said they behaved poorly when resizing
is involved.

> > > 	+ Only icons or labels or a combination of both should be in the
> > > 	Notification Area. No buttons, toggles etc.
> > 
> > I'd suggest that labels shouldn't go here either. The Notification Area
> > should be for a *minimal* amount of necessary notification, with as much
> > affect as you can get out of it. If your status icon needs text beside it
> > to display anything useful, and the tooltip isn't enough, it probably
> > should not be an icon in the status tray.
> 
> Imagine a battery icon that has to display percentage or time remaining
> within its very small icon space. I strongly approve of labels in nicons.

It should be an applet, not an icon.

> > > 	+ Right click or Shift-F10 should display a context
> > > 	  containing:
> > > 	    o A "Remove Icon" option - see below.
> > > 	    o A "Preferences" option if the icon behaviour may be
> > > 	      customized.
> > 
> > These seem to assume that the status icon is a separate process from
> > the main application process, which is typically not true.
> 
> My interpretation of this section is that in some cases, the icon is
> completely unrelated to any other process (or really, user application). A
> network connection applet might be a useful example here. It doesn't
> actually relate to any other program, it just gives you status/notification
> info about your network connection.
> 
> Say I stop using PPP and am connected directly to my network, and feel that
> the status icon is less useful to me, do I:
> 
>   a) Go to the network control panel and turn off the "Show status icon"
>   checkbox, or
> 
>   b) Right click on the status icon and click "Remove Icon"
> 
> I think b is exceptionally useful in this use case - certainly, it is a
> different issue when it comes to things like GnomeICU/Gaim icons, which are
> directly related to another window/application (ie. they are the same
> thing).

Neither. It should be automatic. "Show Status Icon" should be in the
control panel. If you're going to implement it as an item on the right
click menu of the icon, then it should be "Disconnect" for a network
applet. Disconnection should remove the blinky-lights icon that the
network status icon is used for.

> > > 	+ Icon's should have tooltips with a short summary of the
> > > 	  icon status.
> > 
> > Agreed. A textual representation of the status belongs in a tooltip.
> 
> Again, regarding the point about labels, I'd say "further information". :)

> > For battery status, people typically want to know from a quick glance if
> > it's on AC power, charged, charging, or an approximation of the amount of
> > battery life. For an exact percentage, a tooltip should contain that info.
> 
> That's really important 'at-a-glance' info, and I believe it should be part
> of the nicon itself.

If you need that much information, you should be using the applet
anyway. If you aren't against applets, then why are you so against
using them outright, rather than just boxing them in another window and
throwing them in a system tray? Adding more things like this to the
status icons is just as bad as cluttering the tray with extraneous ones.

-- dobey