STS11 037

Examensarbete 30 hpJuni 2011

Android for Fighter Pilots

Replacing Paper with Tablet Technology

Christopher DiLorenzoChristopher Malefors

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student

Abstract

Android for Fighter Pilots

Christopher DiLorenzo & Christopher Malefors

This thesis is produced as the graduate work in the Master of Science programme Systems in Technology and Society at Uppsala University. The thesis was conducted at Saab Aeronautics situated in Linköping during the spring of 2011.The scope of the thesis was to examine if a modern tablet with the Android operating system would suit as a replacement for the papers (known as the flight bag) that are currently being used by fighter pilots operating the JAS 39 Gripen. To do so the authors used a Cognitive Work Analysis to get clear requirements for which functions need replacing. When the requirements were set the use of User Centered Design was used in conjunction with various application development- and design theories. Various prototyping sessions were carried out to pinpoint design flaws and iteratively improve the applications functionality. The process started with paper prototyping and ended with software prototyping. The prototypes were continuosly evaluated with employees at Saab Aeronautics and fighter pilot representatives.The final prototype can be said to have replaced a significant amount of the functionality of the old flight bag. However there is still plenty of work to do to have an Android tablet used in the cockpit of a fighter jet.

ISSN: 1650-8319, STS11037Examinator: Elísabet AndrésdóttirÄmnesgranskare: Anders JanssonHandledare: Torbjörn Fransson & Michael Petterstedt

SammanfattningDet här examensarbetet är den avslutande delen av civilingenjörsprogrammet i System i Teknik och Samhälle vid Uppsala universitet. Examensarbetet utfördes under vårterminen 2011 hos Saab Aeronautics i Linköping. Uppgiften var att undersöka huruvida det är möjligt med hjälp av en "surfplatta" ersätta de papper som stridspiloter än i dag har med sig upp i luften. Fokus under arbetet kom att vara utveckling av Androidapplikationer och se till att dessa inte enbart ersätter funktionaliteten hos papper, utan även att applikationerna är användbara hos slutanvändarna.Genom att utföra en Cognitive Work Analysis utforskades behovsbilden hos olika aktörer för projektet. Resultaten från CWA utgjorde de krav för vad som var tvunget att bli implementerat för att pappersfunktionaliteten skulle kunna sägas vara helt ersatt. Med hjälp av de krav som var spunna ur CWA användes diverse prototypningstekniker, samt kunskap om interaktionsdesign och usability för att snabbt skapa ett par koncept att diskutera och utvärdera tillsammans med anställda på Saab samt pilotrepresentanter. Den information som kom från prototyperna togs tillvara och en del av denna kom att bli implementerad. Under utvecklingsprocessen har idéer, tankar och förslag kontinuerligt diskuterats mellan författarna, anställda på Saab Aeronautics, samt pilotrepresentanter. Detta för att applikationen i slutänden ska bli så användbar som möjligt.Slutsatsen gällande detta examensarbete är att grundläggande funktionalitet har överförts till androidplattformen. Det är dock mycket kvar som behöver undersökas samt genomföras innan applikationen kan anses vara helt klar och flygfärdig.

GLOSSARYActivityIn this thesis it is used in the android programming sense to mean different “windows”. For example if you are at the HOME activity you may see a button which leads to the DRAW activity if pressed. The HOME activity is then removed from the screen and the application is now in the DRAW activity. (Android Reference Library, 2011)Analog Flight BagSee “Flight Bag”Design spaceDesign space refers to ideas that evolve under certain constraints.Electronic Flight Bag (EFB)A digitalized flight bag which replaces, and usually improves upon, the functionality of the analog flight bag.Flight BagThe flight bag is an aid brought onto the aircraft by the pilot. In this thesis it usually refers to the flight bag which is attached to the thighs of a fighterpilot.Mockup or Mock-upCreating mock-ups, in systems engineering, is a way of designing a user interface by drawing it on paper or as a computer image. Should the mock-up have functionality it is called a prototype. (Wikipedia, 2011)Software developmentSoftware development means going from an idea to a finished product. In this case however the finished product is a prototype. Software development iteratively encompasses but is not limited to (in no particular order) introductory research, design, prototyping, coding and testing.

AcknowledgementsWe would like to thank (in alphabetical order) Torbjörn Fransson, Anders Jansson and Mikael Petterstedt for their deep subject knowledge and constant encouragement. Also the fighter pilots, without whom this thesis could never have been, deserve our undying gratitude. They performed usability tests, listened, gave feedback and had an endless amount of suggestions for new functions and improvements.Saab and Combitech are also to be thanked for hosting this thesis. We would also like to thank Yogi Berra for his timeless malapropisms, which seem to be uncannily appropriate for different situations encountered during the course of this thesis.And last but not least Erik Löthman, Kristian Samuelsson, Alexander Lindstedt and Johnny Mnemonic for livening up the workplace and giving us an external opinion whether we need one or not.

Table of Contents

1. Introduction 31.1 Purpose 31.2 Delimitations 41.3 Disposition 51.4 The General Method 5

2 Background 72.1 The Military Flight Bag 72.2 The Electronic Flight Bag 72.3 Saab Aeronautics and the JAS 39 Gripen 92.4 Android on the Samsung Galaxy Tab 92.5 Moving on 10

3 Pre Study: Cognitive Work Analysis 123.1 Theoretical Framework: Cognitive Work Analysis (CWA) 123.2 Method: Generic CWA 133.3 CWA Results 143.4 Moving On 16

4 Application Development 174.1 User Centered Design 174.2 Pre Evaluation Prototyping 204.3 Evaluating Design Theory 214.4 Interaction 244.5 Interaction Framework 244.6 Usability & Interface Design 244.7 Moving On 27

5 The Development Process 285.1 The Process Explained 285.2 Cycle 1: Paper and Keynote Prototyping 285.3 Cycle 2: Initial Code Implementation 295.4 Cycle 3 to n: The Evaluation Implementation Process 305.6 Motivation of this Process 305.7 Credibility 305.8 Moving On 31

6 Application Development Results 326.1 Paper Prototyping 326.2 Keynote Prototyping 426.3 Software Prototyping Round 1 476.4 Software Prototyping Round 2 556.5 Software Prototyping Round 3 626.6 Moving On 65

7 Discussion 66

1

7.1 Design and Hardware 667.2 Cognitive Work Analysis 677.3 Prototyping 677.4 Testing 687.5 Classification 697.6 Conclusions 697.7 Self Criticism 69

8 Further Research 70

9 Sources 719.1 Published Sources 719.2 Unpublished Sources 729.3 Media Sources 729.4 Interviews, Usability Tests & Workplace Discussions 73

10 Appendix 7310.1 A Developers Toolbox 7310.2 FAA EFB Software and Hardware Classifications 7410.3 Cognitive Work Analysis Questions 7610.4 Usability Test Script 77

2

1. Introduction"The future ain't what it used to be"

- Yogi BerraIn Greek mythology, Icarus and his father Daedalus were trapped in a tower on the island of Crete. Daedalus, (meaning “cunning worker”) being a skillfull craftsman and artisan, to escape he fashioned a pair of wings made of wax and feathers for himself and his son Icarus. Daedalus told Icarus that he should not fly too close to the sun, as this would melt the wax, nor too close to the sea, as this might dampen the wings and make them too heavy to fly with. With his fathers verbal instructions in mind Icarus promptly flew straight for the sun and fell into the sea. Why did Icarus ignore his fathers warnings when they were of mortal consequence to him? What if Icarus had owned a modern altimeter, giving him feedback of his altitude along with warnings of dangerous limits? What if Icarus had brought with him a GPS navigator or a map, showing him where he was heading and what course to take? Would he still have done the wrong thing? Perhaps; But then the hubris of Icarus would never have occurred, and there would be no lesson to be learned (Graves, 2011).Today flying is no miracle, it is a commodity used for civilian purposes, but also for military applications. Advanced fighter jets fly faster than the speed of sound, while space shuttles like Atlantis break the earths atmosphere and go into orbit. Inside the fighter jets sit highly trained fighter pilots amongst a myriad of screens, buttons and switches. The fighter jet is one of the ultimate examples of a complex sociotechnical system and there can be no doubt that having a proper design for the different components it is made of is absolutely essential. The interface the fighter pilot uses to interact with the fighter jet needs to be clear and efficient and take into account both machine error and the human condition.In aviation some functions are still in the process of being digitalized. In civil aviation the flight bag has largely been replaced with an electronic flight bag but in fighter jets almost all flight bags are still just paper. The flight bag is maintained and used by the fighter pilot and contains information such as maps, routes, communication frequencies, weather and other vital information. These types of information could be stored on a tablet computer or some other electronic device. The market for tablet computers has recently exploded and the civilian aviation companies, as well as the pilot community, are increasingly interested to see if a tablet could replace the flight bag since some attempts have been fairly successful. So far, very few attempts at an electronic flight bag have been directed at military aviation and fighter jets in particular. Saab Aeronautics in Linköping, Sweden, aims to change this and have initiated a graduate project to see if tablet computers would be a suitable platform for an electronic flight bag for the fighter pilots operating their fighter jet JAS 39 Gripen.

