Attachment 7 FMDS HIG 250918.pdf

Human Interface Guidelines (HIG) for the Flow Management Data and Services (FMDS)

Situation Display v2 April 28, 2023

HIG for FMDS Situation Display i

Table of Contents

1 Introduction

1.1 Human Centered Design

1.2 Program Overview

1.3 Using This Document

2 Situation Display (SD)

2.1 Users

2.2 Primary Functions

2.3 Goals/Approach

2.3.1 Integrated Functionality

2.3.2 User Interface

2.3.3 Customization

2.3.4 Display Environment

3 Look and Feel

3.1 Simplicity

3.2 Consistency

3.3 Standardization

3.4 Screen Optimization

3.4.1 Optimization through user adjustments

3.5 Support the Users

3.5.1 Support Workflows

3.5.2 System Responsiveness

3.5.3 SD System Status

3.5.4 Tool Tips

3.5.5 Quick Action Commands

3.5.6 Data Entry Tools

3.5.7 Prevent / Manage Errors

3.5.8 Online Help

3.6 Use of Color

3.6.1 General Color Guidelines

3.6.2 Color Palettes and Color Sets

3.7 Use of Fonts

ii

3.7.1 Font Family

3.7.2 Font Color

3.7.3 User Control of Font Display

3.7.4 Text Differentiation

3.8 Maps

3.8.1 Look and Feel

3.8.2 Navigation

3.8.3 Overlays

3.8.4 Interactivity

3.9 Data Grids and Tables

3.9.1 Data Table General Design

3.9.2 Column Customization

3.9.3 User Actions

3.9.4 Use of Fonts

3.10 Charts and Graphs

3.10.1 Look and Feel

3.10.2 Interactivity

3.11 System Messages

3.12 Design Checklist

References

Acronyms and Abbreviations

Appendix A – TFMS Design Examples ....................................................................................................... A-1

Appendix B – Fixed Colors .......................................................................................................................... B-1

Appendix C – Design Checklist ................................................................................................................... C-1

List of Figures Figure A-1. Flight Type Icons in FSM, TSD, and Surface Viewer ................................................................ A-3

List of Tables Table 1. System Response Time framework Table 2. Commonly Used TSD Quick Keys ................................................................................................. A-1 Table 3. Flight Schedule Monitor Status Tab Reserved Colors ................................................................. A-2

HIG for FMDS Situation Display .

1 Introduction The fundamental goal of Traffic Flow Management (TFM) is to strategically manage the flow of air traffic to minimize delays and congestion in the National Airspace System (NAS) due to system stressors such as weather or equipment outages. In pursuit of this goal, Traffic Managers use multiple automated decision support tools to perform their operational tasks. The Traffic Flow Management System (TFMS) consists of a suite of traffic management tools, each designed to meet a specific need and to provide the information and capabilities needed to accomplish a particular function.

TFM systems and tools evolved with little attention toward integration, so Traffic Managers must often resort to opening multiple applications across multiple displays in order to comprehend the current traffic situation, develop a plan, and execute a response. Traffic Management Units today are crowded with workstations and displays, but without integration they cannot portray a complete view of the operation, provide integrated tools to manage it, or optimize operational decision-making.

The purpose of this document is to provide human factors guidance for the development of the user interface of the Flow Management Data and Services (FMDS) Situation Display. The Federal Aviation Administration (FAA) Acquisition Management System refers to human factors as a critical aspect of aviation safety and effectiveness and calls for an integrated approach to human factors engineering. FAA Order 9550.8 establishes the policy, procedures, and responsibilities for including human factors on a systemic level throughout the development of all FAA programs and activities. At a fundamental level, the human factors guidance provided in this document seeks to ensure that the design of the Situation Display user interface will provide Traffic Managers with a system that is easy to learn and easy to use.

In addition, this document describes some of the existing user interface conventions. These conventions are important to be aware of because they shape the expectations of existing users.

1.1 Human Centered Design

User interface design is inherently coupled with potential risks to operational task performance, situation awareness, and operator workload. Traffic Managers must be able to use the Situation Display to accomplish operational tasks, maintain awareness of system status, and understand how that might change in the operationally relevant future, while avoiding excessive cognitive workload. A Human Centered Design approach provides a framework to reduce these risks and produce a successful interface by considering the strengths and weaknesses of the user in the design of the overall system (ISO Standard 13407, 1999) from the earliest stages of development.

There are typically five stages associated with a Human Centered Design approach:

1. Identification of operational goals - To create an effective interface, it is important to understand system goals and the overall effect that the system is expected to have on operations. The definition of these goals serves as the input to the analyses conducted in Stage 2.

2. Determine cognitive, perceptual, and motor requirements – This stage determines what problems the users will have to solve, the information they will need, and the controls necessary to achieve their objectives. The results of these analyses inform the initial design of candidate interface prototypes in Stage 4.

