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

List:       kde-usability
Subject:    Two different approaches to plasmoids (was Re: close (x) widget and
From:       "Diego Moya" <turingt () gmail ! com>
Date:       2008-11-19 12:51:07
Message-ID: 11ee04940811190451y46a1a989if0fba529f55e4f9e () mail ! gmail ! com
[Download RAW message or body]

Q- How many surrealists does it take to screw in a lightbulb?
A- Fish.

I think you guys are walking in circles in your discussion on
plasmoids. Maciej and Aurelien bring perfectly valid concerns about
plasmoids as a general widget integrated in a windowing environment,
while Aaron and Esben reply with valid concerns about plasmoids as a
particular programmed object inside a well-developed codebase. None
seems to grasp the subtleties involved in the other's viewpoint, and
hilarity ensues. The first ones only apply to the interface as seen by
non-programmers, the second only as seen by KDE developers.

The conversation has an overall surrealist effect. You're talking
about essentially the same thing, but you could rather be comparing
apples and Swiss cheese.

Could you guys call a truce and try first to understand what the other
people is arguing about before accusing the other of missing the
point? Reality is, you're here mixing design proposals for radically
different sets of users and complaining when those proposals don't
make sense for the other set.


2008/11/18 Maciej Pilichowski <bluedzins@wp.pl>:
> Nope, it is more and more clear you are focused on internals, we are
> talking on different levels; code looks good, if user cannot handle
> 150 methaphors and stream of new interfaces, well, user fault. Then
> Apple, not Apple, comes up with something simple, gather 98% of the
> market, and "everybody" looks surprised -- how it is possible, after
> all our code is better?
>
2008/11/19 Aurélien Gâteau <aurelien.gateau@free.fr>:
> I never claimed to see plasmoids as windows. I say: plasmoids and
> windows share common properties. These properties should be handled the
> same way.
>
2008/11/19 Esben Mose Hansen <kde@mosehansen.dk>:
> I said what  I, as a user, would expect. There is no use arguing against
> facts. You could argue that I would be an unusual user, which is fine, but I
> simply answered your implied question.

Those defending a pure interaction-centered approach to plasmoids
design see their similarities to windows and want to fit them in the
current users mental model. Developers, in turn, want users to treat
them as the wholly new created objects that they are in code, and
think that you can educate users to treat them as different entities.
Problem is, none of those positions seems on the right track to create
a really good interface.

You should first define which are the different target users for
plasmoids, find what they have in common, and design their possible
interactions around those commonalities. Right now you're first trying
to define what a plasmoid "truly" is, and designing its properties
around that preconception. Bad design strategy, IMHO.


2008/11/19 Maciej Pilichowski <bluedzins@wp.pl>:
> On Tuesday 18 November 2008 22:31:17 Esben Mose Hansen wrote:
>> Really, plasmoids are not windows. They are desktop gadgets.
>
> Names are not advantages or disadvantages of anything.

It's not just a name change. Plasmoids in its current form are quite
different beasts than windows, even if they serve the same purpose in
the users mind. They have evolved to solve a different technical
problem inside the codebase and thus it will never be easy to reuse
the same code to implement the behaviors they have in common.

It's unfortunate that they share the same environment while somehow
having overlapping roles, because this is a source for confusion. But
that's not going to change in the future.

The best strategy now should be accommodating them to share the same
environment in the most useful and non confusing way. Virtual
desktops, plasma activities and the Zooming Using Interface are
currently lacking a viable vision that turns them into powerful
task-oriented workspaces. Integrating plasmoids and windows management
is an opportunity to create an innovative tool to solve that problem.
Our efforts should go in that direction instead of criticizing the
overall approach followed till now in the Plasma project. I think
Aaron has sometime in his blog asked for help to develop this vision?


2008/11/19 Esben Mose Hansen <kde@mosehansen.dk>:
>> You are falling into two extremes -- you want to be either plasmoid
>> behave completely different or completely the same.
>
> Yep. Consistency for me as a user is more important than unification.

What is consistent for you is different to what is consistent to a
non-programmer. This is what Maciej is trying to explain, and you
refuse to understand ;-)


2008/11/19 Esben Mose Hansen <kde@mosehansen.dk>:
> In any case, I did my best to explain the reasons to you. I gather that you
> are simply not interested in understanding, and for my part I am not
> interested in arguing with someone who refuses understanding.
Wrong deduction. Simply saying "you have a different mindset than
mine, so I conclude you have no interest in understanding me" strikes
me as a close-minded attitude. As I hope I've explained above, what's
going on here is a severe misunderstanding (in the two sides) because
of radically different interpretations of the same desktop element.


2008/11/19 Esben Mose Hansen <kde@mosehansen.dk>:
> At some point, there are too many exceptions, and it is better to introduce a
> new concept. That is e.g. why radiobuttons and checkboxes looks and behaves so
> differently.
They appear in forms, they change state on a mouse click, they consist
of a small basic form accompanied by a text label. So how are so
different again?

Even if they are different elements, they belong in the same class and
so they share a LOT of properties in common. This should also be true
between windows and plasmoids, because they belong in the class of
rectangular stand-alone canvas that can hold generic information and
are subject to direct manipulation.


2008/11/19 Esben Mose Hansen <kde@mosehansen.dk>:
>2008/11/19 Maciej Pilichowski <bluedzins@wp.pl>:
>> Because you wrote something that sounds like apology, that the UI is
>> bad, but since it is rarely used...
>
> You missed the point again. It is no apology, it is a reason. You interact
> with plasmoids all the time, but you rarely move, add or close plasmoids,
> because they are simply a part of your desktop setup. I mean, how often do you
> resize your panels anyway? Or even change the background?

You're putting the cart before the horse: of course you won't resize
or move panels often if they have a difficult interface for moving,
resizing or otherwise changing them.

But in doing that you're severely limiting its possibilities as a
universal interaction device. If plasmoids had easy manipulation (say,
as easy as those of a window) then users *could* do it often and use
plasmoids in workflows that involved frequent reposition, creation and
dismissal. This is what your preconceptions are biasing you against.

*****************************************************************************************

As an exercise to center the discussion and avoid you going around in
circles, I suggest  checking each of your proposals and arguments
against these two extreme target users:

1- The non-programmer power user
* Works as a freelance designer for a start-up.
* Has never seen a line of code in her life.
* Loves how all the features in his Apple interface work together
allowing her to create her own workflows.
* But has heard about KDE4 and introduced to the Free Software
movement, and is enthusiastic about the idea. She has installed a
KDE-based distro and is trying to find how her previous working
routines fit in the new interface.

2- The KDE core developer
* Has been working with KDE since it had a 1 in front of its version number.
* Knows where is located each line of code that is triggered by each
interface event.
* If the default behavior does not match his personal workflow, he
knows exactly which configuration file to tweak or preference to
activate that deactivates that default.

Hope this helps! :-)
_______________________________________________
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]