Text UIs != Terminal UIs
aartaka.me
aartaka.me
In many cases, I wish UIs in general would be more verbose, utilizing bold text and underlined text to emphasize the most important detail, such as "invalid argument...". I may still want to know which thread, i may want to know its address / tid, I may want to know which scope, which file, the context (caller, callee), etc.
I fully get that a lot of interfaces could be more human-friendly, but I'm not sure I would, as a developer building tools for other developers, focus on lower information density.
Lately, a lot of the stuff built towards developers have started to slant in the direction of not being made for power users and only exposing the necessary information, as it seems the new "developer tooling startups" have started to take cues from typical startup product design, for better or worse.
It seems to me most products today are not considering which of these directions to aim for, so you get some strange amalgamation between the two where neither groups are happy because it's not right to them, and product owners continue to change the UI to try to make everyone happy, not realizing they end up just serving the lowest common denominator.
As a developer/power user, if you let me configure your app with a dotfile that I can keep in my git repo, and you spit out useful info via stdout/stderr when I run your app via the terminal... in many use cases I'm happy as a clam to be honest. In fact one reason I tend to gravitate toward open source apps is because they tend to be more likely to do this, what with their users often also being their developers.
> not overwhelm beginners/new users
This isn’t the right distinction, IMO. I’m decisively a “power user”, but I hate high-density UI for the same reason I don’t leave all my belongings out in the open: it’s cluttered. Clutter can be stressful and tiring.
I guess a good example is Bloomberg Terminal vs whatever investments interface your bank gives you.
The latter typically follows the modern design standards of lots of spacing everywhere, using easier to understand terminology and such, while the Bloomberg Terminal is almost straight opposite, cram as much information in as possible, everything available via keyboard shortcuts, industry terms everywhere, favoring quick action and assuming the user mostly knows what they're doing.
Both products are built with two different users in mind. I guess the point I was trying to make in the parent comment is that trouble comes when you don't explicitly aim for one of them.
Also, clutter/high-density UI isn't the only distinction between the two extremes, also the amount of power the user gets, how many safety features there are, how easy things can be found, how things are explained and more, is also impacted by this.
You ordered a Pepperoni Pizza from Pizza Place for $14.99.
Joseph has picked it up.
It is due to arrive at your Home (5th Street) at 7.45pm.
[Call] or [Message] Joseph.
Give me a terminal with actual graphics already. Like why is htop drawing stuff with | characters? Use actual pixels, it'll look prettier! We do actually have some capability to do terminal graphics with for instance kitty, but pretty much nothing uses it. But it can be done, example: https://i.imgur.com/fHdkkLn.png
Done smartly, it could actually be more accessible. If we can somehow encode the knowledge "this graphic here is a progress bar at 30%", then we could have much more sensible output on TTS than for "[==== ]"
Having more visual terminals and more text UIs elsewhere would be best of both worlds.
No, thanks. My problem with such ideas is not the feature itself but the fact that UI tooling always aims to make use of the medium's full potential, and applications then always follow suit. The only reason we don't have animation frameworks for the terminal is because it's not possible, and I'd like it to stay that way.
More accessibility would be great but you don't need pixels for that either.
Better than images & pixels in the terminal would be a GUI platform that is as simple to use and integrate as the terminal and still feels natural to use with the keyboard. And has a toggle for animations.
This. What I'd really like is some sort of simple API/structured data standard that tools could implement and then a "generic technical UI" which can automatically generate a UI for that tool. (the UI doesn't have to be pretty or fancy, as long as it lets me quickly and effectively make use of the tools).
I think REST endpoints with an OpenAPI definition that automatically lets you generate an HTML documentation with built-in API client goes a bit into that direction. As did Microsoft's idea of "commandlets" I believe. As, actually, did HTML+HTTP in its original inception. However, so far all of those massively fall short in the "allow effective use of the tool" metric: For actual work, it's still way faster and more convenient to make a REST call via curl (once you figured out how to assemble the call!) - than to click around in the OpenAPI client. But maybe some future tool/standard could bring something better to the table here.
> we don't have animation frameworks for the terminal is because it's not possible
We've had AAlib for 3 decades already: https://en.wikipedia.org/wiki/AAlib - and it's not the only game in town.
But things like smoothly opening a menu are doable by just adding line by line, and dialogs can be animated by doing an animation that expands a window from the center.
But we definitely did have it in the 90s:
But there's a bit of a chicken and egg problem there - you need a terminal to expose it, and a screen reader to support it before there's any benefit for any applications in adding it.
One way of pushing some support for that, though, might be that if terminal apps annotates their output, it also opens the door for selectively letting users override presentation of it.
That is exactly what we want to avoid.
It begins with looking "prettier" and ends with "terminal apps" which 20 acres of whitespace around elements, and follow whatever the design fashion of the day is...
And of course UX designers and wannabees get involved, and, it being much easier to bikeshed than code, our cli apps get redesigned every year like Gnome/KDE.
https://github.com/aristocratos/btop/blob/main/Img/alt.png
Great work, it looks amazing! But what's the point of going through all the pain of rendering graphs in text? At that point, give me an actual graph. The code will be less messy and the information display will be better.
Embracing the curses interface constraints and limiting yourself on purpose to express just what you need to show - as opposed to getting sidetracked by the billions of possibilities of things to render and the shiny graphics?
"This cpu is ~80% this is ~25% load" shown with representative bars for a quick visual gauging of the machine's state at a glance. Would it give it any more benefit it it had nice ticks, and fine gradations, and fancy rendering, so that you could tell 78% vs 80% more easily?
It's not like GUI apps don't exist.
Yes. For instance the more cores you have the less room there is to draw a sensible graph, and we're up to 256 threads already. Even less enormous machines are already at the point where text is constaining.
> It's not like GUI apps don't exist.
Yeah, but SSH is great and not everything has good remote management. And I want the command line to keep up, not to be the better than nothing option.
Yes, but by doing what you suggest it wont "keep up". It would be turned into an alternate delivery mechanism for GUI apps.
I want the command line to be the command line. With text, and, at most, curses.
The output for kubectl is text based output table, not a TUI. So it's a really important text format for user interaction.
I have had the idea of a text stream format that configures a terminal UI, so it could be used a bit like fzf and selections can be made with arrow keys.
In this design, your app would be decoupled from the UI framework (ncurses or Textual, your app is just printf), and you just output a special text format that configures collections which are mapped to portlets in the screen. You can use code similar to what tmux and screen does to arrange the portlets to different parts of the screen.
The terminal IS NOT meant for fancy user interfaces, stop abusing it for that. Use a real GUI framework that has actual graphics instead of character cells.
The question is where to draw the line, I believe things like htop, tmux etc are reasonable, so it's hard to say whether a particular program is "abusing" the terminal.
"command line" is a different term from a "terminal", but the reason why it's not great for graphical UIs is that character cells are a bad abstraction for it, people just keep adding more and more features/extensions to terminals to compensate for it, which isn't a good direction at all
As for "features", there are very few features in modern terminals that affect display that weren't either present in "actual" terminal hardware several decades ago or are spiritual successors to that. E.g. displaying images in terminals has been a thing since at least 1981, yet a whole lot of terminals haven't supported it until it started getting a bit of a resurgence lately.
I don't agree it's not a good direction - GUI's are way too complex for a whole lot of applications, where terminals allow you to output quite advanced things with a handful of lines of code and no external dependencies.
If there was a push to make GUI protocols simpler (instead of far more work, as with Wayland) for trivial programs to output, I might be more open to this view.
Otherwise yes, generally I think TUIs should be GUIs instead.
- Portable API.
- A directory context, stack based workflow, in which unrelated programs are be executed together.
While working through the major disadvantages 'traditional' terminal apps have:
- Lack of visual hints, memory prompts, discoverability in the UI design.
Those disadvantages aren't a problem for everyone, have stood in awe of many a terminal wizard as they fly through tasks that would take me much longer, terminal or not - and if that's you, you have my envy.
But for me, my brain just isn't wired to be able to quickly recall all the flags, shortcuts, workflows, and other nuances of 30+ terminal apps, of varying usage frequency.
That's why I like k9s as alternative to kubectl, it guides me, reminds me. Could 'k9s' be a native GUI? Of course, but it probably wouldn't exist if it had to be.
So I hope there's room for both!
They also have some advantages - like painlessly working across a network with low lag.
* Remote desktop forwarding through tmux, ssh, mosh, etc
* Instrumentation of your UI - simply replay the input
* Screen recording with asciinema
Not to mention that you can target the exact same UI framework across Linux, Mac, Windows, and more.
On the other hand, it doesn't play well with your desktop environment. Taken to an extreme - if all your daily drivers are in the terminal:
* You can't easily tell them apart because they all have the same icon
* Some of those bells and whistles might not be supported in all emulators - tmux and mosh are probably a good baseline.
* Accessibility support is lacking (TFA). This is probably more of a demand side problem than anything else though.
On the whole, it's a decent enough UI target for an inner platform on the level with the web - all we need now is Muon - a wrapper that includes a terminal emulator so you can write "native" terminal programs with their own icons.
And what is "IS NOT meant for fancy user interfaces" supposed to mean? (and what about various constraints back in the day as the actual reason for a data in/data out-only interface as opposed to "intent"?) I could argue that tmux is "fancy", since it is a multi-panel workspace, mirroring GUI capabilities, but apparently that's Ok according to you. So your conclusion seems to be that TUIs are actually ok in general - you just don't like bad/over designed interfaces (subjective terms, of course), which is understandable. Sorry, but I don't get your point. Bad interfaces are everywhere.
(I kind of like fancy TUIs when they make sense, to be honest, so there's that)
(Unless of course the debugger is being seen by a non-technical end-user, but that again seems like a failure to handle errors in a reasonable way than anything an LLM would solve.)
To the extent you're "right" that it's not going to be one, it's because its use appears to have faded away in recent years, not because it's not been in use.
For example, in mathematical notation this is the case.
Further, the term "abuse" is used both about transgressions against a person, where I agree that this concept would be offensive as well as to indicate going beyond a perceived normative use of something in a way that does not imply harm to anyone and that may or may not be acceptable to a given person in a given context.
E.g. "I abused this API to do X" implies I recognize that what I'm doing isn't the clean or intended use of it, but doesn't in itself imply that it's not acceptable (it could be unacceptable use, but it could also just not be the "proper" way of doing something).
"Overabuse" is a rarely used word, so I probably wouldn't use it myself, but anyone who quibbles over it because they "don't recognize acceptable forms of abuse" will already struggle with well-established long-standing use of "abuse" in English that is covered by primary dictionary definitions.
> Otherwise what would the prefix imply? It's inherently a comparison to some implicit degree of abuse.
You just answered your own question, and contradicted your initial assumption.