From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: Trepidations of a potential mac-user (long)
Date: 28 Sep 92 14:23:08 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <1992Sep27.225543.42016@news.th-darmstadt.de>, wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!) writes:
> In article <6042.2ac32a2f@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
>>little to do with computer interfaces. From an ergonomic standard, the
> 
> BTW Ergnomics is not the study of human motion, check your dictionary.

I stand corrected.

>>Regardless of Fitt's law, manipulating the mouse is akin to the skills you
>>use every day grabbing your coffee cup. The cognitive load is similar,
>>as is the physical one.
> So what ? Curiously enough the Mac is delivered with a keyboard (I think
> they even put cursor keys back on) so typing is a skill you're gonna need
> no matter what.

Yup. I stated in a previous posting that I would rather use a keyboard to
type text than select characters or words with the mouse.

But typing words is different from typing commands. Especially cryptic 
commands arranged in a rigid computerised form. I can sprinkle my postings 
with a few errors, but you will still (hopefully) understand me. If you don't
you'll no doubt post or mail back. 

The computer is neither as understand nor as forgiving as you are.

>>It doesn't take a superman. Just like
>>you can drive your car or ride your bike somewhere without thinking about it.
>>It's the same type of skill, and it comes from our earliest experiences.
> Sure but your the distance covered does not become less. If you were
> to ride 10km with a bike or walk 100m on one leg, you'd be faster walking
> nevertheless. 

You obviously, completely, missed the point.

We're not just looking at physical motion. We're also looking at cognitive
motion. If you just measure the physical motion, then you'll come to the
wrong conclusion. You seem determined to do just that.

>>The task you specified wasn't to "type 'df'." The task you specified was
>>to get file storage information for a particular file. 
> 
> df shows the free system space. Regardless of position. 

AH! So typing df doesn't even give you the information asked for in the
task! <grin>

I interpreted your example incorrectly. You're actually looking for the
file system free space for a particular drive.

We'll that's easy. Just look at the top of the window. Its there. OK, if
a window from that disk isn't open, you can click on the disk and choose
Get Info, but you can easily double click on the icon to open it and look.
Much easier.

> This means, we have a case where the CLI user for a given task is faster
> than the GUI. 

That has yet to be shown. When this free space task arrives, I merely
look up to the top of the window. (Opening the window if necessary) 
You on the other hand, must wait until a command prompt comes up, then
type df, and pick out the drive you are inquiring about out of the list.
If your system has only one or two drives, this might be easy. Mine has
five, plus a number of network mountable disks. 

> Now imagine that you have a whole lot of tasks involving
> operations that are faster on the CLI than on the GUI, and sure enough
> you have a case where a CLI is preferable to a GUI. 

If you construct a set of tasks that meet the former condition, then you
will certainly come to that conclusion.

Let's suppose you constructed an IQ test that happened to have a large
number of questions concerning MS-DOS programming. You give the test,
then conclude that MS-DOS programmers have high IQs. Small wonder. 

You biased your tests. You deliberately constructed an example to come to
a forgone conclusion. You have shown no proof that your collection of tasks
demonstrating CLI superiority represent a good sample of real world tasks
from the typical user. Most importantly, you may have left out tasks from
your sample where the CLI does most poorly, and these tasks that have
been left out may constitute a representative sample of the tasks performed
by users.

> The problem with you is that your 'stuck' on a system that doesn't use
> CLIs alongside a GUI.

This is not true. I have MPW and I use it for development. I have occasion
to use the CLI in MPW. I don't use it much. I find that actually being able
to see and manipulate my work directly is much eaiser that encoding cryptic
commands. When I do use it, I depend heavily on commando. (Commando is like
the ultimate help system, it gives a dialog-box like represtation of the
command arguments, and makes sure you get the right stuff in the right order)

> (although whenever your resort to typing in a GUI, you are down
> to CLI level)  

When I type, I type English text. I've learned how to do this since I was
9 months old, when I first started to speak. Subsequently, I'm good at it.
There's no comparison with computer CLIs.

>>You appear to be arguing that "since my fingers don't have to move so far,
>>keyboarding must be easier." I find this an inconceivably shortsighted
>>application of "ergonomic" theory to computer interfaces.
> I never said keyboarding is easier, I say for certain tasks a expert
> user is faster.

Again, you fail to take the cognitive time in to account. Even the expert
user has to think. 

