Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- The author makes an excellent point. There are too many poor Terminal UIs created just for the sake of having a TUI. Often these are not well constructed or lack sufficient thought to be effective/productive.
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.
by minimeow - Professional and power user software is always keyboard-oriented when it makes sense, I don't see it being ignored. Microsoft even addressed the criticism that Windows was largely not possible to use from keyboard, and massively improved it starting with Win10.
> But the broader trend in GUI apps has been to target marketshare not deliver productivity for keyboard users.
It's not a trend, it's a fallout of Electron being the default choice. Devs that use non-web UI frameworks are aware of keyboard navigation, or at least don't disrupt the builtin thing. And of course what devs that don't target power users tend to do is irrelevant to GUI vs TUI debate in the context of power users.
- Mildly off topic, but getting to the original GUI vs TUI debate: Speed can also be a factor. I've yet to find a GUI file manager that is better than Midnight Commander/Far. I think there are some graphical orthodox file managers, but I could never do things as quickly in them as I could in mc.
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.
by BeetleB - ALT+TAB, TAB, ↓, ↓, ↓, CTRL+HOME.
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.
by Tanoc - last time i built a crud app (oh maybe about 24 years ago) i made it a point to do this. i remember watching the payroll people fly through their terminal mode vax vms applications with such speed and dexterity that it would make any unix admin well versed in the art of the command line blush and it made me think "oh yeah, all these 90s point and click guis got it all wrong. if people are required to make heavy use of a system at work, they would prefer a learning curve followed by speed, comfort and dexterity over an easier learning curve that trades dexterity for discoverability."
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.
by a-dub - > While it’s true that if you randomly pick a GUI and a TUI application, the latter is more probable to be fully keyboard-driven, this does not tip the scale in favor of developing TUIs over GUIs3. What it does is highlight the inadequacies of keyboard navigation in many GUI applications.
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.
by jolmg - Any text-centric action will have a great advantage when done inside a terminal. I would think the equivalent in GUIs would be first-class OCR support on the compositor level. I am not informed about any progress made in that region to be honest, so I cannot tell how close we are (or not) to this.by ckardaris
- >A TUI can't prevent the user from copying text by its very nature.
Funny but I struggle with copying anything in most recent TUIs. Fancy padding or multiplexer borders and multiple lines of text? It breaks. Incomplete text in a spreadsheet column (tabiew) or a narrow internal window? It breaks. Ohmypi literally has a separate command to copy the prompt because of that, and another command to copy the model reply. TUI is just a poor choice here, it doesn't play well with formatted text like markdown, UI controls, long text, and so on. Terminals are good for CLI where the text is presented as lines, not TUI with spaced layout.
>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.
Terminal navigation has nothing to do with TUI navigation. Most TUI apps suffer from terrible NIH and end up with their own homegrown incompatible keyboard navigation schemas you need to learn every time. Of course absolutely nothing prevents you from writing a TUI framework with a common schema, at which point you will be at the mercy of the dev using this or that framework and schema, same as with GTK and Qt. None of this is unique to TUIs or GUIs.
- And it's not just for websites.
Analogy: the doorframe is of a standard width so that a wheelchair can get through. This means manufacturers can make equipment that will fit in your house without calling you first! You never have to worry you bought a new refrigerator that needs to be pulled into a hole in the roof because it won't fit through the door. You never have to worry about delivering food to a grocer because your hand truck and boxes will fit, and there is a ramp instead of oddly shaped stairs. Nobody needs to be in a wheelchair for this.
by timnetworks - The standard doorway width came before the standard wheelchair width
- Within built environment and industrial design that's termed universal design.
The canonical example is ramps on footpaths providing equivalent benefit to people in wheelchairs, parents with strollers, and commuters on bikes, scooters or skateboards. The door width example you provide is another perfect case.
There are many aspects of things we design and build where a small focus of accessibility for one group brings benefits to many.
by _kb - I agree but I think being usable by the keyboard isn't enough, because the shortcuts are often hard to discover and remember. I think the ideal is - like good TUIs - GUIs should put obvious hints on screen how to navigate via keyboard.
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.
by marklar423 - Agreed. Also, I would support everyone building off of vim principles. If keyboard bindings are somewhat consistent across applications, that would be really nice and there are already a bunch of options using vim bindings as a starting point, since they make intuitive sense once you've learned the "language" vim uses.by OroPla
- What does it mean though for a GUI to be keyboard-driven? The obvious way is that every action simply gets a shortcut assigned. My counter would be that that is not really keyboard-driven, but merely keyboard-compatible.There is the issue of discoverability. The best practice right now seems to display the shortcuts of buttons in tooltips, menu items, or when pressing a different shortcut. I’d content that buttons are a fundamental mismatch with keyboards. A keyboard driven UI shouldn’t have buttons. The issue is that genuinely keyboard driven UIs like CLI or TUI suffer terrible discoverability that being the reason that mouse driven UI exists in the first place. So can we have a keyboard-driven UI that is as intuitive as clicking with a mouse?by YmiYugy
- To me spacemacs nails the discoverability aspect through helm-Mx-fuzzy-matching and which-key
No clutter, but hints come as you stutter on what to press next
by dietr1ch - Yes, there should be a difference between keyboard accessible and driven.
Screen readers allow users to use their keyboards and other assistive devices to navigate websites and apps by tabbing through elements with extra controls and shortcuts to skip to regions, interact with elements and such.
To that degree I agree that all GUIs should be keyboard accessible.
This is obviously not what the original author had in mind, if he had to tab through every item in a web app he would probably get frustrated rather quickly. What he is imagining is like TUIs where all the interactions are through keyboard shortcuts and macros. These are not popular with the majority of users of modern day software, especially if the software is something that is used infrequently. I think we take for granted how component we, people who create software, are.
What has become more popular are interfaces that expose extra controls with a single key press, where the user can type to get the result they want. So instead of memorizing the keyboard shortcuts to dozens of actions, you can press something like Crl+K or / to summon a palette where you can search for the action.
by miguel-muniz - We know what it means for a GUI to be keyboard driven now:
Edit with Copilot[1]
Press the Copilot key on your keyboard[2] and type the thing you want to happen on your keyboard in English without leaving the home row. Forget the keyboard shortcuts, the path through the menus, the button location in the toolbar, the command name in the omnibar, the marketing name of the feature. Forget queueing up keyboard keys in an input buffer based on memorising which dialog will popup next, or the tab ordering on this or that screen. DWIM is back, and this time it still isn't determinstic, but it's the way we are going to manage ever-growing software features and task complexity and finally turn computing declarative instead of imperative.
"Move rows with dates from 2020 to the bottom of the table"
"Change the date format in the table from mm/dd/yyyy to yyyy-MM like 2026-Aug"
"Style the table with alternating dark/pale contrasting colour backgrounds and a different header row colour"
[1] https://support.microsoft.com/en-us/word/edit-with-copilot-i...
[2] https://blogs.windows.com/windowsexperience/2024/01/04/intro...
by jodrellblank - One of the reasons I loved learning Helix is that it shows you the list of possible next keypresses every time you press the first key in a combo. Amazing for discoverability. It even works for user defined shortcuts!by connicpu
- I think a first step would be a sane tab order, so you can easily navigate to a control using tab or cursor buttons. Second step are keyboard shortcuts.
I don't see why removing the buttons would be desirable. All that would do is to make the GUI unusable with the mouse and also make the discovery of the keyboard shortcuts much harder.
by xg15 - My logic for determining if a GUI is keyboard driven is pretty simple: if I can fire up a screen reader and completely drive your UI via the keyboard, then by definition your UI is keyboard-driven. If your app ever requires me to emulate mouse clicks to drive it, then it isn't entirely keyboard-driven and that should probably be fixed. This is even something that can be measured/tested for on platforms like Windows where you can both read the accessibility tree (which in itself is amazingly powerful particularly for testing) but you can also simulate arbitrary input.by ethin
- > A keyboard driven UI shouldn’t have buttons.
You mean because they're basically just in the way, right?
I know it's asking a bit much, but IMO advanced software ideally has
- buttons, pretty colors and icons where they make sense
- keyboard shortcuts for everything
- complete documentation that ships with it (sure "it's online anyway".. so find a way to automate putting what you have on the website into the release in a form that works offline)
- preferences to hide some or all buttons/toolbars, turn off the icons, and change some or all keyboard shortcuts. GUI is cool for that, text files are also cool. In other words, why not have everything? Maybe you could even compile a version that strips out all the stuff that can be turned off, or at least hardcodes some preferences, so the compiler can skip some things that are no longer called etc.
Not a must-have but nice-to-have: tooltips for all things and maybe advanced help, so you don't need the documentation as much, or not at all for simple use cases. But if the docs are complete, I think it's fine to keep the program and development process simpler by not duplicating that in tooltips. Don't go out of your way, unless you want to.
But as I said, that's for "advanced software", by which I mean software you spend a lot of time in. Browser, text editor, email client, file manager, graphics software, and so on. With simpler tools I'm usually just happy they exist.
by customguy - Yes, they should be discoverable. There are platform conventions for this: on Windows you'll see underlined letters; menus show you the shortcuts. Tab is a pretty much universal "move to next field" shortcut and I don't think that's particularly discoverable if you don't already know it.
There's nothing wrong with a keyboard driven UI having buttons as long as they advertise their key, though. That's one way discoverability is supposed to work. It means you can fall back to the mouse when it makes sense.
by regularfry - Power user experience is not the same thing as user experience in general. If you want to make the argument that all developer tooling should be keyboard-driven, fine, be my guest. But most people aren't willing to deal with the learning curve of keyboard-driven GUIs, and that's okay. We shouldn't force it.
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.)
by manlymuppet - It really is not so much about keyboard vs. mouse - power users vs. average Joes. That all is just a discombobulation that distracts from the main issue and the issue is the accessibility of plain text.
Majority of computer professionals (programmers included) come to appreciate a single fundamental truth about their field way too late into their careers. That the most basic foundational unit, the substrate they need to conquer is text. Everything stems from it. We have to deal with text our entire lives. It doesn't matter where that text appears - in web browsers, in Jira, in Slack, in terminal, in PDFs, Word or LaTeX documents. Code by the way is just structured text. The feeling of empowerment and liberation when you can deal with text on your own terms is a disproportionate multiplier. That's why using multiple cursors feature for the first time feels so amazing, even though the practical cases for it are not that common.
And when I say "text", I don't only describe the process of "grabbing some text" and "piping it" into another process, or manipulating it. It's not only about the input, the act of consuming text is equally, if not more important.
We argue that keyboard-driven UIs are more efficient for the input, but hundreds of memorized shortcuts can't really fix the fundamental problem.
Vendors are designed to own you and ownership can take different forms. Slack app that doesn't let you easily extract code snippets from a thread - owns you. Jira that forces you to use their stupid, quirky wysiwyg editor - owns you. Note-taking app that keeps the data on the cloud ain't your friend. The friction is the ownership. When extraction of text requires effort, the tool has leverage over you. It's a subtler form than data lock-in, it is behavioral lock-in. You adapt your workflow to what the tool makes easy, and gradually the tool's affordances shape what you even think to do. Information gets buried in threads, search is mediocre, export is hostile. The "solution" they offer is to stay there longer - search in Slack, link to Slack, screenshare in Slack, summarize with AI in Slack, don't ever leave Slack. The tool becomes the answer to the problems the tool creates.
And when you get to that point, you'd feel helpless - all your knowledge and muscle memory can't help you there - not only the app is not favoring power-user experience, it's forcing everyone downgrade to the "average Joe" levels.
Most popular editors and IDEs don't give you direct leverage over plain text either, at least not without the effort from your side. Shortcuts, popups, UI elements in the IDE at best are local drivers - you can't easily grab a thing from the outside and feed it to your LLM context in the middle of a task, or insert within a comment in the code - you have to switch, copy, paste, deal with format inconsistencies, manual conversion, etc. Then we keep bargaining what method is the best, fastest and most convenient - using the mouse or keeping the fingers on the home row, modality or complex shortcuts. All for the sake of the problem that's artificially enforced on our workflows.
Terminal-heavy users eventually start appreciating the leverage Unix philosophy grants them over text, but that's still contained within locality, they still have to constantly jump around, while eventually figuring out ways for automating some aspects of it.
Point is - do not give in to the status quo. Liberate your text - deal with it on your terms. Get annoyed whenever you need to switch back and forth just for the sake of finding the piece you need and moving it around - it should be instantaneous and instinctual. Like a boxer moving in a ring and casually throwing heavy punches. Long-time Vim and Emacs users "get it", even though they often don't follow through - some things just never become gratifying instincts. Sometimes, even the opposite forms - like redundant muscle memories. Some outright would reject using a new app because it messes with one shortcut they keep accidentally pressing. Sometimes, I wish there was an agreed standard for every UI - to have only the core, commonly used keys pre-set, while making everything else configurable.
by iLemming - I don't know where you got "forcing" here. The author is arguing for guis that give the option of keyboard use. Unless you think having hot keys underlined nonconsensually imposes visual complexity and confusion on the hapless non-power-user, I don't see where your argument makes sense here.by joe_the_user
- > But most people aren’t willing to deal with the learning curve of keyboard-driven GUIs.
Keyboard shortcuts should be an _optional_ way to interact for accessibility and power users! They should never be required!
This is what TUIs get wrong, they make it the required way to navigate and often don’t even let you use the mouse.
by laserbeam - Whoa there.
Allowing people to use keyboard is NOT the same as forcing people to use keyboard.
Also, very few users will use only the keyboard, but quite many will use some part of keyboard access. If today I need to switch between proofreading languages a lot, you bet I will learn the keyboard shortcut for it (and forget day after that, until next time I needit again)
by reamaer - In some cases you may need the keyboard accessibility.
- Your mouse/trackpad breaks or isn't recognized?
- The right mouse button for your trackpad isn't working for some reason (e.g. you spilled a drink on it). It should still be possible to use the context menu keyboard button to bring up the context menu.
- Your hands are on the keyboard (typing a document, email, code, etc.) and it slows you down to move to the mouse/trackpad to perform an operation such as copying/pasting text or bringing up the spell checker context menu actions so you want to do those with the keyboard to keep yourself in the flow.
Most often you'll learn keyboard shortcuts/interactions for your workflow then expand out as and when you need them. Sure, knowing all shortcuts and interactions is fairly limited, but the majority of people will know how to cut/copy/paste with the keyboard as those are common operations.
by rhdunn - FWIW, I think it's a blind spot to think of power users as "Arch Linux people" using "developer tooling".
My wife is a UX Design consultant and she had an engagement where a bunch of state government accountants were bemoaning how a redesigned procurement platform took away all their keyboard shortcuts.
by neutronicus - The argument is that both should be supported, which seems like a valid wish. There's really no reason to either-or this. Just have both work.by OroPla