1.1 PurposeThe purpose of this master thesis is to build a software prototype which replaces significant functionality of the paper-based flight bag. The significant functionality (which is detailed in section 3.3) includes not only information but also usability of the flight bag. To construct such a prototype the thesis will use theories based on interaction and interface design, cognitive work analysis and usability. The software prototypes will be continually evaluated during the development process using usability testing to

3

investigate whether a significant functionality can be said to have been replaced by the prototype being tested.

1.2 DelimitationsThe graduate work for Saab Aeronautics, which is the foundation of this thesis, is focused on developing a working prototype. Matters not explicitly pertaining to the development and prototyping processes are not included in the scope of this master thesis. Included by the authors into the development process are the existing preconditions and more specifically how they are identified. Thus, the scope of this thesis is on the processes of developing the prototype using interaction and interface design, usability theory and testing the implemented prototypes with usability testing (these theories will be presented in chapter 4). Other aspects, which one might think would be included in this thesis, such as information security (encryption and transfer), pilot safety during ejection, certification of the prototype and other hardware considerations are not a part of the focus of the thesis.

4

1.3 DispositionThe following chapter (2) gives a complementary background which will make the rest of the thesis subject matter easier to understand.

Pre-study: Cognitive Work Analysis (3) presents both the theory, method and results from the CWA. The CWA was conducted to get knowledge and requirements about the complex sociotechnical system that the flight bag and actors act in.

Application Development (4) presents both the methods used for designing and testing and also covers the theories used through out the development process. All of this is later tied together in The Development Process (5).

Application Development Results (6) is the empirical findings of the development process. Embedded within this chapter is a continuously analytics section, which ends each subsection.

The chapters following (7,8) present a (7)discussion where the authors discuss the insights from the thesis, followed by (8) suggestions which require further research. Sources for the thesis are detailed in the sources (9) chapter. Finally, the appendix (10) holds material which would be out of place in the earlier chapters of the thesis.

1.4 The General MethodInitially a general understanding was needed about application development, which entails design and usability aspects, as well as about the flight bag. A literary study was performed by reading a plethora, in books and on the internet, about design, usability, interaction design, software testing, development methods, interaction, patterns etc. To gain an understanding about the flight bag a cognitive work analysis (see chapter 3) was used. Based upon the results of the cognitive work analysis the development could proceed using paper prototyping (subsection 4.2.1), followed by interactive prototyping (4.2.2) and then finally by iterative software development, interspersed with usability

5

testing (4.3). More detailed accounts of the graduate works process will come in the following chapters. What is important to keep in mind is simply the following. (i) A literary study was performed in conjunction with a cognitive work analysis to decide which methods would be used based on their results. (ii) User Centered application development, based on the results of the cognitive work analysis and the design and development theories were employed to create an electronic flightbag on a tablet computer.

6

2 Background“If the world were perfect, it wouldn't be.”

- Yogi BerraThe background aims to give the reader a proper understanding of relevant information relating to the subject matter of the thesis.

2.1 The Military Flight Bag"...it is a physical device that carries printed documentation pilots must have available to them during the course of the flight, such as flight manuals, operation manuals, and

approach plates."- Major Fredric S. Fitzsimmons

Major Fredric S. Fitzsimmons wrote a report for the US Department of Defense about the possibilities of an electronic flight bag (Fitzsimmons, 2002). His definition of a regular flight bag is precisely how the authors of this thesis would define a flight bag. This can be a fairly large amount of paper depending on aircraft - from library like installations on large civilian airliners down to different pocket configurations for a fighter pilot. The fighter pilot has a pocket, or folder like installation on each thigh for the flight bag. The problem with paper is not just a weight and space issue, there is the added burden of maintaining the documentation and of keeping it up to date. It is the fighter pilots responsibility to ensure that the flight bag is updated and correct before take off. There are however still some advantages of paper such as the ability to modify it in any preferred way, and that paper, is quite robust and can endure various environments.

2.2 The Electronic Flight BagMost of the flight bag papers are initially produced on a computer and much of the cost lies in printing them to paper; in some cases the information also exists digitally inside the fighter jets cockpit where the flight bags information is used as a backup. It would not only be cost effective to leave the documents in a digital format, it would also, as stated above, save space and weight. FedEx Express were one of the pioneers of electronic flight bags (EFB) when they started using on board laptops in the early 1990s (Wikipedia 2, 2011). Laptop size and price has been steadily decreasing while the technology (processing power, memory capacity etc.) has become more powerful. In civilian aviation there exists fully dedicated electronic flight bags which are essentially heavily modified computers with integrated screens (see fig. 2.1). The evolution of mobile computers and technology has entered a new phase; a sort of mix between a laptop and a mobile phone has been introduced - the tablet personal computer, or simply the "tablet". The tablet might be a suitable electronic flight bag competitor to the existing electronic flight bags as they share many basic pieces of functionality (Paur, 2011). In fact, some civilian aircraft pilots have already started using the Apple iPad tablet computer as a makeshift EFB. Thus, there are two types of EFB solutions on the market - the new competitor tablet variant and the current “pure” EFB.

Fig 2.2: EFB

7

A tablet computer software is very customizable much due to the “app” structure most tablet computers employ. Because tablets support many different developers they have a solidly implemented development environment. Also many tablet computers have built in gyroscopes and accelerometers, as well as GPS. All of these functions would be useful in the pre-flight and in-flight environment. The hardware and software for tablet computers is still in its infancy and it is not clear at the moment if tablets will replace all paper in the cockpit, especially with regard to military implementations such as in the Gripen fighter jet. Another question is if aviation regulations will hinder the inclusion of extra electronic devices inside the cockpit? Today, the American Federal Aviation Administration (FAA) has three hardware classes and three software classes, which are widely used, which electronic flight bags are split into. The following is a “clean” version of the FAA EFB specifications, which is meant to be easier to read without a bunch of technical jargon (FAA, 2011). EFB Hardware Classes:

1. Portable Commercial Off The Shelf (COTS) devices that are not mounted or attached to the aircraft. Class 1 EFBs that have Type B (see below) applications for aeronautical charts, approach charts, or electronic checklists must be secured and viewable during critical phases of flight and must not interfere with flight control movement. An EFB attached to the pilot's leg may still be considered a Class 1 EFB Because it is not attached to the aircraft.

2. These EFBs are typically attached to the aircraft by a mounting device and may be connected to a data source, a hard-wired power source and an installed antenna, provided those connections are installed in accordance with applicable airworthiness regulations. No tools must be required to remove an EFB from the flight deck. Portable EFBs must be located on the flight deck and be controlled by the flightcrew during all flight operations. The components of the class 2 EFB include all the hardware and software needed to support the EFBs intended functions. A Class 2 EFB may consist of modular components (e.g., CPU, display, controls).

3. EFBs installed in accordance with applicable airworthiness regulations.

NOTE: Class 1 or Class 2 EFBs must not display own-ship position while in flight.EFB-Software Classes:

● Type A applications include precomposed, fixed presentations of data currently presented in paper format. Type A applications can be used on the ground or during noncritical phases of flight. Malfunction of a Type A application is limited to a hazard level defined as no greater than a minor failure condition classification for all flight phases and have no adverse effect on the safety of a flight operation.

