HUMAN-COMPUTER INTERACTION
SECOND EDITION
HUMAN-COMPUTER INTERACTION
SECOND EDITION
There are two approaches to answering these questions. The first is by means of example, in which successful interactive systems are commonly believed to enhance usability and, therefore, serve as paradigms for the development of future products.
Observability allows the user to evaluate the internal state of the system by means of its perceivable representation at the interface. As we described in Chapter 3, evaluation allows the user to compare the current observed state with his intention within the task--action plan, possibly leading to a plan revision. Observability can be discussed through five other principles: browsability, defaults, reachability, persistence and operation visibility. Operation visibility was covered in Section 4.3.1 in relation to predictability. The remaining four are discussed next.
We will begin this chapter by providing an introduction to some of the important concepts of software engineering in Section 5.2. Specifically, we will describe the major activities within the traditional software life cycle and discuss issues raised by the special needs of interactive systems. We will then describe three particular approaches to interactive system design which are used to promote product usability throughout the life cycle. In Section 5.3, we will describe the use of design rules in the form of standards and guidelines. In Section 5.4, we will describe a particular methodology called usability engineering in which explicit usability requirements are used as goals for the design process. In Section 5.5, iterative design practices which involve prototyping and participative evaluation are described. We conclude this chapter with a discussion of design rationale. Design is a decision-making activity and it is important to keep track of the decisions that have been made and the context in which those decisions were made. Various design rationale techniques, presented in Section 5.6, are used to support this critical activity.
Validation of a design demonstrates that within the various activities the customer's requirements are satisfied. Validation is a much more subjective exercise than verification, mainly because the disparity between the language of the requirements and the language of the design forbids any objective form of proof. In interactive system design, the validation against HCI requirements is often referred to as evaluation and can be performed by the designer in isolation or in cooperation with the customer. We discuss evaluation in depth in Chapter 11.
As an example, we will take the development of a new aircraft on which there will be many software subsystems. The aircraft company will usually go through a concept evaluation period of up to 10 years before making any decision about actual product development. Once it has been decided to build a certain type of aircraft, loosely specified in the case of commercial aircraft in terms of passenger capacity and flight range, more explicit design activity follows. This includes joint analysis for both the specification of the aircraft and determination of training needs. It is only after the architectural specification of the aircraft is complete that the separate systems to be developed are identified. Some of these systems will be software systems, such as the flight management system or the training simulator, and these will be designed according to the life cycle described earlier. Typically, this will take 4 to 5 years. The separate aircraft systems are then integrated for ground and flight testing and certification before the aircraft is delivered to any customer airlines. The operating lifetime of an aircraft model is expected to be in the range of 20-- 40 years, during which time maintenance must be provided. The total lifetime of an aircraft from conception to phasing out is up to 55 years, only 4-- 5 years (excluding maintenance) of which contain the software life cycle which we are discussing in this chapter.
Prototypes differ according to the amount of functionality and performance they provide relative to the final product. An animation of requirements can involve no real functionality, or limited functionality to simulate only a small aspect of the
Time Building prototypes takes time and, if it is a throw-away prototype, it can be seen as precious time taken away from the real design task. Hence, the value of prototyping is only appreciated if it is fast, hence the use of the term rapid prototyping. However, rapid development and manipulation of a prototype should not be mistaken for rushed evaluation which might lead to erroneous results and invalidate the only advantage of using a prototype in the first place.
Programming support for simulations means a designer can rapidly build graphical and textual interaction objects and attach some behaviour to those objects which mimics the system's functionality. Once this simulation is built, it can be evaluated and changed rapidly to reflect the results of the evaluation study with various users. For example, we might want to build a prototype for the VCR with undo
Most of the simulations produced are intended to be throw-away prototypes because of their relatively inefficient implementation. They are not intended to support full-blown systems development and they are unsatisfactory in that role. However, as more designers recognize the utility of prototyping and iterative design, they are beginning to demand ways of incorporating the prototypes into the final delivered systems -- more along the lines of evolutionary prototyping. A good example of this is in the design of avionics industry, where it has long been recognized that iterative development via rapid prototyping and evaluation is essential for the design of flight deck instrumentation and controls. Workstation technology provides sufficient graphics capabilities to enable a designer to produce very realistic gauges which can be assessed and critiqued by actual pilots. With the advent of the glass cockpit -- in which traditional mechanical gauges are replaced by gauges represented on video displays -- there is no longer a technology gap between the prototype designs of flight deck instruments and the actual instruments in flight. Therefore, it is a reasonable request by these designers that they be able to reuse the functionality of the prototypes in the actual flight simulators and cockpits, and this demand is starting to be met by commercial prototyping systems which produce efficient code for use in such safety-critical applications.
One technique for simulation which does not require very much computer-supported functionality is the Wizard of Oz technique. With this technique, the designers can develop a limited functionality prototype and enhance its functionality in evaluation by providing the missing functionality through human intervention. A subject for evaluation for a new accounting system may not have any computer training but is familiar with accounting procedures. He is asked to sit down in front of the prototype accounting system and asked to perform some task, say to check the accounts receivable against some newly arrived payments. The naïve computer user will not know the specific language of the system, but you do not want him to worry about that. Instead, he is given instructions to type in whatever seems the most natural commands to the system. One of the designers -- the wizard in this scenario -- is situated in another room, out of sight of the subject, but she is able to receive the subject's input commands and translate them into commands that will work on the prototype. By intervening between the user and system, the wizard is able to increase the perceived functionality of the system so that evaluation can concentrate on how the subject would react to the complete system. Examination of how the wizard had to interpret the subject's input can provide advice as to how the prototype must be enhanced in its later versions.
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 |
|
| |