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.
\nThe core rule: any selection or highlight made in one view is immediately reflected in the other.
\nUse coordinated views when:
\nDo 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.
\nSelection state is owned by a single shared store, not by either view. Both views read from and write to the same state.
\nTable row clicked → shared highlight state updated → both views re-render\n\nVisual element clicked → shared highlight state updated → both views re-render\nWhat synchronization covers:
\n| Interaction | \nEffect in table | \nEffect in visual view | \n
|---|---|---|
| Click row | \nRow highlights | \nCorresponding element highlighted | \n
| Click visual element | \nCorresponding row highlighted, scrolled into view | \nElement highlighted | \n
| Hover row | \nSubtle row highlight | \nSubtle element highlight | \n
| Hover visual element | \nSubtle row highlight | \nSubtle element highlight | \n
| Clear selection | \nRow returns to default | \nElement returns to default | \n
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.
\nColour 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.
\nDefine colours centrally:
\nconst CATEGORY_COLORS = {\n groupA: 'hsl(24, 80%, 55%)',\n groupB: 'hsl(210, 70%, 55%)',\n groupC: 'hsl(145, 60%, 45%)',\n} as const;\nBoth the table cell renderer and the visual element renderer import from the same source.
\nA shared legend appears once in the layout — not duplicated in each view.
\nThe split between views depends on which is primary:
\nTable-primary (exploration, data management): Table takes 60–70% of the width; visual view is a companion panel on the right or bottom.
\nVisual-primary (understanding arrangement and relationships): Visual view takes 60–70%; table is a supporting panel.
\nEqual weight: A 50/50 split with a draggable divider. Persist the user's preferred split.
\n┌─────────────────────┬────────────────┐\n│ │ │\n│ Table (primary) │ Visual view │\n│ │ │\n└─────────────────────┴────────────────┘\nOn mobile, show one view at a time with a tab or toggle to switch. Do not attempt to show both on a small screen.
\nControls that affect only the visual representation belong in the visual view panel, not in the table area.
\nCommon visual-specific controls:
\nThese controls do not affect the table. Do not put them in the table toolbar.
\nControls 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.
\nThese are distinct states:
\nHighlight (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.
\nSelection (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.
\nDo not conflate these. A hover highlight that persists after the pointer leaves is confusing.
\nCoordinated views can trigger expensive re-renders if not carefully managed.
\n