coordinated-data-views

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.