--- type: plan title: The road to a usable easel slug: road-to-usable status: active owner: adi created: 2026-09-01 related: - /srv/apps/easel/.logs/planning/next-milestone-onboarding-and-variants.md - /srv/apps/easel/.logs/planning/prototype-overview-teardown.md summary: > What easel still needs before it is used for real, defined against one concrete event: rian presenting the league concepts to darren. Finishes rian's M2 asks 3 and 4, proves the client journey with a human, and closes the notification loop. Everything the prototype teardown surfaced that only pays off at scale is deliberately deferred, with the reason recorded. --- # The road to a usable easel **The definition of "usable" this plan works to:** rian can send the League & Williams concepts to darren, and the round completes — darren understands the tool, leaves feedback we can act on, and locks a direction — **without anyone apologising for the software.** Not "feature complete". That event. Everything below is measured against it. If a thing does not change how that send goes, it is not in this plan. ## Where we actually are Built and live (v0.8.1): the board (wide, per-option thumbnails, browser framing, search), the viewer (sandboxed mockups, pins as threads, play/comment, the discussion drawer), the guided walkthrough with per-step approvals, the tool tour on arrival, the contents pane, stars on parts, direction pick **and** unpick, the bell, and the six-state rollup. **rian's four M2 asks: 1 and 2 are done** (tool walkthrough on arrival; sidebar contents). **3 and 4 are not started** — and they are the two that change what darren actually sees. ## Stage 1 — Finish M2. This is the spine. ### 1a. Two options plus toggleable variants (rian's ask 3) Collapses the six-option plan to two, making every comparison one-variable. Three decisions the milestone said to make deliberately; here they are, with reasons, so a later session does not silently re-open them: - **How a variant is expressed: a CSS class toggled on `` through the bridge.** One bundle, instant toggling, no reload — and the bridge already exists and already resolves selectors for the walkthrough. The cost is that concepts must be authored with the class in mind, which is fine because the same person authors them. The same authoring discipline is what a future region model would need, so it is not a one-off. - **A variant choice IS part of the locked direction.** Settled on Adi's own authority, not a guess: his closing pin Z reads *"Pick an opening … AND a brand level … tick your choice in the option list."* Two decisions. So the selection is `selected_option_id` + a `selected_variants` JSON, and rollup's `done` must require both. - **Pins stay per OPTION, not per option-per-variant.** Simplest, and it is Adi's existing rule. The failure mode of the alternative is much worse: a client toggles a variant, their own feedback disappears, and they conclude the tool lost it. A pin whose anchor drifts slightly is a smaller problem than a pin that vanishes. ### 1b. Option 2 gets a smaller hero (rian's ask 4) Design work in `leaguelaw`, not easel code, then re-seed. Under the two-option model: **option 1 = The Direct Answer** (no hero, the compliance reference rian greenlit), **option 2 = a reduced-height hero** closer to the firm's existing site — not the full-screen treatment. Re-seeding needs `docker exec` (owner-only) OR is done through the UI as an admin. Prefer the UI: it needs nobody. ### 1c. Content hygiene — cheap, and it is what darren reads - The project **description renders directly under the title for the client**. Confirm it is not still "seeded by Claude — curation pending Adi's review". - Option names and concept tags are client-facing. The designer notes already specify them: The Direct Answer / The Welcome Desk / The Bold Welcome, with Quiet brand / Full hive as the badge — which under the new model becomes the variant toggle. - The tool tour is four beats and should stay four. The design walkthrough carries Set A; pins 2 and 3 have already moved out of it into the tour. ## Stage 2 — Prove it with a human. Not optional. Two of the three defects rian found on 2026-09-01 (missing bundle images, the spotlight on the wrong element, the clipped right edge) were invisible to 94 green tests. **The visual pass is the highest-value check on this project and it has never been done on any of the M2 work.** - **The full journey as a client, with WRITE access.** `easel-qa-client` exists; its 48h set-password link is in `.qa-invite.txt` (0600, rian) and has almost certainly expired — ask rian to reissue. View As alone is read-only, so it cannot test commenting, approving, starring or choosing. - **Phone width.** Every client-reachable surface has a phone floor and NOTHING from v0.5.0 onward has been looked at there — the tour bubble, the contents strip, the option tiles, the confirm dialog. - Land cold, run the tour, leave a note, get a reply, star parts, pick a direction, unpick it. Write findings into `handoff.md` as before. ## Stage 3 — Close the loop **easel sends no email.** A client who closes the tab learns nothing until they come back — including that we replied to them. For the first send rian tells darren by hand, so this does not block Stage 1; it does limit the round after. Needs a decision from rian, not a config change: the gateway holds a Resend key but its send endpoint is owner/hosting-peer only with its own recipient allowlist. **Two moments are worth an email and no others**: "concepts are ready for you" and "we answered your note". Everything else is bell-only. ## Deliberately deferred, with the reason From the prototype teardown — all genuinely good, none of it changes this send: - **Screen hierarchy, the sitemap view, the list/tracker view.** These earn their place on a 15-screen project. League has **two** screens. A sitemap of two nodes and a spreadsheet of two rows are worse than the board. Build them when a project needs them, not before. - **Stakeholders panel.** One client contact on this engagement. - **The delivery pipeline and `dev_url`.** Not deferred on cost — out of scope. `building_page` and `waiting_review` against staging are `review`'s job (brief.md, "Not doing"). Porting them makes easel into review. - **Region starring / the comparison matrix.** Already scoped down once by Adi; the per-beat star shipped instead. - **Caddie registration.** Blocked on caddie M2 — the drop-ins do not exist. The seams are built and tested; nothing to do here until they land. ## Order, and why 1. **1c content hygiene** — hours, and it is what the client reads first. 2. **1a variants** — the biggest build, and the thing rian asked for. 3. **1b option 2 hero** — design, then re-seed through the UI. 4. **Stage 2 human pass** — after the above, so it tests what will actually ship. 5. **Stage 3 email** — rian's decision; can run in parallel. Stage 2 is the gate. Nothing ships to darren that a person has not walked through at desktop AND phone width.