Target — Apps and Mini-Apps
Section titled “Target — Apps and Mini-Apps”Full applications (monorepo/apps/sd-app), embedded mini-apps, and SD Snapshots.
All of Design-Principles binds. This is the most involved target, because an app is the one medium where progressive disclosure has somewhere to progress to.
Why apps differ
Section titled “Why apps differ”A page is stateless; an app has state, a session, and a user profile. Three consequences:
- Progression is real. A visitor who expanded “See all” can be remembered. Level 0 is not a compromise — it is the front door of a ladder.
- Defaults are the product. Most people never change one. A default is a design decision with more reach than any control.
- The person can be known. Region, profile, and prior inputs are available, so Tailored is achievable without asking.
Simplified Inputs and Outputs
Section titled “Simplified Inputs and Outputs”The core of this target, in Talbot’s own words:
- Inputs
- only input and analyze the impact of one or two key parameters, with all other inputs set to most common values (with User Profiles), as Steve Jobs would design it
- Simpler, less intimidating, especially for analyses with many parameters. Less resistance to start learning.
- Easier to understand impact of key parameters and message, which is most important
- Faster, to align with busy lives and short attention spans
- 80/20 Big Rocks approach alignment
- Easier to embed simple interactive analysis tool directly in educational web content (SD Snapshots components)
- Easier to fit analysis on smaller devices
- great approach for both SD Snapshots, and initial UX with full function SD App, only progressing to more details in direction user wants
- Core input for SD App is investable cash flow, but even that can be abstracted out by normalizing, analyzing strategies per “$100/mn of cash flow”
- Next core input is Income profile: middle vs high (encapsulated with 1-click on predefined User Profiles)
- Next core input is Savings period: again start with default of 10 yrs
- Snapshots and initial SD App UI: only input is Investor Profile: Middle-income, High-income
- Only show core inputs in UI, with rest behind a “See all” link
- Annual Investment (later Monthly)
- Loan interest rate
- Country/region is automatically determined by browser
- only input and analyze the impact of one or two key parameters, with all other inputs set to most common values (with User Profiles), as Steve Jobs would design it
- Outputs
- same approach to only show minimal most important metrics initially, with one or two common buttons to explore more details (context dependent to strategy), and a “More” link that reveals all other details for the few who care.
Two corollaries worth stating explicitly:
- Where a value has a defensible common case, it has a default. An input with no default is an input that should not be on the first screen.
- Normalization can remove an input entirely. Per “$100/mn of cash flow” above is the worked example — look for that move before adding a control.
Highest Impact Analysis
Section titled “Highest Impact Analysis”- Each one or two core (most important) inputs can be adjusted up and down, and the target output quantified for the relative change.
- The relative change from each input can be ranked to determine which has the highest marginal impact.
- To be more valuable, could let user decide which few inputs to do a highest impact analysis on, as some inputs are not controllable or not something the user wants to change. Example might be working longer (investing longer).
The progression ladder
Section titled “The progression ladder”The two sections above, expressed as shipping stages. Every calculator, analysis, or mini-app ships as a rung on this ladder — never as its top rung first.
| Level | Inputs shown | Purpose |
|---|---|---|
| L0 — Snapshot | One: the Investor Profile | Embeddable directly in educational web content. Fits a phone. Zero resistance to starting. |
| L1 — Core | One or two core parameters; everything else at common values via User Profiles. Rest behind a “See all” link. | The default app entry experience. |
| L2 — Full | The complete parameter set, reached only by the person who asked for it. | For the few who care. |
| L3 — Highest Impact | L2 plus marginal-impact ranking across the inputs the person says are controllable | See above. |
Outputs mirror the same ladder.
Ship L0 and L1 before L2 exists. An app that launches at L2 and plans to simplify later never simplifies.
Mini-apps and embeds
Section titled “Mini-apps and embeds”Mini-apps (LevPro, SD Snapshots) are L0/L1 by definition — they run inside educational content, on a phone, beside prose.
- The embed must be complete at L0. If it needs a second input to say anything, it is not an embed.
- It carries the host page’s brand tokens, never its own palette.
- It must degrade to something readable if scripting fails — the surrounding content still has to make sense.
Implementation
Section titled “Implementation”App-surface mechanics — how a SvelteKit app consumes brand tokens, theme wiring, which of the shared components are usable outside Astro — are repo-side: monorepo/docs/design/apps.md. Principles stay here.
sd-app was wired to the brand token SSOT on 2026-08-29 (monorepo 281f8ce): --primary derives from --primary-8, the Treasury Emerald anchor #004425; dark mode derives from --primary-3. Gaps and cautions are documented in apps.md — most importantly that pnpm colors is currently unsafe to run (monorepo-color-generator-safety) and that the app’s dark mode does not yet render, because nothing adds the .dark class.