3. Compare against established standards and guidelines – Review established human factors standards to identify areas of concern. Section 3 of this document contains practical guidelines that should be applied (as appropriate) in the development of the Situation Display and should be used as a primary source for this exercise. The results of these analyses provide input to the initial design of prototypes in Stage 4.

4. Develop candidate interface prototypes – Produce candidate interface designs that will enable the performance of the required cognitive, perceptual, and motor tasks that were determined in the previous stage. This stage also benefits from the use of a multidisciplinary design team consisting of domain Subject Matter Experts (SMEs), hardware and software engineers, and human factors practitioners. This stage features an iterative design-evaluate-refine process that initially yields a candidate interface design prototype. The prototype is then subjected to performance-based evaluation described in the next stage.

5. Human performance-based testing – Conduct early and ongoing usability testing of candidate interface design prototypes developed in the previous stage. Testing is conducted using operationally relevant scenarios and measures performance, situation awareness, and workload. These measures drive the next iteration (if needed) of the design-evaluate-refine cycle (Ahlstrom, 2016).

The application of this Human Centered Design paradigm features two important elements: the use of multidisciplinary design teams and an iterative development cycle. The multidisciplinary design team should include Traffic Managers as domain SMEs, Human Factors specialists, and software engineers.

Each of these groups is important to increase the probability that the resulting design will meet operational needs given the capabilities and constraints of human users, within real world technological constraints.

The FMDS Situation Display will be the primary tool for Traffic Managers. Therefore, the importance of early and ongoing interaction with domain SMEs is crucial. SMEs are best suited to provide insight into operational issues, ensure that candidate designs address real world needs and meet regulatory requirements, and ensure that test scenarios accurately reflect tasks that Traffic Managers perform routinely in the field under operational conditions.

An iterative development cycle allows for continuous evaluation and refinement of the conceptual design. Through this iterative methodology, the development process ultimately converges on a design that optimizes human performance and thereby optimizes the potential for system success.

1.2 Program Overview

TFMS provides key capabilities to support TFM. However, the tools have reached end of life and are exhibiting reliability, maintainability, and availability (RMA) and performance shortfalls. FMDS is a new incarnation of TFMS that meets the operational, RMA, and performance needs of its users. FMDS does not anticipate significant changes in functional TFM roles and responsibilities relative to the current system, but it envisions a new approach to software development and implementation that will better meet those needs.

TFMS primarily supports TFM functions conducted by Traffic Managers at various air traffic control facilities and the Air Traffic Control System Command Center (ATCSCC). It also provides the framework for conducting Collaborative Decision Making (CDM) among Traffic Managers working in different facilities, and between Traffic Managers and NAS users. Today, TFMS is performing beyond its design, but has not been able to keep up with users’ increasing expectations.

FMDS will provide a robust and reliable automation system to support TFM functions in a modernized, service-based architecture that will provide flexibility to the FAA for implementing capabilities as well as extensibility to future enhancements. As much as possible, functions needed by multiple applications will be implemented as services, which will avoid duplication of functions and data across applications.

The FMDS Situation Display will allow Traffic Managers to view all traffic, Traffic Management Initiatives (TMIs), and weather in one application. This contrasts with the current system, in which weather and different TMIs are modeled, coordinated, and represented in different applications. This integration will improve Traffic Managers’ ability to evaluate predicted demand relative to system stressors and develop, coordinate, and manage TMIs strategically and efficiently. FMDS and the Situation Display will support automatic logging of information that today is collected electronically but must be logged manually, reducing Traffic Manager workload associated with entering duplicate data across applications.

The FMDS Situation Display will also support sharing of TFM information with NAS users. Some NAS users may access TFM information through the Situation Display, whereas others will access the information relevant to their operations through the NAS Status Portal web application, which will receive much of the same information as the Situation Display. Through the NAS Status Portal, NAS users will be able to subscribe to notifications of changes in TMIs, strategic plans, and other information.

FMDS will expose Application Programming Interfaces (APIs) that will allow CDM members to access data and services they can use to assess the impact of TMIs on their flights using the same algorithms that support the Situation Display used by Traffic Managers.

FMDS will create a robust store of the data presented to users, data exchanged among users/facilities, and data exchanged among the application support services that will drive the applications and displays.

The Situation Display will allow the replay of this data to support post-event understanding of the series of events and their impacts on NAS operations. See the FMDS Concept of Operations (FAA, 2021) for further details.

1.3 Using This Document

The purpose of this document is to provide a single source of design guidelines oriented to the users and functions of the FMDS Situation Display. We identified the topics and areas to include based on our experience with the existing TFMS Traffic Situation Display, with a view to the future where a more modern design approach may be feasible. To that end, there are multiple guidelines for each area/topic to allow for flexibility and innovation in the design of the future Situation Display. It is also important to note that while each individual guideline can stand on its own, multiple guidelines may not work effectively in combination. Application of these guidelines will require expert professional judgement within a Human Centered Design approach where the guidelines will frame the discussions with SMEs.

For any areas not covered in this document, the cited references should serve as good sources for human factors guidance.

2 Situation Display (SD)

2.1 Users

