Theme
Customize the design system

Every control starts at the preset. Change one and every preview on the site follows, on this page and the next, until you reset it.

Contrast

Text against what it sits on. Below 4.5:1 fails WCAG AA for body text — the check a reviewer runs on any surface that takes a tone.

Waiting for the first preview to report its palette.

Corners

Sets all three radii at once. The individual values are under Geometry.

Brand 5

The accent seam an app actually brands itself through. Change these and you have made the decision a real `DesignTokens.graphite(...)` call makes.

Geometry 15

Square or rounded, and how heavy every line is. The radius row above the controls sets all three corners at once, because "what does square feel like" is one decision rather than three numbers.

Surfaces 17

Everything the app is painted ON — the ground behind the content (the frame paints it too), the cards over it, the well inset in a card, and the washes that show state.

Bands 10

The rail's head and the view bar beside it (one band across the top at 960 and wider), a pushed screen's bar, the compact bar and the compact nav bar — the band's fill, its rule, its hover and active faces, the resting field box on it, and the ink and accent control that sit on it. The rail's tree and its footer stay on the ground.

Text and controls 11

The ink ramp, the control outlines and the field's focus halo. Every pair the panel can break is watched by a contrast badge above.

Status 7

The three voices that mean something — danger, caution and ok — each as a foreground and a surface wash, danger with a border as well.

Data 5

The default pin head, its glyph and its halo, and the group bands. A pin's category color comes from the palette, named in the theme seed.

Map 11

The basemap's roles — land, water, parks, roads and their casings, buildings, labels — and the pending pin's gray. A raster basemap keeps its own imagery; these paint the map's plate and any kit-drawn map.

Scrollbars 6

Every scroller's bar: the thumb at rest and while hovered or dragged, the strip it rides, and the desk bar's thickness, side gap and corners. The desk half shows only while a fine pointer is attached; at touch the platform's own overlay keeps its size.

Advanced 6

Real controls that are not decisions — motion durations, the focus ring offset, the touch floor. Opens collapsed on purpose.

Take it with you

The Dart that reproduces what you are looking at. It is a real constructor call, because the configurator edits a real preset — what you copy is what an app can paste.

The steady screens

Every screen the suite is built from, live and yours to configure. Open one, move its knobs, and see what it becomes.

