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.
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.
> 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.
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.
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
That seems to have slowly vanished over the last 30 years
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.
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
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...
And no, we don’t have the glorious keyboards from that time :( just standard 104s
And those users want more batch creation and editing.
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.
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
- you can build lightweight web pages if you priority small script size, minimal dependencies,
and do profiling to keep things in check
- limit the amount of data loaded and displayed at one time
- 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
- you can create a keyboard navigation system
- you can build keyboard shortcuts into every screen
- you can create autocomplete shortcut commands to jump to screensIndeed. 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.
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.
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.
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…
Yes, but the it's not due to slow rendering speed. GUIs render even slower.
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.
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 :-)
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.
> 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.
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.
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.
Variable width fonts and style sheets are nice, though.
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 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.
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.
If you’ve seen any of the GUI retail tools that replaced the TUIs, they certainly aren’t designed for discoverability.
I've probably made that sort of UI without realizing it...
The UX is optimizing for accuracy over ease of use, and in this case is likely intentionally difficult to use.
They are. So. Slow. Each and every one of them. Its awful
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.
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.
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/...
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.
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.)
Picasa & Earth era desktop Google software.
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?
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.
They made a 3d drawing application without a learning curve O_O
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?
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!
I've never once seen an experienced user equal or gain efficiency when switching. It's always a loss even after months of acclimation.
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'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.
This is not true. Smart companies do it exactly that way. It saves them a lot of money.
Do you have concrete examples in mind that we can review?
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.
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.
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 ?
Yeah, I guess I could say that before I tried rebinding ctrl-w and some of the Fx keys (like F12).
While using very common web development stacks a lot of developers know how to deal with.
I think the fancy new terminals also allow you to change the font.
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 perfectly possible to handle large amounts of data by copy and paste on a web browser, you just have to actually support it.
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.
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.
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.
FWIW, dBASE IV version 1.5 does support Japanese for date format. It's one of the options for 'SET DATE' command.
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'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.
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
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.
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. ]]
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 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.
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.
And 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.
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
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.
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.
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!
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.
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.
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.
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.
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
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
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.
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
Wikipedia vandals these days...
As you'd expect with having a TUI the users can absolutely fly through it. It's extremely efficient for them.
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.
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.
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.
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.
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've got a mental picture of you excitedly unveiling your work to her. Glad she came around and very cool.
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
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.
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.
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.
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!
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).
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.
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.
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
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 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.
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'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.
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.
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).
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...
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.
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.
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.
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.
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:-)
I look forward to my great grandchildren rediscovering the TUI.
https://www.trojmiasto.pl/tv/Commodore-64-maszyna-do-wywazan...
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.
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.
Where can I find these TUI applications to look at?
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!
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 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.
"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