1. Democracy is about access; make sure everyone has access to your software. 2. The keyboard allows folks with disabilities and power users to fly through your website/app… that being said… the second a tab is off, the person with a disability flies into a wall.

Part of the blame lands on the shoulders of popular UI frameworks (or in the case of those choosing to eschew use of such, the developers who made that choice). The older frameworks tend to make this fairly easy; for example, in Cocoa/AppKit (Mac native UI framework), one can pretty easily wire up their entire UI for proper keyboard navigation entirely visually (mostly just consists of connecting nextKeyView outlet between controls to produce a logical chain to tab-focus through). Defining key shortcuts is also simple; add a menu item for a command and set its corresponding shortcut (which in turn allows the user to rebind the shortcut in System Settings at will).

That sort of design has fallen out of favor with newer frameworks, unfortunately. The new preferred style seems to be a wireframe that the dev chooses which parts fill in, and often only the barest of essentials makes the cut.

HN's insistence on acting like all users are Arch Linux efficiency perfectionist hacker types is painfully corny.

(This reads harsher than I intended. Sorry about that. I love Arch Linux people. It's just think it's no less noble to serve the average Joe than to create the perfect tool for power users.)

When a software is created for the terminal, it can expect the users to know these certain shortcuts. But this cannot be assured for GUI.

For example, in Firefox, trying to save a file when a file by that name already exists, you get a "Cancel" or "Replace" prompt and you can "Cancel" by pressing return, but if you want to "Replace", you apparently HAVE to use mouse or trackpad!?!

For a lot of people this is a recognizable pattern. Switch window, select element, scroll down, then snap back to the very top. The keyboard commands above should do the same thing no matter if it's your text editor or your web browser. People should know these are going to work regardless of what they're using. Because these aren't key commands going to the program, these are key commands going to the operating system. The program shouldn't be able to arbitrarily choose whether it abides by these. Consistency is important not only for speed, but for human understanding and capability. If every door had a different way of opening it such as drawing a series of lines or tapping a certain rhythm or belching thirty feet away people would be mentally taxed discovering that particular door's interfacing method, and common tools would not be able to help those who couldn't find the interface or use it because of disability or differing ability. It's only doors with extremely specialized designs like blast doors that have an unusual interface and interfacing method, because they're designed to do one very specific thing that lies far outside of common use cases. Your chatroom program, image viewer, or archive unpacker is not a blast door. Put a door handle on it where everyone expects it to be.

It would be really great to have some GUI frameworks for the common platforms (including web!) designed to do this and have some opinions on common shortcuts for common actions so we can standardize on something.

it was a webapp framework, but... all browsing/listing screens included row ids and a focused text box- so that typing the row id and enter would select. all action buttons had an underline to signify which ctrl-shift hotkey triggered them. all edit screens defaulted focus to the first editable textbox and at no time was the mouse actually necessary. finally, load times were optimized to target 75ms.

amusingly, the user feedback was "the keyboard control is pretty good but can you please make it faster."

what i thought was chrome ended up being critical to the users not being miserable.

But the broader trend in GUI apps has been to target marketshare not deliver productivity for keyboard users. Back in the 80s and 90s Photoshop, Illustrator etc. became the powerhouses they are today because they focused on allowing professionals to be extremely efficient using their array of powerful keyboard shortcuts. In 2026 when software companies are dying of KPItis scoring their product management on creating compelling subscription models to hook customers, attention to actually delivering productivity for keyboard users is often an after thought. Mobile apps don't have keyboard shortcuts and desktop apps seem to increasingly be treated as as the narrow "edge case" with only a few hundred million target users versus the billions available on mobile devices. It's an opportunity for those who get serious about delivering value by leveraging the power of keyboard shortcuts to make their GUIs highly productive and comprehensively usable from the keyboard. For all their faults, Microsoft got this right with VSCode.

- New *G*ame - *S*ettings - *Q*uit

Ideally keys should be centered around an area of the keyboard and not just the first letter.

Instead they should be engineered in a way that allows users to bypass those developers in a (at least) framework-consistent way as there will never be a time when they collectively become "keyboard-wise".

I just prefer TUIs, I think if you prefer GUIs you should very much use them and ask for more of them, but if you prefer TUIs please do use those too. I could go into all the reasons I prefer TUIs but this is a HN comment not a manifesto.

Please just use and develop what you prefer.

Something to consider is a terminal that has keyboard navigation of its own. Through a terminal shortcut, I can move the cursor at will and copy any text at all, even if it's part of the interface of a TUI. If I want to copy the filepath of the file I'm working on in vim to then use in a shell, for example, it takes like 5 keys to copy it straight off vim's statusbar. A graphical text editor can display the filepath in a tab or something, but I can't copy the text off the tab.

