M2M-30040-Rev-A GUI Standard.pdf

M2M-30040

A (Released)

RELEASE DATE: December 20, 2024

Moon to Mars (M2M) Graphical User Interface (GUI) Standard

- Not CUI - Not Export Controlled -

Not Export Controlled: This document has been reviewed for Proprietary, CUI, and Export Control (ITAR/EAR) and has been determined to be non-sensitive. It has been released to the public via the

NASA Scientific and Technical Information (STI) Process DAA 20250008824

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

1 of 51 8/28/25, 11:55 AM

NASA/TP-20250008824

Change History

Revision Status Changes Redlines Approved

Baseline Superseded Change Request ACD- C0025

Initial Baseline TBD

A Released Change Request M2M- C0032

Change Redlines

M2MICB -

12/04/2024

Table of Contents

1.0 - INTRODUCTION

1.1 - Purpose

1.2 - Scope

1.3 - Change Authority/Responsibility

1.4 - Convention and Notation

2.0 - DOCUMENTS

2.1 - Applicable Documents

2.2 - Reference Documents

3.0 - STANDARD

3.1 - General

3.2 - Layout and Appearance

3.3 - Interacting with the Vehicle

3.3.1 - Data Display Characteristics

3.3.2 - Commanding

3.3.3 - System Messages

3.4 - GUI Components

3.4.1 - Text

3.4.2 - Labels

3.4.3 - Menus

3.4.4 - Buttons

3.4.5 - Alphanumeric Inputs

3.4.6 - Numbers

3.4.7 - Icons and Symbols

3.4.8 - Graphs

3.4.9 - Schematics

3.4.10 - Color

3.4.11 - Flashing

3.5 - Special Purpose Elements

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

2 of 51 8/28/25, 11:55 AM

NASA/TP-20250008824

https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalProducts/1898__M2M-30040-Rev-Baseline https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalProducts/1898__M2M-30040-Rev-Baseline https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Changes/418__ACD-C0025 https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Changes/418__ACD-C0025 https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Changes/418__ACD-C0025 https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Changes/418__ACD-C0025 https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalProducts/5167__M2M-30040-Rev-A https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalProducts/5167__M2M-30040-Rev-A https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Changes/784__M2M-C0032 https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Changes/784__M2M-C0032 https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Changes/784__M2M-C0032 https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Changes/784__M2M-C0032 https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalProducts/5167__M2M-30040-Rev-A?Redlines=Show https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalProducts/5167__M2M-30040-Rev-A?Redlines=Show https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalProducts/5167__M2M-30040-Rev-A?Redlines=Show https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalProducts/5167__M2M-30040-Rev-A?Redlines=Show

3.5.1 - Time

3.5.2 - Automation

3.5.3 - Electronic Procedures

3.5.4 - Alerts

A.0 - ACRONYMS AND ABBREVIATIONS

B.0 - GLOSSARY OF TERMS

C.0 - OPEN WORK

D.0 - Payload Mapping Matrix

TABLES

Table 2.1-1: Applicable Documents Table 2.2-1: Reference Documents Table 3.1-1: Maximum System Response Time to Operator Input Table 3.4.10-1: Required Color Usage and Its Meaning Table 3.4.10-2: Recommended Color Usage and Its Meaning Table C-1: To Be Determined Items Table C-2: To Be Resolved Items Table C-3: Forward Work Items

FIGURES

Figure 3.4.2-1: Examples of Horizontal Text (Preferred) and Vertical Text Figure 3.4.9-1: Lines Not Physically Connected Figure 3.4.9-2: Lines Physically Connected

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

3 of 51 8/28/25, 11:55 AM

1.0 - INTRODUCTION

1.1 - Purpose

The Moon to Mars (M2M) Graphical User Interface (GUI) Standards document specifies the standards to be used in the development of GUIs across Artemis. Adherence to this document will help to establish a usable design framework, with consistency for critical components across Artemis. This will promote ease of learning, ease of use, a reduction in operator workload, error reduction, an increase in situation awareness, and improved mission safety. Adherence to this document will also simplify GUI design and increase efficiency of development.

Consistency refers to the level of similarity in visual style and operation within and among different crew interface designs. Systems that have been designed with consistency in mind require less training and feel familiar. The number of different codes and ways of operating are minimized, which reduces cognitive workload and operational errors. Cross-system consistency is achieved by incorporating threads of similarity in key components across designs. Higher levels of consistency across vehicles will decrease the risk of errors, and result in a safer spacecraft environment.

The M2M-40040 Moon to Mars (M2M) Icon and Symbol Library is a complement to this document. Programs may also have more detailed design information in their corresponding As-Built Display Framework type of documents.

1.2 - Scope

The M2M GUI Standard applies to Human-Rated Spaceflight vehicles, Contractor Furnished Equipment (CFE), Government Furnished Equipment (GFE), and items provided by International Partners, including crew operated hardware and software systems for flight and lunar surface operations. This standard applies to displays on fixed units, as well as those on portable computers, including laptops and tablets.

