Some things I observe from watching these apps is that navigation clues are always present, keymappings are static from screen to screen (F1 is always help, say), and the UI is such that the user is always in control of the application state.
Some things I observe from watching these apps is that navigation clues are always present, keymappings are static from screen to screen (F1 is always help, say), and the UI is such that the user is always in control of the application state.
Sitting in large offices with rows of desks and a huge clock on the front wall, they weren't interacting with customers, they were transcribing from sales sheets, order forms, application forms, etc. prepared by someone else.
There was no great need for user friendliness, because the only users were in house, and they performed the same data entry hundreds of times every day.
The only need was for speed.
The arrival of the PC started changing everything, as people got familiar with the mouse and GUI.
Somehow mouse-based GUIs became the default for everything, which made a lot of sense as at the same time data entry was pushed out to the users themselves and intermediary data entry staff disappeared.
But if you want a fast, simple way to quickly perform common transactions even on very small screens, old school TUIs have a lot to learn from.
Keyboards are just faster once you learn them.
In a traditional TUI you can type at full speed and the system will process the keystrokes as it is able, with no keystrokes being lost. If a keystroke calls up a new screen, then the very next keystroke will apply to that screen. Competent users could be several screens ahead of the computer, because the system doesn't make them wait for the UI to appear before accepting the keystrokes that will apply to that UI.
It's not something windows does or can disallow. You just focus the window in the code and that's it.
Reminds me of https://en.wikipedia.org/wiki/Therac-25
What works best is heavily task dependent, and also needs to account for cognitive load and training requirements. Stations with few primary tasks taking limited input (e.g., product lookup forms and customer purchase forms) lend themselves heavily to a keyboard driven UI, but many others either do not. In that area, it ends up just being a strong personal preference guiding what seems best.
My girlfriend works in a bank and she does virtually everything in a TUI.
She hates it, but I've seen her using it and she's blazing fast and I can't, as a frontend developer, imagine how a full blown application would be better.
On my side I'd much rather have the efficient UI but I can imagine people getting tired if their mind is working 100% all the time.
Copy pasting is also troublesome, and that one is a common scenario to copy/paste from emails.
But it would require people to use full size extended keyboard (function F rows, numpads, etc). Which shrinks the user base quite a bit.
Whereas in indie coffee shops they use a Square tablet and in Apple stores the store people just use iPhones with special cases. Best Buy or Walgreens uses POS tablets with a relatively ugly GUI.
Legacy apps never die. Charles Schwab might use mainframes while Robinhood won't but Schwab won't move off because it's too hard for an established firm. Same with Costco TUIs.
I think it's a mistake to frame this as legacy vs. new. There are real benefits to the approach taken by these TUI applications and it would behoove modern app designers to learn from them.
It's perhaps the case that those coffee shops will someday adopt a TUI once they reach a level of sophistication. As an example: I believe Starbucks uses a TUI for order processing.
At least at the time, it sounded like they made a completely new application... and explicitly went with this stack.
Now, before you point to Amadeus still being command oriented just like that, modern Amadeus is accessed over GUI client - even if you're going to use all console commands.
Meanwhile when I had to reschedule a flight due to a volcano exploding and grounding all planes, I got to see what the KLM/AF local agent did. Fullscreen red-on-black TN3270 session. Took only a moment to handle my case and throw in a few extras.
- Excel
- 3D modeling tools
- Adobe Creative apps
- Programming IDEs
- ?
Also, if you are focused on that metric: the productivity of the power user, then in many cases adopting a more modern GUI framework will not necessarily make it easier to achieve that goal (and in some cases may make it harder).
Thus there is no innate framework benefit, only downside, so it doesn't make sense to handicap yourself tying to this legacy
And that can be a nice improvement to e. g show your code at a normal size but pop a tooltip up with smaller text, or have the linter/errors tab be a smaller font.
But that's a difference and not necessarily an improvement, because having a consistent font and fixed width text can make things more predictable and faster to interact with as you don't have to scan around as much.
> fixed width text can make things more predictable and faster to interact with as you don't have to scan around as much.
In what way does "i" not looking as wide as "w" force any scan speed deterioration?
These folks were fast in the TUI but extending them to 2-4x the workspace was an insane productivity booster. This yard ended up being bought out in part to how we managed to extend email and virtual terminal capabilities and was the basis for the footprint of the LKQ brand at the time. I'm not sure how any web app could compete. TUIs are amazing workflow enablers.
Did some work for Lowe's Home improvement and their PXE booting thin clients in the early 2000's.
If you spend a couple 8 hour days doing returns or checking people into flights or whatever, you'll get good at the regular stuff and the usual exceptions. Or you won't and maybe there's something else you can do.
Most of the time, the real tricks are knowing how to move to the other fields when it's not obviously tab, and what the button is to get into the exception menu. And then learning the layouts to scan the page for what you need.
On a mouse driven system you can usually click into the fields you need, but if you need to, it's usually gonna be slow.
What magic makes TUI faster than GUI?
TUI just use glyphs to render the interface. AFAIK that's not faster that a proper graphics engine.
Keyboard shortcuts are not exclusive to TUI.
Maybe if we would stop hyping UI gimmicks and put more focus on fundamentals, there wouldn't be so many bad GUI apps.
The only difference is that TUIs are worse at displaying... text (and graphics)
While they've modernized a front-end to GENESIS (see their current POS deployment), there's still an option to dump the system back into a TUI for advanced features (the Alt+F12 option).
Charva - http://www.pitman.co.za/projects/charva/index.html
AbsTK - https://gobolinux.org/abstk/