HUMAN-COMPUTER INTERACTION
SECOND EDITION
Though not usually considered together with such simulation environments as HyperCard, a user interface management system -- or UIMS (pronounced 'YOU-imz') -- can be understood as providing such high-level programming support. The frequent conceptual model put forth for interactive system design is to separate the application functionality from its presentation. It is then possible to program the underlying functionality of the system and to program the behaviour of the user interface separately. The job of a UIMS, then, is to allow the programmer to connect the behaviour at the interface with the underlying functionality. In Chapter 10 we will discuss in more detail the advantages and disadvantages of such a conceptual model and concentrate on the programming implementation support provided by a UIMS. Of interest here is that the separation implied by a UIMS allows the independent development of the features of the interface apart from the underlying functionality. If the underlying system is already developed, then various prototypes of its interface can be quickly constructed and evaluated to determine the optimal one.
We have already encountered production rules as part of CCT in Chapter 6. They have also been used extensively to describe the dialog component of UIMS (see Chapter 10). Recall that production rules are of the general form
Where production rules are used as the dialog description within a UIMS or other prototyping tool, various extensions to the simple forms described are used. Variables are added to the state to describe numeric values such as the mouse position. We saw this in CCT with the 'binding' of the variables %LINE and %COL. Different precedence rules are used to decide which of several production rules, which could potentially fire, will fire first. This enables help systems and pre-emptive dialog boxes to be programmed. For example, in a word processor, we may give rules for the help system higher priority than those for the normal system. Hence an event, such as a cursor movement, which would normally refer to the movement of the cursor in the document, would instead be 'caught' by the rules for the help system.
Even more problems may arise in production systems, window managers or UIMS with external control, that is where the application is invoked on each event from the user (see Chapter 10). In these systems, the most obvious form of dialog is completely user controlled. If the designer wishes to provide any control over the input syntax then a 'program counter' must be explicitly coded. So, for instance, if we were operating under a window manager that calls a user routine process_event, we might have the following code for text editor selection (written in C):
In the remainder of this chapter, we will address the various layers which constitute the move from the low-level hardware up to the more abstract programming concepts for interaction. We begin in Section 10.2 with the elements of a windowing system, which provide for device independence and resource sharing at the programming level. Programming in a window system frees the programmer from some of the worry about the input and output primitives of the machines the application will run on, and allows her to program the application under the assumption that it will receive a stream of event requests from the window manager. In Section 10.3 we describe the two fundamental ways this stream of events can be processed to link the interface with the application functionality: by means of a read--evaluation control loop internal to the application program or by a centralized notification-based technique external to it. In Section 10.4, we describe the use of toolkits as mechanisms to link input and output at the programming level. In Section 10.5, we discuss the large class of development tools lumped under the categories of user interface management systems, or UIMS, and user interface development systems, UIDS.
The set of programming and design techniques which are supposed to add another level of services for interactive system design beyond the toolkit level are user interface management systems, or UIMS for short. The term UIMS is used quite widely in both industrial and academic circles and has come to represent a variety of topics. The main concerns of a UIMS, for our purposes, are:
We should acknowledge that some people feel that the term UIMS is inappropriate for all of the above tasks, preferring the term user interface development systems, or UIDS, to distinguish support tools which address many of the design activities that precede the management of the run-time system.
In Section 10.3, we described the two basic approaches to programming the application within an interactive system. In the read--evaluation loop, the control of the dialog is internal to the application. The application calls interface procedures when input or output is required. In notification-based programming, the dialog control resides external to the application. When the user performs some input action, the notifier then invokes the correct application procedure to handle the event. Most UIMS fall into this class of external dialog control systems, since they promote, to a greater extent, the separation between presentation and application. They do not, however, all use the technique of callbacks as was demonstrated in Section 10.3 for the use of toolkits.
The first acknowledged instance of a development system that supported this application--presentation separation was in 1968 with Newman's Reaction Handler. The term UIMS was coined by Kasik in 1982 after some preliminary research on how graphical input could be used to broaden the scope of HCI. The first conceptual architecture of what constituted a UIMS was formulated at a workshop in 1985 at Seeheim, Germany [194]. The logical components of a UIMS were identified as
processed in 0.004 seconds
| |
HCI Book 3rd Edition || old HCI 2e home page || search
|
|
feedback to feedback@hcibook.com | hosted by hiraeth mixed media |
|