Tl;dr reaction time, 300 ms is the golden rule for reaction speed, and apparently there was actually a sports medicine study that came to that #. I was surprised to see that, 300 ms comes up a lot in UX as “threshold of perceptible delay” but it was still surprising to see.

I'm not sure why human reaction time is relevant here, since what I'm talking about isn't the time it takes me to respond to a stimulus but the time it takes the computer to respond to a stimulus.

I do do still have both computers set up side-by-side (legacy data from an old business), and the keyboard in question was a Microsoft Comfort Curve 2000 (the calculator button wasn't a proper key, it was one of those squidgy extra keys so beloved of multimedia keyboards, so not as fast to operate as a proper key.)

Anyhow, the point (arguably hypberbolic as it may have been) wasn't about reaction time per se, it was about the older calculator app - and by extension much of the rest of the OS - being a much simpler and less bloated piece of software, and running it on faster-than-contemporaneous hardware makes for a sense of immediacy which is sorely lacking in today's world of web apps.

I'd be very interested to know to what that 300ms "threshold of perceptible delay" applies. You might not notice a window taking 300ms to open - but I'd be willing to bet that when you're highlighting text with the mouse or dragging a slider, you'd be very aware of the UI lagging by nearly 1/3 of a second.

This is a lot of words that say "yeah, I was hyperbolic, but it was directionally correct." I do appreciate the candor but its a bit late, as you see by the text color of my comments. Many people do the same thing as you, no worries, I appreciate you validating my quixotic self-destructive work.

I'm sorry you're being downvoted - for the record I've upvoted since it's interesting, even if we disagree in some aspects.

Since I still have the machine in question here, and I'm now interested enough to try and get some rough measurements, I've just videoed it with my phone (30fps video) and done some frame counting, both from a cold boot with nothing cached, and also a repeated launch.

Firstly from a cold boot:

It's hard to tell exactly when the keypress registers, but I believe what I'm seeing is the key being pressed, two frames later the hourglass appears, two frames after that the calculator appears. (The TFT screen will likely be adding at least one frame lag, but let's ignore that for now.) So that's somewhere between 166 and 200ms for a cold launch.

If I close the app and repeat, there's now just one frame between keypress and hourglass, and just one more frame between hourglass and the app appearing, so now nearer 100ms.

Looking at the videos my finger is off the key the first time the app appears, but not the second time - though if I made a special effort to release the key as quickly as possible I now think I could probably just about beat it.

I was curious, so did a quick web search, which claims that 300ms is the average reaction time and plenty of people run faster than that.

But I think the question was the other way: Why couldn't calc.exe launch in 300ms?

I have Windows 95 on a Pentium 120 MHz and calc.exe is instantaneous enough that it's probably much less than 300ms to launch.

XP's calculator is hardly any different than 95. It's easy to believe that launching it on a Core 2 Duo of all things is also instant.

You’re both kind of right.

On the average consumer hardware at launch, 95 and XP were slow, memory hungry bloats. In fact everything that people say about Windows 11 now was even more true of Windows back then.

By the end of the life of Windows 95 and XP, hardware had overtook and Windows felt snappier.

There was a reason I stuck with Windows 2000 for years after the release of XP and it wasn’t because I was too cheep to buy XP.

The Doherty threshold is 400 ms. That’s the threshold which you start impacting users focus, and flow.

Back in the day, we actually used to aim for that as a user experience metric.

yeah no. Ask musicians using computers - 50 milliseconds of latency between sound and movement is generally considered unplayable, 20 milliseconds is tough, below 10ms usually is where people start being unable to tell.

You’ve fallen into the common trap of conflating reaction time with observable alignment time.

Reactions are about responding to one off events.

Whereas what you’re describing is about perception of events aligned to a regular interval.

For example, I wouldn’t react to a game of whack-a-mole at 50ms, nor that quickly to a hazard while driving either. But I absolutely can tell you if synth isn’t quantised correctly by as little as 50ms.

Thats because the later isn’t a reaction. It’s a similar but different perception.

Pressing a key to trigger an action that you will then send additional input to is an entirely different sequence of events than whack-a-mole, where you are definitionally not triggering the events you need to respond to.

I'm not talking about latency (though I don't fully agree with your statement but I've covered that elsewhere). I'm talking about the GP's comparison of reactions vs musicians listening to unquantised pieces.

You simply cannot use musicians as proof that people have these superhuman reaction times.

But here we're talking about not being able to notice whether calc.exe opens in less than 300 milliseconds, not how fast we can react to it opening? It's the same thing with audio latency (and extremely infuriating when you're used to fast software where you can just start typing directly just after opening it without having to insert a pause to cater to slowness)

No it's not the same thing with music latency. For one thing, music is an audio event where as UI is a visual event. We know that music and audio stimuli operate differently.

And for the music latency, you can here where the latency happens in relation to the rest of the music piece (be the rock music, techno, or whatever style of music). You have a point of reference. This makes latency less of a reaction event and more of a placement event. ie you're not just reacting to the latency, you're noticing the offset with the rest of the music. And that adds significant context to perception.

This is also ignores the point that musicians have to train themselves to hear this offset. It's like any advanced skill from a golf swing to writing code: it takes practice to get good at it.

So it's not the same. I can understand why people think it might be. But when you actually investigate this properly, you can see why DJs and musicians appear to have supernatural senses vs regular reaction times. It's because they're not actually all that equivalent.