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: Fri, 16 Oct 1992 18:26:11 GMT

In article <583zs4c@rpi.edu> johnsd2@rpi.edu writes:
>In article <1992Oct15.194926.9853@nwnexus.WA.COM>, kanefsky@halcyon.com (Steve Kanefsky) writes:

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

I was speaking in terms of the actual amount of information you have to
remember to directly execute a command.  With the mouse, you go from the
concept "copy" to the name of the command (also "copy" in this case, but
not always exactly what you'd expect) and you also have to know what menu
it is in and where.  With the keyboard command you associate the idea
"copy" with the letter "c" and that's it.  Less to remember.  There are
cases, for me at least, where I remember the keyboard shortcut but I don't
remember exactly where the menu command is.  In this case, do you agree
that the keyboard command will be faster, even if it takes a couple
seconds to remember it?  It takes more than a couple seconds to look
through even a single moderate-sized menu.  It may even take more than a
couple seconds to look through a menu if you know exactly which menu and
exactly what the name of the command is, if you don't know *where* in the
menu the command is.


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

Because of the limited number of menu choices in a Mac program, there are
many "commands" which are only accessible by going through multiple menus
and/or dialog boxes.  Say I asked you to put a double border around a
paragraph in Microsoft Word (please don't just dismiss all Microsoft
products as if they were completely un-Mac-like).  If I recall correctly,
you'd have to choose Paragraph from the Format menu, which brings up a
dialog box.  Then you'd have to click on Borders which brings up another
dialog box, and toy around with the little graphical picture of paragraphs
and the buttons which let you choose border styles.  If you'd never done
anything like that before you'd probably have to search around for a while
and spend several minutes before you found exactly what you wanted.  You
might just have to resort to the on-line help.  If you do that, the
on-line help could just as easily specify the appropriate command, and
give examples which you could copy and paste to execute them.  It would
also be easier to re-use the command on other paragraphs, make a slight
change to the command (if you didn't get it right the first time) and
re-execute it, rather than have to go all the way back through the dialog
boxes again. 

A good graphical help system has some advantages over using the menus
themselves as a help system, because you can put in useful diagrams,
hypertext links, examples, etc. etc.  Going through all the menus is
basically just trial-and-error, and starts to fall apart for large
complicated programs.


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

Gee, I thought you said above that the CLI is bad because you have to try
it to see what it does.  Sometimes it's dangerous to try a command and
it's not always possible (or it doesn't make sense) to undo.  The menus
themselves are organized more for ease of use rather than ease of
learning, so a good hypertext help system is still the best way to
actually learn how to use a program. 


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

Whatever.  That doesn't change my point.  It depends on what kind program
you're using.  Some programs don't have a concept of a "line."  This
thread is ballooning to the point where I'd rather stick to substance and
dispense with nit-picking, if you don't mind.

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

More trivialities.  I consider the page-down region a button of sorts. 
Not all programs have the same concept of pages.


>|> >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 have to remember with the mouse too.  I admit I haven't read Tog, but
I do know something about experiments, and I know how easily a
pre-conceived conclusion can affect the results.


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

Yes.


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

Sure you do.  You have to scroll around, move windows around and make them
bigger because they get in the way sometimes, possibly change the view,
open folders (with ls you can view subdirectories in one step or view any
directory anywhere without having to navigate to it through a series of
folders).  ls is uglier but it's easier to get it to present the
information you need.


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

Same with ls.  Just read the man page (A good hypertext man page system
would be better).  You can have a dozen aliases of ls if you like and call
them anything you like, and get the exact view you want with just a
one-character command if you so choose (you get to choose for yourself
which commands are more frequently used and assign them short names, or
which commands are infrequently used and assign them longer more
descriptive names)


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

I find that interface pretty tedious to use.  SimCity has something like
that as one of the ways to scroll the window in various directions.  I
find the keyboard works better in this case (suprise suprise).  Why put
arrows on the screen when you've already got them on your keyboard. 
The disadvantage is that it's less obvious to the user that the arrows on
his keyboard actually *do* anything, but once you know that it's faster
and easier to use them.


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

Yep, and I like them being there.  I think you'll find that Apple agrees
with most of my positions (or at least they recognize that enough people
feel the need for an alternate command interface that it's worth putting
hooks for it into the system).  Why would they put keyboard shortcuts in
(and even call them "shortcuts") if they didn't think they were faster in
many cases?

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

I agree, and I think consistency has as much (or more) to do with the
Mac's appeal than the graphical interface itself.  Too often they are tied
together.  I'd like to explore the potential for consistency in a
command-line interface and see how much CLI's can be improved
by maximizing consistency.  UNIX already has a great deal of
consistency, but it lacks a great deal as well.  The fact that you can
easily take several UNIX commands and combine them like building blocks to
do exactly what you want gives UNIX enourmous power.  A lot of the power
of the Mac comes from the fact that you can copy and paste, import and
export among many different programs.


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

English isn't a very good language for actually communicating things.  A
huge percentage of what we say depends on enourmous amounts of prior
knowledge and common experience.  Even so we end up misunderstanding each
other a lot, sometimes without even being aware of it.  We couldn't
possibly expect to write programs in English that behave exactly the way
we want them to.  Personally, I like studying computer languages and I
think it helps me communicate my thoughts more clearly in English as well.
I understand that many (or even most) people don't want to have to learn a
complex language.  That's why I'm in favor of keeping the Mac GUI and
improving it as much as possible.  I even prefer it myself for many
things.  I'd also like to see a supplemental CLI.  Not everyone need use
it, but I think it would catch on more than you'd expect and people would
begin using it for tasks where the GUI just gets in the way sometimes.  I
also see a big potential for using it to automate and refine complex
and/or repetative tasks.


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

Sure a pixel can make a difference! and a click vs. a double-click vs a
1-pixel drag can make a big difference as well.  Have you never
accidentally double-clicked, or waited too long between the two clicks of
a double click, or clicked on the wrong thing, or accidentally dragged an
icon, or let go of the mouse at the wrong time and picked the wrong menu
choice, or spoiled a huge selection because you forgot to hold down a
shift key to select the 32nd item, so you had to start all over again?
I sure have, and there's no way to edit a previous command and re-execute
it like a decent CLI.


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

Well, I happened to learn the keyboard before I ever touched a computer. 
It's a pretty common skill.  Even if you use the mouse you still have to
learn the keyboard anyway in most cases.  Very few people use computers
without entering a significant amount of text.  Given that you have to
know the keyboard, learning the mouse is just that much *more* learning.
Beyond that, learning a command shell is more difficult than learning a
GUI, but more efficient once you do learn it.  I think most people would
like learning a GUI first and perhaps picking up a CLI along the way. 
Perhaps the GUI could help the user by showing equivalent commands at the
request of the user.


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

There isn't all that much difference between a CLI and a "scripting
system."  Which is tcsh or csh or sh?  Both, I'd say.



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

What about finding a command in a menu.  How do I easily find venice in my
font menu with 200 fonts in it?


>|> >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  :(

Well you can, sort of.  That's how you look up something in the dictionary
which you can't spell.  But with wildcards and filename completion, you
can specify a filename directly even if you can't spell it, without the
extra step of finding it in a list.


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

All that takes time, and you'll most likely lose the race to the guy who
remembers part of the name and has a CLI with wildcards and filename
completion.


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

You're getting away from the point.  The question was, is it faster to
type a phone number you already know, or find it in a long list.  No doubt
it's better to search for something you don't know than to try to
remember it :-)


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

You're still missing the point.  Say you just saved a document from Word
in a folder with 50 other documents, and you know what you named it.  Many
times it's faster to type the name than to locate it (especially if you
have shortcuts like filename completions)


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


