From: strobl@gmd.de (Wolfgang Strobl)
Subject: Re: More Defense of CLI (there, I changed the subject ... )
Organization: GMD, Sankt Augustin, Germany
Date: Fri, 16 Oct 1992 22:57:07 GMT

In <_!2zygn@rpi.edu> johnsd2@jec325.its.rpi.edu (Daniel Norman Johnson) writes:

>In article <strobl.719069866@gmd.de>, strobl@gmd.de (Wolfgang Strobl) writes:
>|> In <1992Oct13.202113.23250@gvl.unisys.com> dave@prc.unisys.com (David Lee Matuszek) writes:
>|> 
>|> [...]
>|> 
[...]
>|> The question isn't whether you - after a lot of training - can
>|> use a mouse without thinking about it. The question we where
>|> discussing is whether people can use a keyboard in a similar
>|> way or not.

>You mean, point at things with it? Sounds tricky... :)

Actually, it works just as well as by pointing the mouse  
at the screen. At least if you computer happens to have
a touch-sensitive screen. 8-)

>|> My position is that I know that I can, and that
>|> I'm not the only one with that capability.

>Indeed. Took me a lot longer to learn to type than to learn to
>mouse. Do you mean to imply that the reverse was true for you?

Hard to say, because I learned to type before I learned
to use the mouse.

But I watched my two childs how they learned to use the mouse and
the keyboard. I didn't use a stopwatch, but simply noticed 
which errors they made and how they used these input devices.

I got the impression that using the keyboard for certain
simple task wasn't much different from using the mouse, 
and that the time to learn how to use the keyboard wasn't
longer than using the mouse. In certain cases, I noticed
that without further instruction and training, a child may 
have more difficulties to perform an action with the
mouse than with the keyboard, even in areas where 
using the mouse is advocated here.

An example: moving the selection point to a certain
place seems to be more difficult to grasp and to 
perform with the mouse that with the cursor keys.

Or - another example - in a game which offers 
two ways to stop the game (essential to
be able to play it, at least for childs )- namely
an icon and a hard to find function key (F11), 
they constantly both prefered to use the function key.

On the other hand, they both had big fun moving 
windows around or to resize them, using the
mouse only. 

>|> Moreover, I prefer
>|> to utilize that capability over the same capability to operate
>|> a mouse, sometimes, and don't want a system to actively prohibit
>|> my intention to do so, for whatever reason. 

>"actively prohibit"? 

Yes, by not providing a decent keyboard interface in the UI,
for "religious" reasons. One of the interface guidlines for
MS-Windows says that an application should provide a full
keyboard interface, i.e. that it should allow proper use
without a real pointing device. Most Windows programs follow 
that rule, by using and providing building blocks which
have a well thought out keyboard interface. 

Windows proves that it is indeed possible to provide
both a good keyboard *and* a good mouse interface.

Apples "Human Interface Guidlines", on the other hand, don't
have a similar rule. To the contrary, they state "the pointing
device is used for pointing and manipulating, user's don't have
to use the keyboard to type commands. The keyboard is used 
primarily for entering text." The following rules in that book
define a very minimalistic set of actions to be performed by the
keyboard, and forbid other usages of the keyboard. 

>Does it short out your keyboard or something? :)

In a way, yes. When sitting before such an interface,
sometimes I feel like having one hand tied to my
back.

>I suppose you mean it doesn't provide you with enough keyboard shortcuts.
>If that bothers you, you can put them in. (or just not use a Macintosh.
>I can certainly see how a keyboard addict would not like the Mac :) )

No, I don't want more shortcuts. I don't like shortcuts, and don't
use them very often. I want a keyboard interface which replicates
the pointing device interface. I want to use the keyboard to 
browse through menus, for example, not just to have a quick 
access to some hidden submenu entry. 

>It certainly doesn't bother me, or any other Macheads that I have
>noticed around here.

Well, people are different. I never said that you should be
forced to use a keyboard.

[...]

>|> >Humans have a surprisingly limited "mental bandwidth."  The
>|> >psychologist George Miller published, in 1956, an article entitled
>|> >"The magical number seven, plus or minus two: some limits on our
>|> >capacity for processing information."  (Psychological Review 63,
>|> >p. 81-97).  Citing a variety of experiments, he showed how even trivial
>|> >tasks took mental processing power away from other, concurrent tasks;
>|> >a lot of work has been done since on "cognitive load."  Ignore this
>|> >work at your own risk.
>|> 
>|> >I personally use the commoner keyboard shortcuts all the time, such as
>|> >control-C and control-V, but I don't think I have ever used them
>|> >without thinking of the letter (except in highly repetitive tasks,
>|> >where I fall into a physical pattern).  
>|> 
>|> Have you ever played Tetris? Of course, its highly repetitive, but
>|> so are a lot of other activities which one has to perform on a
>|> computer. How would you implement a mouse interface to Tetris?