● Type B applications include dynamic, interactive applications that can manipulate data and presentation. Malfunction of a Type B application is limited to a hazard level defined as no greater than a minor failure condition classification for all flight phases and have no adverse effect on the completion of a flight operation.

● Type C EFB Software Applications are FAA-approved using specified compliances and approval guidelines. If Type C applications are used for weight

8

and balance (W&B) and/or performance they must be approved by aircraft certification service (AIR) for a specific aircraft as part of the aircraft flight manual (AFM) or aircraft flight manual supplement (AFMS).

2.3 Saab Aeronautics and the JAS 39 GripenCurrently the Gripen fighter pilots, like many other fighter pilots, use the analog flight bag which is attached to their thighs. The pockets psychical attributes vary from pilot to pilot, depending on preferences, age of the suit and flight bag as well as the tasks the fighter pilot is performing. Some have pockets on both thighs, others just one, some like to browse the information like a book, others prefer a flip chart like installation. In flight it is necessary to access the right information at the right time, and to take notes. It is also crucial that no object from the analog flight bag detach and get stuck somewhere in the cockpit as this leads to high maintenance costs and makes the fighter jet non- operational during maintenance. There is a high level of customization available of the fighter pilots flight bags, and more likely than not there are no two flight bags which are exactly the same. Saab Aeronautics are interested to see if a tablet computer can function as an electronic flight bag replacing the analog flight bag. Requirements when choosing platform were the physical size of the device and how fragmentation friendly the operating system was. The size requirement is crucial since the space in the Gripen cockpit is very limited and thus the tablet can not exceed the size of the analog flight bag. If the tablet is too large it will conceal fixed instrumentation and possibly be in the way of performing certain maneuvers when operating the aircraft. The location on the pilots thigh is motivated by the fact that there is not any other suitable space left in the cockpit. A solution for a Gripen fighter pilot may well work, with only slight modifications, for other fighter pilots in jets and helicopters. With certain modification, one could also theorize applications for the concept of technicians working on different aircraft.The operating system needed to have a development environment available and be future proof, in the sense that it would not likely be discontinued out in the coming years. Also the operating system should be fragmentation friendly, which means that it can be ported to different hardware configurations. Also the operating system would need to be stable as development and testing for fighter jets takes a fair amount of time. Being hardware adaptive and future proof meant that developed software would work with newer hardware with minor changes to the software. Another aspect when initializing this project was that Saab Aeronautics wanted to have a concept for fast demonstration purposes. In their opinion graduate students would bring in new fresh ideas and solutions, while building a workable concept. (Fransson, 2011)

2.4 Android on the Samsung Galaxy TabThe 7’’ Galaxy Tab tablet computer by Samsung was the chosen hardware platform to be used for developing and showcasing the prototype during its development. This because at the time for this master thesis the Galaxy Tab was the only platform that fulfilled the criterions regarding hardware dimensions and performance. The Samsung Galaxy Tab runs Googles Android operating system version 2.2 called “Froyo”. Google has released an updated Android version 3.0 “Honeycomb”, which is designed from the ground up to enhance user experience for devices with larger screen size (Android

9

Developer Documentation, 2011). Honeycomb however, is not supported on the Galaxy Tab and it is very doubtful that it ever will be as attempts at updating it to version 2.3.3 called “Gingerbread” are tantamount in difficulty to climbing Mt. Everest.

2.5 Moving onUp to this point, information about civilian and military flight bags has been introduced and especially how flight bags being used in the Gripen fighter jet. Also, information about Googles Android operating system and the Samsung Galaxy Tab tablet computer provided. The following will provide the framework of the thesis, which is the reasoning for it being structured the way it is. Hopefully this will help the reader understand the process employed for the graduate work, since that is the basis for the thesis layout.This thesis can be split into two parts, where the first part consist of a Cognitive Work Analysis (Vicente, 1999) and the second part covers aspects of application development. The CWA was carried out to supply a basic understanding of the flight bag currently in use by fighter pilots. Some of this information can be found in the previous sections under Saab Aeronautics and the JAS 39 Gripen (2.3). The remainder of the application development process could then be based on the CWA’s results. Thus the next chapter of the thesis includes both the theories behind CWA and the methodology as to how it was carried out, as well as the results it garnered. The analysis and discussion of the CWA are however a part of the main thesis, since it will be analysed and discussed as a part of the thesis as a whole. The CWA is performed to identify what functionality needs to be replaced for the software prototyping phase, as this is the purpose of the thesis.

Once the CWA had garnered a sufficient amount of information the development phase began. The development phase was focused on designing and testing the application. The Application Development circle drawn above is filled with theories about user centered design, interface design, usability and various evaluatory theories for performing usability tests. These theories form the main framework for the application development phase which was the main part of the graduate work. For comparison the CWA lasted a month while the application development phase lasted for four months. The method used during the application development was user centered design (see section 4.1). The application development process was essentially composed of two stages (a more detailed account of the development processes use of various theories and methods can be found in chapter 5, this part is meant to give the reader an

Fig 2.5: From CWA to Application Development

10

understanding of the work process for application development). First (i) was an implementation stage where different mock-ups (see section 4.2) or code implementations based on different design theories (see sections 4.4-6) were proposed as solutions to different functions and prequisites outlined initially in the CWA. In the second stage (ii) the proposed solutions were evaluated with tests (see section 4.3) and discussions. Results from the second stage were the foundation upon which the next implementation was based and so it went on until time constraints forced the development to stop.The reader now, hopefully, understands why the thesis will be structured the way it is and understands the method of the graduate work. It may be worth returning to this chapter after reading the theoretical chapters (chapter 4), if something is unclear. The next chapter will deal with the Cognitive Work Analysis (CWA) that was conducted at the beginning of the graduate work, to gain an understanding of the general situation. Due to the way the graduate work was dispositioned, with a CWA to understand the problem and then the application development to solve it, the thesis will have a similar disposition with the next chapter detailing the first CWA phase. It should be mentioned that some of the results from the CWA have been previously mentioned to provide essential information about how flight bags are being used today in the Gripen fighter jet.

11

3 Pre Study: Cognitive Work Analysis“You can observe a lot just by watching.”

- Yogi BerraThis is the first phase of the thesis, explaining the nature of CWA, how it was used and

the results it provided.

3.1 Theoretical Framework: Cognitive Work Analysis (CWA)CWA is a multi-stage framework for work analysis. It is based on the concept of behaviour-shaping constraints which are intrinsic constraints on the way work is done by an operator or an automation. At the beginning, the system is completely free, but as more and more constraints are placed upon it the degrees of freedom of the system decrease. The culmination of this process is a foundation upon which development of a new and/or improved system can be built. (Lintern, 2007 & Vicente, 1999) A person within the system being studied is not a “user” of the system but is an “actor” together with the non-living parts of the system. Thus both living and non-living parts of the system are analyzed to give a complete picture of the system which is then used as a basis for the continued system development methodology and system design decisions. (Fidel & Pejtersen, 2005)Figure 3.1 presents the general structure of a CWA. It is supposed to be formative, in that it gives form to the system design, and is therefore defined as a formative approach to work analysis. What the different layers represent is presented below the figure.

● The work domain represents the system which is being controlled. A work domain analysis shows the capabilities (by outlining the constraints) of the system, independent of actor (operator) and activities.

Fig 3.1: Formative Approach to Work Analysis

12

● Control tasks are the goals which need to be achieved. In more correct terminology the focus is on identifying what needs to be done independent of the strategy (how) or the actor. In this case, a control task could be to land a plane or access an emergency checklist.

● Strategies are how control tasks are achieved. Strategies are carried out independently of the actor and describe the exact way the goals of the control tasks are to be fulfilled, sometimes in several different ways. An example of a strategy is how to make a note of something (for example: Grab pen → Use pen on paper).

● Social organization and cooperation details the relationships between the actors. It describes how different work domains, control tasks and strategies are allocated between actors.

● The workers competencies are constraints which are imposed due to the human actors. What competencies do human actors need to fulfill their job? In this case, what knowledge, skills and rules does a fighter pilot need to fly Gripen effectively?

(Vicente, 1999)

