Key nodes must look different from ordinary events

What it is

Most nodes on a timeline are ordinary records: a comment, a sync, a routine status. A few change the story — a release, an incident, a permission change, a milestone. Key-node distinction means those two kinds are not the same mark on the axis. On a scan, the key ones should be caught first; ordinary ones supply context without tying the key ones.

Why it happens

Scanning a timeline is looking for turns. If a turn lives only in the copy, the eye follows the rhythm of the dots and reads a release as equal to a bot comment; the turn is drowned. Distinction has to move shape, size, or position, not colour alone: colour is a weak sole channel under colour-vision difference and a fast scan. A key node spends a larger pause — a bigger mark, a title of its own, even a card that breaks the axis — while ordinary nodes stay dense and light. Over-distinction erases ordinary history, the line becomes a few islands, and context is gone. What counts as key should follow event type and consequence, not “what marketing wants to push”; making an advert node a milestone trains people to ignore every large node. Key and ordinary still share one axis, at different weights; do not pull key events onto a parallel line so sequence has to be compared across axes.

Studying it

On a timeline that holds one incident and many routine logs, compare all nodes isomorphic, key nodes enlarged, and key nodes in a second column. Tasks: “find the incident” and “say what happened just before and after.” Independent variables: means of distinction (size / hue / position). Dependent variables: time to find, missed incident, failure to recall neighbouring ordinary events. Hue-only should be weaker on find than size; a second column should be worst on recalling context.

Where it stops holding

An audit log whose task is “every row matters equally” should not distinguish keys; that would filter on the user’s behalf. A filter to “key only” is legitimate — that changes the set, it is not visual weight on one axis. In a live stream, a just-arrived node may take a brief emphasis and then fall back to the weight its type deserves, or “new” will impersonate “key.” For assistive tech, key must be speakable as a name or state, not only look larger.

Applying it

• Give consequence-changing event types a larger form than ordinary nodes, and put that type in the accessible name (“release,” “incident”).
• Do not distinguish by hue alone. Do not make marketing nodes into milestones.
• Keep key nodes on the time axis, with ordinary nodes beside them as context.
• How to check: squint or shrink to a thumbnail and still count the key nodes. If you cannot, distinction has not left the copy.

Related

• Within the group: E4.21.1 A timeline lays out discrete events in time order · E4.21.2 When event density is uneven, ticks should not be equal linear intervals · E4.21.3 A stream needs a clear start, or a load-more edge
• Adjacent: E6.11 Badges and dots · E4.17 List grouping and sticky headers
• Search terms: milestone · event emphasis · visual hierarchy