Parent
#89
What to build
Shift, Alt and the wheel are invisible unless something says they exist.
A help affordance sits in the colour control's own label row, right-aligned, after the readout: Colour ...... 212°, 85% (?). Hovering it names the three shortcuts. It is not a click target and opens no window.
It appears only where a colour surface does. The stock slider does not implement these shortcuts, so the same icon on a brightness-only widget would promise help it cannot give.
It lives in the label row rather than the widget header because the header already carries the title, the action icon, the chevron and the update alert, which leaves roughly 76px for the title at Small. One more icon would cut that to around 56 and make the title visibly shorten the moment the widget expands. The label row costs the header nothing and sits next to the thing it explains.
ADR-0001 forbids hover chrome pinned to the card's edges while a widget is expanded, because those edges become sliders. The label row is part of a control's own layout rather than an overlay on a track, so this does not conflict with it.
Plus the same shortcuts in the README and the release notes, because a tooltip only helps somebody who already found the control.
Acceptance criteria
A decision deferred to implementation
If the icon crowds the readout at Small, move it to the bottom-right corner of the card, which ADR-0001 leaves free while the widget is expanded. That call is made by looking at it, not by arguing about it beforehand.
Testing
At S2: the widget offers the help affordance for an entity with a colour control, and does not for one without.
Everything else here is a judgement call rather than an assertion, which is what the by-eye acceptance criterion is for. The test that matters is that somebody looks at it at all three presets.
Blocked by
Parent
#89
What to build
Shift, Alt and the wheel are invisible unless something says they exist.
A help affordance sits in the colour control's own label row, right-aligned, after the readout:
Colour ...... 212°, 85% (?). Hovering it names the three shortcuts. It is not a click target and opens no window.It appears only where a colour surface does. The stock slider does not implement these shortcuts, so the same icon on a brightness-only widget would promise help it cannot give.
It lives in the label row rather than the widget header because the header already carries the title, the action icon, the chevron and the update alert, which leaves roughly 76px for the title at Small. One more icon would cut that to around 56 and make the title visibly shorten the moment the widget expands. The label row costs the header nothing and sits next to the thing it explains.
ADR-0001 forbids hover chrome pinned to the card's edges while a widget is expanded, because those edges become sliders. The label row is part of a control's own layout rather than an overlay on a track, so this does not conflict with it.
Plus the same shortcuts in the README and the release notes, because a tooltip only helps somebody who already found the control.
Acceptance criteria
A decision deferred to implementation
If the icon crowds the readout at Small, move it to the bottom-right corner of the card, which ADR-0001 leaves free while the widget is expanded. That call is made by looking at it, not by arguing about it beforehand.
Testing
At S2: the widget offers the help affordance for an entity with a colour control, and does not for one without.
Everything else here is a judgement call rather than an assertion, which is what the by-eye acceptance criterion is for. The test that matters is that somebody looks at it at all three presets.
Blocked by