kubuntu kdebase patches to plasma

[Celeste Lyn Paul]

On Fri, Nov 13, 2009 at 1:50 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> 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.

This isn't a new discussion wrt Kubuntu and we've more than "suddenly
noticed". This is the third? time we've submitted the patch with our
arguments for changes. One, it is part of our process since we don't
want to deviate from upstream as much as possible, and Two, we really
do think this patch is an improvement. We are free to defend it and
you are free to ignore it as usual.

>
> --
> 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
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>



-- 
Celeste Lyn Paul
KDE Usability Project
KDE e.V. Board of Directors
www.kde.org