integrating information — a task-orientated approach

Interacting with Computers 9 (1998) 225-240

Integrating information - a task-orientated approach

Stella Mills* Department of Information Technology, Cheltenham and Gloucester College of Higher Education, PO Box 220,

The Park Cheltenham, GLSO 2QF, UK

Abstract

To date, there have been few attempts at integrating the increasing amounts of information that are available to users of computer systems. Using published literature, this paper collates some relevant

principles (or heuristics) for integrating information based on task orientation. These are then applied to the electronic fishing aids in an in-shore fishing vessel’s wheelhouse with the purpose of reducing

the number of screens used therein. However, the application raises some issues; in particular that of the designer’s knowledge of the tasks so that unique information is not lost. 0 1998 Elsevier Science B.V.

Keywords: Informatim integration; Task analysis; Heuristics; Electronic fishing aids; Fishing

vessel’s wheelhouse design

1. Introduction

With the increase in information being generated by computer systems, there is a need for output from computer systems to be integrated in order to reduce cognitive overload which yields at best stress in the workplace and may make users ill. That this situation is serious, is illustrated by a leading financial house holding a seminar to which experts were invited to help the company find a method of dealing with information overload [l]. However, information integration has been considered for some years in the special&d area of integrating information from safety critical systems used in a control room environment or a similar environment such as the bridge of a ship. Inevitably, the approach has been to reduce the number of screens which the control operators must observe by relating the information generated to the goals and tasks of the moment. However, with the

* Department of Information Technology, Cheltenham and Gloucester College of Higher Education, PO Box

220, The Park, Cheltenham, GL50 2QF, UK. Tel.; 01242 543231; fax. 01242 543208; e-mail: [email protected]

0953-5438/98/$19.00 0 1998 - Eisevier Science B.V. All rights reserved

PII SO953-5438(97)00016-7

226 S. Mills/Interacting with Computers 9 (1998) 22.5-240

exception of Booher’s work [2], there appears to be a dearth of literature suggesting how such an integration of general information could take place in practice, although some

authors have attempted to derive principles or heuristics, both of a general and application specific type, for information integration. These general principles rest heavily on task analysis while those relating to integrating information specifically in control room envi-

ronments are often drawn from practical experience of doing tasks rather than from a theoretical basis.

This paper will derive principles for integrating information from the relevant points

made in the literature and then apply them to the example of electronic fishing aids in the wheelhouse of an in-shore fishing vessel. There are two pertinent areas of the literature to

be considered; the first is that of using task analysis to inform interface design and particularly integrating information, while the second area of relevant literature comes from the

ergonomic discussions of wheelhouse design and especially integrating information for use on a ‘one-man-bridge’. After deriving relevant principles from the literature from

these two areas, this paper then discusses the merits of the various task descriptions methods available, concluding that hierarchical task analysis (HTA) is the best for inte-

grating information. Consequently, HTA is used in the application domain of integrating

the information that a fishing skipper needs, taking a typical task scenario for analysis. The

paper concludes with a discussion of the main issues arising from the integration. First,

then, we turn to considering the relevant literature from task analysis.

2. Principles from task analysis

There are a number of authors, for example, Bellotti [3], Shepherd [4] and Wilson et al. [5], who have used task analysis methods to inform interface design and following

Shepherd [4] this paper takes the view that computers are used as part of a much wider task, i.e. as a tool to achieve a goal which may not have any connection with computers.

It should be noted that throughout this paper, the concepts of ‘goal’ and ‘task’ follow

Benyon’s definitions [6] that a ‘goal’ is ‘a state of a system which the human... wishes to

achieve’ while a ‘task’ is defined as ‘the activities required... to achieve a goal using a particular device’. This means that the tasks may change if the system is changed [6]. A

‘task sequence’ is the sequence of tasks necessary to achieve a goal. While discussing more general interface issues, Rasmussen and Goodstein [7] stressed

the importance of being ‘able to structure the decision task... in task independent

terms’ and they pointed out ‘that particular decision processes cannot be modelled explicitly since they will be very dependent upon the situation and persons involved’. In order to resolve ‘important interface issues’, they consider the two following relevant

points [7]:

1. Which is the set of decision sub-functions which are needed to serve the overall task

content of the user?... 2. Proper selection of the grouping of the information to be available in the various

display formats depends on a careful analysis in this (decision task) domain.

Thus we can formulate the first principle for information integration:

S. Mills/Interacting with Computers 9 (1998) 225-240 227

2.1. Principle 1: Analysis of the decision task domain should inform the grouping of

information [7]

Furthermore, the ‘design objective is to match the displays to a mental model which will be effective for the task and to choose interface design, operator selection and total job content in a way which will guide operators’ subjective preferences in that direction’ [7]. In other words, ‘the configuration in familiar tasks should be related to the rules of users’ know-how’ [7]. Thus we have:

