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

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 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?

>>> 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.

> 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. 

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.

> 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." 

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

> 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.

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. 

>>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. 

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.

> 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.

> 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?

>>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.

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.

>>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. 

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)

>>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.  

1) Programs that add items to the Edit menu add them BELOW the defined
standard, so the position of the standard menus don't change.

2) Few programs dynamically change menus. There's several reasons why this
is considered a bad practice. (It's a potentially hidden mode -- we try
to avoid modes) I'll concede that sometimes it is damned useful. (ie
Hypercard script versus stack windows)

> 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.  

I never insisted that it did. I merely claimed that the Mac interface has
a high degree of consistancy, whereas Windows has a low degree of
consistancy. 

> In fact, the amount of consistency is completely independent of the type 
> of interface.  You can have a completely consistent CLI or completely 
> inconsistent GUI's 

Agreed. You can have good or bad regardless of the technology.

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 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.

If the menus aren't defined in the HIG, then there's no hope to gain a
perfect consistancy. If we set up a truely facist beauocracy at Apple, where
each application interface had to be officially approved by the Apple
Thought Police, then perhaps we can attain this level of consistancy. (Hmm,
at what cost, I wonder)

Developers merely do the best they can. Let's hope the next generation
of visual interfaces is better.

>>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.

> 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.

Today, I use MPW for editing stuff, and I tend to favor the mouse for this
kind of thing. (And I use a smaller font than the LW editor used, too)
Occassionally I'll use the arrows (they work in MPW), but this
is rare. When I do use them, it is a matter of preference, not speed. I'm
probably faster to use the mouse, but sometimes the cursor keys seem handy.

>>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.

Without that consistancy, it is extremely difficult to recall which sequence
does what in which app, which makes it easier and faster to just knuckle
under and use the mouse.

>>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.

>>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.

I'm certainly not suggesting we do away with (standard) shortcuts on the Mac.
I'd hate that.

-- 
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.