Commercial-off-the-Shelf (COTS) applications that provide vehicle insight or commanding shall adhere to the requirements listed in this document. COTS applications that do not provide vehicle insight or commanding shall provide an assessment of compliance in order to perform a risk assessment of the non-compliant items as well as determine what inconsistencies need to be added to crew training.

This standard is applicable to payloads per Appendix D.

This standard does not currently apply to Augmented Reality (AR) displays. <FWD-30040-005>

This standard is applicable to all M2M programs, including future M2M programs. The Human Landing System (HLS) and Orion programs have approved program level GUI standards that meet the intent of this GUI standard. The HLS-STD-002 with relevant HLS SRD requirements, and Multi-Purpose Crew Vehicle

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

4 of 51 8/28/25, 11:55 AM

(MPCV) 72242, are accepted tailored versions of the M2M GUI Standard and meet the intent of the M2M GUI Standard. This document is not applicable to Space Launch System (SLS) and Exploration Ground Systems (EGS). Other M2M programs are expected to adopt the M2M GUI Standard instead of developing a separate lower-level document. Any deviations or waivers to the requirements of this document should be coordinated with the Interoperability Working Group and approved by the M2M Control Board.

This standard is intended to serve two primary audiences: 1) Designers and developers who will use the standards when providing software user interfaces, and 2) Verification teams who will verify delivered software interfaces against these standards.

1.3 - Change Authority/Responsibility

Proposed changes to this document shall be submitted via a Change Request (CR) to the appropriate Moon to Mars Board for consideration and disposition.

All such requests will adhere to the M2M Configuration Management Change Process documented in M2M-30005, Moon to Mars (M2M) Configuration and Data Management Plan (CDMP).

The appropriate National Aeronautics and Space Administration (NASA) Office of Primary Responsibility (OPR) identified for this document is the Interoperability Working Group under the M2M SE&I Systems Integration and Test (SIT) Team.

1.4 - Convention and Notation

The convention used in this document that indicates requirements, goals, and statements of facts is as follows:

"Shall" -- Used to indicate a requirement that must be implemented and its implementation verified;

"Should" -- Used to indicate a goal that the designer is expected to follow if possible, but that is not formally verified;

"Will" -- Used to indicate a statement of fact and is not verified.

When “or” is used in a requirement, at least one of the alternatives must be met, but up to all of the choices may be used. In the absence of other limiting language, the use of “or” in the requirement language is not meant to exclude more than one option being chosen.

In the cases where the values of quantities, or other information, included in this document have not been determined, these values are designated as "to be resolved" (TBR) when the approximate value is known; or "to be determined" (TBD), when no value is yet known. Forward Work (FWD) items are identified as items that have not yet been completed. TBD, TBR, and FWD items are summarized in Open Work tables in Appendix C.

Requirements marked with “*” are requirements that are outside the scope of GUI and are more system level requirements. It is forward work <FWD-30040-013> to work with M2M to move these requirements out of the M2M GUI Standard and into a more appropriate M2M level document.

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

5 of 51 8/28/25, 11:55 AM

2.0 - DOCUMENTS

2.1 - Applicable Documents

Applicable documents are directly related to this document and cited within. The context and how to apply the applicable documents will be included as part of the document citation.

Table 2.1-1: Applicable Documents

2.2 - Reference Documents

A reference document is a document that provides additional information for the reader and may or may not be cited in this document.

Table 2.2-1: Reference Documents

Document Number

Document Revision

Document Title

M2M-40040 Current Revision

Moon to Mars (M2M) Artemis Icon and Symbol Library

M2M-30005 Current Revision

Moon to Mars (M2M) Configuration and Data Management Plan

Document Number

Document Revision

Document Title

MIL-

STD-1472

Current Revision

Department of Defense Design Criteria Standard: Human Engineering

NUREG-0700 Current Revision

Human-System Interface Design Review Guidelines

HF-STD-001 Current Revision

Human Factors Design Standard (HFDS)

NASA/

SP-2010-3407

Current Revision

Human Integration Design Handbook (HIDH)

NASA-

STD-3001

Current Revision

NASA Spaceflight Human System Standard

ISO/IEC JTC

1/SC 29

Current Revision

Coding of audio, picture, multimedia and hypermedia information

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

6 of 51 8/28/25, 11:55 AM

3.0 - STANDARD

The following requirements and goals are to be applied in conjunction with Artemis Program-specific requirements.

3.1 - General

a. The amount of information displayed should be limited to what is needed to perform required tasks.

Rationale: Displays that are too dense with information are perceived as “cluttered”, and can be overwhelming and difficult to use because every data item is drawing attention. Visual search for a desired item within a dense display takes additional time and is more error prone, which can impact situation awareness and decision making.

b. A GUI should provide the information needed to perform the task at hand without requiring the operator to navigate to additional GUIs.

Rationale: When there is a need to access information distributed across multiple GUIs to perform a task, the risks of errors and increased task times are higher. Use of a good task analysis will help ensure that the necessary information for performing a task is available on one GUI.

