John Long
Emeritus Professor, Ergonomics and HCI Unit, University College London, 26, Bedford Way, London, WC1H OAP, UK ( Now at UCL Interaction Centre)
Keywords: HCI Engineering, Domain of work, Design problems
Abstract
Usability continues to be central to Human-Computer Interaction (HCI), in spite of recent developments associated with user experience, user pleasure, etc. The Internet continues to dominate the introduction of a wide range of new technologies and rightly has become central to HCI. One current view of HCI, then, is in terms of the usability of Web pages. This view is appealing and there can be no doubt that usable Web pages would be a laudable achievement for HCI This paper supports such a view, but argues that it is too limited. HCI, as an engineering discipline, supports user interaction design, but for effectiveness. The latter necessarily includes usability – how easy it is to use a computer, but also task quality – how well the work is performed by the interactive user-computer worksystem. Easy-to-use computers may produce poor work, hard-to-use computers may produce good work. Usability alone fails to distinguish between these two cases, but differentiation is essential for HCI design and evaluation, because both usability and task quality need to be as desired. This paper proposes a domain approach to make good the limitation of HCI as the usability of Web pages. The domain of work is represented as object, attributes, values and their desired changes – task quality. Implicit domain models (medical reception; military command and control; and domestic energy management) and explicit domain models (off-load planning; emergency management; and air traffic management) are described. Each model is illustrated in terms of its potential support for design as the diagnosis of design problems and the prescription of design solutions, both as they relate to the task quality of the associated domains of work. It is concluded that HCI is indeed more than the usability of Web pages and that the domain approach to making good the limitation shows promise. In particular, implicit domain models are considered to support design in the short-term, while explicit domain models are considered to support design and research in the long-term.
1. Introduction
Usability and Web pages continue to be central to HCI. However, the view that HCI is no more than the usability of Web pages is rejected as too limited. Nevertheless, usable Web pages constitutes a laudable goal for HCI. This paper proposes a domain approach to HCI to make good this limitation.
1.1 Usability and HCI
HCI has evolved considerably since those early days. A number of developments have extended its scope. For example, computer-supported co-operative work (CSCW) emphasises the interdependance between computer users. Ubiquitous computing (Ubicomp) emphasises the variety of computing devices and their locations. Virtual reality (VR) emphasises the importance of ‘presence’ in its simulations. However, in spite of these developments, HCI continues to retain usability as a critical expression of performance.
The concept of usability has also evolved since the early days of HCI. Pleasure has been proposed as a concept, relating people to computing products, which goes beyond usability (Green and Jordan, 2002). User experience claims to be a more complete expression of the same relationship (Light & Wakeman, 2001). However, these new concepts do not claim that usability is unimportant, or even unnecessary, only that there are additional people-product relations. Usability, then, remains central to HCI. It is concluded that in spite of extensions to both the scope of HCI and usability, over the years since their inception, the latter remains central to the former.
1.2 Web Pages and HCI
New technologies continue to characterise and to extend the scope of HCI. Personal computers soon became networked. Broadband communication integrated data processing and communications. Multi-media synthesised text and graphics. Multi-modality combined user inputs from speech, gesture and keyboard. Other new technologies include: distributed networks; mobile computing and telephony; smart buildings; wearable computing; augmented reality, etc. However, some of these new technologies are only in their infancy. Other technologies have proved less successful than originally expected. Yet other technologies have achieved only modest market penetration. In contrast, the new technology, that is the Internet, has continued to develop, offers a number of successful services (although not all are succesful) and has achieved deep market penetration. It is unsurprising, then, that Web pages have rightly become central to HCI.
1.3 Usability, Web Pages and HCI
Given the centrality of both usability (Section 1.1) and Web pages (Section 1.2) to HCI, one might be forgiven for thinking that HCI is essentially the usability of Web pages. This view is appealing and there can be no doubt that usable Web pages would be a laudable and notable achievement for HCI. The notability would derive both from the importance of the achievement for users and from the increased competition of other professionals, such as graphic designers, software engineers, marketeers and financiers to influence the design and evaluation of interactive computer systems. The view that HCI is the usability of Web pages is shared here. However, the proposition is understood as ‘HCI is not less than the usability of Web pages’, but not ‘HCI is only the usability of Web pages’. The scope of HCI must include usability, a primary expression of performance and Web pages, the dominant New Technology. HCI, then, is not limited to, but more than the usability of Web pages. The aim of this paper is to propose an approach – that of the domain – for HCI to go beyond the usability of Web pages.
2. General Domain Approach to HCI
The limitations of the view that HCI is no more than the usability of Web pages are analysed in terms of: completeness; coherence; and fitness-for- purpose. A domain approach is proposed, which makes good these limitations in terms of the three criteria.
2.1 Limited View of HCI
It has been argued earlier that the view of HCI as only the usability of Web pages is too limited. It is worth setting out these limitations in more detail. The latter both provide support for the argument and set up criteria against which to assess alternative approaches to HCI -such as that of the domain, as proposed here. The criteria are: completeness; coherence; and fitness-for-purpose. These criteria derive from the concept of a discipline, whose knowledge, acquired by research, supports its practices (Long, 1996).
First, the usability of Web pages is an incomplete expression of HCI performance. Ideally, usable interactive user-computer systems also achieve their goals. However, HCI evaluations routinely identify usable systems, which fail to achieve their goals and hard-to-use systems, which do achieve their goals. Usability, then, can only constitute one aspect of performance. There also needs to be some expression of the work an interactive system performs and how well it performs that work. The usability of Web pages is too limited a view of performance. If the Web pages provide a service, such as e-commerce, performance needs to express how well the service is effected, for example, goods purchased.
Usability also fails to reflect the computer’s contribution to performing work. For example, a hard-to-use system might be made more easy to use by simplification of the interface. Simplification might be achieved by reducing inappropriate computer behaviours (and so the code supporting them) or increasing appropriate behaviours (and so the code supporting them). In both cases, usability is the same, but the computer contribution differs. This difference should be reflected in a more complete expression of the interactive worksystem’s performance.
Second, the usability of Web pages is an incoherent expression of HCI performance. Usability appears to be a property of the computer. For example, a hard-to-use computer can be re-designed to be easier to use. But computers can also become easier to use by training, learning and practice with no change in the computer itself. Training, learning and practice all modify properties of the user and not the computer. So, usability would be more coherently expressed, if it referred to the user contribution to the interaction. For example, if usability were expressed as effort, or somesuch, the latter might vary as a function of re-design, training, etc. Third, and last, the usability of Web pages is not fit-for-purpose for expressing HCI performance. HCI, as an engineering discipline (Long and Dowell, 1989), acquires and validates knowledge by research to support HCI design. HCI design (and evaluation) can be understood as the diagnosis of design problems and the prescription of design solutions. HCI, then, attempts to ‘design for effectiveness’, indeed to ‘design users interacting with computers to perform effective work’, (Dowell and Long, 1989 and 1998). The usability of Web pages fails to express such effectiveness and so is not fit-for-purpose for supporting HCI performance.
In summary, then, the usability of Web pages is neither complete, coherent, nor fit-for-purpose for expressing HCI performance for an HCI discipline intent on designing for effectiveness. Those three criteria need to be met by any alternative approach to HCI, including the domain approach, proposed here.
2.2 Particular Domain Approach to HCI
The domain approach to HCI originates in proposals made by Dowell and Long (1989 and 1998). According to the latter, HCI is an engineering discipline, whose research acquires knowledge to support the solution of the general problem of design, having the particular scope of users interacting with computers to perform effective work. Following Dowell and Long, users interacting with computers constitute an interactive worksystem, composed of at least two separate, but interacting, sub-systems, namely users and computers. Such interactive systems have a domain of application. The domain of work is where work originates, is performed and has its consequences. Goals are allocated to worksystems by organisations. A domain is distinct from, and delimits, a worksystem. Worksystems are designed to perform effective work.
Work is conceived as comprising one or more objects, constituted of attributes, which have values. Goals express a requirement for change in the values of these attributes. Interactive subsystems consist of user behaviours interacting with computer behaviours. These behaviours are supported by mutually exclusive user structures and computer structures and are executed to perform work effectively. Effectiveness is expressed by the concept of performance, that is, how well a system achieves its goals – task quality, and the system costs that are incurred in so doing. Costs are incurred by both the user and the computer, may be physical and mental/cognitive/abstract and can be thought of as workload – for present purposes. The domain approach thus adds the separate concept of work to the system effecting the work. In addition, it applies the concept of work as object/attribute/value transformation (by the worksystem) to performance. It further distinguishes user and computer workloads. The conception is entirely motivated and rationalised by the requirements of an HCI engineering discipline to support design for performance.
This view of HCI is considered to meet the three criteria of completeness, coherence and fitnessfor- purpose, identified earlier and so make good the limitations of the view of HCI as only the usability of Web pages.
First, the view is complete. Performance of an interactive work-system is expressed in terms of task quality – how well the work is carried out and worksystem costs, the workload involved in carrying out the work that well. System workload is composed of user workload and computer workload. If usability is considered to be expressed by user workload, then task quality and computer workload are the additional concepts, required for a complete view of HCI.
Second, the view is coherent. User workload is a property of the user; computer workload is a property of the computer. An increase or decrease in the one can be accompanied by an increase or decrease in the other. In general, the trend in current design is to increase computer workload for a decrease in user workload (given the decreasing cost of computer hardware and software). This current trend in design is well expressed by differentiated worksystem costs, but not by usability, either alone or as a presumed property of the computer. Further, design, training or user selection can all be expected to change user workload, but only design can change computer workload.
Third, and last, task quality and differentiated system workload are fit-for-purpose for expressing HCI performance, because design problems can be diagnosed as ineffective performance, and thus design solutions can be prescribed as effective performance. HCI, as an engineering discipline, can, be supported in its intent ‘to design for effectiveness’. Performance-driven design is taken to be the hall-mark of an engineering discipline (Newman, 1994) In conclusion, then, the domain approach to HCI proposed here meets the three criteria of completeness, coherence and fitness-for-purpose that were used to identify the limitations of the view of HCI as only the usability of Web pages. This domain approach to HCI is now illustrated.
3. Domain Approach Illustrations
Each illustration of the domain approach to HCI describes a domain model and its potential to support design as the diagnosis of design problems and the prescription of design solutions. Only task quality is illustrated as an expression of performance. User and computer costs as workload refer to the worksystem and not the work. User workload is a more coherent expression of usability. Only task quality derives from the domain and so goes beyond usability. Hence, the focus of the illustrations on task quality.
3.1 Implicit Domain Model Illustrations
Modelling the domain of work, following the domain conception of Dowell and Long (1989), necessarily produces an explicit domain model. However, the domain conception can also be used informally to identify domain aspects, implicit in descriptions of interactive worksystems. Such descriptions derive from domain expertise and may be provided by domain experts or worksystem documentation, such as operational procedures, training manuals, etc. Implicit domain models are important for three reasons. First, they are readily available, given access to domain experts and/or worksystem documentation. Second, implicit domain models can be used to support design and evaluation as illustrated here. Third, such models provide the starting point for developing explicit domain models. Implicit domain models use a wide range of representations, including text, diagrams, etc. Note that because the domain models are implicit, these representations include descriptions of the worksystem and other aspects, excluded from the domain conception of Dowell and Long.
3.1.1 Domain of Medical Reception
Domain models of Medical Reception (MR) are implicit in the documentation of medical reception itself (for example, Drury, 1981; Jeffreys and Sachs, 1983, etc.) MR involves combinations of people and office devices (including computers, at least in the UK) in the support of interactions between medical practitioners and their patients in medical general practices. Receptionists are central to the organisation of MR. For example, by 1981 over 70% of medical general practitioners in the UK employed receptionists to operate doctor patient appointment systems, in a group practice (comprising three or more doctors), during surgeries (that is, when the doctors see patients). Most of the receptionists’ time is spent dealing with: requests for surgery appointments and home visits, either by telephone or in person; patients, who turn up with or without appointments; telephone requests to speak to doctors and other medical health workers; registration of new patients; and other patient enquiries and complaints. When making an appointment, the receptionist tries to satisfy the patients’ request for a particular doctor, without keeping them waiting for longer than is acceptable. (At busy times, there may be ten or more patients queuing for an appointment, either on the telephone or in person.) It is difficult, under such conditions, to keep track of the order in which patients present themselves, by telephone or in person, so receptionists can become confused and either have to interrupt and recommence appointment-booking, keeping patients waiting longer than is acceptable or fail to respect the ‘first-come-first-served’ principle underlying ‘fair’ queuing.
Domain models can also be implicit in the transcribed videotapes of MR observational studies (Hill, Long, Smith and Whitefield, 1995). Consider this example of protocol data from the latter study:
Telephone 1 : flash
Receptionist 1 : pick up receiver Telephone
: (over telephone) say: “Can I help”
: pick up green card (?baby registration card) from hatch
: read green card : put green card on desk top
: (over telephone) say: “No, I’m sorry I’ve got nothing”.
Nurse : look at nurse appointment book.
Receptionist 1 : (over telephone) say: “Did you say it’s an eye infection?”
: (over telephone) say: “I’ve got literally nothing”.
: (over telephone) say: “All I can offer you is 11:45 this morning – an emergency appointment”.
Receptionist 2 : search prescription – box
Receptionist 1 : (over telephone) say: “Or 10 past 10 with Dr. J tomorrow morning”.
Receptionist 2 : take out prescription
Receptionist 1 : (over telephone) say: “O.K., your name again?”
: write in appointment book
: (over telephone) say: “O.K., 11:45 Dr. I”.
: (over telephone) say: “Thank you. ‘Bye”.
: replace receiver Telephone 1.
: (to hatch) say: “Have you not got a card when you registered the baby
On the basis of MR documentation and the protocol data, the following set of user requirements might be expressed by a receptionist domain expert: “Booking appointments works well, if only one patient is waiting and there are no interruptions. If many patients are waiting, on the telephone and at the hatch (that is, in person), or following an interruption by patient, nurse, doctor or other receptionist, we are often confused as to where we are in the booking procedure. We often take patients out of turn or have to start booking again. This results in us having to work harder than is reasonable and to keep the patients waiting longer than is acceptable to them. Further, we often fail to meet the desires of patients as concerns the particular doctor, the time, or both booked for the appointment. We need some computer help to deal with waiting patients and interruptions, so that our work and the patient waiting times are reduced to acceptable levels”.
It should be noted that neither the MR documentation, the protocol data, nor the receptionist domain expert refer explicitly to the domain, as conceived by Dowell and Long. However, their conception can be used to make explicit the domain, implicit in the description of worksystem behaviours.
For example, following Hill et al (1995), ‘suitability-of-appointment-for-patient’ could be conceived as one attribute of a ‘medical case object’, having values of ‘suitable’ or ‘unsuitable’. For the protocol data, the patient would obviously have preferred an appointment with Dr. J. rather than Dr. I., although an earlier appointment with the latter (for an eye infection) was preferable in this instance to a later appointment with the former. Likewise, an expedition-of-appointment-for-patient’ attribute might have the values ‘timely’ or ‘untimely’. The interruption of a nurse or doctor would have delayed the booking of the appointment described by the protocol data, so rendering it untimely.
Such an informal interpretation of the implicit MR model could be used to support design (and evaluation) in terms of design problem diagnosis and design solution prescription. The design problem and solution would be expressed in terms of the task quality of the MR domain of work.
As concerns design problem diagnosis, the earlier receptionist user requirements identify both acceptable user waiting times and meeting patients’ doctor preferences as candidate problems. In terms of the implicit MR domain model, the design problem could be expressed as the undesired MR task quality of (doctor) suitability and appointment expedition. The problem could be quantified, for example, appointment-booking achieving 90 per cent (doctor) suitability and 90 per cent expedition timelines.
As concerns design problem prescription, computer-based decision support might be provided for the receptionist. The support could record the order of patient arrival and store patients’ doctor preferences, using the latter to prompt preferred appointments. The additional computer support might be expected to increase MR task quality of (doctor) suitability and expedition to a desired level.
The illustration shows how the domain approach goes beyond usability (workload). The latter is implicated in the receptionist user requirements (“This results in us having to work too hard…”). It is also implicated in the additional computer decision support. However, in neither case does usability express MR task quality. (Doctor) suitability and appointment expedition express how well the MR work is performed and not the usability/workload of the MR system performing the work that well. The two concepts, of course, may be intimately related.
3.1.2 Domain of Military Command and Control
The domain of military command and control (C2) carries out two types of work – planning for armed conflict and operating for armed conflict. Nation states pursue their interests by the use of their resources, both human and nonhuman. Users may be political, military, diplomatic, etc. Resources include land, sea, air, space, installations, etc. Domain models of C2 are implicit in military history, doctrine, manuals, domain expert descriptions and military operating procedures. This illustration of military C2 uses the Vincennes incident as described in the official report of the associated enquiry (USDOD, 1988).
The incident took place during the Iran/Iraq war, initially a land battle. Iraq attempted to disrupt Iran’s oil trade, launching air attacks against its oil installations. In response, Iran disrupted oil transport in the Persian Gulf. The US response was to send naval forces to ensure oil supplies. The Iraqi Air Force successfully attacked Iranian forces near the North Persian Gulf. Iranian retaliation of small boat attacks on commercial shipping was expected. The incident occurred when the USS Vincennes – a cruiser – mistakenly shot down civilian Iran Air Flight 655, with total loss of life, while simultaneously engaging a group of Iranian small boats.
The domain model of military C2 is implicit in the expert military descriptions, which appear in the official report. Colbert and Long (1995) summarised the events of the incident as they occur in the report descriptions. Here is a selective extract (the time of the event precedes the events):
0620 The small boats and the Vincennes begin to close ———-.
0647 Flight 655 takes off and is detected by the Vincennes as an ‘unknown, presumed enemy’.
0649 Flight 655 adopts its flight path, which is towards the Vincennes. The Vincennes challenges its air contact (actually Flight 655), but receives no reply. For a moment, Vincennes’ air contact appears electronically to identify itself as a military aircraft (due to freak weather conditions?).
0651 One of the Vincennes’ guns jams when one of the small boats is about to adopt a dangerous position ———. Further challenges to the air contact receive no reply —–. Flight 655’s altitude is misread. The air contact is perceived as diving towards the Vincennes; in fact, it is climbing away from it.
0654 Two surface to air missiles are launched by the Vincennes ——. The missiles destroy Flight 655. All passengers and crew are killed.
The summary does not refer explicitly to the domain of C2, as conceived by Dowell and Long. However, their conception can be used to make the implicit domain model explicit. For example, following Colbert and Long (1995), armed conflict objects could be conceived as constituted of: friends; hostiles; and neutrals objects. All three objects have attributes of vulnerability and involvement. In addition, the friends object has the attribute of power (to realise its interest) and the hostiles object has the attribute of threat (to frustrate the friend’s interest). Attributes could have the values of low, medium and high (or indeed any finer gradations, as required). The C2 expert descriptions of the report can be re-expressed to render the domain model explicit as follows:
0620 The involvement, power and vulnerability of the friend (Vincennes) and the hostile increase again.
0647 The involvement of the neutral (Flight 655) and the friend begins to increase.
0649 The involvement and vulnerability of the neutral, and the friend’s power with respect to it, increases rapidly.
0651 The power of the friend with respect to the neutral temporarily falls sharply——. The involvement and vulnerability of the neutral and the friend’s power with respect to it continue to increase rapidly.
0654 The friend’s power with respect to the neutral is realised, with catastrophic results.
The design problem, as concerns task quality, can be diagnosed as the involvement of the neutral (Flight 655) and the realisation of the friend’s (Vincennes’) power with respect to the neutral. Both the latter’s involvement and the friend’s power with respect to the neutral have undesired high values. As a result, task quality is not as desired, and so constitutes a design problem.
As part of the prescription of a possible design solution, air contact altitude might be more clearly presented, for example, using colour or three-dimensional coding. The Vincennes would then have perceived Flight 655 as climbing away from it and not diving towards it. As a result, the neutral’s involvement would have decreased and the friend’s power would not have been realised. Neutral involvement and friend’s power values, and so task quality, would be as desired.
The illustration shows how the domain approach goes beyond usability. The latter might well be implicated in the Vincennes’ misreading of Flight 655’s altitude, but altitude is co-extensive with neither neutral’s involvement nor friend’s power realisation. Usability tells us how easy or difficult it is to perform work, not how well the work is performed.
3.1.3 Domain of Domestic Energy Management
Energy has multiple uses in the home – heating, cooking, lighting, etc. A major use – in the UK at least – is the heating of the house to maintain the comfort of the people living there. Management consists of the planning and control of the heating to ensure people’s comfort. Management is typically effected by ‘central’ heating systems, consisting of a boiler, which heats water, a tank, which stores it and pipes, which conduct the water to the radiators. Users interact with a controller to set and to programme the heating. The hot water heats the radiators, which in turn heat the house, which determines the comfort of the occupants.
Elsewhere (Stork, Middlemass and Long, 1995), a set of user requirements was elicited for such a central heating system. They are as follows: “The domestic routine of A occasionally requires him to remain at home to work in the mornings, rather than at his office. However, if A leaves after 8 o’clock in the morning, or stays at home to work, then the house is too cold until he turns the gas-powered central heating back on. If he expects to be at home a short time after 8 o’clock, then he often uses the one-hour boost facility on the heating controller to turn the heating back on, which can result in him being too cold, if he is at home longer than expected. A’s ability to work is adversely affected by being cold and having to control the heating. A finds it difficult to plan much in advance, either whether he is staying at home to work, or if he stays, how long he will stay to work. The current gas bill is acceptable, and an increase could be tolerated, although a decrease would be desirable”.
The user requirements make some explicit reference to the domain, for example, “the house is too cold” and “him being too cold”. The references are, however, incomplete. Following Stork and Long (1994), a more complete and explicit domain model might have two main physical objects: A and the house. A has a physical attribute of temperature and an abstract attribute of comfort. The attribute of comfort is related to the attribute of temperature, having a range of acceptable temperatures (for example, 35.75c to 37.5c).
The second physical object is the house, which has physical objects that are the rooms. The rooms have a physical attribute of their temperature and physical objects as radiators. The radiators have a physical attribute of their temperatures. The temperature is related to the temperature of A (an approximately linear relationship) and the temperature of the radiators.
In terms of this explicit domain model, a design problem exists, because the current values of the temperatures of the radiators result in the value of the comfort attribute of A being ‘not comfortable’, at some times, that is, task quality is too low. A design solution prescribed by Stork et al, (1995) involved programming the heating to be on for weekday mornings with an additional remote-heating controller, having an advance button and a bright status light, installed by the front door. The temperatures of the radiators and rooms, and so the house and A, were maintained, such that A’s value remained comfortable, that is, task quality was as desired.
The illustration shows how the domain approach goes beyond usability. Usability/workload is implicated in the user requirements. For example, “A finds it difficult to plan much in advance” and “A’s ability is affected by —— having to control the heating”. However, these aspects do not refer to A’s comfort, the maintenance of which, as desired, constitutes the work of the domestic energy work-system. The design solution likewise. However, the two aspects of performance, and so effectiveness, although related, are differentiated in the domain approach. The rationale is that any design change, such as the addition of a front door controller might affect usability/workload and task quality differentially.
The illustration of how implicit domain models, such as medical reception, military command and control and domestic energy management, when informed by the explicit domain approach of Dowell and Long, can inform design as the diagnosis of design problems of task quality and the prescription of design solutions for task quality, are now complete.
In all cases, the illustrations show how the domain approach goes beyond usability, and given the range of applications, beyond the usability of Web pages. Usability/workload expresses the performance of the work-system; task quality the performance of the work. Together they constitute effectiveness. We turn next to consider how explicit domain models go beyond usability.
3.2 Explicit Domain Model Illustrations
As indicated earlier, applying the domain conception of Dowell and Long necessarily produces an explicit model of the domain of work. Explicit models have also been referenced (Hill et al., 1995; Colbert and Long, 1995; and Stork et al, 1995). The illustrations, which follow show how explicit models support design and in so doing, go beyond usability.
3.2.1 Domain of Amphibious Landing Off-load Planning
As indicated earlier, military C2 carries out planning for armed conflict. Amphibious landing off-load planning is one such type of planning. An amphibious landing may here be considered an attack (that is, armed conflict) against a potentially hostile shore, launched from the sea, and involving air, sea and land forces. It includes the movement ashore of a landing force, embarked on transport ships and naval vessels, by means of amphibious vehicles, landing craft, and helicopters. The landing force arrives ready for combat ashore, and at beaches and landing zones (rather than ports or airfields) (Evans; 1990). Critical for the landing are the off-load plans (see Figure 1), which represents a typical traditional off-load plan as a table (upper figure) and as a gantt chart (lower figure). These plans specify who is to go ashore (left-hand columns of the table) and where and when (right-hand columns of the table). They also specify who is to take the landing force ashore and how the force is to be grouped tactically (middle columns) .
Figure 1. Typical traditional off-load plan
as a table (upper figure) and as a gantt chart (lower figure)
An explicit domain model of amphibious offload planning (following Colbert and Long, 1995 and Long, 2000) is shown in Figure 2. The plan has both physical and abstract aspects, the latter represented at different levels of description. Plan object attributes comprise: scope; content; and view. Scope has time and object values. Content has the values of conflict object goal states etc, view has the values of table, gantt chart etc. 
Figure 2 Domain model of amphibious off-load planning
Following Long (2000), decision problems, such as off-load planning, require three decision types: solution selection; solution construction; and problem elaboration. Traditional off-load plans (Figure 2) provide only limited support for these decision types. Colbert and Long (1995), using the explicit domain models of armed conflict and off-load planning, diagnosed a design problem, indicating the task quality of such traditional off-load plans are not as desired. The design problem identified, as undesired, aspects of both plan content and plan scope. Concerning plan content, there was a failure to achieve 100% availability by the specified deadlines and rates of lift in terms of man/hours. Concerning plan scope, there were too many errors, related to time and object values.
Figure 3 Re-designed interface for amphibious off-load planning
Again, using the domain models of armed conflict and off-load planning, Colbert and Long proposed a re-designed interface, constituting the prescription of a design solution (shown in Figure 3). The interface not only shows the off-load plan to date, but also: next load pending; next load options; and next load assessments. The next load option exploits the domain model of off-load planning, for example, contents. The next load assessment exploits the domain model of armed conflict, for example, power, safety, cohesion and fatigue and the domain model of off-load planning, for example, lift. The redesign was intended to provide improved support for plan solution selection, solution construction and problem elaboration and so to achieve desired content deadlines, and lift and a reduction in scope errors.
Colbert and Long conducted an evaluation of the re-designed off-load planning interface. The results were as follows. Content deadlines were not met as desired, 91.5% not 100% of content was made available by the deadline. The planned rate of lift, however, was as desired – the 267 men/hour achieved fell between the desired criteria of 255 -275 men/hour. Likewise, scope errors of 0.4 fell below the desired criteria of 1.8. We can conclude on this basis that off-load plan quality was as desired, except as concerns content availability by specified deadline. Further redesign would be required to meet this performance criterion.
However, what this illustration is intended to show is not the success of the redesign itself, but that the domain approach goes beyond usability and that explicit domain models have the potential to support design. First, off-load task quality was expressed as desired content availability and rate of lift, together with scope errors. Elsewhere, Colbert and Long evaluated usability/workload in addition to task quality. Users’ rating of workload was an average 3.0, which was less than the acceptable criterion of 3.3, and so as desired. Thus, the redesign affected task quality and user costs differentially, so illustrating how the domain approach goes beyond usability. Both are required to express work-system performance and so to support design. Second, both domain models of armed conflict and of off-load planning contributed to the design by suggesting object/attribute/values, such as plan content and scope. Such aspects undoubtedly also contributed to the effects on the performance of task quality and user costs/workload.
3.2.2 Domain of Emergency Management
As in many countries, the UK has a system for the co-ordination of the emergency services in response to disasters, such as explosions, airplane crashes, etc. This system is called the Emergency Management Combined Response System (EMCRS). This system manages, that is, plans and controls, agencies, such as Fire and Police, when they respond to disasters. The UK EMCRS was set up to support better coordination between agencies.
The EMCRS is a command and control system with a three-level structure – operational, tactical and strategic. The system has objectives (embodied in plans), common to all agencies. These objectives are (in descending order of priority): to save life; to prevent escalation of the disaster; to relieve suffering; to safeguard the environment; to protect property; to facilitate criminal investigation and judicial, public, technical or other enquiries; and to restore normality as soon as possible (Home Office, 1994). The individual agencies relate their own individual plans by means of the shared EMCRS plans to interact effectively. Each agency plan specifies a set of functions, for example: Fire Service – rescuing trapped casualties; preventing escalation of the disaster, etc.
An explicit domain model of EMCR (following Hill and Long, 1996 and 2001) is shown in Figure 4. The model comprises physical and abstract domain objects, having attributes and values. For example, the lives object has a survival/evacuee status attribute, having the values of: rescued and not rescued. The disaster scene object has a site attribute, having the values of preserved and unpreserved. And the disaster character object has a fire-type status attribute, having the values of controlled and uncontrolled. The transformation of the object/attribute/values by the EMCRS determines the values of the stability and normality attributes of the disaster object. These values constitute EMCR task quality.
Hill and Long conducted an observational study, involving two stagings of an inter-agency combined response training scenario, which took place at the Home Office Emergency Planning College. The 60 trainees were members of the emergency services and local authority emergency planning officers. The training scenario concerned the derailment of an oil-tanker train on a bridge over a busy main road and a market. The data from the study were used to construct the explicit EMCR domain model. The data can also be used to diagnose a design problem and to prescribe a design solution to illustrate the contribution of the domain model to design.
Figure 4 Domain model of emergency management combined response system
One design problem derived from a behaviour conflict between the Police, Fire and Ambulance Services. The conflict concerned the relations between the Services’ trampling of the disaster site, and the preserved/unpreserved values of the site attribute of the disaster scene object (see earlier and Figure 4). In the training scenario, the Police declare the site a crime scene as vandalism is suspected to be the cause of the tanker-train derailment. As a result of the declaration, the Fire and Ambulance Services are required, by the EMCRS plan, not to trample the scene in the course of their functions (see earlier), as any evidence of a crime must be preserved “to facilitate criminal investigation” (see EMCRS objectives earlier). However, not trampling the site, that is, moving more carefully and so more slowly, delays the rescue of casualties by the Ambulance Service (a primary function) and hinders prevention of escalation of fires by the Fire Service (also a primary function). The Police Service behaviours of preserving the site of the disaster scene conflict with the Ambulance Service behaviours of casualty rescue, and the Fire Service behaviours of fire containment. In terms of EMCR task quality, there is an undesired survivor/evacuee attribute value of not rescued and an undesired fire-type attribute of uncontrolled. Task quality is not as desired and so constitutes a design problem.
The training data do not make clear, whether this design problem is related to planning or control, training or selection of service personnel and so do not suggest a specific design solution prescription. However, it is plausible to conceive that, in any re-design of the EMCRS plans, the disaster scene object site attribute could take on values of high, medium and low preservation. In the training scenario, the train and the track might be adjudged high preservation, the rest of the bridge medium preservation and the main road low preservation value. The additional trampling gradation would be expected to increase the survivor/evacuee attribute value of not rescued for the Ambulance Service and the fire-type attribute of uncontrolled for the Fire Service. The gradation, however, would also be expected to reduce the facilitation of criminal investigation. In other words, the original desired task quality would not be achieved by the re-design, but the task quality would be superior to the actual task quality, observed in the training scenario.
The additional gradation of trampling might make the EMCRS plan more or less usable, implicating more or less workload for the Police, Ambulance and Fire Services. Be that as it may, the illustration makes clear how the EMCR task quality of the domain approach, expressed as survivor/evacuee rescued and the management combined response system fire-type controlled, goes beyond usability and EMCR systems go beyond web pages.
Figure 5. Domain model of reconstructed air traffic management
3.2.3 Domain of Air Traffic Management
Air traffic management (ATM) is here understood as the planning and control of air traffic. Operational ATM manages air traffic, for example, Manchester Ringway Control Centre in the UK. The Centre manages a terminal manoeuvring area with 9 beacons, more than 2 airways, 1 stack, and 2 exits. Its traffic can be characterised as: departing; arriving, overflying; “low and slow”; high-level bunching and so forth. The management involves track and vertical separation rules (Dowell, 1993 and 1998). Planning is supported by “flight strips” and controlling by radar.
Dowell developed an explicit domain model of Manchester Ringway ATM and a simulation thereof – reconstructed air traffic management (RATM) (Dowell, 1993 and 1998). The model, following Long and Timmer (2001), appears in Figure 5. The model comprises physical and abstract objects. Airspace objects include beacons, for example, Alpha, Beta, etc. Aircraft objects include aircraft, for example, TAW, etc. The intersection of airspace objects and aircraft objects results in air traffic event objects with attributes of: position; altitude; speed; heading; and time. Transformation of the values of these attributes result in air traffic vector object attributes of safety, with values of flying time and vertical separation; and expedition, with values of flight progress; fuel use; manoeuvres; and exit variation. Safety and expedition express ATM task quality. Timmer and Long (1996 and 1997) conducted an observational study, using the RATM simulation. An extract from their data, involving the aircraft TAW is shown in Figure 6. The data can be used to diagnose design problems. For example, in the case of TAW, the data indicate its initial state to achieve desired task quality, the separation goal of false (that is, there is desired separation). However, following an operator intervention to improve fuel use, by changing TAW’s altitude (fuel use decreases with increases in altitude), TAW’s actual task quality becomes less than desired, the separation goal false being actually 1830 (that is, less than desired separation). This difference between actual and desired RATM task quality, constitutes the basis for an instance of a RATM design problem.
A further instance of a design problem, diagnosed by means of the domain model (in conjunction with a RATM worksystem model, proposed by Timmer and Long (2002)) appears in Figure 7. The RATM data have been collapsed to highlight the design problem diagnosis. The final state of the data shows actual performance to be less than desired Figure 5. Domain model of reconstructed air traffic management. performance. ZEN is safe, but unexpeditious (excessive progress and fuel use). The likely reason is that earlier, ZEN was expeditious, but unsafe (see domain model attribute values of Figure 4). The operator intervenes to speed up ZEN, so making it safe. However, the operator fails to update the flight progress slip, which continues to show ZEN at its cruising speed of 720. Exceeding the cruising speed results in excessive progress and fuel use. The operator’s earlier recognition of ZEN as an active, safe and unexpeditious (as concerns speed) aircraft, but subsequent failure to increase to slow down ZEN, is assumed to be associated with the decay of the unexpeditious category in memory and the flight progress strip showing (incorrectly) ZEN to be flying at cruising speed.
Figure 6 Reconstructed air traffic management data showing
Domain model attribute states and RATM Worksystem behaviours
Although Timmer and Long do not prescribe a design solution in detail, they do speculate about RATM re-design options. For example, a procedure, requiring immediate flight progress strip update, might solve the design problem. Alternatively, or in addition, an explicit display by the RATM interface of speed, progress and fuel use, which link position, altitude, speed, heading and time attributes to safety and expedition (see Figure 4) might also solve the design problem. If so, RATM actual performance, as concerns task quality, would equal desired performance.
In both cases, the new flight strips procedure and the re-designed interface would have implications for the usability/workload of the RATM system/operator. However, any such implications are not co-extensive with RATM task quality as expedition and safety. The illustration, thus, makes clear how the domain approach, expressed as task quality, goes beyond usability and how the explicit domain model can support design.
Figure 7 Reconstructed Air Traffic Management design problem (collapsed data)
4. Discussion and Conclusions
Both implicit and explicit domain models constitute HCI design knowledge. Such knowledge is intended to support both design and research. HCI design, as shown by the earlier illustrations, can be conceived as the diagnosis of design problems and the prescription of design solutions (Long, 2001). HCI research can be conceived as the acquisition and validation of design knowledge (Long, 2001). Implicit and explicit models are now assessed for their potential to support design and research.
The illustrations from the domains of medical reception, military command and control and domestic energy management all suggest implicit domain models have potential to support design as both diagnosis and prescription. In contrast, these implicit models would appear to have little potential for informing research, other than as a point of departure. Validation of the design knowledge requires its conceptualisation, operationalisation, test and generalisation (Long, 2001). Since these models are implicit, they are not (explicitly) conceptualised. Hence, they cannot be operationalised, tested and generalised, and so validated.
The illustrations from the domains of off-load planning, emergency management and air traffic management all suggest explicit models have potential to support design as diagnosis and prescription. Note, however, that these explicit domain models express only task quality, that is, performance. They do not describe the worksystem behaviours, neither those of the user nor of the computer, determining performance. Additional models are required to represent the latter. The explicit models would also appear to have the potential for informing research
As the domain concepts are explicit, the models meet the requirement of research for conceptualisation. Since conceptualised, the models offer the potential for operationalisation, test and generalisation, and so validation. It is concluded that both implicit and explicit domain models of work have the potential to support design practice as diagnosis and prescription. However, the nature of the support is different. Implicit models support (re-)design of the instance (that is, the particular work system, for example, the medical prescription system of Drs. I. and J. (see earlier) ). In contrast, explicit domain models express the instance as a member of the class (that is, the domain model of air traffic management of which Manchester Ringway is an example (see earlier) . Explicit model support for design is thus more than implicit model support. In contrast, explicit model support is more limited, as it expresses only performance (as task quality) and not the worksystem itself. As concerns research, only explicit domain models have the potential to provide support, because implicit models cannot be validated, in the absence of conceptualisation. Implicit domain models, however, can be the starting point for explicit domain models, developed by research.
It is concluded, generally, that implicit domain models are needed in the shorter term, to inform design of individual work systems. Explicit domain modelling is in its infancy. However, explicit domain models offer the possibility of validation by research and so a better guarantee, in the longer term, of support for both design and research. The importance of explicit domain models needs to be underlined and its further development encouraged. However, both implicit and explicit domain models can be considered as part of the domain approach to HCI. This approach accepts that usability and Web pages are rightly both central to HCI at this time. However, task quality – how well the work is done, derived from domain models, that is, performance, goes beyond usability, conceived either as a property of the computer or as the property of the user, that is, workload. The domain approach also goes beyond the new technology of Web pages. The Web is essentially an information provider with design problems and solutions, concerning access, navigation, etc. It also currently offers, in addition, a range of services, for example, ecommerce, insurance, banking, holiday and flight booking, etc. However, work such as air traffic management, emergency management and amphibious off-load planning are well beyond its current capability. It is concluded, then, that the domain approach goes beyond the usability of Web pages – the thesis of this paper. Finally, the arguments and the illustrations suggest that the domain approach shows promise in its support for an engineering HCI discipline, whose aim is design for effectiveness and whose design knowledge offers a better guarantee of its application.
Acknowledgements:
For conceptual foundations – John Dowell. For the research – all first authors of illustrations. For paper realisation – Doris; Natalie; Rhunette; Beverley; Minna and Jacky.
4. References
BEKKER, M.M. & LONG, J. User Involvement in the Design of Human-Computer Interactions: Some Similarities and Differences between Design Approaches. In Proceedings of the British Computer Society Human-Computer Interaction Specialist Group, 2000.
CARD, S.K., MORAN, T.P. & NEWELL, A., The Psychology of Human-Computer Interaction, New Jersey, Erlbaum, 1983.
COLBERT, M. & LONG, J. Towards the Development of Classes of Interaction: Initial Illustration with reference to Off-Load Planning. In Behaviour & Information Technology, 15 (3), 149-181, 1995.
Home Office. Dealing with Disaster, 2nd ed. Home Office Publication, London, HMSO, 1994.
DOWELL, J. Cognitive engineering and the rationalisation of the flight strip. Unpublished PhD Thesis, University of London, 1993.
DOWELL, J. Formulating the design problem of air traffic management. International Journal of Human-Computer Studies, 49, 743-766, 1998.
DOWELL, J. & LONG, J. Target Paper: Conception of the Cognitive Engineering Design Problem. Ergonomics, 41 (2), 126-139, 1998.
DOWELL, J. & LONG, J.B. Towards a conception for an engineering discipline of human factors. Ergonomics, 32, 1513-35, 1989.
DRURY, M. The medical secretary’s and receptionist’s handbook, 4th ed. London, Bailliere Tindall, 1981. EVANS, M.H.H. Amphibious operations. London, Brassey’s, 1990.
GREEN, W. S., & JORDAN, P. W. Pleasure with products: Beyond usability. London, Taylor & Francis, 2002.
HILL, B. & LONG, J. A Preliminary Model of the Planning and Control of the Combined Response to Disaster. In Proceedings of ECCE 8, 57-62, 1996.
HILL, B. & LONG, J. Performance Modelling in the Domain of Emergency Management. In M.A. Hanson, (Ed.). Contemporary Ergonomics 2001, 165 – 170. London, Taylor & Francis, 2001.
HILL, B., LONG, J., SMITH, W. & WHITEFIELD, A. A Model of Medical Reception – The Planning and Control of Multiple Task Work. Applied Cognitive Psychology, 9 (1), 81-114, 1995.
JEFFREYS, M. & SACHS, H. Rethinking General Practice: Dilemmas in Primary Health Care. London, Tavistock, 1983.
LIGHT, A. & WAKEMAN, J. Beyond the interface: users’ perceptions of interaction and audience on websites. Interacting with Computers, 13(3), 325-351, 2001.
LONG, J. Specifying Relations between Research and the Design of Human-Computer Interactions. International Journal of Human- Computer Studies, 44 (6), 875-920, 1996.
LONG, J. Cognitive Ergonomics: some lessons learned (some remaining). In M.A. Hanson, (Ed.), Contemporary Ergonomics 2001, 263 – 271. London, Taylor and Francis, 200.
LONG, J. & TIMMER, P. Design problems for cognitive ergonomics research: What we can learn from ATM-like micro-worlds. Le Travail Humain, 64(3), 197-222, 2001.
LONG, J.B. Domain Approach for Decision Support for Planning and Control: a Case-Study of Amphibious Landing Off-Load Planning. In Proceedings of APCHI 2000, 2000.
NEWMAN, W. A preliminary analysis of the products of HCI research, using pro forma abstracts. In Proceedings of CHI ’94, 278-284, 1994.
STORK, A. & LONG, J.B. A Specific Planning and Control Design Problem in the Home: Rationale and a Case Study. In Proceedings of the International Working Conference on Home-Oriented Informatics, Telematics and Automation, 1994.
STORK, A., MIDDLEMASS, J. & LONG, J. Applying a Structured Method for Usability Engineering to Domestic Energy Management User Requirements: a Successful Case Study. In Proceedings of HCI’95, 367-385, 1995.
TIMMER, P. & LONG, J. Expressing the effectiveness of planning horizons. Le Travail Humain, 65(2), 103-126, 2002.
TIMMER, P. & LONG, J. Integrating Domain and Worksystem Models: An Illustration from Air Traffic Management. In Proceedings of the Conference on Domain Knowledge in Interactive System Design, 194-207, 1996.
TIMMER, P. & LONG, J. Separating User Knowledge of Domain and Device: A Framework. In Proceedings of HCI’97, 379- 395, 1997.