HUMAN-COMPUTER INTERACTION SECOND EDITION
Dix, Finlay, Abowd and Beale

Search Results

Search results for interfaces
Showing 240 to 249 of 331 [<< prev] [next >>] [new search]

Chapter 10 Implementation support 10.5.1 UIMS as a conceptual architecture Page 397

One of the most ill-understood elements of the Seeheim model is the lower box, the bypass or switch. This is there to allow rapid semantic feedback. Examples of semantic feedback include freehand drawing and the highlighting of the trash bin on the Apple Macintosh when a file is dragged over it. As with all notions of levels in interface design, the definition of semantic feedback is not sharp, but it corresponds to those situations where it is impractical or impossible to use dialog-level abstractions to map application structures to screen representations.

Chapter 10 Implementation support 10.5.2 Implementation considerations Page 399

We have made a point of distinguishing a conceptual architecture from any implementation considerations. It is, however, important to determine how components in a conceptual architecture can be realized. Implementations based on the Seeheim model must determine how the separate components of presentation, dialog controller and application interface are realized. Window systems and tool-kits provide the separation between application and presentation. The use of callback procedures in notification-based programming is one way to implement the application interface as a notifier. In the standard X toolkit, these callbacks are directional as it is the duty of the application to register itself with the notifier. In MVC, callback procedures are also used for communication between a view or controller and its associated model, but this time it is the duty of the presentation (the view or controller) to register itself with the application (the model). Communication from the model to either view or controller, or between a view and a controller, occurs by the normal use of method calls used in object-oriented programming. Neither of these provides a means of separately managing the dialog.

Chapter 10 Implementation support 10.5.2 Implementation considerations Page 400

Grammar notations The dialog between application and presentation can be treated as a grammar of actions and responses, and, therefore, described by means of a formal context-free grammar notation, such as BNF. These are good for describing command-based interfaces, but are not so good for more graphically based interaction techniques. It is also not clear from a formal grammar what directionality is associated to each event in the grammar; that is, whether an event is initiated by the user or by the application. Therefore, it is difficult to model communication of values across the dialog controller, and that is necessary to maintain any semantic feedback from application to presentation.

Chapter 10 Implementation support 10.5.2 Implementation considerations Page 401

Ultimately, the programmer would want access to a variety of these techniques in any one UIMS. For example, the Myers Garnet system combines a declarative constraints language with a graphical specification technique. There is an intriguing trend we should note as we proceed away from internal control of dialog in the application itself to external control in an independent dialog component to presentation control in the graphical specification languages. When the dialog is specified internal to the application, then it must know about presentation issues which make the application less generic. External control is about specifying the dialog independent of the application or presentation. One of the problems with such an independent description is that the intended link between application and presentation is impossible to describe without some information about each, so a good deal of information of each must be represented, which may be both inefficient and cumbersome. Presentation control describes the dialog in the language in terms of the objects the user can see at the interface. Whereas this might provide a simple means of producing a dialog specification and be more amenable to non-programmers, it is also restrictive because the graphical language of a modern workstation is nowhere near as expressive as programming languages.

Chapter 10 Implementation support 10.6 Summary Page 402

In this chapter, we have concentrated on describing the programming support tools which are available for implementing interactive systems. We began with a description of windowing systems, which are the foundation of modern WIMP interfaces. Window systems provide only the crudest level of abstraction for the programmer, allowing her to gain device independence and multiple application control. They do not, however, provide a means of separating the control of presentation and application dialog. We described two paradigms for interactive programming, and saw that these relate to two means of controlling that dialog -- either internal to the application by means of a read--evaluation loop or external to the application by means of notification-based programming. Toolkits used with particular windowing systems add another level of abstraction by combining input and output behaviours to provide the programmer with access to interaction objects from which to build the components of the interactive system. Toolkits are amenable to external dialog control by means of callback procedures within the application. Other dialog control techniques are provided with yet another level of abstraction in interactive system development: user interface management systems. UIMS provide a conceptual architecture for dividing up the relationship between application and presentation, and various techniques were described to implement the logical components of a UIMS. An interesting additional means of dialog control can be seen to emerge in the use of graphical specification languages which move dialog control all the way across the spectrum to reside entirely within the presentation language. This presentation control opens up interactive programming to the non-expert programmer, but at the cost of a loss of expressiveness.

Chapter 10 Implementation support Recommended reading Page 403

L. Bass and J. Coutaz, Developing Software for the User Interface, Addison-Wesley, 1991.

Chapter 10 Implementation support Recommended reading Page 403

B. A. Myers, Creating User Interfaces by Demonstration, Academic Press, 1988.

Chapter 10 Implementation support Recommended reading Page 403

D. Olsen, User Interface Management Systems: Models and Algorithms, Morgan Kaufmann, 1992.

Chapter 10 Implementation support Recommended reading Page 403

D. Hix, Generations of User-Interface Management Systems. IEEE Software, Vol. 7, No. 5, pp. 77--87, September, 1990.

Chapter 10 Implementation support Recommended reading Page 403

B. A. Myers, User-Interface Tools: Introduction and Survey. IEEE Software, Vol. 6, No. 1, pp. 47--61, January, 1989.

processed in 0.009 seconds