>Games are not intended to be as easy as possible to  play.

You misunderstood my question. Design a mouse based interface
to the TEtris game, as easy to use as you like. Just don't
change the problem definition. 

>You COULD design a very easy tetris interface w/ the mouse-
>just drag teh pieces into place, command click to rotate
>them, something like that. But that would ruin the game. It
>would be far to easy.

No. You changed the problem definition, not just the interface only.
THis, of course, ruins the game.

[instruments...]

>|>             Of cause, this whole imagined discussion
>|> is totally absurd, just like our arguing about which 
>|> interface, keyboard or mouse, is better. 

>It seems to me that one could use less "bandwidth" than the other,
>but Im no musician I coulnd't say which.

>However, this is going to go nowhere fast. You don't believe
>in this congnitive limitation thingy, whereas I (we?) do. Without
>evidence (I haven't any handy, do you?), we won't convince each other
>of anything.

Oh, I believe it (well: consider it to be valid, probably). I 
just don't find it applied well. "Cognitive load" here is just
a buzzword as "intelligence quotient" is one. It is usefull as
a limited technical term in science, but it is as sensible to 
compare user interfaces from a users point of view, as 
it is wise to use an IQ to compare childs. It is NOT.

>|> >Hence, I find the argument perfectly plausable that keyboard commands
>|> >seem faster than mousing (but aren't) because the increased mental
>|> >effort "fills up the time," thereby distorting one's perception of
>|> >time.  Certainly, I have yet to see any alternative explanation.
>|> 
>|> I find that argument quite implausible, because its one of those
>|> arguments which have a built-in catch-22. You can't argue
>|> using your own experience, because the theory says that it is 
>|> misleading, and you can't make an experiment, because
>|> the whole scenario is not well defined. The only actions 
>|> where using the stopwatch as a measure makes sense
>|> are those which are repetetive, and - surprise - just those
>|> are an exception to the theory.

>Nasty isn't it? But by repetive we mean that you do the same physical
>action (extend that finger, etc..), not the same TASK.

>A test that seems reasonable to me is this: In a word processor,
>set up a document containing, on separate lines, the words "bold"
>"italic" "bold italic", "outline" (etc, etc). Provice such a document
>to someone using a GUI word processor and someone using a character
>based one. Instruct them to chang the styles of the words to match
>the words ("bold" is given the bold style, etc); Time how long it takes
>to do this.

I don't consider this test to be reasonable in the context of
what we discuss, for two reasons.

 * I never argued that a "character based" editor would be superiour
   to a GUI based one. So the experiment tries to prove (or disprove)
   something what wasn't claimed at all.

 * It shows a very artificial situation, which seems to be constructed
   in a way which prefers a certain outcome. A more valid test would
   be to ask somebody to change all proper names in a text to bold, or
   to underscore all occurences of the words "mouse" and "keyboard".

>You could also do it with jus tone, GUI word processor for both dudes.
>One guy is instructed to select the styles with the keyboard, the other
>with the mouse. We'll be nice and provide a word processor that does
>offer the standard shortucts, which are nice and short. (some have
>rotten shortcuts. shift-command-B for bold, yeah thats it..)

That's a bit better.

>Of course, this still permits the user to use the mouse to select text.
>Perhaps we could instruct the user to use the keyboard for that too. Hmmmm.

Why not give one person a GUI editor which provides both a keyboard
*and* a a mouse interface, and the other one the very same editor,
but with a disabled keyboard interface. Now give them the task
to copy parts of the content of a spreadsheed page to a new
letter and to formulate and add a paragraph which describes the copied 
table. After both are finished, measure how fast they did 
it, which letter looks better and which one contains less
errors, by counting spelling mistakes and stylistic and
semantic errors.

>Anyway I think I have beat your Catch 22, except for the
>part where "the whole scenario is not well defined". I dont
>understand that part.

See above. We both tried to design an experiment which
tries to measure the very "quality" we where diskussing 
in this thread. Yet, I came up whith an experiment which 
is very different from yours.

Wolfgang Strobl
#include <std.disclaimer.hpp>
Newsgroups: comp.sys.mac.advocacy