Design Journal — Inline Picker & Meaning Canvas

🎯 Intent

What was I trying to achieve today?

  • Decide how to bring the ResumePanel inline into the dialogue flow.
  • Design a Meaning Canvas view for curating gathered answers.
  • Think through mobile compatibility for a multi-column layout.
  • Evaluate naming mismatches in the codebase.
  • First session using Claude Code CLI as a design partner.

🧭 Guiding Questions

What questions are shaping my thinking right now?

  • How does the picker become part of the conversation instead of replacing it?
  • Can the picker be reusable across different content sets, not just Ikigai?
  • What does curation look like after divergent answer gathering?
  • How do we encourage reflection over time instead of binge-sorting?
  • What’s the right mobile pattern for a four-column canvas?

🧠 Insight

What clicked?

  • The overview/picker is not a “resume screen” — it’s a conversational card type that shows options with progress.
  • Dialogue flow is divergent (gather answers). Meaning Canvas is convergent (grade and rank them).
  • A grading budget that replenishes on return visits creates the same respectful pacing as the attention budget.
  • The four-column Ikigai canvas maps naturally to swipeable tabs on mobile.
  • dialogueUi.ts is really just active question persistence — the name doesn’t fit.

🧱 Structure

What did I define?

  • Inline picker: a new bubble variant (e.g. variant: "picker") emitted into the message stream by DialogueSurface. Shows available pods with progress. Replaces the page-swap between overview and question modes.
  • Meaning Canvas: a separate route or overlay. Four columns (desktop) or swipeable tabs (mobile). Reads from the answers store grouped by category/tag. Adds +1/-1 voting per answer.
  • Grading budget: a new store tracking { budget: number, lastVisit: timestamp }. Replenishes on return visits. Same persistence pattern as answers.
  • dialogueDirector simplification: could reduce from “overview”/“question” toggle to just activePodId: string | null, since the surface handles everything.

⚙️ Decisions

What did I choose (and why)?

  • Keep the picker component reusable and content-agnostic — not tied to Ikigai pods specifically.
  • Inline it as a bubble in the dialogue stream rather than a separate view swap.
  • Meaning Canvas as a separate route/overlay, not inside the dialogue flow — different cognitive mode (curation vs conversation).
  • Swipeable tabs for mobile canvas — keeps the “one thing at a time” rhythm consistent with the dialogue UX.
  • CSS scroll-snap for swipe — no library needed.

🔄 Friction

What felt messy or uncomfortable?

  • The current overview/question binary in dialogueDirector is limiting.
  • Naming inconsistencies (dialogueUi.ts) add cognitive overhead.
  • Need to decide exactly when the picker appears in the conversation (on boot? after completion? both?).
  • Grading budget replenishment logic needs concrete rules (how many points? what interval?).

🌱 Learning

What new mental model formed?

  • Two phases of the same data: divergent gathering (dialogue) and convergent curation (canvas).
  • Budgets are a universal pattern in this system — attention budgets for input, grading budgets for curation.
  • Mobile constraints force clarity — if it works as swipeable tabs, the information hierarchy is right.
  • CLI-based design conversations work well for architectural thinking — fast iteration without context-switching.

➡️ Next Move

Single clear next step.

  • Rename dialogueUi.ts → activeQuestion.ts (or activePod.ts).
  • Build the inline picker as a new Bubble variant.
  • Remove the overview/question toggle from dialogueDirector.
  • Have DialogueSurface emit the picker at boot (returning user) and after pod completion.
  • Prototype the Meaning Canvas as a separate route with swipeable tabs.
  • Define grading budget rules (points per visit, cap, replenishment interval).

More posts