I can say that I am also satisfied with many old programs for these reasons, and sometimes other reasons too. When writing new software, I generally try to design it like that too, with keyboard for everything (or nearly everything), and with dense layouts.

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.

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.

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

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)

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.

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

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.

I'm sure it's going to be way way way better.

[edits: cerner not epic?; added another way to emphasize how much better it'll be.]

There’s a link to the OIG reports themselves. It’s almost certainly not the software itself, but the way it was configured and rolled out. Cerner is the market leader for EHRs, so I highly doubt it’s intrinsically flawed; just so configurable it’s easy to cut yourself on the edges.

https://www.military.com/daily-news/2025/01/02/va-sets-sight...

PoS software really plateaued in the 90s. The most common flows were so simple an average user can hold a mental map of the program and always know exactly how to get where they need to be. Pros can fly through ten levels of menus in literally half a second to access some obscure report.

In modern UI we've totally given up and just give the user a search box on every screen. Instead of a clean indexed list of menu items you can hit a key to access, we have to fumble around with tooltips.

I worked at an old grocery store running the front office as a teenager through college maaaany years ago, and everything was a keyboard shortcut, non-touchscreen driven interface from probably the early 90’s. It took some time to get used to and train others on, but I could fly through those interfaces in a way a modern UX simply does not allow by focusing on the lowest common denominator for usability instead of any attempt to cater to ‘experts’: aka the people who have to use those interfaces day in and day out.

Sure, the modern interfaces look great (usually) and in the ideal state anyone can pick it up and use it without much instruction. But there’s no attempt to focus on the poor soul who has to use it in their day to day and just wants to get it done as quickly as possible.

Once I learned how to edit using the buttons and the scroll wheels, I could fly through putting together a news segment with all kinds of cuts, fades and overdubs. I remember thinking, I couldn’t believe how fast my fingers were flying.

The closest thing I can compare it to is learning how to play a guitar; after a certain point muscle memory takes over.

The key thing would be some sort of input-buffering system, where you can have lots of things bound to keys, and the framework will actually buffer things. Generally web browsers and modern UIs in general throw away input on reloads and such, on the generally-correct but very novice-biased theory that you didn't mean to be inputting into a screen you can't see yet. If you undo that and allow buffering keystrokes across loading actions you could start recovering some of that expert-level speed, where you can be using screens that aren't even loaded yet.

"Expert-focused" UIs don't have to be bound to the terminal. That was all an accidental thing.

Expert-focused UIs are nearly dead because all our UI frameworks actively block them. That is also not a fundamental fact of computing and can be undone.

(The other tool that comes to mind is Emacs, but that's appreciably less mainstream than the command line in general.)

I doubt we'd be doing full page redraws and slinging json of all things. I think what you'd end up with is something that looked a little more like a game engine than react. That would be a fun project to work on.

I certainly wouldn't stop at input buffering. Another I'd want is some sort of systematic keypress discoverability. You still probably want a conventional GUI at least mostly available but using the GUI ought to be constantly teaching the user how to do whatever it is they just did with the keyboard instead. This might as well get wrapped into the framework, to standardize it and to make it easy to use.

Unfortunately, one of the many shortcomings of the web as an application and GUI platform is (a) no menu bars, (b) no context menus, (c) no accelerator key framework, (d) keyboard focus is often nowhere in particular or somewhere stupid that will do something bad if you touch the keys.

Would they even know? There was a time when there was such a thing as domain expertise and when usability studies were an integral facet of many SDLC. Those days seem long gone now. The industry seems far more content to haphazardly adapt OTS solutions or create something that's "pretty" or "modern" at the expense of being functional.

Key point. We are now in a UI idiocracy.

It needs to be easy and quick. Doesn’t matter if they are pros or people doing college jobs.

In industries with high staff turnover, it's probably better to have slower workers but with much lower training costs.

Web tech definitely makes it harder to give a really snappy experience.

As a related aside, I recently visited Microcenter where they run their own PCI-compliant PoS system that's all text based. The staff all knew how to zip through various text menus to apply discounts, warranties, etc.

There have never been enough highschoolers to fulfill all the """not real""" jobs that people keep insisting shouldn't pay enough to live. Hell, you used to be able to live on flipping burgers. In plenty of modern and democratic countries you actually still can live while flipping burgers.

Depending on your demands on quality of life I'd doubt that.

Somewhere 1988 to 1989 I 'flipped burgers' as a so called crew-trainer fulltime, and made almost 5000 Deutsche Mark per month (after taxes, 'netto'), due to mostly working late/night-shifts.

Inflation adjusted that would roughly be about €5000/USD now. I think you'd be lucky to reach 2400 to 2800 now, as 'normal' burger flipper, or one level up, as crew trainer, no matter if working late/night shifts. (Because the financial benefits of working late/night are mostly gone now)

I would use the desktop client but it doesn’t have an interface to hyperlink to files in sharepoint.

You’re lucky to get any tooltips nowadays.

Huh. Any etymological connection between "helvetes" and "Helvetii"/"Helvetia"?

https://www.theregister.com/2024/11/27/oracle_cerner_project...

In 2021 an expensive system for schools in Stockholm was so bad that some parents got together and wrote an open source app to not have to use the bad official UI.

https://www.wired.com/story/sweden-stockholm-school-app-open...

I do not think a language barrier is at play; Norwegians and the other Scandinavians are among the most fluent English speakers of English as a second language in Europe, surpassed perhaps only by the Dutch.