The "How the world got here" section #193

Closed
opened 2026-08-01 15:17:23 +00:00 by coilysiren · 2 comments
Owner

The existing 4 graphs are useless

A graph that would be useful: a vertical one that shows when a profession was unlocked (bright line, a color hue'd away from green) and when people take it (less bright, hue'd in the opposite direction)

Ux will be hard. Maybe the default shows all profession unlocks (not people) and the right side has buttons and when you click the button it slices to that profession + people. Mobile design will be hard though.

The existing 4 graphs are useless A graph that would be useful: a vertical one that shows when a profession was unlocked (bright line, a color hue'd away from green) and when people take it (less bright, hue'd in the opposite direction) Ux will be hard. Maybe the default shows all profession unlocks (not people) and the right side has buttons and when you click the button it slices to that profession + people. Mobile design will be hard though.
Owner

Design conclusion

Replace the current four progression sparklines and three rank lists with one vertical profession-history timeline. The primary task is to understand when each profession first appeared in the world, then inspect how people adopted one profession over time.

Interaction

  • The default state shows only each profession's first recorded unlock on one shared in-game time axis.
  • Desktop places a labeled profession selector beside the timeline. Selecting a profession replaces the overview with that profession's first holder and later adopters.
  • Mobile replaces the side buttons with one native Profession select above the timeline. The timeline keeps full width and never requires horizontal scrolling.
  • All profession unlocks is always available as the recovery action.
  • The selected profession belongs in ?profession= so the state is linkable and browser navigation remains meaningful.
  • Same-day adopters group into one expandable day row when individual labels would collide.

Visual encoding

  • A bright warm diamond marks the first recorded unlock.
  • Less-bright cool circles mark later adopters.
  • Shape, labels, and the legend carry meaning alongside color.
  • The chart keeps a neutral time rail and grid. No summary-card row or secondary leaderboard competes with the timeline.

Data contract

The frontend must not derive this view from citizens[].timeline. The server caps both citizen cards and their timelines, which can silently omit older adopters.

The progression backend should derive professionHistory from the complete GainProfession event set before presentation caps:

  • Keep the earliest event for each (profession, citizen).
  • Treat the earliest profession event as its first recorded unlock.
  • Return subsequent adopters with exact time, in-game day, and citizen.
  • Return completeness warnings when the exporter or row cap makes the history partial.
  • Exclude universal starter skills from this surface.
  • Sort professions and adopters chronologically.

The wording stays first recorded unlock because the exporter proves the first observed GainProfession event, not an independent official world-unlock event. If Eco exposes a stronger unlock event later, the data derivation can change without redesigning the interaction.

States

  • While loading, show one compact Tracing profession history… status.
  • A fetched but empty GainProfession export shows No profession gains recorded yet.
  • A selected profession with no later adopters shows the unlock marker and No later adopters recorded.
  • Partial data remains visible with an incomplete-history warning.
  • A failed progression request leaves the rest of Jobs intact and omits this best-effort section.

Validation requirement

Desktop and mobile behavior need browser evidence before implementation is accepted. The hosted Playwright service already exists, but the canonical native inventory currently omits it after a WIP removal. Restoring and verifying that surface is tracked in agentic-os-kai issue 808. eco-app should not add a repo-local Playwright MCP dependency.

## Design conclusion Replace the current four progression sparklines and three rank lists with one vertical profession-history timeline. The primary task is to understand when each profession first appeared in the world, then inspect how people adopted one profession over time. ### Interaction * The default state shows only each profession's first recorded unlock on one shared in-game time axis. * Desktop places a labeled profession selector beside the timeline. Selecting a profession replaces the overview with that profession's first holder and later adopters. * Mobile replaces the side buttons with one native `Profession` select above the timeline. The timeline keeps full width and never requires horizontal scrolling. * `All profession unlocks` is always available as the recovery action. * The selected profession belongs in `?profession=` so the state is linkable and browser navigation remains meaningful. * Same-day adopters group into one expandable day row when individual labels would collide. ### Visual encoding * A bright warm diamond marks the first recorded unlock. * Less-bright cool circles mark later adopters. * Shape, labels, and the legend carry meaning alongside color. * The chart keeps a neutral time rail and grid. No summary-card row or secondary leaderboard competes with the timeline. ### Data contract The frontend must not derive this view from `citizens[].timeline`. The server caps both citizen cards and their timelines, which can silently omit older adopters. The progression backend should derive `professionHistory` from the complete `GainProfession` event set before presentation caps: * Keep the earliest event for each `(profession, citizen)`. * Treat the earliest profession event as its **first recorded unlock**. * Return subsequent adopters with exact time, in-game day, and citizen. * Return completeness warnings when the exporter or row cap makes the history partial. * Exclude universal starter skills from this surface. * Sort professions and adopters chronologically. The wording stays **first recorded unlock** because the exporter proves the first observed `GainProfession` event, not an independent official world-unlock event. If Eco exposes a stronger unlock event later, the data derivation can change without redesigning the interaction. ### States * While loading, show one compact `Tracing profession history…` status. * A fetched but empty `GainProfession` export shows `No profession gains recorded yet.` * A selected profession with no later adopters shows the unlock marker and `No later adopters recorded.` * Partial data remains visible with an incomplete-history warning. * A failed progression request leaves the rest of Jobs intact and omits this best-effort section. ### Validation requirement Desktop and mobile behavior need browser evidence before implementation is accepted. The hosted Playwright service already exists, but the canonical native inventory currently omits it after a WIP removal. Restoring and verifying that surface is tracked in [agentic-os-kai issue 808](https://forgejo.coilysiren.me/coilyco-bridge/agentic-os-kai/issues/808). eco-app should not add a repo-local Playwright MCP dependency.
Owner

Browser-validation correction

The validation dependency is not a single restored Playwright server.

  • playwright_local provides the isolated headless browser that can inspect a localhost eco-app development surface at desktop and mobile widths.
  • playwright_k3s preserves the hosted shared-context browser for durable shared state and cluster-reachable surfaces.
  • eco-app owns neither registration and adds no Playwright dependency.

The corrected setup is tracked in agentic-os-kai issue 808.

## Browser-validation correction The validation dependency is not a single restored Playwright server. * `playwright_local` provides the isolated headless browser that can inspect a localhost eco-app development surface at desktop and mobile widths. * `playwright_k3s` preserves the hosted shared-context browser for durable shared state and cluster-reachable surfaces. * eco-app owns neither registration and adds no Playwright dependency. The corrected setup is tracked in [agentic-os-kai issue 808](https://forgejo.coilysiren.me/coilyco-bridge/agentic-os-kai/issues/808).
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-gaming/eco-app#193
No description provided.