bright@Data-IO.COM (Walter Bright) (04/06/89)
In article <28684@ucbvax.BERKELEY.EDU> jas@ernie.Berkeley.EDU (Jim Shankland) writes: >That's tantalizing. Would you be willing to elaborate a little on what >you think makes a good graphical interface, what's a good example and >why, and what's wrong with the IBM PC keyboard and Macintosh icons? What's wrong with icons is not necessarily icons, but what I've called "iconitis". This is the religious fervor by which an icon is invented for every command, because icons are 'better'. For example, I once attended a seminar put on by a person badly afflicted with this disease. He passed around a char with about 50 icons in it (that were all in use by various mac programs) and asked programmers (who were unfamiliar with the mac) what they meant. Very few were consistently identified. One was an icon for 'printer'. Nobody figured that one out till they were told that that was supposed to be a picture of a printer. I've also seen a lot of effort expended to come up with an icon for 'Help'. Those people got mad when I suggested the string 'Help' would do nicely. Another reason that excessive icons are trouble is the tendency to copyright the %^&* things. Walla, every program has a different set of icons that mean the same thing. Talk about counterproductive. The end result of iconitis is Chinese. Chinese has an icon for every word and concept, and the result is, well, have you ever tried to learn it? English is an excellent vehicle for describing abstract things, or things which cannot be easilly represented as a 16*16 bitmap. Things such as 'Help', 'Print', 'Save', 'Exit', 'Delete', etc. What's wrong with these, and I defy anyone to come up with an icon for these that would be correctly identified by more than 50% of the computer users you present it to. Don't misunderstand me, icons have their place. The arrows on the ends of scroll bars are an ideal example of correct use of icons. I don't know anyone who misunderstood that.
jlg@lanl.gov (Jim Giles) (04/06/89)
From article <1930@dataio.Data-IO.COM>, by bright@Data-IO.COM (Walter Bright): > Don't misunderstand me, icons have their place. The arrows on the ends > of scroll bars are an ideal example of correct use of icons. I don't know > anyone who misunderstood that. Actually, even these can be badly implemented. The expectation of a naive user is that: 1) the arrows on the end of the scroll bars go to the furthest extent in the pointed direction; or 2) the arrows on the end of the scroll bars move the file by an amount equal to the display size (ie. got to next/previous page). Most implementations I've seen follow neither of interpretations. The change in the displayed portion of the file is neither consistent nor easily predictable. Oh well, at least the file moves in the expected direction. My major objection with icons is that often I know very well what I want to do, but I can't do it without walking down some menu. This requires that I use the mouse, move to the right place to bring up the desired menu, move to the selected item, etc.. But, since I already KNOW what I want to do, what I really need is to type in a short command! The icon interface simply slows down experienced users.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (04/06/89)
In article <11555@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >Oh well, at least the file moves in the expected direction. (You mean the IMAGE moves...) I guess it depends on what you expect. I've used a variety of window systems and some of them have their scroll arrows doing the opposite of others. SunView had 2-way arrows at both ends of the scroll bar, and which way you scrolled depended on which mouse button you clicked. I personally prefer the "mux" scheme (also used in "sam" and "myx"), which doesn't use arrows at all, but that requires a 3-button mouse and the Macintosh is therefore hopelessly SOL.
jcbst3@cisunx.UUCP (James C. Benz) (04/06/89)
In article <11555@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >My major objection with icons is that often I know very well what I want >to do, but I can't do it without walking down some menu. This requires >that I use the mouse, move to the right place to bring up the desired >menu, move to the selected item, etc.. But, since I already KNOW what >I want to do, what I really need is to type in a short command! The >icon interface simply slows down experienced users. I'd like to put my two kopeks worth in here too. I found mouse and icon based applications infuriating for this very reason. A word to all you who write these things. I am a *fast* typist. I absolutely hate having to remove my fingers from the home keys to manipulate a mouse. I have a 7300 UNIXPC at home, and I always use the Unix shell rather than the nifty window interface that the designers at ATT thought was so necessary to compete with Macs. I will *never* own a Mac, and will never recommend one to anyone else, until they give up this icon obsession. I do most everything in vi, have used Emacs, and VMS editor, and find all these most productive, but every time I am forced to use a Mac, I turn the air blue around me. Please, if you are going to write applications based on the mouse, give me the *option* of using the keyboard. I don't care if it means a couple of extra key presses - at 90 words per minute, this is hardly a factor, but moving from the keyboard to a mouse and back slows me down to an effective 50 or 60 WPM, and even worse if I have to go through umpteen levels of pull down menus just to look at another file, it just makes me mad. There are plenty of us out here who have good typing skills and the smarts to understand English and even Unix, and by catering to the least common denominator, you only cut yourselves out of a large chunk of market share. (Up with cat, down with mouse!) Flame off. -- Jim Benz jcbst3@unix.cis.pittsburgh.edu If a modem University of Pittsburgh answers, UCIR (412) 648-5930 hang up!
robert@arizona.edu (Robert J. Drabek) (04/06/89)
In article <1930@dataio.Data-IO.COM>, bright@Data-IO.COM (Walter Bright) writes: > > What's wrong with icons is not necessarily icons, but what I've called > "iconitis". This is the religious fervor by which an icon is invented > for every command, because icons are 'better'. > > I've also seen a lot of effort expended to come up with an icon for 'Help'. > Those people got mad when I suggested the string 'Help' would do nicely. "Help" is just fine as long as you read English. I agree with Walter for the most part, but there are a few people who would like to use icons in a limited context. > The end result of iconitis is Chinese. Chinese has an icon for every word > and concept, and the result is, well, have you ever tried to learn it? I can't let this go by. It is now obvious that strings in English could be misunderstood as well. Note the author of the above is known by the the string "Walter Bright"; with such a label we could be mislead as to his intelligence. :-) Come on. Yes, I have tried to learn it (Chinese). So have over a billion other people for a couple of thousand years. And they had no problem. Their reaction, by the way, to learning string-oriented languages is pretty negative. The reading speed of native Chinese and native English literates is very close. From my observation, the Chinese system may even have a (very) slight advantage. And, one of the advantages put forward for iconic interfaces, that you don't need to know the language of the programmer, is clearly evident in the Chinese system. You see, there are several Chinese languages (Mandarin, Cantonese, Shanghainese, Fujian, ...) which are NOT mutually understandable at the spoken interface. But they all share the same graphic interface. So the Cantonese customer can not even ask about the Mandarin waiter's child, but they can pull down the iconic menu and order exactly the dishes they want. Want to go to Czechoslovakia and try that? > English is an excellent vehicle for describing abstract things, or things > which cannot be easilly represented as a 16*16 bitmap. Things such as > 'Help', 'Print', 'Save', 'Exit', 'Delete', etc. What's wrong with these, > and I defy anyone to come up with an icon for these that would be correctly > identified by more than 50% of the computer users you present it to. I really agree that I am very comfortable with this, but probably because I deal with these critters all the time. But let's not be so ethno (techno?) centric. And I still like some icons; they're SO cute. -- Robert J. Drabek Department of Computer Science The University of Arizona Tucson, AZ 85721
charlie@mica.stat.washington.edu (Charlie Geyer) (04/07/89)
In article <11555@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > My major objection with icons is that often I know very well what I want > to do, but I can't do it without walking down some menu. This requires > that I use the mouse, move to the right place to bring up the desired > menu, move to the selected item, etc.. But, since I already KNOW what > I want to do, what I really need is to type in a short command! The > icon interface simply slows down experienced users. Much worse than that. The main defect of any menu-driven application whether it uses mice and icons or not is that it is not programmable and will do nothing not thought of by the original programmer, who probably had very little idea what you want done. Emacs, vi, sed, awk, and the like are infinitely more valuable than any dumb editor no matter how "user-friendly." They can often be easily used to do things that in other environments would require a new applications program be written, which would take months instead of minutes. And will be done right instead of wrong. Dumb applications are suitable only for novices.
sarathy@gpu.utcs.utoronto.ca (Rajiv Sarathy) (04/07/89)
In article <1360@uw-entropy.ms.washington.edu> charlie@mica.stat.washington.edu (Charlie Geyer) writes: > >In article <11555@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > >> My major objection with icons is that often I know very well what I want >> to do, but I can't do it without walking down some menu. This requires >> ... >> icon interface simply slows down experienced users. > >Emacs, vi, sed, awk, and the like are infinitely more valuable than any >dumb editor no matter how "user-friendly." They can often be easily > ... >Dumb applications are suitable only for novices. Actually, dumb applications are the ones suitable for us smart programmers. Something like 'ed' is incredibly powerful in the hands of an experienced user. A novice would be lost. However, something as simple as MacWrite might not be as powerful as ed, but is a hundred times smarter. (Little things like when you remove a word, it also removes a space so that you don't have two spaces between words. In ed, you'd expressly have to remove the space as well (ie s/word //) ^ Icon interfaces do slow experienced users down, no doubt about it. That what makes NeXT so good. You can use either icons or just plain vanilla text, or both! -- _____________________________________________________________________________ | Disclaimer: I'm just an undergrad. All views and opinions are therefore _ | | my own. /\ /\ /-----------------------------------oO(_)| | / \ / \ / NetNorth: sarathy@utorgpu | | Rajiv Partha Sarathy / \/ \/ sarathy@gpu.utcs.utoronto.ca | | --------------------/ {uunet!attcan mnetor att pyramid}!utgpu!sarathy | |_____________________________________________________________________________|
jerry@starfish.Convergent.COM (Gerald Hawkins) (04/07/89)
From article <1930@dataio.Data-IO.COM>, by bright@Data-IO.COM (Walter Bright): > In article <28684@ucbvax.BERKELEY.EDU> jas@ernie.Berkeley.EDU (Jim Shankland) writes: >>That's tantalizing. Would you be willing to elaborate a little on what >>you think makes a good graphical interface, what's a good example and >>why, and what's wrong with the IBM PC keyboard and Macintosh icons? > > What's wrong with icons is not necessarily icons, but what I've called > "iconitis". This is the religious fervor by which an icon is invented > for every command, because icons are 'better'. ... > [suggests using English words instead of icons] ... - - I, too, hate overuse of icons. I believe they make switching between computer systems _MUCH_ more difficult than it should be. They cause mistakes for the new user. For example, here at Convergent, a lightning bolt stands for "erase". In PaintShow a picture of an eraser does the task. In ten other programs you will find ten (maybe only nine) other icons. The obvious upside of icons is that they make the computer just as usable no matter what country the machine is used in ... except that they usually blow the language independence by having menus or questions pop up when you use certain icons. It also makes things nice for functional illiterates. So--icons are great for driving in Europe (you don't need to learn 11 languages in 7 weeks), or for cash registers at McDonald's ... but leave them off anything else unless you have a darn good reason for creating them. All the good ones are taken anyhow. " I don't want to imply I'm underpaid, but ... Last time I took my paycheck to the bank to be cashed, the teller asked me, 'How would you like that, sir, Heads, or Tails?' " Jerry ( jerry@starfish.Convergent.COM ) -----
rob@PacBell.COM (Rob Bernardo) (04/07/89)
Walter Bright writes something I agree with: +What's wrong with icons is not necessarily icons, but what I've called +"iconitis". This is the religious fervor by which an icon is invented +for every command, because icons are 'better'. + +I've also seen a lot of effort expended to come up with an icon for 'Help'. +Those people got mad when I suggested the string 'Help' would do nicely. But then he continues with an unfortunate analogy: +The end result of iconitis is Chinese. Chinese has an icon for every word + and concept, and the result is, well, have you ever tried to learn it? And Robert J. Drabek comments: +I can't let this go by. It is now obvious that strings in English could +be misunderstood as well. Note the author of the above is known by the +the string "Walter Bright"; with such a label we could be mislead as to +his intelligence. :-) Come on. Yes, I have tried to learn it (Chinese). +So have over a billion other people for a couple of thousand years. And +they had no problem. Their reaction, by the way, to learning +string-oriented languages is pretty negative. + +The reading speed of native Chinese and native English literates is very +close. From my observation, the Chinese system may even have a (very) +slight advantage. The Chinese writing system *used to be* iconic, but no longer is. An iconic sign is one which denotes its referent because it *resembles* its referent. Chinese characters and English words are not iconic, but symbolic signs, i.e. they denote their referents due to a *conventional* association between the sign and the referent (onomatopeia aside). (Follow ups to sci.lang or sci.philosophy.) In any case, with this distinction in mind, we might rephrase what Walter Bright had to say as: 1. Use only an icon that clearly depicts the intended referent, or else it isn't a good icon. 2. Use an icon if it communicates more effectively than a symbol purely sign (such as a word or letter). In other words, using an icon for the sake of using an icon is not using an icon for the sake of better communication. -- Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library Email: ...![backbone]!pacbell!pbhyf!rob OR rob@pbhyf.PacBell.COM Office: (415) 823-2417 Room 4E850O San Ramon Valley Administrative Center Residence: (415) 827-4301 R Bar JB, Concord, California
daveb@gonzo.UUCP (Dave Brower) (04/07/89)
In <1930@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes: >Don't misunderstand me, icons have their place. The arrows on the ends >of scroll bars are an ideal example of correct use of icons. I don't know >anyone who misunderstood that. Unless you are talking about SunView... :-(. -dB -- "I came here for an argument." "Oh. This is getting hit on the head" {sun,mtxinu,amdahl,hoptoad}!rtech!gonzo!daveb daveb@gonzo.uucp
sho@pur-phy (Sho Kuwamoto) (04/07/89)
In article <17376@cisunx.UUCP> jcbst3@unix.cis.pittsburgh.edu (James C. Benz) writes: >I'd like to put my two kopeks worth in here too. I found mouse and icon >based applications infuriating for this very reason. A word to all you who >write these things. I am a *fast* typist. I absolutely hate having to >remove my fingers from the home keys to manipulate a mouse. [...] >Please, if you are going to write applications based on the >mouse, give me the *option* of using the keyboard. I agree to a certain extent. I think that for applications which cater toward experienced users, a CLI interface is very handy. However, I find that once you get used to using a mouse, it's not all that bad. The first time I used a mac, I was intrigued, but I found the lack of a CLI interface annoying. Nowadays, I have the option of using a CLI interface for at least the shell (the MPW shell) but I never end up using it unless I absolutely *can't* do something effectively from the Finder. (like using wildcards, for example). In addition, most applications provide ample keyboard equivalents for the menu items, and you can use a macro editor to provide you with the ones that don't exist. I agree that every action should be accesible through both the keyboard and the mouse, but I'm not commited to one over the other. When I'm using an editor on the mac, I sometimes end up hitting emacs cursor control keys to move around (even the arrow keys are kind of far away), but when I'm using emacs on a terminal emulator, I sometimes reach for the mouse when I want to move a large distance.... *sigh*. With regard to programs giving users the option of using the keyboard, I agree. But this keyboard interface can be enhanced by the use of windows, mouse, etc., not hindered. I've been writing a generic CLI package to use in my future programs. It lets you scroll back, pick out, and edit previous commands with the mouse instead of using history. It lets you use cut and paste, find, etc. Eventually, I hope to implement the csh history substitutions for when that's convenient. What I mean to say is that the mouse should not be scrapped altogether, but should be used intelligently.... Sorry if this posting tends to ramble. I have a lot of grading to do and not too much time to edit. -Sho
guy@auspex.auspex.com (Guy Harris) (04/07/89)
>English is an excellent vehicle for describing abstract things, or things >which cannot be easilly represented as a 16*16 bitmap. Things such as >'Help', 'Print', 'Save', 'Exit', 'Delete', etc. What's wrong with these, And, to forestall the obvious responses, programs can be set up to, for example, get the text in question from, say, a file, for the benefit of those for whom English may *not* be an excellent vehicle for describing abstract things (which is probably a fairly large portion of the computer-using population).
peter@ficc.uu.net (Peter da Silva) (04/07/89)
In article <1989Apr6.183222.17943@gpu.utcs.utoronto.ca>, sarathy@gpu.utcs.utoronto.ca (Rajiv Sarathy) writes: > Icon interfaces do slow experienced users down, no doubt about it. That what > makes NeXT so good. You can use either icons or just plain vanilla text, > or both! As you have been able to on the Amiga for years. At 1/10th the price. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
peter@ficc.uu.net (Peter da Silva) (04/07/89)
Followups to comp.windows.misc, perhaps? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
austing@Apple.COM (Glenn L. Austin) (04/08/89)
> There are plenty of us out here who have good typing skills and the > smarts to understand English and even Unix, and by catering to the least > common denominator, you only cut yourselves out of a large chunk of market > share. Plenty of us? I know more people who *DON'T* know Unix than those that do. Also, I know more than a few people who are totally intimidated by an English interface (on the PC, does "FORMAT" get my document ready for printing?). Oh, by the way, the last parenthesizes statement is common among secretaries who know that they have to do something to print their document, but know Plenty of us? I know more people who *DON'T* know Unix than those that do. Also, I know more than a few people who are totally intimidated by an English interface (on the PC, does "FORMAT" get my document ready for printing?). Oh, by the way, the last parenthesizes statement is common among secretaries who know that they have to do something to print their document, but know very little about the PC they are using! I spent 3 years supporting the IBM PC and Apple Macintosh computers. During that time, 99% of the questions asked were of the "What do I do now?" category on the IBM PC. I had about 30 questions (yes, only about 30) on the Macintosh during that time, and of those, 25 were "What software should I use to do..." questions, 4 were "I didn't know disks could wear out", and 1 was from a person programming the Mac who accidentally erased his disk. Oh, also, during that time I recovered 10 formatted PC hard disks, several hundred deleted files, and several trashed floppies (thank God for Norton Utilities!). ----------------------------------------------------------------------------- | Glenn L. Austin | The nice thing about standards is that | | Apple Computer, Inc. | there are so many of them to choose from. | | Internet: austing@apple.com | -Andrew S. Tanenbaum | ----------------------------------------------------------------------------- | All opinions stated above are mine -- who else would want them? | -----------------------------------------------------------------------------
barmar@think.COM (Barry Margolin) (04/08/89)
In article <1360@uw-entropy.ms.washington.edu> charlie@mica.stat.washington.edu (Charlie Geyer) writes: > The main defect of any menu-driven application >whether it uses mice and icons or not is that it is not programmable >and will do nothing not thought of by the original programmer, who >probably had very little idea what you want done. You are comparing two unrelated qualities here. There are many keyboard-driven applications that are not user-extensible. And there is nothing inherent in menus that prevents user-extensions. In fact, there is nothing that prevents an application from providing both styles of user interface simultaneously, and allowing both to be extended. The UIMS on Symbolics Lisp Machines does precisely this. When you are defining a command within an application you can specify a full command name, a menu name, and a single-character keyboard accelerator. I've also used a Macintosh version of MicroEmacs that allowed most commands to be invoked either using the normal Emacs-style keyboard commands or the Macintosh menu bar. I don't think it had any extension capability, but if it did I'd expect it to allow extending the menu bar. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
dmg@ssc-vax.UUCP (David Geary) (04/08/89)
In article <11555@lanl.gov, Jim Giles writes: || From article <1930@dataio.Data-IO.COM>, by bright@Data-IO.COM (Walter Bright): || Don't misunderstand me, icons have their place. The arrows on the ends || of scroll bars are an ideal example of correct use of icons. I don't know || anyone who misunderstood that. | Actually, even these can be badly implemented. The expectation of a naive | user is that: 1) the arrows on the end of the scroll bars go to the furthest | extent in the pointed direction; or 2) the arrows on the end of the scroll | bars move the file by an amount equal to the display size (ie. got to | next/previous page). Most implementations I've seen follow neither of | interpretations. The change in the displayed portion of the file is | neither consistent nor easily predictable. Oh well, at least the file | moves in the expected direction. | My major objection with icons is that often I know very well what I want | to do, but I can't do it without walking down some menu. This requires | that I use the mouse, move to the right place to bring up the desired | menu, move to the selected item, etc.. But, since I already KNOW what | I want to do, what I really need is to type in a short command! The | icon interface simply slows down experienced users. Ah, icons vs. keyboard, mice vs. men ;-). I think everyone will agree that a Mac-like interface is more suited for novices, and a unix-shell-like interface is more suited for experienced users. (of course *someone* will disagree ;-) I used to teach the usage of a 2D drafting package that runs on Sun workstations entitled cimcad, from a company named Cimlinc, for a couple of years. Cimcad had a slick interface which consisted of icons, short commands (keyboard commands), pop-up menus (infinitely superior to pull-down menus IMHO), and strokes (where you press a mouse button and *draw* a symbol on the screen to trigger a command). The most important thing about it was that it was entirely configurable by the user. Novices could start with icons and pop-ups, and later on, when they had become proficient, and as Jim states above "knew very well what they wanted to do", they could redefine *any* command that was found in pop-ups and icons as keyboard equivalents. Not only that, but the pop-ups, icons, strokes and keyboard commands were *all* redefineable - the user could shape the interface into anything they wanted to. I have never used an application since that went to such great lengths to provide users with an interface that everyone could be productive with. And now, on to VI wars... After working here at Boeing for about 1 year (and using a mouse based editor exclusively), we had a Sun technical person come in to fix something that was wrong with my Sun. He had to edit a couple of files, and used vi. I had never seen anything like it in my life. This guy edited about 3 or 4 files, making major changes in each so fast that my eyes could barely keep up with the cursor. I was astounded. Now I use VI exclusively. People see me using VI nowadays, and say "WOW! What kind of editor is that - it's so fast." "Vi", I reply. "Oh, yuck", is usually their reply. I just kind of smile. BTW, when I was learning VI, I cursed it time and time again, and almost came to the point of erasing from my disk a few times, but then I'd think back to that Sun guy, and I'd convince myself that it'd be worth it in the long run. It was. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ David Geary, Boeing Aerospace, Seattle ~ ~ "I wish I lived where it *only* rains 364 days a year" ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
john@chinet.chi.il.us (John Mundt) (04/08/89)
In article <17376@cisunx.UUCP> jcbst3@unix.cis.pittsburgh.edu (James C. Benz) writes: >In article <11555@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >>My major objection with icons is that often I know very well what I want >>to do, but I can't do it without walking down some menu... The >>icon interface simply slows down experienced users. > >I'd like to put my two kopeks worth in here too. I found mouse and icon >based applications infuriating for this very reason. A word to all you who >write these things. I am a *fast* typist. >.... There are plenty of us out here who have good typing skills and the >smarts to understand English and even Unix, and by catering to the least >common denominator, you only cut yourselves out of a large chunk of market >share. You should know by now to never let on that you know how to type. :-) MOst points in the diatribe against icons are probably valid, and you often see experienced Mac users going away from icon representations of different directories with the text version of the same. But! the point is that "icons" are the coming thing, and with all the ponderance of a ship sliding into its berth, anyone who gets in the way of this "fact" are going to get crushed. IBM and AT&T are working windows into PS/2 and UNIX V.4. Whether we like it or not, icons are here to stay and will eventually take over because the market does indeed cater to the lowest common denominator. Hopefully, new programs will give the option of using icon or keyboard. But I doubt it. Icons, graphics, and desktop publishing are just too much fun to play with and that sells computers. I am begining to worry that people are now more concerned with the way the program looks, and the way the output looks to worry much about the usefulness of the program or the value of the output. -- --------------------- John Mundt Teachers' Aide, Inc. P.O. Box 1666 Highland Park, IL john@chinet.chi.il.us (312) 998-5007 (Day voice) || -432-8860 (Answer Mach) && -432-5386 Modem
bright@Data-IO.COM (Walter Bright) (04/08/89)
In article <10115@megaron.arizona.edu> robert@arizona.edu (Robert J. Drabek) writes: >In article <1930@dataio.Data-IO.COM>, bright@Data-IO.COM (Walter Bright) writes: << I've also seen a lot of effort expended to come up with an icon for 'Help'. << Those people got mad when I suggested the string 'Help' would do nicely. <"Help" is just fine as long as you read English. It's also fine if you don't read English, because it's easily found in a dictionary. For icons, there is no dictionary, and if there was, what is the lexicographic order? (P.S. How do the Chinese find their icons in a dictionary?) <The reading speed of native Chinese and native English literates is very <close. From my observation, the Chinese system may even have a (very) <slight advantage. I propose then that the Mac icons be replace with Chinese icons. The advantages are: 1. A billion people already know it. 2. It's standardized. 3. It can't be copyrighted. Frankly, what's the difference. I need an idiot card with the icons and what they mean when I use a Mac, it makes no difference if they were Chinese icons (and at least I'd learn something I could use elsewhere). <Want to go to Czechoslovakia and try that [getting by in a resturant]? I've been to Europe and have gotten by ok with my trusty dictionary. This technique failed on my trip to Japan 'cuz I couldn't figure out how to use the Japanese dictionary!
charlie@mica.stat.washington.edu (Charlie Geyer) (04/08/89)
In article <1360@uw-entropy.ms.washington.edu> I wrote: The main defect of any menu-driven application, whether it uses mice and icons or not, is that it is not programmable and will do nothing not thought of by the original programmer, who probably had very little idea what you want done. In article <38800@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) replies: > You are comparing two unrelated qualities here. There are many > keyboard-driven applications that are not user-extensible. And there > is nothing inherent in menus that prevents user-extensions. except that not all useful "extensions" can be usefully be done by adding options to menus. That's why I said "programmable." It's a truism that every applications program defines a new programming language or uses an old one. Most are incoherent, but they are languages none the less. Icons are baby talk. O. K. for some purposes, but not for most things.
scs@adam.pika.mit.edu (Steve Summit) (04/08/89)
In article <10115@megaron.arizona.edu> robert@arizona.edu (Robert J. Drabek) writes: >In article <1930@dataio.Data-IO.COM>, bright@Data-IO.COM (Walter Bright) writes: >> I've also seen a lot of effort expended to come up with an icon for 'Help'. >> Those people got mad when I suggested the string 'Help' would do nicely. > >"Help" is just fine as long as you read English... I knew someone was going to bring up the language issue. For a lot of these forced, icons-for-icon's-sake icons, the little crypto-graphics are less comprehensible (and harder to look up in an index) than simple words, whether they are in your language or not. On the back of a Microvax is a switch that controls whether the console BREAK key will escape to the processor front-end (the >>> hardware prompt). The switch's two positions are, of course, labeled with two little icons which are utterly incomprehensible to any culture on the planet. (Hey! equal opportunity...) You tell me: does a triangle in a circle mean that the break key is or isn't enabled? I always have to re-determine the switch's functionality, by trial-and-error, each time I try to use it. As I recall, there's another, three-position switch on the back of a Microvax, labeled with even stranger little symbols, which controls whether the initial boot messages are printed in English or in a country-dependent way... Steve Summit scs@adam.pika.mit.edu
peter@ficc.uu.net (Peter da Silva) (04/08/89)
Follow up comp.windows.misc. PLEASE. Windows do not imply Icons (Smalltalk doesn't have icons. Imagine that). Icons do not imply windows (Plato doesn't have windows or a mouse. It has Icons. Imagine that). Just remember this. Windows are a good idea. Icons are a good idea. Each in their own domain. I think windows are more generally useful. I have abandoned the icon interface to my Amiga and written a text/window interface that provides much the same functionality. BUT, windows != icons. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
friedl@vsi.COM (Stephen J. Friedl) (04/09/89)
In article <28558@apple.Apple.COM>, austing@Apple.COM (Glenn L. Austin) writes: > > Also, I know more than a few people who are totally intimidated by an English > interface (on the PC, does "FORMAT" get my document ready for printing?). Think of it as removing all spelling and grammar mistakes :-) Steve -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / friedl@vsi.com / {attmail, uunet, etc}!vsi!friedl "I do everything in software, even DMA" - Gary W. Keefe (garyk@telxon)
fischer@iesd.dk (Lars P. Fischer) (04/09/89)
In article <1936@dataio.Data-IO.COM> bright@Data-IO.COM (Walter Bright) writes: >I've been to Europe and have gotten by ok with my trusty dictionary. This >technique failed on my trip to Japan 'cuz I couldn't figure out how to use >the Japanese dictionary! Shows that any system other than the one you're used to is a pain. Shows nothing else. /Lars -- Lars Fischer, fischer@iesd.dk, {...}!mcvax!iesd!fischer Any sufficiently advanced technology is indistinguishable from magic. -- Arthur C. Clarke
guy@auspex.auspex.com (Guy Harris) (04/09/89)
>The obvious upside of icons is that they make the computer just as usable >no matter what country the machine is used in ... Not necessarily. Consider, for example, an icon for a mail-reading program, in the form of a US-style mailbox. If used in some country where the US-style mailboxes, with the little flag on the side, aren't used, it won't necessarily mean anything. I think the Sun386i uses a different icon for "mailtool", for precisely this reason; unfortunately, at least at one point they used a postage stamp. This may well have been equally understandable in all countries - but then, 0 == 0; it looked more like a picture to me than a postage stamp, and furthermore a postage stamp doesn't directly remind me of an inbox or an outbox, so the association with "mailtool" was rather indirect anyway.... The bottom line is that there is *no* guarantee that, merely by using an icon, people of all nations - or even people of *your* nation - will automatically know to what the icon refers.
is813cs@pyr.gatech.EDU (Cris Simpson) (04/09/89)
In article <28558@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >[...] >I spent 3 years supporting the IBM PC and Apple Macintosh computers. During >that time, 99% of the questions asked were of the "What do I do now?" category >on the IBM PC. I had about 30 questions (yes, only about 30) on the Macintosh >during that time, and of those, 25 were "What software should I use to do..." >questions, 4 were "I didn't know disks could wear out", and 1 was from a >person programming the Mac who accidentally erased his disk. [...] Anytime I have had to use a Mac, I always asked, "Why is it so slow?." cris || Gee, do you think it'd help if I plugged in both ends of this cable? || Cris Simpson Computer Engineer VA Rehab R&D Center GATech Atlanta,GA is813cs@pyr.gatech.edu ...!{Almost Anywhere}!gatech!gitpyr!is813cs
paulc@microsoft.UUCP (Paul Canniff 2/1011) (04/09/89)
Preface ... I agree that icon abuse exists and that text is very powerful form of information. I use "vi", I used Wordstar, I have the scars of every character-based text interface, so don't get on my case. I have some questions about this specific paragraph, though. In article <11555@lanl.gov> jlg@lanl.gov (Jim Giles) writes: < text deleted> >My major objection with icons is that often I know very well what I want >to do, but I can't do it without walking down some menu. This requires >that I use the mouse, move to the right place to bring up the desired >menu, move to the selected item, etc.. But, since I already KNOW what >I want to do, what I really need is to type in a short command! The >icon interface simply slows down experienced users. I'm confused. One of the major advantages of iconic interfaces is that they reduce the number of menus. Look at the palette in any paint program. It replaces a menu of tools. What sort of app are you using that requires menu operations to access icons? Talk about the worst of both worlds! I'd appreciate hearing about this example in some detail. Also, icons which are "objects" (buzzword alert) do more than a menu can do. You can drag stuff to them (trash can, anyone?) and have them "do something" to the stuff. So in addition to having an icon represent an object, it can be an "active" object. Flight of fantasy: I'm just waiting for someone to make a little "copy machine" icon to drag files into. Hope it works better than real copiers. I can see it now .... Diagnostic J8. Please consult key operator or your service manual.
mlinar@caesar.usc.edu (Mitch Mlinar) (04/09/89)
In article <28558@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >> There are plenty of us out here who have good typing skills and the >> smarts to understand English and even Unix, and by catering to the least >> common denominator, you only cut yourselves out of a large chunk of market >> share. > >Plenty of us? I know more people who *DON'T* know Unix than those that do. >Also, I know more than a few people who are totally intimidated by an English >interface (on the PC, does "FORMAT" get my document ready for printing?). >Oh, by the way, the last parenthesizes statement is common among secretaries >who know that they have to do something to print their document, but know >very little about the PC they are using! Yes, Glenn you are right - UP to a point. I have kinda grown up with the computer business over the last 18 years (starting at age 13). The proliferation of computers from behind-closed-door-behemoth to every-day- run-of-the-mill desktop computers during this time has had a BIG impact on the American culture. 15 years ago, few people could tell you anything about a computer. Ask them what a PC meant and what is a floppy disk, and you get blank stares. Many were awestruck by the computer literate. 10 years ago, more people knew what a PC was and 1/2 could recognize a floppy disk. The "error rate" climbed dramatically as the NON-computer users started to get exposed to it and saw its power, but made mistakes. 5 years ago, nearly EVERYONE knows what a computer is and most know how to work them in some form. At this time, the NON-computer users were virtually forced to learn PC/MAC/whatever: office automation really hit. MACs worked best on the computer novice crowd at that time, PCs on more experienced ones. (The distinctions between these have blurred somewhat over the years.) Today, you HAVE to have basic computer skills to get a job in any profession. Even most of the non-technical jobs entail computer use. Period. This "error rate" decreases as people are making their systems more application specific (just like the ICs), but also start out with a higher baseline of knowledge. Nearly all college and high school grads know how to work a computer. My six yr old and three yr old have no problem running a CP/M machine. Nor running a PC or MAC. The fact is that menus/mice selection of same are great for learning a system. Once a system is known, a fast typist is clearly at a disadvantage. The MAC was originally sold for those who needed the power but were computer illiterate. For document processing/integrated graphics, it is STILL hard to beat. But outside of that, a PC does just fine (and certainly better in the cost/performance category). In the future, one need not dwell on such interfaces - and as someone said - any computer should provide BOTH. Take a look around at anyone under the age of 21; you will find FEW who are intimidated by a PC versus a MAC. Given that most were trained on Apple ][s and are now being trained on PCs in grade school/high school, this is not surprising. What is surprising are these continuous arguments over the years to "protect the masses from all this power they just cannot understand". Guano! Give them a shelter, but DON'T lock them in. The average user is no longer that stupid. -Mitch P.S. For proof of this maturation, just take a look at Steven Jobs. The MAC was his baby. I remember articles telling about how he thought CTRL keys were a bad idea (what do they mean?) and even a two-button mouse is too complicated, etc. The Next machine is his current prodigy for comparison and being "retargeted" to business/industry after overemphasis on academics (machine is overpriced for most schools). Both menus/icons and CLI interface are present. And, its OS is UN*X like.
peter@ficc.uu.net (Peter da Silva) (04/09/89)
[comparing user problems on Macs and PCs] My usual question with either of these is "why can't I shove my ^%^&%&^ compile into the background?". -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
peter@ficc.uu.net (Peter da Silva) (04/09/89)
In article <1264@microsoft.UUCP>, paulc@microsoft.UUCP (Paul Canniff 2/1011) writes: > Also, icons which are "objects" (buzzword alert) do more than a menu > can do. You can drag stuff to them (trash can, anyone?) and have them > "do something" to the stuff. So in addition to having an icon represent > an object, it can be an "active" object. And it did that on the original icon machine, the Xerox Star. But Apple didn't follow suit, so all the rest of the icon-using folks have left that significant functionality off. It's like watching gangrene spread, you know, watching all the foul-ups Apple implemented becoming a standard: button-starved mice, menu bars, desk accessories, militant iconism... -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
barmar@think.COM (Barry Margolin) (04/09/89)
In article <1364@uw-entropy.ms.washington.edu> charlie@mica.stat.washington.edu (Charlie Geyer) writes: >except that not all useful "extensions" can be usefully be done by >adding options to menus. That's why I said "programmable." Any extensions that involve adding new keystrokes to an emacs- or vi-style application, or adding commands to a CLI-based application, can be done by adding options to menus. If the extension doesn't involve the command interface (e.g. it changes the behavior of existing commands) then what difference does it make whether the application uses commands, menus, icons, or direct brain interface? Either it's programmable or it isn't. Just because most Macintosh applications aren't programmable doesn't mean that this is a requirement of menu-based applications. Most Unix applications aren't extendable, either (emacs is the exception, not the rule). Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
henry@utzoo.uucp (Henry Spencer) (04/10/89)
In article <1264@microsoft.UUCP> paulc@microsoft.UUCP (Paul Canniff 2/1011) writes: >Flight of fantasy: I'm just waiting for someone to make a little >"copy machine" icon to drag files into. Hope it works better >than real copiers... Shades of VM/370. "What happens when you connect a virtual line printer to a virtual card reader? You get a virtual jam..." -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
crewman@bucsb.UUCP (JJS) (04/10/89)
In article <11555@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <1930@dataio.Data-IO.COM>, by bright@Data-IO.COM (Walter Bright): >> >> The arrows on the ends >> of scroll bars are an ideal example of correct use of icons. I don't know >> anyone who misunderstood that. > >[scroll bar icon problems deleted] > >Oh well, at least the file >moves in the expected direction. > Even THIS isn't always true! I was surprised to find out that in the SunView scrollbar area, a down-arrow means "scroll the file down", and that is exactly the opposite of "move the window down in the file", which is what I expected from working with the Mac and MS-Windows. -- JJS
austing@Apple.COM (Glenn L. Austin) (04/10/89)
In article <7898@pyr.gatech.EDU> is813cs@pyr.UUCP (Cris Simpson) writes: >Anytime I have had to use a Mac, I always asked, >"Why is it so slow?." Compare the time it takes to type "DIR<return>" with double-click. If you notice, it takes a lot less time to double-click than it does to type the command. I took a stopwatch to the two machines and found that it took about half the time to execute a command on the Mac than it did on the PC. Oh, by the way, I type at 98 WPM, so I'm no slouch at the keyboard, but even I appreciate (and use) the mouse and cursor keys. ----------------------------------------------------------------------------- | Glenn L. Austin | The nice thing about standards is that | | Apple Computer, Inc. | there are so many of them to choose from. | | Internet: austing@apple.com | -Andrew S. Tanenbaum | ----------------------------------------------------------------------------- | All opinions stated above are mine -- who else would want them? | -----------------------------------------------------------------------------
austing@Apple.COM (Glenn L. Austin) (04/10/89)
In article <16408@oberon.USC.EDU> mlinar@caesar.usc.edu (Mitch Mlinar) writes: >5 years ago, nearly EVERYONE knows what a computer is and most know how to >work them in some form. 15-20% is nearly everyone?!? Boy, I'll bet the census office would be glad to hear that! The real truth is that more people don't know about computers than those who do, and of those, only about 15% of the "computer literate" really understand what they are doing. Most of the rest are just following instructions by "repeating the instructions like a recipe." I hardly think that 15% of 20% is "everyone." >............. The average user is no longer that stupid. The ads that Apple ran a couple of years ago are still valid today. I have a library of programming reference materials for VM, MVS, UN*X, MS/PC-DOS, IBM PC, and Macintosh. Considering that 99% of my reference materials are for machines other than the Mac, including about 8 linear feet of reference materials for the PC and DOS, most of which have info that is not found in any of the others. I also have 1 linear foot of Macintosh programming material that covers *EVERYTHING* to programming the Mac. True, this is not what the user sees, but the ratio of required PC documentation to required Mac documentation is equivalent. Also, considering that Mac programs look like other Mac programs, who needs documentation, except for specific concepts/instructions? >P.S. For proof of this maturation, just take a look at Steven Jobs. The MAC >was his baby. I remember articles telling about how he thought CTRL keys >were a bad idea (what do they mean?) and even a two-button mouse is too >complicated, etc. The Next machine is his current prodigy for comparison and >being "retargeted" to business/industry after overemphasis on academics >(machine is overpriced for most schools). Both menus/icons and CLI >interface are present. And, its OS is UN*X like. The reason Jobs' machine was geared towards education? Contracts. Check out "Odyssey" by John Sculley. That outlines the agreement that Jobs would wait for 5 years before introducing a machine into the business market. Guess what? The five years are over. ----------------------------------------------------------------------------- | Glenn L. Austin | The nice thing about standards is that | | Apple Computer, Inc. | there are so many of them to choose from. | | Internet: austing@apple.com | -Andrew S. Tanenbaum | ----------------------------------------------------------------------------- | All opinions stated above are mine -- who else would want them? | -----------------------------------------------------------------------------
austing@Apple.COM (Glenn L. Austin) (04/10/89)
In article <3769@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >[comparing user problems on Macs and PCs] > >My usual question with either of these is "why can't I shove my ^%^&%&^ >compile into the background?". If you are using MPW, you certainly can! Also, a lot of compiler writers for the Macs are starting to understand background tasking... Also, with a single-processor machine (like most UN*X machines), you have to time-slice the processor, which means either (1) the compiler runs slower, or (2) the current program runs slower, or (3) both 1 and 2. In most cases, the answer is 3. ----------------------------------------------------------------------------- | Glenn L. Austin | The nice thing about standards is that | | Apple Computer, Inc. | there are so many of them to choose from. | | Internet: austing@apple.com | -Andrew S. Tanenbaum | ----------------------------------------------------------------------------- | All opinions stated above are mine -- who else would want them? | -----------------------------------------------------------------------------
peter@ficc.uu.net (Peter da Silva) (04/10/89)
In article <28683@apple.Apple.COM>, austing@Apple.COM (Glenn L. Austin) writes: > In article <3769@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >[comparing user problems on Macs and PCs] > >My usual question with either of these is "why can't I shove my ^%^&%&^ > >compile into the background?". > If you are using MPW, you certainly can! Also, a lot of compiler writers for > the Macs are starting to understand background tasking... Can I shove the compiler in the background and run Photon Paint? > Also, with a single-processor machine (like most UN*X machines), you have to > time-slice the processor, which means either (1) the compiler runs slower, or > (2) the current program runs slower, or (3) both 1 and 2. In most cases, the > answer is 3. In most cases the answer is (4). What's (4)? (4) The compiler runs a little slower and the current program runs a little slower, but since each is using and waiting on different resources (disk, CPU time, operator response, serial ports, etc) they can be doing useful work concurrently so the whole job gets finished sooner. Maybe not on the Mac, where the CPU does EVERYTHING, but under UNIX and AmigaOS (my current operating environenments) it sure does. Note the followup-to line. This is not appropriate for comp.lang.c. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
mrk@wuphys.UUCP (Mark R. Kaufmann) (04/10/89)
In article <28679@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >In article <7898@pyr.gatech.EDU> is813cs@pyr.UUCP (Cris Simpson) writes: >>Anytime I have had to use a Mac, I always asked, >>"Why is it so slow?." > >Compare the time it takes to type "DIR<return>" with double-click. If you >notice, it takes a lot less time to double-click than it does to type the >command.... >| Glenn L. Austin | The nice thing about standards is that | >| Apple Computer, Inc. | there are so many of them to choose from. | >| Internet: austing@apple.com | -Andrew S. Tanenbaum | > Compare the time it takes to pick up your right hand from the home position on the keyboard, which is its natural place :-) when using a computer, finding the mouse, moving it where you want, double-clicking, then moving your hand back to the keyboard. I'd bet typing four characters is faster by a factor of ten. ======================================= Mark R. Kaufmann UUCP: ...!uunet!wucs1!wugate!wuphys!mrk Internet: mrk@wuphys.wustl.edu =======================================
sjs@spectral.ctt.bellcore.com (Stan Switzer) (04/11/89)
In article <4971@pbhyf.PacBell.COM> rob@PacBell.COM (Rob Bernardo) writes: > +I've also seen a lot of effort expended to come up with an icon for 'Help'. > +Those people got mad when I suggested the string 'Help' would do nicely. > In any case, with this distinction in mind, we might rephrase what Walter > Bright had to say as: > > 1. Use only an icon that clearly depicts the intended referent, > or else it isn't a good icon. > > 2. Use an icon if it communicates more effectively than a symbol > purely sign (such as a word or letter). > > In other words, using an icon for the sake of using an icon is not > using an icon for the sake of better communication. [This is an interesting discussion, but I'm directing folowups to comp.windows.misc] The trouble with icons is that they depict things (i.e. files or "closed" windows) reasonably well and actions (commands) rather badly. Sometimes a gesture serves well as a verb, as the "drag a file over the trashcan" style indicates. In general, though, what sense can I make out of a "printer" icon? Will clicking it display the printer queue, pop up an image of a status panel, or ship some file (which file?) to the printer? None of this is *really* self-evident. Don't get me wrong. Graphical, mouse driven interfaces can be quite wonderful. As with any other software construct, it really comes down to the power, predictability, and believability of the illusion of the user interface. All programming is magic, after all: the creation of an illusory reality -- which is why the Model-View-Controller paradigm works so well. On a related note (and one which *does* belong in comp.lang.c), I always wondered why some people put ones and zeros on power switches and others use #defines for ON and OFF. Each practice is equally misguided. Stan Switzer sjs@ctt.bellcore.com
eriks@cadnetix.COM (Eriks A. Ziemelis) (04/11/89)
In article <17376@cisunx.UUCP> jcbst3@unix.cis.pittsburgh.edu (James C. Benz) writes: >In article <11555@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >>My major objection with icons is that often I know very well what I want >>to do, but I can't do it without walking down some menu... The >>icon interface simply slows down experienced users. And at times, icons slow down or prevent the novice user from becoming an experienced user. In a previous job, I did some support of a CAE/CAD system that uses pull-down menus, icons, pop-ups, etc. I found that many users got so used to working with these various non-keyboard interfaces that they never progressed past them: they did not know of the other commands available to them. They would rarely read any of the reference manuals; their sole source of information, in most cases, were the tutorial manuals they had used which usually focused on the non-keyboard methods. They could perform the simple tasks that were programmed into the icons and menus but would be lost when something "unexpected" would happen or had to do something more complex that could not be performed solely using icons etc. Eriks A. Ziemelis Internet: eriks@cadnetix.com UUCP: ...!{uunet,boulder}!cadnetix!eriks U.S. Snail: Daisy/Cadnetix Corp. 5775 Flatiron Pkwy Boulder, CO 80301 Baby Bell: (303) 444-8075 X336
is813cs@pyr.gatech.EDU (Cris Simpson) (04/11/89)
In article <28679@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >>Anytime I have had to use a Mac, I always asked, >>"Why is it so slow?." > >Compare the time it takes to type "DIR<return>" with double-click. If you >notice, it takes a lot less time to double-click than it does to type the >command. [..] >| Glenn L. Austin | The nice thing about standards is that | Fine. To keep it appropriate for this newsgroup, how would you double click "dir *.c<CR>" ? cris || Gee, do you think it'd help if I plugged in both ends of this cable? || Cris Simpson Computer Engineer VA Rehab R&D Center GATech Atlanta,GA is813cs@pyr.gatech.edu ...!{Almost Anywhere}!gatech!gitpyr!is813cs
jeff@visix.UUCP (Jeff Barr) (04/11/89)
In article <3769@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > > [comparing user problems on Macs and PCs] > > My usual question with either of these is "why can't I shove my ^%^&%&^ > compile into the background?". This is purely an operating system problem, its not related to the interface at all. > -- > Peter da Silva, Xenix Support, Ferranti International Controls Corporation. [long address deleted] Jeff /\ Jeff Barr \ / Visix Software, Inc. /\ 800-832-8668 \ / / \ uunet!visix!jeff \ / 1525 Wilson Blvd. / \ 703-841-5858 \ / / \ \/ Arlington, VA 22209 / \ \/ "A MIMD is a terrible thing to waste."
peter@ficc.uu.net (Peter da Silva) (04/11/89)
[ I was complaining about the lack of multitasking on the PC and MAC ] In article <191@visix.UUCP>, jeff@visix.UUCP (Jeff Barr) writes: > This is purely an operating system problem, its not related to the interface > at all. It's related to the interface, since most of what little O/S there is on the Mac (and now with Windows and its successors, the PC) is entirely oriented towards the user interface. You can't write a program on these machines unless it's tied tightly to the user interface. The whole concept of running in the background is alien. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
sho@pur-phy (Sho Kuwamoto) (04/11/89)
In article <7910@pyr.gatech.EDU> is813cs@pyr.gatech.edu (Cris Simpson) writes: <In article <28679@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: <<Compare the time it takes to type "DIR<return<" with double-click. If you <<notice, it takes a lot less time to double-click than it does to type the <<command. [..] < Fine. To keep it appropriate for this newsgroup, how would you <double click "dir *.c<CR>" ? This isn't exactly what you want, but on the mac, you can select view by type, which will clump all the files created by your c compiler together.... I forget whether it sorts by only creator or by creator and file type. A CLI interface to the finder would be nice, as long as it was done tastefully. -Sho
sho@pur-phy (Sho Kuwamoto) (04/11/89)
In article <664@wuphys.UUCP> mrk@wuphys.UUCP (Mark R. Kaufmann) writes: <In article <28679@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: <<Compare the time it takes to type "DIR<return>" with double-click. If you <<notice, it takes a lot less time to double-click than it does to type the <<command.... <Compare the time it takes to pick up your right hand from the home position <on the keyboard, which is its natural place :-) when using a computer, <finding the mouse, moving it where you want, double-clicking, then moving <your hand back to the keyboard. <I'd bet typing four characters is faster by a factor of ten. When browsing around the disk using the Finder, you never have your hands on the keyboard. The only time you type anything is when you: a) want to use a keyboard shortcut b) want to rename a file. Thus, your hand is virtually always on the mouse when using the Finder. Second, in a windowing system in general, you can have directory windows already open for the most commonly used directories. No need to type "cd ../../foo/bletch". Even if you need to open windows which are not already open, unless you only want to go up or down one level, I find it easier to use a mouse to move through directories. In addition, the Mac is intelligent in other ways. You can double click on a document, and it will open it using whatever application created that file. The StdFile package in the ROMs will give you a scrolling list of appropriate files when you want to open something from within a program. If you want, you can use the keyboard to select: use arrow keys to maneuver in the list, or type in the first n characters which will specify the file you want. If you want to type in the whole filename, go ahead. And if you really need a shell interface, you can always use the MPW Shell. -Sho
garys@bunker.UUCP (Gary M. Samuelson) (04/11/89)
In article <28679@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >In article <7898@pyr.gatech.EDU> is813cs@pyr.UUCP (Cris Simpson) writes: >>Anytime I have had to use a Mac, I always asked, >>"Why is it so slow?." > >Compare the time it takes to type "DIR<return>" with double-click. If you >notice, it takes a lot less time to double-click than it does to type the >command. Not a fair comparison. Typing DIR corresponds to moving the mouse until it points to (for example) the icon of the disk whose contents you want to examine. Typing <return> corresponds to double-clicking. Compare the time to type DIR<return> with <move the mouse><double-click>. I will guess that they are about the same. >I took a stopwatch to the two machines and found that it took about >half the time to execute a command on the Mac than it did on the PC. Not a fair comparison. Which version of Mac, and which version of PC? How many files? Did the Mac display the same information as the PC? Probably not; with the Mac you get (assuming "display by icon") names and icons, which roughly correspond to names and extensions (file types) on the PC. With the PC, if you type only DIR, you get a lot more information (which you may or may not want). To get the same information on the Mac, you have to change from "display by icon" to "display by size". I don't even recall if it's possible to get the MAC to display all the information at the same time that the DIR command displays. >Oh, by >the way, I type at 98 WPM, so I'm no slouch at the keyboard, but even I >appreciate (and use) the mouse and cursor keys. Fine. Some people prefer not to use a mouse; unfortunately, the Mac doesn't always give you a choice. What I want is a computer that can tell on which part of the screen (if any) my eyes are focused. Imagine 'more' stopping when you look away from the screen. Imagine 'vi' moving the cursor as you move your eyes. (Of course, there should be a way to dynamically enable and disable such a feature). Gary Samuelson
ch@maths.tcd.ie (Charles Bryant) (04/12/89)
In article <2587@ssc-vax.UUCP> dmg@ssc-vax.UUCP (David Geary) writes: > >keep up with the cursor. I was astounded. Now I use VI exclusively. >People see me using >VI nowadays, and say "WOW! What kind of editor is that - it's so fast." >"Vi", I reply. >"Oh, yuck", is usually their reply. I just kind of smile. > > BTW, when I was learning VI, I cursed it time and time again, ... This illustrates the _real_ difference between MAC and UNIX style programs. MAC programs are far easier to learn, but UNIX programs are more powerful. For many users it is not worth while spending a lot of time learning about a powerful program. For full-time programmers it is always worth while. This tends to make them see power as very important, whereas ease-of-learning is what sells machines. Another obstacle to developing a good user-interface is that a good user-interface is one that no-one notices while they are using it. If your testers say they were really impressed with your user-interface there is a good chance that its sub-optimal. -- Charles Bryant. Working at Datacode Electronics Ltd. (Modem manufacturers)
ddb@ns.network.com (David Dyer-Bennet) (04/12/89)
In article <28679@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: :In article <7898@pyr.gatech.EDU> is813cs@pyr.UUCP (Cris Simpson) writes: :>Anytime I have had to use a Mac, I always asked, :>"Why is it so slow?." : :Compare the time it takes to type "DIR<return>" with double-click. If you :notice, it takes a lot less time to double-click than it does to type the :command. I took a stopwatch to the two machines and found that it took about :half the time to execute a command on the Mac than it did on the PC. Assuming, of course, that your hand is already on the mouse and it is already pointing at the icon or menu entry you want to click on. -- David Dyer-Bennet, ddb@terrabit.fidonet.org, or ddb@ns.network.com or ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb or ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb or Fidonet 1:282/341.0, (612) 721-8967 9600hst/2400/1200/300
malloy@nprdc.arpa (Sean Malloy) (04/12/89)
In article <2132@pur-phy> sho@newton.physics.purdue.edu.UUCP (Sho Kuwamoto) writes: <In article <7910@pyr.gatech.EDU> is813cs@pyr.gatech.edu (Cris Simpson) writes: <<In article <28679@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: <<<Compare the time it takes to type "DIR<return<" with double-click. If you <<<notice, it takes a lot less time to double-click than it does to type the <<<command. [..] << Fine. To keep it appropriate for this newsgroup, how would you <<double click "dir *.c<CR>" ? <This isn't exactly what you want, but on the mac, you can select <view by type, which will clump all the files created by your <c compiler together.... I forget whether it sorts by only creator <or by creator and file type. But doesn't this lose you the speed advantage that the double click is supposed to give you? And look at your first sentence, "This isn't exactly what you want, . . .": This is exactly the point Cris was trying to make -- if all you want to do is what the programmer decided was what you would want to do, then the iconic interface may be faster; however, if you want to do anything else, then the iconic interface gets in the way of doing what you want. An iconic interface protects the user from the gritty details of running the program; a command-line interface protects the user from the programmer's preconceptions of what the user wants to do. Sean Malloy | "The proton absorbs a photon Navy Personnel Research & Development Center | and emits two morons, a San Diego, CA 92152-6800 | lepton, a boson, and a malloy@nprdc.navy.mil | boson's mate. Why did I ever | take high-energy physics?"
austing@Apple.COM (Glenn L. Austin) (04/12/89)
As a programmer who has worked on the IBM PC, VM/CMS, MVS, UN*X, Mac, ect, I have to say that as a programmer, I had more control over what the user could do under command line interfaces. If a command wasn't appropriate at that time, or was not typed correctly (how many times on the PC has anyone inadvertantly typed "DI<return>R"), or just wasn't recognized at that time. Most of the time, I could get away with just a "simple error message" like "Syntax Error." I, as a programmer, had total control over what the user could and couldn't do. Now that graphic interfaces (like the Mac, Windows, GEM) are becoming the norm, I have to take more care in writing code that doesn't know what order the user normally works with. I no longer am "in control of the user" in terms of what the user can or cannot do, and in what order. The user may want to open an old document first, or start a new document, change between the documents, close one before saving any changes, or any other thing that the interface "allows." I, as a programmer, don't know, and can't know, what order commands are going to be called. The user likes this because they have more control over how they use my program. Their boss likes it because the user can use more programs without spending hundreds or thousands of dollars to send the user to training seminars on each package they use, or spending hours of time attempting to learn the program they are using (the hidden costs of CLI and non-standard- ization). The programmer generally doesn't like it because he has to cover almost every eventuality in the order of commands. (flame on) I have written many programs under CLI and under graphic interfaces, and I prefer the graphic interface. Why? Because (1) the user generally can be productive with my programs without reading the manual, (2) the user can use the program in the way that suits him the best, (3) after writing a shell program that implements the user interface, all I have to do after that is *ONLY* write the specific code to create each program, a savings in time over designing and implementing not only the meat of the program, but the user interface as well, (4) it is a much more natural method for top-down and modular/object-oriented programming styles. It is not unusual to write a *GOOD* program for the Mac in under a day (given that it is a small, but useful program), where I can easily spend a week writing a similar program for the PC where I am spending the time beyond the meat of the program in tweaking the user interface. I have found that most programmers care only about their programs. In what I find what I call the "mainframe mentality" in that many programs change the environment that the program runs under without restoring the environment to what the user specified on exit of the program. This seems to be more prevalent in the UN*X environment than anywhere else, this "I know better what the user wants than the user does" attitude of programming. Since graphic interfaces challenge that belief, a lot of programmers are against them. However, since most users are occasional users of programs (the exceptions are word processors and secretaries), the "intuitive" interface is much better than an interface where you have to remember not only the commands, but how the programmer decided to spell the commands. A good example of this is in writing "KLOSE" to close the file, since C was already used in "COPY", or vice-versa. (flame off) If programmers do not provide what their users want, who will use their programs, and more importantly, who will use computers? ----------------------------------------------------------------------------- | Glenn L. Austin | The nice thing about standards is that | | Apple Computer, Inc. | there are so many of them to choose from. | | Internet: austing@apple.com | -Andrew S. Tanenbaum | ----------------------------------------------------------------------------- | All opinions stated above are mine -- who else would want them? | -----------------------------------------------------------------------------
emuleomo@yes.rutgers.edu (Emuleomo) (04/13/89)
# #Customer support on IBM-PC and Macs etc... # Thank GOD for the Norton Utilities How else do you think that the PC software busines 'blossomed' into a multibillion dollar industries and turned people like Peter Norton into Millionaires? Of course, it's from producing enhancements to our beloved text mode (non-icon) interfaces!! # # Vi (h/j/k/l) etc.. # I use 'vi' at home on my PC and at work on our 3B5 && I love it. I have seen Mac users wrestle with their MOUSE to do simple things like 'delete a line dd' or 'concatenate next line J'. (Can you use Macwrite on any other Machine? Ha ha) Besides you can use the arrow keys to move the cursor on some 'vi' implementations. However, I wish 'vi' had things like Windows && Columnar Cut and paste. --Emuleomo O.O.
flee@shire.cs.psu.edu (Felix Lee) (04/13/89)
In article <7910@pyr.gatech.EDU>, is813cs@pyr.gatech.edu (Cris Simpson) writes: > Fine. To keep it appropriate for this newsgroup, how would you >double click "dir *.c<CR>" ? You don't *need* to double-click "dir *.c". You have all your files arranged in clusters, don't you? -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!shire!flee
jcbst3@cisunx.UUCP (James C. Benz) (04/14/89)
In article <28558@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >Plenty of us? I know more people who *DON'T* know Unix than those that do. >Also, I know more than a few people who are totally intimidated by an English >interface (on the PC, does "FORMAT" get my document ready for printing?). >Oh, by the way, the last parenthesizes statement is common among secretaries >who know that they have to do something to print their document, but know >very little about the PC they are using! So go ahead and write software for users at the kindergarten level. But leave the option open for the knowledgeable user to bypass all the drek and get some real work done. The point of my posting was not that ALL users can do without icons, or even that most users can, but that MANY of us can, and for my money, I will be buying computers that don't get in my way with a lot of window dressing. I will not be buying Macintosh. I will not be buying anything with a mouse unless the software is designed to allow me to unplug the mouse and work exclusively with the keyboard. And icons belong in church, not on my computer screen. -- Jim Benz jcbst3@unix.cis.pittsburgh.edu If a modem University of Pittsburgh answers, UCIR (412) 648-5930 hang up!
jcbst3@cisunx.UUCP (James C. Benz) (04/14/89)
In article <8160@chinet.chi.il.us> john@chinet.chi.il.us (John Mundt) writes: >IBM and AT&T are working windows into PS/2 and UNIX V.4. Whether we like >it or not, icons are here to stay and will eventually take over because >the market does indeed cater to the lowest common denominator. But at least UNIX will (presumably) continue to allow me to get into a raw UNIX mode and bypass the windows. I don't mind icons as much as I do software that depends exclusively on them. Even a shell escape is preferrable to a cutesy little icon that when pointed to gives you the following mouse choosable options: ___________________ | | | cat | | page | | roff | | vi | | lp | |_________________| or something equally ludicrous. Unix in the hands of a skillful user can do ten times the work of any window/icon/mouse based application suite on the same processor and no matter what the market caters to, this will always be true. Catering to a specific market niche is a very dangerous thing for a computer manufacturer to do, as companies that specialized in software for the 6502 based market ten years ago can no longer tell you, since most no longer exist, and those who haven't learned this lesson will. -- Jim Benz jcbst3@unix.cis.pittsburgh.edu If a modem University of Pittsburgh answers, UCIR (412) 648-5930 hang up!
stuart@bms-at.UUCP (Stuart Gathman) (04/14/89)
In article <28558@apple.Apple.COM>, austing@Apple.COM (Glenn L. Austin) writes: > interface (on the PC, does "FORMAT" get my document ready for printing?). > Oh, by the way, the last parenthesizes statement is common among secretaries My brother was supporting MACs. He stepped out of the room for a minute, and when he got back there was a problem. The screen had said, "Insert another diskette" in one of those fancy dialog boxes. So she did. Without first removing the floppy already in the drive. This was the end of the floppy drive. Moral: Some background knowledge is required to operate any program. A truly user friendly system would prevent such a problem, but I submit that this is a very difficult problem for both hardware and software. The MAC still doesn't come close to solving it. P.S. Everyone I know, including myself, has spent at least 20 minutes trying to figure out how to delete a file when playing with the MAC for the first time. -- Stuart D. Gathman <stuart@bms-at.uucp> <..!{vrdxhq|daitc}!bms-at!stuart>
stuart@bms-at.UUCP (Stuart Gathman) (04/14/89)
In article <1936@dataio.Data-IO.COM>, bright@Data-IO.COM (Walter Bright) writes: > is the lexicographic order? (P.S. How do the Chinese find their icons > in a dictionary?) Chinese (and Japanese) icons are constructed from about 200 ideograms. (Small symbols put together to form a larger one.) Lexical order is determined by ideogram order which in most cases scans top to bottom, left to right. There are a few arcane exceptions, but no worse than those in vogue in English library card catalogs. -- Stuart D. Gathman <stuart@bms-at.uucp> <..!{vrdxhq|daitc}!bms-at!stuart>
austing@Apple.COM (Glenn L. Austin) (04/14/89)
In article <155@bms-at.UUCP> stuart@bms-at.UUCP (Stuart Gathman) writes: >In article <28558@apple.Apple.COM>, austing@Apple.COM (Glenn L. Austin) writes: > >> interface (on the PC, does "FORMAT" get my document ready for printing?). >> Oh, by the way, the last parenthesizes statement is common among secretaries > >My brother was supporting MACs. He stepped out of the room for a minute, ^^^^^^^ >and when he got back there was a problem. The screen had said, "Insert >another diskette" in one of those fancy dialog boxes. So she did. Without ^^^ >first removing the floppy already in the drive. This was the end of the >floppy drive. > >Moral: Some background knowledge is required to operate any program. >A truly user friendly system would prevent such a problem, but I submit >that this is a very difficult problem for both hardware and software. The >MAC still doesn't come close to solving it. > >P.S. Everyone I know, including myself, has spent at least 20 minutes trying >to figure out how to delete a file when playing with the MAC for the >first time. Well, anytime you force something, you break it. I have seen more disk drives broken because "the #!@$ disk won't go in" or "I can't get the #!@$ drive door closed." I have also seen many unusable disks that have been misaligned in the AT-type half-height drives with the "twist-type" drive "doors". I think that the moral of this story is "if it don't fit, find out why." ----------------------------------------------------------------------------- | Glenn L. Austin | The nice thing about standards is that | | Apple Computer, Inc. | there are so many of them to choose from. | | Internet: austing@apple.com | -Andrew S. Tanenbaum | ----------------------------------------------------------------------------- | All opinions stated above are mine -- who else would want them? | -----------------------------------------------------------------------------
austing@Apple.COM (Glenn L. Austin) (04/18/89)
In article <10040@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <28836@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >>I find what I call the "mainframe mentality" in that many programs change the >>environment that the program runs under without restoring the environment to >>what the user specified on exit of the program. This seems to be more >>prevalent in the UN*X environment than anywhere else, this "I know better what >>the user wants than the user does" attitude of programming. > >What in the world are you talking about? UNIX's design is such that upon >exit of a process the environment is necessarily back to what it was upon >initiation of the process, with the possible exception of terminal handler >modes, and even there unless the process was "stty" it is universally >understood to be a bug to have unilaterally altered terminal handler modes. How about environment variables? I have seen *MANY* cases where the environment variables get changed, and never restored. This was also the case with terminal handling (not restoring the terminal setups). This is simply poor programming, which has no excuse. >I find the "we know better than the user what the user wants" attitude to >be more prevalent in the Apple party line ("Human Interface Guidelines") >than elsewhere. For instance, when DiversiTune first showed up, the users >were ecstatic, but Apple's comments were nearly universally "hey, it >doesn't follow our HIG!", as though that were really important. Considering that the HIG was put together by experts in the field of user interfaces, it is the best overall guideline for graphics interfaces. However, like all experts, some things get overlooked. The *MOST IMPORTANT PART* of a user interface isn't that it matches a published guideline, although this should be important to the designer, but rather that the interface is intuitive, that it is easily understandable, and that it caters to the users' needs. ----------------------------------------------------------------------------- | Glenn L. Austin | The nice thing about standards is that | | Apple Computer, Inc. | there are so many of them to choose from. | | Internet: austing@apple.com | -Andrew S. Tanenbaum | ----------------------------------------------------------------------------- | All opinions stated above are mine -- who else would want them? | -----------------------------------------------------------------------------
desnoyer@Apple.COM (Peter Desnoyers) (04/18/89)
In article <29126@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: > >How about environment variables? I have seen *MANY* cases where the >environment variables get changed, and never restored. That's rather odd, as you can't change environment variables from a unix command or shell script. The spawned process only sees a copy of the environment. Are you sure it wasn't MSDOS? Peter Desnoyers
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (04/18/89)
In article <155@bms-at.UUCP> stuart@bms-at.UUCP (Stuart Gathman) writes: >..... The screen had said, "Insert >another diskette" in one of those fancy dialog boxes. So she did. Without >first removing the floppy already in the drive. This was the end of the >floppy drive. We may hold the record. During an installation process that required inserting ten floppy disks, one of our users actually got five of them in the drive... And she was annoyed that she couldn't get them all in, as the installation instructions insisted! The dialog box was changed to ask that the previous disk be removed -- and it waits until it is -- before asking for the next one. -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/18/89)
In article <29126@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >How about environment variables? I have seen *MANY* cases where the >environment variables get changed, and never restored. Mind telling us how this could happen? A child process can't change its parent's environment variables. >Considering that the HIG was put together by experts in the field of user >interfaces, it is the best overall guideline for graphics interfaces. Cough, cough.
peter@ficc.uu.net (Peter da Silva) (04/18/89)
Please move this OUT OF comp.lang.c. Observe followups. In article <29126@apple.Apple.COM>, austing@Apple.COM (Glenn L. Austin) writes: > How about environment variables? I have seen *MANY* cases where the > environment variables get changed, and never restored. This is not possible. Environment variables are local to a process... there is not even a mechanism in place for a process to change its parent's environment variables. Given that, how could you possibly have seen *MANY* cases where that's done? > Considering that the HIG was put together by experts in the field of user > interfaces, it is the best overall guideline for graphics interfaces. And the Apple user interface is hardly the best I've ever used. It's too heavily affected by the cost constraints on the original Mac. What's worse, all the sheep are following... my PC has a two-button mouse, so why should I have to use pull-down menus? Bleagh. > | All opinions stated above are mine -- who else would want them? | Amen. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
suitti@haddock.ima.isc.com (Stephen Uitti) (04/19/89)
In article <4855@bunker.UUCP> garys@bunker.UUCP (Gary M. Samuelson) writes: >In article <28679@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >>In article <7898@pyr.gatech.EDU> is813cs@pyr.UUCP (Cris Simpson) writes: >>>Anytime I have had to use a Mac, I always asked, >>>"Why is it so slow?." >> >>Compare the time it takes to type "DIR<return>" with double-click. If you >>notice, it takes a lot less time to double-click than it does to type the >>command. > >Not a fair comparison. Typing DIR corresponds to moving the mouse until >it points to (for example) the icon of the disk whose contents you want >to examine. "DIR" is a poor example. The time it takes to learn a complicated application dominates these days. At home i have a Mac II & a PC XT clone (7.15 MHz). They were purchased at the same time (within a week of each other). The clone was about half the cost. The clone has 50 Meg of disk, the Mac has 40 Meg (they both eat disk). The clone has 640K RAM (plenty), the Mac has 2 Meg (not enough). They have about the same response. (A Mac Se is slightly slower than the clone - but "good enough"). Take a typical program for the clone: pkarc. It has more than a dozen options, no real defaults. I keep a crib sheet under my clone's keyboard "pkarc -nct a dsk:archive files...", and "pkxarc -x dsk:archive", just to give me a hint on how to do these things. Maybe i'm slow, but it took me most of an hour to figure out how it worked. The equivelent on the Mac, "stuffit", never gave me any trouble. OK, so it doesn't work the way *I* would have designed it. It still uses the Mac interface, i didn't have to read the manual, i don't have to keep crib notes. Now take a complicated program. I have "canvas" for the Mac. It does object & bit oriented color graphics. I've used it for postprocessing scanned in images. I've used it as a drafting table (it supports arrows, measurements, etc). I've used it for graphics file conversion. It has a manual, and you need it. It has nearly infinite features. Sure, some of the icons don't mean anything until you read the manual. But they do mean something once you get the idea. No crib notes. It uses the Mac interface, so i can just play with it. It has help online. It comes with a tutorial and a reference guide (i wish more software came with both). I don't have anything nearly as complicated on the clone. The reason is that i simply don't have the time. It would take months rather than just days to learn something like that. My crib notes would be the size of most manuals. Commercial programs for clones are getting better. Turbo C uses menus. Interstel's EMPIRE (great game) uses menus and/or a mouse. Guess what? When you do that, the user interface slows down! The CPU needs to really kick in order to give you any kind of response. It takes all sorts of CPU to move the bits around the screen. At work, i use a Compaq 386/25, running UNIX. Incredible. Easily 3-4 times the speed of the old '780, and (often) all to myself. Guess what happens when we run X windows with a large bitmaped screen? It slows down to what i'm used to, but says "yes master", lots more often. This is a good deal. UNIX has one of the most cryptic command line interfaces ever invented. Powerful, yes. Who would have voluntarily come up with hundreds of two character command names. Almost no commands have options of more than one character. Many commands use both upper and lower case for options because they have too many. Hardly any commands with built in help. AT&T actually removed the manual pages from the distribution (though they may be coming back)!!!?! I'm convinced it was designed by people who could type maybe five words per minute, but who could play "concentration" in their sleep, and never make a mistake. Large bitmapped screens, X windows, mice (with too many buttons - come on guys: there are no lables on mouse buttons!) and real window managers could turn UNIX into a powerful AND user friendly system. Maybe even better than a Mac. Of course, vendors will have to realize that with $10k machines, their software will have to be cheaper... I'm not holding my breath. Stephen.
austing@Apple.COM (Glenn L. Austin) (04/19/89)
In article <29141@apple.Apple.COM> desnoyer@Apple.COM (Peter Desnoyers) writes: >In article <29126@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >> >>How about environment variables? I have seen *MANY* cases where the >>environment variables get changed, and never restored. > >That's rather odd, as you can't change environment variables from a >unix command or shell script. The spawned process only sees a copy of >the environment. Are you sure it wasn't MSDOS? You can do the same thing in MSDOS as you can in UNIX -- find the original copy of the environment table and modify it. It isn't too hard to do for UNIX programs, especially shell scripts. ----------------------------------------------------------------------------- | Glenn L. Austin | The nice thing about standards is that | | Apple Computer, Inc. | there are so many of them to choose from. | | Internet: austing@apple.com | -Andrew S. Tanenbaum | ----------------------------------------------------------------------------- | All opinions stated above are mine -- who else would want them? | -----------------------------------------------------------------------------
guy@auspex.auspex.com (Guy Harris) (04/19/89)
>>That's rather odd, as you can't change environment variables from a >>unix command or shell script. The spawned process only sees a copy of >>the environment. Are you sure it wasn't MSDOS? > >You can do the same thing in MSDOS as you can in UNIX -- find the original >copy of the environment table and modify it. It isn't too hard to do for >UNIX programs, especially shell scripts. It isn't difficult for shell scripts to modify the environment of the shell that's running the script. It is *quite* difficult for shell scripts to modify the environment of the shell that read the command to run the script, since that shell isn't running in the same process as the one running the script, and it is quite difficult for one process to find the environment in another process - for one thing, it needs read/write permission on "/dev/mem" and the swap device, or a "/proc" implementation and read/write access on that process, or the ability to "ptrace" that other process, or the active cooperation of that other process. The same applies to commands implemented as executable images rather than shell scripts. So, if you claim that you ran some ordinary program or shell script and it modified the environment *of the shell at which you typed the command* without the active cooperation of that shell (e.g., some combination of "eval" and backquotes), you didn't see what you think you saw - try again.