[gf000]

But why?

You easily have 4k pixels, why use a tiny subset of those in a very inefficient way? We have proper hardware to make a bunch of these computations actually fast, and yet we should stuck with drawing relatively expensive text everywhere?

If you only care about the UX of TUIs, that I can stand behind (though mostly as a guideline, it doesn't fit every workflow), but you can do that with a proper GUI just as well.

[cfiggers]

> If you only care about the UX of TUIs, that I can stand behind

This is a confusing concession. Of course we love TUIs because of the UX, what other reason is there?

Constraint breeds consistency and consistency breeds coherence.

Take 1,000 random TUI designers and 1,000 random GUI designers and plot the variations between them (use any method you like)—the TUI designers will be more tightly clustered together because the TUI interface constrains what's reasonable.

Yes of course you CAN recreate TUI-like UX in a GUI, that's not the issue. People don't. In a TUI they must. I like that UX and like that if I seek out a TUI for whatever thing I want to do, I'm highly likely to find a UX that I enjoy. Whereas with GUIs it's a crapshoot. That's it.

[Someone]

> the TUI designers will be more tightly clustered together because the TUI interface constrains what's reasonable.

It constrains what’s possible, not what’s reasonable. For example, one could typically fit more text on a screen by compressing it, but most of the time, that’s not the reasonable thing to do.

I’m saying most of the time because of the existence of English Braille (https://en.wikipedia.org/wiki/English_Braille#System) which uses a compression scheme to compress frequently used words and character sequences such as ‘and’ and ‘ing’ shows that, if there is enough pressure to keep texts short, humans are willing to learn fairly idiosyncratic text compression schemes.

colorforth (https://en.wikipedia.org/wiki/ColorForth) is another, way less popular example. It uses color to shorten program source code.

One could also argue Unix, which uses a widely inconsistent ad-hoc compression scheme, writing “move” as “mv”, “copy” as “cp” or “cpy” (as in “strcpy”), etc. also shows that, but I think that would be a weaker argument.

[tolciho]

Try a 300 baud modem for a few months and good money says something terribly modern like Get-MrParameterCount would get compressed, a lot. Here's Bill Joy on the topic:

> No. It took a long time. It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. It was just barely fast enough. A 1200 baud modem was an upgrade. 1200 baud now is pretty slow. — "Bill Joy's greatest gift to man – the vi editor". The Register. 2003.

[gf000]

Come on, my previous phone had more bandwidth via a goddamn satellite, sending emergency infos.

[cfiggers]

> It constrains what’s possible, not what’s reasonable.

Why do you say "constrains what’s possible, not what’s reasonable", as though it's one and not the other? Does possibility conflict with reasonability? I would think it's not an either/or, it's a both/and.

The set of reasonable things is bounded by the set of possible things. So if the constraints of TUI design make certain things impossible, surely they make those same things unreasonable at the same time.

[gf000]

> Constraint breeds consistency and consistency breeds coherence.

In principle I would agree, but there are plenty of bad citizens among TUIs, it's absolutely not true that you can just start using one.

The same way there are excellent GUI applications like blender or intellij.

[Tanoc]

I'm sorry, excellent GUI with Blender? With the 2.5 interface things were ass backwards but you had a bunch of stuff you could do with only the mouse. With the 2.8 interface suddenly a bunch of stuff was hidden behind arcane key combinations, options disabled by default, and the loss of important visual data like the bounding box view and having both the UV and cursor coordinates in the same tab in the UV/image editor. No matter what the controls are different with every sub-window type, and interface panels flip from top to bottom and left to right for best readability without thought spared for consistency. There's a reason why someone can learn FL Studio in a few weeks, but take months or even over a year to become competent in Blender. I love it's jank and have been using it for eleven years, but I would never call the UI more than serviceable.

[majormajor]

The gap between vi and emacs is larger than that of any GUI program I use as regularly as I use either of those.

[pwinnski]

You could double or quadruple the number of pixels, and it wouldn't make any difference in how much information humans comprehend easily. You would be using more computing power and more memory to deliver the same amount of useful information less efficiently.

A "proper GUI" is rarely better than a well-designed TUI for communicating textual information, IMO. And the TUI constraints keep the failure-states for badly-designed UI tightly bound, unlike GUI constraints.

[gf000]

What about a map, or an image? We can surely agree that humans can take in a lot more information than a readable letter-grid allows, depending on the type of information.

[pwinnski]

Sure, of course sometimes an image conveys things better than a thousand words. But a very large percentage of what most people do with computers is primarily text, with more images in ads than useful content. By and large GUIs don't use images to convey information better, they just make text worse.

Modern terminal software supports displaying images, for what it's worth.

[gf000]

> Modern terminal software supports displaying images, for what it's worth.

In a worse, and dramatically overcomplicated way. Like it's kind of funny that largely the same people that is all for this supposed ultra minimalism would be celebrating a Rube Goldberg way of doing graphical interfaces? (Because in the end it is a graphical interface).

[pwinnski]

Sorry for the late response; it's been a busy week.

As a user, I don't care how complicated is the means of displaying images in a terminal session. I would only want to do so when I'm deep in a text-oriented context and there is a suddenly a need for an image. Not a chart or a graph, but an actual image. As a user, whatever contortions are necessary at that point are fine, because it's an unusual circumstance.

I hope that makes sense.

[citrin_ru]

One of TUI advantages over GUIs (including modern web sites) - all text can be selected/copied (you may need to use modifies in some TUI). It's a bit frustrating when GUI shows text but I cannot select and copy it.

[gf000]

Is that always beneficial? Do you ever want to select the text of a confirm button?

What if it just popped on top in a dialog to the content you were about to select?

[citrin_ru]

It's not only about buttons. A web-app of trading platform I use doesn't allow to copy-paste a fund name (both in web and in the mobile app). I don't think they disallow this intentionally, likely an artefact of GUI framework they use.

[cfiggers]

That's a very good point. I hadn't thought about that aspect before.

[zahlman]

The UX is the point.

When you are "drawing text everywhere", you end up not having to draw all that much text. 3d models have more and more polygons as graphics cards improve, but the 80x24 standard persists for terminals (and UX is better for it). And I'm not even that convinced of "relatively expensive". Grokking UTF-8 and finding grapheme cluster boundaries has a lot of business logic, but it isn't really that hard. And unless you're dealing with Indic or Arabic scripts that defy a reasonable monospace presentation, you can just cache the composed glyphs.

[krautsauer]

I'm curious: Do you have a nice set of GUI applications that come with the UX you'd expect of TUIs?

(I'm not actually sure what the UX of TUIs is I love so much. Relative simplicity / focus on core features? Uff, notepad wins this one on vim. Fast startup times? I use gomuks, that takes a minute for the initial sync. No mouse? Moving around in TUI text editors with hjkl is slow. I either jump where I want to go with search or use the mouse. Lightness over SSH/network is the only thing I can't come up with a counterexample for.)

[gf000]

Blender? There you have to use a mouse because you have a much much bigger state space to control.

Also, Intellij is perhaps a better example. You can fully control it via only the keyboard, yet no amount of plugins would turn (neo)vim into something as capable as it is. And it makes good use of the extra pixels - human can take in much more information than a text grid.