3.1.1 Evolutionary Design“The full value of CWA is obtained by letting the characteristics of the problem, represented by the five layers of behaviour-shaping constraints, inform the design of the sociotechnical system”. (Vicente, 1999)The design for the electronic flight bag is not a revolutionary (completely new) design, it is an evolutionary (it has its basis in an existing product of whose functions it must replace) design. The new design inherits many of the constraints of the old design, which means that the work domain and control tasks of the prototype must identify and base the new design on existing design decisions. The implication of this is that the CWA of the analog flight bag will need to use a slightly modified version of CWA, where some design decisions are already made from the outset of the CWA in regard to the work domain analysis. (Ibid.)

3.2 Method: Generic CWAWith a basis in the different stages of CWA outlined by Vicente (1999) (found in figure 3.1.1) a list of questions were compiled. The questions were designed to find the behaviour-shaping constraints of the system and were based on the questions formulated by Fidel and Pejtersen (2005) for CWA. The approach is a more generic CWA where the general ideas of Vicente are followed but with less formalised tools (Lintern, 2007). The questions can be found in the appendix, while the results from the generic CWA are found in section 3.3.

3.2.1 Method: MotivationThe motivation behind using the cognitive work analysis (CWA) was that its strength lies in describing complex sociotechnical systems. A fighter jet with pilot is definitely one such system. The CWA and a literary study defined which theories and practices would be best suited for the systems development of the prototype application. A literary study was performed by reading theoretical books, articles and well sourced

13

web pages which were either recommended to the authors, used previously by the authors or found via media sources (literature in use, the internet etc.). The content was then evaluated as it was read by the professional opinion of the authors in regard to the findings of the CWA.

3.3 CWA ResultsIn this section the results from the CWA methodology, which was used in a generic fashion is presented. The generic CWA was composed of questions corresponding to the different stages of the CWA, and can be found in the appendix.

3.3.1 Work domain: Which possibilities exist within the constraintsThe actual work domain is the pilot, the flight bag, the JAS 39 Gripen fighter jet as well as anyone the pilot can communicate with while airborne and while planning the mission on the ground. However, for all intents and purposes the work domain is delimited to the flight bag, the pilot and the fighter jet with only minor considerations being paid to the design of the prototype application to the rest of the domain. The goals of the work domain are that the flight bag actor provides relevant information to the pilot actor, especially whilst they are flying the fighter jet actor. The work domain information is controlled as a complex sociotechnical system in that many different actors control the information used in the flight bag. There are many actors involved in providing and regulating the content of the flight bag. The fact that many sources control the information of the flight bag is influenced by the absolute prerequisite that certain information be contained in the flight bag such as emergency checklists and plates. Included in the work domain is also a pen for performing notes and editing existing information. Everything needs to be accessible and extremely fast. This is due to the fighter jet actor, as wasting time in a jet plane during certain circumstances is not a very good idea to say the least!Quick recap:

1. The flight bag is a part of a complex sociotechnical system.2. The sociotechnical systems essential actors (from our design perspective) are the

flight bag the fighter pilot and the fighter jet.3. The goal of the work domain is to provide relevant information from the flight

bag to the actor.

3.3.2 Control Task Analysis: Goals which need to be achievedJAS 39 Gripen, its pilot and the flight bag need to be able to achieve the following major goals.

● Perform landings and take offs.● Respond to emergencies via diagnosis and then take action.● Take notes in flight.● Communicate with external actors.● Know what the mission is and which other actors are involved in it.

14

3.3.3 Strategies: For achieving the control task goalsAll of the strategies must adhere to the work domain constraints. When landing, the pilot might get crucial information from a control tower that needs to be remembered, this information is then written down. Some information about procedures can be found in charts and plates. How to land and take off with the jet plane is simply to find the correct maps and instructions on paper in the flight bag. To talk to external actors, the pilots usually receive information from air traffic control of what the next radio frequency is, but should that fail the flight bag includes a table of frequencies. To be able to respond to emergencies the emergency checklist must be found in the flight bag. Basically the strategy is simply to use the flight bag as a book and find the correct page or note down something quickly on an empty sheet of paper.

3.3.4 Social organization and cooperationEverything follow a hierarchical order, where the pilot performs his mission which is initiated and planned by a higher organization. The flight bags are however strictly personal as well as being highly personalized by the pilots themselves in their functionality and informational content. Other social organizational aspects are the classification of the hardware as well as the software, what level of classification should be appropriate according to the FAA regulations?

3.3.5 Worker competencies - Actors/PilotsAll fighter pilots have gone through pilot training so that they can operate the aircraft. Changing the information content or design of a document used in flight was not feasible, since there exist many standards in how for example navigational information is portrayed to the pilots. Thus keeping the standard formatting and simply making the documents more accessible was deemed a more realistic and better alternative. Also, the design can have a more efficient design since the users can be expected to practice with the finished application a lot before actually flying with it.

3.3.6 The result from CWA and how it affected the development processThe CWA outlined the basic functionality the analog flight bag performs, where the two major functions are to display information and to act as an external memory when written on with a pen. Replacing this basic functionality is a must for an EFB to be able to replace the flight bag. Thus showing information in the form of flight plates, communication cards (which include mission data), a frequency table as well as being able to take notes were decided to be the prototypes main functions. And almost as important is to have good navigation of the flight bags information so that it is easy for the fighter pilots to find the correct information as fast as possible. Already the degrees of freedom of the prototype were becoming quite constrained by using this approach which was a very good result.

● Display information● Make Annotations

15

3.4 Moving OnThe CWA paired with the two previous chapter supplied the foundation to understand the rest of the thesis. The CWA gave information about how the flight bag is being used today and what functionality it provides. This helps when deciding which functionality to replace when building software prototypes. To know what functionality to replace is essential, since to know this, and to implement it is closely connected to the purpose of the thesis. The following chapter will be a detailed excursion into the methods employed for designing and evaluating the interface.

16

4 Application Development“You gotta be careful if you don't know where you're going, otherwise you might not get

there”- Yogi Berra

This is the beginning of the second, larger part of the thesis, explaining application development.

The results of the CWA were used for the continued development of a coherent, functional design. Sections 4.1-3 presents application development methods and theories for a good development process. Sections 4.4-6 highlights the theories which are used by the methods in sections 4.1-3. The graduate work used a mixed approach which included part of interaction and interface design as well as usability. Most of the theories in sections 4.4-6 are guidelines to application development, in that none of them present specific design rules such as “font B should be colour C if A is true..”.

4.1 User Centered DesignIn the mid eighties Norman and Draper released a book called “User Centered System Design” which presented a whole new outlook in the field of Human-Computer Interaction. One of the essential parts was the use of a mental model by users. A mental model is unique for each person and guides much of human behavior. The model is the users interpretation of how a system works or how problems are built up. The model helps the user to explain certain phenomena, “...these models are highly affected by the nature of the interaction, coupled with the persons prior knowledge and understanding. The models are neither complete nor accurate”. (Norman, 1986)

Example: The designer designs a radiator based on how she feels it should work. The Documentation and System image are the portrayals of how the actual System works. If they are not accurate representations of the System (or if the User misunderstands something) then the Users’ model (how the user believes the System works) will be wrong. What proceeds to happen is that the User uses the System wrong. For example the radiator may increase its temperature in an exponential fashion, so that maxing out the temperature means it will warm to the medium temperature faster than if the user would simply set the temperature to medium from the start. The user believes that the

Fig 4.1: Mental models

17

temperature increase is linear and so wastes time in trying to get to the desired temperature because the documentation or system image has effectively tricked the user.Norman states that there are three different aspects to be considered when trying to understand mental models. The first one is the conceptualization of the system held by the designer - called the design model. Second there is the conceptual model constructed by the user - called the user’s model, and the third is the physical structure from which the users develop their conceptual models, this also includes documentation and instructions - called the system image. The design model is ideally based on the user’s task, requirements and capabilities. But the conceptualization must also consider the user’s background, experience, and psychological aspects such as short-term memory limits and other related attributes. The user’s model is the mental model of the system produced by the user, this model stems from the system image and is the user’s interpretation of the system. Everything that the user interacts with regarding the system forms the user’s view of the system image. In a perfect world the design model and the user’s model form the same system image; however, this is seldom the case and it is up to the designer to make the system image explicit, intelligible and consistent for the user. (Ibid.) Usually the designer does not communicate directly with the users; all communication is handled by the system image, and if the system image is not clear the user will end up with the wrong mental model. (Benyon et al., 2005) The idea of mental models can help designers to understand that users are different and interact with technology in various ways and have different mental models for how systems work. Together with users, the designer of a system can understand how users acts when dealing with a certain system. (Norman, 1986) A user centered system is based on the idea of providing intelligent, understandable tools that bridge the gap between people and systems. Today, this is a mature discipline with various methods and tools which are used to accomplish a user centered system approach when designing a system. This thesis used a user centered system approach called the Petterstedt roundabout.

