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

Search Results

Search results for mouse
Showing 131 to 140 of 176 [<< prev] [next >>] [new search]

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

This model only describes a special subclass of systems, those that are trajectory independent. The mouse position only has a permanent effect at the moment a command (keystroke or mouse button) happens; the intermediate positions are forgotten. For example, the model cannot describe freehand drawing. It is possible to extend the model to include more general systems; however, the subclass is interesting in itself. With the exception of drawing and similar tasks, such as 'air-brush' painting, most mouse-based systems are trajectory independent. Furthermore, the few that are not exhibit usability problems, suggesting that trajectory independence is itself a general usability principle for all but exceptional situations.

Chapter 9 Models of the system 9.4 Status/event analysis Page 365

Note that the word 'status' is used rather than 'state', as the term will be used to refer to any phenomenon with a persistent value. This includes the position of a mouse on a table and the current screen contents, as well as the internal state of the system. The word 'state' has connotations of the complete state of the system, rather than the selective particular views meant here by status.

Chapter 9 Models of the system 9.4 Status/event analysis Page 365

The distinction between status and event is between being and doing. Status phenomena always have a value one could consult. For example, you can ask the question 'what was the position of the mouse on the tabletop at 3:27pm?' An event, on the other hand, happens at a particular moment. Here the relevant question is 'at what time did the user press the mouse button?'

Chapter 9 Models of the system Page 368

Mouse When the user is positioning the mouse pointer over a target, the user's attention will be focused on that target. This is guaranteed in all but a few situations by the feedback requirements of hand--eye coordination. However, this attention may not stay long after the target has been successfully 'hit'.

Chapter 9 Models of the system Page 368

Text insertion point While typing text, the user will intermittently look at the text just typed and hence the current insertion point. However, because of touch-typing, this is less certain than the mouse except when moving the insertion point over large distances using cursor keys -- another positioning task.

Chapter 9 Models of the system Page 368

If we know where the user is looking, then we can put information there (not in a status line at the top where no one ever looks). Also, changes at the user's visual focus will be salient and become a perceived event for the user. An example, where the mouse pointer itself is used for information, is the egg-timer or ticking watch icon used when a system is busy.

Chapter 9 Models of the system Page 368

Finally, recall from Chapter 1 that when people complete some goal, they experience closure. This means that they have a feeling of completeness and go on to the next thing. Closure has implications both on perception and actions. It is why in the mouse positioning task, the user's eye may stray from the target as soon as the target is perceived as 'hit'. In addition, the user may begin some of the actions for the next task, while certain automatic actions terminating the last task are still going on. For example, it is easy to knock a glass from the table by beginning to turn round before fully letting go of the glass.

Chapter 9 Models of the system 9.4.4 Example -- email interface Page 369

If we look at Figure 9.5, we see that a number of active agents (Brian, the mailtool and Alison) cause events for one another mediated by status elements (the filestore and screen). This is a very common scenario, especially if you look at fine details of interaction. However, it is also possible to have direct event-based connections (which we will see in the next example), or even status--status connections. An example of the latter is the linkage between the mouse on the table and the mouse pointer on the screen. Even this is mediated by events in its implementation, but this is not apparent to the user.

Chapter 9 Models of the system 9.4.5 Example -- screen button feedback Page 371

Screen buttons activated by clicking the mouse over them are a standard widget in any interface toolkit and are found in most modern application interfaces. The application developer has little control over the detailed user interaction as this is fixed by the toolkit. So, the specific results of this example are most relevant to the toolkit designer, but the general techniques are more widely applicable.

Chapter 9 Models of the system 9.4.5 Example -- screen button feedback Page 371

A common problem with many on-screen buttons is that the user thinks the button has been pressed, but in fact it has not been. As an example, imagine Alison at work again on her word processor. The report is too long and so when she notices a superfluous paragraph, she selects it and then moves her button up to the 'delete' button. She clicks over the button and thinks it has had an effect, but actually as she lifted her finger from the button, the mouse slipped from the button and the click was ignored (the button is activated by the mouse up event). Unfortunately, she does not notice until having, with difficulty, pared the report down to 1000 words, she notices that the unwanted paragraph remains.

processed in 0.005 seconds