# RETURN / 归程

## Design rationale

**The screen helps the wearer decide when to return, what needs attention now, and whether somebody needs their help.** When the wearer cannot operate it, the same instrument must help a crewmate take over. V.05 follows the user's latest request to use the supplied Mars scene with genuinely translucent, blurred glass panels and subtle reflected-light gradients. This explicit request supersedes the earlier no-photographic-background direction. The separate generated suit foreground has been removed; the astronaut already in the scene supplies the central composition. Its decisions remain candidates for human review, not validated flight requirements.

### Make the return decision legible

The normal view gives one number priority: **18 minutes before return is due**. It is an estimate for a decision, not a survival countdown. A segmented budget explains the arithmetic: **18 minutes of work + 28 minutes to return + 12 minutes reserved = 58 limiting usable minutes**. These are fixed mock inputs and a mock reserve rule. Production estimates would need validated resource models, route confidence and mission rules; the prototype establishes none of those.

Raw oxygen, pressure, carbon dioxide, battery and body measurements remain available. An abnormal measurement can override the normal hierarchy. Stale location data removes the actionable return estimate and names the unavailable input, following the distinction between live and stale data in [NASA Crew Interfaces, §10.2.1](https://www.nasa.gov/reference/10-0-crew-interfaces-vol-2/).

The navigation flow is deliberately small: select Return, choose the rover, then view bearing, distance and estimated travel time. Bearing is directional information, not evidence that the ground along that line is safe to traverse. A fixed north reference explains the angle. The abstract wireframe terrain is explicitly schematic: it does not supply live geometry, terrain measurements, obstacle detection or a safe-route claim.

### Keep the glass and the hand predictable

Content uses the long axis of the fixed **2400 × 1080** screen, with four physical buttons on the right edge. This gives the time budget a continuous horizontal structure and leaves each key label beside its hardware position. The display itself is not touch operated. The first three keys normally provide Back, Previous and Next; the fourth names the selected action. Any contextual remapping is visible on the glass.

A critical escalation changes both content and available actions immediately. An ongoing press is cancelled: the user must release and press again before a newly assigned action can fire. This rule addresses a specific failure: a press that began as “Next” must not become a consequential emergency action after the screen changes beneath it.

Rescuer view is entered explicitly. The main content rotates **180°**, and each key label rotates **in its existing position**. The label rail never swaps edges or key order. This is the proposal’s deliberate risk: sharing one device between two readers is valuable, but inverted reading and reaching need direct testing. Wrist pose does not diagnose unconsciousness, and it does not silently rotate the interface.

### Use type and colour as instrument structure

The reference is translated through composition as well as colour. Return timing, resources and the time budget sit to the left of the suit; destination, body measurements and crew status sit to the right. A compact task progression runs underneath. The supplied Mars image is used unchanged as a local source asset, cropped in CSS so its astronaut occupies the open center. It is explicitly labelled an illustrative scene, not a live view. Panels have **17 logical-pixel radii**, directional alpha gradients and **16px backdrop blur with 1.12 saturation**. The pressure callout, menu and overview key rail use 13px, 18px and 22px blur respectively. The same material system now covers caution, wearer critical, handoff, crew critical, recovery and every detail page. Only the semantic caution/critical band remains opaque. These choices address the user’s specific finding that the state screens previously looked like a different product.

UI uses **Avenir Next, PingFang SC, Microsoft YaHei, sans-serif**; measurements use **Avenir Next, PingFang SC, sans-serif** with tabular numeric styling where supported. The previous DIN treatment has been removed. Most overview text and values use regular 400 weight, while selected actions use 500. The **1200 × 540 logical canvas maps 2× to 2400 × 1080 native pixels**. Normal return margin is **106 logical / 212 native pixels**, destination travel time **42 / 84**, navigation bearing **76 / 152**, and Chinese key labels **27 / 54**. Idle margin is **133 / 266** in Chinese and **106 / 212** in English. Auxiliary overview text includes **9–13 / 18–26** values. Current selectors and sizes are recorded in `docs/design-tokens.json`; fonts are not embedded or flight-qualified.

A 6.7-inch diagonal implies approximately **155 × 70 mm** of active display. [NASA Appendix F, §F.5.1](https://www.nasa.gov/reference/appendix-f-vol-2/) specifies **0.25° minimum** uppercase character height, with **0.4° or greater preferred**. At 450 mm, those angles correspond to **1.96 mm/30.37 native pixels** and **3.14 mm/48.58 native pixels** of visible glyph height. **Glyph height is not font size.** Smaller auxiliary text is below the preferred sizing intent; rendered glyphs and Chinese readability remain unvalidated. This is not a claim that all text meets either threshold. The display technology, true physical scale, visor, dust and lighting also require testing.

Warm charcoal **#201B18** surrounds the scene-based interface. The underlying glass token **#28241F** is not the rendered background; current screen text is predominantly **#FFF7EC**, with warm champagne accents. Overview panels layer transparent gradients over **#332C262E**, with a darker **#211F1E66** target-panel base and bright upper edges; low-saturation sage marks nominal state. Day mode brightens the supplied scene and changes the tint gradients while retaining glass across overview, alert and detail screens. It is not one uniform full-screen polarity swap. Values, labels, state and instrument overlays remain editable HTML/CSS/SVG, separate from the scene image. Dark default is an aesthetic choice, not evidence of better physical readability.

Caution yellow and critical red retain their distinct roles. [NASA Appendix F, §F.5.10](https://www.nasa.gov/reference/appendix-f-vol-2/) provides a **6:1** contrast reference, **10:1 preferred**. Current opaque-band calculations give **6.70:1** for critical and **8.49:1** for caution. Pressed ordinary-key text is **5.10:1**, below that reference; pressed action text is **11.72:1**. V.05 overview, alerts, details, selected gradients and the glass key rail have not been exhaustively sampled against every scene pixel. Previous solid-detail or key-rail ratios no longer describe those composed surfaces and are not presented as current readability evidence. RGB arithmetic is not physical validation or compliance. Warnings also use words, symbols and layout.

### Change priorities when conditions change

Always-on idle retains return timing and urgent wearer or crew status. The simulated raise-wrist scenario expands supporting information around the same central judgment. Caution names the problem while preserving task context. Wearer critical preserves the shared scene/glass language while replacing the normal information hierarchy with identity, fault, data age, assistance status and an entry to the applicable approved procedure. A **45 logical-pixel minimum opaque severity band** remains distinct. The key wearer pressure reading and caution margin use **82 logical / 164 native pixels**; associated titles use 32 / 64. Glass panels organize the problem on the left and assistance/procedure status on the right. Critical information never waits for a transition animation. Normal interaction feedback may be brief; reduced-motion settings remove unnecessary movement, and nothing runs as a decorative automatic loop.

Acknowledging an alert, silencing its sound and resolving the fault are distinct states. Acknowledgment cannot restore a normal screen while the dangerous condition persists. Recovery depends on the simulated condition changing in this prototype; real recovery thresholds and required confirmations belong to the mission team.

For a crewmate taking over, the display separates **human-confirmed actions** from **sensor observations** and preserves their timestamps. Neither is silently converted into the other. “Request sent,” delivery and responder acknowledgment are also separate claims; operational support depends on a defined communications protocol. Procedure content is a presentation placeholder, not invented lifesaving guidance. A crew emergency identifies the affected person and location confidence while retaining the wearer’s own limiting condition.

### Kill list

- **No persistent heart-rate waveform.** It consumes the space needed for a return decision without establishing a useful action; the measured value and abnormal state remain accessible.
- **No fabricated digital twin or terrain navigation.** The scene and navigation texture are illustrative. Neither implies live camera imagery, measured equipment geometry, body diagnosis, verified terrain, obstacle clearance or a safe route.
- **No automatic rescuer rotation or unconsciousness inference.** A wrist orientation sensor cannot establish incapacity. Manual entry preserves a predictable frame of reference.
- **No second-by-second survival clock.** Mock inputs cannot support that precision or claim. A minute-based return estimate exposes its budget instead.
- **No false live-camera claim, duplicate foreground or decorative animation loop.** The user-supplied scene is static and clearly illustrative; the former separate suit asset is no longer displayed. No UI is baked into imagery. Critical content arrives immediately, with an opaque severity band and explicit hazard content.

## Process notes

This is an **AI-assisted prototype**, not evidence of a completed human design study. The supplied brief and RETURN concept supplied the direction. AI helped interpret requirements, develop interface details, implement the editable HTML/CSS/JavaScript prototype, draft this rationale and identify edge cases. Desk research, mathematical checks and automated or heuristic inspection are distinct from participant evidence. No interviews, gloved usability sessions, visor tests or forearm photograph were performed. No participant quotation or observed user result is claimed.

**V1 → code and heuristic review → V2:** shared acknowledgment state could leak between events, so acknowledgment now belongs to its event; the caution screen could retain a stale ETA, so it now suppresses that estimate; overlapping key inputs were ambiguous, so they are rejected; the compass arrow lacked a clear reference, so it is now north-referenced; Chinese Back and mission Return were too similar, so K1 uses **后退** and the home action **返程**. These are implementation and review findings, not observed participant behavior.

**Historical V.04 reference revision, 19 September 2026:** the user clarified that matching the palette alone was insufficient. The composition was rebuilt around a central suit, translucent rounded panels and lighter typography while retaining the no-photographic-background requirement. No SpaceX branding, fabricated telemetry or participant results are introduced. **90 software checks passed:** 25 base UI, 13 interaction edge cases, 23 layout/motion, 17 FUI behavior and 12 reference-specific checks. Review found internal panel clipping, which was corrected through spacing and minimum heights and then checked in normal/idle, Chinese/English and stale-data states. A readable mobile summary remains available outside the scaled glass. Desktop, mobile and state screenshots were reviewed, and nine native 2400 × 1080 screens exported. Evidence is recorded in `docs/fui-review.md` and the five `output/*verification.json` files. These are automated and heuristic findings, not human-test results.

**V.05 material revision, 19 September 2026:** the user explicitly supplied and authorized a Mars scene, superseding the prior background restriction, and requested more convincing transparent glass. The source image is copied unchanged; CSS handles cropping, tone and blur. The independent suit foreground was removed to avoid duplicate astronauts. A real 16px backdrop filter, layered alpha gradients and reflected edges replace the nearly opaque V.04 cards. The same glass system was subsequently extended across every alert and detail page after the user identified inconsistent state styling. Nine V.05 native screens have been exported. All 90 software checks passed again on V.05; the updated evidence is recorded in `docs/fui-review.md`. The download ZIP includes editable code, current assets, documentation and the review PDF. Nine full native PNGs remain in the local project rather than being duplicated in that download. Asset provenance is in `docs/mars-scene-asset.md`.

Next, human review should approve the typeface, orientation, alarm hierarchy, reserve policy and communications assumptions. Planned sessions cover actual-size glance reading, four-key navigation, escalation during a held press and rescuer handover. [NASA Spacesuits, §11.2.1](https://www.nasa.gov/reference/11-0-spacesuits-vol-2/) describes dexterity and tactility constraints; ordinary gloves cannot validate pressure-glove operation. The human designer must inspect and be able to defend the work before submitting it.

**Elapsed time:** The historical first checked package took approximately 30 minutes of agent session time, including research, implementation, review and browser/PDF checks. That figure excludes the later visual iterations; no verified duration is recorded here for the FUI revision. These are not human working hours. No participant testing time was spent.

**Delivery:** editable prototype and PDF; a user-requested Sites owner-private deployment is configured and handled by the main workflow. Deployment success and access details are reported there, not assumed in this document. No external application or hiring submission has been sent.