Files
rippr/docs/ui-redesign/UI-07-rides-history.md
uhryniuk 822003ed38 UI redesign: 8 tickets from the Stitch export analysis
Same shape as docs/v3/: Goal/Context/Design/Implementation/Acceptance/Tests/Risks/Out-of-scope, written before implementing.

UI-01: persistent 4-tab shell (StatefulShellRoute) replacing the current push/pop stack rooted at Record, with a single shared background map dimmed behind every tab and no header anywhere.
UI-02: animated skeleton map for the no-cache/no-network case, since the map is now a permanent background presence rather than opt-in per screen.
UI-03: shared GlassPanel/FloatingPill/PulsingLocationMarker component kit.
UI-04: draggable, resizable HUD telemetry widgets with a Settings visibility toggle -- split out from the screen redesign itself since it's a genuinely separate piece of engineering (a small widget-layout system, not a reskin).
UI-05: Map HUD/Record screen redesign -- the design north star every other screen ticket restyles toward.
UI-06: Plan & Route Planning -- correct in principle, explicitly restyled toward UI-05 rather than copying the Stitch export's drifted styling.
UI-07: Rides History -- live dimmed map background (not the mockup's static image), search/filter, real per-ride map thumbnails, and real distinct summary stats (fixing the export's 4-identical-cards generation artifact).
UI-08: theme migration to Modern Professional Dark, superseding V3-16's safety-orange direction.

README documents the dependency order, and two categories worth keeping separate: what was named explicitly by the person commissioning this (map-on-every-tab, no header, offline skeleton, customizable HUD) versus what the mockups themselves got inconsistent (nav icon count, duplicate summary cards, wrong active-tab highlight) and should not be copied as intentional.
2026-08-23 18:25:35 -05:00

4.8 KiB

UI-07 — Rides History redesign

Depends on UI-01, UI-03 · Size M · Status Not started

Goal

Rebuild the Trips list as "Rides History": a dimmed live map background (per UI-01, not a static image), a search bar, and richer ride cards with a real route-thumbnail map — restyled to Map HUD's (UI-05) established colors/icons, not the Stitch export's mockup styling.

Context

Today's TripsScreen is a plain ListView of _TripTiles (icon, name, one-line subtitle) over a solid background, reached by pushing off Record. The mockup adds a search bar, a filter button, a summary-stats row, and cards with an actual map-thumbnail image per ride. By explicit instruction, the background here is the same live map every other tab has (dimmed), not the mockup's static blurred screenshot — see UI-01.

Generation artifact to fix, not copy: the mockup's summary row is four identical "Total Dist: 482 KM" cards. This ticket defines real, distinct summary stats.

Design

  • Background: UI-01's shared dimmed map, same as Settings and Plan get when not the active-content tab.
  • Search + filter: a text field over ride name/date, plus a filter affordance (by activity type — V3-01 already has this data — and/or date range). Filtering logic is new; nothing today searches or filters the trips list.
  • Summary row: real distinct stats — total distance, total moving time, ride count, and one more genuinely useful figure (e.g. average speed across all rides, or longest ride) rather than repeating one number four times. Computed from existing Trip aggregate columns already stored on every completed ride — no new data needed, only a query across all of them.
  • Ride cards: title, date, and a distance/time/avg-speed stat row (matching the mockup), plus a real map thumbnail — a small, non-interactive RideMap (or a lightweight static rendering of the stored path) rather than a stock image, since we actually have the ride's own path data, unlike the mockup's placeholder photos.
  • Colors/icons: Map HUD's palette and icon fill-states, per the design north star — not the mockup's card-specific styling choices (e.g. the third card's grayscale/ reduced-opacity treatment, which reads as an arbitrary "older ride" decoration with no defined rule — drop it unless a real rule for it is specified).

Implementation

  1. Rebuild TripsScreen's background to sit over UI-01's dimmed shared map instead of a plain scaffold background.
  2. Add search (text query against Trip.name/date) and filter (activity type at minimum, reusing V3-01's Activity enum and activityIcon/activityLabel helpers).
  3. Add a summary-stats query/provider computing totals across watchCompletedTrips() (or a dedicated aggregate query if computing it client-side over a large ride history becomes a real cost — measure before optimizing).
  4. Rebuild _TripTile as a card with a small live/static RideMap thumbnail (reusing the existing RideMap widget at a small size and non-interactive, rather than building a second map-rendering path) plus the distance/time/avg-speed row.
  5. Confirm this screen's tab identity/name in the nav bar — "Rides" (mockup's label) vs. "History" vs. keeping "Rides" as used elsewhere in the codebase already (V3-07's Routes screen already uses "Rides" as the trips-tab label on the record screen) — match whatever UI-01's nav bar ships with.

Acceptance criteria

  • Background is the shared live map (dimmed), not a static image
  • Search narrows the list by name/date
  • Filter narrows the list by activity type
  • Summary row shows four distinct, real statistics, not one number repeated
  • Each ride card shows an actual thumbnail of that ride's own path, not a stock photo
  • Merge/delete/rename actions from today's TripsScreen still work
  • Colors and icon fill-states match Map HUD, not the Stitch export's card styling

Tests

  • Widget: search filters the visible list correctly
  • Widget: filter-by-activity narrows correctly
  • Unit: summary-stats aggregation matches a hand-computed total over a fixed set of seeded trips
  • All existing trips list widget tests (empty state, newest-first ordering, active-ride exclusion, merge-at-exactly-two-selections, delete) updated to the new layout and still passing

Risks

  • Rendering a small RideMap thumbnail per card in a long list could be a real performance cost (many simultaneous FlutterMap instances) — consider a lightweight static polyline-on-canvas rendering instead of a full interactive map per thumbnail if this proves too expensive; measure with a real ride history of realistic length before deciding.

Out of scope

Any change to trip data, merge, or split logic (V3-10) — presentation and search/filter only.