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.
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.