undefined

points

[-]

> there's no way for it to tell the button to cancel the color change

No, but what should happen in cases like that is that the on-click handler disables the button while it is unresponsive. This will communicate the fact that the button is unresponsive visually to the user and also inhibit the button-was-pressed feedback.

by RugnirViking13 hours ago|

parent|

[-]

Of course, one can fix these problems. GP was merely saying why this kind of mistake is common; it is definitely a mistake, not an inevitability.

by crote11 hours ago|

parent|

prev|

[-]

Simply disabling the button leads to people thinking something is broken, so you need to add a visual "disabled" state - which should probably be separate from the "you are currently pressing the button" state.

In most cases that is going to lead to annoying pointless flickering as most actions & animations are basically instantaneous, and with touchscreens even in the non-pointless scenarios it won't have the desired effect as the button itself will be hidden from the user by their own finger.

In principle I think you are right, but in practice buffering presses is often probably the more user-friendly option.

by PunchyHamster10 hours ago|

parent|

[-]

> Simply disabling the button leads to people thinking something is broken, so you need to add a visual "disabled" state - which should probably be separate from the "you are currently pressing the button" state.

Well, yes, dropping user inputs is "being broken"

by RossBencina11 hours ago|

prev|

[-]

> Sometimes this is used to intentionally give you a chance to cancel the action

EDIT: sometimes UI elements with mouse-held interaction allow you to use the escape key to cancel an in-progress interaction (ESC: abort, mouse-up: commit) however the reply button on this page doesn't work that way so I have to edit this message to add this. That escape-key behavior should be universal I think.