I'm relatively young, only 30, but I have the "privilege" to work on a variety of 90s-era windows-based systems. Everything is mouse-driven. When you have to use the mouse to navigate between multiple nested GUI pages, and each one has a couple seconds of load time, and the button to get to the next level is in another spot relatively to where the previous button you clicked was, it takes hours of your day just navigating between contexts over the course of an entire work day. People who think my fear/hatred of the mouse is irrational have never had to work on the irrational systems and terrible UX that the widescale prevalence mouse has enabled.
Your youthful innocence presumably shielded you from having had to work with the corresponding keyboard driven text menu systems that preceded these mouse based GUI systems. I assure you that they could be far less pleasant to use.
Granted, for any input modality, there are better and worse designs using it, but when designed properly, having an additional modality available can never be a disadvantage. When a newer modality replaces, rather than supplements, an older one, the benefits are often more debatable.
That's interesting, most of the accounts I've heard were that the text mode stuff was vastly superior, because once you knew the interface you could type ahead regardless of how slowly it actually loaded. Are you referring to the difficulty of picking things up in the first place, or am I unaware of some other difficulty that it had?
* Poor availability of navigation options other than linear order.
* Poor availability of editing / correction / undo (and conversely, there often was an easy to hit (deliberately or accidentally) button that would erase everything on the screen so you could start over. Users sometimes trained themselves to use that for any correction, because it WAS effectively superior to other available correction methods).
As an anecdote, in one job, I encountered a text based application for parts inventory management in a garage. The only way to look up parts was to type their full, exact name (And in our country, mechanics were not necessarily solid speakers of the local language).
The programmer didn't see a problem with this, arguing that his design promoted enhanced literacy among his users…
This is a false dichotomy. A GUI app can still provide full keyboard navigation - indeed, all the UX guidelines I can think of require it, and did so back in 90s. And when they do, you can also just type ahead, generally speaking.
In early 00s, I did a GUI (Windows Forms) line-of-business app for a shop that was using an old TUI app written in FoxPro for their other stuff. The people who were doing data entry on that were all using the keyboard pretty much all the time. When they started using the GUI app, they kept using the keyboard - and I didn't even have to do anything special to enable it, just make sure that tab-index is correct and that all widgets have hotkeys.
I'm sure GUIs can provide keyboard navigation and such, but it's not clear to me that this was common. Unfortunately, I'm working from anecdotes, so I can't tell, certainly not this far in the future, what the relative average quality was.
This was very common. For starters, pretty much every UI toolkit provided keyboard navigation between widgets with no need to do anything special. The common QoI problem there was that developers often didn't set tab-index correctly, so if you tabbed through the widgets, the order would be wrong (i.e. not following the screen layout). Visual designers often provided linters for that.
Then there were the shortcuts to immediately activate the specific label, button etc. On Windows, these showed up as underlined letters up until XP (in XP and later, you have to press Alt to see them). Again, as a QoI matter, devs could forget to put them in - but it was really easy to do, and if you didn't, the lack of underlining was actually kinda noticeable. Most apps had them.