>>Now the stupid part. You know that all programmers do? You guessed it, they
>>name their files <whatever>.c. Duh. Tradition.
> 
>>So, the CLI actually restricts you, it doesn't help you.
> 
> Come on, that's ridiculous. Do all your files have different icons ?

They have icons according to their type. In certain types of applications,
(Graphic editing, QuickTime moves) a thumbnail icon of the image is certainly
more helpful in identifying the item than a name would be. System 7
has the capability to give each file its own icon, but this wasn't what I
was referring to.

Since all THINK C source code files have the same icon, the ".c" on the end
is superfluous.

> Do you have a naming scheme, that is unrelated to their content. What would
> you think about an icon with a big C on it and the name dunno.pas...

I would think it was foolish. Of course, you knew it was foolish when you 
created the example, so this is just a straw man.

I create names according to content. Using the ".c" is kinda ridiculous. It
isn't necessary.

> The naming scheme is well used in GUIs too. Technically you don't need them
> for ANY of the two. It's convenience. Does your GUI have ordering schemes
> for filename extensions ?? I thought so...

Filename extensions? What's that? The Mac doesn't have them. (ie you thought
wrong)

>>Ah! But these object weren't unknown or unrelated! You require the files to
>>be related by some syntactic convention of their file names. I submit this
>>is rarely the case. But their may be files that are related by something
> 
> What kind of work are you doing ? In my daily life they are strongly related.

Only because the CLI imposed this rigidity on you.

>>other than a rigid syntactic similarity. Perhaps they all involve the same
>>topic, or they were all created by the same application.
> 
> Well in the second case, even in a GUI you usually have a certain filename
> extension do you ?  

READ MY LIPS -- THE MACINTOSH DOESN'T HAVE FILE NAME EXTENSIONS.

It has file names.

Sheesh. I hate having to put up with people in a debate who obviously don't
have a clue to the issues. You've obviously never even seen a Macintosh,
much less used one.

> Given that you put uncle Herberts face on all icons
> depicting letters to uncle Herbert, yes this is a case where the GUI 
> can't be beat.

Thank you.

>>All the time. I typically do it as a shortcut. Sometimes it is easy to 
>>visually recognize that you want all the files in a certain spot, except a
>>couple. So rather than shift-clicking on every one you want, it is quicker
>>to select a bunch, then shift-click to deselect the ones you don't want.
> Well in that case you were NOT really selecting the "first four columns".

I don't think of it that way. If I had to verbalise it to a computer in a
command line, I'd probably have to type "colselect 1 4" or something. Instead,
I do something far simpler. I use the mouse (inaccurately, according to Fitt's
Law) and select the ones I (almost) want. I don't have to think about which
column they are in.

>>Unfortunately, there's more than just typing involved. There's the realisation
>>that 'rm *.c" is what you want to do. You have again convieniently deleted
>>the cognitive steps required to come to that conclusion.
> 
> As explained last time, the user's planning of this is independent of the
> user interface.

As explained last time, it isn't. With a visual interface, there's little
planning. With a CLI, you HAVE to plan to get work done. Experienced CLI
users plan a bit faster, and they conform their work conventions to be
compatable with the limitations of the CLI in order to AVOID planning.

>>Yes it does. People are human. They make mistakes. Any type of man/machine
>>interface should be tolerant of those mistakes. That's part of what makes
>>a good user interface. I'm not confusing anything.
> No it doesn't. A CLI on the Symbolics for example just marks those files
> deleted, and the OS wipes them away after a day or so, but you can umark
> them easily.

Or you could run an "undelete" application on your PC. You miss the point. 
if you type 'rm *.c' you can't see the results. You may be unaware you
deleted some important file. With a graphic user interface, you can see
it, right there, mister important file is in front of you. If you drag him
to the trash, you know he is going to disappear. Retrieving is a simple
process, drag him out of the trash. With a CLI, you have to run another
command to undo what you did, provided you realise your error soon enough.

>>Again, it depends on how you measure speed. I measure it in the time it
>>takes to get the job done, CORRECTLY.
>>
> Since your job is (apparently) doing graphics, I am sure that you are far
> happier with a GUI. I as a programmer would be VERY unhappy if I just
> had a GUI.

I have a surprise. I'm a programmer.

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

Newsgroups: comp.sys.mac.advocacy