Exactly. This is a very general pattern of error in software design - the use of a non-causal pathway to model causality. It is an especially exasperating problem, as it is both more complicated and more prone to failure than doing it right.

This goes well beyond UI design, and there are even physical analogs - for example, the crash of Turkish Airlines flight 981 in Paris could have been prevented if the device to prevent the cabin being pressurized if the cargo door was not properly closed had been operated by the door locking pins sliding home all the way, rather than by a side-linkage off the linkage that was supposed to drive in the pins.

https://en.wikipedia.org/wiki/Turkish_Airlines_Flight_981#Ca...

My "lazy" solution was absolutely treating the symptoms, yes. Which is why I classified it as a lazy one, even.

But I feel my first suggestion was exactly what you're suggesting -- immediately register the input and apply the operator -- I just phrased it in terms of what happens to the animation.

Also! I certainly feel there are times when letting an animation block your logic is valid. That would be any time when an animation has the UI in a potentially confusing state, such that the meaning of an input is ambiguous. (You should avoid these states as much as possible, of course. And this sort of button-flash comes nowhere even near that category.)

Isn't 'never' an oversimplification? Sometimes there is a feedback loop between UI effects and user input, or the user input changes the way the UI registers hits, which means subsequent input depends on complete processing of prior inputs. On a static view like a calculator grid, you should default to non blocking animation, but sometimes blocking is the desired behavior.

What's a concrete example of this?

An example that comes to mind is a slider switch (iOS is famous for them)

You don’t want the switch activated until it’s all the way left or right.

An even simpler example is page-based navigation. Can't register UI hits while pages are animating in and out.

What if you want to quickly flick through pages? Having to wait for each page to render would be awful.

Slider controls might be a better example, I think. In that case, the position reached by the moveable element is the data, and it is appropriate to take the value from the UI element (of course, if it lags noticeably, that is a UI design issue.) With slider switches, you could argue it either way, so long as program and UI remain consistent, but again there is a problem if the UI response lags the gesture.

Video games use animations as easy to project information to a player. If your character is “stunned” and can’t move, the animation should play for the duration of the status effect.

Sure. But that’s an inherent feature of the animation. In this case the “never” rule doesn’t apply. If animations are a side effect, you want to treat them as such.

The never rule not applying what what I was giving an example of!

But should any buttons pressed during that time be queued? Command queueing and cancellation is an important part of game design.

Tetris

My professor likes to tell this story about keyboard buffers that I never quite understood. Basically, in this old time terminal setup he would start typing the password before the prompt showed up or something and when it did, it would just sail through. Sort of like how I can apt upgrade while apt update is still running but fancier and a couple of decades before...

The computers at my old job working as a cashier did that. It made working with produce so much faster because as soon as I heard the beep, I could move on to the next item, even if the screen hasn’t updated yet.

That "old time" hurts a bit.. I haven't tried this recently, but I distinctly remember doing this in the early versions of Ubuntu.

That's what happens when you read from a keyboard buffer. Since the buffer is not being read (and not cleared) until a prompt is in the screen, you can type whether you want and it'll get dumped and processed whenever needed. Not that long ago really, that's how it worked in DOS and most other terminals.

It still works. I can ssh into a machine and start typing commands before the shell prompt appears. The commands will appear in the terminal once the connection is established and the shell is ready.

Isn't the keyboard buffer a part of the physical keyboard circuitry and interface? Hitting enter triggers an IRQ to flush the buffer, so if the CPU is too busy to handle the IRQ then things queue up until the CPU can get around to handling it. If that's the case, for this "feature" not to work would require a very low level architectural change to keyboards. (it's been many years since i've thought about this though)

Keyboard buffers are decidedly not on the physical keyboard. The keyboard might have a very small one, but the IRQ is triggered on every input.

The buffer in question is, for a tty, a driver-level buffer that holds on to the data until something reads it. If a command doesn't read it (which things like apt-get update don't) then it'll get read as the next command.

Of course, most terminals these days are ptys accessed via emulators, so the buffer is actually part of the emulator, but the same idea applies.

ah, the more you know :) I would have been shocked if i remembered all that correctly

For some reason my brain still finds it important to remember that the BIOS keyboard buffer is 15 bytes by default, but that you could load tiny little devices drivers in CONFIG.SYS in MS-DOS to make it a whole 31 bytes.

You can still do this in at least some shells. PowerShell buffers input if the running program doesn't capture it. If I have a build and execute commands in the history, I can hit up-up-enter twice in a row to start the build and queue the execution command.

I remember people doing that on an AS/400 ramming keystrokes for 5 seconds and then waiting 15 seconds for the system to arrive in the right screen, sometimes even already filling the fields from muscle memory. The first five lines of address data were already entered before the screen loaded.

When I was in high school I had a job after school where they still had a PDP/11 w/real DEC VT-100 terminals. The kid next to me used to do data entry and would get far ahead of the input screen. Except when he made a mistake, and he often did, it would beep. But because he was so far ahead when he made a mistake it would beep for 2 minutes straight. Every time. Max-volume.

Soo.. When he left his desk, I went in and hit SHIFT-SETUP, turned the audible BEL off in the VT-100 setup menu and enjoyed the silence.

When I came back in the office the next day, there was a technician from Digital with the terminal in what looked like 100 pieces on the desk trying to "fix" it. He was pretty upset when he realized it wasn't the speaker and the setting was just turned off (why he didn't check that first, I'll never know). Needless to say as a teenager, I kept quiet about the whole thing.. until now..

Oh wow. That is awesome.

> Sort of like how I can apt upgrade while apt update is still running but fancier

You can link two commands together with the "AND IF" operator

    sudo apt update && sudo apt upgrade

Furthermore, you also have `||` which is the logical or, and also `;` which is just a separator which doesn't care what happend to the command before.

I see that buffer effect all the time still.

It is not as easy as that. UI and logic should run in parallel , yes, but they should also be able to synchronise.