SFDC 1018
`SFDC 1018
`
`
`
`
`
`
`
`
`
`

`
`Retrospective and Challenges for
`Model-Based Interface Development
`
`Pedro Szekely
`Information Sciences Institute, University of Southern California, 4676 Admi-
`ralty Way, Marina del Rey, CA 90292, USA
`Phone: +1-310-822-1511 (ext. 641) - Fax : +1-310-823-6714
`E-mail : szekely@isi.edu
`WWW: http://www.isi.edu/isd/szekely.html
`
`Abstract
`
`Research on model-based user interface development tools is about 10 years old.
`Many approaches and prototype systems have been investigated in universities and
`research laboratories around the world. This paper proposes a generic architecture
`for these tools, reviews the different approaches in light of this architecture, and
`discusses their progress towards the goals of increasing the quality and reducing the
`cost of developing interfaces. The paper closes with a discussion of challenges for
`future model-based development tools.
`
`Keywords
`
`Model-based interface development, automatic user interface generation, user in-
`terface design.
`
`Introduction
`
`Model-based user interface development tools trace their roots to work on user in-
`terface management systems (UIMS) done in the early 1980’s [Myers95]. UIMSs
`seeked to provide an alternative paradigm for constructing interfaces. Rather than
`programming an interface using a toolkit library, developers would write a specifi-
`cation of the interface in a specialised, high-level specification language. This speci-
`fication would be automatically translated into an executable program, or inter-
`preted at run-time to generate the appropriate interface.
`Many early UIMSs focused on dialogue specification [Green86]. They used state
`transition diagrams [Jacob86], grammars [Olsen83, Olsen86] or event-based repre-
`sentations [Singh91] to specify the interface responses to events coming from the
`input devices. The display aspects of the interface were typically specified outside
`the specification language, in call-back procedures that painted the screen as ap-
`propriate.
`
`SFDC 1018
`
`

