From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: When is a CLI faster than a GUI?
Date: 2 Oct 92 16:57:34 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <1992Oct1.212710.31862@news.th-darmstadt.de>, wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!) writes:
> 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.

While some of the study information was DISTRIBUTED via Apple sources, that
does not mean it came from Apple Newsbulletins. What I read indicated much
surprise that keyboard commands weren't found to be faster than mouse
operations. They weren't faster. In at least some instances, they were
slower.

And that was for keyboard equivalents. When you compare this against 
command lines, the keyboard becomes even slower.

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

Then it is a wash. Using the keyboard or the mouse is equally as fast?
That's still a breakthrough for all these people who use keyboards
thinking they are faster -- they're the same speed.

>>Explain this to an "ignorant" mac user -- what the heck is "proceduralization."
>
> 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). 

Well, if you can't adequately explain it, perhaps there's some reason why
people are ignorant of it.

> and it was meant to mean 
> "compiling/optimizing a mental procedure to allow it to be run with little 
> "mental resources" tied up". (*)

After a sufficient period of training, I believe this is true. You mentally
subsume certain tasks at an almost intuitive level. These CLI experts are
able, after a sufficient amount of training, to crank out really awesome
command lines with little apparent effort, provided they follow common
experience.

Going back to the stopwatch, however, I believe you'll find that the speedup
provided by this proceduralization isn't tremendously significant between
experts and those with moderate experience. (Novices are lost on a CLI)

Returning to psycology, we find that humans are very good at recognition,
but are terrible at remembering. Since a CLI depends primarily on 
remembering, it makes sense that a visual interface (which depends on
recognition) makes better use of the human neural power.

Now, you can train your CLI users to the point were they are really fast,
but you gotta train the visual interface users to the same point. I believe
the visual interface users will still be faster, although the gap may narrow
quite a bit.

Looks like there's some room for a Masters or Doctorial study.

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

But the experienced graphic user interface user has the same advantage.
He can anticipate results, plan ahead, and keep an accurate model of
the human-machine system in his head.

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

They aren't. Aren't AppleEvents are a high-level event that is generated
by the application. When you click, type and whatnot, AppleEvents looks 
at the high-level picture of what you did.

For example, if you were to open a document, an application would record an
'odoc' event to record it. (Not that you moved the mouse to the File menu,
Clicked, Moved down to Open, Moved over to the SF Dialog, scrolled down
twice, selected a file) ((Heck, you might even have used Command-O and
guided the SF Dialog from the keyboard))

>>> Command name completion (not filename) (possible, but not implemented)
>
> When you type a command and press [esc] the shell tries to complete the 
> command. 

(The user interface designer in me asks the question -- why the heck do you
have to press "esc"? Why not just match the command as you type, and erase
your match if the user types more -- I implemented an interface like this
for file name matching in Smartcom III and Smartcom Exec)

There's really not an equivelent of this in a graphic interface because,
THERE ARE NO COMMAND NAMES! Sheesh! Why should you have to complete
command names if you don't have any in the first place.

> The equivalent on a GUI (in any GUI I know) is 
> 
> [ Long list of hopeless, folder by folder searching deleted ]
> 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*
> (**) 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.

If you are that clueless about where a file is, using the find file 
is the best idea.

The visual interface is better when you already have an idea of where
something is. This property is enhanced because you can actually SEE it,
you don't have to remember the name and type.

Command completion doesn't seem to be very useful. The only thing I can
see is that is saves a few characters of typing. You still have to remember
the right command in the first place. It would make long command names
more palatable, however.

-- 
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.