The primary users of the FMDS Situation Display (SD) will be FAA Traffic Managers. It is also intended for other FAA users (e.g., quality assurance and training, controllers consulting the Enhanced Status Information System (ESIS) for current relevant restrictions, etc.) and NAS users that have access to TFMS tools today. Their use of the system varies widely dependent on facility and position or role. This can vary from monitoring flows on the map to developing, modeling, and issuing TMIs.

Those who use the system extensively typically set up multiple “views” utilizing workspaces and multiple monitors; then switch between them as needed. For example, a user might show sector demand and National Traffic Management Log (NTML) on one monitor while viewing different traffic flows across multiple workspaces on another.

Additionally, it is anticipated that like the existing Traffic Situation Display (TSD), the SD will be shared with airline users. No specific airline features have been added, but any functions that modify data should be disabled for these users. In effect, this needs to be a view and model only instance of the SD.

2.2 Primary Functions

The FMDS SD will encompass all functions currently available in TFMS via the TSD, Flight Schedule Monitor (FSM), NTML, Surface Viewer, and the capability to provide data to ESIS displays. The SD will support the following functions (FAA, 2021):

• Monitoring NAS Operations - Review the current state of the NAS (traffic, weather, etc.) to identify constraints that may require TFM actions such as TMIs.

• Modeling TMIs - Assess potential TMIs to determine the most appropriate course of action for the identified constraint.

• Coordinating TMIs - Communicate TMIs, especially TMIs that do not generate flight-specific assignments.

• Issuing TMIs - Implement TMIs so they can be reflected in the modeled flight trajectories that drive demand prediction.

• Logging and Reporting – Log actions and report operational information.

• Querying and Generating Route Options – Query, review, and display routes; select routes to avoid constraint areas and weather.

• Replay – The ability to “replay” past data including trial modeling of TMIs against past data.

• Route Management: Enable querying adaptation data to aid in constructing reroutes, plus provide static information on airport/Navigation Aids (NAVAIDs)/fix identifiers, preferred routes, major traffic flows, and parsed routes.

• TFM Reports: FMDS will provide a comprehensive store of operational TFM data that will allow Traffic Managers, NAS users, and post-event analysts to access NAS performance data. Users will be able to access the data store using their preferred data access and analytics tool, but FMDS will provide a commercial off-the-shelf (COTS) capability to access pre-defined reports like those provided today via FSM, TSD, and TFMS Reports. The application will also allow users to create custom reports. The intent is for these reports to be sufficient to support real-time operational evaluation of NAS performance and basic post-event analysis needs, but sophisticated analysts like the post-event analysis team at the ATCSCC may access the FMDS data store directly using query capabilities that they implement on their own, like the home-grown solutions they use today.

2.3 Goals/Approach

The overall goal is to develop and deploy a Situation Display with integrated TFM functionality, using a modernized Graphical User Interface (GUI) within a multi-monitor environment allowing customization to support different roles and workflows.

2.3.1 Integrated Functionality

The SD will integrate TFM features currently spread across multiple applications into a single application that:

• Is extensible, so that it can seamlessly integrate anticipated enhancements from future work packages and concepts

• Is based upon a common data source so that data depicted over multiple display elements are synchronized and up to date

• Uses common terminology1 to ensure consistency in operational communications and to make training easier for users

2.3.2 User Interface

The SD will present TFM information over an updated GUI that:

• Uses intuitive and contemporary GUI elements consistent with industry practice

• Enhances TFM functions

• Maintains a consistent design

• Optimizes screen space

• Favors current TFMS dialog design (wherever they are consistent with the above practices) to facilitate skill transfer from the old system

2.3.3 Customization

To accommodate different types of users and workflows, the SD will:

• Accommodate configuration for different user classes

• Use single sign-on or positional permissions, with the features available to a user governed by their user type / location in an operational environment

• Provide users maximum flexibility in window layout and size

• Allow users to quickly store and retrieve configurations within Preference Sets (Pref Sets) that:

o Store information for a wide range of features within a single Pref Set o Support positional portability so that users can access their personal configuration data across workstations

2.3.4 Display Environment

The SD will present TFM information in a display environment that:

• Allows users to switch between views quickly and easily. TFMS users create multiple window layouts that provide them different views on NAS operations, and they want to be able to easily switch between those views. Currently, TFMS supports this by allowing them to create multiple

1 Such as the TMI Attribute Standardization (TAS) ontology to implement common semantics across TFM applications (Cunningham, et.al, 2016).

workspaces.

• Can display on multiple monitors within a single virtual workspace. Some users expressed the desire that all monitors should be treated as a single, unified desktop. Thus, when switching between workspaces, all monitors should switch to the newly selected workspace. Furthermore, the users indicated that each of the windows within a virtual display/workspace should be drag-able and resizable independently within that virtual display/workspace.

3 Look and Feel This section describes human factors interface design principles likely to maximize FMDS usability, making the system effective, efficient, engaging, error tolerant, and easy to learn (Quesenbery, 2001).

