HUMAN-COMPUTER INTERACTION
SECOND EDITION
HUMAN-COMPUTER INTERACTION
SECOND EDITION
These observations are fairly obvious for state 0--1 devices. With a touchscreen, or light pen, a cursor will often appear under the finger or pen when it comes in contact with the screen. The accuracy with which you can move the cursor around will be far greater than the accuracy with which you can point in the first place. Also it is reasonable to expect that the Fitts' law constant will be different, although not so obvious which will be faster.
Lexical The lowest level: the shape of icons on the screen and the actual keys pressed. In human language, the sounds and spellings of words.
Figure 8.13 shows a flow chart as used by one of the authors, some years ago, for specifying dialogs for forms-based COBOL programs. The dialog shown is a portion of a personnel database update system and is the subdialog for deletion of records. The chart employs two main types of boxes: the rectangular boxes are 'screen images' of the forms used to communicate with the user. The angular boxes are the processes and decisions made by the system. In addition, there is an elliptical 'finish' box, where the user is returned to the main menu, and little 'tape' symbols which represent where the system reads or updates the database.
In many interfaces, the possible screen displays can be easily enumerated. The order in which such screens are produced and the detailed contents of fields may differ, but the basic screen designs are finite. Other systems are more anarchic, especially multi-windowed interfaces where user interaction may dynamically cause the creation of new windows. Thus there is a clear difference between static and dynamic screen presentations.
This issue of dynamic dialog structure is often linked with that of parametrization. An instantiation of a parametrized dialog often involves the creation of new screen resources. For example, we could imagine extending eventCSP to allow
Multi-window-editor
= new-name(name) Æ
( Edit-window(name) [] Multi-window-editor ) -->
However, one suggested 'improvement' was to alter the circle drawing to allow multiple circles. The amendment was shown in Figure 8.2. Unfortunately, this destroys the connectivity of the dialog. There is no way out of the circle dialog; one can only fill up the screen with zillions of circles. This is a fairly obvious problem, but it is easy for more complex cases to slip through. For example, one of the authors was once shown a form-based financial planning system. Some inconsistent information was entered on one page of the form, which was allowed by the system. But, because of this, a later page was repeatedly rejected. There was no valid user input for that page, but the system would not allow you to return to the incorrectly filled page until the later one was accepted -- impasse.
Note that this dialog-level reversability is not a true undo. For example, when the user goes from the Circle 1 state back to the graphics menu, this leaves a circle behind on the screen. Thus the dialog state has been undone, but the full system state has not. Reasoning about undo at this level requires a model of the system, and will be discussed in Chapter 9. There is also a corresponding more complete form of reachability in this setting.
One such support tool is HyperDoc [238], shown in Figure 8.17. The screen shows part of the description for a JVC video recorder. The top half of the screen is a drawing of the interface. The buttons on the drawing are active -- the simulation runs when they are pressed. On the bottom left, we can see part of the dialog description. This describes the transitions from the state 'playPause'. For example, if the user presses the 'Operate' button, the state will change to 'offTapeIn'.
The designer can simply use this as a prototyping tool, by constructing the dialog description and then experimenting by clicking buttons on the top part of the screen. In addition, the tool can construct a graph of states and transitions from the dialog descriptions of each state. This graph is then analyzed using standard graph algorithms for properties such as reachability.
Furthermore, physical limitations may prohibit certain dialog structures. For example, the dialog for the digital watch (Figures 8.15 and 8.16) is designed with the restriction of only three buttons. A similar design for an on-screen alarm clock could make use of a full keyboard and thus have a completely different dialog. Similarly, the range of outputs, visual and aural, will restrict the dialog. If modes and states should be visually distinct then the device's display must be able to distinguish these modes. Unfortunately restricted input leads to a highly moded
processed in 0.008 seconds
|
| |
|
HCI Book 3rd Edition || old HCI 2e home page || search
|
|
| feedback to feedback@hcibook.com | hosted by hiraeth mixed media |
|
| |