Hacker News Reader

Comment by dale_glass | Hacker News Reader

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 "[==== ]"

View on HN

> Use actual pixels, it'll look prettier!

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.

What do you mean? Animating the terminal is totally possible!

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

> The only reason we don't have animation frameworks for the terminal is because it's not possible

https://nick-black.com/dankwiki/index.php/Notcurses

While I agree with your post in general, this is not true:

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

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.

> With animation I mean UI animation, like smooth opening of a menu etc.

But we definitely did have it in the 90s:

https://www.youtube.com/watch?v=2EebJ4dN37M

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.

I feel like we're in the extremes in both cases, where general customer interfaces are all super information sparse, and terminals are heavy on text.

Having more visual terminals and more text UIs elsewhere would be best of both worlds.

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

I mean mainly things like this:

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.

>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?

It's not like GUI apps don't exist.

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

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

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

Maybe the next gen of terminals that use structured data instead of dumb text could achieve that

We can kinda have that already, it's just non-standard and rarely used. Here's for instance neofetch with actual graphics:

https://i.imgur.com/fHdkkLn.png

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.

Reply on news.ycombinator.com