From: johnsd2@lib110.its.rpi.edu (Daniel Norman Johnson)
Subject: Re: More Defense of CLI (there, I changed the subject ... )
Reply-To: johnsd2@rpi.edu
Organization: Rensselaer Polytechnic Institute, Troy, NY.
Date: Fri, 16 Oct 1992 23:29:22 GMT

In article <1992Oct16.182611.17794@nwnexus.WA.COM>, kanefsky@halcyon.com (Steve Kanefsky) writes:
|> 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.

Oh, ok. I didn't see that.
BUT YER STILL WRONG, SO THERE! MUAHAHAHAHAHAH! :)

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

Dat's not it. You also have to remember that its the
ALT- key you ahve to hold down. (or was it control? Or command?
I've forgotten...)

|>  Less to remember.

But no help remembering it. It isn't showing you a list
of commands you can use. (right?)

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

Hmmmmmm. If you have remembered the keyboard equivalent, you've
already blown the 2 seconds. So I guess in this case it would be
faster. (using the menu would just add insult to injury)

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

If you still remember teh keyboard equivalent in this case
(which seems doubtfull to me), that would be faster. If not,
it would not be faster since you dont have to dig up a manual
or search the on-line help.

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

Or (preferably) by manipulating the document directly. But basically
I agree. You can still have keyboard equivalents tho. For instance,
using the keyboard to select something in the finder.

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

AWWWWWWWW PLEASE! :)

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

This bit is VERY un-mac-like, anyway. How modey.

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

That's right. I never said a BAD user interface was better than
a keyboard equivalent, or a command line.

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

Huh? We are on a command line now? Yech!

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

Yep, we are on the command line now. And I can see right now that
even if I (somehow) manage to defend this mess, you can drege up
a user-interface so bad that a command line would be preferable. :)

Actually, I thot you were talking about keyboard-equivalent type
commands. (you know, alt-something)

With a CLI, you need to refer to the help if you even want to do something
you dont to a great deal of. (or at least, ->I<- do, since I cant
remember the obscure details of the commands) Or, you can sometimes
use trial and error. Both are time consuming. You get to do both
when you try to do those modifications to the command line you
were talking about.

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

Who said I wanted to ditch help systems?
I didn't say that. I dont feel that way. They are usefull.
But I dont think a user interface should depend on them,
if it can be avoided.

Incidentally, those large complicated programs would be well
advised not to overdo it with the menus. Smaller programs
can get away with menu dependance, but big ones need to spread the
features out. More direct manipulation, toolboxes, palettes, modeless
dialogs (I hope), etc..

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

Hmmm, ya gots a point (and I seem to have slipped up)

I was thinking along the lines that you would use the menus
to bring up dialogs.

Incidentally, I should certainly hope that if the program
was going to do something that was hard to undo, it would
warn me first!

But Im not saying you should get rid of help systems, just that
you should avoid depending on them (if you can. Sometimes
you can't, sometimes the programs function itself is complicated,
and I dont see how any user interface can cover that up!)

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

Ok, this bit was trivial, but...

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

This isn't, as you said a button wasn't a graphical way to communicate
"next page."; I was just saying you dont have to use a button to be
graphical. If yuou dont like scroll bars, invent your own control that
does the right thing. Perhaps you'd like something like the Pagemaker
page switching controls?

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

Well, no. You can see what you are doing with the mouse. The "cut"
command is sitting right there, in front of you. You do have
to remeber what menu it is in, but if the menu doesn't look right
(ie, like an edit menu), you can quickly move around. With big
nasty complex menu structures you start getting into trouble
here (which is a good reason not to have big complex nasty menus).

This of course doens't apply to some other elements; they are just
sitting there on-screen.

I don't expect you to accept Togs conclusions and all that, as I haven't
provide one shred of evidence for them. If you say you don't buy
it, fine. End o' arguement. But you didn't seem to quite grasp
what it was you were supposed to buy, that's all.

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

Ah. I dont quite see how you can do that with anything
resembling accuracy. But then, I have never tried to do it,
either.

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

uh no, ya see...

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

Not one of these things is done by typing "ls"; You also have
to do something else, just as with the Finder.

ls just blasts it to the screen. To scroll, you need to ls | more,
or somesuch. changing the view menas throwing in some extra switches
(if you remember them, Im not so good at it) or shooting the output
through annother program. (is there a way to do a view by kind,
say? I dont know how to do this)

Viewing subdirecties with ls along doesn't work to well- you want to
pump it through more, I think. In any case you can do that in the
finder, but you need to be in a list view (ie not viewing
by icon or small icon), so there's a potential extra step in there.