I'm not sure, but I don't see why it's relevant.  A new technology has
arrived (GUIs), and that new technology has the potential to improve the
old technology, instead of just throwing out everything we've learned only
to discover that what we threw out wasn't really half-bad.  We have a
tendency to do that with ancient cultures and their medicine, for example.
Many times when we go back we discover that they actually knew something
we didn't know, and we had ignored them because we thought we were so much
better than them.


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

OK, well first there was a typo above.  It should read that 
MK(X,Y) < M(X,Y) implies that there exists Y' such that K(X,Y') < M(X,Y')
Let Y'' be the mouse-only portion of task Y.  Clearly, 
MK(X,Y'') = M(X,Y'') because there's no keyboard use at all in Y''

Let Y' be the keyboard portion of Y.  MK(X,Y'')+MK(X,Y') = MK(X,Y) because
Y'+Y'' is just Y.  Also, K(X,Y') = MK(X,Y') because there's no mouse use
at all in Y'

Substituting, we get M(X,Y'')+K(X,Y')=MK(X,Y).  Since MK(X,Y) < M(X,Y),
we know that M(X,Y'')+K(X,Y') < M(X,Y), so K(X,Y') < M(X,Y)-M(X,Y'').

Clearly M(X,Y)-M(X,Y'') = M(X,Y'), which gives us our final answer:
K(X,Y') < M(X,Y')


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

You're not really doing anything at the same time.  You might be preparing
a little bit to use a key or thinking about it while you're mousing, but
you can do the same thing while you're using they keyboard.  While typing,
I can prepare to type the next thing or think about what I want to type. 
I think the equations above still hold.  The actual part of the task which
involves using a keyboard command, and which doesn't overlap with another
command, is shorter than the corresponding time for the mouse.


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

I meant full-blown CLI commands.


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

I mean that you can save all the time of drawing windows and getting the
contents of directories you don't care about in order to get to the one
you do care about, when you could have just typed it in directly without
doing any of that.  That's just one example.  Another is to specify an
option directly, instead of drawing a big complex dialog box (which
covers up your actual work) just to click one button.

[...]

>|> to specify operations which
>|> are performed very frequently,
>
>What's good about this? What would the computer
>do with this knowledge?

You store it in a file somewhere so you can easily re-execute it later. 
You can alias it, for example, so it's indistinguishable from a
non-interactive application.


>|> to communicate operations unambiguously
>|> to other people over a variety of media,
>
>Huh? Words aint good enough for ya? :)

It's nice to be able to specify an exact set of commands to someone
halfway across the world, to the point where they can literally copy and
paste them to run them.  It's a lot harder to describe a sequence of
operations in a GUI.  There's lots of room for omissions and ambiguities.


>|> to concisely specify very
>|> complicated operations, etc. etc.
>
>You can already do this, ya know. Or
>are you saying mousing about is "non-concise"?

Having to navigate through a whole series of dialog boxes isn't very
concise, when you can specify the whole thing on a single command line. 
It's great for learning about what you can do, but not as great when you
already know what you can do and you've done it a hundred times.

--
Steve Kanefsky

Newsgroups: comp.sys.mac.advocacy