Skip to content

Driver UI Design

noteMASTER11 edited this page Jul 29, 2026 · 1 revision

Driver UI Design

This page records the design rules used by TaxiDriver Reloaded's driver-facing UI. It is both an implementation checklist and a review baseline for future screens.

Design objective

The interface must remain readable at 100% UI scale in a compact BeamNG UI App on a 1080p display. During an active trip, the driver should be able to identify the current task, ETA, remaining distance, route, and any urgent warning with a short glance.

Current visual system

  • Background and surfaces: #08090B, #111317, #181B20, and #20242A.
  • Primary accent: BeamNG-style orange #FF6600.
  • Text: #F5F7FA for primary information and #B8C0CA for supporting copy.
  • Geometry: 2–4 px corner radii; circular shapes are reserved for conventional signs or status markers.
  • Density: an 8 px spacing grid. Operational text is 12–16 px; 9–10 px is limited to metadata.
  • Native default window: 340 × 650 px; supported minimum: 300 × 500 px.
  • Compact mode assigns about 338 px to the navigation map at the 520 × 900 audit size and removes economy/profile metrics.
  • Motion: limited to feedback, progress, and urgent status changes.

Palette contract

Role Color Allowed use
Background #08090B Application and driving canvas
Surface 1 #111317 Main panels
Surface 2 #181B20 Cards and rows
Control #20242A Neutral buttons, chips, inactive controls
Border #343A42 Passive boundaries
Strong border #56606B Interactive boundaries and inactive switches
Text #F5F7FA Primary content
Secondary text #B8C0CA Supporting content
Accent #FF6600 Primary action, selected state, focus, key progress
Success #4CD984 Successful or sufficient state only
Warning #FFB020 Attention and low-resource state only
Danger #FF5C68 Failure, destructive action, critical state
Navigation #5AA7FF Route and navigation information

Orange must never be placed on yellow, amber, brown, green, or purple tinted surfaces. It is used either as foreground on a neutral surface or as a solid action background with near-black text. Translucent orange surfaces and a separate purple Fleet theme are prohibited.

Information hierarchy

Priority Driver question UI treatment
1 What do I do now? Current phase and destination immediately below the map
2 Where and when? Route, ETA, remaining distance, speed limit
3 Is something wrong? High-contrast warning or status strip
4 What will I earn? Compact payout and penalty summary
5 What happened earlier? Collapsed violations, history, profile, and detailed settings

The active-trip screen intentionally keeps economics and history subordinate to navigation. Long explanations belong in settings or parked-state screens, not in the moving-state hierarchy.

AI Driver safety gate

AI Driver is disabled by default. While disabled:

  • the map has no AI Driver button;
  • the Lua API refuses activation;
  • disabling the feature while it is active parks the vehicle and releases AI;
  • advanced AI profiles remain hidden.

Enabling it requires a confirmation that clearly states the feature is experimental, may behave incorrectly, and is not reliable for every vehicle, map, or game version.

Interaction rules

  • Driving-related information is shown before profile, fleet, or economy information.
  • Buttons use short action labels and immediate visible feedback.
  • Settings use progressive disclosure: section first, master switch second, advanced controls last.
  • Touch-oriented Connected Phone controls retain at least a 40 px target height.
  • Text and controls are not distinguished by color alone.
  • Normal text aims for WCAG AA contrast (4.5:1); component boundaries and large text aim for at least 3:1.
  • New layouts must pass the responsive audit at 320 × 568, 390 × 844, desktop widths, all locales, and HiDPI.

