New property proposal for StatusNotifierItem protocol: Label

[Aaron J. Seigo]

On August 10, 2010, Ted Gould wrote:
> On Tue, 2010-08-10 at 09:40 -0700, Aaron J. Seigo wrote:
> > i really think this is one of those places where we should draw a line
 in
> > the sand and say "beyond this point, text doesn't happen, sorry."
 getting
> > rid of textual data in the primary display of these items is a good
> > thing, not a bad thing. it allows the user to tell _at a glance_ what is
> > going on.
> > 
> >  adding bunches of text erodes that.
> > 
> > and if i want to know to the exact % how my battery is doing, i can
 mouse
> > 
> >  over it.
> 
> I think that you're conflicted here saying "at a glance" and "mouse
> over." :) 

if i wish to know my battery status, i glance over and see that the machine
is plugged in to the wall and the battery is mostly full. that's "at a
 glance".

if i need / want to know that it is 78% charged (and whatever other info i
feel i need), i can give that item focus by putting the pointer over it or,
 in the case of touch based devices, touching it.

> I think the issue here is how precise of information you can
> get at a
 glance.  With an icon you can get a round about idea, but a
> number can give you much more information at a glance.

and there are limits on the usefulness of the information.

it's a trade off
between amount of information, the usefulness of it and how easy / enjoyable
 it is to process it.

we can probably agree that putting the subject lines of the 5 emails i have
unread in my inbox into the system tray is overkill. ;) it's too much
information at a glance and isn't particularly useful to the point of that
 notification item which should be notifying me about my mail status.

putting the # of emails there? well, that's perhaps debatable. but
accomodating it creates problems in lay out and clean presentation. so the
question is, how much _value_ is in that information? do i really need to
know that i have N emails right now? is that a meaningful number, enough to
justify putting it there? or do i really want to know that i have "email
 recently", "email unread", "nothing to look to at"?

that's the question. and the idea of adding labels runs around that
question. it is a way of providing a feature without asking if that feature
 makes sense, and i honestly don't think it does for the reasons above.

presentation quality is another issue: on the precise issue of battery, you
end up with all sorts of fun and annoying issues, especially with devices
with more than one battery. overlaying the text associates it strongly with
the "right" iconic entry, but putting it next to it may look better.
however, putting the text next to the icon then requires that we associate
that text strongly with that entry (otherwise if there is an icon on both
 sides of the text .. which does it belong to?)

getting the presentation of text in such a small space with an unknown
 number and type of items is nearly hopeless.
 
> The other issue that we have is that in our visualization we're not
> supporting tooltips. So there is no mouse over for more information.

perhaps that design decision should be re-thought.

> We could use the
 tooltip and put it on the panel, but it seems like in
> general the tooltip in KNSI is designed for much more information than
> "100%" so it doesn't seem like a good match.

yes, it's designed for more information than will fit nicely in the iconic
 space itself.
 
>       * Keyboard layout.  They want to use text to describe the keyboard
>         layout.  Currently in GNOME a couple of letters are put into an
>         icon and frequently those have to be squeezed to make them fit.
>         It would be better to use "standard text" in this case.

this is the one issue we also have. it's an edge case, and i wonder if we
 can't find a more appropriate solution for it as such.

(and remember that public API is never an edge case ;)

>       * Weather. 
 There is a group of developers that is making a
>         weather indicator with the intention of it being in the unity
>         panel.  It would have an icon that is the type of weather
>         (cloudy, sunny, etc.) and then provide the temperature as a
>         label.

this is cleary a case of "They're doing it wrong." if you want a weather
display, don't use the system tray, don't use the _status_ _notifier_ API.
 it's the wrong solution, and it's the reason we have full APIs for applets.

and in case someone says, "But.. I want it in the system tray area!" .. well
.. you can put the weather applet in Plasma's system tray. it uses the right
API for it, too: the system tray simply allows hosting of desktop widgets /
 panel applets in it.

>       * Power.  An icon that would be the approximate battery level, but
>
         also accompanied by a percentage.  While I'm also skeptical on
>         the value of having the label there constantly, there is a very
>         passionate group behind it.  And, I was also shocked to find out
>         even Apple was unable to subdue them :)

passion does not make people right. if we design based on how passionate
someone can get about something, everything would be themed after some
Japanese cartoon or be based on contet from a Holy Book. sometimes we have
to step back and say, "I understand your point, but the surrounding issues
 veto it. Sorry."

(in Plasma, it's an option. and the battery is also an applet, not a user of
 status notifiers. again, right API for the right job.)

> There are a couple of other folks that I have approached me on the
>
 topic.  They were things like CPU temperature monitors which I think
> have less value, but I'm imagine we'll see.

that's what applets are for. not StatusNotifiers. we're trying to get AWAY
from the abuse of the system tray, not add to it. things like monitors need
a very different kind of API, shoehorning them into something like
StatusNotifiers is always going to shortchange them while screwing over the
 actually defensible and needed uses of StatusNotifiers.

> >  some alignment, but the results will still be less than they could
 be.
> 
> Personally, in this case where a grid provides a better layout I think
> not showing the labels is an appropriate reaction.  In general, it seems
> to me that the label should also be "extra information" so showing it is
> handy but not critical to the use of the indicator.  But, I if the text
> is desired in the grid layout in that agateau's suggestion is the most
> reasonable one.  Basically, try to make the grid as strong as possible.

agreed ...

> While I agree with your ideas on API design, I think that
 we're
> providing a set of functionality that is unique with this proposal.
> With small icons (panel sized) it's basically impossible to be precise
> in the display. 

moral of the story (where "you" is the prototypical app developer): if you
need to communicate precise information to the user, status notifiers are
not for you. either that, or you don't really need to communicate precise
 inforamation to the user, you only think you do.

> And to overlay text is also non-ideal because making
> the text readable
 requires basically having no icon at all.  So if we
> want to provide precise information in a panel visualization, I think
> that we really need text to be able to provide that.

and that is the heart of the matter: i don't think we need to, nor want to,
 try to provide precise information via status notifiers.

(there are other more appropriate APIs for that)

-- 
Aaron J. Seigo
humru
 othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20100810/08fd3225/attachment.sig