[myth2018]

In my country (Brazil) I sporadically meet people using TUI-based systems. Mostly COBOL but also a good amount of Clipper (or Harbour, maybe?).

I'm also aware of a couple of companies maintaining systems in Harbour and my parents use a web app written in Pascal -- I could tell by the error messages, which are extremely rare btw; the system is very stable, despite the frequent changes it goes through thanks to the tax-legislation mess we have here.

I started asking people about which type of system they prefer: those old dinosaurs or the good-looking, modern ones? 100% voted for the former. Why? "It's fast", they answer.

Some say it's because "they learned to work on those older systems and now are resisting to change". But this is simply false: even younger professionals, who grew using GUIs and web apps, prefer TUIs when it comes to get stuff done.

Such interfaces are also easier to develop. Then, I believe it would be a win-win if TUIs were widely readopted: happier users, systems cheaper to design, build and test.

But trends are so hard to change...

[int_19h]

It would be more interesting to dive down and figure out what exactly the users like more about TUI. Just speed alone can't be it, because e.g. WinXP-era UI is blazing fast on modern hardware (and was plenty fast even back then). And if we know what it is, we can build GUIs that are just as efficient, but that also offer e.g. better text rendering etc compared to TUI.

I once had an interesting experience migrating users from a TUI to a GUI app, ~20 years ago. In that case, after watching them work for a while and asking some questions, the takeaway was that they really wanted the flow to be 100% keyboard-based. Which the GUI apps nominally provided (back then; less so these days), but all too often the correct tab order etc is ignored in practice, making it very difficult to use.

I made sure design the GUI with keyboard in mind, and that common patterns they've learned from TUI would still work. For example, the TUI had a textbox above a listbox, and it was common for users to press arrow-down to navigate from the textbox to the first item in the list, and arrow-up to navigate from the list back into the textbox. This isn't normal behavior for GUI, but I coded it in anyway.

[myth2018]

> It would be more interesting to dive down and figure out what exactly the users like more about TU

Indeed. When they say "it's fast", I don't read it simply as "the program is fast". They get their stuff done faster, and the program is simply a tool -- if further speed can be achieved with something else, so be it. It doesnt even need to be software.

However, I still think TUIs are in a better position due to lower development and maintainance costs. This can be achieved by GUI frameworks, for sure. But TUIs tend to be terser, and their natural limitations become an advantage when they make certain sorts of bullcrap (animations, for instance) undoable. I believe this contributes to long-term stability, as developers spend way less time dealing with useless requirements.

> the takeaway was that they really wanted the flow to be 100% keyboard-based

Good that you could draw such conclusion. I do think we should rely more on observation to find out what users need, as opposed to what they _say_ they need. I know this sounds condescending, but I dont mean that. I just believe thay it's hard for them to identify and verbalize some critical factors for their success and they need some mediation.

I also feel upset about the keyboard as a second-class citizen in modern systems. There's this UX design school of thought portraying users as creatures of extremely limited working memory, who can't even remember what they wanted when they clicked the option, and therefore need infantilized interfaces full of pictures and colorful buttons because they won't be able to memorize a handful of keyboard combinations

[int_19h]

You need to do both questions and observations, IMO, and iterate between the two. Answers give you hypotheses that can then be verified by observation; if just observing, small things can slip by if you don't know to watch for them in advance.

[jabart]

Most of the time the app really is fast. These old cobol apps have character limits per a screen for the amount of code you can use. Imagine each screen being like 200 lines of code with some raw storage behind the scenes. I had to performance tune a 3270 (mainframe) emulator once in c# and it took 2-3 weeks to get the c# app on a xeon processor to have to start waiting on the mainframe. Also nothing, ever, ever, timed out, ever.