In any case, I wasn't away that ls could present any info but size,
file name, and some limited filetype info (director, executable, link,
or none of hte above :) What else can it do?

Of course, ls can do this stuff with "one step", but I dont see
the advantage in this case. What's wrong with an interactive
approach to this?
|> 
|> >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.

No, definitely not, you see you have to:

|>  Just read the man page (A good hypertext man page system
|> would be better).

Which is not quite the same as just having them there in front
of you. You also have the inconvinience of bring the knowledge
from the man page to the command line. Why should the user have to
do that?

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

And get to remember them. Yay. :( Now what if I want to do something
I dont do regularly?

[delete- a nudge submenu]
|> >
|> >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.

You've a point here, but there are some advantages to the way I mentioned.
You get to have 8 arrows instead of 4, and you can throw in auxiliary
controls. (for instance, how MUCH to nude. Maybe a continuous nudging
ability) Also palette should be labeled and the arrows dimmed if nothing
is nudgable. Throw in some baloon help too. It doens't seem so bad to me.

In this case teh arrows are a pretty good alternative, imho. (also
in flagrant violation of the interface, but its a minor point;
according to the interface these keys should do NOTHING in this case
So if you dont like it, ignore it.); But the arrows seem to say
pretty well "thataway!".

Some other (adequate) method would be nice. I don't
think the interface should depend on teh keyboard here, since
its not obvious what the arrow keys will do.

[deletia- something usefull on a computer]
|> >|> 
|> >|> 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?

To sell product. People like having keyboard shortcuts. Also you
can select with one hand and edit with the other if there are no
shortcuts. Apple also sometimes uses them to add facilities wo/
complicating teh interface (which I disagree with in some of
the cases; you should be able to do mass expansion in teh finder
wo/ using command-option-right arrow already!)

I'm as susceptible as teh next guy. I use command-S to save files,
comand-Q to quit, command-x to copy, etc. I dont use command-option-/
to do whatever the heck it does (if anything) in the programs I use.
Its too much to remember. I dont even use command-shift-B to boldface;
I do use command-B to boldface sometimes tho (which is the standard)

Of course, this doesn't stop me from babbling about it.

Also, we're kinda running out of keys. Its rather hard to assign
mnemonic connections these days.

[deletia- the complexity of mice]
|> >
|> >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.

Me too. I agree completely. (Well, I do think graphical interfaces
make it much easier to have directly-manipulatable documents
and such, but basically..)

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

THat's an interesting thot. The other problem with CLIs tho is
that they are invisible- you can't see what you are doing.

Fix 'em both, and you may just convert me. :)

|>  UNIX already has a great deal of
|> consistency, but it lacks a great deal as well.

Ok, but now what does this:

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

Have to do with consistency?
 
|> 
|> >|>  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.

I agree. But having to specify exactly what you want is one of
the things that make CLIs so obnoxious (imho)

[deletia- what he does with computer languages. heh heh... :) ]
|> 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.

Me too, but...

|>  I even prefer it myself for many
|> things.  I'd also like to see a supplemental CLI.

I'm worried that if you do that things will start to REQUIRE it.
One of the nicest things about the MAc is that you never, ever, ever
have to mess around with low-level garbage (unless you are a programmer);

I suspect that if a CLI was introduced you'd start seeing programs
that could only run that way, or that had limits on what they
could do without involving a CLI. Perhaps Im just paranoid.

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

Well, that's all well and good as long as nobody ever ->HAS<- to use it.
(or at least if I dont have to use it... :) ) If that were the case,
I couldn't complain much about a CLI.

|>  I
|> also see a big potential for using it to automate and refine complex
|> and/or repetative tasks.

This sounds like scripting, which I am all for.

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

1 pixel wont do this on a macintosh, ya know.

|>  Have you never
|> accidentally double-clicked, or waited too long between the two clicks of
|> a double click,

yeah, but I have my double-click speed set right now. :)

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

