Task-related information analysis

Int. J. Human—Computer Studies (1997) 47, 223—257

Task-related information analysis ALISTAIR SUTCLIFFE Centre for HCI Design, School of Informatics, City University, Northampton Square, London EC1V 0HB, UK. email: sf [email protected] (Received 11 March 1996 and accepted in revised form 31 January 1997) Task analysis methods have paid little attention to specification of information displays. A method is described for analysing task-related information needs linked to design of information displays. The method starts by defining users’ requirements with information types. These are added to the task model to specify what type of information is required during the task. The next step selects appropriate means of information delivery according to the users’ needs. Different information access and display paradigms, e.g. hypertext, data retrieval and display media are considered. The method is illustrated with a case study of a shipboard information system. ( 1997 Academic Press Limited

1. Introduction A neglected part of human—computer interaction is design of the presentation interface. Although guidelines offer advice about the display ergonomics (Galitz, 1994), and standards are being prepared for interface presentation (see ISO 9241, part 12), there is little help for designers in HCI methods when it comes to analysing and specifying information displays. Task analysis methods, e.g. TAKD (Diaper & Johnson, 1989) and TKS (Johnson, 1992), do not explicitly define users’ information requirements; however, task models produced by such methods do describe objects which may become the subject matter of the presentation interface. Structured system development methods give data models such as entity relationship diagrams but only general heuristics for screen design, e.g. SSADM (Downs, Clare & Coe, 1991). Clearly, there is a need for methodical guidance to define users’ information requirements in the context of task analysis, synthesize this with data modelling and then produce specifications of the presentation interface. This paper aims to address this need by proposing a method for task-based information analysis. The initial motivation stems from the needs of the INTUITIVE project which developed information retrieval tools for multimedia databases. Information retrieval may be general, i.e. searches for information linked to goals of learning or entertainment, but frequently it is embedded in a task context. This implies that information requirements should be specified in a task-sensitive manner. Several different means of delivering information have been proposed ranging from standard displays to hypertext/hypermedia and information retrieval languages. Hypertext and information retrieval tools are usually considered as separate technologies which bear little relationship to applications or the tasks contained therein. A further motivation for this paper is to address information provision in a unified manner which integrates the disparate technologies of hypertext, multimedia, information retrieval (IR) 223 1071-5819/97/080223#35$25.00/0/hc 970118

( 1997 Academic Press Limited

224

A. SUTCLIFFE

tools and custom-designed displays. In many applications, a combination of all three may be necessary. Linking data modelling, task analysis and HCI design has been proposed by Benyon (1991), and there have been some suggestions about using entity relationship analysis as a basis for design of graphical user-interface displays (Sutcliffe, 1988). Lim and Long (1992) have described a framework for integration of HCI and software engineering methodology which shows where presentation design should fit into the design process, although they offer only general advice about how this may be achieved. Information receives passing attention in user-interface design methods, e.g. STUDIO (Browne, 1994) proposed a few heuristics for eliciting information requirement in task analysis but no recommendation on design of information-intensive interfaces beyond guidelines on window layout. Extensive guidelines on presentation design have been published (Galitz, 1994; ISO 9241, part 12), however, these are linked to an analytic process so they offer little help in determining what information should be presented. Some proposals were made by Sutcliffe and Wang (1991) to integrate information requirements in the specification of human computer dialogues; however, these did not address the problem of specifying those requirements in the first place. This paper takes these proposals forward by developing a method for defining information requirements and specification of the presentation interface. The paper is organized by describing the method in three main sections: analysis, presentation strategy and interface specification. Application of the method is illustrated in each section by a case study carried out in ESPRIT project 6593, INTUITIVE. Finally, the implications for further method development are reviewed.

2. A method for task-based information analysis Information analysis presupposes a task analysis method. As it is not the intention of this paper to devise yet another task analysis method, the recommendations can be applied to specific methods such as HTA (Annett et al., 1971) or TKS (Johnson, 1992). Furthermore, as interface specification should be a normal part of structured systems analysis, information analysis should be easy to incorporate in structured methods such as SSA (De Marco, 1978) or SSADM (Downs et al., 1991). 2.1. TASK ANALYSIS

The basic assumption is that task analysis proceeds by top-down functional decomposition. Most task analysis methods create a hierarchy of goals, composed of subgoals which in turn contain procedures, actions and objects. There are variants on this approach, such as addition of pre- and post-conditions for procedures (e.g. TKS in Johnson, 1992) and more object-oriented views, such as Methode Analytique de Description (Pierret-Golbreich, Delouis & Scapin, 1989). As the functional decomposition is also practised in structured systems analysis (De Marco, 1978) and similar methods familiar to many software developers, information analysis should be easy to integrate within mainstream software engineering. The question to be resolved is how units of information are to be specified and then related to the task structure.

TASK-RELATED INFORMATION ANALYSIS

225

Before proceeding further, a classification of information types is proposed for describing information requirements. 2.1.1. Information types Information types are proposed as ‘‘tools for thought’’ to help refine descriptions of the necessary content. The motivation is to provide informal categories which help assessment of what type of information is required to support user and system tasks. A pragmatic approach is taken to classifying information starting with entity-relationship-type data, facts in text-based documents and progressing to more complex information such as task-related knowledge, i.e. how to do something and abstract facts referred to as concepts. Information can broadly be divided into static data about objects and dynamic data describing actions, events and changes in the environment. Information types are based on the schema of task knowledge structures (Johnson, Johnson, Waddington & Shouls, 1988; Johnson, 1992) which also makes the distinction between dynamic task knowledge and static domain knowledge structures (DKS), composed of object hierarchies. The following information types extend DKS/TKS definitions, and are listed in approximate ascending order of complexity. Attributes. Data items or isolated facts which describe an object, its status and history. Attributive information can be sub-typed into status, historical, descriptive, spatial and quantitative information, e.g. a person has a title, a record of employment, address, religious belief, a job location, height, weight, etc. »alue domains. Values which belong to attributes, e.g. salary in the value domain of £ 0—20 000. Domain properties. Facts or states pertaining to the universe of discourse which are not associated with any particular entity, e.g. information about physical structures and spatial distributions, e.g. air corridors on a map of the airspace for air-traffic control. Propositions. Assertions about some truth or state of the universe of discourse. For instance, a cup may have attributes of volume, colour and material, but assertions about its use, e.g. ‘‘holds liquid’’, ‘‘is used for drinking’’ are propositions. Entities. Information identifying some ‘‘thing’’ of interest in the universe of discourse, be it a concrete object (a customer, ship, aircraft) or a conceptual thing (e.g. mortgage, bank account, reservation). A sub-type of complex entities, distinguished as ‘‘structures’’, model composite sets of physical entities and their relationships, e.g. aggregations such as components of a machine—engine, gears, levers, etc. Relationships. Links between entities which indicate some functional dependency, e.g. computer system—is designed by—software engineer. Concepts. These are based on high-level objects and their relationships. Concepts are higher-order aggregates of objects, relationships and dynamic information which explain some part of the world; e.g. knowledge about how an object works or a rationale for what causes its behaviour (e.g. explanation of how the rainbow spectrum is created). Dynamic information types are also ordered by complexity. Actions. Elementary mental or physical activities, e.g. check order, select supplier, evaluate risk, allocate materials. Note that this is information as a description about how to carry out an action.

226

A. SUTCLIFFE

Events. Messages recording some change of state in the world. These may be regarded as triggers for action or as a transient datum which does not belong to an object, and is therefore more closely related to static information. Rules. Have a condition consequence-action structure and express activity declaratively rather than in procedures; e.g. if book loan date is more than 30 days ago then recall book from loan. Heuristics. Rules of thumb which have a less deterministic consequence, i.e. the action is advisory and may or may not have the desired effect; e.g. if tasks cannot be described in 10—12 lines of procedure then try further decomposition. Procedures. Knowledge composed of actions and objects organized with the control constructs sequence, selection and iteration, e.g. procedures for allocating loans to bank customers, calculating interest payments. Plans. Higher-level goals which are organized in an order, e.g. plans for organizing workload allocation in an office. The categories are informal definitions to preserve ease of use which more formal definitions may impair. The taxonomy helps to identify the necessary source of information and whether information may have to be designed before presentation or if it is more probably accessed in standard databases. This helps planning the match between information requirements and available data resources. For instance, rules and heuristics may have to be constructed specifically for the application; propositions and concepts are more likely to be text-based explanations derived from bibliographic sources; and entity-relationship information is more readily accessed from standard databases. Event information has to be captured from external sources, while plans and procedures come from task analysis. Task models may be available in instruction and training manuals.

2.2. INFORMATION ANALYSIS

The first part of the method specifies task-related information needs. Figure 1 gives an overview of the method stages. In practice, task and information analysis proceed concurrently. This stage may be integrated with either data analysis or task analysis using interviews, observations and investigation of source documents where appropriate. The main objective of information analysis is to specify what type of information is required during a task. The process starts with requirements analysis. In common with the early stages of any system investigation, users’ needs are often vague, incomplete and may reflect individual viewpoints (Pohl, 1993; Jarke, Bubenko, Rolland, Sutcliffe & Vassiliou, 1993). The first part of the method concentrates on eliciting information to classify information requirements in their task context. It should be noted that some requirements may be for information needs alone. The information/knowledge types are used in ‘‘walkthroughs’’ in which the analyst progresses through the task model asking questions about information needs. At each step the level of the required information/knowledge is assessed, although the quantity and quality of information may need to be modified in light of the user’s knowledge. For instance, trained users will require little task knowledge, whereas novices will require

TASK-RELATED INFORMATION ANALYSIS

227

FIGURE 1. Method overview, shown in dataflow diagram format.

considerable knowledge as prompts and instructions. The walkthrough uses lower-level goals in the task hierarchy (i.e. sub-goals which are not decomposed further), as follows. 1. Progress through the task description for each sub-goal to determine answers to the following questions. f f f

What are the information inputs to this task-goal? What are the information outputs from the goal? What other information is required to achieve this goal?

228

A. SUTCLIFFE

If structured analysis (De Marco, 1978) is being used, datastores and dataflows in DFD diagrams are good indicators of information required by a task process. Requirements are identified from the input and output dataflows, combined with descriptions of the datastores. Input dataflows contain messages coming from external sources or other sub-tasks. Information from files (or datastores in SA/SD terminology) implies data retrieval from a database or file. The analysis is then refined at the procedure-action level where necessary. Information may be a necessary input for, or created by, task action, i.e. output. Other information may be required throughout the task; e.g. continuous monitoring data, or knowledge about how to carry out the task. 2. For each goal check each action within the procedures to ascertain the following. f f f

f

f

What input information is required for this action? What output information is produced by this action? Is any other information required to help the user complete this action? At each selection or iteration step. Is any information required to help the user take a decision? and for the whole procedure. Is any information required throughout the procedure?

Input for actions will usually be simple data, although for more complex actions several information types may be required. Similarly, decisions may require a single fact or attributes from several entities to be tested for a complex decision. The quantity of information will depend on the granularity of the task analysis as well as the complexity of the domain. In structured analysis some of the necessary information may be contained in mini-specifications, so procedures and decisions (selections) may become part of the information requirements specification rather than being used to specify system functionality. This decision depends on judgement about task allocation; if the task remains a human responsibility, information requirements will predominate, whereas if the task is to be automated, mini-specs become functional requirements and data structures. One of the purposes of task analysis is to design computerized support for the user’s job of work. Tasks may be either fully automated, partially automated or allocated to human operation (see Gardener, 1988). In fully automated tasks, information requirements simply become input data for a software process, while for human operation, information may be input for the task in hand or descriptions of the task itself as operational procedures. In partially automated tasks, information output from a software process may be required to support users’ activity. Definition of information requirements is therefore bound up with the process of task and dialogue design. Although requirements should, ideally, be described without prejudice to an implementation, defining information needs often necessitates a view about the implementation. For automated processes, simple input data items will be most common. This may also be true for simple, physical human actions, although human cognitive actions in problem solving may require support with more complex information. Furthermore, in user-operated tasks, novices will require considerable task knowledge to help them operate a system with more information for training purposes. Allocation of information types is therefore liable to be iterative as the interface design progresses. An important distinction to bear in mind is whether information is required as part of the task or if

TASK-RELATED INFORMATION ANALYSIS

229

information is needed to help the user to perform the task. To illustrate the point, consider the following. Operational information. Required as input for processing; hence for the task action ‘‘locate hazard’’ the necessary information is the hazard type and compartment-id. ¹ask support information. May be required to help a user carry out the task, although it may not be necessary for all users, so for the sub-goal ‘‘decide counter measures’’, a set of heuristics could be provided to give the captain ideas for containing and dealing with the hazard. The following questions can help elucidate needs for operational and support information in manual and semi-automated actions. f f f

What information does the user need to carry out the action manually? What information should the user supply the computer as input? What supporting information should the computer supply to help the user complete a task-action?

The answers to these questions are linked to specification of the presentation interface, so the needs will unfold gradually as the nature of the task support is clarified. Another important need is to discover which data items are vital for task operation. This will feed through into presentation design for highlighting key information for the users’ attention. Goals and sub-goals in the task model are annotated with information requirements and cross referenced to a list of information types. Many information requirements may be available in standard DFDs, e.g. from the description of dataflows and datastores. However, information analysis will add additional requirements that structured analysis would omit, such as the need for rules to carry out the task itself. Annotating the information requirements on the task also makes the design implication explicit when the task is transformed into a user-system dialogue. 2.2.1. Shipboard information system case study The case study of an information system for shipboard emergency management is used to illustrate each method stage. Initial fact capture was carried out with eight practising ship’s captains using scenario elicitation techniques (Hobday, Rhoden, Bright & Earthy, 1994). Initial interviews were conducted to gather requirements in which the captains were asked to talk through how they would deal with an emergency such as a fire on board. The analysts took notes and then replayed the preliminary task model back to the captains for clarification and asked follow-up questions about the domain knowledge necessary for decision making and completing the emergency control task. In this application the ship’s captain has to control an emergency and give orders to the crew to deal with a fire hazard. Once the immediate hazard is over the captain has to assess the damage and check on any cargo damage, and possible injuries to passengers and crew. The requirements for decision-support information during the emergency control task have to be analysed and specified. Secondary requirements are for a more general information system covering cargo and ship’s complement to be used after the emergency in the ‘‘stabilization’’ phase.

230

A. SUTCLIFFE

FIGURE 2. Data flow diagram illustrating analysis of the manage emergency task.

TASK-RELATED INFORMATION ANALYSIS

231

The task model at this stage is recorded as a data flow diagram, illustrated in Figure 2, which shows the task goals and information flows. The overall task deals with a shipboard emergency. This decomposes into sub-goals for locating the problem, evacuating personnel, mustering emergency crews and managing hazard. Each sub-goal is decomposed further, hence locating the problem has lower-level goals for deciding hazard type, locating hazard and evaluating problem. The low-level goals are described in further detail as procedures which have been omitted for brevity. 2.2.2. Case study: information analysis An entity-relationship diagram of the ship’s data is shown in Figure 3. Some of the data will be fixed (e.g. the ship’s diagrams); however, most of the data will be updated at the instance level (e.g. the crew details will change), hence information requirements cannot be completely ascertained at design time. The next step is to allocate responsibility for the task. Most of the sub-tasks require human judgement so little direct automation is appropriate. The computer system needs to provide decision support to help the captain check that the appropriate actions have been carried out. Task support is also required for status monitoring, and more general information retrieval once the immediate emergency is over. The analysis from the information needs, using the walkthrough technique, yielded the task model shown in Figure 4. The information needs associated with a subset of the task-goals is given below, with the full version in Appendix 1. Goal: Analyse hazard Information input:

Information output:

Notified hazard Semergency type, status, location, compartmentT Hazard description Semergency type, hazard properties, danger warningsT Hazard procedures Analysed problem Shazard type, properties, location, statusT Emergency msg Sdanger signalT Evacuation plans Sinstructions, locationT

The information types are attributive and locational information about the entities ‘‘hazard’’ and ‘‘emergency’’ procedures. Event information on the hazard location has to be acquired from external sources, either automatic fire sensors or telephone communication from crew members. Output informations are procedures and attributes of the hazards. As the tasks will be only partially automated, information will be required for decision support. Goal: Decide countermeasures Information input:

Information output:

Analysed problem Shazard type, properties, location, statusT Ship’s plan, Cargo location SdiagramsT Emergency procedures Shazard type, action list, warningsT Emergency management heuristics Shazard typeT Appropriate measures Sinstructions, action list, warningsT Crew moves Sinstructions, locationsT

232

A. SUTCLIFFE

FIGURE 3. Entity relationship diagram: ship emergency control domain.

In this task, information is needed on how to deal with an identified hazard type. Procedural, object attribute and spatial information is required, implying access to text databases for hazard-management procedures, relational type data on cargo and possibly image data on the ship’s layout. 2.3. DOMAIN ANALYSIS

The purpose of domain analysis is to add further details about the system context which may not be captured in data models or a task analysis. Domain modelling is a necessary step for any interface design. It supplies physical and structural information for design of graphical-user-interface metaphors, patterns of communication between users for distributed and group work applications, and the distribution of users and objects they use in a work system. The first step is to gather facts about the user’s model of the domain. This may be referred to as the domain model, or the user’s model of the system (Norman, 1986). It contains entities and structural information about the physical context of the system. This model suggests the main metaphor of the application, which in most cases will be a picture of the physical context of the system, e.g. the ship for emergency management or anatomy of the human body for a medical information system. Domain models are recorded informally as sketches and drawings of the physical layout of objects in an application domain. These can be acquired by asking the user to sketch pictures of the domain and draw attention to important objects and their associated functions. To supplement information recorded in the data model and

TASK-RELATED INFORMATION ANALYSIS

FIGURE 4. Information analysis for the manage emergency task.

233

234

A. SUTCLIFFE

provide more context information for the task, lists of important entities, entity structures and agents are drawn up using the following questions. f f f f

Where (in what location) is the task carried out? What material entities and resources are implicated in task operation? What agents (human or automated) carry out the task? What physical structures and entities are necessary to understand observed task action?

It is not the intention of this paper to give an in-depth coverage of domain analysis (see Sutcliffe, 1995 for more details). The main purpose of domain models for presentation design is to suggest interface metaphors. This involves investigating the important entities associated with the user’s work. Task actions become specifications for direct manipulations; however, for presentations design, the key facts are which entities and structures to represent and what information should be linked to icons and other information providing cues on the UI image. Hotspots and selectable parts of the UI metaphor image can be pointed at to activate preformed queries or hypertext links. Domain models are used to link task-actions and the information associated with objects in the UI image. 2.3.1. Case study: domain analysis The entity structures in this case were the ship in which the emergency takes place and the task environment, the bridge where the captain has all the necessary communications at hand and the compartments, cargo holds and containers where fire hazards could be located. Task-related entities included muster points for emergency crews, evacuation pathways, hatches, ventilation shafts and emergency appliances. The list of structures and entities is as follows. Ship environment Structures: Compartments, Decks, Hull, Superstructure Entities: Compartments, Cargo-containers, Emergency appliances, Bridge environment Structures: Bridge layout, Chart table, Navigation instruments, Communication devices (radio). Entities: Sensors, Warning Devices, Communications-radio The links between entities Compartment Emergency appliances Sensors Radiocommunications

and task goals are the following. Locate hazard, Give instructions, Muster crews Muster crews, Instruct crews Locate hazard, Operate controls Instruct crews, Give instructions, Muster crews

The bridge environment was not necessary as an interface metaphor because most of the information-related objects are found in the ship environment. Therefore, the main interface metaphor was chosen to be a concrete representation of the ship in diagrammatic form showing the compartments, cargo and emergency appliances. The category analysis examined the entities already identified (see Figure 3). However, a standard data analysis does not advise modelling categories in text-based data, e.g. the hazard and

TASK-RELATED INFORMATION ANALYSIS

235

emergency procedures. The TIM method identified that categories should be added for this text-based information. Furthermore, many items of interest to the user are not explicitly specified by data analysis. For instance, compartments were treated as an attribute of the ship entity in the initial data model; however, information and domain analysis demonstrated that they were important in location-type questions. Compartments therefore needed to be modelled more explicitly. This suggested that the main metaphor of the ship diagrams should show details of compartments from different views. 2.4. INFORMATION RESOURCES ANALYSIS

So far the method has captured the user’s information requirements; the next stage is to describe the available resources to satisfy those needs. It is necessary to decide whether the required data can be accessed by database queries or found in a paper form (e.g. report or instruction manual). Electronic data resources may be in relational or text databases, or in other physical media such as digitized images. Other data sources may have been identified during task/domain analysis and are therefore readily available as documents or scanned text/images. However, the resources may not exist for some requirements and these will have to be created by the designer. This step involves mapping the identified information needs to the target data resources. The method then proceeds to design the presentation interface in light of the requirements and resources by selecting displays, hypertext, data-retrieval languages or a mix of these methods. 2.4.1. Case study: information resources The available resources were the following. 1. A text database on emergency procedures, describing the actions to deal with particular types of hazards. 2. Relational data on ship’s cargo, with details of cargo owners, cargo descriptions, notes on hazards, container location. 3. Personnel data, ship’s crew including name, rank, responsibility and training records. 4. Image data in the form of diagrams of the ship’s architecture, showing compartments, labelled with their approximate contents, entrances and location of important equipment. This implies the image resource will have to be semantically encoded with identities of equipment, entrances and contents. A further need is for access to a text database containing descriptions of dangerous chemicals and other hazardous cargo indexed according to International Maritime Organization hazard types. Access is by keyword search using the emergency descriptions. As the ship’s diagrams existed, these were used for developing screen metaphors showing the locations of objects and pathways between compartments. The diagrams had to be designed as an information resource by creating an image encoded to identify compartments, location of appliances, hatches and pathways between compartments.

3. Selecting the presentation strategy Information may be presented as hypertext, screen displays or retrieved by query languages. For many applications a mixture of techniques will be required depending

236

A. SUTCLIFFE

partly on the users’ requirements, but also on the nature of the data resources and task context. This part of the method starts the design phase by selecting the presentation styles which may be required. Selecting presentation styles involves comparing the resources’ properties with the requirements. Information resources are classified into the following. Static. The data are not expected to change during the lifetime of the application. Dynamic-instance. The data may change at the instance level although the type will remain constant. Dynamic-schema. Data types, i.e. entities in the schema may change, as well as instances. A further permutation is that instance level data within certain media types may also change, e.g. an image may be edited. The changeability of resources impacts on presentation design. Dynamic data can only be accessed by a query interface because updating at the instance and probably schema level makes design of display screens difficult. The type of information may be identifiable, but the instances are impossible to predict because of continuous database updating. Dynamic schema changes imply redesign to the database; in that case the only option is to provide a query language or, more ambitiously, a monitoring process for schema change which alerts the user to update a presentation design. Such adaptive designs are beyond the remit of the method in this paper. If the information resource contains data which are updated frequently, then detailed design of a static display will not be possible. In this situation, the problem changes to specification of an information access interface. How the data are presented depends on the tools available for presentation. While the presentation can be planned in outline, e.g. the approximate order and location of presentation windows, detailed design of formats is only possible if preformed templates can be used. 3.1. PLANNING INFORMATION DELIVERY

Table 1 gives a comparison matrix for selecting the appropriate mix of presentations from the following design alternatives. Information displays. These are hard-coded into a dialogue so the information display will be the same each time. Some decoupling can be achieved by updating the display contents on a disc file; however, changing the display content requires some intervention. Preformed-queries. The contents of these displays are determined by a preformed query which is known at design time but executed at run time. The content of these displays is therefore determined dynamically according to the state of a database. Query templates. These are a variation of preformed queries which allow some user configuration, so the entity and attributes may be specified but the user has to complete the constraint clause with attribute values, e.g. Find Cargo in Compartment S T. ¸inked-queries. The display contents are determined by preformed queries but links to related information requirements are added, so the interface functions as a hybrid between hypertext and a query language.

237

TASK-RELATED INFORMATION ANALYSIS

TABLE 1 Decision matrix: information resources analysis and presentation planning Information resources Requirements

Static

Dynamic instance

Dynamic schema

Single item†

Displays

Preformed queries

Query templates Query language

Information group†

Displays

Preformed queries

Query language

Linked items‡

Hotspots linked displays

Linked queries

Pathway‡

Hypertext

Linked queries

Unpredictable

Query language

Query language

Query language

† Sequential ‡ Non-sequential

Hypertext. Follows the standard definitions as a nonlinear, linked set of data resources. Query languages. Any open-ended query language which allows full syntactic and semantic expression of data retrieval needs. For most databases this will be SQL. If query patterns cannot be determined beforehand, then an information retrieval language (e.g. SQL) will have to be used; however, assuming that questions can be predetermined, it should be possible to associate them with specific steps within the task. The two design possibilities are the following. 1. To embed queries for automatic triggering during the user-system dialogue. When a user action is completed, the system automatically triggers a data retrieval request to the target database. The system presents the results as the next dialogue step. 2. Provide query submission under user control. In this case a sub-dialogue is designed to allow the user to pick queries on demand. Queries are presented in menus which may either be separate from the main-task-related dialogue (i.e. in a hierarchy of menus as a query sub-system) or linked to the main dialogue. In the latter case, completion of a user action causes the system to display a query menu appropriate to the task stage. The first decision (see Table 1) is to enquire whether the information needs are known at the instance level or not. If the answer is yes, then the designer proceeds to create an information display to support that task step. If the answer is no, then only the type of information can be ascertained at design time. The source of the information has to be identified and the instances extracted by database queries at run time. If associated

238

A. SUTCLIFFE

information needs have been identified then either a linked-query or a hypertext interface will be necessary, depending on how stable the data resources are. When requirements are difficult to determine or the data resources are very volatile then the only resort is to a query language. The choice may involve a mixture of static presentation and dialogue for links between information. Static information displays. All information needs are known and displays can be ‘‘hard-coded’’ into a dialogue or as a datafile read into the application. Another option is to predefine questions for retrieving the necessary information. In this case, the designer has to decide how to interleave information presentation within the dialogue. ¸imited question formulation and display. Questions are known in advance but their submission is under user control. The design options are to place questions in explicit lists (menus, radio buttons, etc.) or to embed the question triggers as hotspots in the GUI. Questions and linked information are required. Questions and follow-up information needs are known although the exact question path must be under user control. The design options are to use linked question lists or a hypertext interface. The decision table is used to plan the presentation interface, which will probably require a mixture of different solutions within one application. 3.2. SELECTING PRESENTATION MEDIA

When different media resources are available another strategic choice is which medium should be chosen to deliver an information need. Task characteristics can influence the resource used; e.g. rules and heuristics information are appropriate for reasoning and decision-making tasks. These information needs imply linguistic information as textbased resources or speech. In contrast, visual information is suitable for spatial tasks involving moving, positioning and orienting objects, so image resources will be appropriate. Selection rules, based on experimental research in media perception and cognition in psychology (Sutcliffe & Faraday, 1994a; Bernsen, 1994) and tested in multimedia explanation systems (Fiener & McKeown, 1993; Andre & Rist, 1994) are proposed to guide choice of resources according to the match of information types and resources as follows. SR1: If the task sub-goal requires spatial information then prefer visual media resources. SR2: If the task sub-goal requires information for physical procedures then select visual media resources. Use animation for complex action sequences, and still image with simple actions. SR3: If the task sub-goal requires abstract procedural information then prefer linguistic media with speech for simple, short operations and text for complex, longer procedure. SR4: If the task sub-goal requires attributes with descriptive information for situation, physical objects, then prefer visual media with still images; abstract object properties or values, then prefer linguistic media. SR5: If the task sub-goal requires rules or heuristics for decision making then use linguistic media as text. Speech may be used, but beware: speech is not persistent.

TASK-RELATED INFORMATION ANALYSIS

239

SR6: If conceptual information is required then prefer linguistic media as text but also use image media for illustrations if available. SR7: For event information use audio media for sound warning but present the context of event messages using text for descriptive/status information and image for physical/spatial detail. SR8: For propositional information use linguistic media as text with image illustrations if available. SR9: Entity and property information with values implies relational tabular information; descriptive property information implies text resources. SR10: Relationship information should use diagrams to show associations with text captions to describe the relationships. Using these rules the task information model is consulted and the relevant media resources are matched to each sub-goal. Important considerations are addressability and unit size of resources. These affect the potential for designing media and information units. Unit size dictates how much hypertext nodes or database records will contain, whereas indexing determines how they may be accessed. For example, if information is required about objects within an image this data will usually have to be semantically encoded on to the image. If text is accessible in paragraphs several different combinations are possible, whereas if the resource is only accessible as a whole document then the design alternatives are limited. Occasionally, the necessary information or knowledge may not exist. Furthermore, complex information may not be readily available in documents or existing databases. Task-related knowledge can be acquired from the task analysis; however, conceptual and propositional knowledge may have to be specially designed. Requirements for complex knowledge ultimately leads into consideration of an explanation sub-system when information analysis is used in conjunction with a knowledge analysis method e.g. KADS (Wilenga, Van de Velde, Schreiber & Akkermans, 1993). Treatment of this problem is beyond the scope of this paper. 3.2.1. Case study: presentation strategy Databases were available for text procedures for dealing with hazards, relational data on the ship’s cargo and crew with image resources for diagrams of the ship’s architecture. The cargo and crew databases changed at the instance level, as did the procedures, although less frequently. Static presentations were therefore not possible. The users’ task had two phases, an initial safety critical phase in which information had to be available on demand or the need anticipated and a second stabilization phase when information seeking is not time pressured. For the first phase, preformed queries were the only feasible solution to information seeking under time pressure, hence a touch-sensitive screen displaying the ship’s diagram was specified with preformed queries on the contents of each compartment. This display with an aide-memoir checklist of emergency control actions formed the emergency control interface. The possibility of anticipating the captain’s information needs was investigated. The design possibilities considered were automatic information provision on the hazardous content of a compartment and emergency equipment in the proximity; however, this depended on reliable identification of the location of a hazard. As

240

A. SUTCLIFFE

this was not always possible, the design concentrated on the second, non-safety critical phase. In the second phase, the users’ needs were as follows. f

f

For information seeking access with general non-task-related questions on shipboard management of cargo and crew. This indicated a query language interface. Task-related queries which were for grouped information and some limited query paths. This suggested a mix of preformed queries and links.

The presentation required a task-related metaphor which supported preformed query access, with a separate interface for more general information seeking. As a decision support system was required, queries were placed under user control in menus attached to task goals; an export facility may be desirable to supply information from databases into models, spreadsheets and formulae for ‘‘what-if ’’-type analysis. Queries about hazard location, cargo and crew were specified as templates to be completed by the user before submission to a database. Constraints on location could be added to customize the query. Alternatively, for more well-determined needs, such as location of emergency appliance and escape routes, queries were completely constructed. Queries are held in a library with pointers to link them to specific stages in the task model, so the task model step ‘‘decide hazard type’’ has queries about different fire types. However, queries may not occur in isolation. Information seeking may start with one question and then progress through linked queries depending on the user’s possible information need. This prompted design of follow-up query buttons which linked crew queries to information related to their training, equipment and location. Likewise, query links between hazard types and procedures to deal with them were specified. The task-related part of the interface was implemented as preformed queries organized in a series of menus. Much of the presentation interface was devoted to information seeking and decision support. The system’s role was to support the captains’s decision making and provide an aide-memoir of procedures rather than automate any part of emergency management. The task model was explicitly represented on the user interface as a checklist of actions. Sub-menus of preformed queries were associated with each action to supply the necessary information. This gave six sub-menus for the task-goals: hazard description, analyse hazard type, emergency procedures, decide countermeasure, hazard procedures and instruct crew. Applying the selection rules to the ‘‘Fight Fire’’ procedure, procedural information is required, and this is assigned to text media as the overall instructions for fire fighting are complex. The ‘‘Find Fire’’ task sub-goal calls upon spatial and descriptive information, so selection rules (SR1 & SR4) favour a still image; while the ‘‘Find Team’’ sub-goal is similar, favouring a still image. The ‘‘Muster Team’’ sub-goal requires spatial, descriptive and physical procedure information to find the team’s location and then guide them to the appropriate compartment. The selection rules favour animation for complex operational procedures.

4. Specification of the presentation interface The presentation interface is specified in tandem with task design, and specification of the user-system dialogue. Specification of displays progresses from the task information

TASK-RELATED INFORMATION ANALYSIS

241

model to information grouping and ordering taking users’ needs into account, e.g. according to the user view of priority, importance, security, etc. The main objectives of presentation specification are the following. f

f

Description of the logical structure of the information and any task-related requirements for its organization including drawing attention to specific items. Specification of when information should be displayed during a task.

The task model has already been annotated with the users’ information requirements in Section 2.2; see also Figure 2. For manual tasks the information requirements feed into the design of procedure manuals, operating instructions and forms. Checklists, notepads, aide-memoir lists and forms design will provide information support for user-operated tasks. The end point is to describe a number of documents which will help users complete the task. For partially automated systems a more detailed level of specification is necessary. First the information requirements have to be related to the dialogue design. The user-system dialogue should be based on the task description, thereby making the design compatible with the user’s expectation of their way of working (Sutcliffe, 1995; Lim & Long, 1992). Hence, the sequence and content of data displays follows the information requirements annotated on the task model. The next problem is to group data into presentation units which can be mapped to UI components and devices, e.g. screens, windows, message boxes and speech generators. To help timing, simple bar chart diagrams (see Figure 5) can be used to specify when information groups should be displayed during a dialogue. This technique cross references presentation units to dialogue actions showing which presentation units should be displayed during dialogue actions, the latter being derived from task actions. The bar chart can be inspected to assess the quantity of information needed for specific task actions. Planning the duration of information presentation is based on the task and integrated with dialogue design. For instance, the action ‘‘Decide Countermeasures’’ requires a considerable quantity of information which presented separately may be difficult to assimilate. However, overlays can reduce the problem by showing the location of cargo on the ship’s plans and displaying only those hazard procedures relevant to the hazard type being dealt with. Use of bar charts helps specify not only the necessary information requirements but also pinpoint parts of the dialogue prone to high information densities. In these dialogue steps further design is indicated to reduce information overloading. The dialogue sequence for opening and closing windows and message boxes is planned for implementation. In the emergency management the ‘‘Take Precautions’’ and ‘‘Operate Control’’ are dialogue sub-sequences which could be mapped to a separate window. However, linear bar charts have their limitations; e.g. in moded dialogues, when the display depends on the system state or dialogue history; presentations may be specified by using a separate diagram for each mode. Different diagramming techniques may be chosen according to preferred notations. For instance, Jackson structure diagrams as proposed by Sutcliffe and Wang (1991) can be used to specify the display requirements as elementary operations associated with each dialogue action. Alternatively, dialogue network diagrams, adapted from state transition diagrams, show information needs attached to states. Continuous information displays are problematic but a duration/sequence convention can be adapted for network diagrams. If statecharts (Harel, 1988) are preferred then information displays can

242

A. SUTCLIFFE

FIGURE 5. Display bar chart cross referencing dialogue actions with the display duration of information.

be annotated on to the appropriate state box, although some care is necessary to differentiate input and output information.

4.1. PLANNING PRESENTATION SEQUENCES

Sequencing the presentation applies to all displays, although the ability to design query language output depends on the formatting instructions provided by the language. When several information needs are identified for one task action a considerable amount of information may have to be presented at once. This could exceed the available display real estate. While it is generally advisable to display more information rather than less, the designer has to solve the dilemma of displaying too much information which may cause ‘‘cannot see the wood for the trees’’ problems for users; displaying too little may lead to increased search times by paging through windows. Six principles of presentation design guide decision making. These are based on presentation layout research (Tufte, 1990; Vanderdonckt & Gillo, 1994; Vanderdonckt, 1995) and evidence collated from the literature (Galitz, 1994; Sutcliffe, 1995; ISO, 1996). 1. Maximize visibility. All the necessary information required by the user for their task should be immediately visible. This reduces search time and saves the user work by paging should many screens or windows.

TASK-RELATED INFORMATION ANALYSIS

243

2. Minimize search time. Information should be made available to the user with the minimum of keystrokes. This has to be tempered by designing search mechanisms for high usability, so for complex IR requirements usability may be more important than speed. 3. Structure and sequence displays. Information should be grouped and ordered to help users find the parts they require and to suggest how the information is organized. 4. Focus user attention on key data. Important information should be salient and easily comprehended by the user. This is achieved by highlighting and positioning key data for prominence. 5. Provide only relevant information. As the presentation should be adapted to the user’s needs, the display of only the information relevant to task step is advised; when no strong task model is present, user-configurable filters should be designed so that displays can be customized. 6. Do not overload the user’s working memory. The presentation should not impose a memory burden which exceeds the user’s limited working memory (Hitch, 1987). This principle may be interpreted in several ways. Two examples are structuring and segmenting displays, which reduces the access/search information the user has to remember. Making displays task-sensitive, reduces the quantity of information users need to remember when carrying out tasks. The principles may conflict in some situations. For instance, maximizing visibility may hinder focusing the user’s attention on key data as there is more information on screen to scan. Similarly, minimizing search time has to be considered as a composite of search time to access the appropriate display screen and search time within a screen. Maximizing visibility increases intra-screen search time, although this can be relieved by structuring. The top-level design objectives are to achieve balance between concurrent and sequential presentation, and to choose the optimal information grouping for structuring. The rationale for these decisions depends on the user’s task needs. The principal point is whether the user has to cross reference different information groups. If so, then the burden on working memory should be reduced by concurrent presentation. Concurrent presentation is also advisable to save the user work. If all the necessary information is visible in a tiled display then it can be rapidly scanned; otherwise, the user has to swap between overlapping windows. Access controls have to be selected for scanning large presentations from UI components such as scroll bars, page controls and sliders. Sequential presentation with discretionary user access controls should be reserved for optional information needs. This may be secondary information which helps task operation, even though it is not vital. Alternatively, the user model may suggest that novices need additional information. Another motivation occurs when information seeking becomes a sub-task in its own right. At certain points in the application task the user may have to search for several pieces of information for a decision. In this case information seeking may be seen as a sub-routine of the main task and a sequence of displays is designed to support the user’s needs. When information access pathways are required, hypertext sequences following nodes and links are designed. Optional information needs become exit and return side

244

A. SUTCLIFFE

branches, while more complex networks are created with short cuts to accommodate different user needs and abilities. However, care has to be exercised in designing multiple pathways to avoid conceptual disorientation in large hypertexts (see Conklin, 1987). 4.1.1. Case study: presentation sequences The main presentation requirement was for preformed queries and links as the data were too volatile for static displays. The quantity of information for most task steps was modest, so concurrent presentation in tiled windows could be assumed. In some cases overlapping windows may be required when text procedures were displayed. A limited amount of information pathways were found from the user requirements and follow-up questions; however, a full hypertext implementation did not appear to be warranted. Information pathways were linked to task stages, e.g. consider the following. Task goal: Decide countermeasures basic information need: Hazard type associated with appropriate procedures Ship’s plans and Cargo location further information links: Medical procedures appropriate to the hazard type Location of medical kits Evacuation procedures Task goal: Muster crew basic information need: Hazard location, Ship’s plans for crew location, compartments and pathway to hazard further information links: Emergency appliance in relevant compartment Crew composition and training details Cargo location Most information could be displayed within available screen sizes; however, text information on emergency and medical procedures was expected to exceed a single screen so sliders were specified with a dialogue command of skip to the next procedure. The length of information pathways was modest as a maximum of 2—3 entities or information items were associated in any one sequence. This and the volatility of the data did not justify a hypertext implementation, so information displays with ‘‘link buttons’’ were chosen to enable the user to retrieve related information from a current display. 4.2. HYPERTEXT AND INFORMATION LINKS

If the information base is reasonably stable and the associations between information can be ascertained at design time then hypertext interfaces are appropriate. Analysis of associations between information categories can employ standard software engineering models such as Entity Access Paths in SSADM (Downs et al., 1991) which traces users’ access needs across entity relationships. Information links may be suggested by the resources themselves, from indexes and cross references, while other associations

TASK-RELATED INFORMATION ANALYSIS

245

can be discovered by observation of users’ search paths and usage patterns. Information analysis may indicate links from task modelling or follow-up questions. Following the approach of (Hardman, Bulterman & Van Rossum, 1994), hypertext specification combines both top-down and bottom-up techniques, starting with scenarios for pathways. These are tested with users who may suggest further links. This can be elaborated by conducting a walkthrough of the available data resources asking the user to indicate possible links to and from each entity. A hierarchical view structures the information into sub-networks reflecting the task model goals, while a time-line or network view specifies the user-system dialogue within each sub-net. The output from the specification stage is a data pathway model for hypertext design. If the model has rich connectivity then a full hypertext implementation is appropriate, although if there are limited connections then queries with links may suffice. The latter is more likely with task-driven information requirements. The design question is how to transform information links into a hypertext like dialogue. Two main strategies are possible. 1. When the pathway contains several information nodes, a hypertext implementation is more appropriate. The design problem is to implement the pathways indicated in the analysis with other access routes which may be advisable for user navigation. Patterns of hypertext browsing (e.g. Belkin, Canters & Rivers, 1985) can be used to refine the specification of pathways. Alternative search pathways can be cued by different colours or other means of highlighting. Another design possibility is to use ‘‘guided tours’’ (see Hammond & Allinson, 1988) to lead the user though exploratory, task-related or browsing-style searches. Filtered views of links, history traces of visited nodes and mini-maps can deal with conceptual disorientation (see Nielsen, 1993). Information types and groups can be mapped to nodes. Anchors are specified with hotspots or buttons as cues for links. Waymarks should be added as icons or book mark tags to label important nodes for the user’s attention. 2. When simple links or shorter paths are specified, preformed queries with links to related information are the appropriate implementation. Menus of canned queries may be designed, although this enforces a hierarchical access path. More often, the information types will be chained in a network of different access paths. In this case cues for each query path have to be presented either on the retrieved resource or close by it. A small hypertext-like interface may be designed as a panel of buttons placed close to the presented data. In more sophisticated implementations it may be possible to place hotspots directly on retrieved data, but this implies dynamic allocation of selectable objects, which may not be possible without a sophisticated graphical UI management system. 4.2.1. Case study: information links The domain analysis suggested a concrete metaphor for the application as a diagram of the ship. Grouping of information items into categories was carried out to plan in outline the presentation windows. Another motivation was to help design of a navigation support to guide the user through the information space. Whereas a navigation-type overview was not strictly necessary because a hypertext was not being used for this application, early

246

A. SUTCLIFFE

user feedback suggested that it could prove useful to provide alternative views for information seeking. Hence, a concrete metaphor of the ship’s architecture diagrams was used as well as presenting a more abstract conceptual view of the information. 4.3. METAPHOR AND VISUALIZATION DESIGN

The information access interface is concerned with supplying users with a means of asking questions and displaying answers. This has to be integrated with the user-system dialogue which supports the user’s task. In classical menus and form-filling interfaces the choices are obvious; however, in graphical user interfaces, design options are not so clear cut. Unfortunately, most HCI methods give little or no guidance about metaphor design. The following heuristics and techniques are drawn from Dix, Findlay, Abowd and Beale (1993) and Sutcliffe and Faraday (1994a, b). This stage in presentation design proceeds in tandem with GUI dialogue design that defines the manipulations to implement user actions. Within the focus of presentation design, the questions are how to design the metaphor as an appropriate cue for action and then how to design cues for information links. As more applications use graphical user interfaces the designer has to choose a metaphor for the task domain. Based on the advice of Carroll, Mack and Kellogg (1988) on choosing metaphors for communicating organization, procedural or causal information, in most cases realistic images will be chosen to communicate the organization and context for information seeking. Cues for information needs should be given in a task context, i.e. graphical objects should act as hotspots to access relevant information pertaining to the object. The problems of designing the application interface are as follows. f f

What is the optimal metaphor for the application? How should information queries be encoded as hotspots (or otherwise) on the application interface?

Once the basic metaphor has been settled the next step is to decide how information queries and links should be encoded. The key to this analysis is to locate important objects on the image and then decide which queries are associated with them. Cues may be changed dynamically according to the task stage if this can be detected from the dialogue and user interaction. The metaphor image has to be semantically encoded so that the user-interface management system can recognize points as ‘‘hotspots’’ and link these to hypertext anchors or a preformed query. Some strategies for cueing links are the following. f

f

f

In text-based resources, outlining or underlining words and phrases is a common technique for hypertext interfaces. Alternatively, colour or an icon marker such as an asterisk can be used. In graphical UI metaphors, objects can be highlighted on the image, or icons placed on the image to suggest the presence of further information. Icons can be used to cue the type of information available, e.g. a camera icon on a map depicts a link to a picture. for query selection, mini-menus are advisable while preformed query templates can be implemented with dialogue boxes.

TASK-RELATED INFORMATION ANALYSIS

247

In most cases interface cues will use simple visual attributes: colour, shading or outlining the object will be sufficient to prompt the user that an item is selectable. However, in some cases it may be desirable to cue the nature of the query by placing an icon on the selectable hotspot. The design of these icons is beyond the remit of this method, although simple indications about the nature of the retrievable resource are advisable, e.g. camera icon to indicate a photograph, film reel for a video clip, etc. For further guidelines, see ISO 9241, part 12 or Galitz (1994). 4.3.1. Case study: metaphor and presentation design The final design adopted a mixture of presentation techniques. Domain analysis indicated that the overall metaphors should be a ship’s diagram showing compartments from different views (plan, side elevation). The early phase of the task had well-known emergency needs, hence the information displays could be designed in detail. Figure 6 illustrates the interface for supporting early phases in the emergency control task. Information links were designed between the emergency crews, appliances, access paths and location of the emergency. Hotspots created links from locations to information relating to spatial-type questions of the ‘‘where is’’ variety. Some hotspots displayed results with link buttons so further queries could be submitted; e.g. asking for a video of the crew’s location following links on the muster crew’s status (see Figure 7). This was introduced so that captains could check the pathways from the crew’s muster point to the hazard location and if necessary give instructions through a radio link so the crew could find their way even if a compartment was full of smoke. Specification of these links was suggested by informa-

FIGURE 6. User interface for the ship emergency management system showing preformed questions in the task list panel and links from the diagram to the emergency team panel.

248

A. SUTCLIFFE

FIGURE 7. User interface showing hypertext links from emergency team to video.

tion analysis and follow-up questions; however, it also illustrates the designer’s creative role in presentation design. Showing pathway information was made possible by multimedia technology and this resource had to be constructed from new video material. Other presentation requirements were not concerned with location and consequently were implemented as a set of query lists linked to the task. Picking actions on the master-task list displayed sub-menus of canned queries for the appropriate information. The user could pick the necessary information and customize the queries by adding details to the constraint clause. Preformed queries and links were cued on the interface metaphor by icons to represent important data such as fire-fighting appliances, while compartments were all selectable for questions relating to contents, position and access paths. Although the task-oriented view fitted the prime purpose of the system, i.e. decision support for emergency management, the system had a further requirement as a general shipboard information system. In the later stabilization phases of the emergency task, information needs could not be determined beforehand. In this perspective no strong task-based metaphor existed. The users’ need was for more open-ended information retrieval to answer a series of questions about the state of the ship and its cargo with a browsing style interface. To support this need, a more general information seeking interface was designed to give an overview of all the information categories as a conceptual map, as illustrated in Figure 8. An abstract metaphor of layers was used to

TASK-RELATED INFORMATION ANALYSIS

249

FIGURE 8. Navigator diagram interface, showing information categories.

suggest class hierarchies of information organized in functional groups, e.g. Manpower related data: Equipment data: Cargo: Procedure manuals:

crew, training, teams appliance, medical-kit, crew-equipment container, cargo, owner emergency procedures, first-aid instructions, evacuation plans, operating procedures, technical manuals.

As the users’ categorization of information did not fit the entity relationship model, subclasses were defined to give categories more suited to the users’ view. For instance, cargo was sub-divided into general, mixed, manufactured goods, organic, minerals, with another dimension for liquids, solids and hazardous. These sub-categories formed the logical model from which an ‘‘information map’’ display was designed. Within each layer, entities, relationships and sub-categories were placed in close proximity, as defined in the domain analysis. The map interface supported exploration of the databases, browsing and orientation towards the required information. The user could explore the map progressing through successive layers until the sub-class nodes which allowed query by pointing of the ‘‘find all’’ type. Data retrieval was also supported by a form-filling dialogue similar to query by example (Zloof, 1979), and details of this interface are reported elsewhere (Rosengren, 1994).

250

A. SUTCLIFFE

The design incorporated all the principal means of presentation design: standard information displays, hypertext, preformed query menus and information retrieval interfaces. More structured parts of the task were supported by standard displays and hypertext style designs while less deterministic needs were provided for by concept map interfaces and general information retrieval facilities. 4.4. TRANSITION TO DETAILED DESIGN

Key data for important and safety critical actions should be highlighted following the requirements for user attention annotated onto the task model. Presentation layout is a matter of detailed design for which numerous guidelines have been proposed (e.g. Brown, 1988; Tullis, 1986; Galitz, 1994; ISO 9241, part 12), and is not within the scope of the method. At this stage the information specification contains the following. 1. Lists of information types cross referenced to the task model. 2. Specification of information groups, listed in the data dictionary. These lists may be taken from the data analysis. 3. Specification of structure and organization within information groups. 4. Diagrams cross referencing information presentation to the dialogue design using graphical notation or simple lists. 5. High-level design sketches of presentation layouts and screen metaphors. Prompts, feedback messages, status information and availability of help should have been planned in general terms using presentation barcharts, although more details may have to be added in this stage. Detailed design continues by mapping information groups to display widgets provided by the user interface design environment, e.g. windows, message boxes, lists, etc., within the constraints of style guides and presentation guidelines. Information specification is an iterative process which benefits greatly from user testing. Specification is little substitute for showing users what they are about to see and story boarding, prototyping or Wizard of Oz techniques are invaluable ways of eliciting feedback (Gould, 1987). Story boarding is one of the cheapest techniques for creating mock ups of screen designs. These can be explained to the user with a script for the task scenario and user-system dialogue. Prototypes and Wizard of Oz techniques give a more realistic feel to the use of information in an application. One or more of these techniques should be used to improve the design. 4.5. LESSONS LEARNED

Experience of using the method demonstrated that it was effective, although it was used by a small sample of three designers, who were involved in the project. However, some parts of the method were found to be more useful than others. The task information modelling was well received and integrated well with existing software engineering practices, i.e. use of structured methods and data flow diagram notation. Domain modelling was helpful; however, more guidance on the transition from domain models to metaphor design was requested. High-level design guidance in the form of the display

TASK-RELATED INFORMATION ANALYSIS

251

matrix table proved useful for planning. Likewise presentation bar charts were a natural way of representing presentation sequences, although some designers felt that it might not scale-up and become confusing when several windows with different information groups were required. The media selection rules provided clear guidance although the designers wanted guidance for non-task-related information such as causation. This problem of the coverage was also noted in the information types. Safety critical aspects of the task also needed further guidance, in particular design of warning displays, and more complex issues such as monitoring display for fault finding. Such issues were beyond the scope of the TIM method which was intended to be of general purpose. Finally, the designers urged that the method should be comprehensive and include detailed design guidance for information presentation, rather than referring the designer to other sources such as ISO standards.

5. Discussion The method presented in this paper has attempted to show that presentation design is not just an adjunct of dialogue design but a wider concern. Technologies such as hypertext and hypermedia are often considered to be distinct applications; however, as these technologies are used in more general applications, they should be seen as a means of information delivery in a task context rather than as special techniques. Likewise information retrieval is not part of database technology, nor is it a specialized application limited to libraries and bibliographic databases, but just another means for providing users with information appropriate for their task. Although hypertext systems are becoming easier to link with applications and SQL can be embedded within applications, the developer’s job of creating a seamless presentation interface is often far from easy. However, with the advent of more general information access tools (e.g. Microsoft Access), and open hypertext environments (see Davis, Hall, Heath, Hill & Wilkins, 1992), developers may have the necessary presentation and information access tools with which to build applications. Indeed the distinction between hypertext and data retrieval is becoming transparent in some hypertext environments such as Microcosm (Hall et al., 1992). A more comprehensive solution to this problem has been developed by the INTUITIVE project in the form of an information retrieval toolkit which can be tailored to tasks, and embedded in applications as part of the presentation interface, providing hypertext, standard displays or query facilities. UI research for information browsing has been a concern in hypertext systems (Belkin et al., 1985), and these interfaces have been designed to guide users along paths of related information. Other systems have produced overviews and map-like interfaces to databases (Larson & Wallick, 1984; Rosengren, 1994); however, these designs have not portrayed a task-related viewpoint. Indeed, most hypertext designs have concentrated on constructed pathways through an information space to support learning while few database interfaces have attempted to give high-level conceptual views of data. Some advice on Hypertext wayfinding is given by Nielsen (1993) and in this paper, although further research is necessary on aide memoirs and visualization metaphors. These approaches are necessary to deal with the well-known problems of conceptual disorientation (Conklin, 1987) and information overloading.

252

A. SUTCLIFFE

User-interface research on presentation of complex information, e.g. the information visualizer project, has created three-dimensional carousel views of information hierarchies and a means of manipulating such views (Card, Robertson & Mackinlay, 1991). More recently, browsing and more decision-support approaches to information usage have been supported by ‘‘sense making’’ (Russel, Stefik, Pirolli & Card, 1993), which is moving on the path towards a view of information within the context of its usage. These functionalities, and other metaphors for constructing information spaces, such as rooms (Henderson & Card, 1987), offered further design paradigms that can be used in conjunction with the method. Although we have proposed method extensions to address multimedia databases and presentations (Faraday & Sutcliffe 1993; Sutcliffe & Faraday, 1994a, b), there is considerable work to be undertaken in planning effective multimedia presentation which relates to the user task and information needs. More detailed taxonomies of modalities give finer grained choice for mapping information needs to the space representational possibilities (see Bernsen, 1994). Previous methods of structured user-interface development (Browne, 1994; RedmondPyle & Moore, 1995) have started to address the problem of specifying the information interface, but they only provide limited guidance for identifying information requirements, and concentrate instead on design issues such as statechart specifications of window dialogues. Furthermore, they do not deal with the wide spectrum of information presentation that is addressed in the TIM method. One criticism which may be levelled at all methodology research is that it produces recommendations that expert designers would have come up with anyway. But that misses the point that methods are produced, and introduced to help novice designers improve their performance, ensure poor designers achieve at least an adequate standard, and provide management with mechanisms for controlling the development process by clear stages, deliverables and milestones. Evidence of the effectiveness of HCI methodology in practice has been produced by Remond-Pyle and Moore (1995). In the case study we undertook, the method did change practice. Future work on the method will test its usability on further projects. The experience on the INTUITIVE project reported in this paper has demonstrated the feasibility of the method and ironed out some problems. More work is required on the analysis techniques, as well as on the hypertext-links specification. There is some design advice in the hypertext literature (Nielsen, 1993), but more study is required about how to design information pathways. One problem with methodical approaches to system development is that they consume resources. Even lean methods encounter user resistance (Maclean et al., 1991). With this in mind, part of our future work will be to devise a ‘‘fast-path’’ version of the method which will carry out the essential parts of the process with limited resources. Integration with prototyping approaches will also be investigated. In conclusion, whatever the eventual merits of the method in practice, there remains the prospect that the ideas and concepts will prove useful ‘‘tools for thought’’ for software and information engineers. Even if only fragments of the method are incorporated into software development practice, a neglected part of HCI design may be improved. This work was partially supported by the European Union’s ESPRIT programme in Project 6593 INTUITIVE, whose partners were CAP Gemini Innovation, INRIA, IBERMATICA, SISU,

TASK-RELATED INFORMATION ANALYSIS

253

BRAMEUR, Lloyds Register and City University. The author wishes to thank Clive Bright and John Hobday of Lloyds Register who carried out the preliminary requirements analysis on the shipboard case study, and the team at City, Michele Ryan, Ian Bennett and Ann Doubleday, who carried out the development.

References ANDRE, E. & RIST, T. (1994). Referring to world objects with text and pictures. Coling-94, Kyoto, Vol. 1. pp. 530—534 ANNETT, J. K. et al. (1971). ¹ask Analysis, London: HMSO. BELKIN, N., CANTER, L. & RIVERS, R. (1985). Characterising user navigation through complex data structures. Behaviour and Information ¹echnology, 4, 93—102. BENYON, D. (1991). The role of task analysis in systems design. Interacting with Computers, 4, 102—123 BERNSEN, N. O. (1994). Foundations of multimodal representations: a taxonomy of representational modalities. Interacting with Computers, 6, 347—371. BROWN, C. M. (1988). Human Computer Interface Design Guidelines. Norwood, NJ: Ablex. BROWNE, D. (1994). STUDIO: Structured ºser-interface Design for Interaction Optimisation. Hemel Hempstead: Prentice-Hall. CARD, S. K., ROBERTSON, G. G. & MACKINLAY, J. D. (1991). The information visualiser. Proceedings of CHI 91, Human Factors in Computing Systems. New York: ACM Press. CARROLL, J. M., MACK, R. L. & KELLOGG, W. A. (1988). Interface metaphors and user interface design. In M. HELANDER, Ed., Handbook of Human—Computer Interaction, pp. 67—85. Amsterdam: North-Holland. CONKLIN, J. (1987). Hypertext: an introduction and survey. IEEE Computer 20, 17—41. DAVIS, H., HALL, W., HEATH, I., HILL, G. & WILKINS, R. (1992). Towards an integrated information environment with open hypermedia systems. pp. 181—90. Eds. D. LUCARELLA, J. NANARD, M. NANARD & P. PAOLINI, Proceedings of ECH¹ 92, 4th ACM Hypertext Conference. DE MARCO, T. (1978). Structured Analysis and System Specification. New York: Yourdon Press. DIAPER, D. & JOHNSON, P. (1989). Task analysis for knowledge descriptions, theory and application in training. In J. LONG & A. WHITEFIELD, Eds., Cognitive Ergonomics and Human Computer Interaction. Cambridge: Cambridge University Press. DIX, A., FINDLAY, J., ABOWD, G. & BEALE, R. (1993). Human Computer Interaction. New York: Prentice-Hall. DOWNS, E., CLARE, P. & COE, I. (1991). Structured Systems Analysis and Design Method: Application and Context. New York: Prentice-Hall. FARADAY, P. F. & SUTCLIFFE, A. G. (1993). A method for multimedia design. In J. L. ALTY, D. DIAPER & S. GUEST, Eds., People and Computers »III, Proceedings of the BCS HCI-SIG Conference, pp. 173—190. Cambridge: Cambridge University Press. FEINER, S. & McKEOWN, K. R. (1993). Automating the generation of Coordinated multimedia explanations. In M. T. MAYBURY, Ed., Intelligent Multimedia Interfaces, pp. 117—138. New York: AAAI/MIT Press. GALITZ, W. O. (1994). It’s ¹ime to Clean up your ¼indows: Designing GºIs that work. New York: Wiley-QED Publications. GARDENER, A., Ed. (1988). Human Factors Guidelines for the Design of Computer Based Systems. Loughborough: HUSAT Publications. GOULD, J. D. (1987). How to design usable systems. In H. J. BULLINGER & B. SHACKEL, Proceedings Interact 87. Amsterdam: North-Holland. HAMMOND, N. V. & ALLINSON, L. J. (1988). Travels around a learning support environment: rambling, orienteering or touring? In E. SOLOWAY, D. FRYE, S. B. SHEPPARD, Eds., CHI 88 Conference Proceedings: Human Factors in Computing Systems. ACM: ¼ashington, DC, 15—19 May, pp. 269—273. HARDMAN, L., BULTERMAN, D. & VAN ROSSUM, G. (1994). The Amsterdam hypermedia model: adding time and context to the Dexter model. Communications of the ACM, 37, 50—62.

254

A. SUTCLIFFE

HAREL, D. (1988). On visual formalisms. Communications of the ACM, 31, 514—530. HEGERTY, M. & JUST (1993). Constructing mental models of text and diagrams. Journal of Memory and ¸anguage, 32, 717—742. HENDERSON, A. & CARD, S. K. (1987). A multiple virtual workspace to support task switching. Proceedings of CHI’87, Human Factors in Computing Systems, pp. 53—59. New York: ACM Press. HITCH, G. J. (1987). Working memory. In B. CHRISTIE & M. M. GARDINER, Eds., Applying Cognitive Psychology to ºser Interface Design. London: Wiley. HOBDAY, J. S., RHODEN, D., BRIGHT, C. K. & EARTHY, J. V. (1994). Aiding the control of emergencies on ships. Proceedings of IMAS-94, Fire Safety on Ships: Development into the 21st Century, pp. 23—27. ISO 9241 (1994). International Standards Organisation, Ergonomic requirements for office work with visual display terminals, Part 12, Presentation of Information. Draft International Standard. JARKE, M., BUBENKO, J. A., ROLLAND, C., SUTCLIFFE, A. G. & VASSILIOU, Y. (1993). Theories underlying Requirements Engineering: an overview of NATURE at Genesis. IEEE Symposium on Requirements Engineering, RE 93. San Diego, CA, 4—6 January. JOHNSON, P. (1985). Towards a task model of messaging: an example of the application of TAKD to user interface design. In P. JOHNSON & S. COOK, Eds., People and Computers: Designing the Interface. pp. 6—62. Cambridge: Cambridge University Press. JOHNSON, P. (1989). Supporting system design by analyzing current task knowledge. In D. DIAPER, Ed., ¹ask Analysis for Human—Computer Interaction. pp. 160—185. Chichester: Ellis Horwood. JOHNSON, P. (1992). Human Computer Interaction, London: McGraw-Hill. JOHNSON, P., JOHNSON, H., WADDINGTON, R. & SHOULS, A. (1988). Task related knowledge structures: analysis, modelling, and application. In D. M. JONES & R. WINDER, Eds., People and Computers: From Research to Implementation, pp. 35—62. Cambridge: Cambridge University Press. LARSON, J. A. & WALLICK, J. B. (1984). An interface for novice and infrequent database management system users. Proceedings of NCC, Vol. 84. pp. 524—529. LIM, K. Y. & LONG, J. L. (1992). A method for (recruiting) methods: facilitating human factors input to system design. In P. BAUERSFIELD, J. BENNETT & G. LYNCH, Eds., Human Factors in Computing Systems, Proceedings of CHI92, pp. 549—555. New York: ACM Press. MACLEAN, A., YOUNG, R. M., BELLOTTI, V. & MORAN, T. (1991). Questions, options, and criteria: elements of design space analysis. Human—Computer Interaction, 6, 201—250. NIELSEN, J. (1993). Hypertext and Hypermedia. New York: Academic Press. NORMAN, D. A. (1986). Cognitive engineering. In D. A. NORMAN & S. W. DRAPER, Eds., ºser Centered System Design: New Perspectives on Human—Computer Interaction. pp. 31—61. Hillsdale, NJ.: Lawrence Erlbaum Associates. PIERRET-GOLBREICH, C., DELOUIS, I. & SCAPIN, D. L. (1989). An object-oriented tool for extracting and representing tasks. INRIA Research Report no 1063 (in French). POHL, K. (1993). ¹he ¹hree Dimensions of Requirements Engineering. CAiSE 93, Paris: Springer. REDMOND-PYLE, D. & MOORE, A. (1995). Graphical User Interface Design and Evaluation. London: Prentice Hall. ROSENGREN, P. (1994). Applying conceptual modelling to multimedia information retrieval. Proceedings of RIAO-94, Intelligent Multimedia Information Retrieval Systems and Management. USA, October. RUSSEL, D. M., STEFIK, M., PIROLLI, P. & CARD, S. K. (1993). The cost structure of sense making. In S. ASHLUND, K. MULLET, A. HENDERSON, E. HOLLNAGEL & T. WHITE, Eds., Proceedings of IN¹ERCHI 93. pp. 269—275. New York: ACM Press. SUTCLIFFE, A. G. (1988). Some experiences in integrating human computer interface design within structured system development methods. In R. WINDER & D. M. JONES, Eds., People and Computers I» (HCI-88), pp. 145—160. Cambridge: BCS/Cambridge University Press. SUTCLIFFE, A. G. (1989). Task analysis, system analysis and design: symbiosis or synthesis. Interacting with Computers, 1, 6—12. SUTCLIFFE, A. G. (1995). Human Computer Interface Design, 2nd edn. London: Macmillan.

TASK-RELATED INFORMATION ANALYSIS

255

SUTCLIFFE, A. G. & FARADAY, P. F. (1994a). Designing presentation in multi media interfaces. In B. ADELSON, S. DUMAIS & J. OLSON. Eds., Proceedings of CHI-94, pp. 92—98. New York: ACM Press. SUTCLIFFE, A. G. & FARADAY, P. F. (1994b). Systematic design for task related multimedia interfaces. Information and Software ¹echnology, 36, 225—234. SUTCLIFFE, A. G. & MCDERMOT, M. (1991). Integrating methods of human computer interface design with structured system development. International Journal of Man Machine Studies, 4, 631—655. SUTCLIFFE, A. G. & WANG, I. (1991). Integrating human—computer interaction with Jackson System development, Computer Journal, 34, 132—142. TUFTE, E. R. (1990). Envisioning Information. Cheshire, CT: Graphics Press. TULLIS, T. S. (1986). Optimising the usability of computer generated displays. In M. D. HARRISON & A. F. MONK, Eds., People and Computers: Designing for ºsability. Cambridge: Cambridge University Press. VANDERDONCKT, J. & GILLO, X. (1994). Visual Techniques for Traditional and Multimedia Layouts. In T. CATARCI, M. F. COSTABILE, S. LEVIALDI & G. SANTUCCI, Eds., Proceedings of 2nd ¼orkshop on Advanced »isual Interfaces A»I’94, Bari, 1—4 June 1994, pp. 95—104. New York: ACM Press. VANDERDONCKT, J. (1995). Accessing Guidelines Information with SIERRA. In K. NORDBYN, P. H. HELMERSEN, D. J. GILMORE and S. A. ARNESEN, Eds., Proceedings of 5th IFIP ¹C 13 International Conference on Human—Computer Interaction, Lillehammer, 27—29 June, pp. 311—316. London: Chapman & Hall. WILENGA, B., VAN DE VELDE, W., SCHREIBER, G. & AKKERMANS, H. (1993). Expertise model definition document. KADS project document KADS-II/M2/UvA, University of Amsterdam. ZLOOF, M. N. (1979). Query by example: language design considerations. In Man Computer Communication, Vol. 2, Infotech State of the Art Report. Paper accepted for publication by Associate Editor, Dr Kent Norman.

Appendix 1: Information model Two text categories (emergency and hazard procedures) can be classified into procedure sub-classes for retrieval; two standard entities could be refined into entity sub-types to help the user conceptualize the overall information space. This produces the following sub-categories: Category: Emergency procedures Sub-categories: Fire procedures Chemical spillage Gas leak Collision Explosion Piracy Category: Hazard procedures Sub-categories: Fire handling Sub-sub-categories CO2 treatment

256

A. SUTCLIFFE

Flood compartments Use of appliances Chemical spillage Containment techniques Treatment techniques Neutralization of acids and alkalis Gas leak Ventilation procedures Collision Flood limitation Reinforcing bulkheads List management techniques Explosion Ventilation techniques Preventative measures Piracy Anti-boarding measures Crew instructions Negotiating procedures Cargoes can be classified using IMO (International Maritime Organization) standard schemes for general cargo and hazardous cargoes as specified in the Blue Book. This analysis produces three hierarchies which have to be integrated with the ER view to produce the user model of the information space. Procedures: Emergency and hazard procedures appear to be closely related. Emergency procedures give general advice on analysis of a problem situation while hazard procedures give advice on how to deal with a specific problem. A hierarchy diagram could depict the procedures, the higher-level giving emergency procedures and sub-categories thereof with lower levels showing hazard procedures. Cargo: The entity cargo could be expanded into sub-entities representing machinery, perishable cargo, agricultural products, etc. The user model therefore becomes an extended ER diagram with the addition of procedures, and two subordinate extensions to model sub-entities and categories for the procedures and cargo entities. In addition, representation of instances of Compartments is necessary for location questions.

Appendix 2: An example of a procedure description for the Lloyds demonstrator. Procedure: Analyse-hazard with hazard attributes input Send Emergency-Msg to Evacuate-Personnel-evacuation path IF Hazard"Fire THEN Find Fire-Type IF Chemical-Fire THEN Identify chemical-chem hazard type

TASK-RELATED INFORMATION ANALYSIS

257

Find Instructions for Crew-hazard procedures END-IF IF Electrical Fire THEN Shut down Electrical Circuits-circuit Ids Find Instructions for Crew-hazard procedures END-IF IF Oil Fire THEN Close off ventilation-ventilation controls Find Instructions for Crew-hazard procedures END-IF END-IF If Hazard"Spillage THEN Find Spillage-type-chemical hazard type IF Spillage-Chemical"Caustic Find Instructions for Crew-hazard procedures END-IF END-IF Note that the text is indented to show the span of control for each selection, iteration, etc. Information requirements are shown in italics.

.