The library example is a great one. They used to run some flavour of TSS / UNIX -- I want to say "Bullfrog" or "Bulldog" but I know that's not right -- and it was childs play to operate them. Literally in fact, since they'd have those same systems in schools too.
Then in the mid to late 90s the UK libraries near me switched to Windows 95 + Internet Explorer 4 (albeit massively locked down) and everything was slow. You could visibly see the page load. It would crash often. But above all else, it wasn't any more intuitive than the TUIs of green screens.
I get GUIs are better for home computing interfaces but I never understood why they replaced TUIs in fields where the primary focus is text input. eg call centres and data entry teams, those old green screens were much easier and quicker for agents to use than any of the web forms that replaced them.
I always put it down to lazy development. It's easier to build website and host it on Apache/NGINX than it is to build a green screen and deal with hardening remote terminal access.
I don't disagree with your point, but one consideration is that GUIs are going to feel more familiar to most people, particularly non technically savvy people. Most people wont care about the objective efficiency of an interface - if it looks and feels like something they would use on their computer at home, they will feel more comfortable and adapt to it quicker. A TUI will be less familiar, more likely to be looked at as "old" and "clunky" (irrespective of its its merits) and thus people will adapt to it more slowly.
Obviously, "back in the day" TUIs were the only option, but computers were not as a prevalent back then, so there was no familiarity factor to leverage.
> Most people wont care about the objective efficiency of an interface
They do in the job roles I exampled because a large part of their job is quick entry. I have experience building and supporting systems for those types of users and a frequent comment is "I want to be able to enter information as quickly as I can so I can keep up with the customer speaking their instructions". Some of the older agents even preferred green screens because they could write with one hand and type with the other (while wearing a headset) -- I never quite got how they managed to multitask like that but kudos to them for pulling it off.
Back around 1999 I worked for a company and one of the jobs we had was to replace a financial data entry system which was written in BASIC and run on an aging mini comupter. Access to it was done via a terminal and it was a text based interface. The reason for replacing the system was part of the company's Y2K plan and in preperation for the Euro.
The company wanted everything to run under Windows so it had to be a native app with a GUI. When we deployed it there was a flood of compaints. Most of them were about the speed of data entry and the fact that the old keyboard shortcuts they were all used to had stopped working.
We tried to fix as many of the issues that we could but there was only so much that we could do. As it was a contract job we had to work with the UI the company wanted and as it was a contract job, once the bugs were fixed we couldn't make any other changes.
> Most people wont care about the objective efficiency of an interface
This raises another important consideration. A lot of software isn't and shouldn't be aimed at "most people". A few weeks spent learning something less intuitive can easily pay off over the course of a professional career using the software if it affords those that know the interface well a faster or otherwise better workflow.
Just a reminder so that you people don't design CAD software for heavy use by professionals in the same way you'd design a tax form for almost everyone to use once a year.
In principle though. You _could_ build a nice TUI application using one of the modern TUI frameworks, that you launch from a 'normal OS' for these specific applications, and make the machines connect through some zero trust networking solution. I think the hardest part would be to get management buy-in, not anything technical.
Sorry, I didn't mean it was impossible or even hard to do. I just meant throwing a web site up is easier at all points of the stack. It's the same reason Electron is popular, writing native applications isn't exactly hard per se, Electron just makes the process easier and cheaper at all stages of development.
I would think it should be possible to replicate the UI pretty well on a website, to make it just as quick. Data transferring behind the scenes making it just as snappy.
Yes, but not everywhere. For example, mid '90s software of top professional grade keeping the CPU on all the times.
One of the differences is that some systems of yore looked more rooted in the engineering mindset, whereas today some perceive a way overly "excessive" (in fact, simply wrongly headed) focus on the dumbest specimen (and not to help it but to celebrate it).
Edit: ...so, on a different side, in the old times we could approach technology with full joy, whereas today there are many reasons to approach products with suspect and diffidence.
Just like anything else unfortunately. Similarly, a good scientific calculator in the hands of an engineer is an indispensable tool, but to the general public, it's a confusing mess.
The early internet was designed by and for the people who knew what they were looking for and simply needed the tools to find it.
Modern engineering calculators have streamlined the design and done away with numbers and function buttons. You just hold them in your hand and pose while looking at the ads displayed on the screen.
> One of the differences is that some systems of yore looked more rooted in the engineering mindset, whereas today some perceive a way overly "excessive" (in fact, simply wrongly headed) focus on the dumbest specimen (and not to help it but to celebrate it).
I think this is largely due to the increasing pervasiveness of computers. "Back in the day" the consumers of a software package were likely either very skilled people, or people who were paid to use the software as part of their job, and thus would receive training. Nowadays, there are many more types of computer user.
> mid '90s software of top professional grade keeping the CPU on all the times
Apart from MS-DOS which was already on the way out, mid-90's (even mid-80's) operating systems were already mostly multi-threaded and event-driven and the CPU was idling most of the time (at least in UI applications). They most definitely wasted much fewer CPU cycles per input event than 'modern' operating systems and applications.
Yes but it was a transition. So some very prominent software applications still were not event driven approaching year 2000. Then the new paradigm caught - but the frameworks became increasingly complex.
I remember, in the mid-90s, looking up stuff at a library on a VT100-ish terminal connected via some sort of serial arrangement to a larger computer.
Function keys were clearly labeled, searching was fast and worked well.
None of the heavier replacement machines ever felt as snappy or as useful.