Comment by munificent | Hacker News Reader

Comment by munificent | Hacker News Reader

Parent Full thread

> I went through a phase a while back of holding down keys to see what they did.

Back when I was a gamedev at EA, one of the things QA would do is button-mash test the games. Just smash as many buttons as they could at the same time at all sorts of random points in the game. This was a constant source of bugs. It was surprisingly easy to get the game into a state where it was totally hung because of this.

One of the main culprits was transitions between screens in the UI. So much of the UI code assumed that the initial state of a screen is that no buttons are currently pressed. But if you mash a bunch down in the middle of a transition, the screen can end up receiving a button up event that did not precede any button down event. If the screen's code assumed every up has a preceding down, it could get into a broken state.

I never did see any clean systematic solution to this problem. I still think about it a lot when I do UI programming. In the back of my head, I'm always wondering, "what will happen if the user presses X in the middle of this animation?"

Programmers are particularly prone to these bugs because we have unconsciously trained ourselves to baby our own software. We're careful to wait for transitions to complete and only send input when the app is in a known state.

No good generalized solution for this it seems. The best you can do is to specialize per situation and leverage all the assumptions you can while being cautious not to leverage the assumptions you can’t.

This problem contains lots of incidental complexity and it doesn’t help that folks do the opposite of the above and add a ton of accidental complexity on top. For example, for a situation with a crossfade or morphing set of 2 buttons you should:

- leverage the assumption that there are only 2, and static, buttons. - not assume that there are only 1 button present at any time.

Some end up inclined to create some “reusable” abstraction on top and end up doing the opposite: - generalize to handling n dynamic buttons. Without realizing that some important properties of that specific situation would have been lost. - (usually due to the lack of experience/focus/interest on the problem) oversimplify and assume there’s only 1 button present at any time.

If it was up to me, there were no transitions. I am happy I can disable them on Android... Everything that does or manipulates animation is terrible. Scroll hijackers, image carousels, icon transitions, they are all wasting cpu cycles to please UX/designers!

I'm glad there's at least one other person vocal about doing this. I use a several-year-old Android phone, and when anyone new sees me use it, the first thing they ask is what phone it is and if I just bought it.

Those animations were for a time and place where phone processors were genuinely slow. That time and place is nearly a decade ago, and most of the world is stuck with lower productivity due to this vestigial cruft.

Think of all of those teens that can type a billion letters a minute without batting an eye, and yet have to unwittingly endure all of these silly transitions...

But of course, it breaks a whole bunch of poorly tested apps, even mainstream ones like Uber and Lyft.

Sounds right, I've even had a lot of modern games crash or hang when the action gets hot and I'm spamming inputs (Path of Exile was frequent, but even Hades crashed the other day like this).

Couldn't you just stop receiving keypresses when a UI transition begins and then re-enable input once the new UI state has been established?

Yes, but it still means that when input is re-enabled later, the buttons are in an unknown state and you don't know if you'll be receiving unexpected button up events.

Also, it's very frustrating for users when input gets dropped on the floor at times where they don't expect. Determining when to queue that input and when to forget it is a real art. Humans have subtle, complex expectations there and there's no simple solution.

The problem is "key down" and "key up" are usually separate events. If you write software in a way that you always expect a "key up" to be preceded by a "key down", you'll have problems like the above mentioned.

Seems like a great place to use state machines. That’s not a total solution, of course: if “hold X” and “hold A” have very different behaviors, developers still have to code those states to be exclusive...unless they shouldn’t be. Ain’t easy, that’s for sure.

A robust solution should probably use state machines coupled with generative testing, so that all of those unexpected combinations can be generated and handled before the testers try button-mashing, without relying on developers to think of and write all the individual test cases.

of course, but that doesn't stop a case where a button was already pressed down when input get re-enabled which would mean a button up event would still fire without a corresponding button down.

Reply on news.ycombinator.com