c. Vertical scrolling should be limited to procedures or lists.

Rationale: When displays or images require vertical scrolling, operators must make repeated clicks/ interactions on the display, and are prevented from seeing the entire display/image at once. For this reason, vertical scrolling should be limited to GUI components that are typically used in a top-to-bottom

IEC TC 100 Current Revision

Audio, video and multimedia systems and equipment

IEC TC 110 Current Revision

Electronic displays

MPCV 72524 Current Revision

Cross Program Operations Nomenclature (Op Nom) Plan

GP 10116 Current Revision

Gateway Operations Nomenclature Plan

M2M 30050 Draft Artemis Operations Nomenclature Plan

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

7 of 51 8/28/25, 11:55 AM serial fashion, such as procedures or lists.

d. Horizontal scrolling should be avoided.

Rationale: When displays or images require horizontal scrolling, operators must make repeated clicks/ interactions on the display, and are prevented from seeing the entire display/image at once. Horizontal scrolling presents only a single section of characters or words at a time, and therefore does not provide the same level of context that vertical scrolling provides. Vertical scrolling is the navigational norm, and is highly practiced by operators; whereas, horizontal scrolling is not. The extra effort to get the context can be fatiguing and very frustrating. For this reason, horizontal scrolling should be avoided unless absolutely necessary.

e. Information shall be presented in a directly usable form that does not require mental transposition or computation by the operator.

Rationale: Overtaxing operators in extreme environments can lead to errors. Information should be presented in the most easily digestible form possible. It should be pre-processed, pre-calculated, and correctly formatted so that perception and understanding can be achieved as quickly as possible. This leaves more cognitive resources available for critical tasks such as monitoring and problem solving.

f. Each GUI within a predefined suite (i.e., set of related GUIs) should have consistency with other formats in the suite regarding the appearance, location, and interaction style of common elements.

Rationale: Consistent appearance, location, and interaction style of common elements makes an operator’s interaction with a GUI predictable, and aids rapid understanding. This helps reduce training time and errors.

g*. Modes (e.g., test mode, edit mode) in the interface should be used sparingly.

Rationale: Mode errors are some of the most frequent and frustrating types of errors. A system that contains multiple modes requires an operator to have a more complex mental model of how the system works (i.e., an operator must know what can or cannot be done in a particular mode), and there is often inadequate visual indication of the mode. This can result in errors or confusion about inputs that do not result in the expected action due to the current mode.

h. Operator actions that are irreversible (e.g., could result in the loss of data) shall be safeguarded via confirmation dialog boxes or the equivalent (i.e., two (2) independent operator actions).

Rationale: Operators can accidentally bump a touchscreen, keyboard, or input device, especially in a microgravity environment. These unintended actions can result in sent commands that can cause hazardous situations or data loss. Therefore, any commands that are irreversible are to be safeguarded by requiring more than one operator action (e.g., selecting a command to send, and then receiving a confirmation dialog box that requires another response – Are you sure you want to delete all files?). If operator actions are reversible, the capability for the operator to “undo” the action is recommended.

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

8 of 51 8/28/25, 11:55 AM

i. Payloads including hand-held devices shall adhere to the requirements listed in this document in accordance with Appendix D.

Rationale: Payloads and hand-held devices often have unique, custom components and use cases;

thus, not all GUI standards will apply. The applicable subset is shown in Appendix D.

j*. The system shall provide feedback to the operator input in accordance with the system response times in Table 3.1-1: Maximum System Response Time to Operator Input.

Rationale: A positive indication of control activation is used to acknowledge the system response to the control action. For example, a physical detent, an audible click, an integral light, or a switch position may be used to provide a positive indication of control activation. Timely feedback to operator inputs is critical for the operator to feel they are interacting with a responsive system. Slow response times can result in redundant inputs to the system, which can add to operator confusion and errors. A response time of 0.1s gives the feeling of instantaneous response, and a response time of 1.0 s keeps the user’s flow of thought seamless. This requirement is about system response time to operator inputs and not data update rates.

Table 3.1-1: Maximum System Response Time to Operator Input

System Response Example Maximum Time (s)**

Continuous input: cursor and onscreen dynamic elements

Cursor and symbol motion 0.07 (15 Hz)***

Discrete input: Indication of a visual, auditory, or tactile discrete input

Onscreen keystroke echo;

click or beep; detent/physical feedback

0.1

Update to local element Display of popup menu 0.5

Display of a requested GUI Calling up a new display or display component

1.0

Display of updated data on operator command of a state change

Status of “on” when commanded on; status of “open” when commanded open

1.0

Feedback for commands that cannot be completed within 1 second:

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

9 of 51 8/28/25, 11:55 AM

**System response time variability with respect to mean response time shall be ≤5%. Note that systems with “short time to effect” scenarios may require faster response times.

***Polling rate, DPI, and screen refresh rate are factors that affect cursor and screen dynamic elements