These principles apply across the FMDS user interface. We also provide guidelines for specific attributes of the design. In general, the design should follow interface design best practices and relevant standards such as the Human Factors Design Standard (Ahlstrom, 2016). We reference relevant sections of this standard as “HFDS” throughout this document.

3.1 Simplicity

The SD user interface should represent the simplest design possible consistent with functional requirements and the expected concept of operations (HFDS 4.2.1). Users find systems disorienting when they are overly complex, provide many functional components, use poorly integrated displays, or fail to align with the user’s understanding of the task (Woods, 1984). The resulting disorientation may leave the user searching for a needed function, unsure of how they got where they are, and unsure of how to get to where they need to go (Wickens, 1992).

Simplicity in design is generally associated with increased usability, greater reliability, lower potential for error, and lower training costs. For example, a simple design keeps the amount of on-screen information to a minimum, presents that information in an orderly and predictable manner, and speaks to the user in plain, direct language (HFDS 5.6.1.1.1). In general, FMDS user interfaces should be designed so that system functions and navigation between them are intuitively obvious to the user (HFDS 4.2.3).

It is often the case that complex dynamic domains, such as TFM, require focused attention to support operational tasks. When focused attention is required, extraneous information on the display can contribute to perceptual competition (Eriksen & Eriksen, 1974). The distracting visual elements, or clutter, compete for the users’ available attentional resources (Tufte, 1990) resulting in slower reaction times to system events, increased time to complete visual search tasks, reduced overall efficiency, increased workload, and greater potential for user error. Thus, information on the screen should be limited to the essential elements of information needed to complete the user’s task (HFDS 5.6.1.1.2) and organized so that visual competition between elements is minimized (HFDS 5.6.1.3.3).

Simplicity also matters in the language the system uses, from error messages to dialog headers to help text. Though the system is designed for expert users, even experts benefit from simple, plain-language communication: “No one has ever complained that a text was too easy to understand” (Loranger, 2017b). To communicate clearly and simply, it is important to consider the perspective of the user, use terminology familiar to them, communicate succinctly, write for a 10th-12th grade reading level, and use best practices in formatting (Loranger, 2017). When using jargon or technical terms, evaluate how many users are familiar with the terminology, and consider the importance of using the terminology (Moran, 2023).

3.2 Consistency

FMDS design should be consistent in appearance, behavior, and response throughout. Consistency in design means adhering to the same principles with minimal variation (e.g., maintaining a common design philosophy). Consistent design allows users to transfer general knowledge and skills learned from one part of a system and apply them elsewhere without learning or training (HFDS 4.3.1). Consistency in design is especially important in the SD given that it is integrating several different tools. For this reason, we recommend maintaining consistency in the following areas:

• Visual display design, format, and labeling (HFDS 5.6.3.1.2) – Inconsistent visual displays can confuse users, reduce situation awareness, increase workload – ultimately leading to user error.

Inconsistencies in the interface design can also make it difficult for users to transition from one display within a system to another (Wickens, 1992).

• Coding schemes (HFDS 5.6.6.1.6) – Using consistent information coding schemes (e.g., the use of colors, shapes, or symbols to denote specific meanings within a system) simplifies the user interface and reduces confusion and error. For example, using the same color to represent two different meanings can lead to user error. (See 3.6 Use of Color for more specific guidance)

• User interactions with the system – Inconsistencies in user interaction can lead to increased training requirements, inefficiency, frustration, and user error. If, for example, users must perform the same function using different techniques across different system components, the system will be more difficult to learn, and users will struggle to determine which method is appropriate in which context.

• Terminology – It is important to use consistent language throughout the system, especially in a system with as diverse a tool set as the SD. It is a known issue that TFMS does not use consistent terminology across tools, so it is important to revisit the use of terms while integrating TFMS functionality into the SD environment. This includes command words, terms for data elements, abbreviations, acronyms, etc. Use standardized terms/labels wherever possible.

A critical aspect of consistency concerns whether the design of the SD is consistent with the user’s mental model (HFDS 4.3.2). In other words, the design should align itself with how the user perceives their task, by being consistent with their expectations and cognitive strategies. Mental models provide the framework for a user’s understanding of a given task or system and a basis from which to predict how a system will react to their actions. A user’s actions should cause a predictable result (HFDS 4.6.2), and the order of their actions should be consistent with their understanding of the task.

3.3 Standardization

The surest way to maintain consistency throughout the design is to adhere to a rigorous design standard. The SD should be standardized as much as practical, consistent with functional and operational requirements (HFDS 4.4.1). To achieve this, the SD will be standardized using the following guidelines:

• Establish a design style and apply it throughout the design of the system. Use the same, standard user-interface features (e.g., terminology, coding, look and feel of displays and controls) throughout (HFDS 4.4.5).

o Employ the same user dialogs, interfaces, and procedures for system components that address common functions (HFDS 4.4.2).

o Apply standardized controls to facilitate user learning.

