Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If you're a button, you have one job

unsung.aresluna.org

Post reply on HN
Print view View original

121–130 of 308 posts

Re: If you're a button, you have one job

#121

Post by inigyou »

mrob wrote: post #116
inigyou wrote: post #114

Earlier quoted context omitted.

They didn't say how often the reads are - 50 reads could be only 5ms.

Latency is cumulative, so avoidable latency is never acceptable. Maybe the hardware will change. Maybe somebody will run your software in an emulator. That 5ms could be enough to push the total latency into the "annoying" level. And even with no additional latency, 5ms is perceptible in some cases anyway. Microsoft Research has a video demonstration: https://www.youtube.com/watch?v=vOvQCPLkPt4

Do you really think the people who programmed your microwave should have taken into consideration that someone might write a microwave emulator in the future? Dealing with that is not their job, it is the job of the emulator creators.

Re: If you're a button, you have one job

#122

Post by kccqzy »

mcv wrote: post #94
mproud wrote: post #35

How about when users accidentally click too much, or they believe the first click didn’t register? I am still reminded of a keynote where Steve Jobs was demoing how much faster PDF documents would display on the newer macOS. So he had engineers put a button in for him to click that would scroll through the PDF on the screen, and he accidentally clicked it more than once. Steve wondered aloud if it would scroll all th…

Debouncing exists for a reason. Sometimes when a button is clicked twice, you want it executed twice, sometimes you don't. Distinguishing which is better in which situation is not trivial. At the very least, you should consider which is appropriate for which situation, what if, in your UI, for some buttons one is the obvious choice, for others it's the other, but for some it's not so clear, and both behaviours are de…

It’s really common for people to accidentally click a button twice. Yeah that’s what denouncing is for.

My favorite example of doing it wrong is a log in form: if the login button is clicked twice, the server would reject the login because the first click has already used up the one-time token so the user gets an error page.

But I think the biggest problem is that people either apply denouncing to all buttons in a UI (like turning it on within the framework they are using) or apply denouncing to nothing. So there really isn’t a culture for carefully considering which situations warrant which.

Re: If you're a button, you have one job

#123

Post by crewindream »

jan_Sate wrote: post #90

There's a problem with buffering tho. If the device's slow and unresponsive, and the user tapped the rotation button several times, it would be confusing if the rotation action happens 10 seconds after the user tapping the button. The user'd be left confused like "alright. So, has my input been taken?" Now that I'm wondering. How does iphone mitigate this problem?

One way to deal with it could be “guaranteed interrupt” action (something like sigkill, just for UI action queue).

Other way could be to actually visually indicate action queue depth.

Re: If you're a button, you have one job

#125

Post by arendtio »

Reminds me of the time I built a BabyButton, which was built in a way so that a baby could use it. Instead of the normal click behaviour, it was using the touchdown event, because that way the kid saw that something happened, and there was no problem with holding the button too long or moving the finger while still holding the button.

Whether you should build systems for that age group is an entirely different topic, but I found it a good challenge to design something that fits the user's needs.

Re: If you're a button, you have one job

#126

Post by crewindream »

ivanjermakov wrote: post #91

When I had my last Android phone (KitKat 4.4), best tip for increasing UI snappiness was reducing (or disabling) system animations. I still miss this option on most modern OSes, shells, apps, and websites. It's very rare that animation is not blocking further user actions. No surprise animations are tricky to program - they're very async in nature. Designing animation system that doesn't leak into the rest of applica…

Tangentially related, games added various menu transition animations on purpose, to disable user input while loading resources (from hdd or network).

Idea being that for user it is less frustrating to wait for animation to end, than to see some hourglass/waiting indication.

Re: If you're a button, you have one job

#127

Post by crote »

inigyou wrote: post #114
mrob wrote: post #108

Earlier quoted context omitted.

>averaging the last 50 reads and wait till the majority is either off or on. This is a bad way to do it because it adds avoidable latency. A moving average is a low-pass filter. The switch bounce is better handled by hysteresis. Change state as soon as you see an edge, then ignore further edges until a timer expires, e.g. 5 ms, which should be enough for the bouncing to settle. A 5 ms timeout limits your repetition r…

They didn't say how often the reads are - 50 reads could be only 5ms.

In practice switch bounce often lasts tens or even hundreds of milliseconds, and you need to space out the read process to cover the entire bouncing process if you want to avoid registering fake presses. Using basic averaging means your minimum input latency is going to be ~half your bounce time - which is often way too high for it to feel like real-time input.

If you want to achieve low-latency input, "act on first edge, then ignore for the switch bounce period" is a far better approach. It also conveniently solves the "press, then release within bounce period" problem where an averaging algorithm would completely ignore the button press.

Re: If you're a button, you have one job

#129

Post by vishnugupta »

embedding-shape wrote: post #53
mproud wrote: post #35

How about when users accidentally click too much, or they believe the first click didn’t register? I am still reminded of a keynote where Steve Jobs was demoing how much faster PDF documents would display on the newer macOS. So he had engineers put a button in for him to click that would scroll through the PDF on the screen, and he accidentally clicked it more than once. Steve wondered aloud if it would scroll all th…

I'm no longer the Apple/Mac/Jobs fan-boy I once was in my earlier days, but I do miss the Apple presentations that felt like they were run by a human being wanting to show off cool stuff. I couldn't even finish the last Apple presentations as it all feels so stiff, inhuman and run by suits, they all seem like robots scared of diverging from the holy script who will get fired if they display emotions and humanity. Off…

I agree 100%. I stopped watching after iPhone 15 event or maybe M2.

Absolutely everything seems scripted including hand movements, shifting of postures, smiles..the whole works.

Now I just wait for the press release and that’s that.

Re: If you're a button, you have one job

#130

Post by crote »

inigyou wrote: post #121
mrob wrote: post #116

Earlier quoted context omitted.

Latency is cumulative, so avoidable latency is never acceptable. Maybe the hardware will change. Maybe somebody will run your software in an emulator. That 5ms could be enough to push the total latency into the "annoying" level. And even with no additional latency, 5ms is perceptible in some cases anyway. Microsoft Research has a video demonstration: https://www.youtube.com/watch?v=vOvQCPLkPt4

Do you really think the people who programmed your microwave should have taken into consideration that someone might write a microwave emulator in the future? Dealing with that is not their job, it is the job of the emulator creators.

Who says the emulator is "unauthorized"?

For example, smartphone app developers routinely run their apps in emulators first to make the development process more convenient, only running it on a physical device for confirmation when the work is basically done.

Many embedded developers would kill for something similar, and we're already seeing the start of it with platforms like Wokwi. Being able to do integration tests without the physical device itself is an absolute game changer.

Post reply on HN