18

4.1.1 The Petterstedt Roundabout

The idea of the roundabout is that the designer and the user work together during a process. First, the process is opened up and various inspirational sources may flourish to get possible solutions; the ideas are then narrowed down and tested on the user. Afterwards, the results from the test are analyzed and investigated. The outer boxes signifies the designers inspirational and knowledge sources during a project. Inspiration is during the process translated into different kinds of knowledge and to backup the process there are different tools available to help out the designer to support the process. After one cycle in the roundabout the process starts all over again, which means that the knowledge in the previous cycle gives new inspiration, founded on the gained knowledge from the previous cycle. These cycles continue until the project is done or runs out of time. More cycles in the roundabout will lead to increased maturity over time and reduces the risk for producing the wrong kind of product. Each cycle opens up and closes the design space, but as time progresses the cycles will steadily decrease the design space as the product matures, as displayed in figure 4.1.1 B below. (Petterstedt, 2011)

Fig 4.1.1 A: The Petterstedt roundabout

19

4.2 Pre Evaluation Prototyping“A prototype is a concrete but partial representation or implementation of a system

design.”(Benyon et al., 2005)

This subsection details the theories behind the prototyping, which takes place before usability testing of the software prototype(s) is possible. This includes parallel throwaway prototyping and interactive prototyping. Originally, prototypes were used to allow end users to evaluate developer design proposals instead of having features explained to them by the developers. This meant that the end users could see and evaluate prototypes with limited or no functionality, providing the developers with valuable feedback. (Smith, 1999)

Fig 4.1.1 B: Another view of the Petterstedt roundabout process. The x-axis is time while the y-axis is used to measure both risk and maturity.

20

4.2.1 Parallel Throwaway Prototyping

Fig 4.2.1 A: Parallel Throwaway Prototyping

The method used during the initial prototyping process was parallel throwaway prototyping. Parallel prototyping (as opposed to serial prototyping) evaluates several different prototypes individually without comparing them to each other. Then, using the insights and ideas from the previous round of prototypes, a new set of prototypes are made and evaluated. The previous prototypes are “thrown away” in that they are not used in the continuing prototyping process. For each iteration the amount of prototypes decrease and (hopefully) a better prototype is created. (Dow, 2010) The foundation for parallel prototyping is that comparison aids learning (Gentner et al., 2003). The iteration facilitates discovery of unknown constraints and opportunities and helps to avoid a fixation to a specific design by supporting comparison and thus learning (Dow, 2010).

4.2.2 Interactive prototypingTo make the prototypes more interactive and to test ideas that are hard to implement on paper, Keynote was used. Keynote is a “powerpoint-esque” presentation software from Apple with the ability to hyperlink pages together, giving an added depth of information structure and navigational design.

4.3 Evaluating Design Theory Evaluating design theory details the evaluatory theories used during the prototyping process. The theories explained in this section aim to intersect with the questions in the next chapter, ventilating Nielsens definition of usability (Section 4.6).

Fig 4.2.1 B: Throwaway prototyping

21

4.3.1 Usability TestingSince resources (time and development personnel) were scarce, it was decided that Steve Krugs “Lost-our-lease testing” would be employed. (Krug, 2007)

What Lost-our-lease Testing SuggestionNumber of users per test Three or four

Where to test Any office or conference roomWho does the testing Any reasonably patient human being

Advance planning Tests can be done almost any time, with little advance scheduling

Preparation Decide what you are going to show

What/when to test Run small tests continually throughout the development process

What happens afterwards The development team debrief the same day(Ibid.)

One formal usability test with one user (fighter pilot) was carried out every month. Yet, between writing this report and coding the input was more than sufficient, and many functions and changes were not even possible to address in time for the next test. A formalized usability test script was used, which can be found in the appendix. Krug suggests that almost anybody can be used as a subject for usability testing. However, there is one exception “If your site is going to be used almost exclusively by one type of user and it’s no harder to recruit from that group, then do it” (Ibid). Since finding fighter pilot users was not hard, all think aloud testing was performed with fighter pilots. (Ibid.)

4.3.2 Cognitive WalkthroughThe purpose of a CWA is to determine how easy a system is to learn. This is done by evaluating the actions which must be performed by the user onto the interface to achieve a certain task. To perform a walkthrough, four things must be available.

1. A description of the prototype of the system (for example a paper prototype).2. A description of the task the user is to perform on the system. Typically

representative tasks that most user will want to do.3. A complete written list of the actions needed to complete the task with the given

prototype.4. An indication of who the users are and what kind of experience, knowledge and

skills the users possess.Together, the evaluators step through the written list of actions needed (nr. 3 above) to complete the task. For each item the evaluators try to answer the following questions.

1. Will the users be trying to produce whatever effect the action has? Are the assumptions about what task the action is supporting correct given the user’s experience and knowledge up to this point in the interaction?

2. Will users be able to notice that the correct action is available? Will users see the action? Is it visible when they need it?

22

3. Once users find the correct action at the interface, will they know that it is the right one for the effect they are trying to produce? It is one thing if the button is visible or not, but will the user know that it is the right one to complete a task?

4. After the action is taken, will users understand the feedback they get? Assuming the users did the correct action, will they know that? This can be seen as the end of the action cycle.

Cognitive walkthrough has the best effect when it is used early in a design process, to find flaws in the design which might lead the progression of the design in an undesirable direction. (Dix et al., 1998)

4.3.3 Usability Testing: Think Aloud TestingThink aloud testing is a a relative simple procedure which aims to show how an interface is being used. It might also provide information about flaws regarding the interface and its’ design. The idea is that the user should consistently elaborate their actions by “thinking aloud” - describing what they believe is happening, why they take an action, what they are trying to do. It is important however that the conductor does not influence the subject in any way during the test. (Dix et al., 1998)

4.3.4 Usability Testing: Cooperative EvaluationA variant of think aloud testing is cooperative evaluation. Here the user is encouraged to see himself as a collaborator in the evaluation and not as an experimental subject. As well as asking the user to think aloud, the evaluator can ask questions, typically of the “why?” or “what-if?” type, if the user’s behaviour is unclear. The user may also ask the evaluator for clarification if a problem arises. The benefit of such an approach is that the process is less constrained and therefore easier to learn to use by the evaluator. Users are encouraged to criticize the system and the evaluator can clarify points of confusion at the time they occur and so maximize the effectiveness of the approach for identifying problem areas. Cooperative evaluation can be performed using different protocol methods such as:

● Paper and pencil● Audio recording● Video recording● Computer logging

(Dix et al., 1998)

4.3.4 Usability Testing: Testing SoftwareToday there are software available that has the ability to capture and record the screen of a computer and simultaneously the movements of the cursor as well as audio. This kind of recordings are powerful tools, giving the conductor of the tests the ability to come back to the recordings and examine different features afterwards. (Dix et al., 1998

23

& Krug, 2007) The file output from such screen recordings are much easier to review quickly than a videotape or DVD and they are easy to share over a network. Krug therefore recommends that a screen recorder should always be used during a user test. (Krug, 2007)

4.4 InteractionInteraction is used in the field of Human-Computer Interaction (HCI) to describe the interaction between a system and a user. Systems and users are different from each other in how they function and communicate and thus arises the need for an interface to translate between them. How the interface is supposed to look and function is however different from case to case and the use of different interaction models can help to illustrate the different parts of an interaction, making it easier to analyze. (Dix et al., 1998)

4.5 Interaction FrameworkThe interaction framework is presented to illustrate the basic interaction via an interface. A more complete framework for the actual actions and intents involved in this interaction is presented in subsection 4.6.1. The interaction framework consists of four components:

