25 ms·
Debouncing is a useful concept in software design too. Many UI elements are all too eager to emit hundreds of state update events (like a slider) as the user i
by akersten 7y ago
Debouncing is a useful concept in software design too.
Many UI elements are all too eager to emit hundreds of state update events (like a slider) as the user is finalizing the input they want - but you wouldn't want to send 100 AJAX requests to the webserver while the user's fiddling around. So resetting a 200ms timer before sending the web request is a great analog to the process of physical debouncing.
- fermienrico 7y agoAnother useful software concept is exponential back-off algorithm: https://en.wikipedia.org/wiki/Exponential_backoff https://en.wikipedia.org/wiki/Exponential_backoff Useful in interacting with rate-limits, unpredictable externalities that are not schedule bound, etc
- downerending 7y agoThat's useful as an implementation detail, but even more important is the user experience of failing to debounce correctly. If I press a button (etc) twice within 100ms, that generally does not mean I want this to be seen as two presses. Rather, my finger slipped, maybe I have minor neurological problems, I'm drinking, the software itself glitched, whatever. For the user's sake, user interfaces should debounce themselves. It's all rather striking to me, as the concept of debouncing was one of the first things I learned while reading microcontroller code as a child. (No, I'm not kidding--that was the only book on computers I could find growing up in BFE.) That we still haven't generally solved this in 2020 is appalling. (There are lots of variations. There was an article in Software: Practice and Experience in the 90s (?) lamenting the UI race in most X interfaces (and probably all other GUIs). Briefly, lots of interfaces can pop up a dialog or whatever while the user is pressing a button underneath. The dialog often gets the press, resulting in the software executing some action the user did not even see, much less intend.)
- mrob 7y agoIf a computer is going to disobey my instructions it should be extremely sure it's doing the right thing. 100ms is too long a threshold to make that assumption. 100ms repetition interval is only 10Hz, which is easily accomplished in short bursts by anybody with moderate skill in button mashing. I'd set it no higher than 50ms (20Hz), which is very difficult even in short bursts.
- downerending 7y agoYeah, well, wait until you're older. Or sicker.
- renewiltord 7y agoWhen I'm older or sicker, I'll use a thing that works for me when I'm older or sicker. Otherwise it's like turning on the screen reader for everyone because blind people can't operate computers otherwise.
- downerending 7y agoThat's great for people that are technically inclined. Spend some time with senior citizens and the disabled and you might develop a bit more compassion.
- jzwinck 7y agoIt depends on the context. If you're trying to fire your gun in a video game, sure, it should respect every button press (subject to hardware debouncing which is always required). If you're submitting an online payment, a delay of 10 seconds per order is still not enough. If you're posting in a forum, duplicates should be automatically pruned. Trying to pin down the number of milliseconds without context is a great example of bikeshedding.
- im3w1l 7y agoOverly long debounces are frustrating and 100ms is kinda questionable in that regard. And honestly if I wanted debouncing I'd get a mouse that did that.
- jadbox 7y agoOn this I definitely recommend checking out RxJS and it's stream operators like denounce: https://www.learnrxjs.io/learn-rxjs/operators/filtering/debounce https://www.learnrxjs.io/learn-rxjs/operators/filtering/debo...