Refining the NERC User Interface

Roger Attfield

National Air Traffic Services

CAA House, 45-49 Kingsway

London, WC2B 6TE, UK

INTRODUCTION

The NERC user interface was designed by user interface specialists working with user participants and with prototyping of the key aspects. Although we are still working on quantatitive assessments of the usability of the resulting system, our qualitative assessments show that we have achieved the high standard for which we strived. However, as with any user interface design some choices that looked good on paper or in a prototype have proved poor in practice. In this paper we discuss some of these usability issues and the changes we are making to resolve them. With the advantage of hindsight, we also consider whether these problems might have been avoided in the original design. INTERACTING WITH ELECTRONIC STRIPS

The planner controller's task is to agree the flight levels at which aircraft will enter and leave his/her sector with the planners for the adjacent sector ('coordination'). The system supports this task with functionality for electronic 'offers'. The user interface for receiving and accepting offers works well, but that for making offers does not under some circumstances. The interaction sequence is that the planner: selects ('hooks') the appropriate flight strip; clicks on the exit level area of the strip to bring up a 'coord out' dialog box (or uses a 'coord out' function key) and enters proposed exit level. The system sends the offer to the next sector at the appropriate time (depends on the flight's route and the sectors involved). The problem with this interaction lies with the need to hook the strip before bringing up 'coord out'. This was because of a central concept of the user interface design: that flight data input relates to the single 'hooked' flight - ensuring that we have a clear context for the interaction and helping make sure that the controller always has the 'right' flight. Following this principle the design only provided the 'coord out' and other buttons on a hooked strip. This lead to one more interaction than was necessary. On its own, that would have been a minor defect but the original design had a further misfeature: it was not possible to 'hook' from the right hand end of the strip. This arose because we were trying to disambiguate three interactions with the strips: clicking on embedded buttons in the strip, click on the strip itself to hook or unhook, and press and hold to bring up a pop-up menu. To keep the elements separate we chose to disallow hooking from the areas of the strip containing buttons .We improved the 'coord out' interaction by making the coord out buttons available on an unhooked strip and making the button action hook the strip as well as bring up the dialog box. We also made whole strip sensitive for hooking. This may seem an elementary error which we should have identified and fixed much earlier in NERC's development. We missed it because we expected the planners to set the exit levels for a flight immediately after accepting in it; in that situation the flight is already hooked so the usability problem does not occur. The ATC procedures still recommend setting the exit level straight after accept, but there are sufficient cases where that rule cannot be applied that the problem occurs routinely. The root cause of the poor design was that the scenarios we used in developing the design did not include these cases. Knowing that you have a sufficient set of scenarios remains a difficult judgement.

STANDING AGREEMENT TRAFFIC

The other substantial usability issue for the planner controller arises from a difference between the operational method used at the current London Air Traffic Control Centre (LATCC) and that originally proposed for NERC. At LATTC aircraft are coordinated automatically using 'standing agreements' but for NERC it was intended that the planner would explicitly accept every flight. This has proved to cause too high a workload, so the system has been changed to follow the LATCC model. Making this functional change has a significant impact on the user interface . In the original design we had ensured that strips only moved into the 'accepted' bay under the planner's control. This is a key feature because it prevents the strips with which the planner is interacting from moving unpredictably. If the automatically accepted strips were placed in the correct place in the bay they would break this rule. We dealt with this problem by building on an existing feature of the user interface. The strips are ordered by sorting using keys that include dynamic data, hence automatic re-sorting would have caused unpredictable movement . However, the strip order is important and so we wanted restore it quickly but without imposing a housekeeping task on our users. Our solution to this was to identify a set of 'opportunities' for re-sorting - for example when the planner manually brought a strip into the bay. We adopted this technique for the automatically accepted strips: they are initially put in a separate section of the bay and then moved to their 'normal' position at the next re-sort opportunity.

SILENT HANDOVER ALERTS