3.2 - Layout and Appearance

a. Layout of information on a GUI should support task flow (e.g., left-to-right or top-to-bottom orientation aligned with procedure flow, or located according to architecture).

Rationale: Presenting information in a common, predictable visual scan pattern (e.g., left-to-right or top-to-bottom) helps support task flow by allowing an operator to work through a task efficiently. Locating information near relevant components (e.g., in a graphic or diagram) reinforces their relatedness and reduces visual search.

b. Recurring data fields should be displayed in consistent relative positions across formats.

Rationale: Consistent locations of recurrent data fields across various displays makes the locations predictable and reduces the need to visually scan and search the display. For example, if multiple displays in a suite (e.g., Environment Control Life Support System (ECLSS) display suite) contain the same data field, positioning the data field in a consistent relative position allows an operator to quickly identify it.

c. GUI elements to be used together should be grouped in close proximity on the screen.

Rationale: When elements are shown in close proximity, they are perceived as a visual group, which reinforces the idea that the elements are related. Grouping related items together on a display reduces visual search and navigation, making operations more efficient. For example, a display may contain data, information, and controls associated with troubleshooting. Locating these in close proximity forms a visual group, making troubleshooting operations more efficient.

d. A grouping of related characters (e.g., letters, numbers, and symbols) should be visually separated from other groupings, or from graphical or virtual borders.

Rationale: Visual groupings on a display facilitates understanding (i.e., what belongs together) and efficient use of the information (i.e., reduced visual search and navigation, and increased legibility). For groups to be perceived as distinct, there must be graphical borders or sufficient space between them.

1. Indication that a command or process is in progress

2. Status of the command/ process after request completed

1. A progress bar showing time remaining or a progress message.

2. After request is completed – status message of success/ fail/unknown

1.0

1.0

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

10 of 51 8/28/25, 11:55 AM

e. The primary GUI navigation menu bar shall be located at either the top or bottom of each GUI.

Rationale: Placing the navigation menu at the top or bottom of an interface is the standard model for many common commercial applications (e.g., Windows Start menu at the bottom, Google Chrome menu bar at the top), and is consistent with other Artemis vehicles. This standard refers specifically to the primary navigation menu bar (point of entry to the menu), rather than all menu bars. This does not preclude applications where navigation menu bars are at the top and bottom.

f. All GUIs shall have a common dedicated area for the display of key information to be visible at all times (e.g., time, system messages, alerts, communication status: Loss of Signal (LOS)/Acquisition of Signal

(AOS)).

Rationale: The ability to quickly scan, locate, and comprehend key information relevant across displays will increase system operability and usability. Each program must decide what information needs to be visible at all times (versus on request). Programs should select content carefully to avoid clutter that can draw attention away from the most important information in this area.

g. Each GUI shall have a unique title in a consistent location that is visible at all times.

Rationale: Providing a unique title helps operators distinguish between GUIs. Presenting the unique title in a consistent, always visible location allows operators to maintain situation awareness of the GUI they are currently using.

h. When more information is available for display than can be shown (e.g., multiple pages, or multiple items in a scrollable list), the system shall provide an indication of the portion being viewed, and the total amount of information.

Rationale: Operators need awareness of where they are in a hierarchy or list, and the total amount of information that can be viewed. For example, there may be multiple pages of relevant information, or a long list of items that cannot be displayed due to limited real estate. The system is to provide an indication regarding what portion is being viewed, and the total amount available for viewing. This can be accomplished via text: "Page 4/59", "9/12 messages", scroll bar location and height, or other methods.

i. Elements that are selectable (e.g., buttons, menu options), elements that are static (e.g., labels), elements for embedded navigation, and elements designed for alphanumeric input (e.g., data entry fields) shall be visually distinct from one another.

Rationale: A GUI can contain several types of elements. Providing a visual distinction between elements that are selectable, static, embedded for navigation, and designed for alphanumeric input improves the identification and interpretation of an element (i.e., it helps an operator know how they are going to interact with the element).

j. GUIs for different modes of operation (e.g., test/sim mode vs. flight/mission mode) shall be visually distinct.

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

11 of 51 8/28/25, 11:55 AM

Rationale: Modes define sets of mutually exclusive behaviors that determine the way in which functions are performed. A system can have multiple modes but only one is typically active at a time. When modes are not clearly distinguished, there is a high risk of errors. For example, when different modes for a single GUI are not sufficiently visually distinct, operators can unintentionally and unknowingly interact with a live system, rather than a test system, with potentially dangerous consequences (NASA Lesson Learned).

3.3 - Interacting with the Vehicle

3.3.1 - Data Display Characteristics

a. If a GUI element has states or modes, the current state shall be indicated.

Rationale: States or modes define sets of mutually exclusive behaviors that determine the way in which functions are performed. Providing an indication of the state or mode of the GUI element helps operators quickly understand the operational situation, and the interactions that are possible, which can reduce confusion and errors. If there is a clear nominal mode or state (e.g. all data on a display is nominal), no special indication is needed.

