Development of a Style Guide for the Traffic Flow Management Traffic Situation Display Graphical User Interface

Transcription

1 Proceedings of the Human Factors and Ergonomics Society 2016 Annual Meeting 1394 Development of a Style Guide for the Traffic Flow Management Traffic Situation Display Graphical User Interface Robert Bastholm and Anthony Masalonis, Spectrum Software Technology, Inc. Tanya Yuditsky, Federal Aviation Administration Traffic Flow Management (TFM) functions to minimize airspace congestion and maximize safety and efficiency. TFM personnel at the U.S. Federal Aviation Administration use Traffic Situation Display (TSD) software to observe air traffic and weather systems and issue strategic congestion-mitigation initiatives to Air Traffic Control facilities. Since its initial deployment, the TSD has been augmented by many groups of developers. This distributed process has led to an inconsistent interface that does not always adhere to best usability practices, especially because during the initial stages of development there was little human factors involvement. This can have a detrimental effect on new users learning the interface and also may make experienced users more likely to make errors. We developed a style guide for an operational Air Traffic Management tool, and a companion consistency assessment, to help developers (a) adhere to usability principles for future software expansions and (b) bring older portions of the interface into compliance with user-centered design. We discuss the process of style guide development including the unique aspects of the TFM user population and application domain and their implications for creating a style guide for TFM software and the applicability of our guide beyond the TSD tool. Not subject to U.S. copyright restrictions. DOI / INTRODUCTION The Federal Aviation Administration s (FAA's) Air Traffic Management services include Traffic Flow Management (TFM), dedicated to minimizing airspace congestion and increasing safety and efficiency, generally using more strategic time frames and larger geographical areas of the National Airspace System (NAS) than those of concern in Air Traffic Control. TFM personnel measure air traffic demand against the capacity of NAS resources and delay or redirect traffic flows in response to high-traffic volume, weather, or other events. Instead of directing individual aircraft in the same tactical manner as Terminal Radar Approach Control (TRACON) and Air Route Traffic Control Center (ARTCC) controllers, TFM personnel develop larger scale strategic initiatives affecting flows of traffic and communicate them to controllers for implementation. TFM initiatives may take the form of holds, altered sequencing, altitude segregation, ground delays, miles-in-trail, and many types of less-common solutions (FAA, 2009). TFM personnel rely primarily upon the Traffic Situation Display (TSD) to view NAS status and issue initiatives (see Figure 1). The TSD graphically represents all instrument flight rules aircraft in the NAS, as well as airports, navigation aids, fixes, sectors, and weather systems (FAA, 2009). TFM personnel issue commands via the TSD s graphical user interface (GUI) to define flow constrained areas and reroute traffic around them, among other functionality. The TFM Program Office has been adding new functionality to the TSD, as a result of operational evaluations, research, and user requests, for more than a decade. Due to the long period of time over which functions have been added, many different development teams have been responsible for the various new functions or group of functions. Furthermore, in the early stages of TSD development, there was not much human factors involvement. This approach has contributed to a disparate look-and-feel between individual dialog boxes (see Figures 2 and 3), including different sets of default buttons, varying heading capitalizations, and many other issues. Figure 1. Traffic Situation Display showing flights to KLAX, KORD, and KATL.

2 Proceedings of the Human Factors and Ergonomics Society 2016 Annual Meeting 1395 METHOD Figure 2. One table style. Figure 3. A different table style. Lack of design guidance has also led to confusing use of modal and modeless windows, inconsistently located functions (see Figure 4), a lack of mnemonics for some vertical menus (see Figure 5), and other issues that have the potential to frustrate users and could lead to an error that affects the National Airspace System in a significant way. Figure 4. Absolute Time Range under the View menu in one window and under the Customize menu in a different window. Figure 5. Menu options without mnemonics. To promote consistency in future interface development and encourage developers to improve old portions of the interface, we began developing a style guide (Bastholm, Masalonis, Yuditsky, & Messina, 2016) for the TSD. We drew inspiration from Microsoft, Apple, and the Open Software Foundation, who established and continue to develop style guides and usability guidelines for first- and third-party developers (Apple, 2013; Microsoft Corporation, 2010; Open Software Foundation, 1993). Presumably, developers will adhere to these guidelines not only to improve the user experience but also to make development easier. Using interface elements in a standardized fashion would eliminate most cases of developers need to reinvent the wheel for a given user interaction. We created our style guide with this purpose in mind. Compared to the aforementioned software, the TSD and the TFM application domain have unique aspects that raised challenges for style guide development. First, the user population is highly trained and specialized; TFM personnel use the TSD daily. Therefore, some small degree of deviation from general GUI design norms is acceptable. Second, the highly specialized nature of TFM tasks often meant that little guidance was available in the existing literature and standards that directly addressed a given TSD function. TFM involves decisions that affect flight safety and efficiency. However, it is much less time-critical and more strategic compared to, for example, the tasks of an air traffic controller averting an imminent aircraft collision. One example of a TFM task is to intermittently monitor the progress of an evolving TFM initiative, such as a reroute affecting a large geographical area, over the course of many minutes or hours. Designing for this task brings up quite different design considerations than designing for an aircraft or automotive collision warning function, or a process control monitoring tool designed to detect major but infrequent changes. Changes must be salient, and it must be easy to detect patterns across large areas and long time frames. Environmental factors also come into play for designing TFM GUIs. The task is conducted, at least in most U.S. facilities, in a relatively dark radar room. In addition, because TFM decision making is distributed, it requires extensive verbal communication about developing situations both within the same room and by telephone. The TSD Style Guide (TSDSG) began as a catalog of adherence to and deviations from GUI usability guidelines. Initial topics were dialog boxes, color, menus, controls, and filters. We referred most often to the comprehensive Human Factors Design Standard (HF-STD-001; Ahlstrom & Longo, 2003) for guidelines. This standard provided us with descriptions of how dialog boxes should behave when resized, how text should be aligned, how modal windows should function, and so on. The challenge outlined earlier regarding the specialized nature of TSD functions came into play in that we could not always locate a suitable guideline for a specific operation of the TSD. When this occurred, we assessed and documented the existing behavior of that operation throughout the TSD. For example, the TSD s timeline functions contain

3 Proceedings of the Human Factors and Ergonomics Society 2016 Annual Meeting 1396 information formats idiosyncratic to the application, so there are no standards by which to evaluate them. Therefore, we developed the guideline that single timelines should show flight counts in the top row and time labels in the bottom row (see Figure 6; Bastholm, Masalonis, Yuditsky, & Messina, 2016). This guideline is based on current dominant TSD practice rather than an external standard. Figure 6. Timeline with flight counts on top row and time label on bottom row. At other times, the TSD was not in compliance with best practices, but we heuristically determined that the infraction was minor and made some degree of sense in context. For example, the NAS Monitor function codes high-priority situations in red and medium-priority situations in yellow (see Figure 7). Typically, these colors are reserved for emergencies (Ahlstrom & Longo, 2003), whereas the TSD uses them merely for the sake of prioritizing airspace sectors with regard to their probability of exceeding traffic capacity. The users, however, still benefit from the way in which the information is presented and are accustomed to this coding scheme, so we based our guideline around continuing this behavior. We also documented other, potentially more serious, deviations from established guidelines. For example, two TSD windows have check boxes that, when checked, open child windows. Check boxes should be used to make selections, so opening a window is an unpredictable behavior (Nielsen, 2004). Regardless of the specific source, we documented all interface elements compliance with these guidelines in the form of tables. The TSDSG soon, however, became an unwieldy mixture of guideline text and compliance tables describing behavior instead of showing it. A guide about usability was itself becoming unusable, so we changed its format significantly. We split the TSDSG into two documents. The TSDSG was now focused on showing illustrations of each guideline. It no longer had hard-to-digest text; instead, it provided a visual demonstration of how GUI elements should work. The new format is more readily understood at a glance; guidelines map to images that provide examples, and we use color to highlight key terms (see Figures 8 and 9). Figure 8. Old text-dense TSDSG format. Figure 7. NAS Monitor colors.

4 Proceedings of the Human Factors and Ergonomics Society 2016 Annual Meeting 1397 Figure 9. New image-focused TSDSG format. To document the TSD s compliance with our guidelines and supplement the TSDSG, we created the TSD Consistency Assessment (TSDCA) (Bastholm, Masalonis, & Yuditsky, 2016). This document provides direction for fixing existing usability issues instead of guidance for developing additions to the software. The TSDCA documents not only guideline compliance but also internal consistency. In the TSDCA, we repeated each of our TSDSG guidelines followed by a table listing compliance of the application s GUI elements with the guidelines. A column of check boxes under a given guideline shows that the functions associated with each row are consistent with each other in having that item (see Figure 10). In short, the TSDCA is primarily descriptive whereas the TSDSG is mainly prescriptive. This approach, combined with a somewhat casual writing style compared to American Psychological Association standards, is intended to make the documents more accessible to software developers who are not human factors practitioners. Figure 10. Example compliance table.

5 Proceedings of the Human Factors and Ergonomics Society 2016 Annual Meeting 1398 A primary goal of the TSDSG is to aid developers in making optimal design decisions. For example, by following guidelines about consistently using context menus, developers could avoid users not knowing if they can use context menus in a given interaction. In the current TSD, the NAS Monitor dialog box provides context menus, but the Select Flights dialog box does not (see Figures 11 and 12). The information in the TSDSG and TSDCA would encourage the inclusion of this useful GUI element in both transactions. Figure 11. NAS Monitor dialog box with context menu activated. Figure 12. Select Flights dialog box with no context menu. DISCUSSION We delivered the first edition of the TSDSG to the FAA TFM Program Office in January 2016 for dissemination to the development teams. The TSD is under continual development, and we expect to see improvements in usability and consistency in new functions as developers follow our design guidelines. Although no initiative is currently underway to revise the GUI of existing TSD functionality, we believe that when development resources are available to improve old designs, our evaluations in the TSDCA will prove useful for supporting this effort. Also, the TSDSG and TSDCA principles can be successfully applied to any future large-scale TSD GUI refresh. The TSD itself is a highly specialized application with a limited user population. Nevertheless, the process we used in the development of the TSDSG and TSDCA, as well as some of the specific guidance contained in these resources, will be more widely applicable. For example, the FAA s Human Factors Research and Engineering Division (ANG-C1) and Human Factors Branch (ANG-E25) are undertaking a research effort to develop GUI and training guidance for Decision Support Tools and what-if tools, guidance intended to apply both to TFM and to other (primarily aviation) domains. The same groups are conducting a related effort to derive guidance for display of time-based information again, in multiple aviation and other domains. Decision support, what-if functions, and time-based displays are all prevalent in the Traffic Situation Display, so it is anticipated that the guidance in the TSDSG, as well as the development methodology for the TSDSG and TSDCA, will serve as starting points for these safety-critical design efforts. In addition, we intend for our description of this process to be useful outside the world of aviation. Many domains, such as process control and surgery, share characteristics of TFM, e.g., monitoring complex processes over time and sharing information among users. Our experiences developing a style guide and consistency assessment such as realizing that a graphical style was more digestible than a textual one, and separating prescriptive and descriptive information may serve as inspiration for human factors professionals and software developers working to improve the design of applications in their own domains. We recommend future work to explore the development of design guidance for other specialized application domains. REFERENCES Ahlstrom, V., & Longo, K. (Eds.). (2003). Human factors design standard (HF-STD-001). Atlantic City International Airport, NJ: Federal Aviation Administration, William J. Hughes Technical Center. Apple, Inc. (2013). Mac OS X Human Interface Guidelines. Retrieved from /documentation/userexperience/conceptual/applehiguidelines/textstyle/ TextStyle.html Bastholm, R., Masalonis, A., & Yuditsky, T. (2016). Traffic Situation Display consistency assessment. Atlantic City International Airport, NJ: Federal Aviation Administration, William J. Hughes Technical Center. Bastholm, R., Masalonis, A., Yuditsky, T., & Messina, J. (2016). Traffic Situation Display style guide. Atlantic City International Airport, NJ: Federal Aviation Administration, William J. Hughes Technical Center. Federal Aviation Administration. (2009). Traffic Flow Management in the National Airspace System. Washington, DC: FAA National Headquarters. Microsoft Corporation. (1995). The Windows interface guidelines - A guide for designing software. Redmond, WA: Microsoft Press. Microsoft Corporation. (2010). User experience interaction guidelines for Windows 7 and Windows Vista. Redmond, WA: Microsoft Press. Nielsen, J. (2004). Checkboxes vs. Radio Buttons. Retrieved from Open Software Foundation. (1993). OSF/Motif style guide, Revision 1.2. Englewood Cliffs, NJ: PTR Prentice-Hall, Inc. ARTCC FAA GUI NAS TFM TRACON TSD TSDCA TSDSG ACRONYMS Air Route Traffic Control Center Federal Aviation Administration Graphical User Interface National Airspace System Traffic Flow Management Terminal Radar Approach Control Traffic Situation Display Traffic Situation Display Consistency Assessment Traffic Situation Display Style Guide