Dispatch Visual Review

Review Context

• Playwright MCP opened http://localhost:3000/dispatch with an authenticated session.
• Captures:
• scratch/dispatch-visual-review/dispatch-authenticated-desktop.png at 1440x900
• scratch/dispatch-visual-review/dispatch-authenticated-tablet.png at 1024x768
• scratch/dispatch-visual-review/dispatch-authenticated-desktop-snapshot.md
• scratch/dispatch-visual-review/dispatch-authenticated-tablet-snapshot.md
• scratch/dispatch-visual-review/dispatch-existing-empty-state-desktop-final.png after routing all no-block cases through the shared empty state
• scratch/dispatch-visual-review/dispatch-existing-empty-state-tablet-final.png after routing all no-block cases through the shared empty state
• scratch/dispatch-visual-review/dispatch-empty-state-after-revision-snapshot.md
• scratch/dispatch-visual-review/dispatch-empty-state-no-schedules-button-desktop.png after adding the no-schedules upload action
• scratch/dispatch-visual-review/dispatch-empty-state-no-schedules-button-tablet.png after adding the no-schedules upload action
• scratch/dispatch-visual-review/dispatch-empty-state-no-schedules-button-snapshot.md
• scratch/dispatch-visual-review/dispatch-populated-review-current.png with blocks available but the active Future tab empty
• scratch/dispatch-visual-review/dispatch-populated-review-finished-desktop.png with three finished blocks visible
• scratch/dispatch-visual-review/dispatch-populated-review-selected-finished-desktop.png with a selected finished block
• scratch/dispatch-visual-review/dispatch-populated-review-selected-finished-tablet.png with the selected finished block at 1024x768
• scratch/dispatch-visual-review/dispatch-populated-panels-fixed-desktop.png after the first populated-panel layout pass
• scratch/dispatch-visual-review/dispatch-populated-panels-fixed-tablet.png after the first populated-panel layout pass
• scratch/dispatch-visual-review/dispatch-populated-panels-fixed-finished-readiness-desktop.png after changing selected finished blocks to a readiness review state
• scratch/dispatch-visual-review/dispatch-populated-panels-fixed-finished-readiness-tablet.png after changing selected finished blocks to a readiness review state
• scratch/dispatch-visual-review/dispatch-populated-control-strips-aligned-desktop.png after aligning control-strip heights and reverting finished-block logic changes
• scratch/dispatch-visual-review/dispatch-populated-control-strips-aligned-tablet.png after aligning control-strip heights and reverting finished-block logic changes
• scratch/dispatch-visual-review/dispatch-populated-fullscreen-alignment-review.png at 1920x1080 before separating vehicle header and controls
• scratch/dispatch-visual-review/dispatch-populated-fullscreen-panel-header-aligned.png at 1920x1080 after separating vehicle header and controls
• scratch/dispatch-visual-review/dispatch-populated-fullscreen-matched-vehicle-tabs.png at 1920x1080 after replacing the static vehicle header with vehicle tabs
• scratch/dispatch-visual-review/dispatch-populated-tablet-matched-vehicle-tabs.png at 1024x768 after replacing the static vehicle header with vehicle tabs
• scratch/dispatch-visual-review/dispatch-visual-slice-final-fullscreen.png final visual slice check at 1920x1080
• scratch/dispatch-visual-review/dispatch-visual-slice-final-tablet.png final visual slice check at 1024x768
• The live seeded state showed no scheduled blocks for the selected day, so populated-list findings also use current Dispatch help screenshots.
• Related implementation: bf-manage-web/src/pages/Dispatch/index.tsx, BlockList, and VehicleList.

Empty-State Path Check

• Staging already showed the shared page-level EmptyState for some no-block cases.
• The local authenticated state had no schedules available, which caused useDayOfOpsSetup to disable setup and bypass the original shared empty-state branch.
• That fallback rendered the normal split block and vehicle panes, so the operator saw a visually noisy no-block workspace with sparse vehicle fragments.
• The implementation fix keeps the shared EmptyState and changes the no-block condition so local no-schedule, no-block states use the same full-panel empty state as the staged path.
• The no-schedules empty state now keeps an action button that links to Dispatch settings so the operator can upload a schedule before returning to setup.

Findings