b. Graphical elements should indicate operational limits.

Rationale: Indicating operational limits on graphical elements (e.g. yellow and red lines on a meter) provides situation awareness regarding the current state and distance from the actual operational limit.

c. There shall be an indication when data are stale and / or missing.

Rationale: Feedback that data are stale or missing is important for the crew’s accurate assessment of data during troubleshooting and decision-making periods. Typically, cyan colored "m”s are used across the Artemis displays to indicate a missing data element.

d. A yellow or red up or down arrow following a digital value shall be used to indicate that value is outside of upper or lower thresholds that trigger a Caution or Warning alarm.

Rationale: The ability to view the pattern of out-of-threshold values in a system summary display provides more troubleshooting information than an alert message alone. If necessary, a black arrow on a yellow background or a white arrow on a red background may be substituted to achieve contrast or draw extra attention. Nominally, colors shall be selected to meet proper contrast (see 3.4.10 f.).

e. The system shall provide indication that a value is offscale high or low when that information is necessary to address a malfunction.

Rationale: Off-scale high or low values can indicate a sensor problem, and can signal an issue that may or may not be serious. When an offscale value is needed to address a malfunction, the system is to provide an indicator next to the value (e.g., “H” for high and “L” for low).

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

12 of 51 8/28/25, 11:55 AM

f. Digital data fields should have sufficient fixed placeholder width to show the longest possible value, including the size of any data quality indicators.

Rationale: Digital values can vary in length, and can have associated data quality indicators (e.g., yellow/red up or down arrows to indicate a caution/warning threshold has been reached). The ability to view complete, non-truncated information is important for context, and for making informed decisions.

g. When text data overflow occurs, each character of the entire field shall be replaced by yellow asterisks.

Rationale: Providing a visual indication that a text data field overflow has occurred helps operators understand the value is larger than the system can display. This prevents them from using the values when making decisions, which can reduce errors. Yellow asterisks are typically used across the Artemis displays to indicate an overflow has occurred.

h. When numeric data overflow occurs, each character of the entire field shall be replaced by yellow asterisks, except for the signed field and the decimal point.

Rationale: Providing a visual indication that a numeric data field overflow has occurred helps operators understand the value is larger than the system can display. This prevents them from using the values when making decisions, which can reduce errors. Yellow asterisks are typically used across the Artemis displays to indicate an overflow has occurred.

i. Alphanumeric data values shall be updated no more often than 1 Hertz.

Rationale: Although high data update rates may be desirable, values to be read by the operator that update at high rates may be difficult to read. A rate of 1 Hertz or less ensures values will be readable.

j. Numeric data that changes consecutively shall be updated no more often than 2 Hertz.

Rationale: Numeric data values that increment or decrement consecutively are predictable and can be perceived at a slightly higher rate than alphanumerics that must be read. An example of this type of data is Pitch/Yaw/Roll on a manual control display.

k. Data update rates for graphical elements used in direct manual control tasks (such as attitude, engine parameters, etc.) shall be equal to or greater than 15 Hertz.

Rationale: When graphical data update rates are too slow (e.g. for direct manual control tasks), the features on the display will exhibit jitter, jerkiness, or ratcheting effects, which can be distracting and impact manual control performance.

l. The GUI shall indicate violations of operational limits.

Rationale: Operators need to know when an operational limit has been exceeded (e.g. a meter that changes color after exceeding an operational limit) so that they can understand the system state, and

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

13 of 51 8/28/25, 11:55 AM know where to begin troubleshooting.

3.3.2 - Commanding

a. Commanding should be accomplished via a “Command Popup” (popup menu) to minimize operator memory load and number of actions. (See Appendix B Glossary of Terms for description of Command Popup).

Rationale: Popup menus are advantageous for commanding in two ways. Menus, as opposed to free-form typed entries, allow operators to use recognition instead of recall (memory) to send a command – increasing efficiency and reducing errors. Popup menus, by design, provide a multi-step command sequence, (open the menu, make selection, and send), which prevents accidental actuation that can happen with a single action button.

b. Command Popups shall contain a unique title, options list, indication of current selection, and indication of the option to be selected.

Rationale: Unique menu names are important to help prevent selection of the wrong command. An options list, indication of current selection and indication of the option to be selected are standard design features that help communicate the current status of the system command and ensure usability of the popup menu.

c. The system shall require at least 2 independent actions to activate/execute mission critical and safety critical controls.

Rationale: Controls that can result in hazardous consequences must be safeguarded against accidental actuation. Requiring two independent operator actions reduces the risk that the control was actuated by an accidental bump or by mistake.

d. Commands with an arm control shall be accompanied by a safe control (that removes the armed condition) located to the right or beneath the arm control.

Rationale: Some hazardous operations with irreversible actions (e.g., pyrotechnics) require a specific set of commands to be sent in sequence (i.e., arm and then fire). If a command requires an arm/fire sequence, there must be a control to put the system back into a safe state (i.e., to disarm it). The control is to be labeled “safe” and be located near the arm control.

