Hacker News Reader

Comment by stonemetal12 | Hacker News Reader

In electrical engineering there is the concept of "bounce" where IO, i.e. switches sensors whatever, are in a state of close to change, they can bounce back and forth between on and off. When writing controls for them you have to debounce, that is wait for the signal to switch from off to on for say 10ms before you act on the transition.

When dealing with users, and slow processes (that you can't make faster for some reason), it is often necessary to "debounce" user input. Whether that is graying out a button, displaying a loading popup, or something else is entirely situation dependent. Whatever you choose, you should be preventing people from annoyance clicking their way into trouble.

The amount of software that doesn't seem to get that is rather surprising.

View on HN

>wait for the signal to switch from off to on for say 10ms before you act on the transition

That is the worst way to debounce, because it adds 10ms latency for no good reason. The better way is to act immediately but ignore further inputs for 10ms. You might also want a little bit of analog filtering to improve EMI tolerance, but that shouldn't add more than 1ms latency.

Yeah, I probably should have put it your way. It gels better with the next paragraph about ignoring user input for some amount of time after the initial signal.

It depends on the application. If you wanted to debounce, for example, user autocomplete inputs that will be fed as a search term into your service, generally you would not want to start returning results when a user types the first letter “a” and continues typing, but instead wait for the user to stop typing for a fraction of a second.

If you have exceptional resources you may choose to not debounce at all, but for applications with latency behind it, it can make more sense to just wait for the user to signal they are done.

> state of close to change, they can bounce back and forth between on and off.

I believe the general concept is called hysteresis(1). Many systems require some prior state knowledge before acting to avoid cycling near the setpoint. As you said, the simplest solution is often a deadband around the setpoint so that action can never result in a state requiring action.

1: https://en.m.wikipedia.org/wiki/Hysteresis

> I believe the general concept is called hysteresis

Hysteresis is what you add to the sensor in order to debounce. The bouncing effect itself is not called hysterisis, and does not require the system to have any memory - you get it as soon as there's noise in the measurement, which there always is.

> When dealing with users, and slow processes (that you can't make faster for some reason)

The reason is that these systems all require realtime design techniques, and realtime design techniques are rarely taught in school and the overwhelming majority of software engineers don't know them, and the vast majority of software engineering managers are unaware that realtime design techniques even exist.

All computers that manage user interfaces today -- all of them -- are by many orders of magnitude fast enough to provide near-instantaneous responses to user inputs if programmed with realtime techniques.

As an electrical engineer that wrote more than 5 different denouncing implementations: You are of course correct about denouncing, yet most buttons wouldn't need more than 25ms denouncing, which is a magnitude less.

Denouncing user input in UIs is indeed something you should do. Especially if it would be bad if the user input ends up triggering something twice.

Reply on news.ycombinator.com