From: kanefsky@halcyon.com (Steve Kanefsky)
Subject: Re: More Defense of CLI (there, I changed the subject ... )
Organization: The 23:00 News and Mail Service
Date: Tue, 13 Oct 1992 22:20:51 GMT

In article <6203.2adadad3@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
>In article <1992Oct12.221502.12684@nwnexus.WA.COM>, kanefsky@halcyon.com (Steve Kanefsky) writes:

>> 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 
>
>Not true.
>
>A two-year old can use a mouse. You don't need to even spell or understand
>what letters are to use a mouse. All you have to do is move it like you move
>it on the screen. Simple.
>
>> (where you might have to pick the mouse up if you run out of room on your 
>> mouse pad, etc.)  
>
>This is a trivial operation that is easily learned. 


It's somewhat easily learned, but it does have to be learned, even
by people who are experts at reaching out and grabbing real physical
objects. I've taught several hundred people (individually and in
classes) how to use the mouse, and it takes a little while before
someone gets the hang of it.  For some people it takes quite a
while.  Perhaps you've been using a mouse for so long you've
forgotten? 


>> Note that anyone can press a key on a keyboard with no practice, but it 
>> takes some practice to use a mouse.  
>
>This completely fallacious. What are you measuring here? You can teach someone
>to meaninglessly press a key, versus using a mouse proficiently? 

If I teach someone that "C" stands for copy, then reaching out and
pressing C is certainly meaningful.  On the other hand, a menu
choice isn't always meaningful.  Sometimes it isn't obvious which
menu a command belongs in or what the command should be called.  My
point is that a certain number of common commands can be assigned
keyboard shortcuts, and those shortcuts can have a meaningful
association with the command itself. Pressing a key (or even two) on
the keyboard is almost always faster than using a mouse to select a
menu item.  For some of us it's dozens of times faster.  I admit
that it takes longer to compose a complex command on a keyboard than
to choose an item from a menu, but on the other hand you can express
more in a command than in a menu choice (it would take several large
complex dialog boxes to express everything you could express in one
moderately complex command). 


>How about we compare the amount of time it takes to become proficient with 
>either system. It takes months of practice to become a proficient typist.
>It takes weeks merely to learn where all the keys are. You can learn to mouse
>in a few minutes, and become completely proficient within a few weeks!

It doesn't take any time to learn how to press "C" on the keyboard. 
It may take a minute or two to learn how to hold down the command
key and press C, but that's still less time than it takes to learn
the mouse.  Besides, my argument is that it's faster for
*experienced users* to use keyboard equivalents. 


>> If I learn to associate "X" with cut and "C" with copy 
>> I can reach out to the keyboard and grab the command I want in 
>> practically no time.  
>
>Except that under Windows, the association of "X" with Cut and "C" with Copy
>doesn't exist. Cut could be Ctrl-X or it could be Shift-Del, or it could
>be ALT-ET (except this doesn't work in all cases). This inconsistancy
>inhibits learning, so you never acheive the level of association necessary
>to beat out the mouse.

Couldn't agree with you more here.  I _HATE_ Windows.  I was talking
about the desirability of keyboard shortcuts and a command-line
interface as *alternatives* on the Mac (I would never suggest
replacing the GUI --only supplementing it). 



>> In addition to the extra cognitive effort of manipulating the mouse 
>
>The cognitive effort is not different than that required to reach out and
>grab a coffee cup. You can do this without thinking. It is a low-level 
>operation that takes place with little mental effort.
>
>> you have to remember what menu the command is in 
>
>No you don't. You don't have to remember at all. All you have to do is
>RECOGNISE. Humans are terrible at remembering things. They are excellent at
>recognising things. 

OK, so if I give you a page full of phone numbers -- one of which is
yours -- you'll be able to recognize it faster than you could
remember it? 


>> and you may have to scan all the items in the menu carefully for the 
>> command you want 
>
>This is true only for the first few times you use a new product. We're 
>speaking of reasonably proficient users, who are familiar with the product
>(or similar products). 
>
>The beauty of the Macintosh is that you DON'T have to root around to find
>the "Copy" menu item, because it is ALWAYS under the Edit menu. And the
>Edit menus is ALWAYS in the same place. Consistancy.

But many programs add other commands to the edit menu (though the
edit menu is more static than other menus), so the position of the
copy command could change because of other menu items being added
and deleted dynamically.  And of course there are still plenty of
inconsistencies.  What is called "place" in one program might be
"import" in another or just "open" in another.  So the graphical
interface doesn't guarantee consistency.  In fact, the amount of
consistency is completely independent of the type of interface.  You
can have a completely consistent CLI (where -o always specifies an
output file, for example) or completely inconsistent GUI's (Windows
-- need I say more?)