Records table
Reach for this when many records need columns, sorting and grouping in one scannable grid — columns: carries every bit of semantics, groupBy: and density: do the rest. The shape most screens take: a records table under the app shell, with grouping, sorting and per-row actions live. Change grouping to see the table regroup without touching the data. A verb on this screen has three homes and none of them is the bar: the primary one is the Fab (fab), view verbs like Export are the view-options surface's header affordance, and a record's own actions belong to the pushed record surface — see Detail's hosting knob.
Records list
Reach for this as the compact-class counterpart of the table — the same collection below the table breakpoint, one primary line per record under the same narrowing chrome. A verb on this screen has three homes and none of them is the bar: the primary one is the Fab (fab), view verbs like Export are the view-options surface's header affordance, and a record's own actions belong to the pushed record surface — see Detail's hosting knob.
Records cards
Reach for this to browse records as cards — five postures from dense scan rows to media browse tiles, with onOpen: as the card's single primary action. cardFor binds each row to posture-free slots and the grid picks the posture itself, so the record-to-media swap is the grid's decision rather than the screen's. A verb on this screen has three homes and none of them is the bar: the primary one is the Fab (fab), view verbs like Export are the view-options surface's header affordance, and a record's own actions belong to the pushed record surface — see Detail's hosting knob.
Records gallery
Reach for this when records are primarily images and the grid of tiles IS the collection. Rendered here with no image value, which is the real fallback state rather than a broken one. A verb on this screen has three homes and none of them is the bar: the primary one is the Fab (fab), view verbs like Export are the view-options surface's header affordance, and a record's own actions belong to the pushed record surface — see Detail's hosting knob.
Records map
Reach for this for any spatial view — pins on a geographic basemap or on a fixed background image, one widget for both. The selected record docks as a detail pane rather than a bespoke summary panel. A verb on this screen has three homes and none of them is the bar: the primary one is the Fab (fab), view verbs like Export are the view-options surface's header affordance, and a record's own actions belong to the pushed record surface — see Detail's hosting knob.
Dashboard
Reach for this when several measures share one screen and one narrowing — a snap grid of tiles, each never blank. A dashboard SCREEN is the records floorplan with its dashboard body (RecordsScreen + the dashboard slot); these are the parts it assembles. A tile's tap filters or opens, never both: a filtering tap scopes its value and every tile that reads that dimension reacts, because the bus broadcasts the predicate and excludes each tile from its own dimension, while an OPEN table's row or a map pin opens its record and writes nothing. A tile body insets flow content by 12 and leaves a table, a map or a platter flush — inset: overrides the inference from fillsBody: — and a grouped body is LabeledSection over a category grid, per group.
Detail
Reach for this for one record in full — mediaHeader: and fieldLayout: shape it, and it stays generic over the record type. It OPENS at large: the two-up split (960 and up) and the fields grid's third track (1200 and up) both show by default — paneAtEnd swaps which side the fixed pane takes. Start with sectionNav either way; it is a view-type swap rather than a setting, and tabs, jump and the plain stack are three different screens.
Form
Reach for this for any new or edit record form — fields: declares the shape, onSave: commits, autoAdvance: moves focus. Never hand-assemble a column of fields. Shown in the EDIT posture — a record loaded by id, every field seeded from it, and the delete affordance a new-record form does not have. It brings its own chrome, so this is the whole screen.
Thread
Reach for this for a feed or an open conversation — posts, replies, system events and the composer, as one grammar. The reply affordance is the surface's one loud action.
Settings
Reach for this for a grouped-settings screen — a micro-label heading over the kit's framed list, repeated per group. No spec of its own; it is the design system's settings reference screen made portable. Switches for instant-effect toggles, never a hand-rolled rows list.
Add people
Reach for this wherever a user brings people in, scoped to where they stand: invite by pasted email addresses, or make a join link with its expiry, use cap and approval, each with the access it grants. A pattern over the kit's fields, the same on both kits. The host passes the access it may hand out and does the inviting, so it names no access model.
Home
Reach for this for a person's front door: the apps (or any destinations) they can open, as a grid of category cards under a greeting, with no rail, no search and no facets. The floorplan owns the band (the brand, the organization item, the account button and sync), the greeting, the grid and its faces: the first sync on its way, and the empty face whose copy is yours. A door list that needs search, sort or grouping is a RecordsScreen, not this. Step through face to see each, and set organizations to two to see the organization item.
Import
Reach for this when a batch of records comes in — a file upload or a pull — and someone has to review what is staged before anything is committed. The floorplan owns the frame: the phase line, the summary band and its filter doors, the checks that gate Confirm, the commit footer and the discard dialog. The review body is yours, and a RecordsScreen there nests as embedded. Step through phase to see every face, and change confirmGate to see how Confirm waits for the checks.
Reader
Reach for this when someone reads one multi-page document — a handbook, a drawing set, a scanned form — one page at a time. The floorplan owns the frame: the page strip, the stage and its zoom, the page and load faces, the keys, and the details column beside the page. You resolve each page to an image or a page of a PDF and render the details. Step through state to see each face, and turn initialDetailsOpen off to start with the stage alone. Give it a markup binding per page and it draws and edits the page's real PDF annotations: the markup layer over the page, its toolbar, the comments panel in the details column and the conflict notice on the stage's modeline. A host composing those pieces beside a page of its own wraps them in one markup scope.

Everything else

Nothing fits? Building with it carries the sourcing gate — four legitimate answers, only one of which is "use the kit widget".