If you're a button, you have one job

Button behavior, buffering, and “one job”

• Many argue a button should perform its action once for every tap that the UI acknowledges (visual/haptic/audio). Giving feedback but then ignoring the action is seen as a core failure.
• The criticized pattern: animations that block handling of subsequent taps, so fast multi-taps on a rotation button partly or fully “disappear.”
• Others note buttons often do have multiple responsibilities: conveying what they will do, reflecting current state (toggle modes), acknowledging input, and sometimes showing progress.
• Debate on when it’s acceptable to ignore input: during layout changes, to avoid mis-taps on shifted controls, or after destructive actions.

Debouncing, repeat taps, and accessibility

• Several raise accidental double-taps, tremors, or “over-clicks” as real issues; some users may want repeats ignored once intent is “locked in.”
• Others counter that if you debounce/ignore taps, you must not give positive feedback for them.
• Suggestions:
  • Disable or visually “latch” a button while an in‑flight action completes.
  • Offer system-wide options like iOS’s “Ignore Repeats,” rather than baking per‑app heuristics.
  • Treat error states (e.g., wrong passcode) as hard interrupts that clear buffered input.

Animations: value vs harm

• Strong sentiment that modern iOS/Android overuse animations, making UIs feel slow or unresponsive and sometimes blocking input.
• Some still see value where animation clarifies what changed (e.g., seeing an image rotate helps interpret orientation).
• Proposed principles:
  • Animations should be interruptible and never gate logic.
  • They exist to support function (clarity, masking real latency), not as an end in themselves.
  • Provide global “reduce/disable animations” options.

Broader UX and design themes

• Complaints about flat UI and perpetual redesigns: harder to distinguish controls from content, lower contrast, users forced to relearn UIs.
• Counterpoint: flat UIs can work well if basic affordances (clear buttons, feedback, contrast, consistency) are respected.
• Older software and simple widget sets are praised for being snappier and more reliable under constraints.

Hardware and embedded analogies

• Long subthread on physical button debouncing, race conditions, and how bad input handling has caused real-world failures.
• Repeated theme: tight coupling between feedback and actual state is essential; otherwise users can’t trust the interface.