Most active commenters
  • pjmlp(3)

←back to thread

320 points IroncladDev | 14 comments | | HN request time: 3.037s | source | bottom
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 #
1. 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 #
2. imiric ◴[] No.43671535[source]
That's great, but keyboard shortcuts are not exclusive to TUIs. GUIs can be just as powerful in that sense, and most advanced web apps support keyboard navigation. My objection is mainly to the claim that TUIs are beautiful, and to the effort of bringing their design to the web. But this is ultimately down to personal preferences, and others may disagree.
replies(3): >>43671589 #>>43672702 #>>43672924 #
3. santiagobasulto ◴[] No.43671589[source]
Yes, GUIs and Web interfaces can support keyboard navigation. But I have NEVER found one fully exploiting this. Linear (ticket tracking app) is maybe the only one that comes to mind as a good alternative, but nowhere close to the fluidity achieved by TUIs.

I think the reason is "limitation", if you have to design an app that CAN NOT use a Mouse, you'll be darn sure it'll work well with the keyboard.

4. 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 #
5. 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 #
6. pjmlp ◴[] No.43671926{3}[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 #
7. maccard ◴[] No.43672519{3}[source]
The bottleneck with Skyscanner isn’t not being able to enter the dates without moving my hands, it’s waiting 30-50 seconds for all the flight options to appear, and trying to figure out “which ones are actually flights with the airplane and not third party resellers”.

Similarly with IDEs and programming - saving 0.5-2 seconds for 10-20 operations isn’t my bottleneck once I’ve decided to do the thing; waiting for the corporate antivirus to scan the chrome executable that has self updates since it last saw it, plus the VPN timeout because I haven’t logged into a corp site in 3 hours is.

Besides, visual tools can and do have very powerful shortcuts. ‘Make run’ takes longer to type than pressing F5 does, in visual studio. Photoshop, Maya, Nuke, ProTools, Final Cut, even Unity/Unreal are all graphical tools that have powerful widely used keyboard shortcuts.

8. graemep ◴[] No.43672693[source]
I saw similar in the 90s in a bank branch that was still on an old system. People who new it were very, very fast.
9. graemep ◴[] No.43672702[source]
Its true in theory, but it does not work well in practice because:

1. Developers have to make an extra effort (and require time) to do it right 2. People are much less likely to learn the keyboard shortcuts

If you designed a GUI to be keyboard first then it might work as you say, but I cannot think of any real life examples of that. I think people need to TUI look to push them to use keyboards.

replies(1): >>43716262 #
10. trollied ◴[] No.43672924[source]
You’re correct that modern web apps support keyboard shortcuts just fine. Unfortunately the reality of it is that the modern web is bogged down by the mess that is npm modules, react etc, and the majority of web apps are slow. Oldschool terminal apps you can just type away, and you know your keystrokes will just happen. The modern web? Urgh.

Don’t get me wrong, you can do it right, but most don’t bother with non- functional requirements “this should take 5ms” etc, so you just end up with pointless animations and transitions that stop useful work being done. This is often simple things like the tab order being wrong, or an AJAX request blocking the next thing you want to do.

11. nikau ◴[] No.43677951{4}[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 #
12. pjmlp ◴[] No.43679121{5}[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 #
13. nikau ◴[] No.43679416{6}[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.

14. queenkjuul ◴[] No.43716262{3}[source]
Every graphical PoS system i used in retail was a keyboard-first GUI