Skip to content

design(usage): one house segmented control, labelled once, on the title row - #301

Open
FZ2000 wants to merge 6 commits into
mainfrom
ui/21-usage-range-label-once
Open

FZ2000 wants to merge 6 commits into
mainfrom
ui/21-usage-range-label-once

Conversation

@FZ2000

@FZ2000 FZ2000 commented Sep 19, 2026

Copy link
Copy Markdown
Collaborator

What was wrong

The Usage header printed two labels for one control (the caption Recorded usage range plus the picker's own Usage range, wrapped onto two lines), and the control itself was the native macOS segmented picker: a gray system widget sitting under a plain caption on its own row, while the Dashboard's usage card already switches Tokens/Cost with a designed segmented track. Two vocabularies for the same interaction.

What changes on screen

  • One house control. The Dashboard's switch is extracted into SegmentedChoice (segments at least 52 pt wide and 26 pt tall in captionSemibold, the selected one lifted onto a card fill inside a tintNeutral track, hover/press/focus feedback from ButtonFeedback). The Dashboard now uses it too, so its Tokens/Cost switch takes the same roomier proportion; the extraction itself was verified pixel-identical before the cells were widened.
  • Range with the section it governs. The page title row is Usage & limits ⓘ alone. The Recorded usage section's title row carries RECORDED RANGE [7d | 30d | 90d] trailing, the same composition as the Dashboard card header. It is not on the page header on purpose: the page's top-trailing corner is where recording notices surface, and a control there vanishes behind the notice card on a live window. The control's accessibility name is the full phrase "Recorded usage range".
  • Chart measure matches. MEASURE [Cost | Fresh tokens] uses the same control instead of the native picker.

How it is tested

  • Visual: buttons render under ImageRenderer, so the snapshot stand-ins (the single 7d chip, the measure chip) are gone and every usage-* reference shows the real control on the section row; the 90-day lane shows 90d selected. dashboard-* references are re-recorded for the wider cells. All references re-recorded on the canonical renderer (macos-26-xcode-26.6-arm64-2x); visual-snapshots verify passes.
  • Unit: UsageRangePresentationTests pins the caps label, the accessibility name and the offered windows.

🤖 Generated with Claude Code

FZ2000 and others added 2 commits September 19, 2026 11:13
The Usage header printed two labels for one control: the caption "Recorded
usage range" and, beside it, the segmented picker's own "Usage range" label,
wrapped onto two lines inside the picker's fixed width. Hide the picker's
label, as the chart-measure picker already does, keep the caption as the
control's accessibility name, and size the picker to its segments.

Snapshots used to stand in for the picker with a single "7d" chip, so no
reference showed the header as users see it. A `SegmentedStandIn` now draws
the three windows with the selected one filled, so the usage references
(7-day and 90-day lanes) show the one caption beside the real segment set.
`UsageRangePresentation` carries the caption and the offered windows and is
covered by `UsageRangePresentationTests`. References re-recorded on the
canonical renderer.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The Usage page mixed two vocabularies: the Dashboard's usage card switches
series with a designed segmented track (24 pt segments, the selected one on a
card fill inside a tinted track), while the Usage header and chart measure
used the native macOS segmented picker, a foreign gray widget on a designed
page, sitting under a plain caption on its own row.

Extract the Dashboard's switch into `SegmentedChoice` (one shape, one type
role, one hover/press/focus feedback model) and use it everywhere a page
offers a choice: the Dashboard series switch (its references are pixel-
identical, which is the proof the extraction changed nothing), the
recorded-usage range, and the chart measure. The range control moves onto the
title row, trailing, behind a "RECORDED RANGE" caps label — the same
composition as the Dashboard card's header. Buttons render under
ImageRenderer, so the snapshot stand-ins (the range chip, the measure chip and
the interim SegmentedStandIn) go away and every usage reference shows the real
control; the interactive-only grouping menu stays hidden in snapshots.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@FZ2000 FZ2000 changed the title fix(usage): label the recorded-usage range once design(usage): one house segmented control, labelled once, on the title row Sep 19, 2026
FZ2000 and others added 2 commits September 19, 2026 11:44
On a live window the page's top-trailing corner is where recording notices
surface, and the range control placed there disappeared behind the notice
card. Move it onto the Recorded usage section's title row — the section it
actually governs, together with the capacity table's "Recorded use" column —
trailing, behind the same "RECORDED RANGE" caps label. The page title row is
the title and its help again. References re-recorded.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Short labels (7d, 30d, 90d, Cost) hugged their glyphs, so the track read as
cramped. Every SegmentedChoice segment is now at least 52 pt wide and 26 pt
tall with 12 pt side padding — one rule in the shared control, so the
Dashboard's Tokens/Cost switch, the recorded-usage range and the chart
measure all share the proportion. Dashboard and usage references re-recorded.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@FZ2000 FZ2000 closed this Sep 19, 2026
@FZ2000 FZ2000 reopened this Sep 19, 2026
FZ2000 and others added 2 commits September 19, 2026 13:06
…el-once

# Conflicts:
#	apps/agentacct/Tests/agentacctTests/ReferenceImages/macos-26-xcode-26.6-arm64-2x/PLATFORM.json
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant