Hacker News Reader

Comment by bdavisx | Hacker News Reader

A GUI can be as effective as a TUI if it's designed to be 100% usable from a keyboard - the problem is very few applications take the time to do that design.

View on HN

Maybe in some cases. But largely, no, it really is not comparable. These TUI interfaces literally had 0 latency for any action. You could paste in text (from clipboard), with \t characters, and it would advance the input focus and could fill out an entire form with once paste action. There's a ton of real world cases where the browser is just too heavy to keep up with fast paced data entry.

I've never once seen an experienced user equal or gain efficiency when switching. It's always a loss even after months of acclimation.

It's totally possible to get this done with a web based SPA. Just get rid of all the fancy design, images, gradients, animations, and so on, and just focus on usability.

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).

Possible yes but there are properties of a TUI vs a GUI where the TUI encourages faster keyboard navigation because when they were common there was only keyboard navigation whereas a GUI comes with it's own upsides (discoverability been the big one).

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.

The real issue is, that modern UX design is often too focused on pretty looks, instead of productivity. It's still possible to make a highly productive UI look pretty, but the priority is often completely wrong.

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.

> The real issue is, that modern UX design is often too focused on pretty looks,

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 ?

I was just giving some examples, it being theoretically possible in SPA isn't really helpful given that nobody will implement it that way. You're basically living in theory.

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.

> nobody will implement it that way

This is not true. Smart companies do it exactly that way. It saves them a lot of money.

I've never seen a smart company then.

I have a hard time believing this. The medium impacts interaction.

Do you have concrete examples in mind that we can review?

The things I've worked on were custom tools for internal use. Built on top of existing systems, to improve productivity for specific workflows.

> It's totally possible to get this done with a web based SPA.

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 totally possible to get this done with a web based SPA.

Yeah, I guess I could say that before I tried rebinding ctrl-w and some of the Fx keys (like F12).

Sure, in a browser you can't use all the shortcuts, but still a lot. If you really need it, just wrap it in Electron, Tauri, or any other customizable browser.

You can sure do that, but you are basically implementing a terminal in a website.

Lol, no. You can still use different font sizes, traditional controls that can also be used with a mouse (for people who don't know the shortcuts yet). Also images are possible where they make sense.

While using very common web development stacks a lot of developers know how to deal with.

I give you different font sizes, but a mouse and images are available in the Terminal as well.

I think the fancy new terminals also allow you to change the font.

Fancy old terminals that I don't see in emulators.

Look at the era of teletext. Not exactly multiple typefaces, but you could express wide, compressed, italic, bold and all colors.

My experience has always been that TUIs and Terminal emulators these days have massive snags with how they handle control codes and inputs. Pasting into a terminal is a crapshoot of “what on earth is it going to spew back at me”.

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.

That is not unique to TUIs, but also possible in GUIs where the developers care, and in some games (try the GUI ("tiles") version of Brogue). You can definitely make a GUI that updates in an instant and be fully keyboard-driven, even if that may have been more common last century.

We’re comparing TUI with web browsers for good reason. I don’t see any reason to add game engines to that debate. I have never seen a business client move any application from a TUI to a Unity based UI. I’ve never even heard of anyone considering a game engine in the architecture of a business application. So what you’re saying may well be true but it’s akin to a rare mythical creature, does it even exist?

Hold my beer.

I'm gonna go tell the building manager that people would like our app better and we can save on platform costs by hiring one Unity developer.

That was not what I tried to say. Brogue, like other similar games, can be played in a TUI mode, in the terminal, or with a GUI. Same game, just different UI implementations, and both tend to be about equally laggy, or usually the GUI version is probably less laggy, since you can just blit glyphs without the overhead of terminal escape codes etc to draw the same symbols in the TUI. And Brogue just uses SDL, not a game engine, so that is not relevant at all.

But your snarky reply is probably also wrong anyway, since I would be surprised if there is no business software made using game engines. Tesla is known to have used (but not anymore?) Godot for making GUIs for their in-car displays for instance. I have bought applications (not games) made using both Godot and Unity. Not saying it would be a great idea, in general, to use those engines for business applications, but people are not known for always using the best possible tools, are they, and it certainly would work in theory?

Not very familiar with Unity, but Godot has very nice GUI widgets. Same style of WYSIWYG editor like old Visual Basic or Delphi really. You drag widgets to place them on the screen, set properties, add scripts to react to different events. The entire Godot IDE itself, a very non-trivial application, is implemented using Godot's own GUI framework.

https://docs.godotengine.org/en/stable/tutorials/ui/index.ht...

The other thing that a TUI generally does that a GUI doesn't is that it lets you type ahead, you can drive it without looking at the screen.

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.

A large fraction of the entire point of a GUI is not being keyboard-centric.

No, that's only the Steve Jobs view. You might be grappling with Discoverability.

When IT was trying to sell everyone on WIMP GUI, the standard was WordPerfect. There, you had to memorize the functions of the F1-F12 keys, as well as their shifted (or Control) behavior. The only sure thing was that F1 was HELP.

We were looking for something better--but having no keyboard was the opposite extreme.

How do I implement type-ahead in Qt or GTK application?

Not specifically for those but I have to assume the pattern would work: you could intercept the keystrokes in a parent window or an overlay, then forward them to the correct child window once it's rendered.

So you implement a rendering system and an input queue on top of a drawing region. Sounds like you are implementing a Terminal emulator.

Reply on news.ycombinator.com