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: Thu, 15 Oct 1992 19:49:26 GMT

In article <6211.2adc2d3c@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
>In article <1992Oct13.222051.29320@nwnexus.WA.COM>, kanefsky@halcyon.com (Steve Kanefsky) writes:
>> 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? 
>
>Compare with the previous comment, where you insisted that the keyboard
>was easier than the the mouse for this operation of activating a visible
>menu.

I don't know what you're talking about.  I never insisted that.  I do
claim that a keyboard shortcut can be easier than the mouse for
specifying an operation such as "copy"  No menu is involved at all.
Once simply remembers that "C" is for "copy."

>I submit that the keyboard is much more difficult to learn, and takes
>substantially more time before people get the hang of it. By a factor of
>10 or more. Perhaps you've been using a keyboard for so long you've
>forgotten?

Well, the problem we're having here is what it means to "use a keyboard."
Pressing a key instead of using a selection from a pull-down menu is one
way to use a keyboard.  Understanding a language and being able to press
any one of hundreds of keys or key-combinations at the rate of 300 per minute 
to express things in that language is another form of using a keyboard.
I've been using a keyboard since 1982 or so, and a mouse since 1984
(when I bought a 128K Mac), so I don't think I should be overly biased
by a lack of experience with one or the other.


>>>> 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.  
>
>Go back up and look at the first quoted part. The issue here is NOT the
>presense or absence of menus, or their meaning. The issue is using the
>keyboard or the mouse to invoke a visible menu.

That wasn't the issue I was discussing.  I was discussion the execution
of commands.  Pull-down menus are one way to do it, keyboard shortcuts
are another.  There's no reason a menu has to be involved when you use a
keyboard shortcut.  Part of the disadvantage of the graphical method is
the overhead of the graphics.  Why should I have to pay that price when
I don't need the menu.  Windows may do that but the MacOS doesn't.


>> 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. 
>
>You contradict yourself. If a command is common, then it is obvious which
>menu it belongs in and what it is called. 

Ah, you're right here.  Remembering the keyboard command and the
name/location of the menu choice are about the same.  For uncommon
commands, a good on-line help system for a CLI can find you the command
as fast as rummaging through the menus, if not faster.  A graphical
interface to the on-line help is preferable, incidentally, because in
this case you are literally pointing at things you want to explore.
That's not really true with pull-down menus full of command names.
I'd still want keyboard shortcuts for the things that don't translate
that well to the GUI.  Next page for example.  Clicking on a "next"
button isn't really a graphical way to communicate "next page."
Pressing an arrow key is faster and just as meaningful.



>I agree that common commands should be assigned consistant shortcuts. 
>I know I use these shortcuts on the Mac. The problem with Windows is
>that there are too many choices for shortcuts, the shortcuts aren't
>consistant, and some of them (the ALT- ones) don't work in all cases. Bad.

Agreed.  I thought we were talking about the Mac.


>> 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.  
>
>The issue isn't pressing a key versus selecting with the mouse. The issue is
>REMEMBERING which key to press, then pressing it versus selecting it
>with the mouse. Go back to "Tog on the Interface." 

Sure, there is some point at which it takes longer to remember than to
use the mouse.  I still like having the mouse to use when I forget, and
I like the extra speed when I remember.


>You may perceive that using the keyboard is faster, but the stopwatch tells
>a different story.

Not my stopwatch.  Remember my examples?


>> 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). 
>
>I disagree. In a CLI, there are a number of things you have to express
>because the command syntax demands them. With a visual interface, it is
>possible to express a number of things by implication, or merely to dispense
>with them entirely, in favor of an automated solution.
>
>For example, on a CLI, you might specify to open an editor window of a
>specified size, and have to specify that size explicitly. In a visual
>interface, we would instead open to a standard size, or to the last remembered
>size, rather than going through a dialog each time to specify the size.


Gee, you must be right.  CLI's can't have defaults :-)  The GUI often
still makes you look at a bunch of defaults you don't even care about,
whereas with a CLI I can learn to type "ls" and I don't have to know
about dozens of parameters.  I just get all the defaults.


>There's a lot more you can tell by pointing to a map (or even having a map)
>than you can express with the most explicit instructions. And there's less
>chance of getting the instructions wrong. 

That's a good use for a mouse, I'll admit.  There are areas where the
keyboard is at home as well.  Typing a book, for example.  I'd also want
to use the keyboard if I needed very precise coordinates.  the mouse
isn't always precise enough (even in a drawing program, I like the
ability to "nudge" an object by a pixel by pressing an arrow key.  I
remember the equivalent graphical interface in one program.  there was a
"nudge" choice in one of the menus, and a submenu with "nudge left",
"nudge right", etc.  ick!)



>>>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. 
>
>If you could do something useful on a computer by pressing "C" all the time,
>I'd have to agree with you. 

Well, you can have a dozen or so common commands assigned to keys and
still have useful mnemonics between the keys and the commands.

>But you don't sit around punch "C" all the time. You use "C" in conjuction
>with all the other 60 to 110 keys on a keyboard. That's a lot to learn.

Same with a mouse.  The movement itself may be simple, but learning
about everything there is to click on, when to click on it, when to
double click, when to drag, etc. can be time consuming.  You seem to
think that the ability to move the mouse pointer to a spot and press the
button implies that you can use the whole Mac GUI.  By the same token, I
could claim that the ability to press a key implies you can use a
keyboard.  The advantage of the GUI is that you can apply some of what
you know about objects and how they interact.  With the keyboard you can
apply what you know about language.  In either case you still have to
learn new things because computers can't yet fully imitate either the
physical world or natural language.


