From: wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!)
Subject: Re: Trepidations of a potential mac-user (long)
Date: Sun, 27 Sep 1992 22:55:43 GMT
Organization: MSD software vault #9 @THD

In article <6042.2ac32a2f@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
>In article <1992Sep24.222259.39457@news.th-darmstadt.de>, wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!) writes:
>> [stuff deleted]
>>>BTW, who is Fitts' and what is his law?
>> Oughta be in every basic Software Ergonomy text.
>
>Wait a second. Ergonomics is the study of human motion. I'm afraid this has
>little to do with computer interfaces. From an ergonomic standard, the

Just go to your library, possibly the psychology section and check it out.
I am pretty sure that the term Software Ergnomie is used also in the US.
BTW Ergnomics is not the study of human motion, check your dictionary.

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

> [ deletions]
>> You are not, I repeat NOT, superman and even with a 
>> million years of practice you will need a lot of time scooting around 
>> with the mouse pointer. 
>
>Time is required, yes. But this time is OVERLAPPED with other cognitive
>operations. I (or anyone with a couple of hours experience) can mouse around
>the screen without thinking about it. 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. 

>> Just f.e. Show Info (or whatzitname on the
>> Mac): Manuever mouse to drive icon, click, manuever to menu entry "File", 
>> click, maneuever to "Show File Info" click. These are times you can't
>> reduce. 
>
>I just tried this experiment a few times. I also payed attention to my 
>mousing action. This operation took me a few seconds, perhaps six
>at most. And Fitt's was right -- when I had to go across the screen, I
>missed. Fortunately, I corrected immediately.
>
>> On the other hand on the keyboard even if you haven't exercised madly
>> you can type a short string like 'df' very fast. And if you have been using
>> the system long enough, the mental strain for fetching 'df' as the
>> filesystem info command is negligble. 
>
>The task you specified wasn't to "type 'df'." The task you specified was
>to get file storage information for a particular file. You did not include
>in your command line example a) the time required to remember exactly where
>the file is b) the time required to mentally maneuvour the default directory
>to the desired place (just short of the file) c) the time required to type
>in (correctly) the commands to change the default directory. d) the time
>required to remember and recall that it is the 'df' command that gives the
>information you want, e) the time to type in (correctly) the name of the
>file you wanted information on. (I assume 'df' dumps the information on all
>of the files in a given directory. If you have a lot of files, you'd have
>a problem that this information scrolls off the screen, perhaps scrolling 
>off the file you wanted to know about.)

df shows the free system space. Regardless of position. So a-c don't apply.
When you take in your favor to be an expert handler of the GUI, I can
claim to be an expert handler of the CLI. So d) is the same for you and me.
e) I am obviously faster than you.

This means, we have a case where the CLI user for a given task is faster
than the GUI. 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. 
The problem with you is that your 'stuck' on a system that doesn't use
CLIs (although whenever your resort to typing in a GUI, you are down
to CLI level) alongside a GUI. I as an Atari user habitually go from a
CLI, where "software creation" is done best to a GUI, where file mani-
pulation is done best.


>[deletions]
>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.

>[plenty of deletions]

>Now the stupid part. You know that all programmers do? You guessed it, they
>name their files <whatever>.c. Duh. Tradition.

>[deletions]
>No, you've got it backwards. The syntactic links are forced on you, the user
>in order to moderate the difficulty you have working through the CLI. By
>adopting a rigid convention, you can take advantage of certain CLI wildcard
>features some of the time.
A whole lot of the time.

>So, the CLI actually restricts you, it doesn't help you.

Come on, that's ridiculous. Do all your files have different icons ?
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...
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...

>>>> But it's kinda obvious that touch *.c can't be beaten with the mouse, 
>>>> while I press RETURN you're still scrolling your window, visually 
>>>> identifying objects and clicking them.
>>>
>>>The difference here is that I constructed a generic case. You constructed a
>>>special case that is specially streamlined for your CLI.
>> 
>> Your generic case is a case specially streamlined for a GUI, selecting an
>> arbitrary list of unknown unrelated objects. 
>
>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.


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

>> How often do you select the "first four columns" of the window in real life ?
>
>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".

> [deletions]
>> The goal "to delete all the C source" files is not
>> related to the userinterface, only the translation of this goal into
>> a (series of) action(s) is dependent. 
>
>I protest that the goal is too simplified an example to express any 
>adequate comparison of the two types of interfaces. If we make the
>goal "delete all unwanted files" -- a generic case, then the graphic 
>user interface beats the CLI hands down. This is because "unwanted" is
>not always structured into some handy syntactic convention that the CLI
>is optimized for.
I never ever said that I wanted to make a adequate comparison between a 
CLIs and GUIs, I am just refuting your claim that whatever a CLI can do
the GUI can do better.


>> I think it's plain to
>> see that typing 'rm *.c' is not an outwordly brainconsuming task and faster
>> than selecting a bunch of icon and dragging them to the trashcan.
>
>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.


>>>it be painful to find out that you deleted aimportantfile.c by mistake.
>>>Oops.
>> You're confusing two concepts here, the userinterface be it a GUI
>> or a CLI has nothing to do (conceptually) with the operations the OS performs. 
>
>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.


>>>However, for instructing a computer to perform operations,
>>>the mouse, coupled with the graphic display of information can't be beat
>>>by the keyboard.
>> In what terms ? Ease of learning, I would agree, although that doesn't
>> mean scientifically that any GUI is easier to learn than a CLI. Speed
>> of execution at all times ? No way!
>
>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.

Nat!
-- 
 -----   Email: wallmann@backus.pu.informatik.th-darmstadt.de  -----
                "Bang that bit that doesn't bang"                 
 Album of the month: "Psalm 69" Ministry