• Avoid unnecessary jargon and use standard or familiar task-oriented vocabulary to facilitate user understanding (HFDS 5.6.1.1.7). A common lexicon using standardized terminology will improve clarity. For example, the TMI Attribute Standardization Taxonomy Report (Cunningham, et. al, 2016) is a good source for TMI-related terminology.

Simplicity, Consistency, and Standardization all contribute to a design that helps the users keep track of where they are in a complex multi-element system (Woods, 1984).

3.4 Screen Optimization

The SD has the potential to convey large amounts of information on-screen and display it in an infinite number of configurations. It also provides multiple tools and commands that may be shown onscreen.

To reduce the risk of bombarding the user with information and controls, the SD needs to present data in a way that optimizes screen space, and gives the user tools to adjust how, where, and when that information is shown.

The first step in optimizing the display is to present information and controls within a visual hierarchy (Gordon, 2021) that organizes data according to its importance to the user.

The SD can maintain a visual hierarchy of data and controls by:

• Using design principles to emphasize primary information and deemphasize secondary and supporting information (Gordon, 2021)

• Consolidating monitored data in “dashboard” form designed to be readily understandable (Laubheimer, 2017)

It is not necessary to always have all the available information on screen. Control the amount of displayed information to avoid information overload. Consider design elements that hide secondary or supporting information such as:

• Progressive disclosure: Provide controls to show and hide greater detail.

• Tool tips: Showing pop-up information when the user hovers the mouse pointer over information to get more detail. For example, if the route in a flight list is truncated, show the full route string within a tooltip. (See 3.5.4 Tool Tips)

• Show/hide controls such as “More” or “+” controls to access more options

• Expand/contract menu controls: For example, in an options panel, require an extra step (such as an expander control) to access less frequently used options

• Fly-out menus and controls

• Consolidated menus and controls – consolidate menu bar items under a single menu control

(such as a “hamburger menu”)

• Context-dependent Information Panel – A collapsible / expandable panel that shows relevant information based on the user’s context. For example, when a user selects a flight on the map, the information panel might display status information, historical information, and provide controls for appropriate tasks such as creating a reroute.

3.4.1 Optimization through user adjustments

Also consider design elements that allow the user to temporarily manage on-screen information, such as:

• Window-shading – a capability to quickly hide (and un-hide) a panel or sub-window

• Slide-out / fly-out controls for window elements such as keys used in a bar graph, map legends, or tabs

• Modular tool bars that:

o Have customizable content o Are detachable and re-attachable o Can be displayed vertically or horizontally o Contain elements that can be detached as separate panels, resized, and collapsed

3.5 Support the Users

The integration of any new automation system can negatively affect human performance. New unfamiliar interfaces could impose excessive attentional, memory, or workload demands on users.

Furthermore, TFM is often a time critical domain. Any delay in resolving a traffic constraint may exacerbate the effects of an already difficult situation. As a practical matter, automation that takes too long, or requires too many steps to arrive at a solution, will not be used by Traffic Managers in the field.

The following sections describe design techniques that should be applied to mitigate these risks and support Traffic Managers in performing their tasks in a timely manner.

3.5.1 Support Workflows

Traffic Managers often perform complex, multi-step tasks using information from multiple sources. For this reason, the design of the SD must facilitate their workflows seamlessly, providing graceful transitions between display elements within or between system components. The SD must foster effective execution of procedures, match or enhance user workflows, and minimize factors degrading performance.

To achieve these goals, the SD must provide users with the right information at the right time in the right format for any task. Often this will require the user to “finish the design” by customizing the content and organization of available information to suit their specific operational needs. The following design techniques help support user workflows:

• Match the layout of the interface to the operational tasks performed by the user (HFDS 5.6.1.3.6). For example, the flight restrictions input tab in the NTML organizes the data entry fields in a logical progression for Traffic Managers to complete the entry.

• Allow users to configure the display to specific operational tasks.

• Provide context sensitive access to information / functions / controls that are pertinent to completing the user’s task.

o Provide quick action access to information and immediate actions.

o Identify what the user is doing and anticipate what they might do next. For example, selecting a Flow Evaluation Area (FEA) on the map may launch a fly out panel to Examine, Edit, or use the FEA in a TMI.

• Allow users to access commands in more than one location, such as in multiple locations within a menu hierarchy. Allow flexible navigational hierarchies for items that might not fit in a specific hierarchy (Laubheimer, 2018).

• Provide a search function for users to find commands.

To avoid degrading user performance, the SD must:

• Eliminate or minimize the need for users to access separate systems to retrieve or provide information relevant to the task (HFDS 5.6.1.3.17)

• Not require users to remember information obtained from one component for subsequent use in another (HFDS 5.6.1.1.6)

• Not require the user to re-enter data that already exists in another component (HFDS 5.6.1.2.8)

• Ensure easy transition between applications whenever those applications cannot be integrated o For example, support Cut/Copy/Paste and connection points between applications, such as exporting data from one application to another (Kaplan, 2020)

