Path: utzoo!attcan!uunet!husc6!mailrus!purdue!decwrl!decvax!tektronix!reed!kamath
From: kamath@reed.UUCP (Sean Kamath)
Newsgroups: comp.sys.apple
Subject: Re: hackers/users--interface issues
Message-ID: <9638@reed.UUCP>
Date: 21 Jun 88 05:50:24 GMT
References: <8806192247.aa08285@SMOKE.BRL.ARPA>
Reply-To: kamath@reed.UUCP (Sean Kamath)
Organization: Reed College, Portland OR
Lines: 137

[Before I begin, I want to make it perfectly clear that I will do anything
to continue bashing my head against advancements in technology :-) :-) ]

[BTW - David, don't get me wrong. The point I made was valid, though the
example was silly, if not ambiguous.]

In article <8806192247.aa08285@SMOKE.BRL.ARPA> AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") writes:
>>[>> are me. . .]
>
>>What really happens is that the programmer no longer spends his time
>>on the myriad little things, *nor on the task at hand*, but rather at
>>the 652 page book on guidelines to the user interface.
>
>The Human Interface Guidelines book is actually pretty small...it's
>the *technical* documentation that is big, and it does take time to
>get a feeling for it--but once you do, there is a LOT of useful stuff
>int he toolbox, just waiting to be called by your application! I have
>about four FEET of IIgs documentation, and most of it is NOT about
>interface design issues--it's about how to USE the toolbox routines,
>and if you do that you've almost  *automatically* followed the human
>interface guidelines, since the toolbox does most of the work for you.

But 
what are te majority of the toolbox calls for?  Hmmmmm?  Yes, the use of
the mac environment. . . Which is slow.  I'm not saying this is necessarily
a bad thing, since Apple deemed it appropriate to allocate *8* megabytes for
ROM, and therefore the waste of space is *not* an issue.  What I *am* saying
is that perhaps the space could have been put to better use. . .

>>Now I ask you, go write a program, with a mac interface, on the GS,
>>that inputs a name.  Now do it without the guidelines. . . You end
>>up with a series of calls to the toolkit on the GS, and *one* call to
>>getln in the monitor.  Now, I'm not saying that getln is better, but
>>it's a hell of a lot easier for me, the programmer, do deal with if
>>all I want is a quick way to get a filename.  (good example, that's
>>just exactly what I do right now in Apencode.)
>
>Now JUST A SEC here.  This is how I get a filename in my latest
>project:
>
>  SFGetFile(120,35,'Open what Icon file:',@MyFilter,
>                   TypeListRecPtr(nil),myReply);
>
>It's just ONE CALL to the STandard File toolset.  This one is for
>opening an existing file, and there is an almost-identical one
>for getting a new filename.  myReply is just a RECORD that will
>receive the filename & complete pathname, as well as a flag saying
>if the user chose a file or clicked Cancel.  MyFilter is a function
>that takes a file's directory entry and returns 0, 1, or 2 to say
>whether the file should appear in the list the user sees, and
>whether it should be selectable or dimmed out.

Now *you* wait (Come one, Dave, you should be used to it, what with the
Launcher. . . :-) :-) :-) )

Dave, what language are you in?  Forgive me, but that looks a *lot* like C.
I can write huge programs on one line in C.  So what?  Ok, I said "one
call", and that is "one call", though look how much room you take up on the
stack (assuming ANSI C, short ints, 32 bytes.). Then look at how big the code
is for the toolbox routine (though I give you that I had not initially
mentioned this at all.).  How much stack space is used total?  How much code
(in bytes) is created?  Certainly more than 20 6F FD. . .  Frankly (though I
have to admit I'm very used to the structure used, etc, and I *do* agree it
is "better") I feel that it is a *little* (:-) more complicated, passing two
ints, a string, an address to a filter (?), some *function* return value
(whoo!  Now that's a *BIG* step.  REALLY BIG.) and another int return
value.  Now, I have to say, I'm not sure this is C, but it looks similar,
(in that it just doesn't look like Pascal. . .).  Somehow, just calling a
routine I know will return a sting in a given place is *simpler* (Repeat,
*not* better.  I'm not claiming *better* in a global sense.  Just easier.).
Now, in the long run, this might be *harder*, since you are continualy
having to remove that string from that place, and do a lot of things you
might not have to otherwise, but if all you want to do is get a name, it's
pretty damned easy.

>The Standard File tools let the user select a disk and a directory in
>a nice, standard way (just like the Mac), and they can always Cancel
>the thing.  Unlike GETLN, they don't have to worry about hitting
>Control characters by accident, and they don't have to GUESS at the
>names of their disks, directories, or files.

Yeah, but again, code size. I *agree* that the mac face is *easier* to
*use*.  But say I try and write the identically implemented program on a //e?
Also, while I like the standardization, it's a pain in the hinie.  I *DON'T*
like having to hang on the the mouse button for an hour and a half while I
scroll to the file I want (Don't believe me?  OK, not an hour, but look at
something like a disk repaire program, Suddenly, you have about 40 files,
all called "UNNAMED FILE #xx", so you can't just type a U and go to it!  AN
*SOME* (*NOT* *ALL*) programs *DO NOT ALLOW YOU TO ENTER A FILENAME!*.)  The
problem with standardization is that they restrict.  Look at the RS-232C
*definition*.  Now show me something that *uses* it *fully*.

>>[...] I'm going to wait for something better. Something that does
>>what you say: Better hardware with software that takes advantage of
>>it.  It's like the GS.  Sure, it's got more power than the //e, but
>>does the software take advantage of it?  [...] Do *you* win when it
>>takes hours for P16 to load?  Do you win when your GS takes five
>>hours to redraw the screen?  No.

>You're exaggerating...it never takes more than 4 hours and 52
>minutes for my IIgs to redraw the screen, and never more than 29
>minutes to boot P16 [ :-) ].

:-) :-) :-) :-) :-) :-)  I *like* that one, Dave!

>>The software (well, some does, but not a lot) doesn't really show off
>>the hardware, it exposes it.  That's not what good software is
>>supposed to do!
>
>Have patience!  Well, have a LOT of patience.  There is a growing
>amount of decent software for the GS (I know, because I've been
>growing some of it right here on my hard drive...).  Apple is also
>continuing to improve the performance of the system software, which
>will help a lot.

Exactly.  I have patience, that's why I don't have one (well, OK, I'm also
short the $2000 it'd take to buy one. . . See, I got about $800 targetted
for a hard disk fist. . . :-) ).  In the meantime, I can write code on my
//e, which I *enjoy*, and I already *own*. . .

>>Sean Kamath (see, it really was me!)
>
>--David A. Lyons - a.k.a. DAL systems
>  PO Box 287 | North Liberty, IA 52317

(Ever been to north liberty, anyone?  Rockin' sockin' town, I tell you! :-)
(I hope you appreciate that, Dave.  You have to admit, the atmosphere is
*very* condusive to coding. . . :-)

Sean Kamath
(Yo, I haven't changed by .signature just yet.  I'm looking for another
gateway through from Bitnet, though I think I have a nice new ARPA gateway.
Also, Reed should *eventually* get on BITNET, then things should be fun. . .)
-- 
UUCP:  {decvax allegra ucbcad ucbvax hplabs ihnp4}!tektronix!reed!kamath
CSNET: reed!kamath@Tektronix.CSNET  ||  BITNET: reed!kamath@PSUVAX1.BITNET
ARPA:  reed!kamath@PSUVAX1.CS.PSU.EDU
US Snail: 3934 SE Boise, Portland, OR  97202-3126 (I hate 4 line .sigs!)