home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / question / 13707 < prev    next >
Encoding:
Text File  |  1992-11-20  |  2.1 KB  |  47 lines
  1. Newsgroups: comp.unix.questions
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!nastar!phardie
  3. From: phardie@nastar.uucp (Pete Hardie)
  4. Subject: Re: IS UNIX DEAD
  5. Message-ID: <1992Nov20.215955.8209@nastar.uucp>
  6. Organization: Digital Transmission Systems, Duluth, GA.
  7. References: <98246@netnews.upenn.edu>
  8. Date: Fri, 20 Nov 1992 21:59:55 GMT
  9. Lines: 36
  10.  
  11. In article <98246@netnews.upenn.edu> ioi@pixmap.seas.upenn.edu (Ioi Kim Lam) writes:
  12. >    I see your point. I agree that currently many powerful
  13. >applications are hard to use, but that is due to their poor design. I hope
  14. >you would understand that a lot of "powerful applications" you have
  15. >mentioned (in your previous postings) were made more than a decade ago.
  16.  
  17. This is a blanket statement, and therefore somewhat suspect.  There are some
  18. things that are inherently complex, and no amount of GUIfying can change
  19. this.  When we have AI, we might be able to hand off some of this complexity,
  20. but until then we are stuck with it.
  21.  
  22. One cannot blame the complexity whooly on a poor user interface.
  23.  
  24. >    I believe what the programmer should do is to deliver the power of
  25. >the computer to every user, regardless to their knowledge in computing.
  26.  
  27. As a programmer, I am tasked with delivering a system to the client's order.
  28. Some of this will involve making the system easy to use for a set of the
  29. end-users, yet harder for another set.  For example, removing arbitrary files is
  30. easy for someone with root privelege, and should be.  Such ease is NOT the
  31. desired case for J. Random User, thus the file permissions.
  32.  
  33. >    If a user finds an application too difficult to use, that is not
  34. >his fault. That is the designer's fault. And believe me, we can correct
  35. >it.
  36.  
  37. Again, not in all cases.  I have seen a tendency to expect the machine to do
  38. everything for the user, regardless of this being a bad thing in some cases.
  39. People still need to think about what they are doing, at least at first.
  40.  
  41.  
  42. -- 
  43. Pete Hardie:  phardie@nastar  (voice) (404) 497-0101
  44. Digital Transmission Systems, Inc., Duluth GA
  45. Member, DTS Dart Team           |  cat * | egrep -v "signature virus|infection" 
  46. Position:  Goalie               |
  47.