User experience and interface

The cockpit, the two maps, the visor, and the first hour.

Pillar 4 constrains this page more than any other. Every interface element must have an answer to "where is this displayed, physically?" An element that cannot answer is either drawn on a surface in the world, or it does not exist.

The application shell

⚠️ Read this first. Everything below describes the interfaces inside a flight session. Around them is a shell — a front door, five modes, and a set of dialogs — and the two are shaped by different rules. The cockpit's rule is pillar 4: every element has a physical place. The shell's rule is that it is a website, and a website's affordances are the browser's.

✅ Built. ADR-0011 holds the engineering argument.

The routes

The URL is the product's public surface. Everything a person might want to send someone is addressable, and nothing addressable is reachable only by clicking.

A mode decides what owns the camera. A dialog opens over whichever mode is running and leaves it running — which is the same promise this page already made about settings, generalized: the simulation keeps running.

The scene is never a loading screen. The menu is drawn over the real engine, framed on Earth and slowly drifting. That is the one claim about this project a screenshot cannot fake, and it is worth four lines of camera code to make it the first thing anyone sees.

The account routes are reserved, not pretend

They exist now because two of the three are expensive to add later: a redirect URI is registered with an identity provider ahead of time, and a service worker precaches a route list. What they must not do is look real. No page in this build renders a credential field that goes nowhere — people reuse passwords, and a form that looks real is one they will type a real one into.

The debug overlay

The dev dock — controls, telemetry, performance, graphics — is the author's instrument and is off by default, toggled by ` or the shell bar. A first-time visitor should never meet it; nothing on this page describes it, and the cockpit it will eventually be replaced by is specified below.

Two things are deliberately not behind it. Going somewhere is the Catalog, a panel of the product's own that both the planetarium and the flight workspace carry, because a navigator filed under the author's scaffolding is a navigator a player never finds. The camera is a planetarium panel, because the aperture and the focus belong to the mode whose entire subject is looking. ADR-0018.

Dockable panels

A tool mode is made of panels, and a panel belongs where the person using it wants it. Four zones — left, right, floating, and closed — and a panel moves between them by dragging its header. Closed and floating are places a panel is rather than absences, which is what lets the arrangement be a census: every panel in exactly one zone, exactly once. ADR-0012 has the mechanism; the design rules are three:

• The middle of the frame is never covered by default. Two panes at the edges and a menu at the bottom center; the thing being looked at is the content. A panel reaches the floating zone only by being released over the scene, which is a deliberate act with a visible cost, and it says so with the second elevation step.
• Closing is a move, not a deletion. A launcher rail is always on screen, so a closed panel always has a way back.
• A phone gets the same panels. The zones stop being read and the set becomes a bottom sheet with a tab strip; the arrangement survives the round trip.

Mobile

⬜ Piloting on a touchscreen is not designed. ✅ Looking is.

The planetarium and the cinema player work on a phone today: one finger orbits, two pinch, a tap focuses, and the composed shots carry the framings a keyboard would otherwise reach. Flight modes are desktop-only until there is a touch control scheme worth shipping, and the menu says which is which rather than letting someone find out.

The screen inventory

There are seven interfaces in the entire game, and only two of them take over the view.

There is no pause menu that stops the world, because there is no state in which stopping the world is correct — the save captures canonical state and restores an identical state hash, so quit anywhere is already true. Settings open as an overlay while the simulation runs.

Resolved: solo modes pause, the persistent universe does not.

This turns out to cost nothing architecturally, which removes the objection entirely. Pausing is a host decision, not a simulation one: apps/game simply stops calling advance(delta). There is no special case in the clock, no branch in the tick, and no divergence in the simulation core — the three modes remain one build. The rule is about who is allowed to stop handing the clock wall time, not about how the clock behaves.

The cockpit HUD

