Challenge

Challenge: Mobile Operations Companion

How might we deliver a focused, WCAG-conscious mobile companion inside BetterFleet Manage so depot-floor operators can monitor chargers, vehicles, and active incidents while walking the yard without changing how the main desktop tool operates?

Motivation

• The current Manage experience is desktop-first and assumes a fixed sidebar workspace suited to planning, configuration, and wide-table analysis.
• Yard operators and depot floor supervisors need a faster, smaller workflow for checking live charging activity, spotting issues, and acting on a limited set of operational controls from a phone-sized screen.
• The first mobile slice needs to stay narrow so it can ship safely without rewriting the desktop tool or introducing a new backend surface.
• Accessibility needs to be explicit from the start for the delivered mobile slice, especially around reflow, touch targets, focus order, and non-color status cues.

Context

• The mobile slice will live inside bf-manage-web under a separate /mobile namespace.
• The primary user is a depot-scoped operator who is already authenticated and is working within one selected depot while physically moving around the site.
• Existing auth, depot context, permissions, feature flags, charger actions, and data hooks should be reused.
• The desktop routes, layout, nav, and service-worker behavior should continue to operate exactly as they do today.

High-Level Use Cases / JTBD

• As a yard operator, I want a phone-friendly home screen so I can see whether the site has active incidents, chargers needing attention, or vehicles needing attention before I start walking the yard.
• As a yard operator, I want a list-first yard view so I can check vehicle and charger location/status without relying on pinch, drag, or precise spatial gestures.
• As a depot floor supervisor, I want charger detail screens with a very small set of confirmed actions so I can request soft reset, remote start/stop, or cable release without exposing the wider desktop action surface.
• As an operations user, I want active incident detail with affected assets and event history so I can move from an alert to the relevant charger quickly.
• As a product team, I want the mobile slice to remain isolated so we can iterate without destabilising the main web tool.

Current State -> Desired State

Current State (Pain/Gain)	Desired Outcome	Success Measure
Pain: desktop-first layout is cumbersome on phones	A dedicated /mobile shell supports key mobile tasks	Users can complete core mobile tasks without using desktop nav
Pain: yard-walk use cases are buried inside broad desktop screens	Mobile screens focus on depot-scoped awareness and limited action	Operators can reach incidents, chargers, and yard state within one or two taps
Pain: existing spatial yard views are not sufficient on their own for mobile accessibility	Yard data is available through an accessible synchronized list-first experience	Primary mobile yard interactions work without relying on spatial interpretation
Pain: mobile actions could easily expand into unsafe parity with desktop controls	Only a narrow, approved operational action set is exposed	Soft reset, remote start/stop, and cable release are the only mobile controls
Gain to unlock: iterative mobile delivery	A small separate slice can evolve without changing the desktop surface	Desktop regression risk stays low while mobile scope can grow deliberately

Assumptions & Open Questions

• Key assumptions:
  • Mobile use is depot-scoped, not workspace-wide, in phase 1.
  • Existing data contracts are sufficient for the first mobile slice.
  • WCAG 2.2 AA compliance claims apply to the delivered mobile slice only.
• Open questions:
  • No blocking open questions remain for phase 1 delivery.

Constraints & Out of Scope

• Constraints:
  • Keep desktop routes and desktop shell behavior intact.
  • Reuse existing auth session, depot context, permissions, and feature flags.
  • Do not add offline mode, background sync, or service-worker caching.
  • Keep the mobile action surface deliberately narrow and confirmation-driven.
• Out of scope:
  • Desktop route rewrites.
  • Dispatch, timeline, settings, and workspace-wide mobile administration.
  • Out-of-depot telematics map.
  • Charger settings edits, power overrides, hard reset, and depot vehicle-location editing.
  • Incident resolution from mobile in phase 1.

Evaluation

• User value:
  • Faster situational awareness for people physically working in the depot.
  • Fewer taps and less visual noise on a phone-sized screen.
  • Safer action flows with accessible confirmation and feedback.
• Business value:
  • Unlocks a mobile-specific operations surface without forcing a broad product redesign.
  • Creates a governed, testable iteration path for future mobile expansion.

Risks & Opportunities

• Risks:
  • The mobile slice becomes a partial desktop clone instead of a focused companion.
  • Yard visibility becomes inaccessible if the visual layout is treated as the primary interface.
  • Mobile actions become harder to govern if feature-flag and permission seams drift from desktop rules.
• Opportunities:
  • Establish a reusable mobile shell and route namespace for future small-scope mobile capabilities.
  • Improve accessibility discipline by making WCAG requirements explicit in a narrowly defined surface.

Solution Ideas & Tradeoffs

• Idea A (Preferred): build a separate /mobile companion shell with focused screens and existing service hooks.
  • Best for protecting the desktop surface while shipping mobile value quickly.
• Idea B: retrofit the current desktop routes into responsive variants.
  • Reuses more UI, but carries much higher regression risk and weaker task focus.
• Idea C: create a standalone mobile app or PWA-first offline surface immediately.
  • Could support richer mobile workflows later, but is unnecessary and too broad for the first slice.

Release Sequencing

• Natural order:
  • Define the governed challenge, specification, and story set.
  • Add the mobile route namespace, feature flag, and dedicated shell.
  • Deliver the four phase-1 screens and narrow charger actions.
  • Add targeted tests, docs, and release-note updates.