undefined | Better HN

0 pointsbhauer6y ago0 comments

Virtually all of my accidental inputs are caused by application slowness or repaints that occur several hundred milliseconds after they should have.

I want all interactions with all of my computing devices to occur in as close to 0ms as possible. 0ms is great; 20ms is good; 200ms is bad; 500ms is absolutely inexcusable unless you're doing significant computation. I find it astonishing how many things will run in the 200-500ms range for utterly trivial operations such as just navigating between UI elements. And no, animation is not an acceptable illusion to hide slowness.

I am with the OP. "Good enough" is a bane on our discipline.

0 comments

prox6y ago

How about the i-am-about-to-press-this-button-but-wait-we-need-to-rerender-the-whole-page. At which point you misclick or not at all. Especially some recent shops and ad heavy pages use this great functionality ;)

Natanael_L6y ago

Twitter on mobile.....

SAI_Peregrinus6y ago

The rule for games is that you have 16ms (for a 60Hz monitor) to process all input and draw the next frame. That's a decent rule for everything related to user input. And since there are high refresh-rate monitors, and it's a web app and not a game using 100% CPU & GPU, just assume 4-5ms for a nicer number. If you take longer than that to respond to user input on your lowest-capability supported configuration, you've got a bug.

0ms is great, 4ms is very good, 16ms is minimally acceptable, 20ms needs improvement (you're skipping frames), 200ms is bad (it's visible!), 500ms is ridiculous and should have been showing a progress bar or something.

Responding to input doesn't necessarily mean being done with processing, it just means showing a response.

0x4454426y ago

This happens to me all the time starting pipelines in Gitlab. Which typically results in unwanted merges to master which then need to be reverted.

j / k navigate · click thread line to collapse