`
`xxii
`
`Computer-Aided Design of User Interfaces
`
`Some UIMSs used as their main specification the type and procedure declarations
`that defined the functional aspects of the application [Beshers89, Olsen89]. Based
`on this information, they generated menus to invoke the procedures, and dialogue
`boxes to prompt users for the information needed to construct instances of the
`types.
`Through the late 1980’s and early 90’s the specification languages became more
`sophisticated, supporting richer and more detailed representations that allowed the
`systems to generate more sophisticated interfaces.
`Today’s systems use specifications of the tasks that users need to perform, data
`models that capture the structure and relationships of the information that applica-
`tions manipulate, specifications of the presentation and dialogue, user models, etc.
`The term model-based interface development tools refers to interface construction tools
`that use these rich representations to provide assistance in the interface develop-
`ment process. Tools range from automatic interface generation systems, generators
`of help systems for applications, interface evaluation tools, advisors, etc.
`Even though model-based interface development tools are much more sophisti-
`cated than early UIMSs, they have not become popular in the commercial sector.
`Most software developers use interface builders, toolkits and a programming lan-
`guage to build the interfaces for interactive systems.
`The main goal of this paper is to review the current progress in model-based tools,
`and discuss challenges for the next generation of user interface tools in general, and
`model-based tools in particular. The paper is organised as follows. The next section
`will describe a general architecture of model-based tools that provides a way to
`classify model-based tools according to the components of the architecture that
`they emphasise.
`The sections after analyse the success of model-based work on automatic interface
`generation, high-level specification systems, help generation, and design advisors.
`The last part of the paper discusses new challenges for user interface software, in-
`cluding multi-platform support, intelligent support for the user, multi-modal inter-
`faces and end-user tailoring. The paper closes with conclusions about the future of
`model-based tools.
`
`1 Generic Model-Based Interface Development Architecture
`
`Figure 1 shows the typical components of a Model-Based Interface Development
`Environments (MB-IDE). The rounded rectangles represent tools, the other
`shapes represent information produced or consumed by the various tools. The
`main components of the architecture are the modelling tools, the model, the automated
`
`

`
`
`
`Retrospective and Challenges for Model-Based Interface Development
`
`xxiii
`
`Modeling Tools
`Modeling Tool
`Modeling Tool
`
`Model
`
`Task, Domain
`Models
`
`Abstract UI
`Specification
`
`Concrete UI
`Specification
`
`Developer
`
`Design Critics
`Design Advisors
`
`Design
`Knowledge
`
`Guidelines
`
`Automated Design
`Abstract
`Design Tool
`
`Concrete
`Design Tool
`
`Implementation
`Tool
`
`Toolkit-Ready
`File
`
`Application
`Code
`
`Compiler/
`Linker
`
`Runtime
`System
`
`Delivered
`Application
`Figure 1. Model-Based Interface Development Process
`
`
`
`design tools, and the implementation tools. Developers1 use the modelling tools to build
`the model. The automated design tools are used to perform certain design activities
`that developers either choose or are forced to delegate to the system. The imple-
`mentation tool transforms the model into an executable representation that is
`linked with application code, and delivered to the end-users. The following subsec-
`tions discuss these components in more detail.
`
`1.1 Model
`The model is the main component of the system. The model typically organises in-
`formation into three levels of abstraction. At the highest level are the task and do-
`main model for the application. The task model represents the tasks that users
`need to perform with the application, and the domain model represents the data
`and operations that the application supports. Tasks models typically represent tasks
`by hierarchically decomposing each task into sub-tasks (steps), until the leaf tasks
`represent operations supplied by the application.
`
`
`1 This paper uses the term developer to refer to all the people involved in constructing an interactive
`application. When appropriate, the more specific terms such as task analyst, graphic designer, pro-
`grammer, etc. will be used.
`
`

`
`xxiv
`
`Computer-Aided Design of User Interfaces
`
`The second level of the model, called in this paper the abstract user interface specifica-
`tion, represents the structure and content of the interface in terms of two abstrac-
`tions, Abstract Interaction Objects (AIO), information elements and presentation units. AIOs
`are low-level interface tasks such as selecting one element from a set, or showing a
`presentation unit. Information elements represent data to be shown, either a con-
`stant value such as a label, or a set of objects and attributes drawn from the domain
`model. Presentation units are an abstraction of windows. They specify a collection
`of AIOs and information elements that should be presented to users as a unit. In
`summary, the abstract user interface specification specifies in an abstract way the
`information that will be shown in each window, and the dialogue to interact with
`the information.
`The third level of the model, called the concrete user interface specification, specifies the
`style for rendering the presentation units, and the AIOs and information elements
`they contain. The concrete specification represents the interface in terms of toolkit
`primitives such as windows, buttons, menus, check-boxes, radio-buttons, and
`graphical primitives such as lines, images, text, etc. In addition, the concrete speci-
`fication specifies the layout of all the elements of a window.
`The models of different MB-IDEs can differ substantially. Different MB-IDEs
`typically provide different modelling languages for specifying the contents of the
`model, and they also emphasise different levels of the model. For example, MAS-
`TERMIND [Szekely95] requires developers to explicitly specify all levels of the
`model, whereas JANUS [Balzert96] only requires a data model.
`
`1.2 Modelling Tools
`The modelling tools assist developers in building the models. The main goal of the
`modelling tools is to hide from developers the syntax of the modelling languages,
`and provide a convenient interface for developers to specify the often large quanti-
`ties of information that are stored in the model. A wide range of modelling tools
`have been developed, often specialised to the different levels of the model. These
`tools range from text editors to build textual specifications of models (ITS
`[Wiecha89, Wiecha90], MASTERMIND), forms-based tools to create and edit model
`elements (MECANO [Puerta96b]) and specialised graphical editors (HUMANOID
`[Luo93, Szekely92, Szekely93], FUSE [Lonczewski96], many others).
`
`1.3 Design Critics and Advisors
`Design critics are tools to evaluate designs. The model-based approach provides an
`excellent platform for constructing analytic design critics because models contain a
`rich representation of interface designs that these tools can analyse. Most design
`critics work with the concrete user interface specification layer of the model be-
`cause in most cases they provide evaluations about detailed features of the interface
`(e.g., whether the interface provides a way to access all application functionality).
`
`

`
`
`
`Retrospective and Challenges for Model-Based Interface Development
`
`xxv
`
`Design advisors are tools that suggest how to refine the abstract layers of the
`model into more concrete ones. Design advisors use a knowledge-base of design
`knowledge, typically represented as rules. The condition part of the rules identifies
`some aspect of a design (e.g., an AIO), and the action part of the rule specifies a
`way of refining/transforming the matched design element (e.g., the CIO to use for
`an AIO).
`
`1.4 Automated Design Tools
`Many MB-IDEs allow developers to only specify certain aspects of a model. These
`MB-IDEs feature automated design tools that compute the missing elements of the
`model from the information that developers do provide. For example, JANUS
`[Balzert96] only requires developers to supply a domain model, and it features an
`automated design tool that automatically constructs both the abstract and concrete
`specifications of the interface.
`In contrast ITS and MASTERMIND [Szekely95] require developers to explicitly spec-
`ify all levels of the model, so these systems do not offer automated design tools.
`What they do offer is the capability to re-use specifications. The following section
`discusses automated design tools in detail.
`As shown in figure 1, automated design tools often use a repository of design
`knowledge or design guidelines that control the behaviour of the design tool. In
`most systems developers are not expected to modify the design knowledge, which
`is typically specified by user interface specialists and the architects of the MB-IDE2.
`
`1.5 Implementation Tools
`The implementation tool translates the concrete specification of the interface into a
`representation that can be used directly by a toolkit or interface builder. There are
`essentially three kinds of implementation tools. Source-code generators (e.g., Mas-
`termind) generate source code in a programming language, typically C++. UIMS
`generators (e.g., FUSE) generate a file that can be read by an existing UIMS or in-
`terface builder. Interpreters (e.g., ITS and HUMANOID) do not generate an “imple-
`mentation file”, but rather interpret the model directly at runtime.
`The last step in the interface generation process is to link the toolkit-ready-file with
`application specific code and a runtime library. This is typically done using the
`compiler and linker for the programming language used to implement the applica-
`tion. Interpreter-based systems such as ITS do not use the compiler and linker, but
`rather feature a runtime module that reads the models during runtime, and inter-
`prets the concrete specification of the interface.
`
`
`2 ITS can be viewed as an automated design tool where developers have to explicitly build the design
`knowledge for each application or family of applications.
`
`

`
`xxvi
`
`Computer-Aided Design of User Interfaces
`
`Many MB-IDEs provide implementation tools that use the model to generate more
`than the user interface. For example, JANUS, FUSE, UIDE [Foley91, Foley94] and
`HUMANOID can generate significant parts of the help system for an application
`based on the information contained in the model. Janus not only generates the in-
`terface, but also generates the database schemas for an application, and much of
`the data management code. Mastermind generates code for applications that allows
`other processes to connect to an application, and to request to be notified when
`certain tasks are completed, to be sent snapshots of the application state, and to
`remotely invoke application tasks. This facility supports the construction of agents
`that can assist users in various ways. This facility was used, for example, to build a
`history agent that keeps a history of all the tasks that the user has completed an al-
`lows users to re-invoke previously completed tasks.
`As interfaces become more sophisticated, and users expect more services from
`their interfaces. The ability to provide such additional run-time services for free is
`one of the most attractive features of the model-based technology.
`
`2 Retrospective
`
`The following sections provide a retrospective of the main user interface design
`and construction problems that have been addressed using the model-based ap-
`proach. These sections discuss the various approaches that have been used, and
`how well they solve the problems.
`The retrospective section is organised into five main topics:
`1. Automatic interface design. This section discusses the main approaches for auto-
`mating interface design and their limitations.
`2. Specification-based MB-IDEs. This section discusses MB-IDEs that do not try to
`automate interface design, but rather give developers convenient languages for
`expressing designs.
`3. Help generation. Many MB-IDEs feature components that automatically generate
`help. This section reviews the different approaches and comments on their suc-
`cess.
`4. Modelling Tools. This section discusses various approaches to modelling tools.
`5. Design critics and advisors. This section presents a categorisation of these tools and
`discusses their relative benefits.
`Note. For each topic one or two tools are discussed in some detail. The chosen
`tools are not necessarily the best tools according to some metric, but rather illus-
`trate a point well, and detailed papers have been published about them. The goal of
`this paper is to review the main approaches, not the individual tools.
`
`2.1 Retrospective – Automatic Interface Design
`The primary goal of many MB-IDEs is to automate as much as possible the design
`and implementation of a user interface. These MB-IDEs emphasise the domain
`
`