I don't know if I'm alone in this, but it's very frustrating to want a piece text, see it in front of you, and you can't copy it because the developer for one reason or another didn't implement copying of that text, so you have to type it out even if it's right there.

Sometimes it seems on purpose too. For example, when a game on Steam gets updated terms of use, you get presented with a window showing the terms, but you can't copy them to save them. It's like the purpose is to just accept and forget the terms. A TUI can't prevent the user from copying text by its very nature.

Any terminal can implement this kind of arbitrary-text keyboard navigation on its own and have it work for all TUIs. Were e.g. GTK to implement something like this, it would only work for GTK apps, not for all GUI apps. This is exclusive of TUIs because TUIs are text-driven while GUIs are pixel-driven.

I wish this was a default, but also that there was more of a standard to navigate UIs. That's why I really like vimium and other similar extensions, it's following the vi logic across websites, rather than having to learn everyone's idea of how to navigate.

"It should be possible to move around and interact with every part of your user interface using the keyboard."

Yes, finally. It works both ways; when I have hold of the mouse, I don't want to reach for the keyboard, and vice versa. Windows has had this problem for ages, and probably always will. There are some workarounds, "ctrl-esc" (I do this all the time) and "windows-button", but some of them require really jumping through hoops.

One of my main issues with KDE is that the default keybindings for desktop operations feel like they were designed by people who don't navigate their desktop with a keyboard.

Then there are little things like in Gnome the screenshot implicitly copies to the clipboard, while in KDE you have to click the copy button. There are just little points of friction I experience in KDE that make me yearn for Gnome's workflow. I think my ideal world I would have a KDE desktop that used all the Gnome shortcuts, and worked more like Gnome.

It occurred to me that this is a wonderful way to design software: you immediately know the keyboard shortcuts because you’re already looking at them. I’m working on taking what I’ve built for the qwerty midi keyboard controller (which is built on hammerspoon) and making it just a generic interface for any kind of app.

If the end goal is navigating and controlling the app via keyboard shortcuts, so why not bake that into the design of the GUI itself?

My project if you’re curious: https://github.com/mattdanielmurphy/qwerty-midi-hammerspoon

So sure, add keyboard support to the GUIs. That's always a good thing. Just make sure they're also as responsive as in a TUI. Dialogs should appear instantly, etc.

The other headaches I've had with GUIs (in Linux) is the appearance can change if an underlying library changes. Even if I haven't upgraded the SW, if I upgrade one of the toolkits it relies on the app's appearance and behavior can change.

Somehow this is never an issue with TUIs.

The folks who learn how to use it well navigate through it faster than the system can process their inputs.

The new system has lots of fancy GUI, but is slower, and the folks used to their shortcuts hate it. But it's so much faster to train people to use.

Ideally all GUIs/TUIs are usable with keyboard and mouse independently.

A good example of this is when you have a fancy keyboard-driven workflow yet you can't even do the most trivial task without placing two hands on your keyboard. Sometimes I just want to reach over and do it with one hand on the trackpad.

Where appropriate, the labeling of fields and so forth should be such that it will work for a screen reader.

Often, the expedient option is to use an HTML front-end so that one can off-load most of that to the user's selection of web-browser (and where possible, things should be engineered so that Lynx is a valid option).

That said, I use OneNote and Macromedia Freehand and so forth w/ a stylus --- horses for courses.

And it's auto generated from the UI code. It still surprises me how many people just prefer the mouse anyway, though. But the option is there!

[0] https://sidewaysdata.com

I've found that that itch is pretty much entirely solved by Sway (especially since it supports modal navigation, which I have become pretty addicted to), but honestly I actually found Gnome Shell (as of about ~2 years ago) pretty keyboard friendly. Hitting the Windows key [1] brings up the global search and that worked to launch stuff, moving between workspaces worked ok. I know it's popular to hate on Gnome 3 and beyond but honestly I rather liked it.

[1] Or whatever the official name for it is; it's a Windows logo on my keyboard.

And it should also be easy to make the keyboard controls customizable.

When I developed KeenWrite[2] over 12 years ago, I chose JavaFX because it was (a) bundled with Java; and (b) ran on Linux, Mac, and Windows. JavaFX was later ripped out of Java, to my chagrin, forcing a number of technical contortions.

[1]: Not free on Windows due to Microsoft's $500 cert signing process.

[2]: https://keenwrite.com/

