home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.17 / text0080.txt < prev    next >
Encoding:
Internet Message Format  |  1990-01-06  |  4.2 KB
  1. From: mark@jhereg.Minnetech.MN.ORG (Mark H. Colburn)
  2.  
  3. In article <458@longway.TIC.COM> srg@quick.COM (Spencer Garrett) writes:
  4. >From: srg@quick.COM (Spencer Garrett)
  5. >
  6. >I agree with rich 100%.  I figure that when the standards committees
  7. >start meeting it's time to start looking for the next generation gizmo.
  8.  
  9. It's not exactly that.  As far as windowing standard go, there is
  10. definitely the desire to have a common graphical interface so that both
  11. users and application developers have a common ground to stand on.  However,
  12. it is not this desire which is being met by 1201.
  13.  
  14. The users would like a common user interface (UI) so that they don't have 
  15. to relearn the look and feel aspects for each and every application that 
  16. comes out.  The developers want a common application programming interface 
  17. (API) so that they don't have to go through all the work to port their code 
  18. to umpteen windowing systems on umpteen machines in order to make a 
  19. successful product.
  20.  
  21. There is always the problem of attempting to do too much too early and 
  22. stnadardization in this area may fall prey to this common problem.
  23.  
  24. The development of graphical user interfaces (GUIs) is relatively new and 
  25. there are a lot of different ones out there: NeWs, X, Motif, NewWave, 
  26. NextStep, SunView, Macintosh, Presentation Manager, Windows, etc.  The 
  27. fact that there are so many shows that there is still some shakeout going 
  28. on in the industry.  Lawsuits like Apple's shows how ferocious the 
  29. competition in this area can be.
  30.  
  31. I would agree that there are some problems with the charter for 1201,
  32. however, there are problems with not taking steps to standardize GUIs 
  33. as well: increased development time for new applications (also read 
  34. increased expense) and longer learning time for users on new 
  35. applications.
  36.  
  37. My personal feeling is that 1201 should work on an application level
  38. interface so that portable applications can be built that would provide a
  39. standardized "look and feel" to the user.  Obviously, there is a
  40. significant amount of work that still needs to be done in this area, but
  41. there are some relatively safe things they can say about things like
  42. desktops, windows, menus, etc.  Many of the afore mentioned windowing 
  43. system's user interfaces are quite similar when you take away things like 
  44. whether they shade their overlapping windows, or whether they have round 
  45. or square "radio buttons".  They generally provide some form of desktop, 
  46. windows, menues, scroll bars, etc.
  47.  
  48. Most of these ideas originated at Xerox in the 1960's and 1970's making
  49. these elements of windowing systems at least as old as Unix.
  50.  
  51. Instead of focusing on either the user interface or the API, 1201 is 
  52. standardizing the toolkit, which I feel is too low a layer to be working 
  53. on now, primarily because it does not really address the needs of the two 
  54. sides that "need" the standard the most: the users and the developers.  
  55. The toolkit standardization helps the vendors because they can claim 
  56. conformance to a standard and then layer the toolkit between their own 
  57. proprietary user interface and API, baffling users and developers alike.  
  58. It also walks the fine line of "implementation details" that standard 
  59. bodies usually try so hard to avoid.
  60.  
  61. There are those that would say that a windowing standard will stifle their
  62. creativity to develop their own windowing system.  However, this can be
  63. countered with the argument that instead of directing their creativity to
  64. something which has been done a thousand times already (such as windowing
  65. systems), they can channel their creativity into something new and truly
  66. innovative.
  67.  
  68. I don't neccessarily think that it is too early to start working on a
  69. standard.  Remember that it takes a long time for a standard to come into
  70. being.  By merely starting work on a standard it helps to shakeout the
  71. industry to find out what is "good" and what is not.  There are definitly
  72. enough systems to look at out there.  I am not sure that X is the best
  73. choice, but it is a widely accepted base: the basis for any standard.
  74.  
  75. I would like to see more emphasis placed on both the UI and API aspects of
  76. the standard however, so that the standard can help more than the vendors.
  77.  
  78. -- 
  79. Mark H. Colburn                       mark@Minnetech.MN.ORG
  80. Open Systems Architects, Inc.
  81.  
  82. Volume-Number: Volume 17, Number 89
  83.  
  84.  
  85.