`
`
`
`Retrospective and Challenges for Model-Based Interface Development
`
`xxvii
`
`and task models, and automatically generate the abstract and concrete user inter-
`face specifications from these models. Most MB-IDE in this category are oriented
`towards database applications and produce interfaces that allow the end-users to
`browse the database, to edit the contents of objects, to define new objects, and to
`delete objects.
`This section argues that automating interface design is intrinsically difficult, so MB-
`IDEs should be very selective about the portions of the design that they choose to
`automate.
`
`2.1.1 Structure of Automated Design Tools
`Model Contents. MB-IDEs whose primary goal is to automatically design use
`mainly two kinds of models, a domain model that describes the structure and attrib-
`utes of the information that the application provides, and a task model that describes
`the tasks that users need to perform. For example, tools like JANUS, and early ver-
`sions of MECANO, use only a domain model, whereas tools like TRIDENT [Van-
`derdonckt94a, Vanderdonckt95b], ADEPT [Johnson95, Wilson96], DON [Kim 93]
`and MODEST [Hinrichs96] use primarily a task model, but also have a domain
`model.
`The domain models of the automatic design tools are similar. They describe classes
`of objects, inheritance between classes, the attributes of each class together with
`their types and cardinality, and relationships between objects. In addition, the
`models typically allow the inclusion of user interface specific information. For ex-
`ample the model of object attributes often includes facets to indicate whether the
`attribute should be shown to the user, an ergonomic name, and other information
`to influence the choice of abstract interaction object to be used to specify the at-
`tribute.
`The task models of these tools are also similar. Tasks are usually decomposed hier-
`archically, and information is included to specify the sequencing between the tasks
`(e.g., and, or, xor, parallel). Often, the task model includes references to the do-
`main objects needed and produced in each task. The task model is used during
`automatic generation to determine the interface dialogue and to determine the in-
`formation that should be shown in each window.
`MB-IDEs in this category typically do not require developers to specify either the
`abstract or concrete specifications of the interface.
`Design Process. Most automated design MB-IDEs use the following sequence of
`steps to automatically design an interface:
`1. Determine the presentation units. This step essentially determines the windows that
`will be used, and what information will be shown in each window.
`2. Determine the navigation between presentation units. This step computes a graph of
`presentation units that defines which units can be invoked from which other
`units.
`
`

`
`xxviii
`
`Computer-Aided Design of User Interfaces
`
`3. Determine the AIOs for each presentation unit. The abstract interaction objects spec-
`ify the behaviour of each element of a presentation unit in an abstract way (e.g.,
`select one from set).
`4. Map abstract interaction objects into concrete interaction objects. The concrete interaction
`objects represent the widgets available in the target toolkit.
`5. Determine the window layout. This steps determines the size and position of each
`concrete interaction object.
`The first three steps build the abstract user interface specification, and the last two
`build the concrete specification.
`Post Editing. Once the concrete specification is built, and the implementation
`tool generates the “toolkit-ready” file, the developer has the opportunity to use and
`interface builder beautify the layout, change fonts, colours, add decorations, and
`perform other cosmetic enhancements.
`
`2.1.2 Difficulties With Automated Design
`
`Even though automatic design MB-IDEs can produce interfaces with little or no
`development effort, there is concern about the quality of the generated interfaces.
`There is substantial evidence to indicate that it is not feasible to produce good
`quality interfaces for even moderately complex applications from just a data and
`task models (together with simple annotations of the data model, such as flags that
`indicate whether object attributes are relevant to the user interface).
`The chapters by Morten Harning [Harning96] and by Stephanie Wilson and Peter
`Johnson [Wilson96] describe critical decisions that must be made in the design of
`an interface, which the automated design tools cannot currently make appropri-
`ately, and which do not seem feasible to automate.
`Harning’s paper contains an excellent example that illustrates the difficulty of
`automating steps 1 and 3. Harning’s example is about a project management appli-
`cation where users want an interface to monitor progress in the various activities
`involved in a project. In this application there are four classes of objects repre-
`sented in the data model: Employee, Project, Activity, Weekly Estimate, and Time
`Entry. Harning demonstrates using examples that of a good interface must satisfy
`the following properties:
`(cid:120) Users need windows that show information drawn from multiple objects. In the project
`monitoring example, the project display is based mostly on the Project object,
`but also shows attributes of the Employee and Activity objects. Furthermore,
`the example shows that the choice of attributes is task-dependent, and required
`developers to have a deep understanding of the user’s tasks. This means that
`step 1 of the abstract design tool is hard, if not impossible to automate.
`This property is achieved in the interfaces generated using Trident. The Trident
`task model captures the information needed for each task, and the generation
`algorithm calculates how the information flows between tasks in order to de-
`
`

`
`
`
`Retrospective and Challenges for Model-Based Interface Development
`
`xxix
`
`
`
`termine what information to show in each presentation unit, and where to
`place it. Systems like Janus, which only use the data model do not satisfy this
`property.
`(cid:120) Users do not want the raw information, but rather they need the information to be re-
`structured and summarised. In the project monitoring example, users want a
`weekly report display that essentially combines the Activity and Weekly Esti-
`mate objects on a weekly calendar display that shows how much effort was
`spent on each activity during a specific week. Re-structuring and summarisa-
`tion cannot be done without a deep understanding of the user’s tasks, and
`again points to the difficulty of automating step 1.
`Another restructuring problem is that users want to see the names of people in
`the Project Leader field as “name (initials)”. This means that rather than using
`two AIOs to present two different attributes, a single one should be used to
`present a combination of two attributes. This simple example suggests that the
`assignment of object attributes to AIOs (step 3) is also a hard problem.
`(cid:120) Graphical displays are often more effective than tables and forms. Harning’s paper has an
`example of a graphical display that uses a plot with two curves to show how
`much time has cumulatively been spent on a project compared to the estimate
`of the time remaining to complete the project. This example shows that the set
`of AIOs need to be expanded to include more sophisticated elements such as
`plots. Of course, then the problem is how to select the appropriate one (step
`3), how to set all its parameters, and then how to map it to concrete interaction
`objects (step 4).
`There are two main approaches to automatic design, one based on task models,
`and the other based on the domain model. The task model approach performs bet-
`ter because task models have some of the information to satisfy the properties
`listed above. The domain model approach does not have access to such informa-
`tion, and can only produce simple interfaces, typically with one object per presenta-
`tion unit.
`The requirements listed above point to deep issues of interface design, and raise
`questions about the utility of completely automating the design process, especially
`steps 1 and 3. Even a small amount of developer involvement can have a huge dif-
`ference. A simple calculation reveals the economics of the situation. Most of the
`automatically designed interface force users to bring up several windows to view
`the information they need to perform a task, rather than a single window with all
`the information. Ignoring issues about time to assimilate improperly structured in-
`formation and the error rates that can result, bringing up several windows and clos-
`ing them can easily take 3 additional seconds. If users do this 20 times a day, in a
`year, one full day will be lost per worker. If an organisation has 40 users, 2 man
`months will be lost per year. Surely it is worth to have developers spend several
`weeks working on a design.
`
`

`
`xxx
`
`Computer-Aided Design of User Interfaces
`
`2.1.3 Discussion
`
`The conclusion of this section is that none of the 5 steps should be completely
`automated. Rather, collaboration between developers and tools should be built in
`from the start. Tools should offer suggestions and alternatives. Developers make
`the decisions, accepting suggestions, choosing between alternatives or entering
`their own solutions.
`This means that the abstract and concrete specification layers of the models should
`be available to the developers. The specification languages for these layers must al-
`low developers to control all features of the interface that they want to control, no
`matter how low level. Emphasis should shift from automation to computer aided
`design.
`A simple, and commonly used approach to computerised design aids is the post-
`editing approach. An automated generation tool generates a first draft of the de-
`sign, and then the developer edits the draft to produce the final design. This ap-
`proach has a serious shortcoming, namely that when developers change the model,
`they need to run the generator tool again, and the post-editing changes will be lost.
`The post-editing approach has been used mainly to allow developers to beautify
`layouts. However, many MB-IDEs such as FUSE feature automatic generator of
`higher levels of abstraction, and run the risk of running into the same post-editor
`problems.
`One solution to the post-editing problem is to record the changes performed dur-
`ing post-editing, and to reapply them to the output of the generation tools. This
`approach was used in early versions of MECANO, but it proved difficult to apply
`the changes reliably, especially when new elements were introduced to a design, or
`old elements were deleted.
`A more robust solution requires a deep integration of the computerised advisor
`and the modelling tools. In this approach the advisor tools produce design alterna-
`tives and suggestions that developers can incorporate into an evolving design via
`the modelling tools. There is no batch generation process followed by a refinement
`phase, but rather an incremental evolution of the design, where the computerised
`advisors and the developers incrementally build the design.
`Several MB-IDEs are moving away from automation in the direction of computer-
`ised advisors. For example, the TADEUS [Elwert95, Schlungbaum96] system re-
`quires developers to specify steps 1 and 2 in a structure called a dialogue graph.
`Steps 3 and 4 are table driven. The system builds default tables with default entries,
`but developers can edit these tables and override any entry. Step 5 is done auto-
`matically, but TADEUS supports post-editing of the generated implementation file.
`The FUSE system described in this book also provides a specification language and
`tool (BOSS [Schreiber94b]) that lets developers specify the abstract interface speci-
`fication, and many aspects of the concrete specification. In addition, FUSE provides
`a tool (FLUID [Bauer96]) that uses the task and domain model to produce specifi-
`
`

