rcs@sei.cmu.edu (Robert Seacord) (10/03/90)
Submitted-by: rcs@sei.cmu.edu (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 179rja7m@chaos.cs.Virginia.EDU (Ran Atkinson) (10/05/90)
Submitted-by: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson)
Dr. Randy Pausch of the Computer Science Department here at U.Va.
has actually implemented a User-Interface Toolkit named SUIT
(" Simple User Interface Toolkit") that is in fact portable across
diverse platforms including X-Windows, MS-Windows, the Apple Macintosh,
and others. One nice feature is that using SUIT doesn't lock you
into any Look and Feel and the Look and Feel can be changed without
recompiling.
Folks interested in UIMSs might well want to get more information
on SUIT. Sending a request via e-mail to: graphics@cs.virginia.edu
should suffice.
Randall Atkinson
randall@Virginia.EDU
Volume-Number: Volume 21, Number 183