Hum Rahi

US-027.1 · Status Timeline — Visual Design & Component Specification¶

Epic: E2.3 — Citizen Report Status Tracking Owner: Rahul | Type: DESIGN | Priority: Should Have Story Points: 2 | Sprint Target: Sprint 4

📖 Story¶

As Rahul (a citizen), I want to see a visually clear timeline of every status change on my report's detail screen, so that I understand what has happened to my report and when, at a glance.

🎯 Goal & Context¶

The My Reports Dashboard (US-025) tells Rahul the current status of a report. This story answers the follow-up question: "How did it get here?" A timeline transforms a static status badge into a story of progress. It builds trust — citizens can see that action was taken, even if resolution takes time. This is a design-first story; its output is a signed-off component specification that unblocks US-027.2.

✅ In-Scope¶

• Visual design of the status timeline component for the Report Detail screen
• Design specification for each timeline node (status, timestamp, optional operator note)
• Visual treatment for the completed vs pending segments of the timeline
• Responsive layout within the mobile screen container (375px width reference)
• Design of the empty/initial state (only one status entry — Submitted)
• Handoff-ready spec delivered to frontend engineer before US-027.2 begins

❌ Out-of-Scope¶

• Frontend implementation (US-027.2)
• Operator notes content authoring (police panel story)
• Notification design (US-026)
• Web portal version of this timeline (Phase 2)

🗂️ Timeline Node Content Spec¶

Each node in the timeline must display the following:

🎨 Design Requirements¶

Timeline Structure¶

• Timeline flows vertically, top to bottom, oldest status at the top, most recent at the bottom
• Each status change is represented as a node connected by a vertical line
• The most recent node (current status) must be visually distinct — larger marker, bold label, or accent colour
• Completed nodes (past statuses) must appear visually subdued relative to the current node
• The connector line between nodes should visually indicate direction of progression (top → bottom = oldest → newest)

Status Node Visual States¶

Design Decision Needed: Should the timeline show only statuses that have occurred, or also show upcoming/expected statuses greyed out (e.g., "Resolved — Pending")? Confirm with PM before design begins.

Operator Note Treatment¶

• If an operator note exists on a node, display it as a secondary line of text below the timestamp
• Style it visually as a "remark" or "note" — indented, italic, or in a lighter weight — to distinguish it from the system-generated status label
• Character limit for display: 120 characters. Truncate with "Read more" expansion if exceeded
• If no note exists, do not show a blank space — the node collapses to title + timestamp only

Timestamp Format¶

• Display as: DD MMM YYYY, HH:MM (e.g., 24 Oct 2024, 14:30)
• Use 12-hour format with AM/PM if that is the app-wide convention — confirm with design system
• Do not display seconds
• If the status changed today, display as: Today, 14:30 for improved scannability

Empty / Initial State¶

• When a report has only one entry (Submitted), the timeline renders with a single node
• Do not show a "no history" message — the Submitted node is always the starting point
• This single-node state must look intentional, not broken

Placement on Report Detail Screen¶

• The timeline component sits below the report summary block (title, category, photo, location)
• It must be scrollable if the number of status entries overflows the visible screen
• A section heading above the timeline: "Status History"
• The timeline does not occupy a separate screen or modal — it is inline on the Report Detail screen

📏 Acceptance Criteria¶

🔗 Dependencies & Open Questions¶

✅ Definition of Done¶

• Design spec covers all node states (completed, current, single-node initial)
• Operator note presence and absence both designed
• Timestamp format documented and aligned with app convention
• PM sign-off received on design before handoff
• Spec annotated with spacing, colour tokens, and typography — ready for US-027.2 frontend implementation
• Predecessor dependency confirmed: US-027.1 must be Done before US-027.2 begins

Predecessor: US-025 (Report Detail screen context) Successor: US-027.2 (Frontend implementation)