No abstract

Becoming “customer‐centric” is easier said than done. But it can be done.

The ITS architecture separates applications into four layers. The action layer implements back-end application functions. The dialog layer defines the content of the user interface, independent of its style. Content specifies the objects included in each frame of the interface, the flow of control among frames, and what actions are associated with each object. The style rule layer defines the presentation and behavior of a family of interaction techniques. Finally, the style program layer implements primitive toolkit objects that are composed by the rule layer into complete interaction techniques. This paper describes the architecture in detail, compares it with previous User Interface Management Systems and toolkits, and describes how ITS is being used to implement the visitor information system for EXPO '92.

INTRODUCTIONAs application developers today we all face a problem of great complexity. Because of the diversity of our users, and the variety of their equipment, applications must run in many different configurations. They must support displays of varying size, resolution, and color depth. Different types of input devices are required, from keyboards to touch screens. Applications must run in different countries, being able to reformat messages in varying lengths in each language. Messages should be available in large font sizes for vision impaired users. Interface style should be consistent with other applications running on similar hardware. Style should at the same time conform to guidelines being developed by many organizations for presentation and interaction behaviors.Historically, two types of layered architectures have been developed in attempts to provide the required flexibility in applications: User Interface Management Systems (UIMS) and toolkits. UIMS separate the application and its interface. Back end computations are separated from dialog control and style. Style, however, is often treated in a single interface layer. Toolkits separate style from the application. Dialog control remains in the back end while the implementation of interaction techniques is hidden in a code library.ITS is a four Iayer architecture with separate tools for back end computation, dialog control, rule-based interface style, and the implementation of graphic primitives used in the style [Bennett 891. Recent work has focused particularly on the rule layer. We begin by reviewing previous work in UIMS and toolkits. Then we show how the rule layer in ITS combines the benefits of both UIMS and toolkits. ITS is being used to implement the visitor information system for EXPO 1992 in Seville. We conclude by describing what we have learned from EXPO 92 and from other applications. $1.50ers. An application layer implements the underlying computations while an interface layer implements the details of interface presentation and interaction. According to the traditional Sceheim [Pfaff 851 architecture, the interface layer defines the connection to the application, dialog flow of control, and presentation style, The application layer is structured as a set of callback routines executed in response to user actions or external interrupts.The goals of separating the application from its interface are well documented [Hayes 85, Hartson 891 and include reusing a given application in multiple interfaces, consistency among a family of interfaces that run using a common interface, and independent tools for application and interface developers. We believe previous UIMS have had limited success in meeting these goals because of two problems: they have not suffi-cientIy decomposed the interface layer, and they have provided inadequate tools for interface designers.The Seeheim model calls for separate dialog control and presentation components in the interface layer. Much of the previous work on UIMS has focused on the dialog component. Less atten...

Developers of User Interface Management Systems (UIMS) have demonstrated that separating the application from its user interface supports device independence and customization. Interfaces produced in UIMS are typically crafted by designers expert in human factors and graphic arts. Little attention has been paid, however, to capturing the knowledge of such experts so that interfaces might be automatically generated by the application of style rules to additional applications. This paper considers how toolkits and style rules can be structured so that the resulting interfaces take advantage of the best human factors and graphic arts knowledge, and are consistently styled.