kubuntu kdebase patches to plasma

[Aaron J. Seigo]

On November 13, 2009, Celeste Lyn Paul wrote:
> In some cases you have some text that is always on, some text that is
> only on via mouseover, and some text that is never on (not all entries
> have subtext, e.g. System Settings). This behavior is inconsistent and
> confusing in addition to some of these problems:

the behaviour is not meant to be consistent in terms of "does it paint the 
same way every time". it's meant to be consistent in terms of "provides the 
necessary information to the user without overloading the display". as for 
confusing, it's only confusing if you try and figure out why we've done it the 
way we've done it (reverse engineering the design); i have yet to hear from an 
actually confused user (versus a user trying to pick out issues because they 
are playing "clever critic") though we used to hear all the time from them 
before the disambiguation.

> * When you have some items with subtext on by default (such as when
> you have multiple browsers installed), there is less of an affordance
> to check for the subtext hints because some are already visible, so
> why would you keep looking?

i'm not sure why that would matter in the least. it also becomes very evident 
that they normally show on hover, and that hover information is not 
particularly useful when there's just one "Do Foo" app anyways. your 
assumption here is that, in the common case where there is no overlap between 
application generic names, that the subtext is the important bit. if it is, 
then let's switch to application names first as the default. i'm not sure 
"KTorrent", "KsCD", etc. is really the most user friendly approach however.

> * When some labels are on by default but others appear on mouseover,
> it looks like a bug before you figure out the "disambiguity" pattern

but it's not a bug; i'm all for making things as "immediately sensible" as 
possible until the "immediately sensible" causes problems for others. in this 
case, it solves a real problem our users were really facing and if others 
puzzle over that, well, that's just unfortunate. nobody's hurt, and those who 
need it (who happen to be most people confronted with three "Web Browser" 
entries) are helped.

in fact, i bet if we didn't do this that we'd be hearing from you about the 
three "Web Browser" entry situation.

> * Subtext on mouseover requires the user to read with their mouse
> which is awkward and unnatural, nevermind impossible on touch
> interfaces and adds burden to those using a keyboard instead of a
> mouse for accessibility reasons.

the subtext, except in the case of needing disambiguation, is not critical to 
making a decision. so you don't need to mouse over. unless we didn't show the 
disambiguations. then we'd have a problem.

> * For the task-based labels, mouseover subtext make it more difficult
> for users to find applications by name -- which does happen. People
> get recommendations for installing "Marble" not "Desktop Globe". It
> only supports a single use case.

thankfully we offer search first and foremost. we also found that clusters of 
mysteriously named applications like "Marble" are less useful to people than 
"Desktop Globe", and that when people are told about marble they are told it's 
"mapping software" or "a desktop globe".

when looking for specific items, menu hierarchies generally suck no matter 
what the strategy, though some strategies are better than others. we are 
promoting search, with the menu as a way to explore what's available or to go 
to items you already know or can guess the location of. and in those cases the 
functionality is usually more important than the name of the binary on disk.

> * For the application-based labels, if you are unfamiliar with the
> names or branding, you *must* read with your mouse.

that's why we default to generic names. application labels are for people who 
know what they are doing.

> * When there are no labels, or the labels are not visible, the primary
> label looks disproportionately small compared to the icon because a
> space must be made for the subtext.

and yet when you mouse over it becomes evident. if you would like to provide a 
artist's mockup of a different layout that fulfills the needs outlined here, 
please feel free to do so. it's easy to jab at the current layout until you 
actually try and make something better.
 
> I just don't see any compelling reasons why the subtext should be
> turned off. "Unclutter" the interface doesnt work for me; if the
> subtext is "clutter" then the labels are bad and should be improved or
> it is noise and shouldnt be there at all.

"unclutter" does work for me, since it looks horrific with dense bodies of 
text everywhere. you may not agree with that aesthetic, but it's the aesthetic 
that's been chosen. we can argue it and the relative merits of Dali versus 
Escher over a glass of wine sometime.

the subtext is clutter only when it's shown all the time for all entries. the 
subtext is an aid to the user who wishes to know more, but is not critical to 
the decision making process.

the exception is when a disambiguation is required.

as for improving the labels, i'm not sure how we can improve the names of the 
applications people install. Acroread, indeed.

now, you're a year too late on this discussion. we had conversations about 
this endlessly until i finally said "enough, it's not actually going any 
further at this point". i'm really not open to having those same discussions 
yet all over again just because someone suddenly noticed. we've been through 
this all more than once, including every point you raised here (and probably 
others), and the current design is a conscious compromise between the 
aesthetic we are aiming for and the real world needs of our users as defined 
by real feedback and even some testing.

-- 
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: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20091113/cb447f9d/attachment.sig