HUMAN-COMPUTER INTERACTION
SECOND EDITION
HUMAN-COMPUTER INTERACTION
SECOND EDITION
An important question, which applies to both verification and validation, asks exactly what constitutes a proof. We have repeatedly mentioned the language used in any design activity and the basis for the semantics of that language. Languages with a mathematical foundation allow reasoning and proof in the objective sense. An argument based entirely within some mathematical language can be accepted or refuted based upon universally accepted measures. A proof can be entirely justified by the rules of the mathematical language, in which case it is considered a formal proof. More common is a rigorous proof, which is represented within some mathematical language but which relies on the understanding of the reader to accept its correctness without appeal to the full details of the argument, which could be provided but usually are not. The difference between formality and rigour is in the amount of detail the prover leaves out while still maintaining acceptance of the proof.
In this example, we choose the principle of recoverability described in Chapter 4 as the particular usability attribute of interest. Recall that recoverability refers to the ability to reach a desired goal after recognition of some error in previous interaction, and that the recovery procedure can be in either a backward or forward sense. Current VCR design has resulted in interactive systems which are notoriously difficult to use; the redesign of a VCR provides a good case study for usability
In designing any computer system, many decisions are made as the product goes from a set of vague customer requirements to a deliverable entity. Often it is difficult to recreate the reasons, or rationale, behind various design decisions. Design rationale is the information that explains why a computer system is the way it is, including its structural or architectural description and its functional or behavioural description. In this sense, design rationale does not fit squarely into the software life cycle described in this chapter as just another phase or box. Rather, design rationale relates to an activity of both reflection (doing design rationale) and documentation (creating a design rationale) that occurs throughout the entire life cycle.
The distinction between a process- and structure-oriented design rationale resides in what information the design rationale attempts to capture. Process-oriented design rationale is interested in recording an historically accurate description of a design team making some decision on a particular issue for the design. In this sense, process-oriented design rationale becomes an activity concurrent with the rest of the design process. Structure-oriented design rationale is less interested in preserving the historical evolution of the design. Rather, it is more interested in providing the conclusions of the design activity, so it can be done in a post hoc and reflective manner after the fact.
Rational behaviour is characterized as behaviour which is intended to achieve a specific goal. This element of rationality is often used to distinguish between intelligent and machine-like behaviour. In the field of artificial intelligence (AI), a system exhibiting rational behaviour is referred to as a knowledge-level system. A knowledge-level system contains an agent behaving in an environment. The agent has knowledge about itself and its environment, includings its own goals. It can perform certain actions and sense information about its changing environment. As the agent behaves in its environment, it changes the environment and its own knowledge. We can view the overall behaviour of the knowledge-level system as a sequence of environment and agent states as they progress in time. The goal of the agent is characterized as a preference over all possible sequences of agent/environment states.
We may also want to discuss non-human actors, concrete objects which in some sense act autonomously, which can 'do' something. In the case of 'Vera's Veggies', we would place the irrigation computer in this category. It may not be clear whether or not to regard an object as an actor; we will see that consideration of the actions (below) helps to make this distinction clear.
Closely allied to actions is the idea of an event. Events are anything which happens. The performing of an action is an event, but we may also encounter spontaneous events such as the germination of a marrow seed. There is no agent performing the germination and it should be listed as a spontaneous action of the marrow itself, but not implying that the marrow is in any sense an actor. Some
User Action Notation (UAN) is not a dialog notation as such, but operates at the dialog level. UAN is scenario based in the sense that it considers small snippets of user behaviour, for example the deletion of a file. It describes the actions the user must perform and the system feedback.
The next two axioms say that attempts to move or resize when there is no selected object do nothing at all. Axioms 6 and 7 say that both move and resize are 'forgetful' in the sense that if you do two resizes in a row the second overrides the first as if the first had never happened. This forgetful behaviour of the move operation is very different from the behaviour defined in the model-oriented specification. In the model-oriented approach, it would be easier to specify that a move operation is cumulative -- two successive moves are the same as doing one move equal to the sum of the two moves. Finally, the last axiom says that the action of delete is even more forgetful: it is idempotent -- doing a second delete achieves nothing.
Temporal logics only deal with time in the sense that they represent the succession of events -- one thing happens before another. They do not represent actual durations and times in hours, minutes and seconds. Clearly, there are important user interface aspects which require a real-time statement such as the following:
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 |
|
| |