4 FUTURE WORK IT WOULD BE RECOMMENDABLE TO INVESTIGATE HOW DESCARTES...

9.4 Future work

It would be recommendable to investigate how Descartes will change the organization in

a control room, what new routines there would be, what the controllers new tasks would

consist of, an so on.

To create more correct analysis and recommendations in order of the complex nature of

the context that is the operations control, it is recommended to perform research

including all resource areas within it. When this is done, then it is possible to abstract the

different parts of it to adjust the tools for a specific user target group in a much more

correct way.

The next step in the iterative design process would be to implement a prototype of all the

parts that Descartes consists of, to perform more realistic tests with the entire concept.

The prototype should be developed in accordance to the design recommendations

compiled in this thesis. Since there is a great difference in how the controllers are used to

computers, then it is recommended for the prototype to support the possibility to create

macros for the users to personalize their input work.

When designing the Operations Monitors for other resource areas, then a new user and

task analysis should be performed, since their work differs a lot from the crew

controllers, even though it is in the same context. This thesis could be used in

preparation for such a user study, but the design recommendations are not valid.

One very exciting project suggestion is to investigate how it would be to add virtual

reality technique into the day of operation, by using gloves or similar be able to physically

move around boxes and blocks presenting routes in crew rosters or flights.

1 0 C O N C L U S I O N S

This master thesis explores what are the most important factors in the work performed

in the context of an operations control at an airline, and what tool can best support the

controllers work. The research question has been narrowed down to; “How should a

graphical user interface for an airline crew control Operations Monitor be designed so that the user, the

crew controllers at an airline company, is best supported in both their current work, and also their future

work?” To be able to answer this question, several methods have been used. A user and a

task analysis have been created, resulting in four prototypes, which have been tested

upon real users and expert groups.

From the results of the user tests, the usability and functional requirements were

measured for consistency, and the results were satisfying considering the means that were

available. The following design recommendations were derived from these results:

Minimize the mental constraint on the user

Striving for consistency using static windows for presenting dynamic data

Minimize the number of components that the Operations Monitor consists of

Allow several processes run simultaneously inside the Operations Monitor

By using split-screen several windows can be open simultaneously

The Operations Monitor should be kept in one window

Be consistent

Same font for title bars and buttons

The title bars backgrounds different than other background colors

The different components should be aligned to a reference frame

Minimize the need of scrolling when displaying information

Provide feedback

Make the borders of the buttons stand out when marked

When choosing a button, let it be “pressed”

The alarms should change in appearance in accordance to status

No sound feedback

Consider the choice of icons and colors from an intercultural perspective

Limit the number of colors as information carriers due to color blindness

Minimize the input actions

Use the mouse as a main input

Allow keyboard shortcuts and macros as a complement

Allow regretting actions by providing a “back button”

Support the user’s current way of working

Allow the user to decide to what degree the monitor should be used:

As a monitoring source

As an information source.

As a scenario tool

Create an internal instant message system

Support both a focus and an overview over the current status of operations

Visualize the alarms as graphical objects

Visualize the time of occurrence, the impact, status, and type

Visualize by using a focus+context technique

Make the users feel in control

Allow users to incorporate their own judgement, allowing them for instance to

deliberately break certain rules

Allow customization of the alerts by sorting them in preferred priority

Create the timeline as dynamic, to be customized

Support usage in both time critical and time uncritical conditions

Toolbars are preferably used for quick access to often-used functions

Progress bar displaying the status of the process

These design recommendations were the basis for answering the questions set up in the

beginning of the work, and for the concept and design of the final prototype. Since the

crew controller’s task will most probably change using the Operations Monitor, from

detecting alarms to solely solving them, it is important supporting them in the traditional

way of working. The concept of the Operations Monitor is built upon the definition of

alarms generated from an alarm server, and the purpose is therefore to present the

appearance of alarms and details of them. This data presented is both static and dynamic,

meaning the design of the Operations Monitor can be described as a focus + context

visualization task.

The most important role of the Operations Monitor would be to reduce the

information available, to act as a filter sorting out alarms and sorting out information.

The knowledge and experience of a controller can never be replaced by automation, and

it is therefore important to support that the system can be justified according to the

unique nature of each problem in combination with the users individual preferences.

Founded upon a user analysis and a task analysis, general design recommendations and

human factors affecting the controllers, their work and their environment, suggestions

for an interface design of the concept Operations Monitor has been concluded.

Three prototypes have been implemented and even more ideas have been experimented

with. Evaluated from real user tests, the judgment has been done of what tool to be

useful, deciding what functions are to be main functions and which are to be sub

functions. The prototypes are the results derived from the recommendations and

analyses, being the physical proof of our knowledge and hard work.

The results of this thesis have been affected by the difficulties of separating the concept

of one module of a larger system in order to evaluate it, especially a system that is still

under development. The context in which the system is to be is very specific, the user

group is narrowed and specialized, and this master thesis can be used as a foundation

when designing for this environment since it describes what factors are important

considering and what the problems may be.

1 1 R E F E R E N C E S