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

List:       kde-usability
Subject:    Re: NWI: metaphor needed?
From:       Diego Moya <turingt () gmail ! com>
Date:       2009-07-07 16:39:17
Message-ID: 11ee04940907070939p5a39215ctc20e869eef69dc40 () mail ! gmail ! com
[Download RAW message or body]

2009/7/7 Matthew Woehlke wrote:
> Diego Moya wrote:
>> It's similar to the Python language design guideline: "There should be
>> one-- and preferably only one --obvious way to do it". If done well,
>> it actually should *help* learnability - as you only need to learn one
>> procedure.
>
> Interestingly, I suspect that runs somewhat contrary to the UNIX
> philosophy ;-). Or at least to practice.
Not necessarily.  UNIX advocates having each tool be very good at one
single task; so if you know there exists one tool for the task you
want to accomplish, it should be obvious which task should be used,
even in UNIX (at least for simple, non-decomposable tasks). But keep
reading - the design school I'm explaining doesn't the stop at the
availability of several competing tools, but reaches the low-level
interaction too.


>
> Now I am confused; in principle I agree that multiple /methods/ of doing
> a task are unneeded and possibly even undesirable. My reaction was more
> to only one way of /activating/ a given method. Is it okay to have a
> shortcut key, button, and menu item, all of which perform the /exact
> same/ function?
>
> (Consider something as simple as "copy", which is ctrl-c and Edit->Copy,
> and may have a toolbar button. "Under the covers" they probably all fire
> off the same KAction. Is this okay?)

You actually got it backwards :-)
This is exactly what Jef Raskin opposed to. He defended, and it's
difficult to argue otherwise, that having a single activation point
for each function is *a very good thing*, and having several ones is
quite bad, for a reason: a single method creates habituation.

If a function is always called through the same activation method, it
will become integrated into unconscious reactions (call it "muscle
memory"), and will allow the user to concentrate on the
high-abstraction layers of the task, just like playing the piano or
riding a bicicle. The opposite is also true: if there are several ways
to activate the function, the user will *always* have to decide which
one will select, in every single use for it. This wastes "brain"
resources and delays the task by several tenths - or even whole -
seconds, and even worse, it interrupts the user "flow" of conscious.

Of course the resulting design is very different to the desktop GUI
metaphor. Funny thing is, it's actually very similar to the Command
Line Interface of the UNIX shell, minus all the wrong design decisions
that make the shell very difficult to learn and use. Shell requires
recalling commands instead of assisting recognition like GUIs do. But
graphical command lines (GCLIs?) that help recognition do have both
the versatility of CLIs and the learnability of GUIs, sharing all the
benefits and few of the drawbacks.


> If all humans shared the same knowledge and education, I might agree...
> but we don't. Heck, this breaks as soon as even /one/ person starts
> working on non-identical /tasks/, because the best solution for Task A
> may not be best for Task B.

That's why you'd have a tool for task A and a tool for task B, both
available at any place of the system, without requiring to open
separate applications A and B. High level tasks aren't constrained by
this design to have one single tool for all them, only low-level
interactions.
_______________________________________________
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]