2.2. Principle 2: The conjiguration in familiar tasks should relate to the users’ previous

knowledge [7]

In addition, we should avoid situations of unsuitable task assignment between the user and the computer support such as giving the user calculations which can be performed quicker and more accurately by the computer [8]. Giving the user unnecessary information also must be avoided [8]. More positively, this means that task assignment should optimise the inherent characteristics of the human user and the computer. This can be formulated as:

2.3. Principle 3: Task assignment between user and computer should optimise the inherent

characteristics of each [8]

Having considered the literature relevant to information integration from the area of task analysis, we now turn to that of the application area. Within the context of wheelhouse design there are no known studies on task analysis except in a very cursory way, but some relevant principles can be drawn from work done on the ‘one-man bridge’ concept where some guidance is given about integrating equipment specific to the general area of integrated bridge design.

3. Principles developed through wheelhouse design

There have been some suggestions for reducing the number of screens on a bridge or in a wheelhouse which are related to information integration. In the main, these have generally been based on principles which could also be used for control rooms, as the ergonomic similarity between these and bridges/wheelhouses on shipping vessels has long been noted [9]. Thus, as early as 1984, Witty held that ‘the problem of too many individual screens in the [fishing vessel’s] wheelhouse’ [lo] should be solved by integrating the information according to task [ 111. Reiterating this, Stoop [ 121 suggested that integration ‘of information on one display, such as a VDU, instead of presentation on different displays’ should happen whenever possible. This should be facilitated by automation of transfer of information’ [ 121. In a later paper [ 131, Stoop advocated the introduction of an Automatic Radar Plotting Aid (ARPA) which would combine the information from the radar and the electronic chart. Harre, writing about military vessels rather than fishing vessels [14], pursued a policy of functional integration of the equipment but did not expand on how the required information, after integration, could be displayed on a

228 S. Mills/Interacting with Computers 9 (1998) 225-240

VDU although he claimed to have prototyped a ‘multi-purpose computer console’ [ 141. Thus we have:

3.1. Principle 4: Functional integration should be exploited through automation of

transfer of information Ill, 12, 141

Trying to find a methodological solution to the problem of information integration, Osga used design goals [15] which essentially are application domain principles based on more generic human factors’ principles. He gave a relevant example of such a principle:

‘For tasks which include steps that require the selection of single or multiple tracks, each step... should be performed on the same display’.

Osga gave an example of a user having to ‘shift between 3 controls and 3 displays’, adding the solution was to ‘co-locate all useful task information on a pop-up windows [sic] on the same display’ [El. Consequently, this can be summarised as:

3.2. Principle 5: Task sequences should be completed on one display unit [15]

While not directly addressing systems which integrate information, Wilkinson made the point that displays giving similar but different information should be positioned apart to avoid possible confusion of information [16]. An example of this is the diagrammatical representation of data which are similar but different, such as pie-charts. If no attention is given to this, then confusion in adverse conditions could happen although there seems to be no recorded evidence of such an occasion. Thus we have:

3.3. Principle 6: Confusion between similar but different information must be avoided [16]

For ease of reference, these six principles are summarised in Table 1. Following the derivation of these six principles, it is necessary to consider their different

characteristics in sufficient depth to identify the properties needed by the task description method for the application. Consequently, we now identify this aspect of the principles.

Table 1

Principle 1

Principle 2

Principle 3

Principle 4

Principle 5

Principle 6

Analysis of the decision task domain should inform the grouping of infor-

mation [7].

The configuration in familiar tasks should relate to the users’ previous

knowledge [7].

Task assignment between user and computer should optimise the inherent

characteristics of each [8].

Functional integration should be exploited through automation of transfer

of information [ll, 12, 141.

Task sequences should be completed on one display unit [ 151.

Confusion between similar but different information must be avoided [ 161.


4. Discussion of design principles

It can be seen that all the above principles relate to the tasks the user must undertake and by consideration of these tasks a design which integrates information should obtain. In particular, the decision task domain needs to inform the task analysis by assigning tasks (Principle 3) to machine or human (Principle 4) as well as informing the design (Principle 1). Familiar tasks should relate to the user’s knowledge (Principle 2) but confusion needs to be avoided with similar but different outputs (Principle 6). After analysis, the task sequence should be assigned to one screen if possible (Principle 5). Thus a description method of application of the principles to the application domain is required which clearly exhibits the decision task domain, the user’s previous knowledge, and, of course, the actual tasks to a sufficient level to allow for their assigning to user or machine. In addition, the method needs to highlight those tasks where similar but different information is given by the computer system(s) so that confusion by the user may be avoided. In order to choose a suitable method, some discussion of task description methods in general is essential. However, before considering this, we note briefly here that for such a design to be valid, it must still be developed practically, preferably using a user-centred rapid application development method such as prototyping [24] and be evaluated with users. This is considered to be beyond the scope of this paper, which is only concerned with the first step towards a fully validated design which is to use the principles to inform the production of the design of the first prototype.

5. Description methods of task analysis

Task analysis has been used in its generic sense to mean the global concept of analysing tasks in order ‘to make sense of what people should do or what they actually do’ [25]. In practice, there are at least 25 techniques [26] of task analysis and these can be divided into five main categories: task data collection, task description methods, task simulation metb- ods, task behaviour assessment methods and task requirements evaluation methods [26]. Of these, task description methods is the most relevant here since we want to represent ‘(task) data in a pre-specified format’ [26]. Task description methods can be sub-divided into at least six categories: charting and network techniques which use diagrams for giving a ‘breakdown of the task into clear units’ [26], decomposition methods which ‘ensure that the issues of interest... are systematically considered...’ [26], hierarchical task analysis which ‘enables the analyst to focus on crucial aspects of the task within the context of the overall task’ [26], link analysis which is ‘hardware orientated’ [26], operational sequence diagrams which are useful for ‘showing the relationship between operations’ [26] and timeline analysis which ‘looks only at temporal relationships’ [26].

For the general application domain of integrating information, we can immediately dismiss the use of link analysis, operational sequence diagrams and timeline analysis. Since it is crucial to focus on the decision aspects of the task (Principle 1) in order to facilitate the assigning of the tasks (Principles 3 and 4), hierarchical task analysis (HTA) will be the most useful. However, we shall need to consider systematically the areas of interest, although the ‘breakdown of the tasks into clear units’ will not be required as a


separate entity apart from general decomposition. Thus charting techniques will not be necessary since the task sequences and the functional integration will be apparent from the diagrammatical representation used in HTA. Thus, the most suitable method of task description appears to be HTA but there are some drawbacks to using HTA which need to be considered. First, the most usual form of representing the task decomposition is by a hierarchical diagram which allows a clear decomposition of the tasks. However, additional information about the tasks is not easily represented within the diagram but can be included in additional tables and explanatory notes. ‘HTA therefore has the potential to incorporate a wide variety of task information within its representational format...’ [27]. Thus tasks can be identified as being cognitive and/or requiring a decision (Principle 1). Shepherd [25] also advocates the use of Hierarchical Task Analysis (HTA) in such situations, as this has been developed to ‘cope with... the increasing number of system super- vision tasks’. However, in representing users’ knowledge (Principle 2), other description methods such as Task Analysis for Knowledge Descriptions (TAKD) and Task Knowl- edge Structures (TKS) should be considered, as these have been claimed to be more suitable [27].

The original purpose of TAKD was ‘to provide a description of the knowledge that young trainees needed to possess to be able to perform suitable information technology tasks’ [28]. It consists of a hierarchical description of tasks and a knowledge representation grammar which is used to describe the route of each task’s specific objects through the Task Descriptive Hierarchy [28]. It is worth noting here that TAKD is designed to illicit knowledge from the (hierarchical) task analysis rather than providing a method per se for incorporating into the task analysis the knowledge that a user has already.

TKS is used to represent the knowledge people possess about tasks they have previously learned and performed in a given domain [29,30]. A method of analysing the task knowledge a user or group of users possesses is known as Knowledge Analysis of Tasks (KAT) and the use of this method is facilitated by conjunctively using a structured systems analysis method, e.g. Structured Systems Analysis and Design Methodology, which is better known as SSADM [29]. However, of pertinence here, is the point that each complete TKS has a goal-oriented substructure, task procedures and a taxonomic substructure from the generic task actions and objects [29]. This means that in a KAT analysis the user’s knowledge is that utilised in operating the system in order to achieve the goal. Thus KAT is similar to KATD analysis except that in the latter, analysis yields the knowledge the user must have in order to complete the goal. It is possible, therefore, to consider the two methods as complimentary in this sense.

However, returning to the derived principles above, it will be seen that a consideration of a user’s previous knowledge in relation to familiar tasks is required (Principle 2). This suggests that TKS could be useful if an analysis of the ‘familiar tasks’ were deemed necessary. However, it should be noted that the user’s previous knowledge, in TKS terms, is knowledge of task procedures. It does not relate to knowledge associated with information that the system gives as output, nor does it relate to the interpretation/analysis of that knowledge. Thus TKS may not be so helpful in integrating information in accordance with Principle 2.

There are other methods of representing cognitive aspects of task analysis, most notably Task Action Grammar [31] and Goals, Operations, Methods and Selection Rules (GOMS)

S. Mills/interacting with Computers 9 (1998) 22.5-240 231

[32]. While these have some similarity with HTA (for example, the selection rules com- ponent of GOMS can be equated with the plans within HTA [27]), the diagrammatical representation together with the flexibility of the associated tables of HTA still gives this method (HTA) an advantage, relevant to information integration, over the others, in spite of its limitations to represent cognitive aspects of the tasks. In addition, through its diagrammatical representations HTA allows easy implementation into traditional systems analysis and design methods, regardless of a particular methodology. This is very relevant here since after the task analysis associated with information integration is completed, a systems requirements will be needed. Finally, the user’s previous knowledge should already have been considered in the original system’s design in association with the tasks included in the integration and so independent cognitive analysis of these tasks is unlikely to be required. Thus considering all these points together, HTA still has the strongest pull in deciding which task decomposition method should be used.

Having demonstrated that HTA is the most suitable method of application of the principles we now use this method to analyse a typical task scenario of the chosen application domain of inshore fishing. The type of fishing chosen is trawling since this is one of the main categories of fishing requiring information from a number of different displays. In order to inform the task scenario, a brief description of the application domain is given.

6. A simple application of the information integration principles

As an illustration of the use of task analysis information integration, a simple example is given below which utilises HTA in integrating the different outputs from systems used by fishermen while in-shore fishing.

7. Application domain description

Since the development of acoustical fishing aids in the 1950s [33], the number of visual display units (VDUs) carried in the wheelhouse of in-shore fishing trawlers has increased to around seven (not including a television which some skippers carry to relieve boredom [34]). For the purpose of this paper, in-shore fishing vessels are those in a registered length class of between 16.5 metres and 40 metres. Depending on whether the vessel is used for pelagic (mid-water) trawling or demersal (sea-bed) trawling, the VDUs would typically be [ 13, 351 an electronic navigational chart, two radars, two echosounders, one (horizontal) sonar and one netsonde (giving information in either colour-coded or object-coded form about the net). Such a number of VDUs, often apparently squeezed into small wheelhouses, has led to suggestions [36] that the information given by the VDUs should be integrated so that the skipper need only watch one ‘screen’ [37].

There seem to be no previous studies which consider task analysis methods applied to fishing. Neither are there any studies which relate task analysis and the use of sonar and radar apart from those already mentioned. Indeed, in 1995, there were only about 10 integrated fishing systems as suggested by this design in use in the world [38] and none


Top-level task

Embarking

Steaming out

Shooting the net

Trawling

Hauling the net

Stowing the gear

Steaming home

Docking

Table 2

Task supportive fishing aids

Electronic fishing aid used

None

Navigational chart

Radar

Echosounder (for depth)

Navigational chart

Radar

Echosounder (depth and seabed)

Sonar (seabed, general net position and rudder snag avoidance)

Netsonde (attitude and position of net, headrope and bottom ropes, rudder

snag avoidance)

Navigational chart

Radar


Sonar (seabed and fish location)

Netsonde (attitude and position of net, headrope and bottom ropes)

Navigational chart

Radar


Sonar (seabed, rudder snag avoidance)

Netsonde (attitude and position of net, headrope and bottom ropes, rudder

snag avoidance).

None

Navigational chart

Echosc.mder (for depth)

None

readily viewable in Europe. Thus, while the principles were applied in the usual manner of design, i.e. modifying the design ideas until compliance with all the principles was obtained, it was impossible to test the design practically, although the idea was discussed with a fishing skipper who was enthusiastic to try it should the implementation of the design become viably financially. Consequently, the new design has not been formally validated by implementation but a similar prototype design is being implemented for testing at sea, probably using simulated systems [36].

As has been discussed above, the task decomposition method chosen for generally integrating information is HTA. This also fits the situation here very well as fishermen use ‘computers’ as a tool to help in the catching of fish where they are used to locate the fish. Consequently, HTA will be used to describe real, complete and representative tasks [39] of a fishing skipper, which will indicate tasks requiring a human decision as well as those which are completely computer-based and which may, therefore, be candidates for computerised integration. The information needed by the skipper at any moment in time is apparent from the HTAs (in both tabular and diagrammatical formats [41) and these were used to identify necessary and redundant information. The necessary information for each task was technologically integrated in accordance with the principles already developed in both the task analysis and the wheelhouse design literature by applying the principles in a systematic manner to the design until this complied with all the principles.


While Table 2 summarises the typical tasks, together with the associated computer support, which a fishing skipper would carry out on a typical trawling trip [12, 351, it should be noted that the other non-computer&d fishing equipment such as the wheel or autopilot have not been included as this equipment is not relevant to the aspects of computerised information integration discussed here. Neither will legal requirements of the UK nor the EEC be considered as these vary for different classes of vessel and, in any case, do not relate to interface design.

Having described the application domain, we next need to analyse some typical tasks and so a typical task scenario will now be given. It will be noted that the scenario described is repeated perhaps as many as six or seven times a day so that its typicalness is most apposite for the consideration of information integration.

8. A typical task scenario

Of the eight different top-level tasks shown in Table 2, those of ‘shooting the net’ through to and including ‘hauling the net’ will be.repeated probably some three times in a day’s fishing [34]. If the vessel is away for more than a day, then the whole cycle of tasks may be repeated as the vessel may move to other fishing grounds.

Although Table 2 gives the top-level tasks, it is necessary to consider the fishing cycle at a lower task level in order to appreciate the user’s/skipper’s knowledge (Principle 2) and for the fishing aids to be exploited fully (Principle 1). A typical task scenario [lo] for capturing fish is shown for a high task level of granularity in Fig. 1. Essentially, there is a need for the skipper to locate the fish he decides to capture and then to position the net so that the fish enter and are trapped. In terms of computerised tools to achieve the goal, the skipper will use the echosounder for seabed information and possibly for fish location if there is sufficient potential catch beneath the vessel while simultaneously using the (horizontal scanning) sonar to locate fish in the surrounding waters. After deciding to target a particular shoal of fish (Task 1 in Fig. l), the skipper will then need to position the net (Task 2) so that the located target of fish will enter the net (Task 3). At the same time, the vessel will still be moving and so the navigational aids will be being used, particularly the chart and radar. In addition, the chart will be used to identify the position of the targeted fish (Task 2.1) and to decide the change in bearing needed (Tasks 2.2 and 2.3)

0 Capturing Fish

Fig. 1. Tasks associated with fishing (italics indicate use of aid; D indicates

-fizgq tasks needing decisions).


to move the vessel so that the net behind the vessel is in a position for the fish to swim into it. The skipper then checks the position of the vessel (net) and the fish (Task 3.1) and views the fish entering the net (Task 3.2). This cycle (summarised in Fig. 1) of the skipper selecting targets of fish and then manoeuvring the net so that the targets are caught in the net is repeated until the net is hauled. The number of times this is necessary will depend basically on the size of each shoal of fish and the size of the net; obviously, the net is hauled when it is full of fish but it may be hauled earlier on some occasions such as when moving to new fishing grounds.

Following the description of a typical task scenario and considering the tasks them- selves performed therein, the principles can be applied so that the information is integrated. The description of the integration proposed below is followed by a discussion of the main issues raised from integrating this information.

9. Integrating the information

It is clear from Fig. 1 that the skipper’s goal is to capture fish and so it follows that the information from the fishing aids should facilitate the manoeuvring of the net to catch the targeted fish and that, if possible, this task sequence should be completed on one screen (Principle 5). In addition, the fishing aids should locate suitable targets whilst the decision (Principle 1) as to whether to capture such targets (which may depend on a number of factors such as the catch to date) is made by the skipper (Principle 3).

However, referring to Table 2 and considering further the use of the fishing aids in the cycle of ‘shooting the net’ through ‘trawling’ to ‘hauling the net’, it can be seen from Table 2 that the (electronic) navigational chart, together with the radar and echosounder, are used throughout. Indeed, these are also used ‘steaming’ to and from the fishing grounds although the echosounder’s use also includes seabed profiling whilst fishing. Conse- quently, these three outputs should be integrated (Principle 4) in such a way that the skipper can still gain the information he needs but is only observing one screen (Principle 5). Although at present (1997), it is very expensive and beyond the budget of in-shore fishermen in the UK, a system is already manufactured which utilises an Automatic Radar Plotting Aid (ARPA) and this mirrors the functional integration (Principle 1) of the navigational chart and radar (Principle 4). The depth of freeboard (vertical depth of water beneath the vessel) should be indicated on this single integrated navigational screen, either in numerical form or in a colour-coded depth scale, with red [40] indicating a dangerously low freeboard.

When the echosounder is used to profile the seabed (Fig. 2), it is being used as a fishing rather than navigational aid and consequently this output should be grouped (Principle 1) with that from the sonar and netsonde. It would appear that these three different outputs should be integrated but this is technically not possible at the moment [38]. Neither would it be particularly helpful as the sonar is used to scan the surrounding waters through a 1 SO- degree hemisphere, while the echosounder only provides information about the seabed (and targets in water) immediately below the vessel. Consequently, it could be misleading and confusing for the user ifmthese outputs were to be combined into one ‘picture’ as there may well be parts of it missing. Add to this the fact that the output from both the sonar and


Fig. 2. Typical output from an echosounder (note the fish shoal on the left below the depth output).

the echosounder is constantly changing as the vessel and the targets move so that such a ‘picture’ could easily produce problems of visualisation in trying to imagine the situation in ‘three dimensions’. This arises from the echosounder giving information in only a

vertical plane while the sonar gives similar but different information in the horizontal plane. In addition, Principle 6 is very relevant to fishing vessels as the outputs of informa-

tion from the echosounder and horizontal sonar are similar and under stressful conditions

could be confused. A better solution to the problem seems to be to rely on the previous

knowledge of the skipper (Principle 2) gained through experience of visualising and interpreting the output from the echosounder and the sonar simultaneously and to incorporate the present outputs from the sonar and echosounder into separate windows but on

one screen, thus facilitating visualisation, particularly since attention to detail is important

in observing the information [41]. It has been suggested [lo] that such a solution would increase interpretation problems, but a larger screen allowing adequate size for each of the

outputs should help to prevent this. The netsonde is used to give information about the net, particularly that concerning its

attitude and position, as well as information about the amount of fish in the net. Such

systems vary (proportionally with cost) from being an acoustical output of the net’s mouth to a sophisticated object-coded ‘picture’ of the whole net, which is, in itself, a sound

representation of integration information [42]. Thus it can be seen that the object-coded data from the netsonde (Fig. 3) is preferable to a colour-coded acoustical display (similar to a sonar or echosounder) as this relates much more to the mental model of a net being towed behind the vessel. These latter systems usually give the actual position of the net and the amount of fish therein [43]. If the netsonde is capable of giving the position of the net, then this also becomes useful in a navigational context since


COURSE: 32’ SRTED: 32Kn pas: 5924.7zN p(Yl(y29 Id:tiIO 010 29.12 E

+- 11.6m SoFr- HARD g”

Fig. 3. Typical output from a Netsonde showing object-coded data.

the position of the net must be related to that of the vessel. Consequently, this information needs to be fed to the navigational screen with the net’s position being indicated on the chart. In addition and more importantly, the skipper’s overall goal is to catch fish and as we have seen, to do this the sonar and/or echosounder are used to locate the fish to be caught. Thus it is essential that the sonar system allows the skipper to indicate the chosen target (from the sonar screen) on the navigational screen (Principle 5) so that the net’s position, the vessel’s position and the target fish are all clearly indicated on the navigational screen, hence reducing the capture of the chosen fish to essentially a navigational problem.

There still remains the other information from the netsonde apart from the net’s position. This includes the attitude (orientation) of the net and the amount of fish already therein. This is usually represented by an object-coded ‘picture’ of the net with a colour- coded strip indicating the amount of fish contained in the net (Fig. 3).

This detailed information is needed to confirm that the target fish have entered the net and therefore it should be available immediately after the target fish have entered the net on the navigation screen. Toggling between the navigation screen and the netsonde screen would appear to be a solution.

Using a detailed HTA as part of the information integration has shown that the information the skipper needs to fish can be reduced to two screens, one containing the navigational information together with the fishing information which is necessary to capture the fish, the other screen containing more general fishing information such as positions of shoals and confirmation that the fish have entered, the net (Principle 5). For the fishing screen, it is essential that the information from the echosounder and sonar are separated by (white) space to avoid the possibility of confusion (Principle 6). These two screens can be.


Table 3

Summarial details of application of principles

Principle Comments

Groupings are based on analysis of decision of users (Table 2). For example, all but

decisions requiring detail of information are made on the navigational screen.

Users’ previous knowledge is used (Table 2 and Fig. 1) to inform integration of

navigational and fishing information. For example, the echosounder gives depth of

freeboard on navigation screen.

Users make decisions; all routine tasks are system-assigned. For example, skipper

decides to capture shoal; system indicates position of shoal on navigational chart.

All information transfer is automated where possible. Detailed information about the

net is only needed after manoeuvring the vessel.

Navigation is completed on one display unit and fishing-related tasks are completed

on another single display unit.

Only echosounder and sonar have similar outputs; these must be clearly separated in

the fishing screen design (not considered here). This also needs consideration at

screen design stage.

easily placed alongside each other for comparison, as in a ‘windows’ style environment, so that the user can toggle between the two.

Table 3 summarises the use of the principles in this application.

10. Discussion

A number of points worthy of discussion arise from the example and these can be divided into two categories: first those relating to information integration, and secondly, those of a more general nature.

In the example there were no redundant data and all the information given before integration was utilised after integration. However, in a more general situation, it is possible that some data could be lost through redundancy or even a misunderstanding at the task analysis stage. For example, if certain tasks were omitted from the analysis and these tasks utilised data unique to those tasks, then the data could easily be lost in the integration. As an example from the given application, if the task of viewing the fish (Task 3.2) were omitted from the HTA then the use of the netsonde could be considered redundant. This lays even more responsibility on the designer to carry out not only a correct task analysis but also one which includes all the tasks which need unique information.

Principle 6, which relates to keeping similar but different information apart, may need to be finally resolved at the screen design stage although it should also be invoked in the integrating stages discussed earlier. Thus, in the example above, the echosounder window and the sonar window integrated on the fishing screen would need to be separated suffi- ciently (possibly by white space or the netsonde window). This is not necessarily a draw- back as it links the two processes of designing for information integration and designing for optimum screen usability.

More generally, the use of HTA in the above example has shown a heavy dependency on the knowledge of the tasks that the user must carry out in order to achieve the overall


goal (in this case, catching fish). In addition, the designer has depended on knowledge about the computerised systems already being utilised (here the fishing aids and naviga-

tional chart) both in terms of their output of information and the uses to which this is usually put by the user (here the skipper). Exploiting this knowledge to its full potential,

those tasks which are sequential have been placed on one screen with the exception of the

netsonde (that of the confirmation that the fish have entered the net). However, the amount

of knowledge that the designer must have in order to carry out the task analysis correctly, coupled with the knowledge needed for a sound integration, places a great burden and

responsibility on the designer. The computer systems considered in the example above were very simple in informatics terms as they all only give one ‘picture’ of information at any one time. The systems were also only used for one of two purposes - that of

navigating the vessel and that of facilitating the catching of fish. Case studies of integrat-

ing information in more traditional information systems should be carried out to ascertain the feasibility of using task analysis as a basis for more general applications of information

integration. Another issue arising from using the principles is that of the depth of task analysis. It

was seen in the example that a top-level analysis was insufficient to reveal the detail of

information used in each sub-task and that this detail was used to inform the process of

integrating the information. This raises two potential problems which are common [26] to task analysis methods: first, that of the designer having sufficient skill to undertake the task

analysis correctly and, secondly, that of the time and resources needed to undertake such an analysis. Again, the example used was ideal for this as the second level of analysis

revealed the necessary detail and with the systems only giving information for one user- goal (that of catching fish) the resourcing of such task analysis was minimal. In a more

complicated and traditional information system, the usual problems of time and finance [26] associated with resourcing in-depth task analysis must surely pertain.

11. Conclusion

It has been shown that it is possible to use HTA as a basis for a design for information integration using the six principles derived from the literature. However, while this may be

satisfactory for small amounts of information which have to be integrated, there may be problems associated with in-depth task analysis in using this approach for larger amounts of information, especially if the information is used for a number of different uses, as each

user’s tasks may need to be analysed separately. In particular, the analyst must guard against the loss of unique information. Further studies are needed to confirm the success of this approach. There is also a need to validate designs produced as a result of using this method of information integration in order to demonstrate practically its feasibility.

Acknowledgements

The author would like to thank Dr Dan Diaper and Dr Steve Howard for helpful discussion during the development of this paper.


References

[l] Company, 1997, private communication with the author.

[2] Booher, H.R., (Editor), 1990, Manprint: An Approach to Systems Integration, 1990, Van Nostrand

Reinhold, Amsterdam.

[3] Bellotti, V.M.E., 1990. A framework for assessing applicability of HCI techniques. In: D. Diaper,

D. Gilmore, G. Cockton and B. Shackel (Editors), Human-Computer Interaction, Interact ‘90, North

Holland, Elsevier Science.

[4] Shepherd, A., 1995. Task analysis as a framework for examining HCI tasks. In: Perspectives on Human

Computer Interaction: Diverse Approaches, A. Monk and N.G. Gilbert (Editors), Academic Press, London,

Chapter 7.

[5] Wilson, D.M., Barnard, J.P., Green, R.G.T. and Maclean, A., 1988, Knowledge Based Task Analysis for

Human-Computer Systems. In: G. van Der Veer, R.G.T. Green and M.D. Murray, Working with Com-

puters: Theory versus Outcome, Academic Press, London.

[6] Benyon, D., 1995, A Data Centred Framework for User-centred Design. In: K. Norby, P.H. Helmerso, D.J.

Gilmore and S.A. Amesen (Editors), Human Computer Interaction, Interact ‘95, Chapman and Hall,

London, on behalf of the International Federation of Information Processing (IFIP), pp. 197-202.

]7] Rasmussen, J. and Goodstein, L.P., 1988. Information Technology and Work. In. M. Helander (Editor),

Handbook of Human-Computer Interaction, North-Holland,. Elsevier Science Publishers, Chapter 9.

[8] Lovesey, E.J., 1995. Information Overload in the Cockpit, Keynote Address, Information Overload,

Colloquium of Professional Group C5, Institution of Electrical Engineers, 29th November 1995, ISSN

0963-3308, 951223.

[9] Ivergard, T., 1989. Handbook of Control Room Design and Ergonomics, London, Taylor & Francis.

[ 101 Mills, S., 1995b. Improving acoustical fishing aids for small fishing vessels, Recent developments in radar

and sonar imaging systems: what next?, Colloquium of Professional Group E15, Institution of Electrical

Engineers, 12th December, 1995, ISDN 0963-3308, 1995/239.

[l 11 Witty, J.H., 1984. Fishing Vessel Navigation, J. Inst. Navigation, 37(2): 279-285; also reproduced in

Specialised Navigation, a seminar held on 1st December, 1983, in London, The Nautical Institute,

London, pp. 26-32.

1121 J. Stoop, Redesign of Bridge Layout and Equipment for Fishing Vessels, J. Inst. Navigation 43 (2) (1990)

215-228.

[ 131 Stoop, J., 1990b, Redesign of Bridge Layout and Equipment for Fishing Vessels. In: C.M. Haslegrave, J.R.

Wilson, E.N. Corlett and I. Manenica, Proceedings of the Third International Occupational Ergonomics

Symposium, Zadar, Yugoslavia, 18-20 April, 1989, Taylor and Francis, London.

[14] Harre, I., 1987, Functional Area Integration on Merchant and Research Vessels, Paper 27, Data Dissemina-

tion and Display - Electronics in Navigation, 1987, Conference of the Royal Institute of Navigation,

London, Royal Institute of Navigation, London.

[15] Osga, G.A., 1989. User-computer interface issues for future ship combat controls, Proceedings of the

Human Factors Society 33rd Annual Meeting, 1989, Human Factors Society, 1079-1095, Santa Monica, California, pp. 1079-1095.

[16] G.R. Wilkinson, Ergonomics in Ship Design, J. Inst. Navigation 27 (4) (1974) 471-478.

WI Gilliksen, J, Sandblad, B., Lind, M., 1996, The nature of user interface design - The role of domain

knowledge. In: A. Sutcliffe, D. Benyon and F. van Assche (Editors), Domain Knowledge for Interactive

System Design, Chapman and Hall, London.

]251 Shepherd, A., 1989. Analysis and training in information technology tasks In: D. Diaper (Editor), 1989,

Task Analysis for Human-Computer Interaction, Ellis Horwood Limited, Chichester, Chapter 1,

WI Kirwan, B., Ainsworth, L.K., 1992, A Guide to Task Analysis, Taylor and Francis, London.

1271 Carey, M.S., Stammers, R.B. and Astley, J.A., 1989 Human-computer interaction design. The Potential and Pitfalls of Hierarchical Task Analysis, Chapter 2. In: D. Diaper (Editor), 1989, Task Analysis for Human- Computer Interaction, Ellis Horwood Limited, Chichester.

]281 Diaper, D.. 1989, Task Analysis for Knowledge Descriptions (TAKD): the method and an example, Chapter

4. In D. Diaper (Editor), 1989, Task Analysis for Human-Computer Interaction, Ellis Horwood Limited, Chichester.


1291 Johnson, P., 1989, Supporting system design by analyzing current task knowledge, Chapter 5. In: D. Diaper

(Editor), 1989, Task Analysis for Human-Computer Interaction, Ellis Horwood Limited, Chichester.

[30] Johnson, P., 1992, Human-Computer Interaction Psychology Task Analysis and Software Engineering,

McGraw Hill Book Company, Maidenhead.

[31] Payne, S.J. and Green, T.R.G., 1986. Task-action grammars: a model of the mental representation of task

languages, Human-Computer Interaction, 2(2): 93-133.

[32] Card, S.K., Moran, T.P., Newell, A., 1983. The Psychology of Human-Computer Interaction, Lawrence

Erlbaum, Hillsdale, NJ.

[33] FAO, 1980, Echo Sounding and Sonar for Fishing, Food and Agriculture Organisation of the United

Nations, Fishing News Books Ltd., Famham.

[34] Mills, S., 1993. A Preliminary Analysis of a Skipper’s Interaction with Electronic Fishing Aids, Paper 47,

Proceedings of the First International Maritime Conference on The Impact of New Technologies on the

Marine Industries, Warsash, Southampton, UK, 1993, Southampton Institute of Higher Education, South-

ampton.

[35] Smalley, J.P.A., 1972. Stem Trawler Bridge Design - Ergonomic Considerations, Post Graduate Diploma

(Work Design and Ergonomics), University of Birmingham.

[36] Anon., 1995. Integrated Ship Control System, Aalborg, Fiske&b 2000 A/S.

[37] Beth, K and Andersen, S., 1995. Fiske&b 2000, Aalborg, Fiskeskib 2000 A/s.

[38] Tech, 1995, Private communication with technical expert.

[39] Lewis, C. and Rieman, J., 1995. Getting to Know Users and Their Tasks. In: R.M. Baecker, J. Grudin,

W.A.S. Buxton and S. Greenberg, (Editors), Readings in Human-Computer Interaction: Towards the Year

2000, 2nd edn., Morgan Kaufmann Publishers Inc., San Francisco, Chapter 2.

[40] Widdel, H. and Post, D.L., 1992. Color in Electronic Displays, Plenum Press, New York.

[41] B.P. Goettl, CD. Wickens, A.F. Kramer, Integrated displays and the perception of graphical data, Ergo-

nomics 34 (8) (1991) 1047-1063.

[42] C.M. Caswell, C.D. Wickens, Information integration and the object display, An interaction of task demands

and display superiority, Ergonomics 30 (3) (1987) 5 1 l-527.

[43] Mills, S., 1995a. Usability Problems of Acoustical Fishing Aids, Displays, 16(3): 115-121.

integrating information — a task-orientated approach

Documents