/coordinated-data-views

name: coordinated-data-views
description: Show a table and its map, diagram, timeline or chart together, with selection synced both ways. Use when data appears in two representations at once.
metadata:
  priority: 6
  pathPatterns:
    - "components/**"
    - "src/components/**"
    - "**/*.tsx"
    - "**/*.jsx"
    - "app/**"
  promptSignals:
    phrases:
      - "map view"
      - "chart view"
      - "visualization"
      - "linked views"
      - "coordinated"
      - "highlight"
      - "synchronize"
      - "side by side"
      - "table and chart"
      - "diagram and list"
retrieval:
  aliases:
    - coordinated views
    - linked views
    - chart and table
    - map and list
    - linked visualization
    - synchronized views
    - two representations
    - dual view
    - visual and tabular
  intents:
    - synchronize a chart with a data table
    - link a map to a list
    - highlight items across two views
    - design a dual-view layout
    - coordinate a chart with a table
    - keep two views in sync
  examples:
    - clicking a row should highlight it in the map view
    - the map and the list should stay in sync
    - show a diagram and a table for the same data
    - how should a visual view and a table interact
    - the user should be able to select from either the chart or the list

Coordinated Data Views

Some data has more than one natural representation. A set of locations has both a map and a list. A dependency network has both a diagram and a node table. A dataset has both a chart and a raw table. When both representations are genuinely useful for different tasks, show them simultaneously and keep them synchronized — this is called a coordinated view.

The core rule: **any selection or highlight made in one view is immediately reflected in the other.**

---

When to Use Coordinated Views

Use coordinated views when:

1. The two representations serve different tasks — the table is for finding/scanning; the visual view is for understanding arrangement or relationships 2. Users will frequently move between the two — not just glance at one occasionally 3. The dataset is large enough that the visual view alone doesn't identify individual items, and the table alone doesn't communicate how they relate

Do not add a coordinated view purely for visual richness. If users only ever look at the table and ignore the visual view, it adds complexity without benefit.

---

The Synchronized Selection Model

Selection state is owned by a single shared store, not by either view. Both views read from and write to the same state.

Table row clicked → shared highlight state updated → both views re-render

Visual element clicked → shared highlight state updated → both views re-render

**What synchronization covers:**

| Interaction | Effect in table | Effect in visual view | |---|---|---| | Click row | Row highlights | Corresponding element highlighted | | Click visual element | Corresponding row highlighted, scrolled into view | Element highlighted | | Hover row | Subtle row highlight | Subtle element highlight | | Hover visual element | Subtle row highlight | Subtle element highlight | | Clear selection | Row returns to default | Element returns to default |

**Scroll-into-view:** When a visual element is clicked, the table must scroll to bring the corresponding row into view. A row that is highlighted but off-screen is useless.

---

Consistent Colour Coding

Colour meaning must be identical in both views. If a category is orange in the table badge, it is orange in the visual view. Never use different colour assignments for the same data in different representations.

Define colours centrally:

const CATEGORY_COLORS = {
  groupA: 'hsl(24, 80%, 55%)',
  groupB: 'hsl(210, 70%, 55%)',
} as const;

Both renderers import from the same source. A shared legend appears once in the layout, not in each view.

**Colour encodes state, the label encodes identity.** When every item already shows its own name, give all items of one kind the same colour and spend colour on state alone: planned, partly used, free, unavailable. Tints of one hue read as magnitude, not as different things, and a grey item collides with the grey that means empty. Show that one item recurs by highlighting all its occurrences on hover or selection. The legend then explains states and never lists items, because the labels already do.

---

Layout

The split between views depends on which is primary:

**Table-primary (exploration, data management):** Table takes 60–70% of the width; visual view is a companion panel on the right or bottom.

**Visual-primary (understanding arrangement and relationships):** Visual view takes 60–70%; table is a supporting panel.

**Equal weight:** A 50/50 split with a draggable divider. Persist the user's preferred split.

┌─────────────────────┬────────────────┐
│                     │                │
│   Table (primary)   │  Visual view   │
│                     │                │
└─────────────────────┴────────────────┘

On mobile, show one view at a time with a tab or toggle to switch. Do not attempt to show both on a small screen.

Timelines and Calendar Grids

Place every mark on a time axis by the time it covers, never by a count of units. When units per day vary, give each day the same width and divide the day among the units it actually has, so a mark that ends with the day's last unit ends on the day seam. A width derived from a share of the unit count drifts as soon as days hold different numbers, and the bar then contradicts the grid beside it, so the reader trusts neither.

Build a calendar or matrix from one unit, a square cell plus one gap, and put every row on that pitch, labels included. When the window changes, change how many columns show, not the size of the cell. Keep the grid packed against its row labels and leave the spare width at the far end; a flexible label column on a wide screen pushes the grid away from what it