AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (06/20/88)
>Date: Fri, 17 Jun 88 01:17:40 GMT >From: Sean Kamath <tektronix!reed!kamath@ucbvax.berkeley.edu> >Subject: Re: "hackers" vs "users" >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. >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. 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. >[...] 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 [ :-) ]. >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. >Sean Kamath > >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!) --David A. Lyons a.k.a. DAL Systems PO Box 287 | North Liberty, IA 52317 BITNET: AWCTTYPA@UIAMVS CompuServe: 72177,3233 GEnie mail: D.LYONS2
kamath@reed.UUCP (Sean Kamath) (06/21/88)
[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!)
AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (06/22/88)
>Date: Tue, 21 Jun 88 05:50:24 GMT >From: Sean Kamath <tektronix!reed!kamath@ucbvax.berkeley.edu> >Subject: Re: hackers/users--interface issues >But what are te majority of the toolbox calls for? Hmmmmm? Yes, the >use of the mac environment. . . Which is slow. No!!! The *environment* isn't slow; only the current *implementation* is slow. And it's not all *that* slow--mostly it just BOOTS slowly. (If you open enough windows at a time, you can MAKE it slow, of course; and more speed in the GS+ will certainly help make real GS word processors usable.) >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. . . All right...what do you think should be added to ROM besides the rest of the toolbox? >Now *you* wait (Come one, Dave, you should be used to it, what with the >Launcher. . . :-) :-) :-) ) I don't normally *use* the Launcher...I use Davex. The Launcher isn't even slow--just LOADING THE RAM TOOLS is slow. And if you have been running other desktop-based software, they will already be loaded & you can zip in & out of the Launcher and Finder pretty quickly. >Dave, what language are you in? Forgive me, but that looks a *lot* >like C. Actually, it was TML Pascal, but you're right--it does look a lot like C. The reason it doesn't look like Pascal is that there are some extensions to make toolbox access easy: "@" takes the address of a function, procedure, or variable. Type identifiers can be used LIKE FUNCTIONS (but no code is produced) for changing one type into another. TML Pascal (as shown in my previous msg): SFGetFile(120, 35, 'Open what Icon file:', @MyFilter, TypeListRecPtr(nil), myReply); APW C (looks almost the same!): SFGetFile(120, 35, "Open what Icon file:", MyFilter, (TypeListRecPtr) NIL, &myReply); >[...] 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. . . How much stack space is used? I really don't care, since it has no effect on my program. I suspect it uses somewhere around 2 pages of stack, since StdFile calls WindowMgr to get a modal dialog, the dialog manager calls the control manager, and the control manager calls QuickDraw. (This is oversimplified, but it gives a reasonable picture of what's happening.) The *point* is that the programmer doesn't need to care about any of this--it's all taken care of, and *much* simpler than trying to provide anything in your own code with the functionality of Standard File. Remember it lets the user do treewalking to explore the directory structure of any online disk! How much *code* is generated I can answer: 3 bytes for pushing each 16-bit word on the stack (10 words * 3 bytes = 30 bytes), plus 7 to make the call (LDX with a word and JSL to the tool dispatcher), then 4 to store the error code in Pascal's "ToolErrorNum" variable. Total=41. >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, Yup, it is a little more complicated, but it provides a LOT more functionality as well as consistency for the user. It's well worth it. >passing two ints, a string, an address to a >filter (?), some *function* return value (whoo! Now that's a *BIG* >step. REALLY BIG.) I'm not following that too well...what's passed is the address of a Pascal function that looks likes the one below. This complication is OPTIONAL! If you want *all* the files to be selectable, you can just pass 'nil' instead of a function pointer! (There's also a simpler approach...the TypeListPtr parameter can point to an array of filetypes--I don't use that approach myself because it doesn't give the option of having files appear but be dimmed.) function MyFilter(p: DirEntryPointer): integer; begin if p^.filetype = {whatever you want} then MyFilter := 2 {2 means the file will be selectable} else MyFilter := 1; {1 means the file will appear in the list but won't be selectable} {return 0 if the file shouldn't appear in the list at all} end; >>The Standard File tools let the user select a disk and a directory in >>a nice, standard way [...] >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? Identically-implemented isn't possible, but I assume you mean you want the user interface to be the same. Then you have a problem--since there's no Standard File stuff in the //e's sytem software, you have to write it yourself or change your user interface. Portability is not generally one of the benefits of a desktop interface! >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! Okay, so put the little mouse pointer in the shaded "page down" area below the scroll thumb, and click the little mouse button a few times. Or pick up the thumb and move it where you want. I'm *sure* you nkow this, but I'm not sure why you're complaining! >AN *SOME* (*NOT* *ALL*) programs *DO NOT ALLOW YOU TO ENTER A >FILENAME!*.) The problem with standardization is that they restrict. On the contrary! Standardization isn't the problem at all. Standarization lets you CUSTOMIZE! On the IIgs, if you don't like the way Standard File works, you can write your own and put it in your */SYSTEM/TOOLS directory. And it will be available in *every* program that uses the Standard File. (If you don't think this is a reasonable thing to do, I might just have to do it to annoy you...I've been wishing I could go BACKWARDS through the list of disks, instead of advancing to the NEXT one...takes too long with my excessive collection of drives.) >(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. . . :-) Hey! Capitalize my town's name, or I'll start decapitalizing your name, sean! I know what you mean about the atmosphere...it was about 103 degrees here today, so I'm just staying inside and writing an Icon Editor. <grin> >Sean Kamath >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!) --David A. Lyons a.k.a. DAL Systems PO Box 287 | North Liberty, IA 52317 BITNET: AWCTTYPA@UIAMVS CompuServe: 72177,3233 GEnie mail: D.LYONS2
kamath@reed.UUCP (Sean Kamath) (06/28/88)
In article <8806220019.aa06928@SMOKE.BRL.ARPA> AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") writes: >>[me] >No!!! The *environment* isn't slow; only the current >*implementation* is slow. And it's not all *that* slow--mostly it >just BOOTS slowly. (If you open enough windows at a time, you can >MAKE it slow, of course; and more speed in the GS+ will certainly >help make real GS word processors usable.) Then I claim the only implementation that will speed it up is mass hardware upgrades, like coprocessors and a dedicated video CPU, as well as DMA disk access, with intelligent caching. . . Wait a minute. . . >All right...what do you think should be added to ROM besides the rest >of the toolbox? How about allowing the user to expand his/her usable RAM to up to 12 Meg, and saving 4 meg for ROM? Actually,I'm really coming close to biting my own ass off here, I don't know exactly how it's reserved. I'm sure gobs o' space go to the video firmware (by way of screen buffers, etc.). Just how much of the "reserved" ROM is unused? It seems to me that only about 2-4 megs should *ever* be actual ROM. . . >I don't normally *use* the Launcher...I use Davex. The Launcher >isn't even slow--just LOADING THE RAM TOOLS is slow. And if you >have been running other desktop-based software, they will already be >loaded & you can zip in & out of the Launcher and Finder pretty >quickly. Pretty quickly compared to what? Until the graphics environment becomes faster than the text environemt, I will probably use the text environment. (the reason I say probably is that *sometime* (rarely) I actually use graphics!) >Actually, it was TML Pascal, but you're right--it does look a lot >like C. The reason it doesn't look like Pascal is that there are >some extensions to make toolbox access easy: "@" takes the address >of a function, procedure, or variable. Type identifiers can be used >LIKE FUNCTIONS (but no code is produced) for changing one type into >another. > >TML Pascal (as shown in my previous msg): > > SFGetFile(120, 35, 'Open what Icon file:', @MyFilter, > TypeListRecPtr(nil), myReply); > >APW C (looks almost the same!): > SFGetFile(120, 35, "Open what Icon file:", MyFilter, > (TypeListRecPtr) NIL, &myReply); Uh, Dave, if @ takes the address of the funct, then you ought to have a '&' before the MyFilter above. . . Generally, I find pascal to be a little wierd. The current variation on Pascal I use always sends addresses. They are always 4 bytes wide, and that takes care of that. So it's a little wierd that you have to address MyFilter, but not myReply, yet in C you send the address of myReply, obviously for modification my SFGetFile. . . Well, this is all sort of academic. Either I don't get it, or you haven't fully explained everything (such as data types and specs for the calls. . . ). >How much stack space is used? I really don't care, since it has no >effect on my program. I suspect it uses somewhere around 2 pages of >stack, since StdFile calls WindowMgr to get a modal dialog, the >dialog manager calls the control manager, and the control manager >calls QuickDraw. (This is oversimplified, but it gives a reasonable >picture of what's happening.) Well, don't you thing you ought to care? I mean, suppose you use up your entire bank of stack space? With todays current recusive wonder-routines... >The *point* is that the programmer doesn't need to care about any of >this--it's all taken care of, and *much* simpler than trying to >provide anything in your own code with the functionality of Standard >File. Remember it lets the user do treewalking to explore the >directory structure of any online disk! If you really want to do all this (and *I* do, sometimes), you write in a high level language and use prolific macros. And if you plan on getting really serious, you get an Apollo or Sun workstation. If you recall my *original* point, it was that given the size of code generated, time involved, and ease of use *from assembly*, it just doesn't cut it! Include compile time! Geez, we are really talking Apples and Oranges here! I'm *not* saying that that is bad for Major applications (including serious utilities etc), just not for the quick hack! >How much *code* is generated I can answer: 3 bytes for pushing each >16-bit word on the stack (10 words * 3 bytes = 30 bytes), plus 7 to >make the call (LDX with a word and JSL to the tool dispatcher), then >4 to store the error code in Pascal's "ToolErrorNum" variable. >Total=41. Ha! that's a 1300% increase it space! Gaaaaaa.a. . .a., >Yup, it is a little more complicated, but it provides a LOT more >functionality as well as consistency for the user. It's well worth >it. There you go again, arguing functionalitiy vs. ease of program usage. Why is it that programs for apps get so *damn* large so *damn* fast? Because of the freaking *functionality* of their user interface. >[More prolific examples of functionality] Again, David, the discussion was not concerning functionality, or "correctness" of code, or anything related to that. It was on "hacking" and the user_interface. (jeez, can you tell I'm getting used to those underscores at work!). I maintain that as a programmer, it is, and always be, easier for me in a low level language to dispense with the user interface as best I can (making truely cryptic prompts such a "1:" or "in", and not a little window showing me all the choices, and a nice message saying "please select the file that you would like to convert, then click on 'open'".), and get to the actual work at hand. When that is done, then I can go back and get to work on a nice user interface. >Identically-implemented isn't possible, but I assume you mean you >want the user interface to be the same. Then you have a >problem--since there's no Standard File stuff in the //e's sytem >software, you have to write it yourself or change your user >interface. Portability is not generally one of the benefits of a >desktop interface! Exactly. Whoopie. >Okay, so put the little mouse pointer in the shaded "page down" area >below the scroll thumb, and click the little mouse button a few >times. Or pick up the thumb and move it where you want. I'm *sure* >you nkow this, but I'm not sure why you're complaining! The point is that sometimes programs hedge on the guidlines. Also, if you have ove about 100 options, you really can't use the thumb effectively, you end up going up and down, and spend as much time as whamming on the mouse button in the first place! >On the contrary! Standardization isn't the problem at all. >[example of customization] Standardization supposedly guarantees that you always get the same thing when the same type of event occurs. And I can just see me sitting at your GS, and trying to figure out just exaclty *how* to use your fileselector! :-) >Hey! Capitalize my town's name, or I'll start decapitalizing your >name, sean! I know what you mean about the atmosphere...it was >about 103 degrees here today, so I'm just staying inside and writing >an Icon Editor. <grin> Sorry 'bout that. Jeez, I sure hope you guys get some rain soon! >>Sean Kamath (see, it really was mine!) >--David A. Lyons a.k.a. DAL Systems PS, for anyone who didn't see it in Open-Apple this month, Dave got prominent mention by Tom Waisar this month. Congrats on getting Roger Wagner to publish your NDA thingie! :-) -- 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!)