┌──────────────────────────────────────────────────────────────────────────┐
│  HIP 71683 · b:3                              ⌾ SURVEYED   ★ FIRST       │
│  rocky · 1.09 M⊕ · thin CO₂ · LANDABLE                                   │
│                                                                          │
│                                                                          │
│                              ⊕                     ← target, and the     │
│                                                      lead marker where   │
│                                                      it will be on       │
│                                                      arrival             │
│                                                                          │
│  ┌─ BURN PLAN ─────────────────────────────────────┐   ┌─ TARGET ──────┐ │
│  │ ███████████████████▌·········│·················  │   │ 4.20 AU       │ │
│  │ ▲ now              ▲ FLIP 0:42   ▲ arrive 6:49  │   │ ETA   6:49    │ │
│  │ 0.050 c/s   Δv 20.4 c   fuel 0.153 t            │   │ rel  8.4 c    │ │
│  └─────────────────────────────────────────────────┘   └───────────────┘ │
│                                                                          │
│  DRIVE ████░░  SYS ██░░░░  PAY ░░░░░░    g 1.4    THRM 34%   FUEL 11.4 t │
└──────────────────────────────────────────────────────────────────────────┘

The burn plan is the primary instrument

One horizontal bar carries the entire trip: elapsed against remaining, the flip marked as a hard division, and the three numbers that define the plan — the acceleration you chose, the Δv it costs, and the fuel that buys. Dragging the throttle moves all three, live, before you commit. It is the interface expression of halving the time doubles the fuel, and if it is legible the mechanic teaches itself.

The flip cue is the one moment the HUD raises its voice: a countdown from five, an audio cue, and the plan bar flashing at the division. Miss the ±8 second window and the solution needs re-plotting, which the HUD says plainly rather than silently correcting.

What is always on

What appears contextually

Everything not in these two tables is off. A cockpit that shows nine panels at all times teaches nothing; a cockpit where a panel appearing is itself information teaches constantly.

The Canopy

The canopy is a sensor, not a window, and its controls are physical, on the console, always reachable.

The following controls describe the accepted three-mode design in ADR-0037. The current interface still uses Composite/Direct and a separate Natural response preset.

The first release has one authored Enhanced look and one photographic look. It does not need a second response selector. Spectral filters remain a separate feature that requires actual line emission.

The composited view never rotates the cockpit. The attitude indicator and physical window retain the hull's orientation. Manual stays accessible for a photograph at known settings. Changing display output cannot change that choice.

Resolved: four presets — forward, aft, target, nadir — on a key each, plus hold-to-free-look that snaps back on release. Predictable enough that you can never be lost about which way the hull points, flexible enough for sightseeing, and the physical window remains the orientation anchor. Persistent free-look lives in photo mode, where disorientation costs nothing.

Photo mode

Specified in art. Interface notes: it is entered from the Canopy console, not a menu; the simulation continues unless explicitly paused; and export stamps the location's address into the file's metadata, so an image is a coordinate anyone can travel to.

The three registers on screen

From world: Instrument text is monospace, uppercase, abbreviated. Record text is proportional, mixed case, precise, with units. Correspondence is proportional prose. They are never mixed in one panel.

The system map

Specified in galaxy. Interface notes:

• Overlay, not a screen. 70% opacity on the canopy; the world behind it keeps moving, and a body you have targeted stays visible through it.
• One click from decision to action. Selecting a body plots a burn to it and closes the map, with the plan already on the HUD. This path is used hundreds of times per session and must be under 200 ms end to end.
• Log-scaled orbits, so a hot Jupiter at 0.04 AU and an ice giant at 30 AU are both legible.
• Scan state is the primary visual channel — provenance and survey status are what the player is reading for.

The galaxy map

Specified in galaxy. Interface notes:

• Three scale tiers cross-fade; there is no zoom level at which the representation visibly changes mode.
• Filters are a persistent left panel, not a modal. Toggling a filter must be instant and the map must animate rather than snap, so the player can see what changed.
• Route comparison is always both, side by side — see the route planning panel.
• The horizon of knowledge is always drawn, and its completeness readout updates with the camera. It is the map's most distinctive element and should never be hidden behind a toggle.

On-foot HUD

The visor. Five gauges from onfoot, and almost nothing else.

     O₂ 68% · 42min          ┌────────────────┐            PWR 91%
                             │                │
                             │       +        │      ← reticle only when
                             │                │        something is
                             └────────────────┘        interactable
     THRM nominal                                       RAD 0.4 Sv
     −118 °C ext                                        INTG 100%
                        ▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂
                        EVA  42.0 m/s remaining     ← only during EVA,
                                                      and it is large

The EVA budget gets a large, central readout whenever thrusters are armed, with a predicted trajectory line drawn in the world. It is the scariest number in the game and it should be impossible to lose track of.