e. Commands that change vehicle state shall provide feedback (e.g., displayed value change, message indicating completed, running, failed, or unknown) that indicates the command is in progress and has successfully completed or has failed.

Rationale: To maintain safe mission operations and to provide needed situation awareness to the operator, there must be visibility into the system. Operators need to know if a vehicle state change has occurred as a result of their command, or whether the command has failed. Lack of this information can result in operators performing repetitive navigation to determine the state or the submittal of repeated

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

14 of 51 8/28/25, 11:55 AM commands, which could result in unsafe operations.

f. Command names for different commands shall be distinguishable from one another.

Rationale: When command names are similar, there is a higher risk of selecting the wrong command, which could result in unsafe operations. Using distinct command names can help operators distinguish between and send intended commands.

g. If command operations have counterparts, congruent pairs of command names shall be used in a consistent order (e.g., on/off, enable/inhibit, yes/no, open/close, high/low, Max/Min, Auto/Man).

Rationale: Use of a standard pair of command names in a consistent order throughout the system makes the commands easy to learn and remember, which decreases confusion and chances of errors.

h. Commands that are irreversible or hazardous should include a black and yellow diagonally striped border (i.e. hazard tape).

Rationale: Striped borders around hazardous controls have been used in aircraft and other safety-critical machinery for decades. The crosshatch pattern catches the eye, causes a visual pause, and reminds operators that this control is to be approached with caution. Sparingly used striped borders around hazardous commands serve the same purpose in vehicle/habitat displays.

i. Controls that are used to send commands to change vehicle state shall be visually distinct from other controls.

Rationale: Foreknowledge that a button press could result in a change to the vehicle state will prompt the operator to slow down and proceed carefully, as compared to a control, such as a display view setting or timer that will simply affect what is shown on the display. This distinction contributes to a safer crew interface.

3.3.3 - System Messages

a. Status and error messages shall be displayed in a consistent, designated location.

Rationale: A status message conveys the state of a component or system (e.g., low battery - charging required, automation disengaged). An error message conveys an unintended outcome or a failure to perform an action (e.g., wrong syntax, wrong order of operations, time expired/failure to act). A consistent, designated location for these messages, determined by the type of message, makes the location predictable and reduces the need to visually scan and search for the message.

b. Status and error messages should contain the information necessary for situation awareness, to make a decision, or complete the related action.

Rationale: Providing sufficient detail in status and error messages helps operators understand the state

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

15 of 51 8/28/25, 11:55 AM of the vehicle, which reduces the time and effort it takes to make an informed response or take action.

For example, a message that says, “Command Sent” is not as informative as one that says, “CO2 Scrubber Resuming”.

c. Error messages should convey what is wrong, what corrective actions can be taken, and what caused the error.

Rationale: Providing sufficient information for error messages can help operators understand the error, where it originated from, and how to resolve it quickly. For example, “Invalid input.” alone does not provide enough detail to understand why the input is invalid and what to do next; whereas, “Input invalid. This field requires numerical values.” describes the error and provides guidance for what to do next.

d*. Stored data should be searchable to assist in anomaly resolution.

Rationale: Providing a search capability greatly increases efficiency and anomaly response time for the operator, versus requiring the operator to visually search for needed information manually.

e. Popup messages should be able to be moved/cleared by the operator, or cleared automatically.

Rationale: Popup messages can obstruct areas of a display that are needed by operators (e.g., data or status fields) to confirm an action is in progress, has completed, or has failed. Operators should have the capability to manually close the popup, or the popup should close automatically (i.e., after a command has been sent).

3.4 - GUI Components

3.4.1 - Text

a. Text should use the American Standard Code for Information Interchange (ASCII) character set.

Rationale: ASCII is the most common character set for human-computer interfaces, and includes letters, numerals, basic punctuation symbols, and other characters. Using this character set allows operators to quickly recognize and understand the system, and it promotes commonality with the majority of other systems.

b. A sans serif font should be used.

Rationale: Sans serifed fonts, or fonts without strokes at the end of letterforms, are perceived to be minimal and clean, which can lead to less distraction and an increase in legibility.

c. The font shall allow discrimination of similar characters (e.g., letter l/number 1; letter O/number 0).

Rationale: Fonts with confusable characters can lead to prolonged task times and errors. Operators

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

16 of 51 8/28/25, 11:55 AM need to be able to discriminate between similar characters to perform a task effectively and efficiently.

d. A fixed-width font shall be used on numerical and tabular data.

Rationale: Fixed-width fonts contain characters that take up the same amount of horizontal space.

These fonts create a consistent, visual alignment of numerical and tabular data, making it easier to focus on individual characters. This allows operators to scan and comprehend dynamic data more efficiently.

e. A proportional font shall be used for content that is narrative.

Rationale: Proportional fonts contain characters that take up only the amount of horizontal space needed. These fonts are commonly used for content that is static, like electronic crew procedures, and make it easier to focus on whole words rather than individual characters. This allows operators to read static text more efficiently.

