A timeline lays out discrete events in time order
Aliases: event timeline · chronological axis · history of events
What it is
A timeline lines up things that have happened or will happen, and position means sequence. It is ordered discrete events, not a progress bar for one continuous process, and not a feed ranked by heat. Each status change, commit, or meeting is a nameable node; the gap between nodes means “no other event sits here,” not “nothing happened in that interval.” Putting a still-unfolding article, or a set of peer attributes, on a timeline forces sequence onto things that should not have one.
Why it happens
Time order is a strong constraint: earlier at one end, later at the other, answering “and then?” and “before that?” For the axis to hold, each node must be a separable event, not an unslicable stream. A progress bar says how far one thing has gone; a timeline says which of several things came first. A feed may sort by recency among other keys, but the layout does not promise a readable time axis — newest is not bound to a fixed end. A timeline also needs a stable direction (newer toward the top, or the reverse); flipping mid-way reverses “then.” Time labels on nodes are the axis’s ticks; order without ticks still yields sequence, but not interval. Whether interval should be drawn as real duration is a different question.
Studying it
Present the same events as a timeline, a priority list, and a progress bar, and ask “which came before which” and “how far is this complete.” Independent variables: structure type, presence of time labels. Dependent variables: sequence judgements, wrongly treating the timeline as progress. Sequence should worsen on a progress bar; “how complete” should be unanswerable on a timeline — the structure constrains the questions that can be asked.
Where it stops holding
A process still underway that cannot be sliced into events (a download, a render) wants progress, not a timeline. Chat is ordered in time, but each message is a turn; the timeline kit of node-plus-axis is often too heavy, and the message stream already is the order. A calendar grid is two-dimensional time, not a one-dimensional timeline. Past and future on one axis need a “now” anchor, or direction will read things that have not happened as history.
Applying it
- Use a timeline only when sequence is the main question. Peer comparison belongs in a table or a list.
- Fix a direction and mark it on the axis; give nodes a readable time.
- Do not draw a step wizard as a timeline — steps are planned order, not necessarily events that have occurred.
- How to check: cover the copy and look only at axis and nodes. If three events’ order cannot be spoken, it is not yet a timeline.
Related
- Within the group: 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 · E4.21.4 Key nodes must look different from ordinary events
- Adjacent: E4.17 List grouping and sticky headers · E5.10 Steppers
- Search terms:
timeline·event sequence·temporal order