Race-day UX backlog: sorting, standings detail, live updates, and tablet prep mode

[tobowers]

Context

Mario captured several race-day requests. This issue translates each note into an implementation-ready item with practical guidance.

1) Reverse sort registration and heats pages

Meaning

• Show newest racers/heats first so volunteers can immediately confirm recent changes.

Suggested implementation

• Default registration and heats queries to descending order (created_at DESC or heat_number DESC).
• Add a visible sort toggle (Newest/Oldest) in each table header.
• Preserve sort in URL state (example: ?sort=newest) to keep behavior after refresh.

Acceptance criteria

• Newly added racer or heat appears at the top by default.
• Sort choice remains stable after reload/navigation.

2) Show more nuance on places on display page

Meaning

• Current place display is too binary; we need ties, movement, and confidence/precision cues.

Suggested implementation

• Display tied placements clearly (e.g., "T-2") when points/times are equal.
• Add small deltas like +1 / -1 since last heat to show movement.
• Include tie-break context (best time, head-to-head, total points) as a compact subtitle or tooltip.

Acceptance criteria

• Display page differentiates unique ranks vs ties.
• Spectators can understand why one racer is ahead.

3) Add editing rights so others can check/update standings

Meaning

• Multiple volunteers need access; not everyone should need full admin privileges.

Suggested implementation

• Introduce simple roles: viewer (read-only standings) and editor (can correct standings-related data).
• Gate edit actions behind role checks while leaving standings display public/read-only.
• Add quick role assignment in event settings (optimized for offline/local network usage).

Acceptance criteria

• A non-admin editor can make approved corrections.
• A viewer can open standings but cannot modify data.

4) Clicking on a racer should show full win/loss record

Meaning

• Operators need complete racer performance details without hunting across screens.

Suggested implementation

• Make racer names clickable in standings/heats.
• Open a dialog or detail page with: total heats, wins, losses, ties, lane history, average time, best time, and recent results.
• Include per-opponent summary if available (head-to-head).

Acceptance criteria

• One click from standings reveals complete record.
• Record updates immediately as new heats are entered.

5) Heat and registration pages should live reload during active periods

Meaning

• During check-in/racing, pages must reflect updates without manual refresh.

Suggested implementation

• Add live updates via WebSocket (preferred) or short polling fallback (3-5 seconds).
• Push events for racer add/edit/remove, heat result updates, and schedule changes.
• Show "Last updated" timestamp and reconnect state for reliability.

Acceptance criteria

• Multiple devices stay in sync during registration and race operations.
• If connection drops, UI auto-recovers and backfills missed changes.

6) Support removing broken/missing cars

Meaning

• Cars can break or no-show; app needs a safe way to withdraw racers mid-event.

Suggested implementation

• Add racer status values: active, withdrawn, dns (did not start), dnf if needed.
• Provide a "Withdraw racer" action with confirmation + reason.
• On withdraw, update pending heats (scratch/bye logic) and recompute standings transparently.

Acceptance criteria

• Operators can remove a racer without corrupting heat flow.
• Audit trail records who withdrew the racer and why.

7) Enable printing results as certificates

Meaning

• Need ready-to-print certificates for winners/participants at event end.

Suggested implementation

• Create a print-friendly certificate template route (A4/Letter aware).
• Include event name/date, racer name, placement/award, and signature lines.
• Add "Print certificate" action from final standings and racer detail views.

Acceptance criteria

• Certificates print cleanly from standard browser print dialog.
• Layout remains readable in grayscale and on common school printers.

8) Tablet display: always show next two heats for track prep

Meaning

• Staging volunteers need constant visibility into upcoming racers/lane assignments.

Suggested implementation

• Add a dedicated tablet mode with oversized text and high contrast.
• Persistently show: current heat + next two heats, lane assignments, and ready indicators.
• Auto-advance after result entry; optional manual next/previous for race officials.

Acceptance criteria

• Tablet view stays focused on prep workflow with no deep navigation.
• Volunteers can prep cars continuously without asking announcer for next heat.

Suggested rollout order

1. Live reload + tablet upcoming-heats view (biggest real-time operations gain)
2. Broken/missing car withdrawal flow (prevents race-day stalls)
3. Racer detail modal and nuanced placements
4. Role-based standings access
5. Certificate printing polish