M08 — Dashboards Polish and Fire-Department View

One-line goal: the operator dashboard is polished enough to demo to a customer, the fire-department view delivers exactly what FD users need (and nothing they don’t), the 3D digital twin is fluid, EN/AR with full RTL works throughout, and the KPI / BI panels reflect real-time and historical metrics.

After M08, the platform is “client-perspective ready” — what Saudi Airlines and Civil Defence see is polished and complete.

Tracks involved

• Frontend — primary. Polish, layout work, RTL, KPI panels, FD view, accessibility.
• Backend — KPI aggregation endpoints, BigQuery-backed analytics queries.
• Design — final brand polish (logos, color, type) — light touch unless the pilot has a specific brand spec.

Dependencies

• M02 (auth, role-aware navigation).
• M03 (data model fully populated).
• M04, M05, M06, M07 (every functional surface real, not mocked).

Deliverables

1. Operator dashboard — polish pass

1.1 Home view

• Three-panel layout: camera grid (left, large), active alerts (top-right), KPI strip (bottom-right).
• All three panels resizable; layout saved per user.
• Top bar: organization logo, building selector (multi-building users), language toggle, MFA/security indicator, user menu.
• Bottom status bar: edge connectivity status, AI service health, last alert time.

1.2 Camera view (extends M04)

• Grid layouts (1, 4, 9, 16, 25) selectable from the top.
• Saved layout presets per user, per building, per scenario (e.g., “Fire alarm” preset auto-shows zones near the most recent alarm).
• Per-tile overlays from M05 polished: bounding boxes anti-aliased, anomaly scores subtly colored, crowd density gradient.
• “Spatially aware” auto-layout — when an alert is active, the dashboard offers a single-click layout showing only correlated cameras.
• Full-screen single-camera mode with all overlays.

1.3 Digital twin view (extends M07)

• Three modes per the architecture vision: Overview (exterior), Floor (interior layout), VR Walkthrough (WebXR).
• Smooth transitions between modes.
• Click a camera marker → camera detail panel with live feed.
• Click an alarm zone → zone detail with sensor readings + recent events.
• During an active alert: zone flashes red, relevant cameras pulse, the view auto-frames to include all relevant elements.

1.4 Map view

• Buildings rendered on the Esri ArcGIS map (single building for the pilot; designed to scale).
• Per-building status indicator (green / yellow / red).
• Click a building → drill into that building’s dashboard.

1.5 Alert console (extends M07)

• Active alerts grouped by severity.
• Resolved-today archive.
• Search and filter.
• Per-alert detail panel: full evidence package (snapshots, LLM verdicts, spatial view), action buttons, audit trail of who has done what.

1.6 KPI panels

Real-time metrics:

• Cameras online / total
• Active alerts by severity
• Tier 2 escalations in the last hour
• False-alarm-reduction rate (alerts marked false / total alerts) — the headline metric for the platform’s value proposition
• Mean time to acknowledge
• Mean time to resolve

Historical metrics (BigQuery-backed):

• Daily / weekly / monthly trends for each of the above
• Alert distribution by zone, by time-of-day, by alert type
• Camera-uptime SLA over time
• AI-pipeline latency p50 / p95

2. Fire-Department view

apps/fd-view/ — a stripped-down version of the dashboard, separate origin, separate brand presence (Civil Defence logo if available).

• Only fd_dispatcher role users can access.
• Shows: active alerts only (no routine monitoring), the cameras with line-of-sight to active alerts, the spatial twin auto-framed on the active incident.
• Action buttons: acknowledge, dispatch, request more cameras, mark resolved.
• Mobile-responsive — the FD-view will likely be used on tablets or phones from a vehicle. Touch-targets sized accordingly.
• No exposure of building configuration, user management, or any admin functionality.

3. Internationalization — EN/AR with full RTL

3.1 Translation system