Far beyond mouse, stylus wich are themselves infinitely superior to touchscreen.

I also can't cleanly nest and stack GUI applications in tmux like I can with TUI programs. I think GUIs are for the most part tailored towards non-power users unless its something like video editing or 3d modeling that is aimed more towards professionals

[0] https://vimium.github.io

(we can lie and say that this is to support AI, in actuality it's to have proper programmatic automation and support for custom interfaces instead of GUI apps being black boxes)

I move much faster when I don't have to take my hands off the keys to nudge the rat.

However, I don't think my preference for TUIs is about my efficiency. The most important reason I love TUIs is that they generally only have a base set of features needed to get the job done. Most GUIs go off the rails, implementing features for use cases few people have. TUIs tend to be small, fast, and focus on a small use case.

So even though I started out claiming I love TUIs, what I really love is small software: CLI > TUI > GUI.

This way I can quickly repeat an action from the past. I get a history of commands inserted. _And_ I can bind my own keyboard shortcuts if necessary. TUI and GUI do not meet this level of platform independence.

If a tool is TUI only I will not adapt it. That's not the case with a GUI, though.

My experience is that while it's awesome to have really deep keyboard-driven experience, it can't _only_ be that. You need some graphical controls to help guide users.

Also a lot of webpages have it already built in, by pressing "?" they show a nice overlay. For example github and gmail have it.

For github I still ended up adding a quite a few more shortcuts.

Same thing I hear from everyone.

"You can't compromise on UX" - UX experts.

"You can't compromise on security" - Security experts.

"You can't compromise on Accessibility" - a11y experts.

We gotta make trade-offs, and I gotta get my thing shipped (for me I learn toward security for my service)

I still haven't found generic solutions to selecting and copy-pasting text using the keyboard only though, when the text is not in a textbox/area.

I had used a vim-like plugin in firefox that let you do that somewhat, but nothing OS level.

Love it.

Even crude AS400 days keyboard UIs were beyond nice. But then if people want to try and replicate emacs keymaps or vi command composition, better for the dozens of us. ^^

Bitwarden used to be keyboard friendly, but recent updates have removed those functions for reasons I can’t understand.

Like anything else in life, I think there's no single answer to this.

But for people interested in seeing the difference between mouse-driven vs keyboard-driven flows while web browsing, check out the Vimium extension. It made my sentiments very much favour keyboard-driven workflows

I would love a return to function keys. You get 12, make 'em count.

Hacker browser: allows to navigate browsers without ever needing to use the mouse.

I highly recommend it, it's such a productivity booster

For me personally it goes I like TUI/CMD for things I use as a daily driver, I know what I want to accomplish I know exactly what movements to do and clicking GUI items is just too slow.

Then there are GUI things that I don't use that often I need some kind of map, I don't to "read the fucking manual" every 3 months when I use it and I barely remember, but if I see it in GUI my memory will kick in. It also works for most new things better than TUI/CMD because for a new tool I don't want to invest my focus, I just want to find out how to be done with my things or just learn what it is, reading manual is not fastest way, fastest way is clicking around.

Nowadays we have 3rd mode namely "chat interface" I can just chat with whatever bot is integrated in the app or just chat with the bot to use the application for me. Command line utilities work like charm in that mode I can accomplish a lot by asking vague stuff to a bot that will make stuff for me in a ways I don't even have to know how or what.

But I do believe final form of interface is not "chat interface" alone. I do believe what Karpathy already outlined, that there will be specific interfaces for systems that will use GUI elements to make it clear for the user what is going on and will be faster to clear the information to the user instead of having user to read back text.

https://vimgolf.ai

Every action was keyboard first and only got mouse access later. Browsing by keyboard is not the browser's specific goal, but it was a feature from day 1!

[1] https://github.com/tayler/hww

It's a plugin that enables many keyboard shortcuts, so that you almost don't need to touch the mouse to navigate.

For me, it's such a productivity booster, especially the ability to navigate links without pointing at them to click

We basically designed the app as a TUI, but implemented mouse events so you can also drive it like a GUI.

When we hit the limits of the terminal (couldn’t register the app as a DWM window and throw up separate windowed modals etc) we forked and extended ghosttty.

Now it also supports mouse hover events, DWM popups, and a bunch of other good stuff. We plan to add icons next.

Yes. One problem with this argument in particular is that every TUI reinvents the wheel and designs its own schema.

To reinforce author's point, classic GUI frameworks and their guidelines actually provide hotkey schemas for common actions by default, and hot paths for quick interface traversal. They're universal and work by default, so in a lot of cases you don't even need to think about it, only extend it with your own actions. Absolutely nothing prevents you from doing the same in a TUI framework, but at this point the supposed simplicity and flexibility is lost.

New GUIs have other innovations, see for example Microsoft Ribbon that adopted link navigation from Vimperator to make classic toolbars discoverable, compact, accessible from the keyboard, and customizable - all at the same time! Unthinkable for any other UI paradigm.

It's incredible that after the Electron devastation era this unification and keyboard accessibility feels like some kind of lost art, and the perceived lack of keyboard driven GUIs is used a strawman to criticize GUI as a principle. Status quo of "most apps do X" is not the principle. It's also not true, essentially all good GUI apps are keyboard driven, and surely most professional/heavy user ones.

Design good interfaces, not bad ones, regardless of the paradigm. This is harder than it seems, and TUI is not a automatic substitute for your lack of this skill. If you think it is you will design a bad app, in the same way pixel art looks hideous when used to compensate for game designer's laziness. In fact, a lot of recent TUI apps I see are pure terminal cargo cult and are simply worse by being TUIs.

All UI's should be tab-able, but that's still a miserable experience for keyboard users. A keyboard-centric UI must provide instantly discoverable shortcuts. Possible methods:

- Put all elements on a grid so that they can be navigable with the keyboard. This is a significant restriction for the designer.

- Put keyboard shortcuts next to every button. It's not enough to put them in tooltips (*cough* Raycast). Common in games, but wastes space.

- Add a Command Palette. This is the easiest, but it requires mirroring every action, and is suboptimal when you have the same action for each item in a set.

When designing for technical users: all of the above please. But for average users it's less clear. I think there's still room for innovation, both on the software architecture and the UI side.

Interestingly, people have seen my GUI Emacs and commented "I didn't know you could get images in a terminal". Then I have to tell them it's not a terminal...

If I had to pick the absolute worst things about Teams, which is already one of the worst pieces of software ever made, it would be that it's not keyboard driven at all.

[0] https://news.ycombinator.com/item?id=49397145

I tend to deride UX/UI as almost a joke because it nearly never understands that fashion and science are different things.

This one gets it.

The way we are moving I believe soon we will be talking to the websites not just clicking or typing around...

Excel is the same way. I’ve been an excel power user as well as a Sheets power user and the latter just never managed to enable the level of speedy keyboard navigation Excel could. I can almost work blindfolded in Excel.

I mean these things aren't only highly usable, they're absolutely beautiful[2].

I'll also add that being keyboard driven helps people with disabilities AND makes things easier for AI agents. For exactly the same reason too. It's far easier for programs to hit key codes than try to determine pixel locations on a screen.

As a "power user" I still love TUIs but I also love good GUIs. Why should I be constantly lifting my hand to reach for the mouse? Though one of the big reasons I love living in the terminal is that it is extremely light weight. So many GUIs just eat up your system resources. I don't have that issue with TUIs. FFS, just compare 2 editors: (neo)vim vs Word. And before you say "Word does more" go ahead, add a hundred plugins to vim and then run that test again. vim will still win while also replacing VS Code, Obsidian, and a dozen other applications. The other big reason I love it is portability. Like the author mentions and is discussed in last week's thread, I can jump between machines (even through ssh!) and have no friction. I can have full control of my machine through ssh in a TUI while my mouse jitters while streaming the screen through either ssh or a VNC. I literally have to set different PS1s on my machines because otherwise there's no feedback telling me I'm connecting to something locally vs remotely.

But more importantly, let people do what they want. If you prefer to live in GUIs, do that. If you prefer to live in the terminal, do that. What's great about computers is the choice and flexibility. A big reason I'd support the OP here is that it exclusively adds to that. The ability to program computers and make them do what we, a random user and not an employee at some big tech company, want them to do is what made them take over the world. That even includes smart phones, where no two are alike (you all have different apps). Let's just make good products and let the best ideas flesh out. That's better than just arguing. I don't care if you use emacs, Atom, or program in fucking notepad++. You do you. But as devs we should add flexibility, not put people into boxes.

[0] https://i3wm.org/

[1] https://hypr.land/

[2] https://github.com/caelestia-dots/shell

We just need better, efficient and faster GUIs to put these TUIs to an end.

Take a look at gpgui and glaze leading on this. There should be no reason to use TUIs anymore.

It is time to move on from using this arcane technology from the 60s-70s.

https://gpui.rs/

https://glaze.app/

CLIs should be preferred when available. Learning them pays you back when it's time to write a script or pipe massive amounts of data.