home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 179.a < prev    next >
Internet Message Format  |  1990-12-05  |  14KB
  1. From jsq@cs.utexas.edu  Thu Oct  4 10:44:57 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA28247; Thu, 4 Oct 90 10:44:57 -0400
  4. Posted-Date: 3 Oct 90 16:45:24 GMT
  5. Received: by cs.utexas.edu (5.64/1.77) 
  6. From: rcs@sei.cmu.edu (Robert Seacord)
  7. Newsgroups: comp.std.unix
  8. Subject: User Interface Management Systems and Application Portability
  9. Keywords: UIMS, P1201
  10. Message-Id: <13180@cs.utexas.edu>
  11. Sender: jsq@cs.utexas.edu
  12. Reply-To: rcs@sei.cmu.edu (Robert Seacord)
  13. Organization: The Software Engineering Institute
  14. X-Submissions: std-unix@uunet.uu.net
  15. Date: 3 Oct 90 16:45:24 GMT
  16. To: std-unix@uunet.uu.net
  17.  
  18. Submitted-by: rcs@sei.cmu.edu (Robert Seacord)
  19.  
  20. the following article appears in the standards column of the october issue
  21. of ieee computer.  i am posting it to this newsgroup with permission from 
  22. the ieee.
  23.  
  24. rCs
  25. ______________________________________________________________
  26. User Interface Management Systems and Application Portability
  27.  
  28. by
  29.  
  30. Robert C. Seacord
  31. Member of the Technical Staff
  32. Software Engineering Institute
  33.  
  34.   Higher  level  programming  languages  and  standard  operating  systems now
  35. provide greater portability of application software than previously  possible.
  36. Software  developed  in  C  for  Unix,  for example, can be easily ported to a
  37. variety of different architectures and  machines.    Developing  language  and
  38. operating  system  standards  such  as  ANSI  C  and  IEEE  POSIX will further
  39. application portability.  At a quick glance it appears as though open  systems
  40. are finally becoming a reality, but are they really?
  41.  
  42.   As  porting  software  to  different  architectures  becomes more and more a
  43. matter of simply  recompiling  the  software  for  that  architecture,  it  is
  44. apparent  that  a serious problem in portability is with the user interface of
  45. these systems.  Now, more than ever, when a customer buys a computer  platform
  46. they  are  also  buying  a  "look and feel" associated with that system.  When
  47. using an Apple Macintosh, for example, the user expects to be able to  perform
  48. a variety of actions using a single button mouse.  When working with an MS DOS
  49. application, the user expects to be able to perform the same actions using the
  50. keyboard.    When  running  OpenLook,  Motif, or NeXTStep the user expects the
  51. application to provide a defined look and feel.   Porting  an  application  to
  52. simply run on a different platform is insufficient; there is a requirement for
  53. the application interface to behave in a similar fashion to other applications
  54. developed for that environment.
  55.  
  56.   Software  designs are usually not extensible enough to allow the integration
  57. of different user interface toolkits, particularly if  these  toolkits  employ
  58. significantly  different  models  in  their  application interfaces.  Changing
  59. toolkits or integrating new toolkits usually requires  major  modification  to
  60. the application, which then requires extensive re-testing of the application.
  61.  
  62.   Current  standards  activities are just beginning to address these problems.
  63. To date, standards bodies have attempted to define an abstract user  interface
  64. toolkit  that  can  be  implemented  in  different  ways.  Where this approach
  65. provides some degree of device independence it does not allow for the  removal
  66. of  stylistic  concerns  from  the  application.   For example, where one user
  67. interface style guide may call for a pull-down menu, another may  call  for  a
  68. command line interface.
  69.  
  70.   One  approach  for  addressing the problem of application portability across
  71. multiple look and feel platforms is the definition  and  implementation  of  a
  72. method  for  separating  the  application  from  the  user  interface.    This
  73. separation makes changing the user interface of the system practical. It  also
  74. makes  it  possible  to  change  user interface toolkits without modifying the
  75. application software.
  76.  
  77. User Interface Management Systems
  78.  
  79.   The term user interface management system (UIMS) was first coined at a  1982
  80. Workshop  on  Graphical  Input  Interaction Technique (GIIT) [17].  UIMSs are,
  81. among other things, intended to encourage the separation of a software  system
  82. into  an  application  portion  and a user interface portion.  The application
  83. portion of  a  system  implements  the  core  functionality,  while  the  user
  84. interface portion implements the user interface dialogue.
  85.  
  86.   UIMSs   provide   facilities   for   defining   both  presentation  and  the
  87. computer-human dialogue components of a user  interface.    A  UIMS  also  may
  88. provide  facilities to support prototyping, encourage a design that allows for
  89. easy  modification  of  the  user  interface,   support   implementation   and
  90. maintenance   of   the   user   interface,  and  allow  for  the  evolutionary
  91. incorporation of new user interface technologies.
  92.  
  93.   Most UIMSs are based on the Seeheim architecture [7] (see Figure 1).    This
  94. architecture  uses a layered approach similar to the one used in International
  95. Standards Organization (ISO) Open Systems Interconnection (OSI) standard.  The
  96. architecture  is intended to encourage the separation of functionality between
  97. the application and the user interface portions of a  software  system.    The
  98. three different layers of the architecture provide differing levels of control
  99. over user input and system output.
  100.  
  101.         Application Layer
  102.  
  103.         Dialogue Layer
  104.  
  105.         Presentation Layer
  106.  
  107.                         Figure 1:   UIMS Architecture
  108.  
  109.   The application layer consists of the core functionality of the  application
  110. that can be described in a presentation independent manner.  For example, in a
  111. calculator program this would include the underlying math subroutines library.
  112.  
  113.   The dialogue layer  specifies  the  presentation  dependent  portion  of  an
  114. application  system including the dynamic behavior of the user interface.  The
  115. dialogue should allow the display and removal of interaction  objects  without
  116. application  involvement and support cascading menus, direct manipulation, and
  117. other user interface sytles and techniques.  The dialogue provides the mapping
  118. between  the presentation and application layers.  The user interface dialogue
  119. may be specified using a user interface definition language (UIDL)  or  by  an
  120. interactive technique.
  121.  
  122.   The  presentation  layer  controls  the  end-user interactions and generates
  123. low-level feedback.  The  presentation  layer  consists  of  a  collection  of
  124. interaction objects defined for a given user interface technology.
  125.  
  126. Existing Approaches
  127.  
  128.   Since  the  1982 GIIT Workshop, there have been a number of efforts to build
  129. UIMSs that achieve the goal of  separation  of  concerns,  while  remaining  a
  130. practical   approach  to  software  development.    These  systems  have  been
  131. classified by the model used in dialogue specification.    Some  of  the  more
  132. successful  approaches have been:  event-driven, declarative, object-oriented,
  133. data-driven, and interactive layout systems.
  134.  
  135.   In the event-driven approach, inputs are  considered  as  events  which  are
  136. immediately  handled  by  event  handlers.    Event  handlers can cause output
  137. events, change  the  internal  state  of  the  system,  and  call  application
  138. routines.   Examples of event-driven systems include the University of Alberta
  139. UIMS [6], ALGAE [5], Sassafras [9], and the TeleUSE UIMS [16].
  140.  
  141.   Another approach is the use of declarative languages  in  which  constraints
  142. are  defined in order to specify what the system should do rather than specify
  143. how it should be done.  An example of a system that  takes  this  approach  is
  144. Cousin [8].  In this category, there is a class of systems which automatically
  145. generate the user interface based on a definition  of  the  semantic  commands
  146. supported by the application. Examples are the UofA* UIMS [12] and MIKE [10].
  147.  
  148.   An  object-oriented  approach  uses  objects for defining user interactions,
  149. transforming data and interacting with the application.  A good example  of  a
  150. commercially  available  system  that uses an object-oriented approach is Open
  151. Dialogue [1] developed by Apollo Computer.
  152.  
  153.   In the data-driven approach, the application communicates with the  UIMS  in
  154. terms  of  shared  data elements.  The UIMS behaves like an active database in
  155. that it provides a mapping between application data and user interface toolkit
  156. objects, and notifies the application of changes to application data resulting
  157. from user interactions.  This approach was implemented  in  the  Serpent  UIMS
  158.  [2]  developed  at  the  Software  Engineering  Institute  at Carnegie Mellon
  159. University and the George Washington UIMS [11].
  160.  
  161.   Interactive layout systems allow the user to build user interface by  direct
  162. manipulation.    Examples are Menulay [3], DialogEditor [4], vu [13], and TAE+
  163.  [15].
  164.  
  165. UIMS Study Group
  166.  
  167.   The IEEE P1201 working group was formed in January of 1989 and chartered  to
  168. develop standards that would further application and user portability in the X
  169. Windows Environment [14].  Since P1201 was formed,  Open  Software  Foundation
  170. (OSF), Sun and AT&T have independently developed toolkits for X Windows.  Much
  171. of the P1201 effort has been spent trying to decide if any of  these  toolkits
  172. can  serve as a basis for a standard or if a "virtual" toolkit approach can be
  173. used.
  174.  
  175.   In August of 1989, a UIMS study group was begun in  P1201  to  determine  if
  176. UIMS  technology was sufficiently advanced to solve the problem of application
  177. portability across multiple look and feel platforms and to define the scope of
  178. a UIMS standard.
  179.  
  180.   The   group   identified  two  components  where  standardization  would  be
  181. beneficial to the industry.  The first of these is an application  programmers
  182. interface (API) that would:
  183.  
  184.    1. Provide a standard application programmers interface across changes
  185.       in the underlying toolkit.
  186.  
  187.    2. Support  the  separation  of  an  application   into   presentation
  188.       independent  and presentation dependent layers corresponding to the
  189.       application, dialogue,  and  presentation  layers  of  the  Seeheim
  190.       architecture.
  191.  
  192.    3. Allow   the  development  of  applications  that  are  presentation
  193.       independent  (i.e.,  the  underlying  windowing  system   or   user
  194.       interface toolkit).
  195.  
  196.   The  second  component is a UIMS interchange format (UIF).  The purpose of a
  197. standard UIF is:
  198.  
  199.    1. To enable a wide variety of UIMSs to use a single format  to  store
  200.       and exchange their data.
  201.  
  202.    2. To  allow  vendors  to develop compilers or interpreters that could
  203.       "execute" the UIF on their  platforms  in  a  manner  analogous  to
  204.       postscript printers.
  205.  
  206.   The  P1201  UIMS  study  group  has  evaluated  a  number  of user interface
  207. management systems including Serpent, TeleUSE, and TAE+.  The concensus of the
  208. group  is that the state of the practice is sufficiently advanced to warrant a
  209. standards effort.  It is believed that a  UIMS  standard  would  enhance  both
  210. application  portability  and  the  state  of  the  practice in user interface
  211. development.
  212.  
  213.                                   REFERENCES
  214.  
  215.  
  216. [1]   Apollo Inc.
  217.       Open Dialogue:  Designing Portable, Extensible User Interfaces.
  218.       1987
  219.  
  220.  
  221. [2]   Bass, L.J., et al.
  222.       Serpent:  A User Interface Environment.
  223.       In Proceedings, Winter 1990 USENIX Technical Conference.  Washington,
  224.          D.C., January, 1990.
  225.  
  226.  
  227. [3]   Buxton, W., Lamb, M.R., Sherman D., Smith, K.C.
  228.       Towards a Comprehensive User Interface Management System.
  229.       In Computer Graphics: SIGGRAPH'83 Conference Proceedings, pages 35-42.
  230.          Detroit, MI., July, 1987.
  231.  
  232.  
  233. [4]   Cardelli, L.
  234.       Building User Interfaces By Direct Manipulation.
  235.       In Proceedings, ACM SIGGRAPH Symposium on User Interface Software, pages
  236.          152-166.  ACM, New York, NY, 1988.
  237.  
  238.  
  239. [5]   Flecchia, M.A. and Bergeron, R.D.
  240.       Specifying Complex Dialogs in ALGAE.
  241.       In Proceedings SIGCHI+GI'87: Human Factors in Computing Systems, pages
  242.          229-234.  Toronto, Ont., Canada, April, 1987.
  243.  
  244.  
  245. [6]   Green, M.
  246.       A Survey of Three Dialogue Models.
  247.       ACM Transactions on Graphics 5(3):244-275, July, 1986.
  248.  
  249.  
  250. [7]   Green, M.
  251.       Report on Dialogue Specification Tools.
  252.       User Interface Management Systems :9-20, 1985.
  253.  
  254.  
  255. [8]   Hayes, P.J., Szekely, P.A., Lerner, R.A.
  256.       Design Alternatives for User Interface Management Systems Based on
  257.          Experience with COUSIN.
  258.       In Proceedings SIGCHI'85: Human Factors in Computing Systems, pages
  259.          169-175.  San Francisco, CA, April, 1985.
  260.  
  261.  
  262. [9]   Hill, R.D.
  263.       Event-Response Systems -- A Technique for Specifying Multi-Threaded
  264.          Dialogues.
  265.       In Proceedings SIGCHI+GI'87: Human Factors in Computing Systems, pages
  266.          241-248.  Toronto, Ont., Canada, April, 1987.
  267.  
  268.  
  269. [10]  Olsen, D.R.
  270.       The Menu Interaction Kontrol Environment.
  271.       ACM Transactions on Graphics 5(3):318-344, 1986.
  272.  
  273.  
  274. [11]  Sibert, J.L.
  275.       An Object-Oriented User Interface Management System.
  276.       In Computer Graphics: SIGGRAPH'86 Conference Proceedings, pages 259-268.
  277.          Dallas, Texas, August, 1986.
  278.  
  279.  
  280. [12]  Singh, G. and Green. M.
  281.       A High Level User Interface Management System.
  282.       In Proceedings SIGCHI'89:  Human Factors in Computing Systems, pages
  283.          133-138.  ACM, New York, NY, 1989.
  284.  
  285.  
  286. [13]  Singh, G. and Green. M.
  287.       Designing the Interface Designer's Interface.
  288.       In Proceedings, ACM SIGGRAPH Symposium on User Interface Software, pages
  289.          109-116.  ACM, New York, NY, 1988.
  290.  
  291.  
  292. [14]  Mehta, S.
  293.       User Interfaces and the IEEE P1201 Committee.
  294.       Unix Review 8(1):14-20, January, 1990.
  295.  
  296.  
  297. [15]  Szczur, L. and Miller, P.
  298.       Transportable Applications Enviroment (TAE)+:  Experiences in
  299.          Objectively Modernizing a User Interface Environment.
  300.       In OOPSLA'88 Conference Proceedings, pages 58-70.  San Diego, CA,
  301.          November, 1988.
  302.  
  303.  
  304. [16]  TeleLOGIC.
  305.       TeleUSE Reference Manual.
  306.       1989
  307.  
  308.  
  309. [17]  Thomas, J.J. and Hamlin, G.
  310.       Graphical Input Interaction Technique (GIIT) Workshop Summary.
  311.       Computer Graphics 17(1):5-30, January, 1983.
  312.  
  313.  
  314. Volume-Number: Volume 21, Number 179
  315.  
  316.