Skip to content

Module 5 — Interaction

Module 4 produced a static map with depots and service areas. Module 5 turns it into a working application. Three roles — each seeing the same operational data but through different lenses — become the organising principle for everything that follows.

The module has eight lessons. The first two set up the model and navigation shell; the next five build out the three role-specific dashboards; the final lesson consolidates the shared map infrastructure into a clean reusable layer.

Lesson 1 — The operational model. What the application is actually about. Jobs, customers, depots, service areas, users, and the relationships between them. This lesson is mostly schema and concept — defining the core entities and the operational flow they represent. Everything afterwards builds on this model.

Lesson 2 — Role-aware navigation. Three roles need different views: managers see strategic overviews, dispatchers see active operations, field officers see their own work. The lesson sets up role-based access control, the conditional sidebar (different items per role), and the routing that ensures users land on the right home page based on their role.

Lesson 3 — The manager’s overview. The strategic view. National job statistics, depot performance, recent activity. The lesson introduces the manager dashboard’s data shape — aggregated metrics across the whole operation — and the supporting service objects (NationalJobs and friends). Performance-conscious from the start: aggregations use pluck and SQL aggregates, not full AR object instantiation.

Lesson 4 — The dispatcher’s map. The dispatcher’s first view. A map showing today’s jobs, with active states colour-coded. Pickers for service area and date. This lesson is where the map component from Module 4 starts becoming a working operational tool — not just a visualisation, but the dispatcher’s primary interface.

Lesson 5 — Composing the map. As the dispatcher map grows, the markup grows with it. The lesson refactors the inline map setup into a higher-level component (Components::DispatcherMap) that owns the layer composition for this specific view. The pattern: reusable primitives at the Vera::Map level; opinionated compositions at the application component level.

Lesson 6 — The dispatcher’s dashboard. The full dispatcher view. Map plus a sidebar showing active jobs, FO availability, and the day’s metrics. Click a job in the sidebar to highlight it on the map. The lesson is where map-and-sidebar interactivity first appears — a pattern that recurs throughout the application.

Lesson 7 — The field officer dashboard. The FO’s own view. Today’s jobs, in order. Their next destination on a small map. Simple, focused, mobile-friendly. The lesson illustrates that not every role needs a complex view; sometimes the right answer is just “what do I need to do now?”

Lesson 8 — Consolidating the operations layer. The shared infrastructure that emerged across the previous lessons — service objects, components, helpers — gets refactored into a clean operations layer. Naming, organisation, and the service-object pattern (module Foo; extend self; end) become explicit. The dispatch deck has a sustainable code structure going into Module 6.

What this module produces

Three working dashboards — manager, dispatcher, field officer — each with a tailored view of the operational data. Navigation that adapts to the user’s role. A factored operations layer (service objects, dashboard components) that’s organised for ongoing development.

What this module sets up

  • The role-based UI patterns that subsequent modules extend
  • The service-object discipline (module Foo; extend self; end) used throughout
  • The dashboard structure (map + sidebar, contextual data) that becomes the chassis for reports
  • The data shape the seed task populates — making realistic-scale testing possible from Module 6 onward