Flat UI composition

  • Layout uses spacing and solid neutral surfaces as the primary grouping mechanism.
  • A DOM branch may expose at most two surface levels: canvas plus one section or repeated row. Nested metric, metadata, thumbnail, and projection surfaces are prohibited.
  • Passive perimeter borders around cards and metrics are prohibited. A single sibling divider may separate list rows or adjacent metrics.
  • Borders are reserved for keyboard focus, selected controls, text inputs, modal boundaries, destructive actions, and map overlays that require contrast over changing content.
  • Repeated structural rows use zero radius, real controls use 2 px, and floating overlays or dialogs use at most 4 px. Large rounded "floating card" stacks are not part of the visual language.
  • A normal component must not combine a static perimeter border, distinct background, and shadow. Shadows are reserved for floating overlays and dialogs.
  • Status chips are reserved for actual state such as AI-assisted, rush, warning, or error. Ordinary metadata is inline text or a definition grid.
  • Home uses one readiness plane; Settings is a continuous list; Orders expose one surface per offer; Profile and Fleet use definition/list rows; Fuel uses one transaction plane.
  • Connected Phone Settings at 900 px and wider use a persistent category sidebar and one active content panel. Narrow screens keep the single-open-section accordion.

Content-fit contract

  • Names and descriptions use one or two lines according to context. Truncated content must expose its complete value through title.
  • Operational numbers never use ellipsis. They use tabular numerals and remain on one line.
  • Counts from 0 through 999 are exact. Larger badge counts use 999+; large analytical aggregates use locale-aware K, M, or B notation.
  • Critical transaction values, such as an offered fare or projected payout, remain fully formatted. Large account and history aggregates may be compacted, with the exact value available in title.
  • Shift history renders 30 entries initially and loads further entries in bounded batches.
  • Stress fixtures use 193 shifts, long vehicle and passenger names, six-digit ride counts, multi-million balances, long localized durations, and large distances. The visual audit rejects clipped operational values and label/badge overlap at 100% scale.
  • At 320 × 568 and 360 × 640, Trip switches to a driver-first hierarchy: map and ETA, passenger or cargo state, route progress, energy warning, and Offline. Rating, economy, history, and other secondary layers are removed instead of being allowed to overlap a sticky footer.
  • Native Home keeps New Shift fully above the fold at 320 × 568. Native Fuel uses normal-flow actions on low screens, so Refuel never covers transaction values.

Motion contract

  • Motion tokens are 80 ms for press, 120 ms for hover/color, 160 ms for controls and disclosures, and 200 ms for parked-screen or overlay entry.
  • Parked screens enter once with a 6 px rise and opacity transition. Trip and Compact use a shorter opacity-only transition so critical guidance does not move.
  • New shift receives one 680 ms sheen after a 480 ms delay on the first Home appearance in the UI session. Returning from Settings does not replay it.
  • Buttons use a small 80 ms pressed displacement; switches and progress bars use 160 ms transitions. Accordion content enters with a 4 px rise and opacity transition.
  • Status pulses are finite. Motion does not become a persistent source of attention.
  • Decorative infinite motion is prohibited; indeterminate spinners are allowed only for real loading work.
  • prefers-reduced-motion: reduce removes keyframes, transforms, and the static sheen pseudo-element while shortening state transitions to effectively zero.

Review gate

  • Pixel baselines verify rendering stability; they do not approve a design.
  • The automated style gate rejects the retired yellow palette, translucent brand-orange surfaces, a purple Fleet sub-theme, duplicate raw semantic colors, and token pairs below 4.5:1 contrast.
  • Home, Orders, Trip, Settings, Fleet, and Compact require manual visual review before baselines are updated.
  • A two-second exposure test should confirm that players can identify current state, next action, distance, and ETA without opening secondary panels.

Research basis

The implementation follows the intent of these primary sources:

These are design inputs rather than a claim that a game UI is a certified automotive interface.

Next improvements

  • Add a focused next-manoeuvre banner when BeamNG exposes stable manoeuvre data.
  • Add a parked-state layout that expands order comparison without affecting the driving view.
  • Measure glance time with five-second screenshot tests and user sessions, not only layout metrics.
  • Audit color-vision variants for event, penalty, fuel, and route states.
  • Add keyboard/controller focus styling to every interactive element.

Clone this wiki locally