From: wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!)
Subject: Re: When is a CLI faster than a GUI?
Date: Thu, 1 Oct 1992 21:27:10 GMT
Organization: MSD software vault #9 @THD

In article <6072.2ac8373c@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
>In article <1992Sep28.202604.20391@news.th-darmstadt.de>, wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!) writes:
>>>No, it does not.  Every time someone sits down with a stopwatch
>>>and times someone, they find that this is not true.  Regardless of
>>>how experienced the user is.
>>
>> That is complete bullshit!
>
>So, the guys with the stopwatch are lying? Or is there some sort of
>temporal distortion in the vicinity of the CLI-driven keyboard?
What guys with what stopwatches ? Since I know that there are studies with
guys'n girls with stopwatches where it is NOT true (I choose at this point
to mention, that I did study Software Ergnomics very recently (done since
July)) the poster above was either merely making something up or extra-
polating from Apple Newsbulletins or somesuch.


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

>> Snide remark: The apparent lack of understanding of some  Mac users that
>> there is something like proceduralization which allows the user to
>> interact (after exercise) with the system using very little 'attention',
>> seems to indicate that the Mac GUI is severely lacking in some
>> respects.
>
>Explain this to an "ignorant" mac user -- what the heck is "proceduralization."
>(I'm pretty sure it isn't in my dictionary)
Sorry, this was Germaninglish. What I meant was a reference to Anderson's
process system, which I can't justly explain in a few words, since it took
me some time to fully grasp (-> weeks). I thought about the german word
Prozedur -> procedure, when writing this, and it was meant to mean 
"compiling/optimizing a mental procedure to allow it to be run with little 
"mental resources" tied up". (*)

Take this as flame, if you must, but it isn't intendend as such. Why don't
you, since you are obviously interested in the subject, pick up a book
about Software Ergonomy. Psychology is usually quite fun to read, and
interesting since everybody has the hardware (har), and for a couple of
points, where I am apparently unable to explain it convincingly, maybe 
the book can.

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


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

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


Nat!
(*)  Just forget about it. Anderson would kick my butt if he read this.

(**) If you say you always use find file whenever you want to locate
     something a level lower, well... I somehow would not quite believe
     you.
-- 
 -----   Email: wallmann@backus.pu.informatik.th-darmstadt.de  -----
                "Bang that bit that doesn't bang"                 
 Album of the month: "Psalm 69" Ministry

Newsgroups: comp.sys.mac.advocacy