1. The top command row is visually busy and has weak grouping.
2. Depot local time, date navigation, setup actions, destructive actions, undo, and settings sit in one long row with limited hierarchy.
3. Icon-only buttons on the right have unclear meaning without hover, especially delete, undo, and settings.
4. The disabled Set up day button still consumes primary attention even when it is unavailable.
5. At 1024px, the page controls wrap into two rows while the setup/settings actions float right, making the action order harder to follow.

6. Likely implementation area: bf-manage-web/src/pages/Dispatch/index.tsx.

7. The two-pane split is functional but visually heavy.

8. The center divider and shared bordered container make the page feel like one large table, while the two sides actually represent different tasks.
9. The panels are crashed together with only a 1px divider, so the block controls and vehicle controls feel like one compressed surface rather than two related work areas.
10. The left and right panel headers do not share a consistent baseline, type scale, or divider rhythm: block tabs sit at the top edge while the vehicle heading starts lower and uses much larger type.
11. The vehicle pane has a large empty lower area when the list is shorter than the block list.
12. The equal-width layout gives vehicle rows too much horizontal space and block cards too little scanning structure in some states.
13. In the empty/sparse state, the left pane is grey and the right pane is white, which makes the split feel accidental rather than purposeful.

14. Likely implementation area: ContentContainer in bf-manage-web/src/pages/Dispatch/index.tsx.

15. Block cards are hard to scan.

16. The purple time-span line dominates each card but does not clearly explain itself at a glance.
17. Block name, relative start time, absolute times, duration, assignment state, and actions compete for attention in a small vertical area.
18. The Unassigned pill repeats on every card and creates visual noise because nearly all visible cards share the same state.

19. Likely implementation area: BlockList and BlockCard under bf-manage-web/src/evenergi-ui/components/Dispatch/.

20. Controls inside panels are uneven.

21. Block tabs, the unassigned toggle, and sort control occupy separate horizontal bands, which costs vertical space before work items begin.
22. Vehicle search and sort align better, but the All Vehicles heading is oversized for a dense operations panel.
23. Horizontal rules and panel section lines do not line up across left and right panes, which makes the interface feel assembled from separate components rather than one coordinated dispatch surface.
24. The block side lacks a search control while the vehicle side has one, making the two panes feel inconsistent.
25. At 1024px, labels such as Show unassigned only and Sort by wrap awkwardly inside the toolbar.
26. The Show unassigned only toggle appears only halfway open/clipped in the tablet layout, which makes the control state ambiguous and visually broken.
27. The block tab dropdown, toggle, and sort control form a crowded toolbar that competes with the vehicle toolbar.

28. Likely implementation area: BlockList.controlRibbon and VehicleList.controlRibbon.

29. Vehicle rows have spacing and contrast issues.

30. Allocate buttons are repeated in a disabled state, drawing attention to actions the user cannot take.
31. The battery bar is long and visually dominant, while vehicle identity and operational state are comparatively small.
32. Percentage, kWh value, charging state, and vehicle type are spread across the full row, increasing eye travel.
33. In the sparse live state, Unknown now and - render as detached fragments rather than a coherent readiness summary.

34. Likely implementation area: VehicleList and VehicleCard.

35. Selected block detail improves context but still feels dense.

36. The selected card adds useful energy, distance, route, vehicle class, and allocation data, but the hierarchy is flat.
37. The selected outline is strong, while the inner allocation panel uses similar button and pill weight as the surrounding card.
38. The energy bar and allocation action sit on the same row as identity details, which makes the selected state harder to parse quickly.
39. Likely implementation area: BlockCard and VehicleSlot.

Populated-State Review

1. Tab state is technically accurate but operationally confusing.
2. The page opened on Future with zero blocks while Finished had three blocks, so the visible body still looked like a near-empty state.
3. The tab counts are helpful, but there is no prompt in the empty active tab to guide the operator toward the populated tabs.

4. Likely implementation area: BlockList.renderBlockCards no-block callout copy and tab presentation.

5. The selected finished block is too visually similar to actionable future work.

6. Finished blocks still show a prominent Unassigned state and selected-block allocation panel.
7. The right pane offers red Force allocate actions against finished work, even though the block is already in the past.
8. This weakens operator trust because historical status and active assignment actions are mixed.

9. Likely implementation area: BlockCard, VehicleList, and selected-block viability/action gating.

