Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/v21/179.a.diff

Text File | 1990-12-05 | 15.0 KB | 334 lines

394 vn/179 vn/179.a
1c1
< From [e-mail]  Thu Oct  4 07:46:00 1990
---
> From [e-mail]  Thu Oct  4 10:44:57 1990
3,4c3,4
<     id AA15203; Thu, 4 Oct 90 07:46:00 -0400
< Posted-Date: 4 Oct 90 11:35:31 GMT
---
>     id AA28247; Thu, 4 Oct 90 10:44:57 -0400
> Posted-Date: 3 Oct 90 16:45:24 GMT
6,14c6,16
< From: root@cass (cass System Administrator)
< Newsgroups: world
< Subject: cancel <1990Sep29.121015.27562@cass>
< Message-Id: <1990Oct4.113531.7949@cass>
< References: <1990Sep29.121015.27562@cass>
< Control: cancel <1990Sep29.121015.27562@cass>
< Organization: Bull HN, USIS/ISPT - Advanced Technologies for Business Systems.
< Date: 4 Oct 90 11:35:31 GMT
< Apparently-To: [e-mail]
---
> From: [e-mail] (Robert Seacord)
> Newsgroups: comp.std.unix
> Subject: User Interface Management Systems and Application Portability
> Keywords: UIMS, P1201
> Message-Id: <[e-mail]>
> Sender: [e-mail]
> Reply-To: [e-mail] (Robert Seacord)
> Organization: The Software Engineering Institute
> X-Submissions: [e-mail]
> Date: 3 Oct 90 16:45:24 GMT
> To: [e-mail]
16c18,314
< This article was probably generated by a buggy news reader.
---
> Submitted-by: [e-mail] (Robert Seacord)
>
> the following article appears in the standards column of the october issue
> of ieee computer.  i am posting it to this newsgroup with permission from
> the ieee.
>
> rCs
> ______________________________________________________________
> User Interface Management Systems and Application Portability
>
> by
>
> Robert C. Seacord
> Member of the Technical Staff
> Software Engineering Institute
>
>   Higher  level  programming  languages  and  standard  operating  systems now
> provide greater portability of application software than previously  possible.
> Software  developed  in  C  for  Unix,  for example, can be easily ported to a
> variety of different architectures and  machines.    Developing  language  and
> operating  system  standards  such  as  ANSI  C  and  IEEE  POSIX will further
> application portability.  At a quick glance it appears as though open  systems
> are finally becoming a reality, but are they really?
>
>   As  porting  software  to  different  architectures  becomes more and more a
> matter of simply  recompiling  the  software  for  that  architecture,  it  is
> apparent  that  a serious problem in portability is with the user interface of
> these systems.  Now, more than ever, when a customer buys a computer  platform
> they  are  also  buying  a  "look and feel" associated with that system.  When
> using an Apple Macintosh, for example, the user expects to be able to  perform
> a variety of actions using a single button mouse.  When working with an MS DOS
> application, the user expects to be able to perform the same actions using the
> keyboard.    When  running  OpenLook,  Motif, or NeXTStep the user expects the
> application to provide a defined look and feel.   Porting  an  application  to
> simply run on a different platform is insufficient; there is a requirement for
> the application interface to behave in a similar fashion to other applications
> developed for that environment.
>
>   Software  designs are usually not extensible enough to allow the integration
> of different user interface toolkits, particularly if  these  toolkits  employ
> significantly  different  models  in  their  application interfaces.  Changing
> toolkits or integrating new toolkits usually requires  major  modification  to
> the application, which then requires extensive re-testing of the application.
>
>   Current  standards  activities are just beginning to address these problems.
> To date, standards bodies have attempted to define an abstract user  interface
> toolkit  that  can  be  implemented  in  different  ways.  Where this approach
> provides some degree of device independence it does not allow for the  removal
> of  stylistic  concerns  from  the  application.   For example, where one user
> interface style guide may call for a pull-down menu, another may  call  for  a
> command line interface.
>
>   One  approach  for  addressing the problem of application portability across
> multiple look and feel platforms is the definition  and  implementation  of  a
> method  for  separating  the  application  from  the  user  interface.    This
> separation makes changing the user interface of the system practical. It  also
> makes  it  possible  to  change  user interface toolkits without modifying the
> application software.
>
> User Interface Management Systems
>
>   The term user interface management system (UIMS) was first coined at a  1982
> Workshop  on  Graphical  Input  Interaction Technique (GIIT) [17].  UIMSs are,
> among other things, intended to encourage the separation of a software  system
> into  an  application  portion  and a user interface portion.  The application
> portion of  a  system  implements  the  core  functionality,  while  the  user
> interface portion implements the user interface dialogue.
>
>   UIMSs   provide   facilities   for   defining   both  presentation  and  the
> computer-human dialogue components of a user  interface.    A  UIMS  also  may
> provide  facilities to support prototyping, encourage a design that allows for
> easy  modification  of  the  user  interface,   support   implementation   and
> maintenance   of   the   user   interface,  and  allow  for  the  evolutionary
> incorporation of new user interface technologies.
>
>   Most UIMSs are based on the Seeheim architecture [7] (see Figure 1).    This
> architecture  uses a layered approach similar to the one used in International
> Standards Organization (ISO) Open Systems Interconnection (OSI) standard.  The
> architecture  is intended to encourage the separation of functionality between
> the application and the user interface portions of a  software  system.    The
> three different layers of the architecture provide differing levels of control
> over user input and system output.
>
>         Application Layer
>
>         Dialogue Layer
>
>         Presentation Layer
>
>                         Figure 1:   UIMS Architecture
>
>   The application layer consists of the core functionality of the  application
> that can be described in a presentation independent manner.  For example, in a
> calculator program this would include the underlying math subroutines library.
>
>   The dialogue layer  specifies  the  presentation  dependent  portion  of  an
> application  system including the dynamic behavior of the user interface.  The
> dialogue should allow the display and removal of interaction  objects  without
> application  involvement and support cascading menus, direct manipulation, and
> other user interface sytles and techniques.  The dialogue provides the mapping
> between  the presentation and application layers.  The user interface dialogue
> may be specified using a user interface definition language (UIDL)  or  by  an
> interactive technique.
>
>   The  presentation  layer  controls  the  end-user interactions and generates
> low-level feedback.  The  presentation  layer  consists  of  a  collection  of
> interaction objects defined for a given user interface technology.
>
> Existing Approaches
>
>   Since  the  1982 GIIT Workshop, there have been a number of efforts to build
> UIMSs that achieve the goal of  separation  of  concerns,  while  remaining  a
> practical   approach  to  software  development.    These  systems  have  been
> classified by the model used in dialogue specification.    Some  of  the  more
> successful  approaches have been:  event-driven, declarative, object-oriented,
> data-driven, and interactive layout systems.
>
>   In the event-driven approach, inputs are  considered  as  events  which  are
> immediately  handled  by  event  handlers.    Event  handlers can cause output
> events, change  the  internal  state  of  the  system,  and  call  application
> routines.   Examples of event-driven systems include the University of Alberta
> UIMS [6], ALGAE [5], Sassafras [9], and the TeleUSE UIMS [16].
>
>   Another approach is the use of declarative languages  in  which  constraints
> are  defined in order to specify what the system should do rather than specify
> how it should be done.  An example of a system that  takes  this  approach  is
> Cousin [8].  In this category, there is a class of systems which automatically
> generate the user interface based on a definition  of  the  semantic  commands
> supported by the application. Examples are the UofA* UIMS [12] and MIKE [10].
>
>   An  object-oriented  approach  uses  objects for defining user interactions,
> transforming data and interacting with the application.  A good example  of  a
> commercially  available  system  that uses an object-oriented approach is Open
> Dialogue [1] developed by Apollo Computer.
>
>   In the data-driven approach, the application communicates with the  UIMS  in
> terms  of  shared  data elements.  The UIMS behaves like an active database in
> that it provides a mapping between application data and user interface toolkit
> objects, and notifies the application of changes to application data resulting
> from user interactions.  This approach was implemented  in  the  Serpent  UIMS
>  [2]  developed  at  the  Software  Engineering  Institute  at Carnegie Mellon
> University and the George Washington UIMS [11].
>
>   Interactive layout systems allow the user to build user interface by  direct
> manipulation.    Examples are Menulay [3], DialogEditor [4], vu [13], and TAE+
>  [15].
>
> UIMS Study Group
>
>   The IEEE P1201 working group was formed in January of 1989 and chartered  to
> develop standards that would further application and user portability in the X
> Windows Environment [14].  Since P1201 was formed,  Open  Software  Foundation
> (OSF), Sun and AT&T have independently developed toolkits for X Windows.  Much
> of the P1201 effort has been spent trying to decide if any of  these  toolkits
> can  serve as a basis for a standard or if a "virtual" toolkit approach can be
> used.
>
>   In August of 1989, a UIMS study group was begun in  P1201  to  determine  if
> UIMS  technology was sufficiently advanced to solve the problem of application
> portability across multiple look and feel platforms and to define the scope of
> a UIMS standard.
>
>   The   group   identified  two  components  where  standardization  would  be
> beneficial to the industry.  The first of these is an application  programmers
> interface (API) that would:
>
>    1. Provide a standard application programmers interface across changes
>       in the underlying toolkit.
>
>    2. Support  the  separation  of  an  application   into   presentation
>       independent  and presentation dependent layers corresponding to the
>       application, dialogue,  and  presentation  layers  of  the  Seeheim
>       architecture.
>
>    3. Allow   the  development  of  applications  that  are  presentation
>       independent  (i.e.,  the  underlying  windowing  system   or   user
>       interface toolkit).
>
>   The  second  component is a UIMS interchange format (UIF).  The purpose of a
> standard UIF is:
>
>    1. To enable a wide variety of UIMSs to use a single format  to  store
>       and exchange their data.
>
>    2. To  allow  vendors  to develop compilers or interpreters that could
>       "execute" the UIF on their  platforms  in  a  manner  analogous  to
>       postscript printers.
>
>   The  P1201  UIMS  study  group  has  evaluated  a  number  of user interface
> management systems including Serpent, TeleUSE, and TAE+.  The concensus of the
> group  is that the state of the practice is sufficiently advanced to warrant a
> standards effort.  It is believed that a  UIMS  standard  would  enhance  both
> application  portability  and  the  state  of  the  practice in user interface
> development.
>
>                                   REFERENCES
>
>
> [1]   Apollo Inc.
>       Open Dialogue:  Designing Portable, Extensible User Interfaces.
>       1987
>
>
> [2]   Bass, L.J., et al.
>       Serpent:  A User Interface Environment.
>       In Proceedings, Winter 1990 USENIX Technical Conference.  Washington,
>          D.C., January, 1990.
>
>
> [3]   Buxton, W., Lamb, M.R., Sherman D., Smith, K.C.
>       Towards a Comprehensive User Interface Management System.
>       In Computer Graphics: SIGGRAPH'83 Conference Proceedings, pages 35-42.
>          Detroit, MI., July, 1987.
>
>
> [4]   Cardelli, L.
>       Building User Interfaces By Direct Manipulation.
>       In Proceedings, ACM SIGGRAPH Symposium on User Interface Software, pages
>          152-166.  ACM, New York, NY, 1988.
>
>
> [5]   Flecchia, M.A. and Bergeron, R.D.
>       Specifying Complex Dialogs in ALGAE.
>       In Proceedings SIGCHI+GI'87: Human Factors in Computing Systems, pages
>          229-234.  Toronto, Ont., Canada, April, 1987.
>
>
> [6]   Green, M.
>       A Survey of Three Dialogue Models.
>       ACM Transactions on Graphics 5(3):244-275, July, 1986.
>
>
> [7]   Green, M.
>       Report on Dialogue Specification Tools.
>       User Interface Management Systems :9-20, 1985.
>
>
> [8]   Hayes, P.J., Szekely, P.A., Lerner, R.A.
>       Design Alternatives for User Interface Management Systems Based on
>          Experience with COUSIN.
>       In Proceedings SIGCHI'85: Human Factors in Computing Systems, pages
>          169-175.  San Francisco, CA, April, 1985.
>
>
> [9]   Hill, R.D.
>       Event-Response Systems -- A Technique for Specifying Multi-Threaded
>          Dialogues.
>       In Proceedings SIGCHI+GI'87: Human Factors in Computing Systems, pages
>          241-248.  Toronto, Ont., Canada, April, 1987.
>
>
> [10]  Olsen, D.R.
>       The Menu Interaction Kontrol Environment.
>       ACM Transactions on Graphics 5(3):318-344, 1986.
>
>
> [11]  Sibert, J.L.
>       An Object-Oriented User Interface Management System.
>       In Computer Graphics: SIGGRAPH'86 Conference Proceedings, pages 259-268.
>          Dallas, Texas, August, 1986.
>
>
> [12]  Singh, G. and Green. M.
>       A High Level User Interface Management System.
>       In Proceedings SIGCHI'89:  Human Factors in Computing Systems, pages
>          133-138.  ACM, New York, NY, 1989.
>
>
> [13]  Singh, G. and Green. M.
>       Designing the Interface Designer's Interface.
>       In Proceedings, ACM SIGGRAPH Symposium on User Interface Software, pages
>          109-116.  ACM, New York, NY, 1988.
>
>
> [14]  Mehta, S.
>       User Interfaces and the IEEE P1201 Committee.
>       Unix Review 8(1):14-20, January, 1990.
>
>
> [15]  Szczur, L. and Miller, P.
>       Transportable Applications Enviroment (TAE)+:  Experiences in
>          Objectively Modernizing a User Interface Environment.
>       In OOPSLA'88 Conference Proceedings, pages 58-70.  San Diego, CA,
>          November, 1988.
>
>
> [16]  TeleLOGIC.
>       TeleUSE Reference Manual.
>       1989
>
>
> [17]  Thomas, J.J. and Hamlin, G.
>       Graphical Input Interaction Technique (GIIT) Workshop Summary.
>       Computer Graphics 17(1):5-30, January, 1983.
>
>
> Volume-Number: Volume 21, Number 179