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:

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 names.

Visual View Controls

Controls that affect only the visual representation belong in the visual view panel, not in the table area.

Common visual-specific controls:

• Zoom / pan — navigation (usually handled by the rendering library)
• Layer opacity — reveal overlapping regions on a dense map or diagram
• Layer toggle — show/hide categories or types
• Reset view — fit all elements into view; extent reset for maps

These controls do not affect the table. Do not put them in the table toolbar.

Controls that affect the shared data (filters, time range, category selection) belong outside both views, above or beside the layout, since they affect what appears in both.

Highlighting vs. Selection

These are distinct states:

Highlight (hover): Transient, shown while the pointer is over an element. Does not persist. Both views show a subtle version (e.g. 50% opacity overlay, or a faint row background). No interaction required to clear it — moving the pointer clears it.

Selection (click): Persistent until explicitly cleared. Both views show a strong, unambiguous visual (e.g. bright border, saturated colour, selected row background). Cleared by clicking elsewhere or pressing Escape.

Do not conflate these. A hover highlight that persists after the pointer leaves is confusing.

Analysis Beside the Data

A panel that explains or summarises the data on screen is a coordinated view, not a dialog. Open it beside the table, non-modal, page still scrollable. The user checks each claim against the rows it came from. A modal hides exactly those rows.

Performance Considerations

Coordinated views can trigger expensive re-renders if not carefully managed.

• Debounce hover highlights — do not update on every pointer-move event, only when the target element changes
• Use stable identity for items (a consistent ID) so React (or equivalent) can reconcile without re-creating elements
• For large datasets (1000+ items), virtualize the table regardless of the visual view
• For canvas- or WebGL-rendered views, avoid re-creating elements on each highlight — update style properties on the existing ones instead

Review Checklist

• Is selection state shared between views via a single store — not duplicated?
• Does clicking a row highlight the corresponding visual element, and vice versa?
• Does clicking a visual element scroll the table to the corresponding row?
• Are colour assignments identical in both views, defined from a single source?
• Is the shared legend shown once, not duplicated per view?
• Are visual-specific controls (zoom, transparency, layer toggle) in the visual panel, not the table?
• Does any analysis or summary panel sit beside the data, non-modal, with the page still scrollable?
• Are hover highlight and click selection visually distinct states?
• On mobile, is there a clear way to switch between views?
• Are hover events debounced to avoid unnecessary re-renders?