From: johnsd2@lib106.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: Thu, 1 Oct 1992 23:10:46 GMT

In article <1992Oct1.212710.31862@news.th-darmstadt.de>, wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!) writes:
[deletia- arguement about stopwatches]
|> >> On the whole taken ALL relevant studies together there is NO clear
|> >> indication that menues are faster. (really, surprising but true)
|> >
|> >Have you reviewed ALL the studies possible? I find this amazing, since you
|> >don't even seem to believe a single study measured them as faster.
|>
|> Yes, all studies taken together show that there is NO clear indication. My
|> professor did review ALL the relevant studies.

Er, your professor. As in not you. You may trust your professors
judgement, but WE dont even know who he is. Plus, this is an
.advocasy group. Arguement from Authority is no fun. (particularly
anonymous authority)
 
[deletia- explaination of Proceduralization]
|> 
|> >You are saying that there's some element of a CLI that allows a user to
|> >make use of the computer while practically ignoring it? What might this
|> >be?
|>
|> I wouldn't say that. I would say that the CLI environment lets the expert
|> user express his ideas and actions more fluidly (in certain operations)
|> than with a GUI, since he is not very dependant on system feedback.
|> He anticipates results beforehand, and plans ahead (even types ahead), 
|> for he has a quite accurate model of the human-machine system in his
|> head. (quite the opposite to the novice user)

Having just read "Tog on Interface" [good book!], and therefore
having had my brain suitibly warped :) it occurs to me that maybe
most people don't keep internal models of the system in their heads.
One of the major principles of Apple's interface is making sure that
you do not need to do so, since most people (allegedly) aren't very
good at this, and don't want to anyway. That's the reason for
all teh visible feedback.

Note that there's not a lot I can do about it if you want to dismiss
this as Apple Propaganda (since it seems to be).

|> 
|> 
|> >> Command history                        (mouse macros don't count)
|> >
|> >Wrong! AppleEvents (when recorded) make up a detailed command history.
|>
|> Tell me more about apple events. If they are like AtariEvents, a record of
|> mouse movements, clicks, keyboard input it doesn't count. Why ? Since
|> the events are position dependent! And usually you have to say, start
|> record, perform operation, end record. That is no competition to a shell
|> with history that does this automatically.

An Apple Event is a sort of event that any app can send to any other app,
or to itself, complete with (typed) parameters. Lots of other neat
tricks too, like sending across nets and so on.

Officially, you are supposed to write programs wherein whenever
the user does something, the app sends an event to itself, and
then responds to that event. The events are not position dependant.

I dont know how many apps do this.
 
|> >> Command name completion (not filename) (possible, but not implemented)
|> >
|> >What the heck is this?
|>
|> When you type a command and press [esc] the shell tries to complete the 
|> command. The nice thing is that it does it across paths. You give it a 
|> list of paths and it searches for it there. The equivalent on a GUI 
|> (in any GUI I know) is 
|> 
|> look around
|> find folder you suspect file to be in
|> double-click, *double-click* 
|> (the first one failed)
|> wait for the machine to draw all the icons
|> look around
|> find the folder you suspect file to be in (third level)
|> double-click
|> wait for the machine to draw all the icons
|> look around
|> scroll window down
|> look around
|> scroll window more down
|> look around
|> now either
|> 	did not find it
|> 	then either
|> 		go one folder back and continue search
|> 	or
|> 		give up and use find file (**)
|> or
|> 	find application
|> 	double click *double-click*
|> 
|>

Well, I'd say there are other ways.

On the Macintosh there is no direct equivalent (the system is
really quite different from a CLI, ya know), but here are some
possibilities:

	a) Double Click the document. Let the finder find the
	   right app to launch.
	b) Select the app off the Apple Menu (the Apple Menu  items
	   facility might be considered like a path, I suppose)
	c) Double clikc it (or an alias to it) on the desktop.
	   (same rationale as b)
	d) Use the find command (you only need part of the filename)

Of these, only a and d really qualify as anything liek command
completion. A) is used most often; you generally do not have to know
where the app that made any particular file is to use that file; the
Finder deals with it. But this is no good for creating NEW documents.
 

Also, you make that search above sound slower than it is. One of
the ncie things about icons is that it doens't take long to see/
recognize one. Also, you assume there are LOTS of file in there
(hence the scrolling); This aint the case generally. At least in my
experience. Perhaps its just the way I set up my hard drive. Also
apps do not need lots of auxiliary files on the Mac, which
helps a bit. And icons draw pretty fast. :)

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