[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: close (x) widget and managing objects
From:       "Diego Moya" <turingt () gmail ! com>
Date:       2008-11-18 22:44:03
Message-ID: 11ee04940811181444u6a4298agf707ae3a87d14c86 () mail ! gmail ! com
[Download RAW message or body]

2008/11/18 Esben Mose Hansen <kde@mosehansen.dk>:
> I understand you are frustrated at not getting a sympathetic reaction to
> your critique, but these gadgets have been existing and working for a long
> time now. Even if you think you have something better, you will have to
> understand the reasons and metaphors a bit better before you denounce us all
> as fools and idiots :)

It's a shame that the radically different starting positions are
getting in the way of a meaningful discussion. Maciej has brought out
some really good insights on the KDE plasmoids interface, from the
point of view of user-centered design. You are essentially dismissing
his insights because you don't get why these concerns are important,
but you're dismissing them with arguments that are not at all relevant
to Maciej's discourse (I think "implementation details" says it all).

As a programmer myself, I fully understand your position. For you, a
desktop environment is a simulation of a programmed world, with its
own rules of physics and its predefined behaviors for everything in
it. So if something is a plasmoid, it's a plasmoid. And it doesn't
make sense to think of it as a window, which is a different something
(for a programmer, that is).

Unfortunately, if you want to create a usable environment, you'll have
to completely rethink that point of view, or at least listen with
respect to the people who share the view of the common user. For a
computer user who is not a programmer, that view of simulated objects
in a running environment makes no sense at all. Think of it for a
moment: to share the "running simulation" view, one needs to
understand how programs run inside the computer's memory. And for
that, one has to be a programmer.

If you're not a programmer all you can see are rectangles containing
information and handled through the input devices. You don't come to
see in the interface which is the parent class that implements the
behavior of a particular rectangle. In the end, in the user's mental
model there's little distinction between the rectangle that shows a
window and the rectangle that shows a plasmoid - both are data widgets
handled with the same input device. So it would make sense for them to
be handled in consistent ways.

If you have a useful data widget that you rely upon for your everyday
tasks, you'd expect it to have all the available repertory of actions
applicable to your useful widget (be it maximizing, attaching to a
panel, rotating, shadowing). And you won't understand why some actions
only apply to one of your useful data widgets and not to the other.
(Even if your helpful programmer tries to explain it with weird
metaphors that make little sense for you). From a usability POW, only
a highly consistent environment (where all the information bits can be
handled with the same interaction tools) will make sense.

So I think my point can be summarized to this: you can defend your
current metaphors (and their current implementations), but don't be
surprised when someone thinks that those metaphors are not the best
ones for the average people, because they are not (for reasons
grounded in user-centered design and cognitive psychology, not
interface programming and simulation toolkits).
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]