• Consider workflow in the display of modal (e.g., windows that take focus) windows o Do not allow relatively unimportant modal popup windows to interrupt the completion of time sensitive tasks (See also 3.11 System Messages)

3.5.2 System Responsiveness

The time that the system takes to respond to user input should align with user expectations and be appropriate to the user task. Nielsen (1993, updated 2014) provides high-level guidelines for mapping response times to user task needs. Where the user would expect an instantaneous response to their actions, such as responding to keystrokes or mouse clicks, the system should respond within 0.1 seconds. A response time of 1 second or less is vital for tasks that require the user’s uninterrupted flow of thought, such as sorting a table or pasting copied text. Actions taking longer than 10 seconds are likely to lose the user’s attention.

Table 1, derived from Doherty & Sorenson (2015), provides a useful framework for classifying system response time and mapping specific times with user expectations and actions.

Table 1. System Response Time framework

Attention Level

Category Name

System Response Time

User expectation and behavior

Attentive Instantaneous < 300 msec User maintains a sense of direct control

Immediate 300 msec – 1 sec Task is “easy to perform” by the system

Transient 1 sec – 5 sec Task may require some processing. User maintains task flow.

Attention Span 5 sec – 10 sec User believes system requires more time to process, will need system feedback to maintain task flow.

Non-Attentive Non-attentive 10 sec – 5 min User expects complex processing and will likely multi-task.

Walk-away > 5 min System needs to perform intensive processing.

User will “walk away” from the task and require feedback about system progress.

If an action is likely to affect the user’s task flow, the SD should (from Kaplan,2021a, and HFDS 5.6.15.7):

• Show system progress and indicate time remaining, changing progress text when status changes.

For lengthy processes:

• provide context in the progress dialog, such as start time, end time, time elapsed, and actions taken

• allow the user to pause, defer, exit, and resume

• allow the process to run in the background

3.5.3 SD System Status

Traffic Managers are often required to make decisions that rely on the timely receipt of information. It is crucial that the SD provide current and clear system status information to help them maintain situation awareness (HFDS 4.6.1).

To provide the users with system status:

• Include time and date information associated with the data (HFDS 5.6.1.1.8). This includes update times for individual displays as well as system level updates if the two may be different.

• Warn the user if the system did not receive an expected update.

• Notify users about any interruptions in operational data feeds (see also 3.11 System Messages).

• Clearly differentiate between system operating modes (e.g., real-time, model mode, and playback) (HFDS 5.6.1.2.6). For example, use different color schemes to differentiate between modes.

• If an action or search results in no data to display, indicate the null result in the space where results would occur (Kaplan, 2021b).

3.5.4 Tool Tips

Tool tips provide context sensitive information without adding clutter and are used extensively throughout the existing system. When a user hovers the cursor over an element on the screen, a text box or pop-up display presents relevant information about that element. The displayed information stays on screen until the user moves the cursor away from the target. The following recommendations provide examples of areas where tool tips will support the users:

• Provide context specific online help (e.g., description of control element or its function). Do not use tooltips for critical task information (Joyce, 2019).

• Provide additional or supplemental information relevant to a displayed element (e.g., flight information when hovering over an aircraft icon on the map).

• Display the complete entry for truncated information (e.g., when a table or grid column is too narrow to fit the contents in their entirety, show a complete route in the tool tip).

• Ensure that the tool tip disappears in a timely fashion when the user no longer hovers over the element.

3.5.5 Quick Action Commands

Quick action commands give the user rapid access to frequently used functions via macros, gestures, or keyboard shortcuts, (for example, Harley, 2019). The current system uses keyboard shortcuts extensively – which users refer to as “Quick Keys” – mapping designated keys and key combinations to frequently used functions (HFDS 5.6.7.6.2).

For example, Quick Keys allow Traffic Managers to:

• Manipulate the TSD map (e.g., zoom in, zoom out, move locations)

• Toggle information on the display as needed (e.g., show airspace boundaries or jet routes).

Modern system design may provide alternate means for accomplishing functions quickly, but existing system users will expect (at least the most used) legacy keyboard commands to be available. Based on the feedback received from Traffic Managers, we recommend a hybrid approach to the design of quick action commands in the SD. An approach that features innovative design solutions, such as quick action buttons or controls, while also being receptive to legacy functionality is likely to result in a more usable interface with broader acceptance among Traffic Managers. We recommend the following for the design and implementation of quick action commands:

• Provide a default set of system defined quick action command functions that are also available via the keyboard. (See example in Appendix A, Table 2.)

• Provide the ability for users to customize quick action command functions.

• Maintain consistency in quick action command functions throughout the SD.

• Provide a list of all system and user defined quick action command functions in Help.

When deciding which Quick Keys to maintain as keyboard controls, consider ones that are memorable (i.e., there is an intuitive connection between the command and its associated Quick Key) and that do not interfere with common practices (e.g., Ctrl-C for Copy, Ctrl-V for Paste; see also Section 3.5.6 Data Entry Tools).

3.5.6 Data Entry Tools