>> 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.  
>
>Except that you can't do anything useful by pressing command C all day,
>but you can do a lot of useful stuff just manipulating the mouse.

>I'm afraid you aren't comparing equivalent things here. When you compare
>the time it takes to learn the ENTIRE keyboard, and not just one key, the
>mouse becomes much, much easier to learn.

Gee, I can't do much by just moving the mouse 3 pixels to the left all
day.  I have to learn how to move the mouse to any point on the screen,
how to click, double-click, drag, recognize and use buttons and windows 
and menus and icons, etc. etc.  Moving a mouse around is not equivalent 
to using a GUI proficiently.  And because the GUI can't do everything
you'd want to do, it still depends on keyboard input and language.


>> Besides, my argument is that it's faster for *experienced users* to use 
>> keyboard equivalents. 
>
>Then why in the world did you bring up this silly "easier to learn "C" than
>the mouse" argument?

I believe it was in response to an argument that the mouse is better
because it's easier to learn.  I'd prefer to drop it and talk about what
experienced adults can do.


>> 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.
>
>Well, I guess the thread has suffered substantial drift.
>
>As for alternatives, I'd rather see Apple concentrate on a BETTER visual
>interface than producing a CLI for the Mac.
>
>Besides, if you want a CLI for the Mac, they already exist. Get MPW or
>A/UX. There's your command line.

But I'd like a way to have the same applications respond to command-line as
well as graphical input.  That what AppleScript is all about.


>>>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? 
>
>Hmm. Interesting question. Maybe, maybe not. Consider: I don't call my own
>phone number, so there's a good chance I could forget it. 
>
>Of course, I do hope I remember my name. If the visual display (the list)
>is in some kind of easily recognized order, I can find my name (and hence
>my number) in short order. 

I've often had the problem where I knew the name of a command or a file
and I couldn't find it among all the clutter.  I knew exactly what I
wanted but had to spend a lot of extra time actually finding it so I
could use the darn thing.

>Oh, perhaps you meant that there's nothing but numbers on the page. That's
>a terrible interface. (Which goes to show that just having a GUI (I hate
>that term) doesn't prove you have a good interface)

I was thinking of just numbers, but you can attach your name if you
want.  You don't get to sort them by name because you don't always have
that ability.  Even when you do it just takes extra time to sort them by
some criterion before you can even start looking.


>What I'm concerned about is the POTENTIAL of each technology. CLIs haven't
>improved much in 10 years. There's little room for improvement. But we've
>barely scratched the surface of visual interfaces. The Mac isn't the first
>visual interface, but, to paraphrase Alan Kay, it is the first interface
>good enough to criticise.

I think that CLI's and GUI's have the potential to improve each other.
Neither one is sufficient by itself.  Something as simple as a command
window with the ability to graphically edit the command line is an
improvement over a purely keyboard-based system.  I'm sure GUI's would
stagnate after a while too if we don't think of innovative ways to
combine mouse input with other forms of input.


>>>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).  
>
>Ah, I see the problem. Go back to your original test. Try doing it without
>the mouse at all. That way you have to do the selecting with the keyboard
>as well as the shortcuts. Then we'll see how fast things are.
>

Ugh.  Haven't you understood yet that I think the mouse is better for
some things?  The two can complement each other tremendously, yet you'd
just as soon throw away all we've learned about commands instead of
seeing how they can be combined and used effectively.


>> 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)
>
>When I first starting using the Lisa Workshop editor, this sorta thing really
>pissed me off. I kept missing the line, and the arrow keys weren't any
>help (they didn't work in the LW editor). Grrr.
>
>But the problem wasn't the editor (necessarily), it was me. I wasn't that good
>at selecting what I wanted. After a couple of months, this no longer bothered
>me, since I was now proficient at the mouse.

I must say I'm quite proficient after 8 years of mousing too.
It's still tedious sometimes to have to move the mouse pointer halfway
across the screen to a tiny little spot, just to move the cursor by one
character.  My hands were already on the keyboard anyway so why not use
it?

>>>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).  
>
>Here's where the consistancy part comes in. While you can use the arrow
>modifiers to do some cool stuff with the keyboard, different software does
>things differently. Some apps support things like command-shift-left (selecting
>the next word), some don't, or do something entirely different.

Yes, the MacOS should be more consistent about keyboard equivalents for
text selection.


>>>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.
>
>I see. I would suggest we add a function MK( X, Y ) to our list of candidates
>then, where MK is the time required for a system using both a mouse and a
>keyboard. I'd agree that this function must necessarily be faster than
>M or K alone.

That's not necessarily true.  There are efficient ways to combine the
two and inefficient.  But if you agree that MK(X,Y) > M(X,Y) for some
X,Y  then it's easy to show that there is some subtask of Y (call it Y')
where Y' is performed soley on the keyboard and K(X,Y') < M(X,Y').
A subtask of a task is still a task, so my proof is still valid.


>> Well, hopefully this article gave you an idea of how widespread the
>> benefits of keyboard shortcuts are.
>
>I'm certainly not suggesting we do away with (standard) shortcuts on the Mac.
>I'd hate that.

So why not have a standard set of commands as well, as a way to save
graphical overhead when that's desirable, to save time, to specify
a series of lengthy operations all at once, to specify operations which
are performed very frequently, to communicate operations unambiguously
to other people over a variety of media, to concisely specify very
complicated operations, etc. etc.

--
Steve Kanefsky

--
Steve Kanefsky
Newsgroups: comp.sys.mac.advocacy