`
`
`
`Retrospective and Challenges for Model-Based Interface Development
`
`xxxi
`
`cations that can be fed to the BOSS tool to refine and produce an interface. It is
`unclear for the published papers whether and how FUSE avoids the post-editing
`problem.
`TRIDENT is perhaps the most sophisticated and robust system that combines
`automatic generation and computerised advice. TRIDENT developed many differ-
`ent strategies and algorithms for performing each of the 5 steps listed above. For
`example, they developed six strategies for defining presentation units, and have
`tools that can automatically select and apply a strategy based on information con-
`tained in the task and domain model. TRIDENT also offers developers the option
`of choosing a strategy, or performing the step by hand. However, it is unclear from
`the published literature on TRIDENT whether it uses an integrated approach as de-
`scribed above.
`
`2.2 Retrospective – Specification-Based MB-IDEs
`MB-IDEs in this category seek to provide powerful interface specification lan-
`guages. These languages provide effective layering or abstraction mechanisms that
`allow developers to express interface properties at a convenient level of abstraction
`to facilitate reuse and design modifiability. These languages also seek to give devel-
`opers extensive control over all features of the interface, so that developers can ex-
`press any design that they can think of. The goal is not to automate design, but
`rather to make it easy for developers to express designs, change designs, retarget
`designs to new platforms, new classes of users, new tasks, etc.
`MB-IDEs in this category are oriented towards data management applications.
`Most business-oriented applications fall in this category, but many engineering and
`data visualisation applications do not, because they have interfaces whose graphical
`components are too complex to be expressed in their interface specification lan-
`guages.
`
`2.2.1 Structure of Specification-Based MB-IDEs
`
`The structure of specification-based MB-IDEs is also compatible with the architec-
`ture shown in figure 1. They emphasise the model and the implementation tool,
`and typically do not have an automated design tool.
`The modelling language of these MB-IDEs have facilities for developers to express
`models at the three different levels of abstraction shown in figure 1. The models of
`these MB-IDEs typically feature a data model, but not always a task model. The
`data model is used mostly in the implementation tool to generate the binding be-
`tween the interface objects and the application data, so that the interface objects
`can access the application objects to retrieve the pieces of information that will be
`displayed (e.g., access the name field of a person object).
`The modelling languages to specify the abstract and concrete user interface specifi-
`cations are designed to maximise reuse. Even though the goals of the different
`
`

`
`xxxii
`
`Computer-Aided Design of User Interfaces
`
`MB-IDEs in this category are the same, the features of the modelling languages are
`different. For this reason, this section will not attempt to describe these languages
`in general terms, but rather uses the well known ITS system as an example. Other
`MB-IDEs in this category include BOSS, HUMANOID and MASTERMIND.
`
`2.2.2 ITS
`
`The ITS system was developed by IBM research, and was used to construct several
`large applications such as the information kiosks for the Seville world fair, a pur-
`chasing system for a large corporation, an insurance industry application, and many
`others.
`ITS has modelling components corresponding to the three levels of modelling
`shown in figure 1. The domain model is called a data pool, there is no task model,
`the abstract specification is called content specification, and the concrete specification
`is called a style specification.
`The data pool definition language (domain model) supports the specification of
`structured objects and sequences of objects, like the domain model in many other
`MB-IDEs. The following is an example of the data pool specification for an airline
`reservation system.
`
`list listname = flights, numrecords = 10
`field destination, rangename = cities, size = 20
`field departure_time, size = 10
`field departure_date, size = 20
`field airline, rangename = airlines, size = 20
`field number_stops, size = 5
`The content specification (abstract user interface specification) of an interface con-
`sists of a collection of frames. Frames can contain lists, forms, choices, information
`blocks, and nested frames. These elements specify the information that will be pre-
`sented to the user. Top-level frames correspond to presentation units. Lists and
`forms specify which elements of the data pool are to be shown in a frame.
`Information blocks specify static pieces of information to be shown in a frame.
`Choices indicate sets of alternatives that can be chosen by the user, and correspond
`to AIOs. Each element specification can be elaborated using an extensive set of at-
`tributes that specify the interface content in detail.
`The following is a fragment of the content specification for the airline reservation
`example. This frame s