Smart Fill and Cut-Copy-Paste are industry standard functions that make data entry more efficient for the user. Both features should be implemented in the SD to be used within as well as between applications (wherever the buffered material is compatible).

Smart Fill

Smart fill (or “type-ahead”) fields match user input as they type and display relevant entry suggestions.

This capability is especially useful in:

• Search fields

• Text entry fields, especially for information with a specific search set, such as facility or NAS element

Smart fill should incorporate the following features:

• Dynamic updating: smart fill choices should update automatically based on user input.

• Smart ordering: order smart fill matches starting with the best matched input. (Sometimes it is helpful to prioritize frequently used matches.)

• Autosuggest: displaying a drop-down field of options matching user input.

• Autocomplete: allowing the user to select the best match, typically using the Tab key.

• Flexible search: avoid strict left-to-right matching in some contexts. For example, when a user types “EWR” in an airport field expecting ICAO format, smart fill should find and suggest

“KEWR.”

• Context filtering: limiting suggestions based on context. For example, if the user has selected an airport in another field and is entering a departure fix, limit the search to departure fixes for the selected airport.

Cut-Copy-Paste

Cut-copy-paste allows the user to select and buffer information, then apply that information into another location. This is typically used for text, but also may apply to formatting and to objects (such as images or files).

The SD should provide multiple ways to execute cut, copy and paste including:

• Keyboard commands (typically CTRL-X, CTRL-C, CTRL-V for cut, copy, and paste)

• Right-click menu options

• Window Menu commands when editing is a primary function

• Dedicated keyboard keys or mouse actions

Date and Time Entry

Another way to support users is to give them tools that assist with entering dates and times. The SD should provide controls for date and time entry that are context-appropriate (see Li, 2017):

• Allow users to type the date even when other tools are provided, where appropriate.

• Note: Times should be displayed in hhmm format.

• Do not require special characters in date or time fields.

• Avoid drop-down controls for selecting months, dates, and years.

• Avoid over-reliance on calendar picking widgets. Reserve use of calendar picking widgets for selecting nearby dates or selecting date ranges.

• Provide intelligent default dates and times, where appropriate. For example, consider setting the current date and time as defaults for creating an FEA.

• Only allow the user to select dates and times appropriate for the context. For example, only allow arrival times that come after the departure time.

3.5.7 Prevent / Manage Errors

The design of the SD should include elements that minimize human error under normal, degraded, and off-nominal conditions (HFDS 4.5.1). The SD should be error resistant, incorporating design features that make it difficult for a user to make an error, and error tolerant, with design elements that mitigate the effects of any errors that may occur (HFDS 4.5.4).

• Keep the design simple and present information clearly (HFDS 4.5.3).

• Display confirmations when an action may have significant operational consequences.

• Present confirmations for potentially destructive commands, especially those that may result in a loss of data (HFDS 4.5.5). (For example, when deleting stored files or settings.)

• Incorporate automatic system monitoring capabilities that detect off-nominal events/user actions/entries and notify the user (e.g., notifying the user when a route amendment requires an extreme turn).

• Incorporate automatic validation of user-entered information and notify the user of any errors https://www.nngroup.com/articles/date-input/

(e.g., notifying the user if the system did not recognize a route element before issuing a reroute).

• Detect and report user errors as soon as possible after an entry so that the user can correct them in a timely manner (HFDS 5.6.15.10.1.4; 5.6.15.10.1.17).

• Provide error notifications that clearly explain the nature of the error (See also 3.11 System Messages).

• Design error messages to be brief, specific, and task oriented (HFDS 5.6.15.10.2.9). Use plain language (Loranger, 2017b) and consider the audience when using jargon or technical terms (Moran, 2023).

• Avoid using “hostile patterns” in error prevention: only display error messages after the user makes an error, and reserve error message indication styles for error notifications (Kaplan, 2022).

• Provide the ability for the user to correct the specific error rather than require complete reentry

(HFDS 5.6.15.10.1.6).

• Provide the ability to undo or step back from unintentional commands (HFDS 5.6.15.10.1.14).

3.5.8 Online Help

Help should be provided when a user has difficulty operating the system (HFDS 4.7.1). Online Help is primarily an interactive, context-sensitive source of information that can tell a user what entry to make at the current location in an application, what keystrokes are required, or what steps are required to complete a task. Online Help can also provide documentation and reference information (HFDS 5.6.16.1).

The SD should provide several methods for users to obtain online Help (HFDS 5.6.16.3.9). The TSD, for example, provides access to Help from the Main Menu as well as within each dialog, and via a designated Help key.

When accessed from a specific dialog or function (HFDS 5.6.16.2.15, 5.6.16.4.1), the content displayed should be relevant to that dialog or function. In addition to context-sensitive content, a comprehensive reference manual or user guide should also be available (HFDS 5.6.16.2.4).

The following recommendations provide additional guidance:

• Online Help must always be available (HFDS 5.6.16.1).

