From: wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!)
Subject: Re: Trepidations of a potential mac-user (long)
Date: Wed, 30 Sep 1992 23:25:53 GMT
Organization: MSD software vault #9 @THD

In article <6062.2ac7154d@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
>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:
>[deletions]
>>>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.

I don't know what kinda OS your running on your brain. (har (*)) You can
optimize mental procedures to a point where they go 'real fast' and from
a psychological point use very little 'mental resources'. On the other
hand those physical motions are factors that remain stable. 
Or in other words mental processes have much more room for improvement,
than physical processes.

>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.
No, no for all the drives...

>[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.
>
>Again, you fail to take the cognitive time in to account. Even the expert
>user has to think. 

But as I point out time and time again, the time for each user (GUI or
CLI) is the same. Since the user has a internal model of the 
system (else he wouldn't function) he runs his plans procedures there and
then interfaces with the real world again to issue commands. The non-expert
use will be more interested in feedback from the interface (and what is
called obligatory control points), but the expert user with his procedures
finely honed, uses this only to a very small extent.


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

Guess what, the GEM system is a GUI too and it uses filename extensions, 
I am pretty sure it's the same for AMIGA Workbench and Windows. 


>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.
If I had your attitude, I wouldn't even be thinking of responding...

(BTW I played Crystal Quest quite a lot). The Mac also as an item 
'Sort by type", which I remembered as sort by filename extension. In
fact though, the Mac app. uses a seperate field in the directory entry
to record the type of the application. Now this looks very much like
a rigid filename extension to me. (a rose by a different name...)


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

The point I tried to make (about three articles ago) was that something
like colselect 1 4 is very unlikely to happen, that in fact what I'd called
common 'fate' was more likely to be a cause for selection. Then we went off
to filename extensions...

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

If that was true (which it isn't) than GUI users would, by sheer 
convenience never adopt better strategies of doing things, since they
rarely have to plan. They just look, see what's on the screen and react.
It just isn't that way.

Anyhow, wherever did you get the idea that you have to plan in a CLI more
than you have to in a GUI ? In a GUI you usually have a better look at
the available resources, but that rarely has anything to do with planning.

o For the expert user to build the plan that he wants to lets say
  make a project in the background while he wants to start reading the
  news with rn is the same as for the Mac user.

o The access to knowledge how to do this is quite the same for both

o The actual execution of the CLI user is faster goddam' it!
  
>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
Hah! When I select a bunch of files and drag them into the trashcan, (on
the Atari you see outlines of those moving anyhow, I think it's the same on
the Mac) I have made my mistakes. The time I notice is usually, when I miss
the file, not when executing the drag. Or do you delete file by file ?
There is an option where the system tells you 'Deleting file: xxxx' for
every file it deletes. Well great if you have a floppy, but deleting from 
the harddisk you see a blurr.

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

Well for once on the Atari GUI, if you drag it into the trashcan it's GONE!
So for that alone you'll see that this is VERY much not a feature of a
GUI, but just of the particular implementation.

And dragging your files from your Mac trashcan and running another command
from a CLI is, you guessed it, equivalent.

>>>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.
I am surprised. You must be a one-tool guy then. (har)

Nat!
 (*) One har == one smiley (but I hate smileys)

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