Skip to main content

Mobile Trucking Driver Experience – Current Implementation

1. Overview​

  • Feature name: Mobile Trucking Driver Experience (Loads & Legs)
  • Primary users: Truck drivers using the AttuneLogic mobile app
  • Industries: Trucking
  • What this feature solves today:
    • Provides drivers with a mobile dashboard showing today’s and upcoming loads/legs.
    • Allows drivers to view load/leg details, documents, and tasks.
    • Aligns driver views with dispatcher assignments made via the web scheduler.

2. Repos & Entry Points​

Mobile (@attunelogic-mobile)​

  • Dashboard & Home
    • features/Dashboard/index.tsx – Main dashboard showing jobs/legs depending on user type & appType.
  • Schedule Tab
    • app/(app)/(tabs)/schedule/index.tsx – Schedule view, labeled “Loads” when appType === "trucking".
    • app/(app)/(tabs)/schedule/_layout.tsx – Layout for schedule stack.
  • Driver-specific views
    • features/Job/DriverLoads.tsx – Calendar + list of legs for a specific driver and date.
    • components/LegCard/* – UI representation of a leg (origin/destination, times, status).
    • features/Load/LoadShow.tsx – Load/leg detail screen with tabs:
      • LoadDetails, LoadDocuments, LoadTasks.
  • Shared navigation
    • app/(app)/(tabs)/_layout.tsx – Tabs; uses appType to label the schedule tab as “Loads” for trucking.

API (@attunelogic-api)​

  • Data accessed by mobile driver flows
    • Leg model and Job model (trucking loads and legs).
    • Schedule endpoints (/api/v1/schedule) used by mobile schedule view.
  • API slices (mobile)
    • store/api/legs/api.ts – useGetLegsQuery, useGetLegByIdQuery.
    • store/api/jobs/api.ts – useGetJobsQuery, useGetDriverJobsQuery.
    • store/api/schedule/api.ts – useGetScheduleQuery for schedule tab.

Web (@attunelogic-service)​

  • Dispatcher-facing complement
    • Web scheduler/dispatch assigns legs to drivers and sets dates/times.
    • These assignments determine what appears in the driver’s mobile views.

3. Current Implementation (By Platform)​

3.1 Mobile App – Driver Experience​

Home Dashboard (features/Dashboard/index.tsx)​

  • Uses useConfig() and useAuth() to determine:
    • appType (trucking vs serviceRepair).
    • Whether the current user is a driver (user?.type === "driver" when appType === "trucking").
  • Fetches:
    • Today’s jobs for all users via useGetJobsQuery.
    • Driver-specific today’s legs via useGetLegsQuery when user is a trucking driver.
    • Upcoming jobs and upcoming legs (next 2 weeks).
  • UI behavior:
    • If driver + trucking:
      • Shows two LegList sections:
        • “Today’s Loads” – legs assigned to the driver for today.
        • “Upcoming Loads” – legs for upcoming days.
    • Otherwise:
      • Shows JobList for today’s and upcoming jobs (service or non-driver trucking users).

Schedule Tab (app/(app)/(tabs)/schedule/index.tsx)​

  • Presents a schedule view that:
    • Uses useGetScheduleQuery to fetch schedule events for:
      • Selected day.
      • Entire month (for calendar indicators).
    • Uses appType to filter events appropriately.
  • For trucking drivers:
    • Focuses on legs/loads assigned to the driver.
    • Uses date selection to navigate through assignments over time.

DriverLoads Feature (features/Job/DriverLoads.tsx)​

  • Provides a calendar + list view for a given driver:
    • Determines targetDriverId from props or useAuth().user.
    • Uses useGetLegsQuery with:
      • driverId.
      • startDate/endDate based on selected date.
    • Maps data.legs into:
      • Calendar “appointments” keyed by date.
      • A list of LegCards for that day.
  • Tapping a LegCard:
    • Navigates to /load/[id] with id = leg._id (showing LoadShow).

Load Details (features/Load/LoadShow.tsx + subcomponents)​

  • LoadShow:
    • Accepts id and fetches leg/load details via useGetLegByIdQuery.
    • Uses a tabbed layout (Tabs):
      • Load Details – summary of route, client, schedule, etc.
      • Documents – BOL, POD, and other load-related documents.
      • Tasks – driver tasks/checklist (where implemented).
  • This provides drivers with a richer context for each leg/load.

3.2 API & Web – Supporting Behavior​

  • Assignments & schedule:
    • Dispatcher assigns legs to drivers using the web scheduler.
    • Assigned legs (with driverId, appointmentDate/time) are:
      • Returned by leg queries (/api/v1/legs).
      • Included in schedule responses (/api/v1/schedule) used by mobile.
  • Driver context:
    • Mobile uses useAuth() to determine current driver identity and role.
    • Tenancy and appType are controlled by the same customer config system as the web app.

4. Status & Completeness​

Implemented today​

  • Drivers can:
    • See today’s and upcoming loads/legs on the dashboard when appType === "trucking" and user is a driver.
    • View a per-day DriverLoads calendar/list of legs.
    • Open Load details with documents and tasks.
  • The Schedule tab:
    • Shows loads/jobs based on the schedule API.
    • Respects appType to focus on trucking loads when appropriate.

Partial / early implementations​

  • Actual production usage for trucking drivers is limited (pilot/bare-bones):
    • One customer uses the app in a basic way; most trucking operations are still centered on the web job page.
  • The dashboard and schedule are driver-aware but:
    • The overall UI is still shared across industries and not fully optimized for trucking drivers (labels, icons, workflows).
    • There is limited in-app guidance for drivers (e.g., no HOS information, route preferences, or truck-specific hints).
  • Status updates and workflows:
    • Leg status updates are possible in principle, but a fully guided “status progression” UX (e.g., En Route, At Pickup, Loaded, Delivered) is not yet fully formalized in the mobile UI, and today most status updates are handled by dispatch/back office on the web.

Missing / not implemented​

  • No dedicated driver dashboard focused solely on trucking, with:
    • HOS status, remaining driving hours.
    • Next stop, ETA, and route cues.
    • Quick actions (start/complete leg, report issues).
  • No mobile-side:
    • HOS tracking, break timers, or violation warnings.
    • Truck-specific routing, navigation integration, or GPS-based ETAs.
    • Comprehensive pre/post-trip inspection workflows (DVIR) and vehicle assignment.

5. Dependencies & Configuration​

  • Customer config (useConfig on mobile):
    • Provides appType (trucking vs serviceRepair), which:
      • Controls labels (Loads vs Jobs).
      • Influences which endpoints and views are used.
  • Auth (useAuth):
    • Provides user with:
      • type/role (e.g., driver).
      • id/_id for filtering legs/jobs.
  • Backend assignments:
    • Leg records must have driverId (and relevant dates) to appear in driver views.

6. UX Notes & Known Issues​

  • What drivers experience today (trucking):
    • See a mixed dashboard that adapts to trucking vs service but isn’t fully trucking-native:
      • “Today’s Loads” and “Upcoming Loads” lists exist but share UI with other appTypes.
    • Get basic visibility into their assigned legs and load details, including documents and tasks.
  • Known rough edges:
    • The distinction between “Job” and “Load” can be confusing: some lists are job-based, others leg-based.
    • The UX does not yet emphasize the driver’s next action (e.g., “Start this load now”, “Check in at pickup”).
    • HOS and safety/compliance info is missing from the driver’s daily view.

7. Roadmap Alignment​

  • Relevant roadmap sections (mobile):
    • docs/MASTER_ROADMAP.md – “Trucking Implementation Status”:
      • Notes: backend apptype support and legs model are complete; driver-focused UX is missing.
    • Planned trucking features:
      • Driver-focused dashboard.
      • Enhanced job cards with load numbers and routes.
      • Driver assignment UI and notifications.
      • HOS compliance, fleet management, advanced navigation.
  • What’s planned vs what exists:
    • Planned:
      • Full trucking driver experience (dashboard, HOS, navigation, inspections, communication).
    • Exists:
      • Solid baseline: drivers can see assigned legs/loads and details, but without the richer trucking-specific context and tools.

8. Testing & Risk​

  • Tests:
    • Mobile testing is currently limited, with most validation done via manual testing.
    • There are unit/integration tests around auth, basic navigation, and some features; trucking-specific driver flows are not extensively covered yet.
  • Risks / edge cases:
    • Changes to schedule or leg APIs may affect driver views if not coordinated.
    • Misconfigured appType or user roles can cause drivers to see job lists instead of leg-based views.
    • Lack of HOS and route-awareness may lead to drivers depending on external tools for compliance and navigation.
  • Monitoring:
    • Production feedback from drivers and dispatchers is key to identifying issues.
    • Error tracking via Sentry is integrated but not yet heavily tuned to driver workflows.

9. Current Adoption & Next Steps​

  • Current adoption:
    • FC Trucking and Logistics Inc. uses the mobile app in a bare-bones pilot capacity; most operational work is still anchored on the web job page.
    • Drivers can see assigned loads/legs and details, but the app is not yet their primary system of record for the workday.
  • Next steps:
    • Introduce a driver-centric trucking dashboard that highlights “what’s next”, HOS context (when available), and key actions.
    • Formalize a leg status progression for drivers (e.g., En Route → At Pickup → Loaded → Delivered) and wire it cleanly into the API + scheduler.
    • Layer in trucking-specific helpers over time: navigation integration, route/hazard awareness, simple pre/post-trip checklists, and eventually HOS and fleet features.