E4.21.1timeline as ordered discrete eventsdesignresearch

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

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/E4.21.1