Together, Input and Output form the entire interface. As the interface sits between the User and the System. A User interacts with the interface by causing Input. The System interprets the Input and causes Output which is interpreted by the User. (Dix et al., 1998)

4.6 Usability & Interface DesignSince the interface is the link between the user and the system, it is essential that the interface ease the communication. This can be done with a well designed interface. Interface design it self focuses on the interaction and user experience and the objective is to make the interaction as simple and clear as possible. (Benyon et al., 2005) The International Standardization Organization ISO defines usability as "The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use." (ISO, 1998)

Fig 4.5: The interaction framework

24

This definition is quite similar to the usability expert Jakob Nielsens five components which comprise his definition of usability.

● Learnability: Users should be able to start use the system the first time they encounter the design. The system should be easy to understand.

● Efficiency: When the user has learned how to use the system, the user should be able to perform tasks efficiently.

● Memorability: Users who use the system from time to time should be able to remember how the system works when they use it again.

● Errors: The system should prevent users from making errors and help users recover from them.

● Satisfaction: The system should be pleasant to use.(Nielsen, 2003)

Also according to Nielsen, the usefulness of a system is the issue of whether the system can be used to achieve some desired goal. It can be divided down into two categories: utility and usability, where utility describes whether the functionality of the system can do what is needed, and usability focus on how well users can use that functionality. (Ibid.)

4.6.1 The Seven Stages of ActionWhen interacting with a system the user goes through a cycle of actions. This cycle is called the action cycle by Norman. (1988) An apt analogy of the process is the actions required by a user when performing the activity of toasting a piece of bread. The first step is for the user is to decide that she wants a piece of bread thoroughly toasted. She then decides to use a toaster to achieve her goal. Thirdly, she formulates a strategy for using the toaster, put the toast in and turn the knob for example. Now, the user actually performs the actions of the strategy, followed by checking the system for feedback on the status of her toast. Is it getting hot in there? Has the bread become toasted? The user then finally evaluates the system state based on the original goal, which was to toast a piece of bread. These different activities as part of the interaction between the user and the system are all stages in Norman’s model of interaction. (Ibid. & Dix et al., 1998) Formally they are as follows

● Establishing the goal.● Forming the intention.● Specifying the action sequence.● Executing the action.● Perceiving the system state.● Interpreting the system state.● Evaluating the system state with respect to the goals of intentions.

(Norman, 1988)These goals may not be as precise as the toast example, which likely leads to the rest of the activity stages being based on an imprecise intention. Basically, the user may not be sure of how to achieve the goal and thus may need to iterate and form several intentions

25

after evaluating the system state, should the system state not correspond with the users goals. (Dix et al., 1998)“Activity in reality does not progress as a simple set of stages. Stages might appear out

of order, some be skipped, some repeated.”

- (Norman, 1986)

4.6.2 Principles of Good DesignThe aim of a well designed interface is to minimize the effort to execute and evaluate a systems state. Too accomplish this a good design should help the user build the correct conceptual model of the system. The conceptual model depends upon what parts the system makes visible to the user and that the links between the visible parts of the system and the actions that they support are clear. The design should also exploit memory through explanation and supply the user via good memory aids with a good mental model. It is also important that the design considers feedback and accommodate errors. (Norman, 1988). To design an interactive system from a human-centered perspective, Benyon et al. have outlined the following guidelines:Help the users to access, learn and remember the system

1. Visibility - Ensure that things are visible, this will help the user to see what functions are available and in which state the system currently operates in.

2. Consistency - Be consistent in your design.3. Familiarity - Use language and symbols that the intended users will be familiar

with.4. Affordance - Design things so it is clear what they are for.

Convey a sense of control to the users5. Navigation - Provide support to enable users to move around the system.6. Control - Make it clear who or what is currently in control. Allow users to take

control.7. Feedback - The system should provide the user with information about what

effect their actions have had.Make the users feel safe and secure in the system

8. Recovery - Enable recovery from actions, particularly mistakes and errors. This should be done in an effective way.

9. Constraints - Provide constraints, so that user don’t do things that are inappropriate. Users should be prevented from making errors.

Allow the users to feel at home in the system10. Flexibility - Allow multiple ways of doing things so as to accommodate users

with different levels of experience and interest in the systems. Provide people with the opportunity to change the way things look or behave so that they can personalize the system.

11. Style - Designs should be appealing.12. Conviviality - Interactive systems should be polite, friendly, and generally

pleasant.

26

(Benyon et al., 2005)

4.7 Moving OnChapter four went through the theoretical methods and the application design theories employed during the development process. In the next chapter the actual method of development will be shown and tied to the theoretical methods and design theories presented in chapter four.

27

5 The Development Process“Litte things are big”

- Yogi BerraThis chapter explains the methodology of the development process by connecting it to the theories (chapter 4) and methods used in the thesis. This means that the Development Process is the theoretical framework of the thesis AND the method employed for the actual development process. This is due to the fact that the process of designing and implementing the prototype constitutes the application development, which is the subject matter of the thesis. First, a short overview of the overarching development process is presented followed by sections which go deeper into the specifics of the different stages of development. Afterwards, a motivation for the chosen theories is provided for transparency as well as a short discussion about the credibility of the thesis.

5.1 The Process Explained

The Petterstedt roundabout (see chapter 4) formed the basis for the method employed by the authors for the application development. Figure 5.1 is the exact representation of the development process and is drawn by the authors of this thesis. Each phase (see subsection 4.1.1) of the development is represented as a square rotated by 45 degrees. Each square is a cycle of the application development where the design space first becomes wider when all manner of design solutions are proposed, some of them completely disregarding theories of application development (see sections 4.4-6). The design space then narrows by evaluation of design viability with help from the application design theories and testing. As the work progressed the absolute amount of design space decreased over time. The actual development process started, with paper prototyping, after an initial cognitive work analysis (see chapter 3) was used to describe the problem.

5.2 Cycle 1: Paper and Keynote PrototypingDesign criteria were based on the principles of good design and usability (see section 4.6). For inspiration the android UI guidelines and design patterns from Jennifer Tidwells book Designing Interfaces were used (2010). A lot of time was spent on prototyping features with regard to different specific design, such as affordance and

Fig 5.1: The process evolved from the Petterstedt roundabout

28

feedback from the principles of good design and learnability from usability theory. The principles of good design and Nielsens definition of usability have many overlapping features, and so they were used in conjunction with one another. The Android UI guidelines, an Android systems limitations and Tidwells design patterns gave a good foundation for the initial designs by narrowing the pool of possible design solutions. (Android UI Guidelines, 2011 & Tidwell, 2010)The first cycle was conducted after the CWA, this phase of the development consisted of paper and keynote prototyping (see fig. 5.1). Paper prototyping meant making several throwaway mock-ups in accordance with parallel prototyping theory (see section 4.2). The design space grew as more and more mock-ups were created, until end users and others were asked their opinion, at which point several non-feasible designs were thrown out. This meant that many mock-ups were made and then evaluated on their own merits, independently of each other. Those prototypes which were feasible and in accordance with the principles of good design (see subsection 4.6.2) and with the somewhat overlapping definition of usability (see section 4.6) were kept in mind for the next volley of parallel mock-ups while the completely useless ones were thrown away, in the sense that they were archived as failures. By not literally throwing away the mock-ups, there was still a possibility of looking at them and remembering what was wrong about them, but also be able to look at them for inspiration or even to re-evaluate some design aspects which might work in a new design setting, despite their initial rejection.As the mock-up quality became more refined the seven stages of action (see subsection 4.6.1) became more useful as a design tool, as they could be tied to both CWA, usability and interface design questions. The different stages were not used explicitly, but more as a list to tacitly remember when connecting the different design theories to the CWA.The paper prototypes and the thought functionality were discussed and tested with human-computer interaction experts and several fighter pilots. The results from the tests and the theory based evaluations led to insights, some of which were implemented in the keynote prototyping phase.Keynote prototyping worked in much the same way as the paper prototyping except that it was done on a computer with clickable functionality. The parallell prototyping theories (see subsection 4.2.1) were discarded here due to time constraints.For a more detailed analysis of the theories use during the development process see the analysis sections in chapter 6.

