HUMAN-COMPUTER INTERACTION
SECOND EDITION
HUMAN-COMPUTER INTERACTION
SECOND EDITION
From the programmer's perspective, even at the level of a windowing system, input and output are still quite separate for everything except the mouse, and it takes quite a bit of effort in the application program to create the illusion of the interaction object such as the button we have just described. To aid the programmer in fusing input and output behaviours, another level of abstraction is placed on top of the window system -- the toolkit. A toolkit provides the programmer with a set of ready-made interaction objects -- alternatively called interaction techniques, gadgets or widgets -- which she can use to create her application programs. The interaction objects have a predefined
The sample program quit.c in Figure 10.6 uses the XView toolkit. Programming with toolkits is suited to the notification-based programming paradigm. As we can see in the example, the button is created as a PANEL_BUTTON object (lines 23--26) and registers the appropriate callback routine for when the notifier receives a selection event for the button object. The button interaction object in the toolkit already has defined what actual user action is classified as the selection event, so the programmer need not worry about that when creating an instance of the button. The programmer can think of the event at a higher level of abstraction, that is as a selection event instead of as a release of the left mouse button.
Some help systems are context sensitive. These range from those that have specific knowledge of the particular user (which we will consider under adaptive help) to those that provide a simple help key or function which is interpreted according to the context in which it is called and will present help accordingly. Such systems are not necessarily particularly sophisticated. However, they do move away from placing the onus on the user to remember the command. They are often used in menu-based systems to provide help on menu options. The Spy editor help command and the Macintosh Balloons help are examples of this. In Spy, the third mouse button is dedicated to help. The user positions the cursor over the menu option of interests and presses this button. Help on that topic is presented in a new window. Balloons help is an option in Macintosh System 7 which can be enabled or disabled. When enabled, an explanatory balloon is displayed when the cursor is over a screen widget (see Figure 12.1). In both cases, the invocation of help is interpreted in terms of the context in which it is made.
The first decision the designer must make is how help will be accessed by the user. There are a number of choices. Help may be a command, a button, a function which can be switched on or off, or a separate application. A command (usually) requires the user to specify a topic, and therefore assumes some knowledge, but may fit most consistently within the rest of the interface. A help button is readily accessible and does not interfere with existing applications, but may not always provide information specific to the user's needs. However, if the help button is a keyboard or mouse button, it can support context sensitivity as we saw earlier. The help function is flexible since it can be activated when required and disabled when not. The separate application allows flexibility and multiple help styles but may interfere with the user's current application.
To close the window, place the mouse cursor on the box in the top left hand corner of the window and click the mouse button.
Windows can be closed by moving the mouse cursor to the box in the top left hand corner of the window and clicking the mouse button.
processed in 0.004 seconds
|
| |
|
HCI Book 3rd Edition || old HCI 2e home page || search
|
|
| feedback to feedback@hcibook.com | hosted by hiraeth mixed media |
|
| |