• Users should be able to access Help without leaving the dialog they are working in, and easily return to where they were before requesting Help (HFDS 5.6.16.3.1).

• When accessed from within a dialog, the content displayed should be specific to the functions of that dialog.

• Help displays should not obscure the screen or element for which it was requested (HFDS

5.6.16.2.8) and should remain visible on screen until the user chooses to remove it (HFDS 5.6.16.2.9).

• An online index of Help topics should be available (HFDS 5.6.16.6.15).

• Online Help displays should be searchable (HFDS 5.6.16.2.11).

• Help should include basic information likely to be of use to novices.

Online help should be written in a concise, readable manner. Consider the following techniques for writing for an audience of experts (Loranger, 2017a):

• Write according to a user’s perspective.

• Use terminology familiar to the user (Moran, 2023).

• Use concise language.

• Write at a 10th-12th grade reading level.

• Use web formatting techniques to communicate information structure such as hierarchical headlines, bulleted lists (Loranger, 2017a), and use of white space to separate structural elements.

3.6 Use of Color

In general, colors in the SD should follow good aesthetic and perceptual practices for color. This section describes guidelines for palettes in multiple contexts, and for how those palettes should coexist within the SD.

3.6.1 General Color Guidelines

In user interfaces, color serves a dual purpose, simultaneously creating a general aesthetic while also conveying information to the user. The design of the SD should serve these purposes in a visually appealing manner that avoids interfering with the user’s task. For this reason, the design aesthetic should employ color in a way that optimizes legibility and supports the visual hierarchy of information on screen (Gordon, 2021).

• Consider neutral background colors within dialogs and menus (bar graphs, tables, etc.).

• Colors used in window design must not affect legibility.

o “GUI chrome” colors (Nielsen, 2012), colors used as part of the surrounding window design such as tab colors or title bar backgrounds, must be applied in a manner that protects the legibility of text within the window.

• Reserve the use of strong, saturated, or otherwise eye-catching colors for capturing user attention or coding user information (such as communicating a need for user action, flight colors or graph elements).

• Avoid using reserved colors in other contexts.

3.6.2 Color Palettes and Color Sets

For the purposes of this document, we will differentiate between the following kinds of color sets:

Window design / GUI chrome palette: colors used for window design and decoration, such as backgrounds and borders for menus or title bars.

Fixed palette: colors used to convey specific meanings such as weather levels. Colors within fixed palettes have specific RGB or HEX color codes. Appendix A provides the RGB values for the fixed colors that are currently used in the TSD.

Reserved colors: hues used to convey specific meaning but are not specific in terms of tint, shade, or tone, and do not have specific RGB or HEX values. For example, the use of red to signify emergency conditions, or grey text to signify a predeparture flight in a flight list. (See 3.6.2.1 Reserved colors below.)

Customization palette: set of colors selectable by the user. For example, the set of colors used to categorize flight sets or map elements on the TSD Map. (See 3.6.2.2 Color customization.)

https://www.nngroup.com/articles/visual-hierarchy-ux-definition/

Because the SD will display diverse types of information in many contexts, it is important for the available color palettes to coexist in a way that limits potential confusion or distraction.

• Where possible, colors used in window design and customization palettes should be perceptually distinct from colors used within the same context.

• Select reserved colors that are distinct from fixed palette colors that are likely to appear in the same context.

3.6.2.1 Reserved colors

The current system design employs many color conventions unique to TFM operations. These conventions are associated with specific hues but are not specified in strict RGB or HEX terms. For this reason, the developer may be flexible in selecting specific tints, shades, or tones within the described hues. Any changes in these coding schemes should be reviewed and evaluated.

• Reserved colors are based on hues expected by system users. The SD should set specific RGB/HEX values for reserved colors and use them as consistently as possible throughout the SD.

Flight list conventions

For flight lists that provide real-time, detailed per-flight information (about flight status, route information, etc.), use reserved colors to differentiate between:

• Active flights

• Pre-departure flights

• Flights with more than one flight plan/reroute

• Flights requiring attention

See Appendix A for the hues used for flight lists in the current design.

Indication of urgency

Users also expect urgency status indicators (e.g., highlighting, icon color) to follow these color-coding conventions (HFDS 8.6.2.4.3):

• High emergency conditions: red o Poor or emergency conditions o Occurrence of error, failure, or malfunction o Circumstances requiring immediate user action

• Medium emergency conditions: yellow o Marginal or alert conditions o Unexpected delay in system response o Circumstances requiring caution or need to review information

• Safe and satisfactory conditions: green o Monitored system is within tolerance o Satisfactory conditions o User may proceed with an operation or transaction

Other reserved colors

• Model mode indication

• Unknown aircraft/vehicles

• FSM bar chart color schemes

• NAS Monitor active and proposed flights

See Appendix A for the hues used in the current design.

3.6.2.2 Color customization

Wherever possible, the SD should allow users to select colors to differentiate information and adapt the display to their environment.

Currently, users can customize colors of the following display components:

• Flight icons on the map – Users configure flight sets…