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


Search Results


Search results for predictability
Showing 11 to 19 of 19 [<< prev] [new search]


Chapter 9 Models of the system 9.3 Interaction models Page 354

The particular model we will describe, the PIE model, was designed to attack WYSIWYG-like properties. It would be nice to say that after reading this section, you will know exactly what WYSIWYG means. Unfortunately, it is too wide and varied a term to be formalized. However, we will describe several principles from Chapter 4, more limited in scope, which can be formalized. Of these some cover areas within the general area of WYSIWYG, namely observability -- what you can tell about the current state of the system from the display -- and predictability -- what you can tell about its future behaviour. In addition, we will define principles concerning the control of the system by the user, such as reachability -- you can get anywhere from anywhere -- and undo -- the ability to perform backwards error recovery.


Chapter 9 Models of the system 9.3.1 The PIE model Page 355

For a formal statement of predictability it helps (but is not essential) to talk about the internal state of the system. This does not counter our claim to have a black-box model. First, the state we define will be opaque; we will not look at its structure, merely postulate it is there. Secondly, the state we will be discussing is not the actual state of the system, but an idealization of it. It will be the minimal state required to account for the future external behaviour. We will call this the effect (E). Functions display and result obtain the current outputs from this minimal state:


Chapter 9 Models of the system 9.3.2 Predictability and observability Page 357

9.3.2 Predictability and observability


Chapter 9 Models of the system 9.3.2 Predictability and observability Page 357

A related issue is predictability. Imagine you have been using a drawing package and in the middle you get thirsty and go to get a cup of tea. On returning, you are faced with the screen -- do you know what to do next? If there are two shapes one on top of the other, the graphics package may interpret mouse clicks as operating on the 'top' shape. However, there may be no visual indication of which is topmost. The screen image does not tell you what the effect of your actions will be; you need to remember how you got there, your command history. This has been called the 'gone away for a cup of tea problem'. In fact, the state of the system determines the effects of any future commands, so if we have a system which is observable in the sense that the display determines the state, it is also predictable. Predictability is a special case of observability.


Chapter 9 Models of the system 9.3.2 Predictability and observability Page 359

This is as far as this bit of the formal story goes in this book. However, there are more sophisticated principles of observability and predictability which take into account aspects of user attention, and issues like keyboard buffers. Formalisms such as the PIE model have been used to portray other usability principles discussed in Chapter 4. Principles of predictability do not stand on their own; even if you had known what was bound to the function key, you might still have hit it by accident, or simply forgotten. Other protective principles like commensurate effort need to be applied. Also, although it is difficult to formalize completely, one prefers a system which behaves in most respects like the transparency principles, rather than requiring complicated searching to discover information. This is a sort of commensurate effort for observation.


Chapter 9 Models of the system 9.3.3 Reachability and undo Page 362

Unlike the predictability principles, there are no awkward caveats. The only problem is that, if anything, it is too weak. For instance, a word processor could have a delete key, but no way to move the cursor about, so you always type at the end of the document. Now you can, of course, get from any document state to any other, you simply delete the whole text and retype what you want. However, if you had just typed in a whole letter and then noticed a mistake on the first line, you would not be pleased! So, ideally one wants an independent idea of 'distance' between states and to make the difficulty of the path between them commensurate with the distance -- small changes should be easy. Despite this, the principle on its own would have been strong enough to prevent the behaviour of the debugger!


Chapter 9 Models of the system 9.3.4 Other interaction models Page 363

Non-determinism If you are ignorant of certain information in a system, it may appear to behave non-deterministically. Many properties of different models, for example the predictability of PIEs, map onto problems of non-determinism. Methods of handling this non-determinism from one domain can then suggest similar methods in what would otherwise appear disparate areas. The fact that supposedly deterministic interfaces often appear random suggests that, where it is helpful for other purposes, the interface can be made deliberately non-deterministic.


Chapter 9 Models of the system 9.5 Summary Page 374

In Section 9.3 we considered interaction models, in particular the PIE model. This type of model addresses classes of system rather than specific designs, allowing us to describe general properties such as predictability (the 'gone away for cup of tea problem'), observability (what can we tell about the state of the system from its display?) and reachability (whether there are any dead ends from which we can never return). We looked at the issue of undo and how the PIE model allowed us to discover that the apparently obvious meaning of undo was in fact inconsistent! As well as the very general PIE model, more specific interaction models address issues such as timing properties and user attention.


Chapter 10 Implementation support 10.4 Using toolkits Page 394

predictability The value of a scrolling mechanism lies in the user being able to know where a particular scrolling action will lead in the document. The use of arrows on the scrollbar is to help the user predict the effect of the scrolling operation. If an arrow points up, the question is whether that indicates the direction the window is being moved (the first case) or the direction the actual text would have to move (the second case). The empirical question here is: to what object do users associate the arrow -- the text or the text window? The arrow of the scrollbar is more closely connected to the boundary of a text window, so the more usual interpretation would be to have it indicate the direction of the window movement.


Search results for predictability
Showing 11 to 19 of 19 [<< prev] [new search]

processed in 0.005 seconds


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