I really do like UIs that dump a lot of structured information instead of telling me a shorter but less informative message "for humans".
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.
On a related note, I wish more ecommerce apps would do english text dumps, rather than fancy 2 dimensional multi-coloured UIs where I need to remember where the date, order number, etc. are. E.g.
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.
Just like "security vs convenience", UIs are caught in the middle between two forces pulling them in two different directions. In one direction to provide all the information a power user could use, with dense information and everything available at once, and the other direction being only showing what's absolutely necessary in order to not overwhelm beginners/new users.
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.
> provide all the information a power user could use
> 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.
Yeah, maybe it's not perfect, nor am I saying there aren't exceptions.
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.
One important thing to remember - there are power user tools which those user prefer to use and like, and there are power user tools which are simply the only option which is available. A good test may be - can you take a power user tool, slightly but meaningfully improve it and then claim a market share with it? In the case of a Bloomberg terminal- you probably can't, because the value proposition is not the UI or keybinds or actions, but the content and the corporate sources and support behind it.
Yeah, I neglected to mention that there are necessary compromises, and Bloomberg Terminal is a great example. I’m not sure that product could serve its users’ needs without being dense and cluttered.
Two UIs will cost twice as much to design and build, but frankly, we have stdout and stderr today, you just don't see most GUI application developers making use of them.
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.
I think people in this discussion are missing the point of the article, which is accessibility, specifically to people using terminals with a screen reader. Visual organization is irrelevant if you can’t see it, and it’s equally irrelevant to the screen reader which just reads aloud all text in the window, expecting something approaching prose rather than {[]}# mess. Sadly I don’t think many authors of CLI software even consider that someone might use their programs with a screen reader, and I don’t think the converse is likely either.
While I sympathize with the needs of accessibility, personally I want to head in the complete opposite direction.
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 "[==== ]"
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.
"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.
With animation I mean UI animation, like smooth opening of a menu etc. That is obviously not possible because it would require a much higher resolution. That is generally the kind of animation I dislike as it almost always comes with no real benefit while slowing down user interactions.
Absolutely possible. There are DOS programs that did it, but the name escapes me right now.
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.
Again, I said "smooth" animation. Yes, it's kind of obvious that rendering movement is possible in the terminal as long as it can update the screen fast enough, but it feels pretty laggy at lower speeds because of the lack in precision.
When people implement animations on UI elements they do it because it feels fluid, that's why terminal text editors aren't known to have smooth scrolling for example.
>Give me a terminal with actual graphics already. Like why is htop drawing stuff with | characters? Use actual pixels, it'll look prettier!
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.
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.
>But what's the point of going through all the pain of rendering graphs in text?
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?
> "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?
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.
htop is not drawing things with "|" unless it has to. It's using the boxdrawing characters. If that's not pixel perfect at all scales, it's your terminals problem, not htop (quite a few terminals have custom code to render the box drawing characters exactly to ensure they still join up and look like the appropriate box elements at all scales).
If your terminal exposes an API screen readers could access, there's nothing stopping it from defining escapes to allow you to assign aria roles, etc. to spans of text.
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.
I actually really enjoy text UIs. I would like something similar to Vimperator or Pentadactyl to label keywords with numbers, perhaps in parentheses or square brackets so I can refer to things without typing them in. This is useful for identifiers which might be uuids, rather than type them in or use the mouse or tmux text selection to select and copy and paste, you can just refer to the numeric identifier.
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.
I'm a bit puzzled by first reading about problems with "graphicality" and "pseudo-graphics frenzy" and then getting an example with no graphics, no ANSI control sequences, no text-based table columns, nothing. The text is more structured than in a novel, but I don't see how that's bad, it seems appropriate for the context even if the screenreader stumbles over it.
I'm constantly annoyed by programs that try to make "fancy" terminal UIs, with a ton of formatting, colors, utilizing as many terminal features as they possibly can. It just seems like such a hack to me.
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.
I have the opposite sentiment; I grew up with DOS TUI and miss them dearly. Not all of them were great, but when the programmers focused on the UI experience, you got some really nice results. I do come from a "command line" culture, rather than a "terminal" culture, though; in particular, I don't understand why the command line is "not meant for fancy user interfaces". A "terminal" in the sense of the 60s might, but I don't care about that. I care about the system I have.
> I don't understand why the command line is "not meant for fancy user interfaces"
"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
Plenty of fancy user interfaces do not need to be graphical, but can still benefit from better textual presentation.
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.
There are a few key things that you get by targeting a terminal for your UI:
* 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.
They're trying to leverage the advantages the terminal brings:
- 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.
I think the main issue is with SSH. Remote console access is a lot faster and less resource intensive for servers than remote desktop, so htop and tmux really help for servers and sysadmins.
Otherwise yes, generally I think TUIs should be GUIs instead.
I like some fancy terminal UIs (e.g. lazygit), but what I like most about them is the keyboard navigation which could be replicated in a GUI, but is often not.
They also have some advantages - like painlessly working across a network with low lag.
Htop uses a huge number of terminal features. It uses color, vertical bars to make graphs, and you can move a cursor to select processes. So if htop is reasonable, what is an example of something not reasonable?
What? No. I can run these on a server and get the same UI as locally, which is great. As with everything else sometimes TUIs make sense, sometimes not. There are a lot of crappy GUIs out there as well, which would have been better served as CLI tools (in my subjective opinion).
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)
And I'm annoyed by programs that don't make full use of it, to the point where I e.g. use "grc" [1] to colorize the output of a lot of commands. I don't want to use "a real GUI framework" for it, because that is 1) way more complexity, 2) not network transparent enough (yes, I can use X; no it's not pleasant over a network with any kind of latency), 3) I often don't want "actual graphics" - I want something constrained to a grid and that I can cut and paste as text, 4) "a real GUI framework" would prevent me from further filtering and rewriting the output, the way I do with grc.
Nevertheless it probably is much easier (in terms of computational resources needed) to interpret pseudographical picture than to interpret a real graphical picture. This said we probably can put an LLM which would input a pseudographics-rich terminal UI and describe what's there in a meaningful and concise way. I' mot a huge fan of putting an AI into everything but this seems like a natural way to really help disabled people.
Surely "espeak" also struggles with the code leading to the debugger, no? This seems like a much larger problem than just the ui, and adding an LLM to the mix isn't going to fix anything.
(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.)
I'm glad the Rust compiler draws ASCII arrows and underlines code elements using the line below, so I'm not sure how an alternative would work there, but IDEs might offer more accessibility around compiler output.
"Word X is just made up, stop using it!" is an overabused sentiment, one I would say is overabundant among internet pedants. Maybe you are feeling an overwhelming urge to overcorrect grammar? Get over it.
Nah, I just skip an article that starts with a non-word like overabuse, as it is unlikely to teach me anything. Especially when the article is about the equivalence of two concepts.
"Overabuse" in this case represents a recognition of levels of "abuse", not a moral judgement of whether abuse is ever acceptable.
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.
The "over" prefix does actually imply a level of acceptable abuse, regardless of whether or not you consider this a moral judgement. Otherwise what would the prefix imply? It's inherently a comparison to some implicit degree of abuse.
A newspaper archive searchs finds it's been in use since the 1850's at least, and though common it has had brief surges in popularity.
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.
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.