undefined | Better HN

0 pointsint_19h3y ago0 comments

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.

0 comments

myth20183y ago

> 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_19hOP3y ago

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.

jabart3y ago

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.

j / k navigate · click thread line to collapse