From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: More Defense of CLI (there, I changed the subject ... )
Date: 9 Oct 92 10:23:19 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

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.

So, it makes no difference how easy it is to type "ALT-FN" or "ALT-FX" 
because you have to factor in the cognitive time to remember and recall
each shortcut. Typing is not the item that takes time. It is this cognitive
load that takes time.

Hence the dichotomy. The keyboard SEEMS faster, because your noggin' is so
busy with these cognitive loads. The mouse SEEMS slower, because your
noggin' has little to do during that mouse movement time. The stopwatch
shows the truth.

>    However, if you wish to claim that
>    keyboarding is _actually_ faster than mousing, the ball is in your
>    court; let's hear about the _experiments_ that show this.
> 
> Well, that's what I just asked for, now, wasn't it?

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.

-- 
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.

Newsgroups: comp.sys.mac.advocacy