←back to thread

320 points IroncladDev | 4 comments | | HN request time: 0s | source
Show context
imiric ◴[] No.43671000[source]
Ah, wonderful. It even mimics the empty rectangles when a font doesn't contain a glyph...

This is neat, but no, stop it. TUIs are an abomination of design that poorly mimic actually beautiful UIs. They look the way they do because of inherent constraints of the terminal, not because their authors particularly wanted them to look like that. So bringing that design language to a platform that does support rich UIs is artificially limiting what can be done on the web. It will also never truly have the same design as the terminal, unless you also want to avoid having any rich multimedia, interactivity, or use any web functionality introduced after 1995. At that point, your users would be better served by a text-only or Gemini site instead.

As an aside, I think TUIs are wrong in most cases. If you're building something like a text editor or process manager, sure, they have their place. Although even then I would argue that they shouldn't mimic the look and feel of GUIs, but be purpose-built for the app in question. But most terminal programs shouldn't use TUIs. They should accept command-line arguments to modify their behavior, run and do what the user asked, and then exit. This is how you make programs adaptable, composable, and scriptable. They can still be made interactive at runtime via a different e.g. "client" program, but forcing the user to manually interact with an interface that mimics GUIs is an awful experience.

replies(4): >>43671037 #>>43671146 #>>43671155 #>>43671324 #
santiagobasulto ◴[] No.43671324[source]
> TUIs are an abomination of design that poorly mimic actually beautiful UIs

My mother used to have an early "digital company" back in the 90s in Argentina. We are from a small town in the "Patagonia region"[0] and there was only 1 programmer in the whole town. The guy was a huge nerd that had spent some time studying in Buenos Aires.

Long story short, my mother hired this kid to build software for him. This is around 1992 so it was all DOS.

This guy built a full TUI software with CRUD operation, reporting, "cron jobs" (some stuff that I never understood but would run every night), printing, etc.

Until this day I remember the people working at my mother's company how they just FLEW over the software. It was all keyboard and hotkeys. They'd just go back and forth, print stuff, enter data, connect with the Fax machine, all with their keyboard in this black screen full of green, white and orange glyphs.

I NEVER found any other software that is SO powerful and efficient and user friendly as TUIs.

[0] The "true" Patagonia region in the East of Arg.

replies(3): >>43671535 #>>43671684 #>>43672693 #
pjmlp ◴[] No.43671684[source]
Except my laptop isn't something bound to 1 MB RAM, with luck having a VGA card able to do 256 colors, running at about 20 MHz with turbo button and a whooping 40 MB hard drive.
replies(1): >>43671843 #
jen729w ◴[] No.43671843[source]
Except it’s quicker to navigate an interface using keystrokes than it is using a mouse regardless of how much RAM you’ve got.

Compare a proficient travel agent who speaks Sabre to you booking a flight on Skyscanner. They’d whup your ass.

https://youtube.com/watch?v=G8n0_3t-EhI&pp=ygUPc2FicmUgY2xpI...

replies(2): >>43671926 #>>43672519 #
1. pjmlp ◴[] No.43671926[source]
GUIs have keyboard shortcuts for decades, blame the developer that wasn't up to their stuff, not providing keyboard navigation.

Heck, there are even Win32 and X Windows APIs designed with the exact purpose for keyboard navigation and shortcuts.

Maybe instead of doing TUIs one should better spend their time learning the tools of their craft.

Skyscanner failure to adopt such tooling, which browser also have due to accessibility requirements, has nothing to do with technical issues, all about skill and willingness where to spend budget.

replies(1): >>43677951 #
2. nikau ◴[] No.43677951[source]
The difference is keystroke buffering - the agent in sabre can type ahead while the system is processing a transaction, the web/gui user has to wait for each screen to load.
replies(1): >>43679121 #
3. pjmlp ◴[] No.43679121[source]
First of all, keyboards have limited size buffers, secondly the same is available on GUIs, and I go back to mastering the craft and OS APIs.

https://learn.microsoft.com/en-us/windows/win32/inputdev/key...

https://tronche.com/gui/x/xlib/events/keyboard-pointer/keybo...

replies(1): >>43679416 #
4. nikau ◴[] No.43679416{3}[source]
Its not the hardware keyboard buffer, its the tty readline or equivalent buffer which ends up being a like a stack of commands for the app which pops off the next buffered line after the previous line has processed.

Although I'm sure its technically possible to do it, in reality no gui apps work that way and extra keystrokes end up lost while web forms refresh or a 2 tier app is waiting for the DB to respond.