Andrew M. Dearden

Abstract models for HCI

Abstract This paper investigates the use of formal mathematical models in the design of interactive systems and argues for the development of generic models that describe the behaviour of a class of interactive systems. In recent years a number of authors have suggested methods for modelling interactive systems using notations and frameworks drawn from software engineering mathematics. We argue that these models tend to be either: so abstract as to limit their ability to express important interaction concerns for specific systems, and limited in the degree to which they support the construction of software that conforms to the designer s intention; or so specific to an individual system that they provide only limited re-use across development projects and are therefore likely to be too expensive to develop except in a few special applications such as safety-critical systems. We argue that it is possible to construct a generic model of a class of interactive systems at an intermediate level of abstraction. Such a model would offer wider reusability than detailed specifications of a single system, but greater expressiveness and support for software development than fully general abstract models. To support our argument we review a number of existing models in the literature and present a generic model of interactive case memories, a class of systems used in case-based reasoning.

Locating the scene: the particular and the general in contexts for ambulance control

Ambulance control involves distributed group work using a mix of computer and communications technologies. The implementation of computer technologies has had mixed results in this area, evidenced by serious failures in the London Ambulance Service in 1992. Often failures are due to inadequate attention to integration of organisational and technical aspects of work. We report a field study of the organisation of one aspect of the work of ambulance control, locating the scene of an emergency. The study was carried out in two ambulance control centres, one predominantly urban and highly computerised and the other largely rural and minimally computerised. Our analysis shows that the particulars of ‘locating the scene’ are best seen in terms of the use of different technologies to link representations and represented. This research has implications for understanding task and context and the integration of technology and organisation in design, particularly with respect to using similar computer-based technologies in both ambulance control centres.

DMVIS: Design, Modelling and Validation of Interactive Systems

Much of the work reported in the first three DSVIS conferences has concentrated on techniques and languages for specifying and developing interactive systems. In this paper, we argue that a change of emphasis may be necessary as the field matures. We argue that real projects with specific objectives for formal methods are more likely to employ a range of diverse, lightweight modelling techniques. We explore this view by showing how, on one example, several quite different kinds of analysis can be performed using different models.

Experiences using situated and non-situated techniques for studying work in context

In this paper, we draw a distinction between situated techniques and non-situated techniques for studying work context. We define a situated technique as one in which the data collection takes place in the normal working environment of the person being studied. We describe our experience of a case study in which we applied a combination of situated and non-situated techniques to analyse work practice in context. To co-ordinate these different types of technique, and to provide adequate validation, we adopted an iterative model building approach.

Choosing a reasoning style for knowledge based system: lessons from supporting a help desk

In this paper, we present two broad styles of KBS reasoner: those based primarily on some general, explicit model of the knowledge of the domain (whether that model be expressed by heuristic rules or by a deep model of structure and function), which we term domain model-based reasoners ; and those based primarily on a set of examples of events in the domain, which we term example-based reasoners (EBR), of which case-based reasoners are a subset. The aim of this paper is to guide developers in considering the trade-offs between these different styles of reasoning. We believe that this cannot be done in general, but may be possible for specific domains. Thus, the paper provides an example analysis of the usefulness of these reasoning styles. We assess the suitability of these styles against a series of requirements which we have identified that KBSs must fulfil if they are to support help desk operations. We conclude that EBR systems are more likely to meet those requirements (the analysis draws on our earlier work in Bridge & Dearden, 1992).

Improving the Interfaces to Interactive Case Memories

An interactive case memory (ICM) is a system that interacts with a human user to gather information about a problem, interpret that information and search a store of previous cases to find cases that may be useful in solving the new problem. Many of the commercially successful products that have been derived from research on case-based reasoning could be described as ICMs. ICMs are type of advisory knowledge based system (KBS). Research on the design of interfaces to rule-based advisory KBSs has suggested that a user of such a system should be allowed to take control in interaction with the KBS. The user should be able to review their input, select the reasoning strategy used and re-direct the KBS towards particular hypotheses.

Modelling Interaction Properties for Interactive Case Memories

Previous work on formal models for interactive systems has often used text editors and graphics editors as case studies. Consequently the notations developed do not necessarily include all the facilities that may be required in reasoning about other types of interactive system.

Risk Analysis, Impact and Interaction Modelling

Operator error has been blamed for many accidents and incidents in safety-critical systems. It is important that human-machine interface (HMI) designers are aware of the relationships between their design decisions, operator errors, and the hazards associated with a system. In this paper, we demonstrate how information from risk analysis can be combined with formal specification of the HMI, to support designers in exploring these relationships. We use the concept of interactor to model the human-machine interface (HMI); together with a concept of impact, which we define informally as: “the effect that an action or sequence of actions has on the safe and successful operation of a system.” We show how interactors can be used as design representations for the HMI at the earliest stages of design, as well as providing a medium by which risk analysts can inform HMI designers about the impact of human-errors. To demonstrate the feasibility of this approach, we consider a simple, gas-fired, electricity generating plant as a case study. Our proposed approach is intended to complement, rather than compete with, existing design and analysis methods for the HMI. The method achieves this by making risk analysis information available in the early stages of HMI design.

Impact as a Human Factor in Interactive System Design

Operator error has been blamed for many accidents in complex, hazardous work-systems such as nuclear power plants and aircraft. Safety engineering is concerned with analysing and quantifying the severity of hazards and the risks associated with such systems in order to guide design. It is clear that, in the design of human-machine interfaces for such systems, the severity of potential hazards and the risk of accidents occurring may dominate the design problem. It is less clear that, when considering interfaces for more everyday computer applications, the impact of individual operations, and the risk of undesirable events may be just as important to the quality of the design. However, the combined effect of many small errors and inconveniences for many users may represent a significant cost to organisations using the software.

A Software Engineering Model for Case Memory Systems

This paper describes a generic model for case memory systems expressed using the Z notation. A case memory system is an essential part of any case-based reasoning system, and provides a mechanism for storing old cases, and for assessing the relationship between the stored cases and a new problem. Using the model, characteristics that have been claimed for specific case memory systems in the literature, e.g. responsiveness to a reasoners goals or use of past experience in case assessment, are expressed formally in terms of constraints on the means by which case relations are computed. The model supports precise reasoning about the characteristics of specific systems and offers insight into the variety of options available to software or knowledge engineers seeking to reuse a case memory system, to select a case memory system shell or to develop a new system.