If you are in the US, pick a slow day and chat to the customer service people at Lowes or Costco. Both stores use TUI interfaces for their instore service apps, and boy are they fast with them. They reserve GUI things for the self service point of sale systems and keep the TUI for cases where speed matters. I suspect that these apps might once have been mainframe hosted (in other words, screen-oriented, with the PC terminal doing local processing and not sending the request to the server until the user hits Send) but of course those days are long gone and I imagine that at worst they are running on a TN3270 emulator and more likely they just expose a remote app in a browser or RDP session.
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.
Back in the old days, the primary users of many mainframe UIs were the data entry team (almost universally female).
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.
It's part of it but not all of it. Today's modern UIs won't buffer keystrokes as you move between UI contexts. You often have to wait for a bit of UI to load/appear before you can continue, or else your premature keystroke will be eaten or apply to the wrong window. This kills your throughput because you have to look at the screen and wait to recognize something happening. Even if you have all the keystrokes memorized, the UI still makes you wait.
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.
This works if you have one app with a completely dedicated computer. But that's a limitation on the popular systems. If you have an automatic focus switch to new windows, like Windows/Mac pretty much enforces, you can't buffer input. An incoming call to your VoIP system would be dropped/redirected, because you were typing the right thing at the time.
No, Windows goes out of its way not to allow a popup window from a background application to take focus. Instead, it blinks the taskbar icon. An incoming call should not start eating the keystrokes you were sending to the active application. Focus stealing isn't totally solved as an issue, but it's certainly regarded as a problem to be solved and not the desired behavior.
That's nowhere close to my experience. Things that steal focus constantly: 1password losing SSO token, UAC for an application's backup, 3CX call coming in, every random thing in vscode, ...
It's not something windows does or can disallow. You just focus the window in the code and that's it.
https://danluu.com/keyboard-v-mouse/ - "Unlike claims by either keyboard or mouse advocates, when I do experiments myself, the results are mixed. Some tasks are substantially faster if I use the keyboard and some are substantially faster if I use the mouse. Moreover, most of the results are easily predictable (when the results are similar, the prediction is that it would be hard to predict)."
Mice + keyboards are good for versatility. When you need more than data entry or non-tabular (images, video) data entry or processing, having a mouse is key.
A mouse is not itself a problem, although most functions should be operable by keyboard. When selecting objects and points on the screen, the mouse is helpful. It is best to have both, although I would think that a keyboard alone is generally better than a mouse alone.
While I prefer to use a keyboard, it is not true that keyboard are universally faster. Even text navigation can be significantly faster with a mouse if done right, especially if you start to go into button chords.
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.
I've been transitioning many mobile apps I rely on to TUI-based alternatives or creating custom apps for personal purposes. Honestly, our obsession with eye candy has led us astray. Consider this: navigating old.reddit.com is significantly faster than browsing www.reddit.com. While there's a time and place for visually appealing designs, when it comes to conveying information efficiently, every non-informative element on the screen can hinder performance. I think we all intuitively know this - UI design is trending towards minimalism at the moment.
What I've seen on Costco scanners looks identical to the menus in Koerber/Highjump's "Advantage Platform". If they're anything like us they are just running a telnet client on a ruggedized Android decvice. Once you use the system for a bit you build muscle memory and don't even need the menu text most of the time.
The AS400/OS400-like interfaces always seem like they should be more popular super-user interfaces. They seem best at navigating tree-like data but most OS level interfaces feel tree-like these days. I think the affordances work a little better than vim-keys sometimes. A vim-mode option or command palette would be straightforward.
But it would require people to use full size extended keyboard (function F rows, numpads, etc). Which shrinks the user base quite a bit.
The navigation cues are a huge point. So many cli tools today run on cmdline flags, and it’s so frustrating to have to look them up each time. There must be a better idiom then —help or full curses applications.
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.
I remember around 2010 seeing ads about how KLM/AF did a huge upgrade of their passenger handling system - and how they explicitly went with TN3270 talking to z/TPF application as the new main interface for agents to use.
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.
But there are no benefits, you can replicate everything in terms of user interaction identically in a more readable/better looking GUI app, so efficiency is maintained
Sure you can, but it's rare to see a GUI app built keyboard first and specifically optimized for the productivity of power users. The list of apps that do this successfully is a tiny fraction of the total.
- 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).
TUI apps aren't optimized for the productivity of power users, and by the same token, replacing a GUI app with a legacy TUI framework will not necessarily make it easier while almost definitely will make it harder since some advanced productive UI patterns simply don't get implemented in TUIs - they might not've been invented/known at the time this legacy framework was created
Thus there is no innate framework benefit, only downside, so it doesn't make sense to handicap yourself tying to this legacy
why would a gui app be more readable for reading text?
The only inate difference I can think of is the ability to vary fonts and rendering based on what you are rendering more.
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.
Someday the COBOL programmers are going to cross the sea to the undying lands and there's going to be a reckoning for companies that have kept legacy apps around this long.
Before Apple switched to the iPhone for their POS system they used iMacs with a very ugly app. I think it was called iPOS. I know as a customer I wasn’t supposed to see it, but I was surprised Apple used something like that, considering Jobs always talking about how even the inside of something that no one ever sees should still be beautiful.
My favourite is how what most people think of "apple store" in Poland the Macs that run sales will actually run windows with BootCamp and run some run of the mill POS/ERP software.
I wonder what they'll do when they will have to switch to ARM-based macs without BootCamp support. Also, do you mean Apple resellers that market themselves as actual Apple Stores? I don't think there is an actual Apple store in Poland yet
Genuine Parts (large US based auto parts retail) is similar. The folks working there are working on turbo muscle memory and navigate the system impressively quickly.
Way back in the mid 90s I helped convert one of the largest auto salvage yards from dumb terminals (Wyse) to NT machines using terminal emulation. The sales folks went from having been limited to physical desk space or multiple terminals to multiplexing serial over Ethernet.
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.
I'm 35 and DOS applications in Windows machines were a common sight in India. They gave way to GUIs that can cram so much data in a 1024*768 black and white screen that I hate most webapps running on my 5k perfect color accuracy screen and can be quickly navigated by a loud mechanical keyboard.
I’ve always wondered about this. I get that a keyboard driven text interface can be extremely fast for an experienced user. However, when I think about a lot of the places I see them, they are retail jobs with what I can only assume is high turnover. The text interface has to have a much higher learning curve, which I would think would only pay off for jobs people work in for a long time.
Some of these jobs you simply need to be fast or find something else to do. When you're new, your supervisor is near by, and you learn how to do the easy things, and ask the super for help with exceptions.
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.
> Both stores use TUI interfaces for their instore service apps, and boy are they fast with them. They reserve GUI things for the self service point of sale systems and keep the TUI for cases where speed matters.
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.
It's not keyboard shortcuts, it's pure keyboard input; an important distinction to make, as with modern GUI interfaces, keyboard input is often an afterthought.
I fully agree. I made a TUI client/server framework loosely modeled around the concepts of CSS/HTML. One of my core design decisions was keyboard only input.
Yep. Many long-time Lowes employees will remember specific GENESIS screens to drop into by their numeric shortcuts and whip through the system.
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).
If one were to start a project from scratch today, with the goal of having such a hyper-efficient TUI, similar to the Lowes/Costco ones, to be accessible via SSH/Telnet/locally... are there frameworks out there to use? Would my best bet still be ncurses? Are there simpler alternatives?
The `rich` module for Python is remarkably complete and lets you code at a very high level - even has CSS. Rich's sibling, Textual[1] is designed for building TUIs.
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.