5.3 Cycle 2: Initial Code ImplementationThe second square represents the initial code implementation and it opened the design space. During this phase, several possibilities and constraints within the android platform were discovered which showed a reasonable direction for the prototype development to take. All design decisions from the paper and keynote prototyping were implemented within the constraints of the android operating system. Thus the same design theories used in previous prototyping were simply translated to a software implementation and no new use were made of them, unless they needed to be altered in some way. If previous design decisions needed to be altered, a quick discussion and throwaway prototyping sessions was performed based on the design theories (see section 4.4-6). It should be noted (and is in fact noted in section 6.3 below) that during this phase there were two prototypes being built which only differed by one large

29

difference. This meant that most of the code could be copied and pasted between them, which means that development was generally performed on both prototypes by coding for one and then copying and pasting to the other.

5.4 Cycle 3 to n: The Evaluation Implementation Process This is the iterative part of the development process which commenced after each software development cycle. After performing a usability test (see section 4.3) a quick skirmish of throwaway mock-ups were created to solve problems which had been found. Design decisions were based on the same design theories (see sections 4.4-6) which were a part of the paper, keynote and software prototyping performed previously. However, sometimes certain parts of the design process after the evaluation were skipped if it was obvious what the problem was, since drawing a mock-up at that point would only be a waste of time. No new computer drawn sketches were made after the initial Keynote prototyping session.

5.6 Motivation of this ProcessSince there would inevitably be interaction between the fighter pilot and the application ,a framework for that interaction would be needed. Interaction design theory was therefore used to define that interface design theory would be needed to facilitate the interaction between the fighter pilot and the application, via the tablet. The interaction would need to be efficient, which in turn meant a well designed interface would need to be created following various design theories and practices. The fighter pilots had essentially all the important information about the old flight bags’ functions and content and were also the best choice for evaluating the prototypes. A user centered design seemed the most natural way of incorporating their knowledge into the consecutive prototypes and the more specific the Petterstedt roundabout was used as the actual user centered design method. The reason for the Petterstedt roundabout being used was that the authors view of the design space decreasing for each iteration followed the narrowing of the design space with the help of tools which the Petterstedt roundabout employed. To evaluate the prototypes usability testing was used as both an aid in the development of the application and as a way of continually getting quantifiable data on different designs so that they could be measured against each other. It was used because having an application which had high usability would imply it would be easy to learn and use efficiently as well as not be error prone.To summarise; the main motivation for the use of the methods and theories employed for the development process were due to external factors (user’s knowledge base, CWA results) and a goal of developing an application with a high degree of usability.

5.7 CredibilityThis subsection aims to give an objective view of the thesises credibility with respect to whom has written the thesis and the methods chosen to perform the graduate work which is the foundation of the thesis. The professional opinions of the authors in regard to software application development via prototyping is one of many. There is no “correct” way of performing software development, as the product and its use must be taken into account. The method employed in this graduate work is simply our way

30

5.8 Moving OnChapter five ends the series of chapters which detail how the graduate work was performed and more importantly why it was performed the way it was. Next is seeing the results of this development process interspersed with analyses by the authors of the different results and their connection to the theories employed.

31

6 Application Development Results“If you ask me a question I don't know, I'm not going to answer.”

- Yogi BerraThis chapter presents the results of the different prototyping phases which were carried out during the development process. The results from the testing and evaluation, which opened the design space after each consecutive iteration, are also included. Thus, the chapter follows the development process in a chronological fashion where it begins with the iterative process of parallel paper prototyping followed by Keynote prototyping and finally the code implementations interspersed with the testing and evaluation for each cycle. After each cycle of prototyping an analyses of the designs and results will be presented based on the design theories, mainly interface and usability design (see section 4.6) and the principles of good design (see subsection 4.6.2). A good deal of figures are presented throughout this chapter whose purpose, if not referenced explicitly, is to give a clear understanding of the different stages of application development.

6.1 Paper Prototyping

The paper prototyping began with drawing mockups on top of of the Samsung Galaxy Tab S. The picture of the tablet and its’ launch screen were modified using Inkscape (see appendix 10.1) so it had no content, which left room for drawing. Pages with two tablets on one page were used, which proved to be very useful. For example the result of an action on the left screen could be shown on the right hand screen or two versions of the same interface could be drawn next to each other. All of the pictures were drawn in portrait mode1 for the tablet, since that is how it would be viewed when attached to the fighter pilots thighs.

Fig 6.1 A: Paper prototyping phase

32

1As opposed to landscape mode.

6.1.1 Top/Bottom NavigationThe prototyping phase started off with trying to solve navigational issues. Three different solutions were made. Tabs were placed either at the top of the application or at the bottom. A sliding tab interface was also mocked up where the user would slide the finger on the screen or over the buttons to navigate.

Fig 6.1 B: Templates of the Samsung Galaxy Tab S

Fig 6.1.1 A: Top Navigation

33

The second solution was inspired by the perceived need for screen real estate (to be able to use as much of the screen as possible to perform certain functions). The idea was that buttons would take the user to different activities. Like the home screen in Android have various icons leading the user to the application connected to the icon. This solution, since it is not a tab solution, meant that the hardware return button on the tablet needed to be used to take the user back to the launch menu.

Fig 6.1.1 B: Bottom-sliding Navigation

Fig 6.1.2 A: Homescreen Navigation

34

6.1.3 Sliding MenusThe third alternative regarding navigation was a tab-like interface but with sliding properties, the idea was to support scalable functionality in the future.

Fig 6.1.2 B: Homescreen Navigation

35

Fig 6.1.3 A: Sliding Menus

Fig 6.1.3 B: Sliding menu bottom

36

6.1.4 Plate NavigationOther issues considering navigation were inside the plate activity, as it should contain various information that needed to be sorted somehow.

Fig 6.1.3 C: Sliding menu top/bottom

37

Two solutions were produced, the first was tab-based with a list to the left displaying various airports, when an aiport was clicked the different procedures for that airport expanded as a clickable list to the right. The procedures corresponded to PDF documents loaded on the tablet. The other solution offered a search function that where suppose to be able to search the within all the activities (plates included). Other features

Fig 6.1.4 A: Plate navigation

Fig 6.1.4 B: Search- and List- based navigation

38

inside the plate activity included the ability to mark some procedures or airports as favorites, and those who were starred would be displayed above the others.

6.1.5 COMM-Card

Fig 6.1.5: A solution for the COMM-Card?When dealing with activities that could contain a lot of information (Such as the comm-card) the above solution was produced. The idea was that the information could be scrollable but also have “quick buttons” at the bottom, which would show up when you clicked the menu button, to quickly scroll to where the sought information was. The design would provide tools for browsing vast amounts of information in a single file.

6.1.4 EvaluationDuring the process of creating the mock-ups they were continually under the scrutiny of two Saab employees, one Human-Machine Interaction wizard and one Saab oracle. They gave input regarding functionality and offered continuous feedback regarding different designs independently of each other. Most of the sessions with the wizard or the oracle were spontaneous and none of the evaluatory methods of testing (chapter 4) were really used. This however did not mean that the information from the informal meetings was lost - the drawings and ideas that were produced on whiteboards etc. were copied and saved. When testing the ideas on fighter pilot representatives, the character of the meetings were more formal and the usability methods for cooperative evaluation (4.3.3) were followed - to catch flaws in the design and reveal errors in thinking committed by the designers.

6.1.5 FindingsMeetings with the wizard and the oracle gave such input so the design space initially grew. After a while however, some ideas where thrown away to make way for new improved ones, which often consisted of several ideas put together. The test on the pilot representatives gave insight in some of the problems pilots are faced with. Results from

39

the tests showed that it was essential to keep down the amount of actions for performing tasks. Other findings where that the launch screen prototype would provide more screen real estate but probably raise the amounts of actions for performing an action. The tab prototype on the other hand would keep the amount of actions down, but would constantly occupy some of the screen. The version with sliding properties were discussed, but the fighter pilot believed that it would be hard to be precise when sliding through the menu and performing the right action while in flight. When dealing with the navigation inside the plates activity, the pilots felt the need for arranging the airports in their own way. The idea regarding favorites was well received. Other important feedback was how to sort out information when an airport was chosen; should the information be sorted with respect to the type of procedure (taking off or landing) or the runway being used. In this case opinions differed from pilot to pilot. Attributes considering information on multiple pages were also discussed and how it preferably would be flipped or scrolled, no conclusions were made at this point. An issue regarding scalability was discovered. Since the tab version and the homescreen version only provide a limited number of functions that fit within the tab and on the homescreen, this would cause problems if more functionality were added in the future, since there would be no space left to put more buttons. The sliding feature however would solve this problem as functionality then is just added to the sliding menu and the user has the ability to slide through the multitude of available selections. The sliding solution was however deemed to be hard to navigate efficiently as functions were added.

