5.1 TESTING THIRD PROTOTYPE AT BRITISH AIRWAYS THE CONTROLLERS AT BR...

6.5.1 Testing third prototype at British Airways

The controllers at British Airways handles problem concerning the following resources

(“The airline business”, 2001):

§ Fleet size: 263

§ Employees: 62 844

§ Passengers: 36 million

Before performing the test, new questions and goals were prepared:

q Is it possible to solve problems in the traditional way, not using the crew recovery

solver?

q What functionality is missing?

q Is the division on main and sub functions correct?

q What information is most critical?

The testing focused on checking all the usability and functional requirements, as this was

possible now that the Operations Monitor could communicate with the rest of

Descartes, which could therefore be incorporated into the scenario.

This test was performed in a meeting room at British Airways Compass Center at

Heathrow in London, and was arranged by responsible for Descartes. Present were three

representatives from British Airways; one former crew controller, one manager, one from

Operations Management, and a representative from Carmen; the responsible person for

the crew recovery solver. The meeting lasted for almost two hours, and a mini disc player

recorded all audio with a small microphone placed on the table, to not forget any of the

valuable comments.

The technique consisted of two laptops connected through a network, with one screen

projected on the wall. Unfortunately the laptop containing the crew recovery solver

experienced technical problems, it accidentally turned off now and then. This affected

the demonstration to some extent, since the scenario was interrupted and could not be

shown in one interval. Time had to be spent waiting for the computer to restart, and this

contributed to irritation and anxiety among all persons, but also it also contributed to

laughs and jokes.

At first the background, the ideas and the concept were presented, the user interface was

shown in details, and then a full demonstration of the scenario was shown. We

performed the demonstration of the scenario and the responsible for the crew recovery

solver demonstrated the Disruption Manager and the XML-handling. During the

presentation, questions were asked and discussions came up.

Unfortunately there was no time for putting the graphical design in focus when we were

to present this prototype at British Airways in London, and therefore the appearance is

not very satisfying. This prototype was instead more technically advanced, since the alerts

and the information presented about the alerts were drawn from a database that we had

created. The communication with the Disruption Manager was implemented, meaning

we could communicate through sending XML-messages, creating disruptions.

c 1 = C o m p u te r 1

c 2 = C o m p u te r 2

Figure 6-8 Flow chart of the demonstrated scenario

The demonstrated scenario, where a flight was delayed 60 minutes, affected three

crewmembers since their connecting flights were to be missed. The new way of solving

the problem, using Descartes, was demonstrated; to create a disruption and send it to the

solvers. The traditional way of solving the problem was demonstrated; presenting

information about each affected crewmember, their rosters and personal information,

and compared it to a stand by list with rosters. When finding three stand bys, they were

signed to the flights, and the original crewmembers schedules were changed.

Results

The test persons were very familiar with the Descartes concept and development, and

had no problems respecting the fact that it was just a prototype, not fully implemented. It

was rather an advantage that the prototype was not graphically completed, since the

focus were not towards the graphical appearance but to the concept and the

functionality.

q Is it possible to solve problems in the traditional way, not using the crew recovery solver?

Consideration was taken to the fact that problems could be solved without the

solvers, leading to conviction that the information presented in the interface was

enough, and satisfaction among the test persons with the fact that this had been

considered at all in the design. They were also satisfied with the way a disruption

was created, and how alerts could be compared with each other.

q What information is most critical?

The most critical information is always depending on the nature of the problem,

but in general they are: the route, the time and the knock on effect.

q Is the division on main and sub functions correct? What functionality is missing?

The division of main and sub functions were satisfying, even though suggestions

for added functionality came up presented here:

§ To be able to work with scenarios, being able to move around flights or

crewmembers presented as graphical objects in a Gantt view. When crew

rosters are displayed in a Gantt format then overlaps of disruptions can be

seen physically; when trips are displayed as graphical objects they could be

repaired on screen. One of the test persons used an excellent metaphor as an

argument: “It is like an analogue or a digital watch; you look at the problem,

you don’t read the numbers. Overlap or not, you can see the picture of the

time; you don’t read the numbers to work out what the time is. It is exactly

the same with a Tracie screen where you have to read the screen, and a Gantt

chart where you assess the gaps between.”

§ Having suitable stand bys appearing as graphical objects in the crew roster, so

that it would be able to sign a stand by immediately. The destinations are

usually of no matter when working with roster maintenance, just to fill the

gaps with available crew.

§ To be able to appreciate the nature of the problems, the most important

factors to appear are the route, the time and the knock on effect. The easiest

way would be to show this as graphical objects, not having to read them It is

almost irrelevant what the route is, more if one object collides with another,

if they are night stops or not, and just being able to move and replace them.

The objects have to be comparable, and moveable by drag and drop or point

and place.

§ In the alert view, sometimes the most relevant fact to see quickly is when to

take action rather then when an alert actually occurs. In the cases when there

will be just one opportunity to take action, then this is very important.

§ Navigation in and interaction with the interface should be configurable by

keystrokes or be mouse driven, preferably mouse driven, from the test

person’s personal experience it is a disaster to mix the two due to the

consequences of added confusion and time-loss.

§ The timeframe and expansion has to be deeply considered. The timeline in

the alert view has to be expandable, since there is a personalization in peoples

time view, one person would prefer to see the whole day, another prefers to

see what will happen the next hour, and so forth, so something in between is

the optimum.

§ In the detailed alert view, it is not a good idea to separate the route from the

arrival/departure times, since the term used is “the six thirty from Paris”,

meaning it is preferable to support that in the visualization, based upon the

terms used in the operations control.

§ In the detailed alert view, all relevant information should be displayed

without requiring scrolling.

§ When comparing several alerts with each other, moving them from the

detailed alert view to the workspace, then the lines of information will be too

long, meaning that the cognitive load on the user will increase trying not to

loose the lines while scrolling them.

§ The optimum solution to the visualization of the alert would be to have one

object saying this is the possible problem, and one object next to it saying this

is the possible solution.

Findings showed that when the way the controllers work today can be supported as well

as derive advantages from other graphical tools, closing in on the gap from the

graphically more advanced tools used in planning to the tools used at day of operations,

then the concept is actually satisfying.