From: johnsd2@vccnw01.its.rpi.edu (Daniel Norman Johnson)
Subject: Re: When is a CLI faster than a GUI?
Reply-To: johnsd2@rpi.edu
Organization: Rensselaer Polytechnic Institute, Troy, NY.
Date: Mon, 28 Sep 1992 00:45:10 GMT

In article <8elX6ue00VRBA9iL5w@andrew.cmu.edu>, fj05+@andrew.cmu.edu (Faisal Nameer Jawdat) writes:
|> johnsd2@jec324.its.rpi.edu (Daniel Norman Johnson) writes:
|> > But what if you dont REMEMBER the command-keys to hit?
|> 
|> In order for someone who is used to the program to forget what command
|> keys to hit, the command must be of sufficient dissuse and complexity
|> that it would also take some time to find the command in the
|> appropriate menu or more likely, sub menu, assuming it's not on some
|> dialog box you have to bring up, or some such thing...

I agree, except tha tI dont think they hav eto be complex.
If you dont use 'em , you wont remember them. And the less
you use them, the harder it will be to remember them.

Complex of course makes it worse, but its not required.

|> > Indeed, there are supposedly studies that show that mousing is faster
|> > than command-keys because you have to remember stuff to use
|> > command keys. You just don't remember thinking about it. I expect
|> > you've heard of that, but I doubt you believe a word of it. :)
|> 
|> I have yet to see one of these famous studies -

Me neither, I just wanted to bring them up. If you dont
believe 'em, I cant use em to defend my opions.

|> I saw someone mention
|> that Apple had done studies showing that mousing was faster than
|> typing, and then this person hypothesized that the reason was the
|> active process/memory recal bit, and suddenly everyone's taking as
|> gospel the fact that it is easier to double click on my hard drive,
|> double click on the games folder, double click on the tetris like
|> games folder, double click on the colour tetris folder, and double
|> click on the colour tetris folder than it is to type the following
|> keys (which is what i would have to type if I were using tcsh on my
|> mac):
|> a c [tab] g [tab] t e [tab] c o [tab] t e [tab] [enter]
|> which translates to the following
|> the tab does file matching
|> i do similar things on my unix account all the time - even if the
|> shell hasn't caught up to me it buffers my typing so that when its
|> done it executes
|> with the mac i have to wait for each folder to open, which takes time
|> i just did the example on the mac and a similar example in a shell to
|> my unix account
|> mac: 17 seconds
|> unix: 3 seconds to type, 4 seconds wait for the shell to run through
|> the file completion and buffer and then execute the instructions, but
|> meanwhile i was doing something else

the macintosh supports typehead. Your command will work unaltered
(I _think_) in the finder if you just replace the tabs with
command-o or command-down arrow (or option+either of those) and
drop the enter.

Of course, you coudl also do the same thing on the Mac by typing:

[command-f] Tetr [return]

And let the finder search for it. You could also have an alias
on your desktop, or in the apple menu too.

|> somebody please show me where these alleged studies are, and then i
|> will be more likely to believe them
|> if not i may force you all to take our competing cognitive processes
|> course here - you'll love it
|> 
|> > |>  More nested menu choices amplify this
|> > |> difference.
|> > 
|> > This is true. Heirarchial menus are very slow. A good
|> > reason not to use them, imho. But sometimes they are necessary.
|> 
|> but unless your menus are huge and unorganized, you need heiracchial
|> menu's or you have a rather limited scope of options
|> 
|> > |> Programs that do not offer keystroke alternatives are assuming that
|> > |> their users are either too lazy to get used to a keyboard or don't
|> > |> care if it takes longer to perform an operation with the mouse.
|> > 
|> > Or think it doesn't. Most provice keyboard equivalents for frequent
|> > operations, but not for uncommon ones. After all, what good
|> > is a keyboard equivalent if you cant remember it?
|> 
|> which is assuming too little of the user, i postulate...
|> Look at the word processor Nisus for the mac.  It lets you set
|> keyboard shortcuts for menu items - thus it makes the interface work
|> for you, rather than forcing you to work to its interface - I use
|> Nisus, and not a lot, but I type my papers and my stories on it, and
|> do a lot of text formatting of things I find on the internet.  Of
|> their command key equivalent i use about 20, and I use another 20 I
|> made myself
|> maybe I just have a better memory than the rest of you..

You've a better memory than me. I have no problem with lotsa
command-shortcuts, as long as the standard commands are supported,
and you dont HAVE to use them.

|> the best of both worlds is a GUI that lets you use CLI's and GAI's all
|> at once - you can't do that on a straight CLI - this is the advantage
|> of the NeXT, os/2, Xwindows, etc.

If you do the GUI right, and didn't give it short shrift, this could
be so. The NeXT gui is nice, but the file manager seems to have gotten
short shrift and there are few apps out for it (however good they may be);
Also unix is a hardware hog. Os/2 is tempting, but the hardware you need
is spectacular (tho NT is supposedly gonna be worse); X-Windows
needs a standard GUI people will actually use, and a decent graphical
file manager.

But I propose that yer Ideal System would not need a CLI; it would
have a really nifty GUI, which supported pipes [or something
similar, hopefully better], and a scripting system that could
control applications.

This arrangement doesn't provide wildcards, but thats the only
thing its missing, that I can see. As for wildcards, I use them
all teh time under Unix, but on teh MacOs I don't, and I dont miss
them. Perhaps that's just because I never need to rename 5000
files at a time. (do you? really?) :)

Not that Im saying you shouldn't have a CLI, if you want one.
So feel free to toss a CLI into my "ideal system" above, but
don't make me use it. :)

|> (GIA: Graphically Interactive Application)

Spiffy Acronym!

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