From: kanefsky@halcyon.com (Steve Kanefsky)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: More Defense of CLI (there, I changed the subject ... )
Date: 12 Oct 92 22:15:02 GMT
Article-I.D.: nwnexus.1992Oct12.221502.12684
Organization: The 23:00 News and Mail Service

In article <6156.2ad55d98@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
>In article <TOMSTER.92Oct7113657@wpi.WPI.EDU>, tomster@wpi.WPI.EDU (Thomas Richard Dibble) writes:
>> In article <1992Oct7.142810.13778@gvl.unisys.com> dave@prc.unisys.com (David Lee Matuszek) writes:
>> 
>>    You are correct in that there are surveys showing that users think
>>    using command keys is faster.  There are also experiments showing that
>>    mousing is faster.
>> 
>> As there are experiments showing keyboarding is faster.  It all depends on
>> the subset of commands you use -- if you use a subset of commands the GUI
>> programmer anticipated you would use, therefore putting them in the top
>> slots of all his programs, you will mouse very quickly and efficiently.
>
>As a interface designer, I consider putting items at the top of windows
>and dialogs, so the user will notice them first. However, I don't usually
>consider this for menus. I would note that it is best to keep menus as short
>and as concise as possible.
>
>This is also the second time I've noticed a CLI advocate using this 
>"programmer anticipation" argument. As a designer, you don't always have to
>anticipate everything, because sometimes your intuition is wrong in the worse
>way. The thing to do is user testing. (You can't always test everything, but
>you should remember to try) I remember a particular article by Tog describing
>methods to ask the user on an Apple II if he had a color monitor. They tried
>six different solutions to this problem before finding one that worked 
>reliably through user testing. 
>
>You are confusing the term "experiment." A true experiment is designed to prove
>a hypothesis false. In science, you can't actually prove anything as being
>true, you can only show which theories are false.
>
>So, if you design a set of tests to "prove" a hypothesis (eg to show that
>graphic user interfaces are faster) then you prove nothing.
>
>However, in the cited cases below, the experiments were used as a basis of
>discovery, not "proof." The conclusion is based on experience over a large
>number of trails.
>
>Just because it comes from Apple doesn't immediately disprove the results.
>If you talked to Tog, you could probably learn enough to recreate the 
>experiments. Knowing how the experiment was performed gives you the opportunity
>to a) re-create the experiment and verify the results, b) change the methods
>to see how they affect the results. This way, you could either show the results
>were erroneous, the methods were erroneous, or uphold the findings.
>
>But you can't dismiss the results of experiment just because you don't like
>or agree with what was found. That's not how science works.
>
>The cited experiments:
>
>>    In his book on interface design, Tognazzi writes: "We've done $50
>>    million of R&D on the Apple Human Interface.  We've discovered, among
>>    other things, two pertinent facts:  1) Test subjects consistently
>>    report that keyboarding is faster than mousing.  2) The stopwatch
>>    consistently reports that mousing is faster than keyboarding."
>> 
>> In the MacOS?  Of course mousing is faster.
>
>Ah! So the MacOS is faster than a CLI. You agree. End of debate. (1/2 <grin>)
>
>Note the dichotomy. Users thought the keyboard was faster. Experiments proved
>it wasn't faster.
>
>(Now, to back up a bit:)
>
>> But if you have to search for these commands -- say they are at the bottom of
>> the menu list, or at the bottom of a heirarchial menu system -- you will
>> not mouse very efficiently at all.  
>
>Assuming you know where the menu items are, there's more distance to be covered
>with the mouse, but the mouse also accelerates (unless you are in tablet mode).
>This fractional amount of time to move the mouse isn't significant.
>
>> Alt-<FX> is just as easy to type as Alt-<FN>.  
>
>(Ah, the fundamental fallacy!)
>
>> the 'New file' option on the File menu is much easier to hit
>> than the Exit menu item, because the 'new' item is highlighted already when
>> I click on the 'File' menu.  
>
>In the MacOS, the File item is highlighted. You have to lower the mouse to
>highlight the "new" item.
>
>The problem with this comparison is you are dwelling on only the MECHANICS of
>entering or selecting the command. You've not addressed the COGNITIVE part
>of the operation. 
>
>With the keyboard, you have to think of where the menu is, what it is called,
>recall the path to that item, recall (or synthesize) the shortcut, and then
>type.
>
>With the mouse, you have to think of where the menu is, then you REACH OUT
>AND GRAB IT. There's almost no cognitive load.

This is utter nonsense.  They keyboard is, in fact, easier to reach out
and grab than a menu on the screen, because you are literally
reaching out and grabbing it, rather than going through the mouse (where
you might have to pick the mouse up if you run out of room on your mouse
pad, etc.)  Note that anyone can press a key on a keyboard with no
practice, but it takes some practice to use a mouse.  If I learn to
associate "X" with cut and "C" with copy (not exactly a great mental
leap) I can reach out to the keyboard and grab the command I want in 
practically no time.  In addition to the extra cognitive effort of
manipulating the mouse (because it's a less-than-perfect analog of
actual human motion), you have to remember what menu the command is in
(a somewhat arbitrary assignment in some cases) and you may have to scan
all the items in the menu carefully for the command you want (especially
in programs that change the menu structure according to context).
Furthermore, you can pipeline or parallelize keyboard commands with
mouse movements.  Suppose you have a dialog box on the screen with
several fields, and you want to paste a value into each field.  While
I'm mousing from field to field I can use the keyboard shortcut to paste
into each field.  Alternately, I can use the keyboard shortcut for
moving between fields and use the mouse to paste.  Best of all, I can
use one hand to tab between fields and the other to use the keyboard
shortcut for paste.  There's no way to do anything like that with the
mouse.

Your example of using keyboard commands to navigate through menus is
almost guaranteed to be worse than mousing because it imposes many of
the disadvantages of mousing.  You might as well insist that I use easy
access to control the mouse pointer from the keyboard.  And then I can
insist that you test the speed of the mouse-based interface by typing
command lines with the Keycaps DA.


>Until the CLI camp can come up with results from such experiements, we must
>conclude that using the mouse (and a visual interface) is faster than using
>a CLI. End of debate.


OK, here is my experiment:

Define a function K(X,Y) as the time it takes person X to perform task Y
on the keyboard.

Define another function M(X,Y) as the time it takes person X to perform
task Y on the mouse.

Let X be me and let Y be the task of copying a line of text in Microsoft
Word 5.0, then pasting 10 times.

My experimental results show M(X,Y) = 2.5 seconds and K(X,Y) = 14.7
seconds.

Since 2.5 < 14.7, there exists X, Y such that K(X,Y) < M(X,Y)
    
You seem to claim that M(X,Y) < K(X,Y) for all X, Y.  I have just proven
you wrong.

I'll leave it as an exercise to show that the set
  { X,Y | K(X,Y) < M(X,Y) } is infinite (but probably not uncountable)
  
(hint: use induction)


--
Steve Kanefsky