f. The system should provide an optical zoom function that allows an area within the GUI to be temporarily magnified.

Rationale: Optical zoom allows for easier reading of small text, or closer inspection of small icons or areas within a schematic. This capability can be particularly useful for operators experiencing changes in vision due to aging (presbyopia) or spaceflight associated neuro-ocular syndrome (SANS). It can also be useful for viewing critical information under vibration, or for viewing portions of the screen (e.g., clock) while working a distance away from the display. When implementing optical zoom, consider that a display left in a zoomed state can be disorienting, since the overall layout is changed, and elements of the display may be occluded.

g. Character height shall subtend a minimum angle of 0.4 deg at the design eyepoint, preferably larger if the text may be used when vibration amplitudes exceed 0.3g.

Rationale: Text size needs to be large enough for operators to accurately read under expected spaceflight conditions. Font height in degrees refers to the angle subtended at the eye by the height of an uppercase letter in the font. For example: 0.25 deg is 10-point type at 32 inches viewing distance.

The font may need to be larger when taking into account flight and operator conditions. For more information about calculating/selecting font size, refer to the Human Integration Design Handbook

(NASA/SP-2010-3407).

h. Non-acronym text shall be mixed case (i.e., uppercase and lowercase letters).

Rationale: Mixed case text is generally easier and faster to read than uppercase, which is the standard for acronyms.

i. Acronyms and abbreviations shall be as specified in the <TBD-30040-006> Operations Nomenclature Plan.

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

17 of 51 8/28/25, 11:55 AM

Rationale: Using acronyms and abbreviations defined in the <TBD-30040-006> Operations Nomenclature Plan promotes consistency across Artemis vehicles and habitats. A common nomenclature reduces operator confusion and risk of errors.

3.4.2 - Labels

a. Labels should be shown with data fields.

Rationale: Data shown without labels are subject to misinterpretation, resulting in errors. This is a particular risk in Artemis, since crew will routinely move among different vehicles, habitats, or rovers that will have different display designs. Even if crew is well-trained on a display, emergency situations can result in cognitive overload and stress, leading to confusion or a lapse of memory. Labels that clearly identify the data make the vehicle/habitat interface safer.

b. The wording and grammatical structure of labels should be consistent throughout a GUI.

Rationale: When labels follow a consistent pattern in terms of wording and grammatical structure, they are easier and faster to process, and the operator is less prone to error.

c. Labels should be shown in horizontal orientation.

Rationale: Labels are easier and faster to read when presented horizontally, in a left-to-right reading orientation, as compared to other orientations (e.g., vertical).

d. Data field labels shall appear to the left of data values, or above data values when data are in a columnar format.

Rationale: Labels are easier and faster to read when presented in a left-to-right or top to bottom reading orientation with respect to the values.

e. When vertical orientation of labels is necessary, labels shall be rotated counter-clockwise (see Figure 3.4.2-1).

Figure 3.4.2-1: Examples of

Horizontal Text (Preferred) and

Vertical Text

Rationale: If vertical orientation is required due to space limitations, the standard for graphs is adopted, which is counterclockwise rotation. These types of labels are easier and faster to read than marquee style labels, where individual letters are rotated versus the entire word.

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

18 of 51 8/28/25, 11:55 AM

3.4.3 - Menus

a. Popup and drop down menus should appear near components related to the menu selections.

Rationale: The Gestalt principle of proximity states that elements that are close together are perceived as more related than elements that are further apart. Clarity in the relationship between a menu and associated components is important to avoid confusion and errors.

b. Popup and drop down menus shall not cover critical information or information needed to perform the task.

Rationale: Covering up safety-critical information with a popup could result in a safety hazard (e.g., failure to see that a fault has occurred). Covering up information needed to perform a task could require memory and repetitive navigation (i.e., the need to close the popup, view and memorize what is underneath, and then reopen it). This can lead to wasted time and frustration.

c. Information should be no more than 4 levels deep (i.e., no more than 4 actions to access).

Rationale: While layering of information is important for managing clutter and information overload, incorporating too many layers prevents timely access to needed information. Excessive clicks are generally frustrating to operators.

d. Menu items should be listed in an order based on sequence of operations, urgency, functionality, or frequency of use. If no basis for menu item order exists, items should be listed in alphabetical order.

Rationale: Providing a logical, meaningful order of options in a menu can help the operator build or reinforce a mental model of the system (e.g., this is done before that; this is more important than that). It can also speed selection when more frequent options are at the top or when order follows the well-learned alphabet.

3.4.4 - Buttons

a. Soft buttons (virtual buttons) shall have labels on the button surface.

Rationale: Controls, such as buttons, need to be clearly identified to avoid confusion about their function. Labels located on the button will be intuitively associated with the button according to the Gestalt law of proximity.

b. Buttons shall have labels that are visible in all states.

