Ask HN: My family business runs on a 1993-era text-based-UI (TUI). Anybody else?
93 comments
·November 5, 2025abdullahkhalids
No, but I learned yesterday that a carpenter and renovation person I know uses a GUI software from 1996 called "FloorPlan Plus 3D 3.01" [1] to design furniture before he builds it. He has a dusty old laptop running Windows XP on which the only thing that works is this software and the connection to the printer.
He showed me his workflow in detail. It's a beautiful software that does everything he needs.
And notice it's only 3.8 MB - smaller than many SaaS software webpages that offer lesser functionality.
[1] https://vetusware.com/download/FloorPlan%20Plus%203D%203.01/...
estimator7292
Many (most?) older retail businesses still use TUIs. They're reliable, consistent, and orders of magnitude faster than GUI systems.
When I worked ar Sherwin Williams, I got good enough with the TUI that customers could rattle off their orders while I punch it into the computer in real time.
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.
The program had many menu options added and removed over the decades, but the crucial part is that the hotkeys and menu indexes never, ever changed. 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.
UX absolutely peaked with TUIs several decades ago. No graphical interface I've ever seen comes even close to the raw utility and speed of these finely tuned TUIs. There is a very, very good reason that the oldest and wealthiest retail businesses still use this ancient software. It works, and it's staggeringly effective, and any conceivable replacement will only be worse. There simply is no effective way to improve it.
Edit: 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. But the key is that it really doesn't take longer than your ordinary training period to become minimally effective. After that, you just pick up the muscle memory as you go. It's pretty analogous to learning touch typing without trying. Your hands just learn where the keys are and after enough time your brain translates words into keystrokes without active thought.
It's a beautiful way to design maximally effective software. We've really lost something very important with the shift to GUI and the shunning of text mode.
perlgeek
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.
estimator7292
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
urnicus
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.
perlgeek
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 :-)
trbleclef
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.
galaxy_gas
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
arichard123
I remember using a TUI for a Bank in the UK, and them switching to a web-based javascript system. Because the TUI forced keyboard interaction everyone was quick, and we could all fly through the screens finding what we wanted. One benefit was each screen was a fixed size and there was no scroll, so when you pressed the right incantation the answer you wanted appeared in the same portion of the screen every time. You didn't have to hunt for the right place to look. You pressed the keys, which were buffered, looked to the appropriate part of the screen and more often than not the information you required appeared as you looked.
Moving to a web based system meant we all had to use mice and spend our days moving them to the correct button on the page all the time. It added hours and hours to the processing.
Bring back the TUI!
bdavisx
A GUI can be as effective as a TUI if it's designed to be 100% usable from a keyboard - the problem is very few applications take the time to do that design.
conductr
Maybe in some cases. But largely, no, it really is not comparable. These TUI interfaces literally had 0 latency for any action. You could paste in text (from clipboard), with \t characters, and it would advance the input focus and could fill out an entire form with once paste action. There's a ton of real world cases where the browser is just too heavy to keep up with fast paced data entry.
I've never once seen an experienced user equal or gain efficiency when switching. It's always a loss even after months of acclimation.
andix
It's totally possible to get this done with a web based SPA. Just get rid of all the fancy design, images, gradients, animations, and so on, and just focus on usability.
The management needs to pick the right concept though, not the one with pretty and playful screenshots, but the one that focuses on the right KPIs (the 20 most common user flows need to take less than x seconds for an average user).
maccard
My experience has always been that TUIs and Terminal emulators these days have massive snags with how they handle control codes and inputs. Pasting into a terminal is a crapshoot of “what on earth is it going to spew back at me”.
It’s perfectly possible to handle large amounts of data by copy and paste on a web browser, you just have to actually support it.
bryanlarsen
The other thing that a TUI generally does that a GUI doesn't is that it lets you type ahead, you can drive it without looking at the screen.
Most GUI's make you wait for the form to appear before you can type into it. That totally destroys the flow of operators.
There are GUI's that are properly designed to be keyboard driven and to allow type-ahead. Those can be truly best-of-both-worlds. Too bad they're so rare.
fluoridation
Devil's advocate: There is one thing GUIs do better than TUIs: international text. Try to present on the same terminal screen text in Arabic and Japanese.
dardeaup
Yes, I'm quite sure that's true in most cases.
FWIW, dBASE IV version 1.5 does support Japanese for date format. It's one of the options for 'SET DATE' command.
conductr
I was making this argument in early 2000s, how the "upgrade" would kill efficiency - and it largely did for data entry. I did this swap in medical industry and finance industry and it landed on deaf ears all the time in the name of modernization. Actually, feels like I'm reliving it right now with AI.
andix
Sounds like the UX designers for the new applications didn't understand the requirements. I worked on two web app projects that required to be usable fast and with keyboards only. It's not that hard, if you define the requirements right.
Also no scrolling was a requirement. This was done by defining a min and max screen resolution, and designing everything exactly for that. The app was supposed to be used exclusively full screen, so no need for responsive design.
The result was a bit like a video game, very few loading delays and instant responses to user input.
HPsquared
TUIs have a high speed ceiling when muscle memory comes into play.
jamal-kumar
Yeah I actually help out a friend's family business a lot and we recently had to fix the program for something. It's a foxpro application rewritten in '89 from an original dBase port from earlier in the 80s. I legit had to bust out radare2 and hexdump(analysis)/hex fiend(editing) in order to get the changes done because the original programmer passed away (RIP). Was quite the learning experience but I'm glad that things were simple enough back then to make it something like an easy introduction into the world of reverse engineering for money.
I've seen even older in use. There's an auto parts store in the capital city of Costa Rica which was still running dBase III for its inventory system on a green phosphor screen IBM PC. Not sure if that store is around post-pandemic but it certainly was running around 4 or 5 years ago. Wish I got a video but it's in a particularly sketchy area that I don't really have any reason to return to.
Also, if anyone else ever has to dump an old database to CSV or whatever, I found perl to be the best tool for the job as it handles old encodings just fine. You can go from ancient database to spreadsheet really easy this way. Here's the ticket:
CodeWriter23
Costco. Go to a supervisor in a red vest and ask what other Costco has the item that has stocked out and you'll see. No idea what the backend is but the app they use is a terminal emulator that looks straight out of the late 80's.
jamal-kumar
Here's a photo for anyone curious:
https://mastodon.social/@nixCraft/111839478303640635
It's also worth noting that the original mainframe hardware has likely been virtualized at this point. Used to work for a company that was doing a lot of that around 15 years ago
hyperpl
Looks like an AS/400
Aloha
AS400 in their case
kitrose
AS400 I think
perlgeek
Yes, we still have a TUI to our core CMDB and billing. With 500+ employees, not everybody is happy with it, so we also built an API and a web app to access and manipulate the most central data.
But, we also have some power users who absolutely swear by it, and we offer some power user features for them :-)
* full readline integration, so there's a command history, Ctrl-R reverse search in the command history etc.
* tab completion for many prompts
* a generic system where outputs can be redirected to a pager, a physical printer, "wc" (word count), into a file etc.
* tabular data also has an alternative CSV representation
* generic fast-jump into menus. This works by supplying commands on the command line, and transitioning to interactive mode when the command list has run out
This is all built in-house; the first git commit is from 1997 but that was "import from CVS" and already 20k LoC, so the actual origins go back further.
It's written in Perl with no framework, just libraries.
EvanAnderson
My parents' small businesses still run an xBase-based TUI accounting application for GL, AP, AR, and payroll they first purchased in 1988. Other than a Y2K update it has run unchanged since it was originally installed. Today I have to use DOSBox to make it run but it still works great. I've scabbed-on a few quality-of-life updates (mainly by capturing and processing print jobs) but it mostly just does its thing.
As you'd expect with having a TUI the users can absolutely fly through it. It's extremely efficient for them.
mrngm
Most, if not all, Asian take-out / restaurants in NL still use a TUI for registering your order. Several motorcyle retailers in NL use a TUI for parts management, invoicing, repair tracking. In both cases, people operating these systems develop muscle memory for their everyday usage. I'm not sure if it's still in use, but for at least a decade since 2005 or so, the local university's student canteen used an in-house developed TUI for selling snacks and drinks.
And if you stretch the definition of TUI a bit, the Bloomberg terminal is a fascinating example.
privong
An interesting theme here in the comments (that I am sympathetic to) is "TUIs have steep learning curves but are fast/efficient for people with proficiency". I wonder if a small part of the modern preference for GUIs is related to a lack of employee retention. If companies aren't necessarily interested in working hard to keep employees then training new hires needs to be faster/easier and that could work against TUI and keyboard-based tools.
Of course, if that's a factor I'm guessing it's a small one in comparison to expectations about what "modern" software should look like.
avidiax
It's also quite common that the customer is now the one that drives the interface.
It's the customer's time wasted by the UI, but also the customer typically can't be expected to perform enough orders to actually learn a complicated interface.
TUIs persist in industries where there is specialized knowledge needed to even complete the order. For example, an optometrist's office.
privong
I was thinking about employee-facing tools, but I agree that TUIs present an even bigger challenge for casual users / customers.
urnicus
This is a definite reality and headache. The learning curve was steep and I literally had somebody walk out after training them for less than two hours.
tonyarkles
I don't know if they're still using it but around 2010 or so a client from the early 2000s got in touch because the UPS they were using for their SCO Unix + serial terminals server had failed and they wanted to replace it. I was amazed that they were still using it. I was even more amazed that the APC UPS they were going to replace the old one with... had a new version of the SCO UPS Monitoring application that they used to automatically do a clean shut down of the server if the power was out too long. Got them all set up and everything kept humming along.
james_marks
If it’s survived this long, it likely because it has years of small fixes to make it reliable and useful, and more than anything—- predictable for the user.
Modernizing will roll some of that back; I would only consider it if there’s a plan to be around for the years it will take to get good again.
mitchell_h
Lowes and home depot come to mind. Their POS/terminals are just a terminal into an TUI. John Deere, kabota and other ag equipment service & parts providers still largely use a TUI.
vablings
Also, Costco uses AS/400. Applications that are pure function over form are amazing
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.