10. The tablet layout is usable but cramped.

11. The block tab dropdown, unassigned toggle, and sort control stack into a dense toolbar before the first block.
12. The toggle track is partially clipped in the toolbar, so the switch reads as broken before the operator even reaches the block list.
13. The two panels meet too tightly at the divider; there is no breathing room between the selected block card and the vehicle recommendation panel.
14. Selected block details wrap awkwardly: Block 1, finished timing, vehicle class, and estimate labels fight for space.
15. Vehicle rows become hard to compare because force-allocate actions, status, unknown energy values, and vehicle name wrap into uneven columns.

16. Likely implementation area: BlockList.controlRibbon, BlockCard selected layout, and VehicleCard.

17. Sparse vehicle telemetry is still visually noisy.

18. Unknown now, Unknown end, and - repeat on every row without a compact explanation.
19. The repeated red action buttons dominate more important readiness context.

20. Likely implementation area: VehicleCard readiness summary and action priority.

21. Panel typography and line rhythm need a coordinated pass.

22. The left pane leads with tabs and small toolbar labels, while the right pane leads with a large Recommended Vehicles/All Vehicles heading.
23. Divider lines, header heights, and content starts are misaligned between panes, so the eye cannot scan left-to-right cleanly.
24. This should be treated as a layout-system issue, not a one-off card tweak.
25. Likely implementation area: shared Panel, BlockList, VehicleList, and the page-level ContentContainer.

First Populated-Panel Fix

• Replaced the hard 1px center divider with a deliberate gutter between the block and vehicle panes.
• Added panel framing to both panes so they read as related but distinct work areas.
• Reduced the vehicle panel heading scale so it better matches the block-side tab/header rhythm.
• Stabilized the block toolbar at tablet width so the Show unassigned only toggle no longer appears clipped or half-rendered.
• Reverted the selected-finished-block behavior change. Finished-block allocation behavior needs a separate workflow decision before changing the logic.
• Aligned block and vehicle control-strip minimum heights at desktop and tablet widths, so toolbar rows occupy a steadier vertical rhythm across panes.
• Added a vehicle panel header row so search and sort sit in the second control row, matching the block side where tabs occupy the first row and filters/sort occupy the second row.
• Replaced the static vehicle header with real vehicle tabs (Available, Needs attention, All) based on the current requiresAttention signal, so both panels use the same tab/dropdown visual language.
• Moved vehicle lists onto the same grey work surface as the block list and rendered each vehicle as a compact white card.
• Reduced vehicle list section headings to compact labels with counts, and removed the redundant All section break because the active vehicle tab already provides that context.
• Tuned vehicle-card spacing to use a smaller block-like gap with slightly more internal padding.
• Remaining visual debt: finished block cards still show Unassigned prominently, block-card internals still have dense border/outline layers, and unknown telemetry still needs a more compact readiness summary.

Suggested First Fixes

1. Tighten the Dispatch shell before changing business behavior.
2. Give the page-level command row clearer left, center, and right groups.
3. Add accessible labels to icon-only action buttons.
4. Reduce visual priority for disabled setup actions.

5. Define a wrapped tablet layout where date controls and page actions keep a predictable order.

6. Improve panel structure.

7. Give each pane a clear compact header: Blocks and Vehicles.
8. Move tabs, search, filters, and sort into stable panel toolbars.
9. Add a deliberate gap or stronger panel framing between the block and vehicle panes instead of relying on a single 1px divider.
10. Align header baselines, typography scale, divider lines, and toolbar heights across both panes.
11. Fix the tablet toolbar so the Show unassigned only toggle has stable width and cannot be clipped.
12. Use sticky panel headers so controls remain visible while scrolling each list.

13. Make empty and sparse states visually balanced across both panes.

14. Improve dense scanning.

15. Reduce the visual dominance of repeated disabled actions and repeated Unassigned states.
16. Make block timing and vehicle readiness easier to compare by aligning key values in predictable columns or compact rows.
17. Tone down decorative lines and make them secondary to block identity, start time, and assignment state.

18. Replace detached unknown/empty vehicle values with a compact readiness summary.

19. Validate visually in browser before and after.

20. Use Playwright MCP at desktop and tablet widths.
21. Capture screenshots for default future view, selected block view, no selected block vehicle view, and narrow desktop/tablet layout.