Daybreak design system¶
Daybreak is the name of this app's design system: the shared color, spacing, and type tokens in src/theme/, the presentational components in src/components/, and the accessibility conventions that bind them together.
Why "Daybreak"¶
The name follows the product, not the other way around. A few reasons it fits.
-
It matches the core loop. The app is built around a daily check-in, the Today screen and the good-days framing. Daybreak carries that sense of a fresh start each morning, the gentle beginning of a new day rather than a clinical event.
-
It sets the right register. This is a wellness practice for older adults, built with seniors rather than for them. Daybreak reads as calm, warm, and human. It signals dignity and light rather than diagnosis or deficit, which is the tone the whole system is meant to hold.
-
It names light, and light is what the system is about. Accessibility is a build requirement here: measured contrast ratios in colors.ts, 44pt touch targets, font scaling never disabled, reduced motion respected. A system organized around clarity and legibility is well served by a name that means the return of light.
-
It is short and ownable. "The Daybreak design system," a
daybreaktoken namespace, and everyday sentences like "use a Daybreak surface color" all read naturally in code and in conversation. It avoids collision with established systems in this space; notably we did not choose "Clarity," which is already a well-known design system and an overloaded word in accessibility work.
Scope¶
Daybreak is the single source of truth for how the app looks and behaves at the component level. It covers the design tokens (color with contrast ratios, the 4-point spacing scale, the type scale), the shared primitives that consume them, and the accessibility rules in docs/accessibility.md that every component is expected to honor. New surfaces should build from Daybreak tokens and primitives rather than introducing one-off values.
It also covers how much fits. The one-screen rule is a Daybreak
constraint: every screen is laid out in the Screen frame, sized so its content fits the
display window without scrolling at either text size, and every authored string has a
character budget that CI enforces. Text and controls take the height they need; media is
the elastic part; lists that can grow are paged rather than scrolled.
The tokens are sized for the smallest supported display and then scaled to the window the
app is actually in — about 1.15x on a large phone, about 2x on an iPad. Type, spacing,
icon sizes and media floors all move together, so a screen on a tablet is the same design
drawn larger rather than a phone layout with empty margins. Components read the factor
from useDisplayScale and the scaled scale from useScaledSpacing.
User appearance settings¶
Daybreak's type scale and palettes are the base; the user bends them through the
Appearance Settings: a light/dark theme override, a text size
(Large or Extra large), and a font family (sans-serif, serif, or monospace). The tokens
behind this live in
typography.ts:
fontSizeMultipliers, fontFamilies (platform system fonts only), and
resolveTypeStyle, which ThemedText uses for every variant.
Two rules keep the system coherent:
- Never style text from the raw
typeScaletokens in a component; useThemedText'svariantprop (orresolveTypeStylewhere a bareText/TextInputis unavoidable), or the user's settings will not reach that text. - At the default settings the resolved style equals the base type scale exactly, so adding an option must never change the standard look.