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


Search Results


Search results for uims
Showing 1 to 10 of 19 [next >>] [new search]


Chapter 5 The design process High-level programming support Page 211

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.


Chapter 8 Dialog notations and design 8.4.2 Production rules Page 314

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


Chapter 8 Dialog notations and design 8.4.2 Production rules Page 318

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.


Chapter 8 Dialog notations and design 8.5.5 Maximizing syntactic description Page 329

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):


Chapter 10 Implementation support 10.1 Introduction Page 378

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.


Chapter 10 Implementation support 10.5 User interface management systems Page 395

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:


Chapter 10 Implementation support 10.5 User interface management systems Page 395

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.


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

10.5.1 UIMS as a conceptual architecture


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

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.


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

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


Search results for uims
Showing 1 to 10 of 19 [next >>] [new search]

processed in 0.004 seconds


feedback to feedback@hcibook.com hosted by hiraeth mixed media