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

Search Results

Search results for toolkit
Showing 31 to 40 of 44 [<< prev] [next >>] [new search]

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

The basic behaviour of models, views and controllers has been embodied in general Smalltalk object classes which can be inherited by instances and suitably modified. Smalltalk, like many other window toolkits, prescribes its own look and feel on input and output, so the generic view and controller classes (called View and Controller, respectively) do not need much modification after instantiation. Models, on the other hand, are very general because they must be used to portray any possible application semantics. A single model can be associated with several MVC triads, so that the same piece of application semantics can be represented by different input--output techniques. Each view--controller pair is associated to only one model.

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.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 Exercises Page 403

10.2 Recall the state transition diagram for font characteristics presented in Chapter 8 (Section 8.3.3). Compare different interaction objects which could implement this kind of dialog. Use examples from existing toolkits (pull-down menus or dialog boxes) or create a novel interaction object.

Chapter 11 Evaluation techniques Automatic protocol analysis tools Page 430

A third example is DRUM [148] which also provides video annotation and tagging facilities. DRUM is part of the MUSiC (Measuring the Usability of Systems in Context/Metrics for Usability Standards in Computing) toolkit which supports a complete methodology for evaluation, based upon the application of usability metrics on analytic metrics, cognitive workload, performance and user satisfaction. DRUM is concerned particularly with measuring performance. The methodology provides a range of tools as well as DRUM, including manuals, questionnaires, analysis software and databases.

Chapter 13 Groupware Overview Page 463

Implementing groupware is more difficult than single-user applications:

-- because of network delays

-- because there are so many components to go wrong

-- because graphical toolkits assume a single user.

Chapter 13 Groupware 13.5.2 Shared editors Page 484

These problems are precisely why the principle of WYSIWIS ('what you see is what I see') is used in meeting rooms. Even minor differences between displays, such as lags between the appearance of one participant's typing on the others' screens, can cause severe problems -- no wonder different views cause trouble. Of course, WYSIWIS is not always appropriate, for example if we want to edit different parts of a document. Neither is it a solution to all problems. For example, if two people try to scroll the shared view at the same time, we have scroll wars. People find this conflict harder to resolve than typing clashes. This is probably because scrolling is a less direct and less predictable action anyway, and thus it is more difficult to diagnose what is going wrong. This suggests that better locking of scrollbars and visual clues are required. As we will discuss later (Section 13.7) graphics toolkits do not make such modifications easy.

Chapter 13 Groupware 13.7 Implementing synchronous groupware Page 496

We have discussed a wide range of groupware systems, but there are formidable problems with implementing such systems, particularly synchronous groupware. Groupware systems are intrinsically more complicated than single-user systems. Issues like handling updates from several users whilst not getting internal data structures or the users' screens in a mess are just plain difficult. These are made more complicated by the limited bandwidth and delays of the networks used to connect the computers, and by the single-user assumptions built into graphics toolkits.

Chapter 13 Groupware 13.7.5 Graphical toolkits Page 501

13.7.5 Graphical toolkits

Chapter 13 Groupware 13.7.5 Graphical toolkits Page 501

We discussed in Chapter 10 some of the widgets one finds in a typical graphics toolkit or window manager, such as menus, buttons, dialog boxes and text and graphics regions. These are useful for creating single-user interfaces, and one would like to use the same components to build a groupware system. Unfortunately, the single-user assumptions built into such toolkits can make this very difficult.

processed in 0.003 seconds