home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / amiga / misc / 19823 < prev    next >
Encoding:
Internet Message Format  |  1993-01-12  |  4.8 KB
  1. Path: sparky!uunet!mcsun!Germany.EU.net!mpifr-bonn.mpg.de!uniol!caty!cbmger!peterk
  2. From: peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany)
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: Commodity question
  5. Message-ID: <10422@cbmger.de.so.commodore.com>
  6. Date: 12 Jan 93 09:17:46 GMT
  7. References: <1992Dec17.070805.1@vaxb.acs.unt.edu> <rschuler.724653094@pv0221.vincent.iastate.edu> <crystal.724659529@glia> <10372@cbmger.de.so.commodore.com> <crystal.725771527@glia>
  8. Reply-To: peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany)
  9. Organization: Commodore Germany
  10. Lines: 85
  11.  
  12. In article <crystal.725771527@glia> crystal@glia.biostr.washington.edu (Crystal) writes:
  13. >In <10372@cbmger.de.so.commodore.com> peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany) writes:
  14. >>In article <crystal.724659529@glia> crystal@glia.biostr.washington.edu (Crystal) writes:
  15. >> >In <rschuler.724653094@pv0221.vincent.iastate.edu> rschuler@iastate.edu (Rodney A Schuler) writes:
  16. >> >
  17. >> >>RTFM (read the FINE manual)
  18. >> >
  19. >> >Uh, if I may interject here... ?
  20. >> >
  21. >> >Many times I've found that the manuals written by *programmers* are difficult
  22. >> >for the non-programmers/casual users to decipher.  
  23. >
  24. >>Sorry, wrong in this case. All the Amiga user manuals are *not* written
  25. >>by the programmers but by docs specialists.
  26. >
  27. >If you read my post carefully you would see that I said  "MANY TIMES" not ALL
  28. >the time...  
  29.  
  30. Yes, and I didn't want to say you were lying, but to give an information
  31. how it's done at Commodore and that at least *this* issue is not a first
  32. reason to be concerned.
  33.  
  34. >And just because something is written by a "specialist" does not AUTOMATICALLY
  35. >mean that any fool/idiot can understand it.  
  36.  
  37. Yes, of course. Nobody's perfect.
  38.  
  39. >I don't know what kind of Dr. you are, Sir, but if you have ever tried to
  40. >teach, you may have noticed that there are some students that you have to 
  41. >clobber with bricks and TOTAL simplicity to get them to understand even the 
  42. >most simple concepts, that to you are second nature/common knowledge.
  43.  
  44. Again you are completely right. I studied Physics and during my time at uni
  45. one of my main tasks was to teach pharmaceuts (sp?) some physics. You can't
  46. imagine less physics-motivated people than these. And yes, we had to do it
  47. like for the extreme dumb ones.
  48.  
  49. But with computer manuals, there's a dilemma, we sit between a whole number
  50. of chairs:
  51. - If we do manuals for the dumb ones, the more literate users complain,
  52.   what this company has an imagination of its users, they feel really
  53.   blamed.
  54. - If we do manuals for the literate ones, the others complain about not
  55.   understandable docs.
  56. - If we do both, the docs get so much volume that a) Commodore bosses
  57.   complain about the cost, b) all (:-) users complain because they can't
  58.   find anything in these mountains of paper.
  59. - Some people like lengthy and wordy explanations. When we do this, the
  60.   others complain about too much redundance and bloating.
  61. - Some people like compact, short and precise information. When we do
  62.   this, the others complain about lack of "explanation".
  63.  
  64. So my conclusion is that it's perfectly impossible to create documentation
  65. that satisfies *every* user. They are sooo different. But of course we 
  66. *try* to satisfy as many as possible. This is a case of nonlinear 
  67. optimization and you never know where the optimum really is. But I can 
  68. assure you that we listen to our customers and try to fix recognized 
  69. deficiencies, once spotted.
  70.  
  71. >(BTW, I have trouble understanding the docs that came with the 2.04 ROM. I keep
  72. >getting the impression that I need to have some sort of "background" which I
  73. >don't have, in order to make sense out of the terminology used.  It doesn't seem
  74. >to match the terminology I am used to from MAC/MS-DOS/APPLE ][ and CP/M. Like,
  75. >what the H*ll is a "commodity"???  
  76.  
  77. Don't ask me. We even had no word for translating this into German. So for
  78. us, this is simply a name of a drawer holding a certain type of service
  79. programs. In English it's thought as something comfortable, if I read my
  80. dictionary correctly... (I'm german, you know)
  81.  
  82. >...nor can I understand the difference between a utility, a tool or
  83. >a project... *whimper*)
  84.  
  85. Well, a project is data, not program code (but OTOH, program source files
  86. for an interpreter or compiler are also considered as projects), or better
  87. "not directly excutable code". The differences between "tools", "utilities",
  88. "commodities" or things in the System drawer are indeed not very big.
  89. For Commodities, you can state that they are all handlers inserted into
  90. the input data stream, doing some interesting and nice things there. They
  91. are defined by their use.
  92.  
  93. -- 
  94. Best regards, Dr. Peter Kittel  // E-Mail to \\  Only my personal opinions...
  95. Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
  96. Wer's nicht kann, soll's bleiben klopfen oder Steine lassen!
  97.