Hacker News Reader

Comment by OneLessThing | Hacker News Reader

It's not so simple. There are times where you intend to tap one thing and something else appears underneath your finger instantaneously. So sometimes while rendering a layout you want to stop accepting input.

View on HN

That's a different bad UX pattern. If a button has already rendered in a certain location, a new button shouldn't replace it without first giving the user ample warning that a material change is about to happen.

I see it as the same problem of when to accept button input. In my view having the button give "ample warning a material change is about to happen" is making the button do something more than "one job." But maybe you're right if your point is that if you're showing a button it should do the work it says it will do.

Isn't that a different issue from what the blog post described and easily solved by holding everyone who allows their UX elements to get pushed around, for whatever reason, to the fire?

Yeah, that is an issue in Apple Maps.

If you tap for directions and then tap to change the mode of transportation as it's loading the routes then it thinks you've picked the first route because it bumps the transport mode panel up in order to show the first route in the list.

Very annoying as they could just account for the height of the first route from the start.

Then don't give UI and haltic feedback.

Sorry how is this relevant to the example?

They are both about when it is best to accept user input. In the specific example with rotating images nothing covers or moves the buttons so it is not relevant. My impression of the article was that the buttons one job was to accept input always, my argument is that there are times it's okay to not accept input, for example the short time after certain layout changes

Reply on news.ycombinator.com