.bn-btn family from atoms/modal.css (including the 31 Aug base-background fix)
and the shimmer is atoms/shimmer.css verbatim. What is new is the transitioning, and it
is marked.Review climbs out of its row and into the gutter. That is the whole structural consequence, and it is what makes the idea work: the gutter is where the eye already went to click Install, so the reward appears where the action was. The review row keeps the counts and loses its button, which is a better division — the row states the finding, the gutter carries the verb.
It also resolves an open question by construction. The catalogue's §4 asks what rank Review should
hold among three verbs on one screen (Browse Library, Install/Uninstall, Review) and offers three new styles
to settle it. If Review is Install in a later phase, there is no third verb and no new style: it
inherits primary because it is the same control. .bn-btn-quiet, -tinted and
-outline stop being needed for this case.
The cost is that Install and Uninstall stop being a toggle. Today the gutter holds one button whose label flips. Under the arc, an installed-and-coded card holds two — Uninstall, plus the phase pill — and the App Store precedent gives no guidance, because the App Store never shows Delete next to Open. Three ways out are drawn below.
It settles the multi-codebook problem, which nothing else did. Six codebooks can be installed on one project and each can carry its own job. A single sidebar status line cannot say six things, and an aggregate ("2 codebooks to review") needs a popover to disambiguate. A per-card button needs none of that: six cards, six pills, each in its own phase, no aggregation and no arbitration. This is the strongest argument for the idea and it is not the App Store one.
It does not settle attention. The pill is only visible on the codebook lens for the project you are looking at. Navigate away, or close the sidebar while on another project, and the arc is off-screen — which is the case the chip covers today and the native status line would cover next. The button is the right UX for this surface, and it is a surface the researcher has to already be on.
Two things to check before building. The shimmer has never been applied to a button: it is declared
for text elements, needs the consuming surface to set --bn-shimmer-base explicitly (the
clip-to-text technique forces color:transparent, so currentColor would vanish), and
on a filled pill the polarity inverts — base #fff, peak the accent, at the chip's 20% contrast
rather than the sidebar's 5%. That is what this page does; it wants looking at in both palettes. Second, a
button whose label changes identity across phases needs its accessible name to change with it, and a live
region for the transition — a control that silently becomes a different verb is a screen-reader trap.
The shimmer and a determinate bar are mutually exclusive on one element, and that is a written rule rather than a preference:
atoms/shimmer.css's own header says the sweep "REPLACES the spinner — never run it alongside a determinate progress bar on the same element (design-motion §4.7)". So the tagging phase has to choose, and the two candidates are genuinely different products.processed/totalis on every poll. But a filled progress pill is a new component, and it must not shimmer.Note that App Store's middle state is not a labelled button at all — it is a circular determinate ring with a stop square, and the word disappears for the duration. If the analogy is being taken seriously, 2b is the faithful reading and 2a is the house one. They are both defensible; they are not combinable.