HUMAN-COMPUTER INTERACTION
SECOND EDITION
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.
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
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.
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
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!
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
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.
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.
processed in 0.005 seconds
| |
HCI Book 3rd Edition || old HCI 2e home page || search
|
|
feedback to feedback@hcibook.com | hosted by hiraeth mixed media |
|