Screens
Whole composed surfaces, specified as units. This is where a correct component and a wrong page order still produce an unusable result.
Overview
A component page tells you whether one part is right. A screen page tells you whether the assembly is. Those are different questions, and the second one is the one that ships: every component on a screen can pass its own accessibility check while the screen as a whole announces its parts in the wrong order, spends its alarm budget on the wrong thing, or puts the number a person came for below three things they did not.
Screens are also the only place where the three systems that make opsinjs distinctive have to hold simultaneously:
- The two colour axes. On one component the never-mix rule is easy. On a screen with six coloured elements from two axes, it is a discipline. See The two colour axes.
- The material ladder. A rung is a relative claim. Six surfaces stacked on one screen is where the ladder either reads as depth or reads as fog. Materials is where the ladder lives.
- Motion. Sequencing, continuity and what all of it degrades to under
prefers-reduced-motion. Choreography covers all three.
There are six specimens. Five are chosen to cover the four things a consumer health product does: show a result, capture a reading, show change, ask permission. The fifth of those is the first run, which decides whether any of the rest happens. The sixth is a different kind of artefact: a whole application rather than a screen, so that the assembly question can be asked at the scale a product is actually built at.
Two built specimens, four specifications
Two of the six are now built. The results screen renders its real composition in the preview frame, assembled from parts that already ship, so the three screen-level checks below have something rendered to run against. The medicines app goes further and renders a whole application out of thirty-five of them, with four destinations, five overlays and a working form. The other four are still specifications: each carries the composition it is intended to have, the ways it could mislead, and the accessibility contract it must meet, so that it can be reviewed and argued with now, and its preview frame falls back to the not-implemented notice until the registry has something to put in it.
What a screen page contains
The same six sections, in the same order.
| Section | What it is for |
|---|---|
| What this screen does | The reader's situation on arrival, what they are trying to find out, and an explicit statement of what the screen deliberately does not do. |
| Composition | The part hierarchy, and the material rung each surface sits on. |
| Preview | The screen rendered in isolation under the product theme, at device widths. |
| Safety notes | Where this specific screen could mislead, and what it does instead of guessing. |
| Accessibility | Heading structure, landmarks, focus on entry, reading order against visual order. |
| Status | What is decided, what is open, and the questions the implementation has to answer. |
Two conventions worth knowing:
Previews render under the product theme, not the docs chrome. A screen is
embedded from an isolated (view) route with its own document and its own token
scope, so what you see is the opsinjs product surface rather than this site's
deliberately dense square chrome. That surface has squircle corners, system-ui
and generous spacing. The reasoning is in
Lyra and the docs chrome.
Material rungs are referred to by position, never by name. The rungs are named once, in The ladder. These pages say "one rung above the page" so that they cannot drift from that page as the names settle.
The screens
- Results screen covers one result, what it means, and what happens next. The highest-stakes screen in the set, and the one where the reading order matters most.
- Daily log screen is the surface somebody returns to every day, judged on how little it costs rather than how much it shows.
- Trends screen covers change over time across several metrics, with the axis rules and the data-table twins.
- Consent flow is a sequence rather than a screen, and the one place where the design's honesty is directly testable.
- Onboarding screen is the first run. The minimum is collected before something useful is visible.
- Diabetes medicines app is the whole application: four destinations, thirty-five components, and a set of refusals that keep a medicines record on the safe side of the line between a diary and a regulated device.
Recipes and patterns first
If you are building rather than reviewing, a screen page is usually the wrong place to start. It is a specimen of the finished thing, not a build order.
- Recipes build one piece of a screen, with the steps.
- Patterns describe the flow a screen sits in.
- Screens show the assembly, and are what you check your assembly against.
Verify it worked
Hold your screen against these three, in this order. They are the checks that a per-component review passes and a screen fails.
- Read the screen from top to bottom with the styling off. The order you get is the order a screen-reader user gets. If the number the person came for is fourth, the screen is wrong however it looks.
- Count the coloured elements and name the axis of each. Category colours identify; status colours grade. If any one element is doing both, or if you cannot say which it is doing, fix it before anything else.
- Count the surfaces at attention and urgent. The budget is one urgent surface per screen. See Alarm fatigue. Two means one of them is going to be ignored, and you do not get to choose which.
Troubleshooting
"The preview is empty." Expected on the four screens that are still specifications. Their frame renders the not-implemented notice, naming the screen and its status, and the composition and the contract on the page are the reviewable artefact for now. The results screen and the medicines app are the exceptions: both frames render the real assembly.
"My screen has parts no specimen covers." Likely. These six are specimens, not a catalogue. Compose from Recipes and check the result against the three questions above.
"The screen I need is not here."
There is still no multi-metric dashboard specimen. The medicines app is a today surface for one domain and it carries neither colour axis, so it answers the composition half of the question and not the hard half: a home screen showing readings from several categories, where the alarm budget and the two axes have to hold at once. That remains the largest gap in this set.
There is no result disclosure specimen: the moment between a notification and an out-of-range result. The flow is described in Result disclosure but no screen shows it.
"Two screens disagree about a rule." The doctrine page wins. Screens are downstream of Health and Foundations, and a screen that contradicts either is the thing that is wrong.
Next
- Results screen is where to start. It is the specimen with the most decided.
- Safety review checklist is the pre-ship pass for any screen showing a health value.
- Layout covers page shells, safe areas and the two canonical health screen layouts these specimens are built on.