From: johnsd2@vccnw05.its.rpi.edu (Daniel Norman Johnson)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: More Defense of CLI (there, I changed the subject ... )
Date: 16 Oct 92 14:39:00 GMT
Article-I.D.: rpi.583zs4c
Reply-To: johnsd2@rpi.edu
Organization: Rensselaer Polytechnic Institute, Troy, NY.

In article <1992Oct15.194926.9853@nwnexus.WA.COM>, kanefsky@halcyon.com (Steve Kanefsky) writes:
|> In article <6211.2adc2d3c@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
[deletia- lots of stuff involving confusing Windows for MacOS :)]

[deletia- using a keyboard summary, more Windows/MacOS stuff]
|> 
|> >> 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.

Are they? The thing about the menu is that you can see what you are
doing, you don't have to try it and see if it works.

It doesn't seem to be about the same to me, anyway.

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

This one strikes me as unlikely. Perhaps you could go over this help
system?

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

Isn't it? You point at the menu title when yu want to explore that menu.
You point at a menu item to see what it does.

|> 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 disagree. The arrow key is already defined to mean "move
the insertion point down a line (or whatever)"; You want
(I think) the Page Down key.

In any case teh appropraite interface element isn't a button,
its the page-down region of a scroll bar.

[Deletia- talking about the Mac, as opposed to Windows]
|> 
|> >> 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.

This isn't quite what Tog was saying. He was saying the command
key equivalents are never faster, even if you do remember them.
Remebering them, according to Tog, takes about 2 seconds.

|> 
|> >You may perceive that using the keyboard is faster, but the stopwatch tells
|> >a different story.
|> 
|> Not my stopwatch.  Remember my examples?

I don't. :( Were you the fellow who somehow timed himself?

[deletia- complexity of commands]

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

And in the GUI, you never have to type anything to get the same thing. :)
[ls isn't such a good example...]

However, it hardly hurts you to look at the defaults (the don't take
that long to draw, ya know) and it makes it easier if you want to change
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.

I agree with ya, here. The keyboard is what I'd want for both of these
things.

|>  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!)

Well, that's REALLY bad design, but it COULD be done graphically wo/
that. Stick 8 clickable arrows on a palette, maybe with a speed control
or something. It could be much better that that submenu mess.
 
|> 
|> 
|> >>>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.

The MacOS already does this (the standard commands; there are something
like 15 of them now)

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

This is true. THis is why consistency is so important. You do have to
learn about various things like how pulldown menus work, how a scroll
bar works, buttons and checkboxes, windows, etc etc etc...

They are pretty consistent most of the time. (a lot of things
go of if you just click on them- scrollbar arrows, buttons, checkboxes,
close boxes, etc) but there are exceptions (icons, growboxes, drag bars,
menus)

The thing is you should only learn this junk once.

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

Well, not me.  Bill can deny this for himself. :)

|>  By the same token, I
|> could claim that the ability to press a key implies you can use a
|> keyboard.

In fact, you did, so it's clear that you can! :)

|>  The advantage of the GUI is that you can apply some of what
|> you know about objects and how they interact.

That's not the only one. See above.

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

But I submit that they are really, really bad at language. Their grammer
and vocabulary is far removed from English (I sure hope there's
no real language like that!), and is missing most of the flexibilty of
"real" language. Its also very picky and intolerant of little typoes
and such.

Mousing at least doens't mind if you miss by a pixel (or more); if you miss
by a letter (X instead of C say) in a CLI, too bad!

[deletia- keyboard v/ mouse ease of use]
|> >
|> >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,

Which is considerably easier than moving it 3 pixels to the
left, btw.

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

Now, now. You just lumped a whole GUI into "using a mouse". If you
including understanding a the bourne shell into learning a keyboard,
you might be able to compare. (of course, knowing the bourne shell
doesn't help you use other apps. But that's not the keyboards fault)

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

Don't look now, but we are. :)

[deletia- look at this thread drift!]
|> >
|> >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.

Actually, AppleScript is a scripting system not a Command Line. But
other than that, I agree. Can't wait.

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

Doesn't happen to me much, but when it does you can deal with it
easy enough. Use the find command. (actually, in some cases you can
just type part of the name and thats it, but not in all cases)

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

If there are names, you cant find it wo/ remembering it anyway. Kinda
defeats the purpose  :(

So lets have the names. But names all look very much like each other,
so the interface still needs much improvement.

You can sort them by name, because you DO have the ability. Computers
are good at sorting. :) But that's not enough, lets separate  them out
so that each letter is on its own page. That way there'll be less
to search through.

Now we are getting into an area which is better- Id rather search such
a list than try to remember some arbitrary persons phone #, anyway.

As for my OWN phone number, well obvious the interface was not designed for
this. But that's ok, we can fix it. Put my name and phone number
in red, and boldface them. Make sure the page its on is light pink.

NOW I think we have an adequate user interface for this little example.

|> 
|> >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'm with you here. But remember that after 10 years GUIs are now seen
as a contender w/ CLIs. How long have CLIs been around?

[deletia- cut, copy, paste..]
|> >> 
|> >> 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.

Well, I certainly buy that if you use one hand on the mouse and the other
on the keyboard, for commands you are very familiar with (cut, copy, etc..)
this is better than either alone.

[deletia- mousing about in editors]
|> 
|> 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?

They seem to be about the same to me, generally. At first mousing
for this did bother me too.

[deletia- seleting test]
|> >> 
|> >> 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.

I dunno. Its always shift-<arrow>. (isn't it?)

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

If its so easy, go ahead and show it. :)

In the common example of it, u select with the mouse and edit with the
keyboard. It lets you operate both at the same time (if you can deal
with that, anyway); How is it that this advantage persists if you dont
use the mouse at the same time?

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

We do.

|> as a way to save
|> graphical overhead when that's desirable,

Im all for faster graphics, but I have a feeling that's not quite
what you meant. Do you mean "don't use the GUI?"

|> to save time,

This is (allegedly) what the whole thing is all about.

|> to specify
|> a series of lengthy operations all at once,

This I want.

|> to specify operations which
|> are performed very frequently,

What's good about this? What would the computer
do with this knowledge?

|> to communicate operations unambiguously
|> to other people over a variety of media,

Huh? Words aint good enough for ya? :)

|> to concisely specify very
|> complicated operations, etc. etc.

You can already do this, ya know. Or
are you saying mousing about is "non-concise"?

-- 
			- Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

These opinions have had all identifiying marks removed, and are untraceable.
You'll never know whose they are.