First-time experience

The shape is in loops. This is the specification.

There is no tutorial. No pop-up teaching a key, no forced sequence, no objective marker. There is a ship, a system that everybody already knows, and a prompt hierarchy that appears only when it is relevant.

The design rule for prompts: a prompt appears when the player is in a situation where the action is both possible and useful, and never before. It disappears permanently once used successfully twice. There is no prompt for anything the player can discover by looking.

🎮 Designer's Note: The 28-minute mark — walking out onto the Moon and looking up at Earth — is the moment the game either lands or does not. Everything before it is setup and everything after it is elaboration. It should be playable end to end as the first thing built after terrain, and it should be the thing every milestone is judged against.

Controls

Three schemes, all first-class. The design does not assume a HOTAS, and does not punish having one.

Everything is rebindable, including modifier layers, and the editor is /settings/controls: a row per act, press it to capture the next chord, a conflict named in place, reset per row and for all. Every label in the interface that names a key reads the live chord for the act rather than a string, so a rebind reaches the keys sheet, the panel tooltips and the screen reader in the same commit that stores it. ? opens the sheet from any mode.

A binding is a physical key, not a character: + is Shift+Equal on every layout this ships to, so a chord tied to what the key types would not survive a change of keyboard. The label goes the other way — navigator.keyboard where it exists, a US table where it does not.

Tab, Escape, F11, F12 and anything with Ctrl or Cmd cannot be bound. Those belong to the browser, and a mode that claims Tab owns focus navigation whether it means to or not.

Where they are stored. controls.keymap in this browser, as overrides only — a stored copy of the whole table stops tracking the defaults, so an act whose default later moves is frozen at the old one for everybody who ever opened the editor. Preferences are not part of the universe, so they are not in a save; /settings/data exports them as a file, which is how they reach a second machine. Bindings in the save, and syncing them to an account, come with the account — the controls group is what would go. ADR-0018.

What a browser can actually do with a HOTAS

Spike 5 measured the API surface in three browsers and read the caps out of Chromium's source. The answer is yes, with a browser named.

Mozilla's position on WebHID is negative and settled — "devices are generally not designed with access from arbitrary websites in their threat model" — and WebKit has stated no position and not shipped it. Plan for WebHID being Chromium-only indefinitely.

The Gamepad API is the universal floor, and it has hard limits that shape the binding UI:

The button cap is worse than a cap. On macOS, Chromium indexes buttons by HID usage number and drops anything above 32 without reporting it:

// Ignore buttons with large usage values.
if (button_index >= Gamepad::kButtonsLengthCap)
  continue;

So a throttle whose report descriptor declares buttons above usage 32 will appear to work and quietly lose inputs. The binding UI must never present gamepad.buttons as the device's real button set, and a device with more physical buttons than reported ones should say so rather than letting the player discover it during a fight.

WebHID has no such caps, exposes the raw report descriptor, is event-driven rather than polled, and — verified in Chromium's protected-usage list — does not block Joystick (0x04) or Gamepad (0x05) collections. Permission is per-origin, granted through a device chooser behind a user gesture, persistent, enumerable via getDevices(), and revocable with device.forget().

How to say it in public: "full 6-DoF axis binding with no emulation layer, in Chrome and Edge." Unqualified "HOTAS support" would have to be withdrawn for half the audience.

⚠️ The hardware half of the spike has not been run. No stick-and-throttle pair was available. Dual-device enumeration, reconnect stability, end-to-end latency against native, and whether real devices actually declare buttons above usage 32 are all still unknown. The software says it is possible; hardware says whether it is pleasant. Run it before this paragraph goes in a README.

Accessibility

Not a compliance checklist. Several of these are load-bearing for a game about looking at things.

Exposure and HDR interact with accessibility and need care. A game that flies from a star at display peak luminance to interstellar dark does a great deal of adaptation, and that is genuinely uncomfortable for some players — more so in HDR, where the peak is brighter than any SDR display can reach.

Three controls, all findable, none buried:

See art.

Related

• galaxy — the two maps, specified
• planetarium — the mode with no ship, and its panels
• cinema — the scene player
• onfoot — the five gauges
• art — how all of this is drawn
• loops — the shape this page specifies
• ADR-0011 · ADR-0012