Yup. However, you should be able to undo mistakes like this. (the Finder
is notoriously lame about the undo feature tho. :( )

[deletia- learning how to mouse, etc]
|> >
|> >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.

Certainly. We agree so far, but beyond that...

|> Beyond that, learning a command shell is more difficult than learning a
|> GUI, 

Hey, we still agree! Something must be done about this...

|> but more efficient once you do learn it.

Ah, now here we disagree. At the very best you can only claim the CLI
is better in some cases. I'll yeild cases involving scripting and
wildcards right now, so we don't waste even more bandwidth.

For the stuff I do, the GUI seems very well suited and more
efficient that (say) the bourne shell on this unix box Im using
to post this. Its simple stuff like moving a file there, deleting
those files over there. That sort of thing. Its also better for
unbinhqxing files, because I can just start DownLine and then load
the files up. It knows what to do. (it can also unstuff older
formats, but things get less efficient when you have new stuffit
archies, and so on)

|>  I think most people would
|> like learning a GUI first and perhaps picking up a CLI along the way. 

I very much doubt it. I dont see what Joe User would use a CLI for.

|> Perhaps the GUI could help the user by showing equivalent commands at the
|> request of the user.

What does this mean? I no get it.

[deletia- CLIs/Scripts]
|> >
|> >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.

Most CLIs know how to execute commands from a script, but the thing
is a CLI is very much like interactive programming- you type in
commands, and they happen. You loose the speed o' program execution
and the reusability of a program.

The apple script thing, last I heard, did not include a CLI. You would
type in stuff like hypercard scripts, and save it, and they you'd
have this thing that could do stuff. (pardon me if Im a little
vauge), but you dont have a place to just type "rm bleah ../bleach";

I suspect there'll be a shareware program that provides this, but
remember this will be hypercard like.. thats pretty verbose...

|> >|> 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 gad, I know the feeling! Thats why I cleaned out my system file and
took all those fonts OUT of there and stuck them in a folder. I dont
USE 200 fonts in any documents (and I sure hope you dont...)

I also cut down my apple menu, smae reason. (put the stuff on my desktop
instead, or at least the stuff I use.)

[deletia- nothing bu NUMBERS? yech!]
|> >|> 
|> >|> 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.

If you can spell the beginning of it. If those first letters are unique.
Wildcards are kina messy for this- you have to ls <expression> then pick
from THAT list.

In any case, for the phone number example, the difference between
862-2234 and 862-2235 is so small it wont trigger an "ah, THAT'S what
I want!" responce, I suspect.

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

Have it presorted, o'course.

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

True, true. Oh well.

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

So go ahead and type it, or part of it. Poof. This is of course the
special case that you already know the name. (tho you have come
up with a plausible explaination)

I still wouldn't like to be wo/ the list in case I dont remeber
it, or dont remember it right. The list doesn't hurt you if you
DO remember it. 

However, this doesn't quite apply to this list- here's you'r
saying "its faster not to look  up something you already know",
which is true enough. However, what if there's something you dont
know in that list?

[deletia- mutuial improvement stuff]
|> >
|> >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 isn't what I meant. Im saying, CLIs have had all this time to develop
neat tricks, so its not surprising they have some. When GUIs have had
as much time, I suspect they will have developed nice tricks too. (in
fact, Id say they already have done so, but they'll get more)

Id say the problems CLIs solve for you can be solved with GUIs;
but how to do it right, that's the probelm.

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

[deletia- complicated pseudomathematical proof]

Seems to me this assumes that the thing that was faster was teh
keyboard, which is just circular reasoning. What else
could it be, you ask? Read on...

|> 
|> >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 dunno.. I can't... Hmmm..

In any case, in this case you are keeping one hand on a set of keys,
the other on the mouse. This has several effects:
	a) No left hand movement (just finger movement)
	b) No searching for keys. (I dont know if you have to do this,
	   but I sometimes gotta, especially with an unfamiliar keyboard)
	c) Never moving your hards between the keyboard and mouse
	d) Never moving the mouse up to the menubar, then back down.

Each of these is very small, but they gang up on you, and they apply
for each edit you make.

And of course you are assuming you dont do them at the same time.
I can operate a keybaord and a mouse at the same time; you have
to do option-click on something (for instance)

[deletia- basically: See! It Works!]

|> >
|> >We do.
|> 
|> I meant full-blown CLI commands.

Oh, ok. We swich between them so fast I can't
keep track. :(

We discuss this elsewhere.

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

Well, if you mean stuff on your path, there are facilities like that
on the Mac (Apple Menu, desktop, etc) If you mean just something
sitting there, well I still have to use ls to see what to type
anyway. Its true there's soem graphic overhead involved, but I'd
rather have that than have to remember+type filenames. Better
the computer should work hard than I should. Also, you can
get faster graphics. You can't get a better brain (I dont think),
so there's at least the possibilty of relief.

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

Sounds like a rotten design to me, but its not clear to me just
what you are doing here so it may not be.

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

Oh, I see. Sounds sorta like scripting system, or macros. Both
nice (particularly the scripting suystem)..

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

Oh I see.
Sounds like annother case where scripting would take care of it.

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

Its also bad design. :(

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

I wouldn't say its great for learning. Its hard to see how you get to
that option. (in fact, its well-neigh impossible) It really hurts
user friendlyness.

-- 
			- 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.
Newsgroups: comp.sys.mac.advocacy,comp.os.os2.advocacy