coordinated-data-views

Name: coordinated-data-views
Author: dembrandt

27stars5forks

How to install coordinated-data-views?

dembrandt/dembrandt-skills/coordinated-data-views

$npx -y skills add dembrandt/dembrandt-skills --skill coordinated-data-views

Installs into the current project.

Summary

When data has both a tabular/list representation and a visual representation, show both simultaneously and keep them synchronized. Clicking a row highlights the corresponding element in the visual view, and vice versa. Applies to maps, diagrams, timelines, and charts that accompa

Files · 1

View on GitHub

SKILL.md

1	# Coordinated Data Views
2
3	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.
4
5	The core rule: any selection or highlight made in one view is immediately reflected in the other.
6
7	---
8
9	## When to Use Coordinated Views
10
11	Use coordinated views when:
12
13	1. The two representations serve different tasks — the table is for finding/scanning; the visual view is for understanding arrangement or relationships
14	2. Users will frequently move between the two — not just glance at one occasionally
15	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
16
17	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.
18
19	---
20
21	## The Synchronized Selection Model
22
23	Selection state is owned by a single shared store, not by either view. Both views read from and write to the same state.
24
25	```
26	Table row clicked → shared highlight state updated → both views re-render
27
28	Visual element clicked → shared highlight state updated → both views re-render
29	```
30
31	What synchronization covers:
32
33	\| Interaction \| Effect in table \| Effect in visual view \|
34	\|---\|---\|---\|
35	\| Click row \| Row highlights \| Corresponding element highlighted \|
36	\| Click visual element \| Corresponding row highlighted, scrolled into view \| Element highlighted \|
37	\| Hover row \| Subtle row highlight \| Subtle element highlight \|
38	\| Hover visual element \| Subtle row highlight \| Subtle element highlight \|
39	\| Clear selection \| Row returns to default \| Element returns to default \|
40
41	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.
42
43	---
44
45	## Consistent Colour Coding
46
47	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.
48
49	Define colours centrally:
50
51	```ts
52	const CATEGORY_COLORS = {
53	groupA: 'hsl(24, 80%, 55%)',
54	groupB: 'hsl(210, 70%, 55%)',
55	groupC: 'hsl(145, 60%, 45%)',
56	} as const;
57	```
58
59	Both the table cell renderer and the visual element renderer import from the same source.
60
61	A shared legend appears once in the layout — not duplicated in each view.
62
63	---
64
65	## Layout
66
67	The split between views depends on which is primary:
68
69	Table-primary (exploration, data management): Table takes 60–70% of the width; visual view is a companion panel on the right or bottom.
70
71	Visual-primary (understanding arrangement and relationships): Visual view takes 60–70%; table is a supporting panel.
72
73	Equal weight: A 50/50 split with a draggable divider. Persist the user's preferred split.
74
75	```
76	┌─────────────────────┬────────────────┐
77	│ │ │
78	│ Table (primary) │ Visual view │
79	│ │ │
80	└─────────────────────┴────────────────┘
81	```
82
83	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.
84
85	---

People who liked this also viewed

6 picks

Type

coordinated-data-views

27stars5forks

View on GitHub

How to install coordinated-data-views?

dembrandt/dembrandt-skills/coordinated-data-views

$npx -y skills add dembrandt/dembrandt-skills --skill coordinated-data-views

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Coordinated Data Views
2
3	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.
4
5	The core rule: any selection or highlight made in one view is immediately reflected in the other.
6
7	---
8
9	## When to Use Coordinated Views
10
11	Use coordinated views when:
12
13	1. The two representations serve different tasks — the table is for finding/scanning; the visual view is for understanding arrangement or relationships
14	2. Users will frequently move between the two — not just glance at one occasionally
15	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
16
17	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.
18
19	---
20
21	## The Synchronized Selection Model
22
23	Selection state is owned by a single shared store, not by either view. Both views read from and write to the same state.
24
25	```
26	Table row clicked → shared highlight state updated → both views re-render
27
28	Visual element clicked → shared highlight state updated → both views re-render
29	```
30
31	What synchronization covers:
32
33	\| Interaction \| Effect in table \| Effect in visual view \|
34	\|---\|---\|---\|
35	\| Click row \| Row highlights \| Corresponding element highlighted \|
36	\| Click visual element \| Corresponding row highlighted, scrolled into view \| Element highlighted \|
37	\| Hover row \| Subtle row highlight \| Subtle element highlight \|
38	\| Hover visual element \| Subtle row highlight \| Subtle element highlight \|
39	\| Clear selection \| Row returns to default \| Element returns to default \|
40
41	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.
42
43	---
44
45	## Consistent Colour Coding
46
47	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.
48
49	Define colours centrally:
50
51	```ts
52	const CATEGORY_COLORS = {
53	groupA: 'hsl(24, 80%, 55%)',
54	groupB: 'hsl(210, 70%, 55%)',
55	groupC: 'hsl(145, 60%, 45%)',
56	} as const;
57	```
58
59	Both the table cell renderer and the visual element renderer import from the same source.
60
61	A shared legend appears once in the layout — not duplicated in each view.
62
63	---
64
65	## Layout
66
67	The split between views depends on which is primary:
68
69	Table-primary (exploration, data management): Table takes 60–70% of the width; visual view is a companion panel on the right or bottom.
70
71	Visual-primary (understanding arrangement and relationships): Visual view takes 60–70%; table is a supporting panel.
72
73	Equal weight: A 50/50 split with a draggable divider. Persist the user's preferred split.
74
75	```
76	┌─────────────────────┬────────────────┐
77	│ │ │
78	│ Table (primary) │ Visual view │
79	│ │ │
80	└─────────────────────┴────────────────┘
81	```
82
83	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.
84
85	---

People who liked this also viewed

6 picks

Type