HUMAN-COMPUTER INTERACTION
SECOND EDITION
HUMAN-COMPUTER INTERACTION
SECOND EDITION
As we mentioned, the requirements specification concentrates on what the system is supposed to do. The next activities concentrate on how the system provides the services expected from it. The first activity is a high-level decomposition of the system into components that can either be brought in from existing software products or be developed from scratch independently. It is the purpose of an architectural design to perform this decomposition. An architectural design is not only concerned with the functional decomposition of the system, determining which components provide which services. It must also describe the interdependencies between separate components and the sharing of resources that will arise between components.
The detailed design for a component of the system should be in such a form that it is possible to implement it in some executable programming language. After coding, the component can be tested to verify that it performs correctly, according to some test criteria that were determined in earlier activities. Research on this activity within the life cycle has concentrated on two areas. There is plenty of research which is geared towards the automation of this coding activity directly from a low-level detailed design. Most of the work in formal methods operates under the hypothesis that, in theory, the transformation from the detailed design to the implementation is from one mathematical representation to another and so should be able to be entirely automated. Other, more practical work concentrates on the automatic generation of tests from output of earlier activities which can be performed on a piece of code to verify that it behaves correctly.
In relation to the software life cycle, one of the important features of usability engineering is the inclusion of a usability specification, forming part of the requirements specification, that concentrates on features of the user-- system interaction which contribute to the usability of the product. Various attributes of the system are suggested as gauges for testing the usability. For each attribute, six items are defined to form the usability specification of that attribute. Table 5.2 provides an example of a usability specification for the design of a control panel for a video cassette recorder (VCR), based on the technique presented by Whiteside, Bennett and Holtzblatt [259].
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.
Though not usually considered together with such simulation environments as HyperCard, a user interface management system -- or UIMS (pronounced 'YOU-imz') -- can be understood as providing such high-level programming support. The frequent conceptual model put forth for interactive system design is to separate the application functionality from its presentation. It is then possible to program the underlying functionality of the system and to program the behaviour of the user interface separately. The job of a UIMS, then, is to allow the programmer to connect the behaviour at the interface with the underlying functionality. In Chapter 10 we will discuss in more detail the advantages and disadvantages of such a conceptual model and concentrate on the programming implementation support provided by a UIMS. Of interest here is that the separation implied by a UIMS allows the independent development of the features of the interface apart from the underlying functionality. If the underlying system is already developed, then various prototypes of its interface can be quickly constructed and evaluated to determine the optimal one.
Lee and Lai [136] explain that various proponents of design rationale have different interpretations of what it actually is. We will make use of their classification to describe various design rationale techniques in this section. The first set of techniques concentrates on providing a historical record of design decisions and is very much tailored for use during actual design discussions. These techniques are referred to as process-oriented design rationale because they are meant to be integrated in the actual design process itself. The next category is not so concerned with historical or process-oriented information but rather with the structure of the space of all design alternatives, which can be reconstructed by post hoc consideration of the design activity. The structure-oriented approach does not capture historical information. Instead, it captures the complete story of the moment, as an analysis of the design space which has been considered so far. The final category of design rationale concentrates on capturing the claims about the psychology of the user which are implied by an interactive system and the tasks that are performed on them.
Task analysis can be used to guide the design of new (although possibly not novel) systems. Recall (from Chapter 5) that requirements capture is the process of eliciting what a new system should do. Task analysis in itself is not a form of requirements capture as it refers to the existing system, not the planned system, and it includes many elements which are not part of the system. However, it makes a strong contribution towards the complete statement of requirements. Typically, the original statement of requirements given by a client will mention the new elements required and possibly refer to the existing system and its functionality. Further information elicited by a system developer may well concentrate on what the system should do but may forget how it will be used.
We have seen several task analysis methods. Hierarchical task analysis decomposes a task into subtasks. These can be recorded either in a textual outline format or in a tree diagram. Knowledge-based techniques build taxonomies of the objects used during a task and the actions performed upon them. Cutting the taxonomy at some level gives one a set of generic objects and actions. Finally, one can again look at objects and actions, but concentrate on different kinds of object: passive object and active human and non-human agents, and the relationships between the objects and actions.
We began by looking at different kinds of software engineering formalism which can be used to specify the behaviour of specific systems. These specifications can be used for communication between designer and implementor and for analysis. Model-based specifications define the state of the system, the invariants which must
We now concentrate our attention on programming the actual interactive application, which would correspond to a client in the client--server architecture of Figure 10.2. Interactive applications are generally user driven in the sense that the action the application takes is determined by the input received from the user. We describe two programming paradigms which can be used to organize the flow of control within the application. The windowing system does not necessarily determine which of these two paradigms is to be followed.
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 |
|
| |