Is anybody still using TUI applications for business?
My family company is a wholesale distribution firm (with lightweight manufacturing) and has been using the same TUI application (on prem unix box) since 1993. We use it for customer management, ordering, invoicing, kit management/build tickets, financials - everything. We've transitioned from green screen terminals to modern emulators, but the core system remains. I spent many summers running serial and ethernet cables.
I left the business years ago to become a full time software engineer, but I got my start as a script kiddie writing automations for this system with Microsoft Access, VBA, and SendKeys to automate data entry. Amazingly, they still have a Windows XP machine running many of those tasks I wrote back in 2004! It's brittle, but cumulatively has probably saved years of time. That XP machine could survive a nuclear winter lol.
I recently stepped back in to help my parents and spent a day converting many of those old scripts to a more modern system (with actual error-handling instead of strategic sleep()s and prayers) using Python and telnetlib3. I had a blast and still love this application. I can fly around in it. Training new people was always a pain, but for those that got it—they had super powers.
This got me thinking: Are other companies still using this type of interface to drive their core operations? I’m reflecting on whether the only reason my family's business still uses this system is because of the efficiency hacks I put in place 20+ years ago. Without them, would they have been forced to switch to a modern cloud/GUI system? I’m not sure if I’m blinded by nostalgia or if this application is truly as wonderful as I remember it.
I’d love to hear if and how these are still being utilized in the real world.
P.S. The system we use was originally sold by ADP and has had different names (D2K, Prophet21). I believe Epicor owns it now (Activant before).
P.P.S. Is anybody migrating their old TUI automation scripts to a more modern framework or creating new ones? I’m super curious to compare notes and see what other people are doing.
> UX absolutely peaked with TUIs several decades ago.
I'm going to push back a little on that. For several years, MacOS followed a strong UX convention with consistent keyboard shortcuts, menus, layout order, and more. Similarly, Microsoft started with the same, but with everything reversed. At the time, most major cross-platform apps followed these conventions.
Two periods broke these rules: the expansion of web apps and Apple's pivot towards the consolidation of everything into iOS.
First was the dawn of web apps. Faced with two opposing standards, web apps didn't know which model to follow. Business sites stuck with MS standards, while design-centric sites followed Mac standards. As those broke consistency, cross-platform apps gave up and defined their own standards.
Mobile platforms tried to establish new standards. iOS was mostly successful, but started slipping around iOS 7. Material Design was supposed to standardize Android, but Google used it for all Google products, making it more of a standard for the Google brand than Android.
The second started around WWDC 2019. At that point, Apple deprioritized UX standards to focus on architecture updates. The following year, Catalyst was literally a UX catalyst, introducing two competing UX standards for MacOS. From that point forward, Apple really hasn't had a singular UX standard to follow anymore, but they seem to be marching towards iOS standards for all devices.
> > UX absolutely peaked with TUIs several decades ago.
> I'm going to push back a little on that. For several years, MacOS followed a strong UX convention with consistent keyboard shortcuts, menus, layout order, and more. Similarly, Microsoft started with the same, but with everything reversed. At the time, most major cross-platform apps followed these conventions.
I used Mac OS during that era. While in many ways it was better than the GUIs we have now, using the mouse was an absolute must, which prevented it from ever getting as efficient as a TUI. Yes there were keyboard shortcuts, but they were never sufficient to use the machine or any application without a mouse. Also they had to be completely memorized to be useful.
In 1991, I used Inside Macintosh for inspiration, but a much broader view of interface was distilled in the MITRE Corporation user interface book.
MITRE successfully conveyed how to have keyboard-operated GUI with plenty of power user modes --all with discoverability. You might call it "fallbacks for every mode".
Its principles combined TUI (then known as CUI) and GUI as well as DSL (domain specific language).
A fully architected program having a DSL (domain specific language) had a console much like a macro recorder: as you used the menus and icons, the console would show the commands you could otherwise type in to get the same effect.
You could edit the console line and re-execute it.
In the 1990s, DSL was a buzzword but if you got it right, your GUI was a power tool.
I think Microsoft Office 2007 moving to a "ribbon" rather than normal menus and an optional toolbar for certain things was the major break in usability. Mac OS has kept the menus, and added a really useful menu search thing in "help", and this is huge.
I think sublime text was one of the first to bring the TUI style super-powers into the modern desktop UK, where you press some random keyboard shortcut (e.g. cmd-p in sublime) and you can instantly start typing a command.
Another thought I have had for a long time is that when GUIs like Mac and Windows were taking off, they were often described as more "user friendly" than TUIs. I always thought this depended on the kind of user. A lot of effort went into prioritising making it possible for an untrained user to use a system, but making it fast for someone with experience was no longer important.
Emacs has “M-x” for ages before sublime.
What is one of the advantages of TUIs is that every action is deserialized from a common stream and that stream is buffered. This means both an advantage for speed, but also for a simplification for interaction, since if the user wants it, the information can flow in one direction only and the other direction happens only when the user wants it.
Since GUIs are not scriptable, unlike command-line TUIs, a GUI can never be as fast or as customizable as a TUI, which makes them inherently less usable. It doesn't help that the Mac was partially inspired by the work of Jef Raskin, who was religiously opposed to customization.
When we built systems in the early 90's (non web GUI), typical requirements were that login/startup would at most take a few seconds and any user action would have to be satisfied with sub second response time. I often think about that when I am waiting for the third SSO redirection to complete or the web page to complete its 200 web requests after a single click. We gained a lot but efficiency seems to have taken a backseat in many cases.
Decades of progress made in hardwares and networks… just to be negated with 100kb+ webpages
> I will say that these systems take time and effort to learn. You have to commit these UI paths to memory, which isn't too hard, but in order to be maximally effective, you also have to memorize a lot of product metadata.
One thing that often gets lost in the discussion of TUIs vs GUIs is that this is also true of GUIs. You have to know which icon to click, and it's not always in the same place, and not always labeled. Increasingly, functionality is hidden behind a hamburger menu, and not laid out in logical sections like File, Edit, View, etc menus.
The cool thing about TUIs is that everything has an explicit label because it has to be this way.
On the system I use, every menu item was prefixed with a number. You punch in that number on the keyboard and you're in that menu. Just absolutely beautiful functionality
I had a summer job in a place with one of these. When I started, I was like “how does this guy know the 15 digit number for these screws?” By the end, I know the code for screws in general, the code for popular types, metric/imperial, and then it was like length and size. The numbers flashed up as well, so you wouldn’t have to memorize anything, but you quickly didn’t need to see the numbers for popular items.
This is the way. The "bicycle for your mind" that Jobs wanted. It augments your memory and enhances everything you do, and at every step you quickly internalize a system that doesn't change according to the whims of far-distant web devs.
GUIs used to have this too of course. Alt-F to bring up the file menu, the hotkey was underlined.
That seems to have slowly vanished over the last 30 years
I still have this and I loath programs that breaks this consistency by shipping their own graphics toolkit stacks. This is a reason for me to deinstall a program and never use it again. Programs that are not 3D games or specialized CAD programs should only be allowed to use the OS graphics stack and nothing else. (This includes programs shipped by the OS vendor.)
IMHO touchscreens just seem to keep falling into the same traps. Here's a big pile of unlabeled mysterious buttons with cryptic icons, at least one of which will probably ruin whatever you're doing without being able to go back. How do I know what it will do? Paw at it meekly and hope for the best!
You're right to point out the speed, but it is just not true that GUIs can't be fast. You can have screens that load quickly and shortcut keys etc.
You just have to make fast navigation and data entry a high priority. The assumptions and approaches people make today mean that generally isn't the case. With a TUI there is a hard limit on the amount of data you can load and that helps as a starting point.
- Often it's hitting a server is that is far away rather in the same building.
- Each page is very heavy with lots of JavaScript etc. loading - Data loading delays rendering - Data is slow to load - Slow to navigate with mouseMany years ago I used a TUI retail/inventory terminal that was running in an SSH session over a painfully slow wireless link. Each keystroke came with several seconds of latency. This was not a problem, though, since I'd memorized all the important menu sequences. I could just punch in a rapid-fire string of keyboard strokes representing an entire transaction and then just wait a few moments for the screens to catch up and a receipt to print.
I think this is one of the deepest problems with modern UIs - event delivery is no longer reliable. You type "abc" and only "ac" gets delivered to the application, or "b" ends up sent to another window. Maddening.
I do this to this day, over a crappy kilobyte line via Phone via Bluetooth and it works great.
At work we recently moved from Jira to Linear. It it fully keyboard navigatable and has shortcuts for pretty much everything. It's great! For me the only downside is that al that keyboard greatness clashes with my Vimium browser extension. Oh well...
You can also buy a car, remove all it's part and do the road on feet. I'm not sure how the car was helpful to move across the roads but hei we have a car.
> You just have to make fast navigation and data entry a high priority. The assumptions and approaches people make today mean that generally isn't the case.
Indeed. Most developers today make their own easiness of development the priority, not anything related to the end user's experience. This is why software is so bloated and slow, but the pernicious idea of "developer experience matters more than speed" doesn't seem to be going away any time soon.
There is nothing stopping someone from designing GUI stemming from same rules. It just won't "look pretty" and be easy to sell to the suits.
There is also trend with "modern" UI/UX to focus near entirety of effort on user's first few minutes and first few hours with a software, while near zero thought is being put on users having to use given piece of software for hours at end, day in, day out
I definitely see cash register/POS systems like this out in the wild, replete with ugly fonts, Windows 3.x style buttons, and even F-key legends at the bottom. So somebody somewhere is thinking of the poor cashiers.
The entire GUI was sold on it being easy to use for beginners. There's a reason why keybindings are today called "shortcuts": Steve Jobs's diktat was that the primary means of giving commands to the Mac was the mouse. Anything you can do on a Mac (except for entering text) was to be done with, and designed around, the mouse. Keyboard "shortcuts", so called as a quicker way to issue (some, but not all) menu commands, were a sop to power users but really were an addition, not essential to use of the program.
Windows, by contrast, was designed to be keyboard-accessible. Not all PCs in 1985 had mice...
I still work on a system where it sometimes says to press F17 to do something…
And no, we don’t have the glorious keyboards from that time :( just standard 104s
I once booted Windows 2003, it is crazy how you can intuitively interact with it via keyboard, without being familiar with that UI or ever having used a computer from even that era. It takes like ~40seconds to figure it out after trial and error.
> while near zero thought is being put on users having to use given piece of software for hours at end, day in, day out
And those users want more batch creation and editing.
> It turns out that if you never change the UI and every menu item always has the same hotkey, navigating the software becomes muscle memory and your speed is only limited by how fast you can physically push the buttons.
Oh, I’ve been a new hire at places like this.
The day1 stuff in the system will be logically or coherently placed (e.g. alphabetically) and then the rest will be incrementally added on top.
The menu options will go like this:
1. Alpha
2. Bravo
3. Charlie
4. Turbo-Bravo
5. Charlie-Undo
6. AAAlpha
Great for day1 users that are still there and started with just 3 options but new users are screwed. The arrangement started to stop making sense circa 1995.
I’ve seen the same thing where parts shelves were sorted by manufacturer (to make re-ordering by manufacturer simple).
When they moved to automatic inventory, shelves didn’t matter anymore and if a part was made by manu1 but now manu2, they’d keep putting it with manu1 because “that’s where everyone’s gone to look for it for the part 20 years”.
All you had to know was who made that part in 2003 when auto-inventory stopped forcing them to be consistent by manufacturer to know which shelf to pick from. Easy!
New hires get screwed and over time nothing makes sense anymore.
I remember training a new hire on her first day and, about an hour in, she said she needed a coffee break. I never saw her again lol.
Typically the first two weeks of training revolved around new hires asking why in the world we used this system before their spirits broke and they reluctantly plunged into the deep end...kind of like being released into the matrix.
Heh, I can relate. We employ a lot of Linux and Windows admins, for them it's usually not a big problem.
We also have a small finance team (typically around 2 employees), and finding somebody with a finance/billing background who is willing to work with TUI on Linux... that was a challenge :-)
> We've really lost something very important with the shift to GUI and the shunning of text mode.
GUIs can have keyboard shortcuts too. I'm an artist and I work two-handed: right hand moves the stylus around the screen, left hand floats around the keyboard and changes tools, summons control panels, etc. Whenever I try a different program than the one I'm used to, and have to poke at icons with my right hand because I don't know its shortcuts, I feel like half my brain's idling.
You see this a lot with videos editors. A professional video editor flies around in their software of choice like an sales person in a TUI. Both are inherently proficient with their tool, to the extend that it's hard to graps what's actually happening on screen. We also see this with editors and IDE. Some people cruise around Emacs or Vim, while other hit a few keys and Visual Studio or IntelliJ will refactor 500 lines of code in an instant.
The TUIs are a little funny, because often people can navigate and input faster than the program can render. So you vaguely see a screen change, a menu move or an overlay pop up, only to instantly disappear. The user doesn't need to know what's happening on screen, because they trust their fingers and the system to do the right thing.
Movie editors are as persnickety about their editing software as we are about ours, it turns out, for many of the same reasons: we accumulate years of proficiency with a tool and don't want to have to retrain in something else without a clear head-and-shoulders advantage.
> The TUIs are a little funny, because often people can navigate and input faster than the program can render. So you vaguely see a screen change, a menu move or an overlay pop up, only to instantly disappear. The user doesn't need to know what's happening on screen, because they trust their fingers and the system to do the right thing.
I learned this while creating some autohotkey scripts: I could have the macro click before the button was shown on the screen.
This also created some problems where users would unintentionally hit their scroll wheel after clicking and change a 1 to a 7 on the next screen before it even appeared. That wasn’t good…
> The TUIs are a little funny, because often people can navigate and input faster than the program can render.
Yes, but the it's not due to slow rendering speed. GUIs render even slower.
We solved this with mnemonics (underlined letter is the shortcut) but then got rid of them for some reason
I love the system in Autodesk Animator (now: https://github.com/AnimatorPro). Every menu item or button currently on the screen always have a unique initial letter. There is no need to highlight or underline anything. Amazingly this was done without having to use any too obscure labels (but I doubt it would be fun to try to translate it to other languages). Almost every function is two or three single letter key-presses away, and after using the application for a while you will have memorized more and more of those.
Some frequently used functions have their own special single-key shortcuts as well, so instead of having to press C-P (to open the Clip menu and then select Paste) you can just press the ' key, saving the user a key-press every time they do that.
Oh yeah - AutoCAD by Autodesk was also like this. Once you memorized the keystrokes, you could fly through your line drawing.
I recently rediscovered that I can do GUI menu things on the keyboard in apps like VLC. Feels like a magic trick -- the best of both worlds. Was it the move to phones that did it? Or did most people not use alt shortcuts?
My memory is hazy but the heydey of underlined shortcuts was in the era when not everyone used a mouse, if I remember right - support was strong in e.g Windows 3.1 (dating myself a bit here) and got worse from Windows 95 onwards...
Some keyboard apps will input those shortcut combos. Many work on phones. I found out when using a Bluetooth keyboard one day for some emergency doxument create when I got stuck with both a deadline and a dead laptop.
Doesn't work with internationalization. P for Pencil is great in English. P for Crayon en Français? Non.
Doesn't work with reassignable keys, either. If I wanna reassign the shortcut for "pencil" to "d" because it's easier to hit with my left hand then that's my own business.
> It's absolutely crazy that a well designed TUI is so much faster. It turns out that if you never change the UI and every menu item always has the same hotkey, navigating the software becomes muscle memory and your speed is only limited by how fast you can physically push the buttons.
Bloomberg Terminal basically. And then because of muscle memory, it's so hard for users to get used to another system. And then they push it onto their juniors. And then you get to charge companies $250 per head to train juniors on how to use the system, with all of its textbased commands.
Ha. I experienced two decades of Bloomberg. It was always a melange of ancient Fortran tabbed forms with never-to-be-fixed bugs and newer consistent TUI. By 2010 they had started to pile on mouse menus.
The advantage was in typing a command and most of its arguments quickly.
I hope you didn't seriously associate the price $250 with Bloomberg training. Everything Bloomberg has a lot more zeroes after it, except what they pay to new hires in Princeton.
> Everything Bloomberg has a lot more zeroes after it, except what they pay to new hires in Princeton.
I ROFL'd. They even bumped up our prices from $25k to $36k annually.
I worked for a small company that had a project with Bloomberg. We went to the office downtown, and being the clueless Upstate hick that I was, I saw the text-based UI up on a screen and asked my boss — a little too loudly — if we were at an auto parts store.
"Shhhhh! That's the Terminal!"
A single $250 payment per head for training is quite cheap if you consider the hours saved at not waiting for awfully slow SSO redirections to complete and web page refresh.
It was a 3 day online course that I had to pay for out of pocket during my internship. :(
Granted, that internship led me to where I am now, so I'm not complaining.
I worked at a big-box retailer before figuring out a career. They had an old-school TUI that was incredibly fast and well designed. Function keys to do all kinds of lookups and adjustments, advanced menus when you needed them, overall just a well designed system. People took a week or so to get the hang of it but then the skill ceiling was insane, people could get fast.
A few months before I left they switched to a "modern" GUI. It was shockingly bad. The speed of every transaction lowered. Even with optimal use it just took longer. So much time wasted.
> Many (most?) older retail businesses still use TUIs. They're reliable, consistent, and orders of magnitude faster than GUI systems.
What is sad is that is doesn't have to be that way. But you describe is not an intrisic characteristic of a TUI, but of using keyboard instead of a mouse. You can write a webapp that performs in the same way (modulo the resources needed of course), but it takes extra time and once it works with a mouse there little reasons to put more work for keyboard user (it is not a selling point in most cases).
The main advantage of a TUI is that it forces to write the UI in a certain way, so you get the result automatically.
> Once you learn that you can pop into a quick order menu with this specific sequence of five keys, you just automatically open the right menu the moment a customer walks up. No thought, just pure reflex.
This works because you can 'buffer inputs' as the gaming crowd says. You can hit the keys and the computer reads them one at a time and does what you asked at its pace. Often these kinds of systems do run faster than the input, but when they don't, it still works.
It's hard to do that with a GUI, you usually can't click (or tap) the button before it shows up and expect it to work... and when it does work like that, it's often undesirable.
Similar story.
I worked for a medium sized company who did work with Toro. We supplied many of their lubricants and they had TUI they still used on one of their machines to enter the orders from our company. It was the last of their legacy products, but worked incredibly well. We had very little issues ever with the system. Our Oracle ERP Net Suite? Had three people dedicated to making sure it ran smoothly. I still remember some of the guys I used to talk to at Toro were "lifers" who were always talking about how easier things were before all the SAAS and ERP software came on the scene.
The stories they had were pretty entertaining.
I agree with basically everything you've said, but I'd add that I sometimes wish we had a way to sometimes pop up a GUI for very specific tasks.
For example, enabling a fast multi-select of rows in a longish table (or even worse, a tree) is one of the tasks that TUIs don't really excel at. Popping up a PDF or image viewer would also be great.
The TUI I'm working with runs on a pair of Linux VMs, and is accessed from Windows, Linux and Mac, so asking all our users to enable X forwarding doesn't really work.
Yeah, everything that couldn't be done through the TUI was a shitty web app, or worse, an iPad app. Fortunately those tasks were far less common and mostly dealt with the meta processes like searching national inventory, special corporate account data, things like that. All the day to day was in the TUI
There is no reason a TUI couldn't do this. Calling another program is easier in a TUI, since it is one step nearer to execve and a shell. If it is in a file, then opening another program isn't hard.
> The TUI I'm working with runs on a pair of Linux VMs, and is accessed from Windows, Linux and Mac, so asking all our users to enable X forwarding doesn't really work.
Run another Linux VM on the client. /s
Aren't there X servers for Windows? I remembered installing one on a locked down university computer for fun.
When Lowes made the shift off their in-house TUI point-of-sale to a GUI I heard a lot of fallout from the hardcore TUI users losing their keyboard menuing. Stores and people would build their own “cheat sheets” to fly around the system and it became almost a second language to get to know the TUI.
Knowing that 1.5.6 sends you to scheduling a pickup, or 11.1 to get into the credit card application, versus hunting through graphical hell with a mouse and a touchscreen.
This is about keyboard navigation rather than TUI vs GUI, there is no reason you have to render your app with plain text to support efficient keyboard nav.
It's also about consumer software versus business software.
Consumer software is all about conning people who don't currently own the software into thinking it's good and buying it. Once they have it, their experience doesn't matter at all. In fact, you should actively make the software less capable - really dumb it down, to appeal to the widest audience. Yes, more white space, yes, more menus. An error message that says 'oopsy something went wrong'? What a splendid idea! Information density does not matter. Speed does not matter. Accuracy of data does not matter. Hell, even bugs don't matter, if your software looks pretty.
Business software is different. It's crufty, it's ugly, and it doesn't change. Because you're optimizing for your users using the same software for 8 hours a day for the rest of their lives.
It's also from an era where you used one piece of software doing routine tasks that rarely changed.
Imagine learning all the keyboard shortcuts for every website you use nowadays.
For example I worked at a video store long ago that had some dos program to manage everything, I didn't own a computer and I didn't use any other software. It was still often a slow turd, and it wasn't networked with the 2 other local stores, so if I wanted to know if a customer had an account there, or if they had some stock there, I had to call.
Imagine if all the websites would render to semantic html and the browser would provide the interface. The problem is not the concept of websites.
That's true, but if the use case is to display text and to optimize keyboard navigation, then the added complexity of a GUI might be unnecessary.
Variable width fonts and style sheets are nice, though.
It also is about designing things around a single buffered input stream. There is no reason GUIs couldn't do this, but most don't.
Just the fact that you can use the keyboard is brilliant. I teach high school and most of my computing tasks are in lowest-bidder web GUI messes (lousy UX, no hotkeys) and take so much longer than a keyboard interface would. Even taking roll takes a minute or two longer than it used to.
I teach at a summer camp once that had custom web app for roll such that it displayed one name at a time to call out and to mark it as present you had to type their given name in a box, otherwise click next with empty input for absent
Somebody needs to be fired for that sort of UI...
I've probably made that sort of UI without realizing it...
False absence, is better than false presence. Especially with kids.
The UX is optimizing for accuracy over ease of use, and in this case is likely intentionally difficult to use.
If I was faced with that, I would switch to paper. Somebody can type it in later.
Also I have no mental imagery of summer camp with networking much less internet. I can't comprehend dropping my kids off at a retail storefront or a church as "summer camp".
Ouch.
I remember my high school went big on Gradebusters software--text entry on the Apple IIe (80 column required!) of course that was all keyboard driven.
Tab tab down space down space down down down space.. that was taking attendance.
One problem with GUI is that pointer-warping is unnerving, we don't have facilities like "I clicked, now warp the pointer to the next target" but that's commonplace with text UI.
There's no TAB button on a mouse.
So much of my work as a software engineer is done in shitty web UIs: trello, github, google gsuite, jira, gmail, calendar.
They are. So. Slow. Each and every one of them. Its awful
"We've really lost something very important with the shift to GUI and the shunning of text mode."
I use text-mode every day
Cannot speak for others but I lost nothing. On the contrary I gained faster hardware and faster network
This times 1000x. I dream of an alternate path we could have taken where TUI and keyboard input was the default and all the fancy GUI stuff was put to good use where it's needed. In retrospect it's ludicrous that we have to use a pixel-perfect pointing device to amble slowly over to whereever the designers put their menus/toolbars/icons, context menus. Select from a list? I have like 50 keys that could do the job!
Maybe because there are other usages than business data entry and programming? I don’t think I’d be more productive when say editing pictures/movies or producing music with a text interface. Maybe it’s because I grew up with classic Mac OS but computers were not only about productivity, they were a place, and UX peaked with Spatial Finder. Nowadays I spend my working days mostly in text mode and I feel like I’ve lost something.
Times have changed. Priorities have changed.
In the heyday of TUIs, job attrition was much lower. It made sense to create a tool that was extremely hard to use, but also extremely efficient once learned.
In the modern days, attrition is much higher, especially in retail. You need to focus on discoverability and simplifying training as much as possible. Efficiency is secondary at best.
> Times have changed. Priorities have changed.
I think what actually happened was technology changed. GUIs became possible, and therefore most designers made GUIs without much if any thought (because many assume newer == better). Now you'd be hard pressed to even build a TUI, since most know only how to build GUIs and all the tools are GUI focused.
> In the modern days, attrition is much higher, especially in retail. You need to focus on discoverability and simplifying training as much as possible. Efficiency is secondary at best.
That sounds like a post-hoc justification. Also higher attrition doesn't just happen like the weather. Deliberate decisions lead to it.
Attrition is higher overall for sure, but retail stores always had high turnover—temporary workers, seasonal workers, high school kids etc…
If you’ve seen any of the GUI retail tools that replaced the TUIs, they certainly aren’t designed for discoverability.