Re: [Usability] Notification Area Preferences

On Mon, Jun 16, 2003 at 12:14:04AM +0100, John Levon wrote:
> [Cc: to usability@ added back]
> On Sun, Jun 15, 2003 at 05:47:21PM -0500, Gregory Merchan wrote:
> > The checkbox, "Allow unidentifiable icons"
> This means almost nothing to the user. How is the average user going to
> comprehend what this means, and, more importantly, decide whether they
> want it or not ?
> I suspect you will get baffled looks and "well, of *course* I don't want
> unidentifiable icons ! I prefer identifiable ones please" ;)

I can't believe I'm going to write this, but that's why the Help button is
there. It really is; I couldn't think of another way to handle the
unidentifiable icons, other than always or never allowing them. I didn't
think the checkbox label, or any other short label, would convey the
meaning clearly. I figured since I was adding the Close button, only to
avoid comment about its absence, I might as well add a Help button and
shunt the problem off to the documentation.

> >  is there in case programs provide icons without setting the
> >  recommended hints.
> Wouldn't this indicate that such programs need improvement ?

But what does that matter? Unless GNOME adopts the policy that unidentifiable
icons will never be shown, the user will be stuck with them. If GNOME
adopts that policy, there will surely be complaints that the tray isn't
working; in part, because the tray spec doesn't require the hints.

Best case scenario, the specification changes to require the _NET_WM_NAME
or WM_CLASS hint be set. Without that change, either GNOME adopts a special
policy, or the checkbox must be there.

> > they should not do this. There is one exception: if the user asks the
> > application to show its icon explicitly - e.g., by checking a box in the
> > application's preferences window - and the application detects its icon
> > is not being mapped, then it should present an alert directing the user
> I don't think making the user do something twice is a good idea. The
> computer should be able to do what it's told and deal with its own
> problems, not hassle the user.

The only way to avoid the alert would be to provide a way for applications
to tell the tray that the user has changed his mind, which would require
an addition to the protocol. Unfortunately, such an addition would also
allow apps to do this without user interaction, thus overriding the user's

Actually, there's another way: don't include any such option in the
application. This way there's only one place for it - in the tray prefs.


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