>> (especially in programs that change the menu structure according to context).
>
>I have yet to see a Macintosh program that changes the location of Copy or
>the position of the Edit and File menus. If you can find one, I submit that
>the authors of these programs should be shot.

The cut, copy, and paste commands in the edit menu are pretty stable
because new commands tend to get added *below* those commands.  But
there are plenty of other commands in other menus which appear and
disappear, which effectively changes the position of other commands.


>> 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.  
>
>Good point. I do this often. If I had to use the keyboard for all operations,
>I'd be quite a bit slower.

I agree.  I want both.  Neither one is faster all the time.  That's
all I'm saying. 



>> 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.  
>
>It wasn't my example. It was the example of these rabid Windows users who
>appear to infest comp.sys.mac.advocacy. They seem to be of the opinion that
>this menu navigation is actually faster and easier than using the mouse.

Yeah, once you get beyond something like command-C, a keyboard
shortcut for a menu choice doesn't look so great.  Add to that the
fact you have to remember variations for different programs, and
it's a real mess.  I would only use this kind of keyboard "shortcut"
as an emergency measure if my mouse broke!


>> 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.
>
>This is obviously an ad hominem argument by taking a rational suggestion
>to its irrational extreme. I suggested no such thing. 

Well, you biased the experiment towards your own desired result, by
not using a reasonable set of keyboard equivalents.  I was just
exaggerating to make a point (I thought it was kinda funny too :-) )


>>>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.
>
>I submit that Y is too trivial a task, and one that is selected to enhance
>the results from the keyboard. Why did you paste 10 times? Why not paste
>just once? 

Because it's something I do fairly often.  Even if we're talking
about copying and pasting once, it's faster to use cmd-X and cmd-V. 
You can get ready to hit cmd-X while you're selecting the text with
the mouse, and you can get ready to hit cmd-V while you're moving
the cursor to the desired location (again using the mouse).  Doing
it all with the mouse involves moving the mouse wildly all over the
screen, even though there's only a tiny distance between the source
and destination locations.  Also, I claim that it's often faster to
use cursor keys if you want to move exactly one line down or one
character to the left or right (since you may miss with the mouse a
reasonable percentage of the time)


>Further, I don't believe your experiment included the actual SELECTION
>process. You'd need to try a variety of selection sizes, including selections
>that aren't visible from the screen.

Well, there are keyboard shortcuts for selection, and there are even
cases where it would be faster to use the keyboard (perhaps to
select one character in a tiny font, or to select one English
sentence if the software let you do that).  Nevertheless I usually
use the mouse to select text.  That doesn't invalidate my claim,
because I still used the keyboard to my overall advantage.


>A better test would be to have users find a particular paragraph within a
>text, select it, cut it and replace it at a different point in the text.
>This would cover all the basic skills, and remove this rubbish of pasting
>10 times.

Maybe I'm the only one, but when I'm writing programs I often need
to make several copies of a line of text (then I usually have to
make a small change to each one).  However, as I said above, you can
accomplish the task you mentioned above faster with a combination of
keyboard shortcuts and mouse gestures faster than with mouse
gestures alone.  That still proves that replacing mouse gestures
with keyboard shortcuts speeds some things up.


>> You seem to claim that M(X,Y) < K(X,Y) for all X, Y.  I have just proven
>> you wrong.
>
>For the specific, limited case of a single Y, perhaps so. But for the generic
>case of all computer tasks Y, not at all. You've shown me nothing. (Except
>ways to improve your tests)

Well, hopefully this article gave you an idea of how widespread the
benefits of keyboard shortcuts are.

--
Steve Kanefsky

Newsgroups: comp.sys.mac.advocacy