hansdezwart/bgclock
1
0
Fork 0
Code Issues Actions Releases Activity

Reset by holding the button, not by tapping it twice

Browse Source 
A test user found the reset button, tapped it once and gave up. That is what
the old feedback invited: a first tap brightened the icon and started a ring
draining over 2s, and a draining ring reads as "wait" or "loading", not "press
me again". The one thing that would have said otherwise — a word — is not
available here, because the bar is shared by two players sitting opposite each
other and every word in this app lives inside a panel that rotates to face one
of them.

"Tap this twice" has no wordless vocabulary. "Keep holding" has a very
well-worn one, so reset is now a 975ms hold: a dim track ring appears whole the
moment the finger lands, a bright arc fills over it from 12 o'clock, and
letting go early makes the arc retreat. The retreat is the instruction. A stray
hold is also far less likely than two stray taps inside 2s, so the live game
this was guarding is guarded better than before.

Three things that look incidental and are not:

- Hiding the ring is an opacity that waits out the retreat, not display:none,
  which cut the retreat off at the instant of release — invisible, and it was
  the whole point. The fade has a real duration because a 0s transition with a
  delay may be treated as no transition at all, taking the delay with it.
- width:auto on the ring: .btn svg sets a width for the bar icons, and
  inheriting it against the ring's new height draws an ellipse.
- The ring's transition is exempted from the blanket prefers-reduced-motion
  rule. Collapsing it would fill the ring the instant you touched the button
  and claim the reset was done 975ms before it was. It reports state.

Keyboard, switch and assistive activation cannot hold, and hold-only would have
left those users unable to reset at all, one release after an accessibility
pass. Clicks arriving with detail 0 — no pointer behind them — keep the old
two-presses-within-2s and the draining ring.

Success now sounds: the flag's falling triad, rising instead. Deliberately not
another rising fifth, which sndSwap owns and plays on every handover.

Also corrects a claim in RELEASING.md: the screenshots reproduce near-exactly,
not exactly. Two runs of identical code differ by a 4x13 pixel sliver where the
delay bar's fill edge lands mid-pixel, so a non-empty git diff after re-running
proves nothing on its own.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
hansdezwart
2026-08-15 14:51:06 +02:00
co-authored by Claude Opus 5
parent b31087223a
commit ec1a65c89c
3 changed files with 162 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tools/screenshots.py
+8 -3
View File
@@ -3,9 +3,14 @@
python3 tools/screenshots.py
They are rendered, not photographed, so they reproduce exactly and can be
redone whenever the UI changes. Output is 1170x2532 — 390x844 CSS pixels at
device scale 3, an iPhone-sized frame that F-Droid is happy with.
They are rendered rather than photographed, so they can be redone whenever the
UI changes. Output is 1170x2532 — 390x844 CSS pixels at device scale 3, an
iPhone-sized frame that F-Droid is happy with.
Near-exact, not exact: two runs of identical code differ by a 4x13 pixel sliver
at the delay bar's fill edge, where the scaleX boundary lands mid-pixel and the
rasteriser rounds it differently. Invisible, but it means a non-empty git diff
after re-running proves nothing on its own.
Three things bite, and all three fail quietly rather than loudly: