Communication Between Interface and Application

Two common models exist for supporting communications between an interactive system’s interface and its application. These are linguistic dialogue and shared state (Dix 1998). A linguistic dialog is a formal language that converts user-generated events, such as mouse button press actions, into requests for application services. Conversely it converts application-generated events into user interface actions. The linguistic approach to interface-application communication is demonstrated by the Seeheim model (see Figure 4.1), an idealized architecture which was proposed by the Seeheim Workshop (Pfaff 1985). The Seehiem architecture effectively partitions an interactive system into three distinct components:

! Presentation component

This component controls the appearance of the interface as well as promoting services available to the user through the interface. It interfaces to the input devices, transforming signals generated

! Dialogue control component

This component serves to regulate the communication that takes place between the presentation component and the application component. It effectively defines the structure of the dialogue that takes place between the user and the application. User inputs are passed to the dialogue component by the presentation component as tokens. These user-input events cause the dialogue component to send tokens to the application interface component.

! Application interface component

This component represents the view of application semantics provided by the interface. On receipt of information from the dialogue controller, the application interface component may do one of two things. If the information received is syntactically valid, it is passed on to the application. If it is not syntactically valid data, the application interface informs the dialogue controller of this fact.

It is possible for the application interface to bypass the dialogue control component and communicate with the presentation component directly. This is in order for the application to provide greater semantic feedback about application level structures. This bypass also serves to overcome some of the performance limitations inherent in the model due to the communication overhead produced by token passing between components.

Application User Presentatio n Componen Dialogue Control Componen Applicatio n Interface Componen

Flow of control from application component to presentation

Interactive system implementations based on Seeheim must not only determine how the separate components are to be realized, but also support communication between those components using linguistic dialogue. Examples of systems that reflect the Seeheim model of interaction include the DRUID (Singh 1990) user interface management system (UIMS), which supports communication between interface and application components by the passing of tokens. Also VUIMS (Pittman 1990) which provides inter-object communication via asynchronous message passing. User interface objects in VUIMS can communicate by sending messages, where a message takes the form of a request to the receiving object to call a method, or change some state within in the sending object.

The notion of token passing between components does not scale up to the building of large and complex interactive systems out of small building blocks such as those found in many development toolkits. As is the case with most idealised models of how things should be done, Seeheim addresses the logical concerns of interface-application communication, but not the implementation concerns. This limitation has since been recognised and is the reason for the

bypass, which enables the application to deal with the presentation component directly. When required to do so, usually for reasons of performance, it is possible to switch communication from one mode (dialogue) to the other (direct).

A more suitable paradigm for building systems out of small, preconceived parts is the Model- View-Controller (MVC) (Krasner 1988). This model, illustrated in Figure 4.2, is the model employed by the Smalltalk programming environment. Smalltalk (Goldberg 1983) is built around a library of object-oriented classes, which are inherited by interface object instances and modified to create different interaction techniques. The object classes in Smalltalk incorporate the behaviour of models, views and controllers.

Rather than supporting communication based on linguistic dialog, the MVC maintains the link between application and interface by means of shared state. The model of the MVC represents the

application semantics, and serves as the state shared between application and interface. The view

is similar to the presentation component in the Seeheim model, in that it manages the graphical and textual output of the application. But whereas the presentation component also handles user input, in MVC, a separate entity called the controller is assigned the task of managing input into

the system. The view represents the ‘look’ and the controller the ‘feel’ prescribed within the Smalltalk toolkit. Models are necessarily more general as they are required to represent any

in various MVC relationships (whereas the view-controller can only be associated with one model).

The MVC model uses callbacks to support communication between a view or controller and its

associated model. The presentation component (view or controller) has to register itself with the

application component (model). Communication to and from a model to either a view or controller, or between a view and a controller occurs in use of normal use of method calls used in

object-oriented programming.

The X Window System’s (Scheifler 1986) programming model supports user interface and application linking via callbacks. It is possible to add callbacks to any event that can be generated within the user interface. The callbacks themselves reside within the application code. When a user interface event is generated, the callback invokes a procedure within the application corresponding to that user interface event.

A third model for interface-application communication is presentation-abstraction-control (PAC)

(Coutaz 1987). Shown in Figure 4.3, PAC is a conceptual hybrid of Seeheim and MVC. It has a

presentation component similar to that in the Seeheim model which groups input and output

together. The application semantics reside in the abstraction component, which is equivalent to

MVC’s model. But whereas in MVC the application semantics act as shared state between the input (controller) and output (view) components, in PAC a separate control component is

assigned the task of explicitly managing the dialog between the presentation component and the

Input devices Display User View Model Controller

abstraction component. Neither the Seehiem model nor MVC provide a means of separately managing the dialogue between interface and application.