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.
> 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.
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.
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.
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.
> 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.
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.
- you can put the web server in the same building
- Each page is very heavy with lots of JavaScript etc. loading
- you can build lightweight web pages if you priority small script size, minimal dependencies,
and do profiling to keep things in check
- Data loading delays rendering
- limit the amount of data loaded and displayed at one time
- Data is slow to load
- an older system has limited capacity meaning it's not an option to keep inactive data around
- this means data is more likely to be indexed
- new systems have very large storage capacities, leading to a larger and larger growing db
- eventually default configuration for the database does not allow for everything active to be indexed
- solution is to keep inactive data out of active tables being queried for normal operations
- Slow to navigate with mouse
- you can create a keyboard navigation system
- you can build keyboard shortcuts into every screen
- you can create autocomplete shortcut commands to jump to screens
Many 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.
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 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.
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.
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 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.
> 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…
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.
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.
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.
> 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.
> 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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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
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".
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.
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.
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.
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.
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).
I was just giving some examples, it being theoretically possible in SPA isn't really helpful given that nobody will implement it that way. You're basically living in theory.
I've literally done the before and after on this a handful of times and it's always worse off. Management will never do that, it's always design by committee, the KPIs won't be defined or will never really have teeth, it will turn into someone's vanity project, they won't even pay someone to optimize the code - quite the opposite, they'll choose to build it on something like Salesforce or some other very non-performant enterprise-y platform, etc, etc. All the TUI get these performance gains out of the box without much additional effort. The constraints of the UI are it's strength as it prevents people from adding all this bloat in the first place. When you leave it up to people, especially business users or UX folks, it will get spoiled. It's almost a law.
Possible yes but there are properties of a TUI vs a GUI where the TUI encourages faster keyboard navigation because when they were common there was only keyboard navigation whereas a GUI comes with it's own upsides (discoverability been the big one).
When I was in college (many years ago) the company I worked for used a TUI for its inventory/back office systems (terminal emulator talking to an AS/400) and once you understood the hierarchical structure and how it worked you could fly through that system because it was all keyboard nav.
Few GUI's have ever been that fast for me even the ones that go out of their way to make everything accessible via the GUI bindable.
The real issue is, that modern UX design is often too focused on pretty looks, instead of productivity. It's still possible to make a highly productive UI look pretty, but the priority is often completely wrong.
They shouldn't start from a few pretty figma sketches and then try to make them more usable. They should start from user flows, solve how the users can do certain things with maximum productivity, easy navigation, showing the right data together on the same screen, and so on. Only in the end make it pretty.
Sure, in a browser you can't use all the shortcuts, but still a lot. If you really need it, just wrap it in Electron, Tauri, or any other customizable browser.
Lol, no. You can still use different font sizes, traditional controls that can also be used with a mouse (for people who don't know the shortcuts yet). Also images are possible where they make sense.
While using very common web development stacks a lot of developers know how to deal with.
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.
That is not unique to TUIs, but also possible in GUIs where the developers care, and in some games (try the GUI ("tiles") version of Brogue). You can definitely make a GUI that updates in an instant and be fully keyboard-driven, even if that may have been more common last century.
We’re comparing TUI with web browsers for good reason. I don’t see any reason to add game engines to that debate. I have never seen a business client move any application from a TUI to a Unity based UI. I’ve never even heard of anyone considering a game engine in the architecture of a business application. So what you’re saying may well be true but it’s akin to a rare mythical creature, does it even exist?
That was not what I tried to say. Brogue, like other similar games, can be played in a TUI mode, in the terminal, or with a GUI. Same game, just different UI implementations, and both tend to be about equally laggy, or usually the GUI version is probably less laggy, since you can just blit glyphs without the overhead of terminal escape codes etc to draw the same symbols in the TUI. And Brogue just uses SDL, not a game engine, so that is not relevant at all.
But your snarky reply is probably also wrong anyway, since I would be surprised if there is no business software made using game engines. Tesla is known to have used (but not anymore?) Godot for making GUIs for their in-car displays for instance. I have bought applications (not games) made using both Godot and Unity. Not saying it would be a great idea, in general, to use those engines for business applications, but people are not known for always using the best possible tools, are they, and it certainly would work in theory?
Not very familiar with Unity, but Godot has very nice GUI widgets. Same style of WYSIWYG editor like old Visual Basic or Delphi really. You drag widgets to place them on the screen, set properties, add scripts to react to different events. The entire Godot IDE itself, a very non-trivial application, is implemented using Godot's own GUI framework.
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.
No, that's only the Steve Jobs view. You might be grappling with Discoverability.
When IT was trying to sell everyone on WIMP GUI, the standard was WordPerfect. There, you had to memorize the functions of the F1-F12 keys, as well as their shifted (or Control) behavior. The only sure thing was that F1 was HELP.
We were looking for something better--but having no keyboard was the opposite extreme.
Not specifically for those but I have to assume the pattern would work: you could intercept the keystrokes in a parent window or an overlay, then forward them to the correct child window once it's rendered.
Acquiring the skill to fly through such interfaces is equivalent to learning to play a musical instrument, where the desired attention (taking cues) and action (body/finger movement) becomes second nature. Such skill and interfaces are, unfortunately, not viewed as similarly valued as playing a musical instrument, and such visual presentation of the TUI is thought to be "difficult" to use, and they do take learning and effort to achieve that level of mastery. Meanwhile, the interface to traditional musical instruments, while there's been some changes and improvements, have stood the test of time and remain attractive to a lot people who want to make music. Many of the claimed "improvements" that GUI interfaces have over TUIs look in some cases, to me, like busy box toys created for toddlers (this is how I feel about the Windows Ribbon menu widgets). Once something becomes second nature, it's not "I'm putting my fingers in this position" it is "I want to play an A after this series of other notes".
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.
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.
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.
Actual terminal-based TUIs sure, they have small character sets burned into ROM, sized for 50-years-ago prices.
Modern terminals, even the text-based console on a fresh minimal Arch linux install, is going to support Unicode probably without a ton of issues as long as you have a font installed that has the characters. The struggle then for RTL or non-Latin character sets and languages is making the UI fit the words in a way that makes sense.
Yes, you can spend an inordinate amount of time figuring out how to lay out multilingual text on a terminal, or just use Cairo or some toolkit and let solved problems stay solved.
Just use gettext? The strings might vary in sizes, but when you are comfortable with the text resolution of the GUI, just set your Terminal to the same resolution and that problem is the same.
But the past didn't use ASCII as such, but extended character sets, or multiple characters sets, which did allow for Russian, German, etc. text interfaces.
And yet, as I read manuals from the 1970s-80s, I see a lot of money was made by minicomputer vendors whose operating systems were sold with multi-lingual character sets. Even Japanese.
I experienced the same thing. The big Brokerage firm I worked for in the 90s had amazing TUIs. You could fly through the screens. They even had DMs and group chats. Pretty amazing. The next company I worked for was rolling-out a GUI replacement for their TUI interface and I watched people's productivity plummet as they went from keyboard, to mouse for every text box... Those old mainframe TUIs were amazing, probably the result of decades of time and motion studies.
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.
I've also helped running an old Windows 3.1 accounting software. It runs perfectly fine on Windows XP inside a VM.
In 2020 it suddenly came to a halt, because the date pickers just couldn't go further than 2019. Nobody seemed to care in 1992 when it was released.
It was really easy to de-compile the Visual Basic 3 software (perfectly legal where I live). My first idea was to get the source cleaned up a bit and compile it again to 32 bit with Visual Basic 4, but I couldn't figure it out, it required some 3rd party libraries that I just couldn't get a hold of.
In the end I just changed the number 2019 in the binary to 2059 in a hex editor, and it just worked. There was only one occurrence of the number 2019 in the whole binary. I guess I got really lucky.
Edit: It seems like Windows and Visual Basic are not affected by the Unix 2038 problem at all. 16 bit Windows seems to be fine until the year 2107.
> My first idea was to get the source cleaned up a bit and compile it again to 32 bit with Visual Basic 4, but I couldn't figure it out, it required some 3rd party libraries that I just couldn't get a hold of.
This was super common for VB apps. The original architecture of VB was, loosely speaking, a GUI container for various pluggable controls connected to a BASIC runtime. The number of controls that came in the box would vary depending on how fancy a version of VB you bought, and you could plug in additional third party controls in the form of "VBX's" - Visual Basic eXtensions. Even though VBX's were designed mainly for GUI controls, they were the easiest extension point for VB and got extensively used for all sorts of integrations until OLE Automation became more prevalent. (Roughly contemporaneous with the switch to 32-bit.)
I wonder if there is a reddit thread with people showing off their surviving Windows XP setups. Mine is a dell tower laying on its side because I harvested a power supply unit from another dell, but it doesn't fit in the case.
I remember using those pre-cloud versions. I loved them. Sketchup was so intuitive (as a 3D modelling noob) it was ridiculous. My tool of choice for making 3D levels for my various OpenGL projects.
I tried to do some rudimentary modelling with modern day Blender and failed. It‘s quite the juggernaut to learn.
What software today do people recommend as an alternative to Sketchup? Is the cloud version any good?
> What software today do people recommend as an alternative to Sketchup?
onshape (web; free to use unless you want to protect your designs) and fusion (autodesk; free license available) are both really popular right now. they work differently than sketchup. i never really made friends with sketchup but the parametric modeling system used in fusion and onshape clicked with me and i really enjoy using them.
I remember running Sketchup for the first time. I had zero experience but in less than 20 minutes I was drawing large complicated machinery, tractors, buildings.
They made a 3d drawing application without a learning curve O_O
IIRC that version made it really easy to design things with dimensional lumber. 2x4”s, 2x6”s etc. I have vague recollections of designing a dog house that way from that time period.
I’m not sure how I’d do the same thing now. If I tried to do that now with Fusion, I’d probably have to build out my own primitive set of lumber sizes, right?
IIRC SketchUp 8 (released in 2010) was the last version released by Google, which had licensing allowing commercial use of the free version. After the sale to Trimble, later versions of SketchUp 8 and all future free versions become for non-commercial use only. SketchUp Make 2017 was the last free version that could run locally.
Loved using Google Sketchup back in the day! My high school engineering teacher would show off his 3D modeling of cars during class. It was so cool seeing what you could do with that software!
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:
Man, this would have came in handy when I was trying to extract data from .dbf files. Ended up writing something in Go while referencing the dBase IV spec. Lots of trial and error as I recall.
There's a few tools out there, another one I tried in Common Lisp but it was a horrible pain in the ass to get working. Figured to search for perl scripts because it's pretty much fine with old as hell encodings (latin-1) as it was originally developed contemporary to those, and that came up. There's also this, but it was written for dBase III and idk how well it works with fox pro
Hahaha this woulda saved me some time. We considered porting the app to be a web app but after some time it was obvious that wouldn't have been as good
This whole thread reminds me of when I saw my first Windows-based ticket dispensing machine at a movie theater. Early in the year there was a screening of the Star Wars trilogy at the Cinema at the North Park Mall in Dallas. Every geek for miles beat a path to the theater. When I got there the line was moving along reasonably quickly and was maybe 20 people deep. No problem. You get to the front of the line, hand over a $10 for two $5 tickets and the cashier pressed the "dispense ticket" button twice. Two tickets came out immediately and you were on your way.
Later that same year Jurassic Park premiered at the same location. Again, every geek for miles around beat a path to the theater. But this time when I arrived, the line was hundreds of people deep and it took about 45 minutes to get to the head of the line (good thing we got there early.) When I got up to the cashier I found they had a new Windows-3.1 based ticket dispensing system. You said how many tickets you wanted and the cashier moved the mouse over a text field, took their hands off the mouse to type "1" or "2" or whatever. If you bought a child's ticket or a senior ticket, that went in a different form field. Then the cashier put their hands back on the mouse, scrolled down and hit the "calculate" button. It told them how much cash to take. They took their hands off the keyboard to collect the cash and then pressed the "dispense tickets" button. Thankfully, the system seemed to actually dispense tickets without crashing. (Windows 3.x had a very bad reliability reputation.)
What had taken 10-15 seconds with the "old school" interface now took about a minute.
Never let anyone tell you "the new system" is better just because it is new.
[[ Also, about this time I remembered Jef Raskin going on about keyboard interfaces, but this was long before the publication of The Humane Interface. And I know we're using the initialism "TUI" in this thread to mean "Text UI", but some people use it to mean "Tactile UI." No one ever got fired for recommending a React Single Page App optimized to quickly swap pages on the current model iPhone. Whether or not that's the best interface for the application is irrelevant. ]]
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.
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.
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.
What I heard from one large chain is they couldn't train warehouse employees on the green screen (3270) inventory app, its too different for them. They just wouldn't do it or would quit.
The other thing is that GUIs can be very slow to load, limiting the potential speed/efficiency. One of the most frustrating experiences is pressing a series of key commands (or just single keys) that SHOULD have performed a very specific series of actions, but the software lagged behind at some point(s) in the flow and something ended up getting messed up because my series of key presses resulted in a totally unintended action.
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.
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.
> if you stretch the definition of TUI a bit, the Bloomberg terminal is a fascinating example
The Bloomberg Terminal uses several different UI methodologies depending on use case -- many functions (applications) are absolutely TUIs whereas Launchpad is more mouse-driven.
> In both cases, people operating these systems develop muscle memory for their everyday usage.
I worked as a UX designer at Bloomberg and when we had to modify existing functions we were careful to maintain shortcuts and keyboard navigation. In a couple cases we even ended up re-implementing UI bugs that one or more users had grown accustomed to. I've never worked anywhere quite so committed to backward UI compatibility, but that came at the expense of a steep learning curve.
I had to reverse engineer the 1980s style ASW screen and replicate it, bugs and all. It had on-screen side effects where hitting TAB would cause numbers to recalculate according to a buggy LIBOR interpolation rule that persisted until ASW got replaced around 2010. Yet traders would take ASW as gospel.
I spent many evenings hand-marking dozens of Bloomberg screen prints to satisfy Accounting that my calculations were right and our Bloomberg operators were getting fooled.
I never worked on ASW or its replacements, but assuming they fixed the calculations in one of the newer swap curve functions I also wouldn't be surprised if some poor developer had to add a "compatibility mode" with the old calculation to avoid breaking someone's longitudinal analysis or satisfy some important user who prefers a stable calculation to a correct one.
I worked with a steel warehouse about 10 years ago who were using software written in a Data General Business BASIC offshoot dialect, which ran on a proprietary Windows runtime that was essentially emulating the original minicomputer which ran the software when it was originally written in the late 1970s. Thankfully, the emulator at least ran on Windows so we were able to move it to a hosted environment with backups and away from a random tower in a metal warehouse, which is no place for a computer.
We were also tasked with adding new process automation and tooling. Instead of rewriting the system, we reverse engineered the database format and wrote additional tools and utilities around the core tooling, using more modern frameworks. I think this was the right choice and everyone was happy: they didn't have to relearn years of muscle-memory and business process built around the BASIC system, but we could iterate in a modern programming environment.
It wouldn't be surprising if the system was still in use, there was nothing wrong with it and it worked great.
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.
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
> that the original mainframe hardware has likely been virtualized at this point
The as400 is a mini-computer, the high end of this line overlaps the low end of mainframe.
When I did some consulting work out there many years ago, they had a network of the largest as400's that IBM makes, connected together in one image.
Regarding virtualization: It would have to be on IBM's power processors. IBM does offer cloud services running as400, I have no info on whether Costco is using that or not.
It's a network of high end as400's, the software is custom.
They've burned multiple 100's of millions of dollars on multiple projects trying to re-develop and move off as400's, but they just pulled the plug on their most recent project a year or two ago.
The biggest issue with adoption on new system (based on insiders I've talked to) is that the existing system is very efficient for people knowledgeable about how to use it and the newer GUI based systems just don't match it.
My grandfather purchased a niche customer management DOS application in 1986 or so and used that Software up until the day he died in 2012.
When he was finally forced to upgrade to a computer without a parallel port, he was a bit stuck for a bit because the software would only print to a printer connected via parallel port. I couldn’t find a card for this at the time, for whatever reason, but I eventually was able to trick the software into printing to a modern printer and I had never seen him more happy since it saved him the $3000 software upgrade fee.
I worked as a sales consultant for AT&T wireless, back during the smartphone boom, at their retail stores. During onboarding everyone was taught how to use the GUI for everything (OPUS, I believe it was called): creating accounts, upgrading accounts, etc. But I noticed a few of the senior reps lived in the TUI (Telegence) and wondered why. When asked they claimed they were just used to it, but I quickly learned how much faster it was by observing them. They were able to process customers so much more quickly, a comparative advantage in commissioned-based sales.
My buddy and I requested access and learned how to use it. Not only did it streamline our process, it allowed us to do everything, where the GUI often omitted certain tasks forcing us reps to call customer service (for example, providing customers with credits after fixing their accounts).
So we lived with both the GUI up for when management walked by and relied on the TUI when we needed/wanted to work quickly.
I bet the system hasn't changed a bit. But I still live in the terminal quite a bit these days.
My 2 cents is that GUI is good for exploring new software, while TUI is wonderful if you already have a mental map of what you're doing. So for everyday used software I would definitely hope that more TUI's where used.
Are you taking on new customers? I know a few folks hungry for old fashioned, on premises accounting and task tracking now that Intuit is pushing everyone to cloud subscriptions.
Ideally it would be a perpetual license so we can never have the rug pulled on business critical data, but I like the "x years of updates and support" model
You can contact me at my username + gmail if you wouldn't mind discussing further
What a coincidence, I've just read this paper while I prepare my proposal for a PhD. I feel that the difficulties reported by the novice users were related to the peculiarities of the mainframe interfaces + the 3270 emulator. Not exactly to the fact that they were using a TUI.
Costco runs on TUI. They force you into minimal design and uncomplicated workflows. I bet someone is going to say you need servicenow to manage all this in an easier way. Please don’t listen to that person
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.
I'm not positive whether Target's system from ~15 years ago was a TUI, but a friend worked there in college. He mentioned the process for tax exempt purchases was a bit challenging/not the most common. There were some frequent shoppers who had heard the assistance from the manager enough times, they could walk an employee through what buttons to press to get it setup correctly.
Was not a TUI, but was totally controllable from the keyboard. There was no mouse or touch screen, you could get pretty fast at it. You are also correct about the tax exempt thing, the customers who used it often knew what to ask for. The new registers now have a completely different UI with a touch screen. Seems like a step backwards.
My first programming "job" was a sort of summer internship when I was 14 for a family owned company called Signature Systems (signature.net). They are still in business. Their product is an operating system called Comet, that if I'm not mistaken was originally a compatibility play bringing software from the previous era of 16 bit microcomputers onto DOS PCs, and then later into Windows. I may be misremembering some of the details but I think at one point a Comet system ran ticket sales at Madison Square Gardens. My summer project was to build a demo using their new support for Windows GUI elements. The last time I spoke with the owners, they told me that they still had customers, including in the textiles industry where loom patterns had been coded in Basic. I often think about it as an example of a legacy system, and smile at the idea of someone thinking they need to rewrite their plaid weave in TypeScript or Rust.
Separately, I have spent the last three years building a web app that replaced a heap of automation scripts for a ~50 person business. These were much more modern than what the OP describes but it had some of the same qualities. The scripts mostly generated google sheets and emails. The replacement is a python web app using SQLite. Moving the company data into a proper database has been a very significant step for them. In some ways, the project feels a lot like custom business software that got built in the 90s.
Fry's Electronics used to have a powerful TUI for getting parts from the cage, the employees could hammer everything in and hit print and turn around to do something else while the screens were still loading.
Later they had some GUI that was used to open ... a terminal of some sort for the same TUI. The GUI made it slower, somehow.
Only a few ago I had been installing new VoIP phones for a small business on the East Coast that had 2 or 3 green screen terminals and an IBM server running some variant of Unix. Most people in the office had terminal emulators, but one fellow in the warehouse section showed off his boxed terminals they had on hand incase one died. It is interesting to me to hear from someone that experienced these anachronistic machines and software. Very unique building, there was a floor between floors you could only get to via the warehouse. It made for an unnaturally long stairwell.
Textbook example of a piece of software being a shark (perfectly adapted over millennia to being a perfect predator) not a dinosaur (obsolete/extinct).
I work on a bunch of Pick systems :) Love it all and we're still doing active development. (Feel free to send me an e-mail, we pick up orphaned systems)
If anyone wants to take a look, here are some links:
There's a completely unironic obituary linked from the LA Times from 1994, which makes me wonder if the scandalous meaning even existed yet in those days?
My dad recently retired but his company was still using Pick as of a year or two ago. They also had a one-dude maintenance plan. I wonder if it was the same dude.
My first job out of college was over 2 decades ago, and I was hired to work on a web app which was considered new technology. But an important application there that was used by hundreds of people around the country was written with Pick, and the owner of the company also had some local Houston businesses whose Pick applications he occasionally did maintenance work on. The owner had moved from Chicago to Houston at the beginning of the 80s because he was able to get a high-paying job with no degree, but when the oil bust happened he learned Pick programming from an older guy and did so well when he started his own business that he retired early.
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.
I don't think you're blinded by nostalgia. In the early 2000's, I worked in an organization that was migrating away from TUI to web apps. I was one of the web guys back then. We got modern, more maintainable code at the expense of usability. Those TUI interfaces are way faster.
The web failed to live up to the early promises in a lot of ways. We have complicated frameworks, complex architectures, browser headaches, etc. and what we got out of it are user interfaces that are slower than what we replaced and entire categories of bugs that didn't exist before. There's so much extra bullshit in place to overcome the fact that we are using a stateless protocol designed to deliver text documents.
The only things I would really be concerned about with your family company's app are maintainability, availability of security updates, and the use of obsolete software like XP. It sounds like you're already modernizing the code. That old OS is a disaster waiting to happen though.
I like the idea of an internal enterprise app running in the terminal on a reliable FreeBSD or Linux machine. The people who have to live in that app will be faster with a keyboard-driven workflow. A web front end is for customers and situations where you prioritize looks and accessibility over speed and usability. If you implement the the business rules in a modern middle tier and have a good database backing it, you can have the best of both - TUI for internal users and slap on a web front end for external users.
I wrote the main application for my wife's business — she's a psychologist. That was only a few years ago, but as a senior lecturer in the more theoretical parts of computer science, I never really needed fancy UIs with flashy graphical effects. So I built a core engine and used the classic dialog tool as the thin user-facing layer.
At first, my wife was pretty disappointed — as a computer science teacher, wasn't I supposed to know how to build a “real” app? But a few years later, she doesn't want anything else. I even offered to have one of my students create a nicer UI without changing the engine or database, but by now she's completely used to the terminal menus.
The tool keeps a database, collects data through dialog forms, generates PDF invoices with groff, and launches Thunderbird when needed (to send invoices, etc.).
I work in a medical center, which is my family business. in here, I am the IT guy, as well as receptionist and one of the secretaries.
we currently use a 2019 HP Pavilion 15 laptop with an AMD Ryzen 7 3700U, 12GB of DDR4 RAM, and a 512GB SSD. as you may have noticed, this computer is insanely overpowered for just using Excel and WhatsApp. that's why I've been given the task to downgrade to a different piece of hardware, a 2011 laptop with an Intel Pentium P6200, 2GB of DDR3 RAM, and a 300GB HDD.
and I am the guy responsible of building the old-new TUI app we will use in that machine. I am conscious of how much of a downgrade this is, but it's to avoid throwing away hardware that still works.
I have made a few prototypes using lightweight web technologies, but I ended up not liking how they look, perform or interact, so I start over. this time I will attempt to build something especially tailored to this old laptop, using TUI tools like ncurses.
Both of the lumberyards in my city are still running on DOS (or DOS emulation) for their systems, along with quotes printed on dot matrix printers (and no online price sheet). They’re so low margin and old school, I don’t think they get tech upgrades more often than once every two human generations except for new capital equipment, which sucks most of their surplus.
I supported a lumberyard that was like this too. Also, some "modern" laser machines required ancient versions of Windows and required floppy discs. This was about 20 years ago, though.
TUI were great for many business applications, specially those in warehouses or factories. They were easier to write and modify. Many business applications were migrated to web for little gain. IMHO.
Have you ever been to a Marriott? They have something called MARSHA depending on the property. Once you log in it's basically a command line interface filled with abbreviations. As a high schooler in 2016 I used to train people at a reservations call center on how to use Marsha. It's super unintuitive but surprisingly everyone can wrap their heads around it eventually. Ok maybe 9 out of 10. You could decline to learn Marsha and work for properties that use a GUI like Opera PMS (for us it was mainly IHG properties). You got a pay raise if you learned Marsha. Opera was great, they later started upgrading to some bloated crap with lots of padding between buttons.
IIRC Marsha has transactions so you can build up a reservation and make queries in the process. There's even test properties in production so you can practice making/reserving/retrieving reservations.
Super late to the party, but Dale Harris Cash Register is a free Point of Sales TUI program that has been maintained by Dale since the 90s[1]. The website is pretty great too. He originally made it for his locksmith/key business. He has a gallery of people using it in the wild [2]. I've always wanted to have some sort of business where it makes sense to use it!
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.
People who are good programmers say this, they have this fantasy, but it's a myth. The opposite is of course true, because there is no maintenance, there are a bajillion agonizing bugs and people simply work around them, the "small fixes" live inside the heads of the people using the application.
Like the fantasy is that the bank uses TUIs and the bank has accumulated years of knowledge and the bank doesn't make mistakes. The bank has extremely well paid staff. Joe Shmoe's TUI app looks like the bank's app, but it is unmaintained, it has accumulated years of problems, not fixes, nobody is fixing them, people who say they fix them cannot possibly be keeping up with the sheer amount of toil and bugs needed for production software. You can see this in any GitHub project, how much insane maintenance is required, for stuff people actually use and has few bugs.
A lot of “traditional” industries still run on TUIs/even as400 systems, such as freight/trucking companies, banking, medical, travel (saber, etc). And many companies in those spaces who appear to have migrated away from those systems are likely just using a modern gui interface that still uses those old systems behind the scenes.
It’s generally because 1) they’re actually reliable 2) they contain custom business logic and rules that are not documented well/at all and hard to replicate 3) the people who set up all of these things have retired and no one is left who understands any of it
Until recently I helped running an old Clipper/dBase TUI application from the late 80s for a family member. We managed to run it successfully until they retired.
vDos (vdos.info) was a huge life saver for this application. It's similar to DOSBox, but more tailored to business applications. The big issue was always to find compatible printers for the old application, vDOS includes some emulation to print to any Windows printer.
There might be free alternatives to vDos, but it worked very well and is reasonably priced.
PS: we also tried to recompile the Clipper source code with Harbour to modern targets. It looked very promising, but they were extremely happy with the vDos solution, which only took 2 hours to deploy.
I've been there, this doesn't work well at all. Actually since Windows NT the DOS subsystem is already an emulation, and it's not that good. DOS applications worked really well up to Windows ME, but with NT/XP/7 it got worse.
vDos was overall much better than running DOS applications directly on Windows. Only drawback was performance. It never ran as fast as on a Pentium III with Windows 98, but still much faster than the original hardware it was designed for (~30 mhz 80386).
Our application was designed for Novell NetWare, back then it even supported row/table locks for dBase files on the shared network drive. This didn't work with Windows NT anymore. But vDos brought back the feature to Windows 10 and SMB shares!
It was a customer management and billing system, for a specific industry. Tailored to local requirements and insurance regulations (a lot of things got billed to insurance). There is commercial software available for this purpose, but it's a very small target group, and the products are neither great, nor cheap.
Over time it even got extended to interface with a few external systems, mostly by reading and writing text files to specific locations.
It was deployed on one location with 2-5 concurrent users on the same database. The workflow was something like this: open customer/new customer, read/add notes, register products/services provided, print invoice for customer, print monthly invoice for insurance companies including all the required information (hundreds of pages).
I have also met some people who worked at large old insurance companies. They originally used old mainframes and TUI, and the companies still exist. They told me of various things that were done. Of course migrations happened. And interfaces were built so that modern systems could speak with the old, sometimes via terminal emulator. And of course, some old systems still in use far beyond their time.
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.
I'm starting to maintain a COBOL codebase for my dad's small business. It uses MicroFocus's runtime so it runs fine on Windows 10/11 (but I'm trying to migrate it to OpenCOBOL). He helped write a good chunk of it, but doesn't make any major changes to it anymore. I'm not confident enough to make major changes to it, but I fix some bugs here and there. I ended up writing a python script to parse the database layout for a python-based fuzzy search tool, but I still stuck to a terminal UI for it.
This prompted me to check if MicroFocus was still in business. It's a little complicated. Also, the Wikipedia article mentions Ryan-McFarlan - a COBOL and FORTRAN compiler company. I miss the 80s...
> This got me thinking: Are other companies still using this type of interface to drive their core operations?
Probably a big chunk of businesses that developed their core systems before the PC era. I don't know if they still use it, but Avis Rent-a-car's main application used by its front-line people was a TUI like that, and the front desk people could fly around int it (like you said).
But most developers ape current trends rather than actually figuring out what would work best, so I'd guess very few user-facing TUIs are being built now.
Been experimenting with charmbracelet's[2] stuff recently to do something similar. Still very early stages so nothing to show off yet but would highly recommend it for anyone else looking into creating a TUI app/business.
I’m bringing charmbracelet to the web using gotty. The example is chat app that uses tailscale as the auth layer, and is exposed over ssh via charmbracelet/wish and over http via gotty. I haven’t written any docs yet; you should be able to run the example chat app on your tail net.
Would like to add some other forms of auth, but tailscale was just so easy to provide the same auth for both ssh & http.
> I got my start as a script kiddie writing automations for this system with Microsoft Access, VBA, and SendKeys to automate data entry
I've done exactly this for the likes of JP Morgan Chase. Many of their core banking systems are some COBOL/Fortran mainframe (that I know nothing about) but the interface through a TUI client. When they have a desire to work in a more modern fashion, it's SendKeys to the rescue. There's definitely still a lot of TUI's that run the world.
Quite a few large businesses are still running code that was originally written for mainframes in the 60s and 70s. Usually it is large batch operations, but I know of at least two fortune 100 companies that still have non-technical users running terminal emulators to connect to their 'mainframe' to perform some tasks.
I was about to say that's what keeps Sungard in business, but then I googled and saw they are no longer in business. So maybe it is starting to die down.
I visited a food service company a couple years ago. They had phone reps taking orders from customers (restaurants ordering produce and such). They used a TUI (a "green screen" essentially).
I have never seen people move through a GUI that fast. They were lightning quick with it. They were like an veteran accountant with a ten-key adding machine. It was amazing, and pretty damn sobering when you think how much work we spend on GUIs.
Been through this cycle a few times. What helped wasn’t stepping away from AI — it was building something that runs itself. Once you stop babysitting models and start automating the orchestration, the stress drops fast. My current project basically learns and adapts without me watching it, and that’s been the difference between burnout and flow.
I recall guitar center is still on a green screen back when I worked there in my youth. It was pretty fun learning that interface, fancy keyboard shortcuts etc.
I remember going to the Pasadena Public Library as a kid (90s) and there were terminals everywhere for interfacing with the digital card catalog system. Pretty sure they were made by Digital/DEC. The black screens with orange glowing text were such a pleasure to play around with. I've been thinking it would be fun to have one of these in my house 24x7 to interface with a Home Assistant TUI.
I struggle to remember myself... but I found this earlier today:
"The years of 1995 and 1996 brought many technological improvements to the Library including the addition of InfoTrac SearchBank, a computerized magazine and newspaper index; ADVANCE, a new Unix-based online library catalog; public access to the Internet with terminals at all library locations;"
Not using TUIs (unfortunately). Work in a large business on services for real estate transactions. Heavy GUI applications. I’ve actually been investigating adding heavily keyboard-driven interfaces to our GUI apps with my teams because the multi-screen clicking around all our users have to do now is so incredibly slow and inefficient.
Some of my most productive use of software (in both personal and professional settings) have been with TUIs.
Even with all the hype around AI right now (and we’re working with that, too), we can’t not have more traditional UIs to keep a human in the loop when it matters the most and as a fallback for when AI misses the mark - but that doesn’t have to mean it’s all click heavy.
It's been a while since I worked at a bank, but most there core stuff was running in a mainframe and while "modern" front ends exist, the core work uses terminal access.
A key thing modern replacements lose is the input buffer: One can type multiple screens ahead. In a modern GUI application I can enter a shortcut, but then have to wait till the corresponding view/popup/window appears and registered it's event handlers till I can put in the next command. In a mainframe-style TUI, if I remember the sequence, I can type ahead the shortcuts and input for next screen(s) before it's ready. For the experienced user, who runs the same sequence often this is really efficient.
A fairly large GDS company has replaced their old “green screen” terminals with a web app that contains the same green screen but with syntax highlighting and hyperlinks inline controls that appear and other quality of life improvements.
This is something I've wondered about. I started out in the green screen era and remember how amazingly quick those UIs were to navigate. I don't see any reason why we couldn't replicate much of that UX and development model, but deliver it to web browsers with graphical capabilities in the parts of the system that need it.
I feel like mouse+keyboard is a step down in speed of use for many tasks, but I do wonder about touch screens. For some things, touch screens can be plenty fast and the UI adapts to the task.
Yeah, I was just thinking of a very popular bar that I would go to about 15 years ago that was operated on very simple touch screens with large UI buttons. The bartenders could enter drinks & the tab it goes on very fast. It wasn't flashy, but very simple large buttons that always pop up in the same place very quickly, so they definitely had some muscle-memory going on for navigating it.
I recall that IBM had a lot of manuals on how to design TUI , known as CUI then. Especially around the advent of OS/2 and PM, as it seemed every DOS app was gaining imitation menus and windows.
A hallmark was that functionality must fit CUI and GUI front ends alike. Keyboard shortcuts would be identical.
I first read about the unified CUI principles in Dr Dobbs' Journal.
It seems a lot of that knowledge is lost or never made in it on the web.
My employer was running Growthpower (ERP software) on an HP 3000 system up until 2018 or so. We replaced it with a "modern" .NET/MSSQL ERP solution that does a lot more, but it's slow and terrible to navigate compared to the old console menu system, and its database is hundreds of tables without a single foreign key. The frontend application makes a long series of sequential queries to build each view... if you're willing to wade through the muck, you can write a server side query that can do in milliseconds what it does in minutes.
I’ve worked at many bars and restaurants. The best ordering interface I ever used was at Pizza Hut circa 1999. It was a monochrome TUI (orange). It was ancient-looking even then.
The speed was incredible once you got proficient. Once you got the muscle memory down you could punch in any single pizza order in less than a second. Even something complicated like different toppings on the halves was NBD. Pizza Hut was always coming up with these ridiculous gimmicks and the system could accommodate them seamlessly. Just incredible.
This system probably quietly saved the company millions in its time.
The last time I went to Steve's Music Store (Toronto, Canada) they were still using the green on black terminals. This was pre-pandemic. Maybe someone can confirm if they still are.
Worked for a car insurance firm about a decade ago and the whole business ran on their Big Iron. I joined the company to work on a customer facing web UI that hooked into an API layer the server group developed to pull data from the Db2.
The callcentre however still used the TUI for all customer inquiries; it was only the customers who got a pretty interface to view their details.
Depending on which system you were logged into, you had a green screen (production) or magenta (development).
Costco still runs its warehouse operations on a TUI application running on AS/400 machines. At least the ones in Canada but I heard it's the same for the US warehouses.
That’s what’s so efficient about TUIs for local software. You typically can’t do that in web apps. Not that it’s impossible, but it’s far from the default.
Sam Ash (recently defunct U.S. musical instrument chain) infamously used a system called GERS with a TUI, the components of which IIRC were adapted from either a furniture or carpet store. Well into the 2000s, receipts were still printed in full size carbon paper (triplicate) on dot matrix printers. You'd get a gift "card" that was a literal greeting card with one sheet of that dot matrix printout stuffed in it.
I watched Alien: Earth recently and was admiring the TUIs everywhere. The show takes place in 2120 and they kept up the aesthetics of the original movies. A future full of synthetic humanoids and interstellar ships kept the TUI. I do not remember tablets being in the series, however even those seem to use a similar TUI.
I look forward to my great grandchildren rediscovering the TUI.
Ah I am still running such a thing: a wonderful piece of software I wrote in the 90s w/ FoxBase.
But here’s the nice thing: I converted everything in a Flask app with React frontend.
The nicest thing is that besides using a modern relational DB, I write everything to keep old db files synced so that I can still run the old app in DosBox…and keep the new stuff in Docker.
Prediction: there will be a huge demand for apps that have at least a baseline of functionality that is TUI enabled, preferably feature complete.
Why? Token in & out inference cost. Heck of a lot cheaper to use an LLM than a vision model for something like automating apps, or enabling your app to be agent-friendly at a low cost.
When I worked at State Street everything was done in IBM/370 terminal emulators and a COM component which made is easy to scrape information into Excel. I wasn't really supposed to know about that but found enough code examples which weren't password protected that I could figure it out.
I worked on a PCI-DSS project at a major consumer electronics retailer almost 17 years ago as an AIX/Solaris specialist.
At that time their 'web store' just put paid orders in a queue and a room full of humans typed the orders into the green screen which had all the actual inventory.
My country's national postal system still uses an IBM mainframe based system from the 80s. The clients these days are desktops with Linux Mint and a terminal emulator but it's still very much TUI based.
Wegmans’ cash registers still use a TUI. It looks quite clean and friendly compared to the GUI-heavy slop of, say, my time at a major retailer. Speaking of nostalgia, my old gaming store also used a TUI for transactions, and it was highly responsive for anything local (and a PITA anytime it had to communicate with the CO). Also been exposed to a number of businesses these past few years who still use old AIX/Unix/TUI boxes for critical business functions, and most seem happy with them.
And therein lies the rub: if the process works, and modern software doesn’t necessarily offer any better value proposition, then there’s no real reason to migrate. For a lot of companies, the status quo might literally be all they’ll ever need, and IT’s role is to just keep it up, available, and secure as times change. Sure, I’ll side-eye a theater using a Windows box as an intermediary for Ticketmaster to run transactions against their old AIX rig collecting dust in a corner of a closet, but if it works and it’s secure, well, more power to them keeping costs down.
The advice I’d give is not to knock something just because it doesn’t fit current narratives around technology. Our jobs - first and foremost - are to build and support solutions that amplify productivity of humans in a way they can use without external support; whether it’s an ancient TUI or a modern GUI isn’t as relevant as its efficacy.
I used to work for a major greeting card company that had a TUI based ERP system from the 90’s until like 5 years go. People were insanely efficient using it, but quite the learning curve to learn all shortcuts and commands.
the accountant who does my taxes, I don't know what software she uses, but just 3 or 4 years ago she sent me a document her computer created that had some serious font display problems. investigating what I had to do to make it right, I discovered that I had to install fonts from Windows 3.1!
Working with FoxPro, I'm assuming. I spent several years dealing with xBase systems, and it was honestly a nightmare. I suppose if you've never used any other language or database, you wouldn't notice. Plus, the bit relative to the OP, it's a mostly worthless skill.
I think those old TUI systems are analogous to learning Vim. At first, you don't wtf is going on. But, the more time you spend with it, the more it's ingrained, and eventually becomes second nature.
I've seen many of these systems over the years. Before I moved into software full time, the company I was working for was transitioning from a TUI to a GUI based system. The long time sales and warehousing staff absolutely hated it. Which, yes, is par for the course with any new system. But, I really believe there is an (potential) efficiency to a TUI system that makes it superior to a GUI when dealing with prototypical business operations (order entry, inventory lookup, etc).
Which makes me think, is there a market for "modern" TUI systems?
I had the great fun, no sarcasm, of modernizing a TUI system that had been in use at a company from the mid to late 80s. It was a DOS app, I don't recall the name, that let you build "screens". Each screen would have multiple fields, possibly multiple pages, and would write data to a CSV (colon separated file) with a max size of 2MB. Each screen had its own file, and screens could not "talk" to other screens. Each screen had 3 modes, search, data entry, and record paging. There was a fourth type of screen called a report. This was basically the search screen, with slightly different operators that would mainly produce counts of whatever fields were being searched for, and would send that to a printer.
The search was interesting. I don't remember the specifics of it, but it was fairly powerful. A user would enter values in fields they wanted to search on. Say they wanted to find a customer named Bill who had ordered in the last 30 days. They would move the cursor to the First name field, enter "Bill" ^ "William" (the caret being the OR operator, I do remember that one), then move to the Order field and enter "30D-", hit enter, and get their records back.
The company had about 20 of these screens, and the way they used the program was fun. Everyone in the office had a Windows computer with a network drive that pointed at the storage server. The storage server had all of the screens CSV files. There was one screen in particular that everyone used. It was the product orders screen. When someone in the office was using it, they flipped a switched on the wall next to their computer that turned on a small red light for everyone else letting them know that the product screen was in use, and no one else could touch it. Once the light went off, someone else could jump in. I heard that it was usually a race to be the next one to use it, and arguments would pop up if someone was hogging the product orders screen.
I was brought in around 2009 to modernize the system. I was told that it has to look, feel, and work exactly like the old one, but be multi user. They also gave me a list of 15 of the screens that they really needed implemented in the new system. Being that I am a web developer, that is what I reached for. PHP backend, a JS frontend, and MySQL for all the data. The first order of business was ingesting all of the CSV's, and then relating all of the data. With orders, work orders, customers, company contacts, people contacts, inventory, etc this took awhile. Next was building the API to access the data. This was fairly simple. The truly hard part was the frontend. At that point, I had little to no JS experience, but I soon learned.
By the end, I had a website that when loaded had a main menu that looked exactly like the main menu of the old app. Each screen was listed with a keyboard shortcut next to it that would load a particular screen. By default screens were in search mode. I spent a lot of time with the built in help menus of the old program, and talking to the people who used it, to get a list of all of the search functions and how they worked. Then had fun writing a parser for this that would translate the searches into SQL queries.
Hitting Page Down while in search mode would start paging through records. The challenge here was the speed. In the old app, they had at most 2MB of data on a local file. The new system of course was a web page calling an API, which was querying a database that had 30 years of data in it. Users biggest complaint is that this was just way to slow. So I reached for the new at the time web workers API to preload 100 records in the background so that paging through records became nearly instant. And this worker would start filling the record cache once it got about half way through its current list.
One of the most challenging things in the build was the keyboard navigation. In the old app, if you pressed the down arrow you would move to whatever field was directly under the current field. But, if that field overlapped 2 fields below it, and the cursor was in the far right of the field, and the user pressed down, it would move to the first location in the right side field that was under it. I basically came up with a mapping system for fields so that when a user pressed the down arrow it always went to the correct field. Another fun part was the left and right arrows. If there was no data in the field, it would just move to the next field left or right. But, if there was data in the field, it would only move left if you were at the start of the field, or right if you were at the last character written in the field.
Another challenge was keyboard shortcuts. There were key press handling libraries at the time, but none of them did quite exactly what I needed, especially with each screen mode having slightly different shortcuts. This lead to me writing my own keyboard handling library that was aware of what state it was in.
And something I had fun building was the printing capability. The old app had a companion app that could be sent data, and it would put it into a pre-built form that was then sent to a printer. So something like an invoice would be created, data was sent to the other app, it had a pre-built invoice form with a company header, and data placeholders for all the incoming records, and print that out. For my solution, I had a print.css file for each screen. When a user hit the Print Screen button the page would swap in the print.css, trigger a Ctrl-P, wait for the user to select print in the browser, then swap back to the normal css file.
I got to do so many things with a web app that first of all I didn't know were possible, and second, I haven't had the pleasure of doing since that app.
To this date, its the most fun I have had working on any project, and its still in use today. So in another 15 years, maybe someone else will have to come along and update my web TUI to whatever new technology is around.
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.
> 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.
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.
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.
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 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.
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.
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.
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.
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.
> 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.
> 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.
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 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!"
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.
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.
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.
> 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.
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.
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
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!
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.
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.
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).
I was just giving some examples, it being theoretically possible in SPA isn't really helpful given that nobody will implement it that way. You're basically living in theory.
I've literally done the before and after on this a handful of times and it's always worse off. Management will never do that, it's always design by committee, the KPIs won't be defined or will never really have teeth, it will turn into someone's vanity project, they won't even pay someone to optimize the code - quite the opposite, they'll choose to build it on something like Salesforce or some other very non-performant enterprise-y platform, etc, etc. All the TUI get these performance gains out of the box without much additional effort. The constraints of the UI are it's strength as it prevents people from adding all this bloat in the first place. When you leave it up to people, especially business users or UX folks, it will get spoiled. It's almost a law.
> nobody will implement it that way
This is not true. Smart companies do it exactly that way. It saves them a lot of money.
I have a hard time believing this. The medium impacts interaction.
Do you have concrete examples in mind that we can review?
The things I've worked on were custom tools for internal use. Built on top of existing systems, to improve productivity for specific workflows.
I've never seen a smart company then.
Possible yes but there are properties of a TUI vs a GUI where the TUI encourages faster keyboard navigation because when they were common there was only keyboard navigation whereas a GUI comes with it's own upsides (discoverability been the big one).
When I was in college (many years ago) the company I worked for used a TUI for its inventory/back office systems (terminal emulator talking to an AS/400) and once you understood the hierarchical structure and how it worked you could fly through that system because it was all keyboard nav.
Few GUI's have ever been that fast for me even the ones that go out of their way to make everything accessible via the GUI bindable.
The real issue is, that modern UX design is often too focused on pretty looks, instead of productivity. It's still possible to make a highly productive UI look pretty, but the priority is often completely wrong.
They shouldn't start from a few pretty figma sketches and then try to make them more usable. They should start from user flows, solve how the users can do certain things with maximum productivity, easy navigation, showing the right data together on the same screen, and so on. Only in the end make it pretty.
> The real issue is, that modern UX design is often too focused on pretty looks,
It may be pretty but it makes me puke.
The "modern UX design" is based on layers upon layers of abstraction and "cheap" interfaces. Which one is the button ? Where is the scrollbar ?
> It's totally possible to get this done with a web based SPA.
Sending http response, waiting for reply. Http 200 ok
and so on and so forth. Web sucks. Of course, you can have something like Jira, bur still sucks.
> It's totally possible to get this done with a web based SPA.
Yeah, I guess I could say that before I tried rebinding ctrl-w and some of the Fx keys (like F12).
Sure, in a browser you can't use all the shortcuts, but still a lot. If you really need it, just wrap it in Electron, Tauri, or any other customizable browser.
You can sure do that, but you are basically implementing a terminal in a website.
Lol, no. You can still use different font sizes, traditional controls that can also be used with a mouse (for people who don't know the shortcuts yet). Also images are possible where they make sense.
While using very common web development stacks a lot of developers know how to deal with.
I give you different font sizes, but a mouse and images are available in the Terminal as well.
I think the fancy new terminals also allow you to change the font.
Fancy old terminals that I don't see in emulators.
Look at the era of teletext. Not exactly multiple typefaces, but you could express wide, compressed, italic, bold and all colors.
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.
That is not unique to TUIs, but also possible in GUIs where the developers care, and in some games (try the GUI ("tiles") version of Brogue). You can definitely make a GUI that updates in an instant and be fully keyboard-driven, even if that may have been more common last century.
We’re comparing TUI with web browsers for good reason. I don’t see any reason to add game engines to that debate. I have never seen a business client move any application from a TUI to a Unity based UI. I’ve never even heard of anyone considering a game engine in the architecture of a business application. So what you’re saying may well be true but it’s akin to a rare mythical creature, does it even exist?
That was not what I tried to say. Brogue, like other similar games, can be played in a TUI mode, in the terminal, or with a GUI. Same game, just different UI implementations, and both tend to be about equally laggy, or usually the GUI version is probably less laggy, since you can just blit glyphs without the overhead of terminal escape codes etc to draw the same symbols in the TUI. And Brogue just uses SDL, not a game engine, so that is not relevant at all.
But your snarky reply is probably also wrong anyway, since I would be surprised if there is no business software made using game engines. Tesla is known to have used (but not anymore?) Godot for making GUIs for their in-car displays for instance. I have bought applications (not games) made using both Godot and Unity. Not saying it would be a great idea, in general, to use those engines for business applications, but people are not known for always using the best possible tools, are they, and it certainly would work in theory?
Not very familiar with Unity, but Godot has very nice GUI widgets. Same style of WYSIWYG editor like old Visual Basic or Delphi really. You drag widgets to place them on the screen, set properties, add scripts to react to different events. The entire Godot IDE itself, a very non-trivial application, is implemented using Godot's own GUI framework.
https://docs.godotengine.org/en/stable/tutorials/ui/index.ht...
Hold my beer.
I'm gonna go tell the building manager that people would like our app better and we can save on platform costs by hiring one Unity developer.
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.
A large fraction of the entire point of a GUI is not being keyboard-centric.
No, that's only the Steve Jobs view. You might be grappling with Discoverability.
When IT was trying to sell everyone on WIMP GUI, the standard was WordPerfect. There, you had to memorize the functions of the F1-F12 keys, as well as their shifted (or Control) behavior. The only sure thing was that F1 was HELP.
We were looking for something better--but having no keyboard was the opposite extreme.
How do I implement type-ahead in Qt or GTK application?
Not specifically for those but I have to assume the pattern would work: you could intercept the keystrokes in a parent window or an overlay, then forward them to the correct child window once it's rendered.
So you implement a rendering system and an input queue on top of a drawing region. Sounds like you are implementing a Terminal emulator.
Acquiring the skill to fly through such interfaces is equivalent to learning to play a musical instrument, where the desired attention (taking cues) and action (body/finger movement) becomes second nature. Such skill and interfaces are, unfortunately, not viewed as similarly valued as playing a musical instrument, and such visual presentation of the TUI is thought to be "difficult" to use, and they do take learning and effort to achieve that level of mastery. Meanwhile, the interface to traditional musical instruments, while there's been some changes and improvements, have stood the test of time and remain attractive to a lot people who want to make music. Many of the claimed "improvements" that GUI interfaces have over TUIs look in some cases, to me, like busy box toys created for toddlers (this is how I feel about the Windows Ribbon menu widgets). Once something becomes second nature, it's not "I'm putting my fingers in this position" it is "I want to play an A after this series of other notes".
Brilliantly said.
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.
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.
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.
Actual terminal-based TUIs sure, they have small character sets burned into ROM, sized for 50-years-ago prices.
Modern terminals, even the text-based console on a fresh minimal Arch linux install, is going to support Unicode probably without a ton of issues as long as you have a font installed that has the characters. The struggle then for RTL or non-Latin character sets and languages is making the UI fit the words in a way that makes sense.
Yes, you can spend an inordinate amount of time figuring out how to lay out multilingual text on a terminal, or just use Cairo or some toolkit and let solved problems stay solved.
Just use gettext? The strings might vary in sizes, but when you are comfortable with the text resolution of the GUI, just set your Terminal to the same resolution and that problem is the same.
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.
Isn't that just the order of the date components for I/O? It's still just ASCII characters.
But the past didn't use ASCII as such, but extended character sets, or multiple characters sets, which did allow for Russian, German, etc. text interfaces.
There is history frozen into printer manuals. One solution was control codes like DC1 to bank-switch the appearance of a block such as ASCII 128-159.
Yes! I was just pointing it out to show that they had at least thought of Japanese users (in some small way).
Not an issue with modern terminals and Unifont.
You are underestimating the complexity of laying out multilingual text.
Enough to read Japanese under Unicode. Arabic might be more difficult but a native might read it in a hurry at least.
And yet, as I read manuals from the 1970s-80s, I see a lot of money was made by minicomputer vendors whose operating systems were sold with multi-lingual character sets. Even Japanese.
I experienced the same thing. The big Brokerage firm I worked for in the 90s had amazing TUIs. You could fly through the screens. They even had DMs and group chats. Pretty amazing. The next company I worked for was rolling-out a GUI replacement for their TUI interface and I watched people's productivity plummet as they went from keyboard, to mouse for every text box... Those old mainframe TUIs were amazing, probably the result of decades of time and motion studies.
Back then people probably got promoted for such things.
Now they get promoted for changing things to appease MBAs and giving their boss something to talk about to their boss.
America has fallen, and we can't get back up.
I remember seeing how past people were in 1-2-3 for DOS using the / menu back in the 90's.
TUIs have a high speed ceiling when muscle memory comes into play.
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/...
I've also helped running an old Windows 3.1 accounting software. It runs perfectly fine on Windows XP inside a VM.
In 2020 it suddenly came to a halt, because the date pickers just couldn't go further than 2019. Nobody seemed to care in 1992 when it was released.
It was really easy to de-compile the Visual Basic 3 software (perfectly legal where I live). My first idea was to get the source cleaned up a bit and compile it again to 32 bit with Visual Basic 4, but I couldn't figure it out, it required some 3rd party libraries that I just couldn't get a hold of.
In the end I just changed the number 2019 in the binary to 2059 in a hex editor, and it just worked. There was only one occurrence of the number 2019 in the whole binary. I guess I got really lucky.
Edit: It seems like Windows and Visual Basic are not affected by the Unix 2038 problem at all. 16 bit Windows seems to be fine until the year 2107.
> My first idea was to get the source cleaned up a bit and compile it again to 32 bit with Visual Basic 4, but I couldn't figure it out, it required some 3rd party libraries that I just couldn't get a hold of.
This was super common for VB apps. The original architecture of VB was, loosely speaking, a GUI container for various pluggable controls connected to a BASIC runtime. The number of controls that came in the box would vary depending on how fancy a version of VB you bought, and you could plug in additional third party controls in the form of "VBX's" - Visual Basic eXtensions. Even though VBX's were designed mainly for GUI controls, they were the easiest extension point for VB and got extensively used for all sorts of integrations until OLE Automation became more prevalent. (Roughly contemporaneous with the switch to 32-bit.)
I wonder if there is a reddit thread with people showing off their surviving Windows XP setups. Mine is a dell tower laying on its side because I harvested a power supply unit from another dell, but it doesn't fit in the case.
Loads of woodworking is done on SketchUp version whatever that's pre-cloud licensing, dating from 2008 I believe. (Cloud aversion, if you will.)
Picasa & Earth era desktop Google software.
I remember using those pre-cloud versions. I loved them. Sketchup was so intuitive (as a 3D modelling noob) it was ridiculous. My tool of choice for making 3D levels for my various OpenGL projects.
I tried to do some rudimentary modelling with modern day Blender and failed. It‘s quite the juggernaut to learn.
What software today do people recommend as an alternative to Sketchup? Is the cloud version any good?
> What software today do people recommend as an alternative to Sketchup?
onshape (web; free to use unless you want to protect your designs) and fusion (autodesk; free license available) are both really popular right now. they work differently than sketchup. i never really made friends with sketchup but the parametric modeling system used in fusion and onshape clicked with me and i really enjoy using them.
I remember running Sketchup for the first time. I had zero experience but in less than 20 minutes I was drawing large complicated machinery, tractors, buildings.
They made a 3d drawing application without a learning curve O_O
Since this thread is about TUI, I confess that horrible 3D interfaces drove me into SCAD.
It's ideal for typing in your 3D geometry.
All three were bought by Google, they didn't start there.
IIRC that version made it really easy to design things with dimensional lumber. 2x4”s, 2x6”s etc. I have vague recollections of designing a dog house that way from that time period.
I’m not sure how I’d do the same thing now. If I tried to do that now with Fusion, I’d probably have to build out my own primitive set of lumber sizes, right?
A bit of searching turns up lots of references to SketchUp Make 2017. Could this be what you mean?
IIRC SketchUp 8 (released in 2010) was the last version released by Google, which had licensing allowing commercial use of the free version. After the sale to Trimble, later versions of SketchUp 8 and all future free versions become for non-commercial use only. SketchUp Make 2017 was the last free version that could run locally.
Loved using Google Sketchup back in the day! My high school engineering teacher would show off his 3D modeling of cars during class. It was so cool seeing what you could do with that software!
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:
https://www.burtonsys.com/download/dbf2csv.php
> https://www.burtonsys.com/download/dbf2csv.php
Man, this would have came in handy when I was trying to extract data from .dbf files. Ended up writing something in Go while referencing the dBase IV spec. Lots of trial and error as I recall.
There's a few tools out there, another one I tried in Common Lisp but it was a horrible pain in the ass to get working. Figured to search for perl scripts because it's pretty much fine with old as hell encodings (latin-1) as it was originally developed contemporary to those, and that came up. There's also this, but it was written for dBase III and idk how well it works with fox pro
https://linux.die.net/man/1/dbview
PHP used to have dBase database support. Also older version of Excel can just open dBase. LibreOffice seems to support it too.
https://help.libreoffice.org/latest/en-US/text/scalc/guide/d...
Hahaha this woulda saved me some time. We considered porting the app to be a web app but after some time it was obvious that wouldn't have been as good
What a lucky friend - you're a superhero.
I just like to hack shit
This whole thread reminds me of when I saw my first Windows-based ticket dispensing machine at a movie theater. Early in the year there was a screening of the Star Wars trilogy at the Cinema at the North Park Mall in Dallas. Every geek for miles beat a path to the theater. When I got there the line was moving along reasonably quickly and was maybe 20 people deep. No problem. You get to the front of the line, hand over a $10 for two $5 tickets and the cashier pressed the "dispense ticket" button twice. Two tickets came out immediately and you were on your way.
Later that same year Jurassic Park premiered at the same location. Again, every geek for miles around beat a path to the theater. But this time when I arrived, the line was hundreds of people deep and it took about 45 minutes to get to the head of the line (good thing we got there early.) When I got up to the cashier I found they had a new Windows-3.1 based ticket dispensing system. You said how many tickets you wanted and the cashier moved the mouse over a text field, took their hands off the mouse to type "1" or "2" or whatever. If you bought a child's ticket or a senior ticket, that went in a different form field. Then the cashier put their hands back on the mouse, scrolled down and hit the "calculate" button. It told them how much cash to take. They took their hands off the keyboard to collect the cash and then pressed the "dispense tickets" button. Thankfully, the system seemed to actually dispense tickets without crashing. (Windows 3.x had a very bad reliability reputation.)
What had taken 10-15 seconds with the "old school" interface now took about a minute.
Never let anyone tell you "the new system" is better just because it is new.
[[ Also, about this time I remembered Jef Raskin going on about keyboard interfaces, but this was long before the publication of The Humane Interface. And I know we're using the initialism "TUI" in this thread to mean "Text UI", but some people use it to mean "Tactile UI." No one ever got fired for recommending a React Single Page App optimized to quickly swap pages on the current model iPhone. Whether or not that's the best interface for the application is irrelevant. ]]
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.
I think you are about a decade off on your first git commit, unless you meant they went cvs -> svn or something and then ended up on git later.
There might have been another VCS involved in between, dunno if it was SVN.
Import from SCCS %DATE% %USER%
Import from CVS
Import from SVN
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.
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.
I was thinking about employee-facing tools, but I agree that TUIs present an even bigger challenge for casual users / customers.
What I heard from one large chain is they couldn't train warehouse employees on the green screen (3270) inventory app, its too different for them. They just wouldn't do it or would quit.
But if it had a Matrix screensaver...
Whoops, kids these days don't know that movie
I don't think it's an either/or situation.
An application I worked on was a GUI but (at the user's request) we loaded that thing up with hotkeys like no other.
Watching experienced employees operate a gui I worked on was a fascinating experience. They were so fucking fast!
I think the problem is that GUI authors often put hotkeys in as an afterthought.
The other thing is that GUIs can be very slow to load, limiting the potential speed/efficiency. One of the most frustrating experiences is pressing a series of key commands (or just single keys) that SHOULD have performed a very specific series of actions, but the software lagged behind at some point(s) in the flow and something ended up getting messed up because my series of key presses resulted in a totally unintended action.
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.
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.
> if you stretch the definition of TUI a bit, the Bloomberg terminal is a fascinating example
The Bloomberg Terminal uses several different UI methodologies depending on use case -- many functions (applications) are absolutely TUIs whereas Launchpad is more mouse-driven.
> In both cases, people operating these systems develop muscle memory for their everyday usage.
I worked as a UX designer at Bloomberg and when we had to modify existing functions we were careful to maintain shortcuts and keyboard navigation. In a couple cases we even ended up re-implementing UI bugs that one or more users had grown accustomed to. I've never worked anywhere quite so committed to backward UI compatibility, but that came at the expense of a steep learning curve.
Aha.
I had to reverse engineer the 1980s style ASW screen and replicate it, bugs and all. It had on-screen side effects where hitting TAB would cause numbers to recalculate according to a buggy LIBOR interpolation rule that persisted until ASW got replaced around 2010. Yet traders would take ASW as gospel.
I spent many evenings hand-marking dozens of Bloomberg screen prints to satisfy Accounting that my calculations were right and our Bloomberg operators were getting fooled.
Ha, somehow I'm not surprised.
I never worked on ASW or its replacements, but assuming they fixed the calculations in one of the newer swap curve functions I also wouldn't be surprised if some poor developer had to add a "compatibility mode" with the old calculation to avoid breaking someone's longitudinal analysis or satisfy some important user who prefers a stable calculation to a correct one.
I think the Bloomberg terminal counts as a TUI. It's also probably the most complex and heavily used TUI in existence.
I worked with a steel warehouse about 10 years ago who were using software written in a Data General Business BASIC offshoot dialect, which ran on a proprietary Windows runtime that was essentially emulating the original minicomputer which ran the software when it was originally written in the late 1970s. Thankfully, the emulator at least ran on Windows so we were able to move it to a hosted environment with backups and away from a random tower in a metal warehouse, which is no place for a computer.
We were also tasked with adding new process automation and tooling. Instead of rewriting the system, we reverse engineered the database format and wrote additional tools and utilities around the core tooling, using more modern frameworks. I think this was the right choice and everyone was happy: they didn't have to relearn years of muscle-memory and business process built around the BASIC system, but we could iterate in a modern programming environment.
It wouldn't be surprising if the system was still in use, there was nothing wrong with it and it worked great.
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.
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
> that the original mainframe hardware has likely been virtualized at this point
The as400 is a mini-computer, the high end of this line overlaps the low end of mainframe.
When I did some consulting work out there many years ago, they had a network of the largest as400's that IBM makes, connected together in one image.
Regarding virtualization: It would have to be on IBM's power processors. IBM does offer cloud services running as400, I have no info on whether Costco is using that or not.
It's a network of high end as400's, the software is custom.
They've burned multiple 100's of millions of dollars on multiple projects trying to re-develop and move off as400's, but they just pulled the plug on their most recent project a year or two ago.
The biggest issue with adoption on new system (based on insiders I've talked to) is that the existing system is very efficient for people knowledgeable about how to use it and the newer GUI based systems just don't match it.
Looks like an AS/400
AS400 in their case
AS400 I think
My grandfather purchased a niche customer management DOS application in 1986 or so and used that Software up until the day he died in 2012.
When he was finally forced to upgrade to a computer without a parallel port, he was a bit stuck for a bit because the software would only print to a printer connected via parallel port. I couldn’t find a card for this at the time, for whatever reason, but I eventually was able to trick the software into printing to a modern printer and I had never seen him more happy since it saved him the $3000 software upgrade fee.
Miss you, Grandpa!
I worked as a sales consultant for AT&T wireless, back during the smartphone boom, at their retail stores. During onboarding everyone was taught how to use the GUI for everything (OPUS, I believe it was called): creating accounts, upgrading accounts, etc. But I noticed a few of the senior reps lived in the TUI (Telegence) and wondered why. When asked they claimed they were just used to it, but I quickly learned how much faster it was by observing them. They were able to process customers so much more quickly, a comparative advantage in commissioned-based sales.
My buddy and I requested access and learned how to use it. Not only did it streamline our process, it allowed us to do everything, where the GUI often omitted certain tasks forcing us reps to call customer service (for example, providing customers with credits after fixing their accounts).
So we lived with both the GUI up for when management walked by and relied on the TUI when we needed/wanted to work quickly.
I bet the system hasn't changed a bit. But I still live in the terminal quite a bit these days.
I built my own ERP system for handling my business. It's also an TUI and has been here on Hacker News a few times.
About training new staff, there's actually studies done on it: https://pmc.ncbi.nlm.nih.gov/articles/PMC2655855/
My 2 cents is that GUI is good for exploring new software, while TUI is wonderful if you already have a mental map of what you're doing. So for everyday used software I would definitely hope that more TUI's where used.
I made a simple biz app for a friend, with dotnet C# but as a TUI. Seemed the easiest to teach.
Are you taking on new customers? I know a few folks hungry for old fashioned, on premises accounting and task tracking now that Intuit is pushing everyone to cloud subscriptions.
Ideally it would be a perpetual license so we can never have the rug pulled on business critical data, but I like the "x years of updates and support" model
You can contact me at my username + gmail if you wouldn't mind discussing further
What a coincidence, I've just read this paper while I prepare my proposal for a PhD. I feel that the difficulties reported by the novice users were related to the peculiarities of the mainframe interfaces + the 3270 emulator. Not exactly to the fact that they were using a TUI.
Super interesting study. Training new staff was always the most challenging aspect of the software.
Costco runs on TUI. They force you into minimal design and uncomplicated workflows. I bet someone is going to say you need servicenow to manage all this in an easier way. Please don’t listen to that person
Love walking by the AS/400 terminal emulator screens after checkout. If it ain't broke, why fix it?
You may need to get it to a shape where you can hire people to maintain it and not rely on IBM all the time ;)
But that being said I love TUI. Don’t ever need to use a mouse - Muscle memory and speed. Moving away from as/400 should not mean giving up the TUI
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.
Also, Costco uses AS/400. Applications that are pure function over form are amazing
I'm not positive whether Target's system from ~15 years ago was a TUI, but a friend worked there in college. He mentioned the process for tax exempt purchases was a bit challenging/not the most common. There were some frequent shoppers who had heard the assistance from the manager enough times, they could walk an employee through what buttons to press to get it setup correctly.
Was not a TUI, but was totally controllable from the keyboard. There was no mouse or touch screen, you could get pretty fast at it. You are also correct about the tax exempt thing, the customers who used it often knew what to ask for. The new registers now have a completely different UI with a touch screen. Seems like a step backwards.
My first programming "job" was a sort of summer internship when I was 14 for a family owned company called Signature Systems (signature.net). They are still in business. Their product is an operating system called Comet, that if I'm not mistaken was originally a compatibility play bringing software from the previous era of 16 bit microcomputers onto DOS PCs, and then later into Windows. I may be misremembering some of the details but I think at one point a Comet system ran ticket sales at Madison Square Gardens. My summer project was to build a demo using their new support for Windows GUI elements. The last time I spoke with the owners, they told me that they still had customers, including in the textiles industry where loom patterns had been coded in Basic. I often think about it as an example of a legacy system, and smile at the idea of someone thinking they need to rewrite their plaid weave in TypeScript or Rust.
Separately, I have spent the last three years building a web app that replaced a heap of automation scripts for a ~50 person business. These were much more modern than what the OP describes but it had some of the same qualities. The scripts mostly generated google sheets and emails. The replacement is a python web app using SQLite. Moving the company data into a proper database has been a very significant step for them. In some ways, the project feels a lot like custom business software that got built in the 90s.
Fry's Electronics used to have a powerful TUI for getting parts from the cage, the employees could hammer everything in and hit print and turn around to do something else while the screens were still loading.
Later they had some GUI that was used to open ... a terminal of some sort for the same TUI. The GUI made it slower, somehow.
RIP Fry’s
Not 100% related, but there are a few of business around that still use home computers from the 80's.
some examples:
A bakery in Indiana is still using the 40-year-old Commodore 64 as a cash register | A 1 MHz CPU and 64KB of RAM are enough [1]
A an Atari 1040ST still in use for the a campsite's operations [2]
Commodore 64 Still Powering Auto Repair Shop in Poland [3]
A Japanese kimono factory that still use a Sharp MZ-80K [4]
[1] https://www.reddit.com/r/gadgets/comments/1hhqa0h/a_bakery_i...
[2] https://www.youtube.com/watch?v=6LxPEz9x2fs
[3] https://www.popularmechanics.com/technology/gadgets/a23139/c...
[4] https://www.youtube.com/watch?v=zWJZFQHklBg
(Note: some of the above links are a few years old, it may be that it is no longer the case)
Only a few ago I had been installing new VoIP phones for a small business on the East Coast that had 2 or 3 green screen terminals and an IBM server running some variant of Unix. Most people in the office had terminal emulators, but one fellow in the warehouse section showed off his boxed terminals they had on hand incase one died. It is interesting to me to hear from someone that experienced these anachronistic machines and software. Very unique building, there was a floor between floors you could only get to via the warehouse. It made for an unnaturally long stairwell.
Textbook example of a piece of software being a shark (perfectly adapted over millennia to being a perfect predator) not a dinosaur (obsolete/extinct).
That's a great analogy! "Sharkware"
A client i work for used a Pick system and it's maintained by one dude. He's in his 60s, so who knows how long they'll be able to get support...
[0]: https://en.wikipedia.org/wiki/Pick_operating_system
I work on a bunch of Pick systems :) Love it all and we're still doing active development. (Feel free to send me an e-mail, we pick up orphaned systems)
If anyone wants to take a look, here are some links:
Open source version: https://github.com/geneb/ScarletDME
The last version of true pick: https://github.com/Krowemoh/R83
> It is named after one of its developers, Dick Pick
Wikipedia vandals these days...
There's a completely unironic obituary linked from the LA Times from 1994, which makes me wonder if the scandalous meaning even existed yet in those days?
Well it started with smartphones, so no.
Dick Pick, initially released on GIRLS.
Wow
Hahahahahaha - the kids are alright
I should become a maintainer to keep the legacy going…
My dad recently retired but his company was still using Pick as of a year or two ago. They also had a one-dude maintenance plan. I wonder if it was the same dude.
My first job out of college was over 2 decades ago, and I was hired to work on a web app which was considered new technology. But an important application there that was used by hundreds of people around the country was written with Pick, and the owner of the company also had some local Houston businesses whose Pick applications he occasionally did maintenance work on. The owner had moved from Chicago to Houston at the beginning of the 80s because he was able to get a high-paying job with no degree, but when the oil bust happened he learned Pick programming from an older guy and did so well when he started his own business that he retired early.
So many of these systems were one man shops. It really speaks to how easy to develop pick systems was. It still very much is.
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.
I don't think you're blinded by nostalgia. In the early 2000's, I worked in an organization that was migrating away from TUI to web apps. I was one of the web guys back then. We got modern, more maintainable code at the expense of usability. Those TUI interfaces are way faster.
The web failed to live up to the early promises in a lot of ways. We have complicated frameworks, complex architectures, browser headaches, etc. and what we got out of it are user interfaces that are slower than what we replaced and entire categories of bugs that didn't exist before. There's so much extra bullshit in place to overcome the fact that we are using a stateless protocol designed to deliver text documents.
The only things I would really be concerned about with your family company's app are maintainability, availability of security updates, and the use of obsolete software like XP. It sounds like you're already modernizing the code. That old OS is a disaster waiting to happen though.
I like the idea of an internal enterprise app running in the terminal on a reliable FreeBSD or Linux machine. The people who have to live in that app will be faster with a keyboard-driven workflow. A web front end is for customers and situations where you prioritize looks and accessibility over speed and usability. If you implement the the business rules in a modern middle tier and have a good database backing it, you can have the best of both - TUI for internal users and slap on a web front end for external users.
Anyone who has ever worked with legit 10-key operators understands why many companies were loathe to migrate to modern graphical interfaces.
Some of the fastest manual data entry I've ever seen was by operators entering claim information into a medical billing system based on MUMPS.
Keep all hands and feet away.
I wrote the main application for my wife's business — she's a psychologist. That was only a few years ago, but as a senior lecturer in the more theoretical parts of computer science, I never really needed fancy UIs with flashy graphical effects. So I built a core engine and used the classic dialog tool as the thin user-facing layer.
At first, my wife was pretty disappointed — as a computer science teacher, wasn't I supposed to know how to build a “real” app? But a few years later, she doesn't want anything else. I even offered to have one of my students create a nicer UI without changing the engine or database, but by now she's completely used to the terminal menus.
The tool keeps a database, collects data through dialog forms, generates PDF invoices with groff, and launches Thunderbird when needed (to send invoices, etc.).
<At first, my wife was pretty disappointed
I've got a mental picture of you excitedly unveiling your work to her. Glad she came around and very cool.
I work in a medical center, which is my family business. in here, I am the IT guy, as well as receptionist and one of the secretaries.
we currently use a 2019 HP Pavilion 15 laptop with an AMD Ryzen 7 3700U, 12GB of DDR4 RAM, and a 512GB SSD. as you may have noticed, this computer is insanely overpowered for just using Excel and WhatsApp. that's why I've been given the task to downgrade to a different piece of hardware, a 2011 laptop with an Intel Pentium P6200, 2GB of DDR3 RAM, and a 300GB HDD.
and I am the guy responsible of building the old-new TUI app we will use in that machine. I am conscious of how much of a downgrade this is, but it's to avoid throwing away hardware that still works.
I have made a few prototypes using lightweight web technologies, but I ended up not liking how they look, perform or interact, so I start over. this time I will attempt to build something especially tailored to this old laptop, using TUI tools like ncurses.
Both of the lumberyards in my city are still running on DOS (or DOS emulation) for their systems, along with quotes printed on dot matrix printers (and no online price sheet). They’re so low margin and old school, I don’t think they get tech upgrades more often than once every two human generations except for new capital equipment, which sucks most of their surplus.
I still use a dot matrix in my office lol. I love the sound and they are so cheap to operate.
I supported a lumberyard that was like this too. Also, some "modern" laser machines required ancient versions of Windows and required floppy discs. This was about 20 years ago, though.
TUI were great for many business applications, specially those in warehouses or factories. They were easier to write and modify. Many business applications were migrated to web for little gain. IMHO.
I'm in the distribution/manufacturing ERP vertical in the US for SMB clients... yes we see it. No - not often
Most people are running on 90s-2000s era stuff rather than TUIs.
For the most part, it works well, and is not very costly.
Check out Sage100... flexible, cheap, on prem... runs everything from job / work tickets to inventory, purchasing, financials, payroll, etc.
Aint sexy but it works!
Nice - thank you!
Have you ever been to a Marriott? They have something called MARSHA depending on the property. Once you log in it's basically a command line interface filled with abbreviations. As a high schooler in 2016 I used to train people at a reservations call center on how to use Marsha. It's super unintuitive but surprisingly everyone can wrap their heads around it eventually. Ok maybe 9 out of 10. You could decline to learn Marsha and work for properties that use a GUI like Opera PMS (for us it was mainly IHG properties). You got a pay raise if you learned Marsha. Opera was great, they later started upgrading to some bloated crap with lots of padding between buttons.
IIRC Marsha has transactions so you can build up a reservation and make queries in the process. There's even test properties in production so you can practice making/reserving/retrieving reservations.
Super late to the party, but Dale Harris Cash Register is a free Point of Sales TUI program that has been maintained by Dale since the 90s[1]. The website is pretty great too. He originally made it for his locksmith/key business. He has a gallery of people using it in the wild [2]. I've always wanted to have some sort of business where it makes sense to use it!
[1] https://keyhut.com/pos.htm [2] https://keyhut.com/posphoto.htm
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.
People who are good programmers say this, they have this fantasy, but it's a myth. The opposite is of course true, because there is no maintenance, there are a bajillion agonizing bugs and people simply work around them, the "small fixes" live inside the heads of the people using the application.
Like the fantasy is that the bank uses TUIs and the bank has accumulated years of knowledge and the bank doesn't make mistakes. The bank has extremely well paid staff. Joe Shmoe's TUI app looks like the bank's app, but it is unmaintained, it has accumulated years of problems, not fixes, nobody is fixing them, people who say they fix them cannot possibly be keeping up with the sheer amount of toil and bugs needed for production software. You can see this in any GitHub project, how much insane maintenance is required, for stuff people actually use and has few bugs.
Eh, I bet a lot of this stuff is running on some old SCO box held together with ducttape and prayers, because the vendor is long gone/dead.
A lot of “traditional” industries still run on TUIs/even as400 systems, such as freight/trucking companies, banking, medical, travel (saber, etc). And many companies in those spaces who appear to have migrated away from those systems are likely just using a modern gui interface that still uses those old systems behind the scenes.
It’s generally because 1) they’re actually reliable 2) they contain custom business logic and rules that are not documented well/at all and hard to replicate 3) the people who set up all of these things have retired and no one is left who understands any of it
Until recently I helped running an old Clipper/dBase TUI application from the late 80s for a family member. We managed to run it successfully until they retired.
vDos (vdos.info) was a huge life saver for this application. It's similar to DOSBox, but more tailored to business applications. The big issue was always to find compatible printers for the old application, vDOS includes some emulation to print to any Windows printer.
There might be free alternatives to vDos, but it worked very well and is reasonably priced.
PS: we also tried to recompile the Clipper source code with Harbour to modern targets. It looked very promising, but they were extremely happy with the vDos solution, which only took 2 hours to deploy.
Thanks for the link, afaik my clients are still stuck using their old DOS TUI in a windows 7 VM that has no network access
I've been there, this doesn't work well at all. Actually since Windows NT the DOS subsystem is already an emulation, and it's not that good. DOS applications worked really well up to Windows ME, but with NT/XP/7 it got worse.
vDos was overall much better than running DOS applications directly on Windows. Only drawback was performance. It never ran as fast as on a Pentium III with Windows 98, but still much faster than the original hardware it was designed for (~30 mhz 80386).
Our application was designed for Novell NetWare, back then it even supported row/table locks for dBase files on the shared network drive. This didn't work with Windows NT anymore. But vDos brought back the feature to Windows 10 and SMB shares!
What type of business was it? What kind of functionality did this TUI application provide?
It was a customer management and billing system, for a specific industry. Tailored to local requirements and insurance regulations (a lot of things got billed to insurance). There is commercial software available for this purpose, but it's a very small target group, and the products are neither great, nor cheap.
Over time it even got extended to interface with a few external systems, mostly by reading and writing text files to specific locations.
It was deployed on one location with 2-5 concurrent users on the same database. The workflow was something like this: open customer/new customer, read/add notes, register products/services provided, print invoice for customer, print monthly invoice for insurance companies including all the required information (hundreds of pages).
> a few external systems, mostly by reading and writing text files to specific locations
The joys of large business transactions handled by .txt files (or equivalent) over FTP (or equivalent). It almost feels… like digital fax, in a way.
The joy of cron jobs sending files by ftp to the mainframe, which falls back to paging the programmer.
Reminds me of this story from 2021
https://hackaday.com/2021/10/06/atari-st-still-manages-campg...
I have also met some people who worked at large old insurance companies. They originally used old mainframes and TUI, and the companies still exist. They told me of various things that were done. Of course migrations happened. And interfaces were built so that modern systems could speak with the old, sometimes via terminal emulator. And of course, some old systems still in use far beyond their time.
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.
I'm starting to maintain a COBOL codebase for my dad's small business. It uses MicroFocus's runtime so it runs fine on Windows 10/11 (but I'm trying to migrate it to OpenCOBOL). He helped write a good chunk of it, but doesn't make any major changes to it anymore. I'm not confident enough to make major changes to it, but I fix some bugs here and there. I ended up writing a python script to parse the database layout for a python-based fuzzy search tool, but I still stuck to a terminal UI for it.
This prompted me to check if MicroFocus was still in business. It's a little complicated. Also, the Wikipedia article mentions Ryan-McFarlan - a COBOL and FORTRAN compiler company. I miss the 80s...
https://en.wikipedia.org/wiki/Micro_Focus
> This got me thinking: Are other companies still using this type of interface to drive their core operations?
Probably a big chunk of businesses that developed their core systems before the PC era. I don't know if they still use it, but Avis Rent-a-car's main application used by its front-line people was a TUI like that, and the front desk people could fly around int it (like you said).
But most developers ape current trends rather than actually figuring out what would work best, so I'd guess very few user-facing TUIs are being built now.
I immediately think of Terminal Coffee[1].
Been experimenting with charmbracelet's[2] stuff recently to do something similar. Still very early stages so nothing to show off yet but would highly recommend it for anyone else looking into creating a TUI app/business.
[1] https://www.terminal.shop/ [2] https://github.com/charmbracelet
I’m bringing charmbracelet to the web using gotty. The example is chat app that uses tailscale as the auth layer, and is exposed over ssh via charmbracelet/wish and over http via gotty. I haven’t written any docs yet; you should be able to run the example chat app on your tail net.
Would like to add some other forms of auth, but tailscale was just so easy to provide the same auth for both ssh & http.
https://github.com/ghthor/webtea
> I got my start as a script kiddie writing automations for this system with Microsoft Access, VBA, and SendKeys to automate data entry
I've done exactly this for the likes of JP Morgan Chase. Many of their core banking systems are some COBOL/Fortran mainframe (that I know nothing about) but the interface through a TUI client. When they have a desire to work in a more modern fashion, it's SendKeys to the rescue. There's definitely still a lot of TUI's that run the world.
Quite a few large businesses are still running code that was originally written for mainframes in the 60s and 70s. Usually it is large batch operations, but I know of at least two fortune 100 companies that still have non-technical users running terminal emulators to connect to their 'mainframe' to perform some tasks.
I was about to say that's what keeps Sungard in business, but then I googled and saw they are no longer in business. So maybe it is starting to die down.
I visited a food service company a couple years ago. They had phone reps taking orders from customers (restaurants ordering produce and such). They used a TUI (a "green screen" essentially).
I have never seen people move through a GUI that fast. They were lightning quick with it. They were like an veteran accountant with a ten-key adding machine. It was amazing, and pretty damn sobering when you think how much work we spend on GUIs.
Been through this cycle a few times. What helped wasn’t stepping away from AI — it was building something that runs itself. Once you stop babysitting models and start automating the orchestration, the stress drops fast. My current project basically learns and adapts without me watching it, and that’s been the difference between burnout and flow.
I recall guitar center is still on a green screen back when I worked there in my youth. It was pretty fun learning that interface, fancy keyboard shortcuts etc.
In this thread:
- people with seriously thick rose colored glasses
- hazy fever dream of TUI applications
- folks not understanding that gui applications definitely can have shortcuts like TUI -- it comes down to design and the developer(s) making it
I remember going to the Pasadena Public Library as a kid (90s) and there were terminals everywhere for interfacing with the digital card catalog system. Pretty sure they were made by Digital/DEC. The black screens with orange glowing text were such a pleasure to play around with. I've been thinking it would be fun to have one of these in my house 24x7 to interface with a Home Assistant TUI.
Was it Dynix by chance?
https://en.wikipedia.org/wiki/Dynix_%28software%29
I struggle to remember myself... but I found this earlier today:
"The years of 1995 and 1996 brought many technological improvements to the Library including the addition of InfoTrac SearchBank, a computerized magazine and newspaper index; ADVANCE, a new Unix-based online library catalog; public access to the Internet with terminals at all library locations;"
ADVANCE: https://librarytechnology.org/document/4772
InfoTrac: https://en.wikipedia.org/wiki/InfoTrac
Not using TUIs (unfortunately). Work in a large business on services for real estate transactions. Heavy GUI applications. I’ve actually been investigating adding heavily keyboard-driven interfaces to our GUI apps with my teams because the multi-screen clicking around all our users have to do now is so incredibly slow and inefficient.
Some of my most productive use of software (in both personal and professional settings) have been with TUIs.
Even with all the hype around AI right now (and we’re working with that, too), we can’t not have more traditional UIs to keep a human in the loop when it matters the most and as a fallback for when AI misses the mark - but that doesn’t have to mean it’s all click heavy.
There are entire businesses still running on Commodores..
https://www.pcworld.com/article/2562588/this-us-business-sti...
https://www.reddit.com/r/Commodore/comments/avv1j1/this_olda...
https://groups.google.com/g/comp.sys.cbm/c/LuLJihA1NCU?pli=1...
It's been a while since I worked at a bank, but most there core stuff was running in a mainframe and while "modern" front ends exist, the core work uses terminal access.
A key thing modern replacements lose is the input buffer: One can type multiple screens ahead. In a modern GUI application I can enter a shortcut, but then have to wait till the corresponding view/popup/window appears and registered it's event handlers till I can put in the next command. In a mainframe-style TUI, if I remember the sequence, I can type ahead the shortcuts and input for next screen(s) before it's ready. For the experienced user, who runs the same sequence often this is really efficient.
Count your blessings.
And if anyone suggests rewriting it, fire them.
A fairly large GDS company has replaced their old “green screen” terminals with a web app that contains the same green screen but with syntax highlighting and hyperlinks inline controls that appear and other quality of life improvements.
This is something I've wondered about. I started out in the green screen era and remember how amazingly quick those UIs were to navigate. I don't see any reason why we couldn't replicate much of that UX and development model, but deliver it to web browsers with graphical capabilities in the parts of the system that need it.
I feel like mouse+keyboard is a step down in speed of use for many tasks, but I do wonder about touch screens. For some things, touch screens can be plenty fast and the UI adapts to the task.
Yeah, I was just thinking of a very popular bar that I would go to about 15 years ago that was operated on very simple touch screens with large UI buttons. The bartenders could enter drinks & the tab it goes on very fast. It wasn't flashy, but very simple large buttons that always pop up in the same place very quickly, so they definitely had some muscle-memory going on for navigating it.
I recall that IBM had a lot of manuals on how to design TUI , known as CUI then. Especially around the advent of OS/2 and PM, as it seemed every DOS app was gaining imitation menus and windows.
A hallmark was that functionality must fit CUI and GUI front ends alike. Keyboard shortcuts would be identical.
I first read about the unified CUI principles in Dr Dobbs' Journal.
It seems a lot of that knowledge is lost or never made in it on the web.
My employer was running Growthpower (ERP software) on an HP 3000 system up until 2018 or so. We replaced it with a "modern" .NET/MSSQL ERP solution that does a lot more, but it's slow and terrible to navigate compared to the old console menu system, and its database is hundreds of tables without a single foreign key. The frontend application makes a long series of sequential queries to build each view... if you're willing to wade through the muck, you can write a server side query that can do in milliseconds what it does in minutes.
I’ve worked at many bars and restaurants. The best ordering interface I ever used was at Pizza Hut circa 1999. It was a monochrome TUI (orange). It was ancient-looking even then.
The speed was incredible once you got proficient. Once you got the muscle memory down you could punch in any single pizza order in less than a second. Even something complicated like different toppings on the halves was NBD. Pizza Hut was always coming up with these ridiculous gimmicks and the system could accommodate them seamlessly. Just incredible.
This system probably quietly saved the company millions in its time.
The last time I went to Steve's Music Store (Toronto, Canada) they were still using the green on black terminals. This was pre-pandemic. Maybe someone can confirm if they still are.
Worked for a car insurance firm about a decade ago and the whole business ran on their Big Iron. I joined the company to work on a customer facing web UI that hooked into an API layer the server group developed to pull data from the Db2.
The callcentre however still used the TUI for all customer inquiries; it was only the customers who got a pretty interface to view their details.
Depending on which system you were logged into, you had a green screen (production) or magenta (development).
Costco still runs its warehouse operations on a TUI application running on AS/400 machines. At least the ones in Canada but I heard it's the same for the US warehouses.
> I can fly around in it.
That’s what’s so efficient about TUIs for local software. You typically can’t do that in web apps. Not that it’s impossible, but it’s far from the default.
Sam Ash (recently defunct U.S. musical instrument chain) infamously used a system called GERS with a TUI, the components of which IIRC were adapted from either a furniture or carpet store. Well into the 2000s, receipts were still printed in full size carbon paper (triplicate) on dot matrix printers. You'd get a gift "card" that was a literal greeting card with one sheet of that dot matrix printout stuffed in it.
I noticed Guitar Center also using a TUI when I was in there last.
TCL and Expect would shine there. Even JimTCL could do it once built against WIndows XP with Min-C:
https://github.com/msteveb/jimtcl
https://minc.commandlinerevolution.nl/english/home.html
My buddy works at a rather large auto auction and uses a TUI extensively, only jumping out to copy stuff from a few GUIs and pasting it into the TUI.
Leroy Merlin (French multinational retail company, home improvement and gardening products) still runs these systems at the PoS, at least in Spain.
I watched Alien: Earth recently and was admiring the TUIs everywhere. The show takes place in 2120 and they kept up the aesthetics of the original movies. A future full of synthetic humanoids and interstellar ships kept the TUI. I do not remember tablets being in the series, however even those seem to use a similar TUI.
I look forward to my great grandchildren rediscovering the TUI.
Ah I am still running such a thing: a wonderful piece of software I wrote in the 90s w/ FoxBase.
But here’s the nice thing: I converted everything in a Flask app with React frontend.
The nicest thing is that besides using a modern relational DB, I write everything to keep old db files synced so that I can still run the old app in DosBox…and keep the new stuff in Docker.
It works, flawlessly:-)
The https://ratatui.rs/ TUI framework has a backend called Ratzilla (https://github.com/orhun/ratzilla) that lets you build web applications which look and feel like TUIs.
Prediction: there will be a huge demand for apps that have at least a baseline of functionality that is TUI enabled, preferably feature complete.
Why? Token in & out inference cost. Heck of a lot cheaper to use an LLM than a vision model for something like automating apps, or enabling your app to be agent-friendly at a low cost.
There's this Polish article about a company that balance drive shafts with commodore c64
https://www.trojmiasto.pl/tv/Commodore-64-maszyna-do-wywazan...
When I worked at State Street everything was done in IBM/370 terminal emulators and a COM component which made is easy to scrape information into Excel. I wasn't really supposed to know about that but found enough code examples which weren't password protected that I could figure it out.
Seems like a good fit for Expect.
https://core.tcl-lang.org/expect/index
https://en.wikipedia.org/wiki/Expect
Huge swathes of business software run on stuff built in the 80s and 90s with only incremental changes since.
I worked on a PCI-DSS project at a major consumer electronics retailer almost 17 years ago as an AIX/Solaris specialist.
At that time their 'web store' just put paid orders in a queue and a room full of humans typed the orders into the green screen which had all the actual inventory.
My country's national postal system still uses an IBM mainframe based system from the 80s. The clients these days are desktops with Linux Mint and a terminal emulator but it's still very much TUI based.
Wegmans’ cash registers still use a TUI. It looks quite clean and friendly compared to the GUI-heavy slop of, say, my time at a major retailer. Speaking of nostalgia, my old gaming store also used a TUI for transactions, and it was highly responsive for anything local (and a PITA anytime it had to communicate with the CO). Also been exposed to a number of businesses these past few years who still use old AIX/Unix/TUI boxes for critical business functions, and most seem happy with them.
And therein lies the rub: if the process works, and modern software doesn’t necessarily offer any better value proposition, then there’s no real reason to migrate. For a lot of companies, the status quo might literally be all they’ll ever need, and IT’s role is to just keep it up, available, and secure as times change. Sure, I’ll side-eye a theater using a Windows box as an intermediary for Ticketmaster to run transactions against their old AIX rig collecting dust in a corner of a closet, but if it works and it’s secure, well, more power to them keeping costs down.
The advice I’d give is not to knock something just because it doesn’t fit current narratives around technology. Our jobs - first and foremost - are to build and support solutions that amplify productivity of humans in a way they can use without external support; whether it’s an ancient TUI or a modern GUI isn’t as relevant as its efficacy.
I used to work for a major greeting card company that had a TUI based ERP system from the 90’s until like 5 years go. People were insanely efficient using it, but quite the learning curve to learn all shortcuts and commands.
this should video of the use of IBM CallPath on an AS/400 should get you all misty-eyed https://youtu.be/5pY6Xxptp9A?t=2058
Plenty of places are still running this: https://keyhut.com/pos.htm
Just recently seen this sort of trend of text-based UI or "TUI" applications in the terminal which has caught my attention ever since Claude Code.
Where can I find these TUI applications to look at?
https://github.com/rothgar/awesome-tuis
I think some people would enjoy something akin to HyperCard for building custom TUIs and/or highly efficient web UIs.
About 99% of the DevOps guys I know use K9s which is a TUI application for managing EKS clusters.
Somewhere in 2004 I upgraded a TUI interface for a major advertising company in Belgium to support €. They used it for many years since, AFAIK.
Microcenter does this too. When you are in the checkout you can see the cashier using a DOS interface to ring up the items.
the accountant who does my taxes, I don't know what software she uses, but just 3 or 4 years ago she sent me a document her computer created that had some serious font display problems. investigating what I had to do to make it right, I discovered that I had to install fonts from Windows 3.1!
Interesting. What sort of database are they running and what is the frontend? Dbase? Foxpro? Turbo Pascal with BDE?
Foxpro is alive and well in our town water utilities company. My fellow student still works on it. I don't know a worse way to waste your best years.
What do you consider waste? Living in a small town? Working for a utility company? Working with outdated software?
Working with FoxPro, I'm assuming. I spent several years dealing with xBase systems, and it was honestly a nightmare. I suppose if you've never used any other language or database, you wouldn't notice. Plus, the bit relative to the OP, it's a mostly worthless skill.
This is a good direction, converting TUI to GUI.
I manage the roomaccess of my workshop via a custom TUI application . Works flawlessly.
Costco still uses a TUI in its stores that looks like it runs on DOS.
When i checkout at costco i see their TUI and im so curious about it.
Does linux count? 99% of linux use-cases don't include xwindows.
They are managed via terminal probably, but only few cases the business application runs as TUI.
I think those old TUI systems are analogous to learning Vim. At first, you don't wtf is going on. But, the more time you spend with it, the more it's ingrained, and eventually becomes second nature.
I've seen many of these systems over the years. Before I moved into software full time, the company I was working for was transitioning from a TUI to a GUI based system. The long time sales and warehousing staff absolutely hated it. Which, yes, is par for the course with any new system. But, I really believe there is an (potential) efficiency to a TUI system that makes it superior to a GUI when dealing with prototypical business operations (order entry, inventory lookup, etc).
Which makes me think, is there a market for "modern" TUI systems?
Any good guides to building TUIs in 2025?
If you like Python, try https://textual.textualize.io/
IBM IMS - fast until abend :)
This is absolutely impossible in the EU where law is changed 100x times per day. You simply wouldn't comply.
what if your entire business was on a TUI? terminal.shop be like
I had the great fun, no sarcasm, of modernizing a TUI system that had been in use at a company from the mid to late 80s. It was a DOS app, I don't recall the name, that let you build "screens". Each screen would have multiple fields, possibly multiple pages, and would write data to a CSV (colon separated file) with a max size of 2MB. Each screen had its own file, and screens could not "talk" to other screens. Each screen had 3 modes, search, data entry, and record paging. There was a fourth type of screen called a report. This was basically the search screen, with slightly different operators that would mainly produce counts of whatever fields were being searched for, and would send that to a printer.
The search was interesting. I don't remember the specifics of it, but it was fairly powerful. A user would enter values in fields they wanted to search on. Say they wanted to find a customer named Bill who had ordered in the last 30 days. They would move the cursor to the First name field, enter "Bill" ^ "William" (the caret being the OR operator, I do remember that one), then move to the Order field and enter "30D-", hit enter, and get their records back.
The company had about 20 of these screens, and the way they used the program was fun. Everyone in the office had a Windows computer with a network drive that pointed at the storage server. The storage server had all of the screens CSV files. There was one screen in particular that everyone used. It was the product orders screen. When someone in the office was using it, they flipped a switched on the wall next to their computer that turned on a small red light for everyone else letting them know that the product screen was in use, and no one else could touch it. Once the light went off, someone else could jump in. I heard that it was usually a race to be the next one to use it, and arguments would pop up if someone was hogging the product orders screen.
I was brought in around 2009 to modernize the system. I was told that it has to look, feel, and work exactly like the old one, but be multi user. They also gave me a list of 15 of the screens that they really needed implemented in the new system. Being that I am a web developer, that is what I reached for. PHP backend, a JS frontend, and MySQL for all the data. The first order of business was ingesting all of the CSV's, and then relating all of the data. With orders, work orders, customers, company contacts, people contacts, inventory, etc this took awhile. Next was building the API to access the data. This was fairly simple. The truly hard part was the frontend. At that point, I had little to no JS experience, but I soon learned.
By the end, I had a website that when loaded had a main menu that looked exactly like the main menu of the old app. Each screen was listed with a keyboard shortcut next to it that would load a particular screen. By default screens were in search mode. I spent a lot of time with the built in help menus of the old program, and talking to the people who used it, to get a list of all of the search functions and how they worked. Then had fun writing a parser for this that would translate the searches into SQL queries.
Hitting Page Down while in search mode would start paging through records. The challenge here was the speed. In the old app, they had at most 2MB of data on a local file. The new system of course was a web page calling an API, which was querying a database that had 30 years of data in it. Users biggest complaint is that this was just way to slow. So I reached for the new at the time web workers API to preload 100 records in the background so that paging through records became nearly instant. And this worker would start filling the record cache once it got about half way through its current list.
One of the most challenging things in the build was the keyboard navigation. In the old app, if you pressed the down arrow you would move to whatever field was directly under the current field. But, if that field overlapped 2 fields below it, and the cursor was in the far right of the field, and the user pressed down, it would move to the first location in the right side field that was under it. I basically came up with a mapping system for fields so that when a user pressed the down arrow it always went to the correct field. Another fun part was the left and right arrows. If there was no data in the field, it would just move to the next field left or right. But, if there was data in the field, it would only move left if you were at the start of the field, or right if you were at the last character written in the field.
Another challenge was keyboard shortcuts. There were key press handling libraries at the time, but none of them did quite exactly what I needed, especially with each screen mode having slightly different shortcuts. This lead to me writing my own keyboard handling library that was aware of what state it was in.
And something I had fun building was the printing capability. The old app had a companion app that could be sent data, and it would put it into a pre-built form that was then sent to a printer. So something like an invoice would be created, data was sent to the other app, it had a pre-built invoice form with a company header, and data placeholders for all the incoming records, and print that out. For my solution, I had a print.css file for each screen. When a user hit the Print Screen button the page would swap in the print.css, trigger a Ctrl-P, wait for the user to select print in the browser, then swap back to the normal css file.
I got to do so many things with a web app that first of all I didn't know were possible, and second, I haven't had the pleasure of doing since that app.
To this date, its the most fun I have had working on any project, and its still in use today. So in another 15 years, maybe someone else will have to come along and update my web TUI to whatever new technology is around.
Yeah so does CostCo