Timeline

Problem Context

• Events belong to one case, claim, order, application, person, incident, project, shipment, or process.
• Users need to understand sequence and causality more than compare columns, consume live updates, or complete current form steps.
• Events may be generated by people, systems, integrations, or scheduled milestones.
• The timeline may include past events, the current event, expected future events, collapsed groups, filters, or links to source records.

Selection Rules

• Choose timeline when the main user question is what happened, when it happened, who or what caused it, and what came next.
• Use feed when items keep arriving as a dynamic stream and reading-position preservation is central.
• Use activity log or audit log when users need exhaustive, immutable, compliance-grade evidence, field-level changes, actor IDs, retention, export, or search across logs.
• Use process list when users need planned journey guidance and task links rather than a record of events.
• Use step navigation when users are inside a current linear task and progress must reflect validated route state.
• Use table or data grid when users need to compare many events by shared columns, sort by multiple fields, or export records.
• Keep timeline items short and link to details instead of turning each event into a full case note.
• Label current and future expected events differently from completed historical events.
• Group long histories by date, phase, month, or status range while preserving visible order and hidden-count context.
• Avoid timeline when event order is uncertain, unimportant, or likely to be misread as causality.

Required States

• Default timeline with heading, order label, date or phase groups, and event markers.
• Past, current, expected future, cancelled, failed, warning, and system-generated event states.
• Expanded and collapsed event detail states.
• Filtered, grouped, searched, paginated, loading-more, no-events, and failed-load states.
• Hidden-range or hidden-filter count state when not all events are visible.
• Unknown time, approximate time, corrected timestamp, timezone, and duplicate-event states when applicable.
• Responsive narrow-screen state where date, title, actor, status, and actions remain readable.
• Linked source-record state when users need deeper case notes, documents, messages, or audit evidence.

Interaction Contract

• Each event has one stable identity, timestamp or date label, event title, and actor or system source when known.
• The visual marker and connector reinforce chronological order but do not carry the only meaning.
• Filtering and grouping never reorder events without stating the active order and hidden range.
• Expanding an event reveals supporting detail in place without hiding adjacent dates or changing event identity.
• Opening a source record preserves return context to the same event or date group.
• Current and future items are visually and textually distinct from completed history.
• Corrected, approximate, unknown, or timezone-sensitive times are labelled rather than silently normalized.
• Long timelines expose load, pagination, or range controls that preserve date boundaries and focus.

Implementation Checklist

• Define event identity, timestamp, date granularity, actor, source system, title, summary, status, type, detail route, and whether the item is past, current, or future.
• Choose the default order and state it in the UI, such as newest first, oldest first, grouped by date, or grouped by phase.
• Use semantic list structure with headings or time elements for date groups and event titles.
• Provide text labels for markers such as current, expected, failed, cancelled, system, warning, or corrected time.
• Add expansion only for concise supporting detail; route dense notes, documents, audit evidence, and comments to dedicated records.
• Design filters and range loading with visible hidden counts, active filters, empty results, retry, and order preservation.
• Preserve focus and scroll position when expanding events, filtering, loading older events, or returning from source records.
• Test long titles, missing actors, approximate dates, localization, timezones, keyboard order, screen-reader date grouping, and mobile wrapping.

Common Generated-UI Mistakes

• Using timeline as decorative chrome around a normal list with no meaningful time sequence.
• Omitting dates, actors, or event summaries and expecting icons to communicate the sequence.
• Mixing future tasks and completed events without text that distinguishes expectation from history.
• Replacing audit logs with simplified timeline summaries when users need exact evidence.
• Replacing a feed with timeline visuals while live insertion and ranking behavior remain unresolved.
• Replacing step navigation inside a form with a timeline that cannot validate progress.
• Letting filters or groups hide events without counts or range labels.
• Treating event order as causality when the product only knows timestamps.

Critique Questions

• What object, case, order, application, or process does this timeline belong to?
• Are users trying to understand event sequence, consume a live stream, follow a planned process, or complete current steps?
• Which event fields are required: date, time, actor, source, status, event type, summary, document, or action?
• How are current and future expected events distinguished from completed past events?
• What happens when events are filtered, grouped, corrected, duplicated, missing timestamps, or loaded in ranges?
• Would feed, activity log, audit log, process list, step navigation, table, or data grid better fit the task?