The issue is that so many different companies and vendors say so and so, way beyond what is actually delivered for the end user behind the keyboard, that the mere words have pretty much lost all credibility to the end users.

For example I’ve personally seen >60 year old cashiers at a small pharmacy with arthiritis, trembling hands, and everything, flawlessly input over 100 complex commands per minute on 30+ year old machine with a software design probably from the 70s.

With 0 bugs, 0 human perceptible delays, and not even a single misinput.

Other than the obvious — keyboard shortcuts — this also heavily relies on being able to input ahead of time, before the next screen is even drawn. Older systems buffer inputs and apply them correctly to the interface elements as they become visible.

The modern web does none of this, which is why users have to wait for each screen before inputting the next command… if it has a keyboard shortcut. It probably doesn’t.

Yeah and the worst part is, nobody, not even quite serious vendors selling stuff with all sorts of bells and whistles, do any sort of benchmarking on all these various paramters. (That I’ve seen)

So even if people wanted to believe and buy so and so product, they have no way to substantively compare who is more honest.

Not quite true. Worked at epic previously. Due to the culmination of a 10 year migration from VB to electron, the os level input buffer was discarded mid 2023 since electron doesn’t handle those the same way. The primary reason for this is that VB was pretty much synchronous. However, web technologies don’t act the same way because keeping your keyboard inout while navigating to a different site would be weird.

We added an input handler to queue inputs so that sequences of shortcuts and keypresses could be used.

Additionally, the internal framework we had allowed for shortcuts and we tried to replicate as much as could shortcut wise (as well as functionality wise). Almost everything should have a shortcut or a way to navigate to it via just keyboard — they had put in a lot of effort to ensure accessibility so that they could get the va contract that went to cerner(pre-oracle acquisition)

> We added an input handler to queue inputs so that sequences of shortcuts and keypresses could be used.

You must be one of the few (or any) companies that did this.

This definitely doesn't work in the general case of SPA web apps.

> However, web technologies don’t act the same way because keeping your keyboard inout while navigating to a different site would be weird.

Depends. It is not the place of the underlying tech to impose such limits.

> The modern web does none of this, which is why users have to wait for each screen before inputting the next command…

Or wait further. Many web screens appear in a state that is initially nonresponsive, becoming responsive invisibly after an unknown and variable period of time taken for code to load.