6.1.6 Analysis: Paper PrototypingThe two main navigational structures were homescreen navigation and the top/bottom navigation, which mainly consisted on modifications of tab navigation. Tab navigation allowed for different choices to be constantly available which strengthened the efficiency of use and helped recovery upon error. For example, if you pressed the wrong button in the homescreen you would first have to go back and then press the correct button; while in the tab navigation you would simply press the correct tab directly after pressing the wrong one. Also in the homescreen the user would need to be aware of pressing the wrong button as visible feedback when reaching the active activity while in tab navigation feedback is given directly on the tabs in the form of a change of color, thus alleviating the need for the actual activity provide this feedback to the user. Examples of this feedback, visibility and navigation can be found in pictures 6.1.5 and 6.1.1 B, as well as many others. The tabs are similar to the tabs found in folders which affords an already present sense of use in the users, they "just know" that they can be clicked. The tab design consisted of buttons with text to show purpose and "clickability" as well as a static location which increases memorability and learnability (6.1.4 A). The homescreen buttons also looked like buttons and had static locations for placement memory recognition.The homescreen version had more screen real estate which opened up the possibility for larger buttons, meaning less errors from pressing the wrong buttons. The obvious feedback upon pressing a button is that the systems screen changes to the associated activity. To get back to the homescreen, to navigate to another activity for example, the user would need to press the hardware "back" button and then press the correct button, which means constantly adding a button push to navigate between activities. This does promote use in the sense that the entire screen can be used for the active activity but it

40

does not promote navigation or efficiency due to all the extra button pushes. Since there are no built in visual clues upon navigation in the homescreen application it is important that the design is consistent. It has to be very obvious that the user has navigated to the desired activity (using breadcrumbs or a title for example). To keep consistency, the new activity should follow the same design rules employed in the other activities, such as colors and fonts, as much as possible. This gives a consistent impression to the user and gives the user a visual cue that says "yes, you are still in the same application, everything is OK!".Sliding menus, like tab navigation, gives the user high visual feedback of which activity is currently active. Some of the drawbacks include a lack of error prevention due to the sliding instead of pushing. Also the human memory remembers the positions of things as well as appearance, and the position of the buttons will move around as the user slides and thus does not use the human memory to its full advantage. The sliding menus do not constrain the user away from making the wrong decisions, if performing a poor slide while in flight or due to the navigational or error prevention problems. Sliding is also a fairly new phenomenon in the user interaction world which reduces its familiarity since the user does not intuitively know how it works, which gives it less affordance.The PLATES activity hold a lot of information and must be easy to navigate and provide the user with obvious feedback of how to use its list based structure properly. The "search solution" (figure 6.1.4 B) has poor visibility since it does not show any choices, the user must know exactly what is being sought. The fighter pilots did not have a search function in their old flight bags and are therefore not familiar with using it in the cockpit. They may however be familiar with the search solution from web browsing and other modern activities. The only feedback received are the results from performing a search. An idea to solve this would be to implement an instant search, showing dynamic results. The other solution for presenting plates (see figure 6.1.4 A) is for a more classical double list. The left list dictates what the right hand list shows and there is visual feedback of the list item selected by changing its color in a similar way as the tabs. The right hand list also has a small title which also shows what has been selected. In retrospect, this would have been better used to signify the type of operation being performed (landing, take-off…) or the runway being used. This is a very familiar interface in the digital realm with a high degree of affordance, as many applications use this structure to display information. Also that the buttons look clickable and their output is what the user thinks they will (If you click on an airport you will get that airports PDFs).For the COMM-Card a solution (see figure 6.1.5) was needed to show many different types of information at the same time. Both tables and pictures as well as a space for free flowing text. When considering visibility design principles it seemed smart to only show the user the information which was important at the moment. Other aspects were how to handle several pages of information and how the navigation between the different types of information could be efficient and intuitive. In figure 6.1.5, it was solved by using "quick buttons" which popped in at the bottom of the screen when touching anywhere on the screen. These quick buttons would allow the user to navigate the COMM-Card to a set of predetermined destinations. This does not initially support feedback or visibility as the quick buttons were hidden, but after the user uses the application once or twice, it was theorized that the memorability would be high enough that the function would be remembered by the user. It was deemed "worth it" to forsake some visibility to help the navigation and efficiency when using the COMM-Card

41

activity. This solution was only implemented for the COMM-Card activity, which was not very consistent and questionably familiar to the user. However, if successful, this solution could have been implemented for the FREQUENCIES and CHECKLISTS activities.

6.2 Keynote Prototyping

The keynote prototyping began with importing the template of the Samsung Galaxy Tab S. Elements from the paper prototype were then successive placed through out the template. Only the Tab version was implemented to keynote because functions would be the same almost regardless of the overarching navigational structure. Also, it was believed to be the most likely candidate of the different interface navigation layouts, based on the principles of good design. All the different elements (checkboxes, buttons etc.) are standard android elements and proposals for how the elements should look like and behave when interacted with. Below, the PLATES activity is displayed.

Fig 6.2 A: The keynote prototyping

Fig 6.2 B: PLATES activity default

Fig 6.2 C: PLATES activity ESSA selected

Fig 6.2 D: Viewing a plate

42

The initial state of the template application was the PLATES activity. To notify the user which activity was active its button was colored gray, while inactive activity tabs had a distinctly darker color. The different airports were presented in a list which afforded clickability. When an airport is marked, the button shifts color and a list of runways and procedures for that airport expands to the right. A click on one of the procedures will open the corresponding PDF document, replacing the list of airports and runways. However, the PDF would be opened by the application itself, not an external one.Since “favorites” was one of the ideas which was well received during the paper prototyping phase, it was implemented as stars to the left of the text for airports. The favorites were placed at the top of the list of airports. Airports became marked as favorites when an unfilled star was clicked - then the new favorite moved to the other favorites at the top of the list. Other attributes that were implemented were the properties of the hardware buttons. This was done because it was clear that they would need to retain their basic functionality since they could not be removed - Figure 6.2 E and 6.2 F displays the functionality of the settings button.

The settings button is positioned at the bottom of the tablet to the left. When touched, a menu will expand upwards with a button named settings. When this button is clicked the SETTINGS activity will start. In the SETTINGS activity are two checkboxes and an “open dialog” button. Note that the settings are not necessarily specific to the PLATES activity, which was open when the SETTINGS activity was started, meaning that the properties in this template can be global for the whole application. The COMM-CARD activity needed to handle several pages of tabular and image information. This templates solution dealt with the issue of multiple pages using arrows that would take the user to the desired page instead of scrolling. Note that this is a dummy COMM-Card.

Fig 6.2 E: Plate with Settings opened

Fig 6.2 F: Settings

43

Figure 6.2 I-K displays the template version of the CHECKLIST activity. The buttons each represent different features that could be checked. Note that this is a dummy checklist.

The NOTE activity is a place for the user to perform notes and drawings. Since the area is quite small there is an additional button for adding pages. Since it can contain a varying number of pages, it was conceived that the user would “flick” to move between different pages that have been made. There is also the possibility to completely wipe a page, so new information can be added to that page. The white circles show the amount of pages and the blue coloring lets the user know which page is currently in use.

Fig 6.2 G: Comm-Card Fig 6.2 H: Comm-Card page 2

Fig 6.2 I: Checklist Fig 6.2 J: Run-up Fig 6.2 K: Run-up & Oil status

44

6.2.1 EvaluationThe testing was conducted on the HMI wizard (Petterstedt, 2011) and the authors. The aim was to see if the navigational structure and designed functionality would work out or if there were any inherent flaws. At this point, the testing was informal but stricter than the first meetings when the paper prototypes were scrutinized. Think aloud testing and cooperative evaluation were conducted, supported by case