home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / windows / x / 18882 < prev    next >
Encoding:
Text File  |  1992-11-08  |  3.3 KB  |  67 lines
  1. Newsgroups: comp.windows.x
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!ames!think.com!mintaka.lcs.mit.edu!bloom-beacon!INTERNET!dont-send-mail-to-path-lines
  3. From: kk@unisql.UUCP (Kerry Kimbrough)
  4. Subject: Design for independent UI development
  5. Message-ID: <9211051635.AA02325@hyundai.unisql>
  6. Sender: root@athena.mit.edu (Wizard A. Root)
  7. Organization: The Internet
  8. References: <7307@fury.BOEING.COM>
  9. Date: Thu, 5 Nov 1992 16:35:14 GMT
  10. Lines: 55
  11.  
  12.  
  13.  
  14.    |>   It is my experience that the user interface tends to be very tightly
  15.    |>   bound to the system that is being designed, and that the user
  16.    |>   interface code tends to be mixed in directly with application code,
  17.    |>   making it very hard to split up their development.
  18.  
  19. To those interested in sw UI's, this issue occupies somewhat the same
  20. position as the question of a unified field theory does for physicists. 
  21.  
  22. Since the 60's (! remember the Reaction Handler?), the fundamental premise
  23. of work in UIMSs and most UI toolkits is that it's possible to modularize a
  24. sw system so that its UI is independent of its functional core. We want
  25. this to be true, we *need* this to be true. (In fact, if it isn't true,
  26. then we're likely to go broke.)  It seems very plausible and possible. But
  27. is it actually true? As for a unified field, the evidence is tantalizing
  28. but incomplete.
  29.  
  30. It seems to be a matter of degree. Some UI independence is certainly
  31. possible, but how much? A lot? Or negligible? For example, it's pretty
  32. clear that the functional core need not depend on most UI details at the
  33. lowest lexical (presentation) level. But experience shows that it's much
  34. harder for the intermediate dialog levels of the UI to remain extricable
  35. from core semantics.
  36.  
  37. Also, it seems to depend on what kind of UI you're talking about. For
  38. command language UIs and forms-based UIs, we've seen a lot of successful
  39. tools for independent UI development. But for the direct manipulation GUIs
  40. that occupy our main interest today, the situation is still pretty rough.
  41. The efficacy of the tools seems inversely proportional to their
  42. applicability to new domains, with new kinds of objects at the functional
  43. core.
  44.  
  45. Personally, I feel that hope for DM GUIs may lie in the notion of a shared
  46. database of objects that form the communication between UI and core. This
  47. is the approach taken by the UIMSs like Serpent and Apogee and others.
  48. These shared objects must reflect both UI and core domain needs.  These are
  49. objects *of* the core domain that encapsulate domain facts and behaviors.
  50. But, within the domain, they function as UI ambassadors. That is, these are
  51. the objects that represent exactly how the system appears to the world
  52. outside its domain (which may very different from how the system actually
  53. works). These ambassadors may constitute the true line of UI independence,
  54. with both UI and core free to vary on their respective sides of the line.
  55.  
  56. That's why, regardless of what tools you use, the first step in designing a
  57. GUI is to itemize in complete detail all the components of the user's
  58. conceptual model of the system --- facts, relationships, and behaviors.
  59. This model is then a picture of your ambassador objects. That also explains
  60. why designing the UI first increases chances of system success --- without
  61. the conceptual model, system engineers don't know what ambassadors to
  62. construct.
  63.  
  64.  
  65.  
  66.  
  67.