In addition to its primary civil air traffic function, NERC also supports the London Joint Area Operation (LJAO) which controls military flights traversing civil air space. LJAO procedures include a 'silent handover' in which controllers follow a system mediated dialogue to pass an aircraft from one team to another (silent because the controllers don't need to speak to each other). This is supported by an existing flight data processing system called EDDUS which has been combined with the other NERC systems to provide an integrated user interface. As with the civil user interface, the design is built around electronic flight strips. We have found two problems with this part of the LJAO user interface. First, the strip interactions suffer from an equivalent problem to that with the civil strips described above. The same solution has also been applied. Secondly, we found that the offering controller did not notice the display indications telling him or her that the receiving controller had initiated the dialogue. This has been fixed by applying our standard alert for notifying the controller of a new task - we infill the appropriate area on the strip [Cozens 1998]. With hindsight, this highlight should have been part of the original design. It was overlooked because we incorporated the 'working' EDDUS user interface directly into the NERC context. The EDDUS user interface does not distinguish between low priority data updates and those that indicate new work - it demands positive acknowledgement of every change - and we simply mapped this onto the NERC design for low priority changes. Had we prototyped silent handover we most likely would have identified the need to alert the controller to the start of a new transaction (almost certainly - a sister project looking at the main military ATC centre did prototype silent handover and did find the problem). However, project constraints on time and effort limited the LJAO prototyping to a simple facade to validate the strip layouts. This choice was primarily because the new civil ATC functionality took precedence; the fact that we were transplanting the EDDUS user interface into NERC reinforced this view. RADAR COLOURS

One of the most difficult and contentious elements of the NERC user interface has been the use of colour, especially for the radar display. Not only was this a pioneering effort - previously only monochrome displays had provided sufficient resolution - but we were also substantially increasing the quantity of information displayed for each radar track by including significant flight plan and status data. To determine an appropriate mixture of colour, symbology and text labeling we prototyped a variety of solutions before settling on a basic scheme. For the actual colours we adopted a scheme devised by a NATS research project 'DAWS'. This used groups of colours matched in saturation and brightness to create a 'layered' effect. In our original design, the base colour is a mid grey, background maps use dull colours, mid range colours are used for highlights and targets and track data block text is black. We diverged from the DAWS recommendations in two respects: we did not always use filled target symbols and we did not use white 'flags' behind the track data block text. We used filled / open symbols to show a piece of status data and rejected flags both for making the data blocks too prominent and because they obscured the maps. While the system was being developed, ongoing simulation work indicated problems with this scheme and once we started large scale tests with the real system it was apparent that the prominence of the targets and the legibility of the track data block text were not sufficient. This has been remedied by making the targets yellow (and normally filled) and track data block text white. With hindsight we can see that when we diverged from DAWS recommendations we did not go far enough. At the same time, we also made a number of other changes to the colour scheme. In particular we refined the way radar tracks were classified changing from two main types: foreground and background, to three: foreground, background and 'others' (tracks without flight plans). This was needed because the NERC radar system was 'seeing' many aircraft outside controlled airspace which are 'clutter' for NERC controllers. We were not surprised that the original colours were not good enough; we had concluded the prototyping work with a design we were confident could be made to work and so could commit to the system development.

CONCLUSIONS

We can, arguably, claim to have followed 'best practice' in the design of the NERC user interface and we think our experience shows the 'usability limits' inherent in large, bespoke developments (especially under a firm fixed price contract). We suggest there are three fundamental factors that contribute to these limits: project constraints on effort and time will always restrict the number of iterations of the design (although we feel that had we done more prototyping we might well have improved the 'wrong' parts of the design); some aspects of the users' tasks will only make their presence felt in the real world (this is especially true in a real time context) and the overall system requirements evolve and/or our understanding of what is required improves over time.The remedy, of course, is to maintain the usability focus through the latter stages of system development and deployment and, were necessary, be prepared to iterate the delivered system.

REFERENCES

Cozens J. (1998) The User Interface of Britain's New En-Route Centre for Air Traffic Control,HCI 98

Industry day Paper