Rationale: Operators must have adequate situation awareness regarding system functionality; thus, button labels are to be visible at all times. When button functions are unavailable or inappropriate in certain conditions, the label may be coded as such through colors and shading (e.g., using gray shading to indicate unavailable). However, the label is to be readable in all states to inform/remind the operator that the function exists.

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

19 of 51 8/28/25, 11:55 AM

c. Buttons shall change appearance when actuated.

Rationale: A positive indication of control actuation is important to communicate to the operator that the button has been actuated. When there is no feedback (i.e., no change in appearance), buttons are often pushed repeatedly since it is not clear if the button is functional. Repeated button pushes can unintentionally send multiple commands, which can have undesirable or hazardous consequences.

d. A grouping of related buttons should be visually separated from other groupings, or from graphical or virtual borders.

Rationale: The Gestalt law of proximity states that objects in close proximity are perceived as related to one another. Creating visual groups by separating information with graphical borders (e.g., lines, boxes) or virtual borders (e.g., space), pre-organizes objects into groups that have related purposes or functions, making it easier for operators to comprehend.

e. Edge keys (physical buttons on a display unit) shall have virtual labels placed adjacent to the physical button on the GUI if the physical button surface doesn’t have a label.

Rationale: Controls, such as buttons, need to be clearly identified to avoid confusion about their function. Labels located on the button and/or adjacent to the physical button on the GUI will be intuitively associated with the button according to the Gestalt law of proximity.

3.4.5 - Alphanumeric Inputs

a. When a specific data entry format is required, format cues shall be provided (e.g., mm/dd/yyyy).

Rationale: Format cues, or placeholder text, are used to describe the expected value for an input field.

These hints can help operators quickly understand what specific data should be entered into an input field, which can prevent incorrect entries, errors, and rework.

b. The system shall provide an indication when the operator inputs invalid entries.

Rationale: Input validation assesses the accuracy and reliability of the entry. It prevents errors from occurring within the system by stopping and requesting correction before transmitting the entry for execution.

c. Text within data entry fields shall be left aligned.

Rationale: Text that is left aligned follows a common, predictable visual scan pattern (e.g., left-to-right reading), which helps support task flow by allowing an operator to work through a task efficiently.

d. Text data entry fields shall be of sufficient width to show the longest possible word.

Rationale: The ability to view complete, non-truncated text inputs is important for self-checking the

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

20 of 51 8/28/25, 11:55 AM accuracy of what has been entered. The data entry field width should be sufficient to provide operators with the appropriate context.

e. Numbers within data entry fields should be right aligned.

Rationale: Aligning numeric data to the right helps operators make comparisons between data fields more efficiently.

f. Numeric data entry fields should be of sufficient width to show the longest possible value.

Rationale: The ability to view complete, non-truncated numeric inputs is important for self-checking the accuracy of what has been entered. The width should be sufficient to provide operators with the appropriate context (e.g., yellow/red up or down arrows to indicate a caution/warning threshold has been reached).

3.4.6 - Numbers

a. Values for the same type of parameters shall be shown in the same units.

Rationale: Using different units of measure for the same parameters shown on the same or related displays can cause confusion and lead to errors. Displaying consistent units allows an operator to interpret values and make direct comparisons between values more efficiently.

b. Units of measure shall be displayed for each numeric value or for each group of numeric values where the units are the same.

Rationale: When units of measure are not displayed, but are left up to operator memory or assumption, hazardous consequences can result. In 1999, the unmanned Mars Climate Orbiter disintegrated on approach to Mars due to navigational errors arising from lack of awareness that two different units of measure were being used.

c. The number of decimal places shown shall be the number required by operators to perform the associated task.

Rationale: If the number of digits beyond the decimal place is too few or too many, accuracy in performing the task will be put at risk. While computers can provide many decimal places of accuracy, the cognitive workload required by an operator to interpret the numbers is increased when an excessive number of digits is shown beyond the decimal point. This can lead to misreading values and errors in rounding.

d. Where numeric data is presented as a vertical group, the decimals should be vertically aligned.

Rationale: Numbers presented in a fixed-width font and grouped vertically create a consistent, visual alignment of data, making it easier to focus on individual digits. Aligning visible and implied decimals

Firefox https://moon2mars.ndc.nasa.gov/cmw/app/main.aspx/Baseline/DigitalP...

21 of 51 8/28/25, 11:55 AM allows an operator to quickly scan and compare multiple numeric values.

e. Where numeric data is presented as a vertical group, whole numbers should be vertically aligned with the implied decimal place.

Rationale: Numbers presented in a fixed-width font and grouped vertically create a consistent, visual alignment of data, making it easier to focus on individual digits. Aligning visible and implied decimals allows an operator to quickly scan and compare multiple numeric values.

f. Numbers that have absolute values less than 1 shall be displayed with a leading zero prior to the decimal point (e.g., 0.25 rather than .25).

Rationale: Decimal points are small and can be overlooked or confused with punctuation marks (e.g., period, comma). Presenting numbers with a zero prior to the decimal point can help an operator identify decimal values more accurately.

g. Numbers that have…