• i18next with namespaces per view.
• Translation strings in apps/dashboard/src/locales/en/*.json and ar/*.json.
• Build-time check that every key exists in both locales; missing translations are CI failures.
• For dynamic content (LLM reasoning, alert descriptions): a thin translation layer (deferred decision — automated translation API in Dammam, or post-hoc operator-facing English only).

3.2 RTL layout

• Tailwind CSS direction-aware utilities (or equivalent in our styling library).
• All flex orderings, padding/margin, icons, charts, and animations tested in RTL.
• Numerals: digits remain Western (1, 2, 3) for technical readability of camera IDs etc., even in Arabic mode. Civil Defence convention.
• Date and time: rendered per locale conventions.

3.3 Cultural specifics

• Hijri calendar option for date display alongside Gregorian.
• Prayer-time-aware UI hints (optional; future enhancement).

4. Accessibility

• WCAG 2.1 AA baseline:
  • Keyboard navigation throughout.
  • Visible focus rings on every interactive element.
  • Color contrast ≥ 4.5:1 for body text, 3:1 for large text and UI components.
  • ARIA labels on icon-only buttons.
  • Screen-reader friendly headings and landmarks.
• Live regions for real-time alert updates (so a screen-reader user gets new-alert announcements).
• Reduced-motion preference respected for animations.

5. Branding

• Logo placement and primary color from docs/civil-defence-innovation-submission/pdf-generation/logos/ until final brand is set.
• Per-tenant branding option (when a tenant supplies their own logo + color, the dashboard themes accordingly).
• Saudi Airlines branding on the FD-view if/when their logo is provided for the pilot.

6. Performance

• Lighthouse score ≥ 90 on the production dashboard build (run as a CI check).
• Initial bundle ≤ 500 kB gzipped; lazy-load Three.js + Esri SDK on first use of those views.
• 60 fps target on the camera grid with 16 simultaneous tiles + overlays.
• Memory: dashboard tab idles under 1 GB RAM with 16 cameras active.

7. Demo mode

A toggle in the admin panel that enables a curated test scenario:

• Seeded synthetic cameras + a simulated FACP event.
• Pre-recorded test footage played as if it were live.
• Used for sales demos and customer training without exposing real data.

Verification

1. Operator UAT script passes. A canonical script with ~30 actions (log in, switch buildings, view cameras, acknowledge an alert, mark false alarm, view audit log, etc.) executes successfully on a fresh test tenant.
2. FD UAT script passes. A separate FD-specific script confirms an FD-dispatcher user sees only their authorized content.
3. Arabic + RTL renders correctly throughout. A manual review of every view in Arabic mode confirms no broken layouts, no clipped text, no mis-mirrored icons.
4. Lighthouse ≥ 90. CI confirms the production build’s score.
5. 3D twin at 60 fps on the test laptop (Civil Defence-representative spec).
6. Real KPI numbers. All KPI panels show actual computed values from the database, not placeholder mocks.
7. BigQuery-backed history works. Historical KPI panels render in < 2 s for the last-30-days query on a representative dataset.
8. Demo mode toggles cleanly. Enabling demo mode replaces live data with the curated scenario without leaking real data.
9. Mobile FD view works on a tablet. Touch targets are at least 44×44 px; layout adapts gracefully to portrait and landscape.
10. Accessibility audit passes. Automated axe-core scan reports zero serious / critical issues on the main views.

Risks

Open questions

• Should the FD view use a different language default? Probably Arabic-default for FD users in KSA; configurable per user.
• Dynamic-content translation strategy. For now, render LLM reasoning text in English with an English-only toggle for the operator; full machine translation is a post-pilot enhancement.
• Hijri calendar — required or nice-to-have? Confirm with customer; if required, add to M08 scope.
• Demo mode — included in production builds or behind a feature flag? Behind a feature flag — never in customer-facing production by default.

Exit criteria

All 10 verification items pass. Operator + FD UAT scripts signed off by the customer’s representative (or a stand-in for the pilot). M08 sign-off entry in docs/plan/COMPLETION_LOG.md.