I work on ADA a lot for my company. Please put on some headphones, turn on the voice assistant of your OS, put on some blinders, and run your app or website… no mouse, just keyboard.
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.
I had to keep accessibility in mind a lot in my previous job (web development for a university). The thing that I consistently found was that, the more accessible a website was, the better the experience for everyone, not just people with disabilities.
I 100% agree. I've been working on a component library rebuild at work and accessibility is a key focus, granted I don't think that would be the case if some of our contracts didn't mandate it but it's fiiiiiine
I'm someone who enjoys this kind of work, especially when the target is a stylized drop down - I got to spend a week with the MDN page for the ARIA combobox open, trudging through all of the ins and outs of keyboard accessibility and I know I'm still missing a couple things (typing when the control is focused but not open, for example), and having clearly defined specs is something we don't seem to get a lot in webdev
Definitely not a substitute, and a bit slow, but GPT computer use is demonstrating an alternative path with live vision models. I'd be curious how this is fairing for those with vision impairments.
My father is blind, the only tech he knows how to use is a smart tv, when i build him custom apps the first thing i do is turn off talkback when the app opens, so i can control what tts says. The regular talkback is so so annoying and repetitive
Yeah unfortunately this seems to be something very few outside of bug tech dedicate resources to. Even for them it seems to be an afterthought, at least in my professional experience. It winds up another compliance checkbox just like security.
That's a good point. Accessibility is the next step that should also not be ignored. Navigating to the elements is one thing, but for the voice assistant to work properly it can be a little trickier.
It's been a while since I've done actual development, but determining tabindex ordering was a very big deal in the early 2000s when clerks/admins were moving from legacy systems to the web. They did most of their jobs with a keyboard, and if you set up tabindexing so that they can use a keyboard for 90% of their job then they would fly through tasks. If you didn't then you'd have some very angry clients at the end of the project ;)
So just echoing that this is not just an accessibility thing, but just a good user interface design thing. If your UX designer isn't taking keyboards into account (jettison mobile first development into the sun please) then they have no business building business applications.
The issue with accessibility is bots from scrapefly or browserbase will abuse website to death. There is reason why we can't have good things due to abuser like scrapefly, browser base, anchor browser etc... I had to turn off all the accessible selector and randomized html soup to make their life harder.
The solution is redirecting to an actual API or MCP with the same ability as your GUI, along with a real way to export your data. This is the future with how AI agents will work whether you like it or not. People are not going to want to deal with a GUI if an agent can do it better and faster for them.
Keyboard accessibility is one of those things that tends to get swept under the rug or forgotten about entirely alongside accessibility in general. The funny thing is that the former usually falls out of the latter.
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.
Funny that you bring macOS, because for _decades_ I've struggled with navigating it without a keyboard. Windows components however, especially old ones, are incredibly accessible
As a system macOS definitely has some holes in keyboard navigation, as well as a couple corners which are KB-navigable but the way to focus them is not immediately obvious.
On the app level, keyboard navigability depends on the developer. If they take the time to dot their I's and cross their T's it's between decent and great, but if they don't care it'll be bad.
MacOS has intentional holes in keyboard support. You have to go into settings and turn on a config for keyboard navigation to reach all elements. Apple intends for most users to navigate with a mouse.
There's no option to bring up a context menu with the keyboard. And there are no keyboard accelerators _AT_ _ALL_. Windows will underline the shortcut characters when you hold "alt".
The philosophy was that anything visible in a context menu should also be in the app-wide menu bar. Instead of bring up a context menu and click Copy, you would find the Copy menu item in the menu bar. Therefore such menu items can be assigned any keyboard shortcut by the user.
> Always make context menu items available in the main interface, too. […] In macOS, an app’s menu bar menus list all the app’s commands, including those in various context menus.
Therefore one can rightly conclude that there is no need for a key to bring up a context menu.
In this case it's not a context menu, it's just a menu. User experience is degraded, see GP's case. There is an expectation and a common paradigm which is intentionally ignored because the OS developers thought they knew better than the users.
This reminds me of frequent conversations with other developers when presented with a bug report. "That's not a bug, it's working as intended." The intention is wrong, then -- the bug is in the design, not the code, but it's still a bug.
> There's no option to bring up a context menu with the keyboard.
That used to be the case but has changed. Since at least macOS 15 the context menu key on typical keyboards is recognized and functions, and on other keyboards it can be opened with Ctrl+Return.
To reinforce your point, by default on macOS you can't use Tab to select different options in a dialog box. You have to enable that in System Settings -> Keyboard -> "Keyboard navigation" which is off by default.
>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.
Which ones, besides web frameworks pretending to be desktop ones? Most if not all frameworks I know support keyboard navigation.
I know of at least 5 different UI frameworks in different languages which are partially accessible or completely inaccessible. Some include Dlangui, Tkinter (although this is getting better), DearImGui... Really any UI that decides to draw it's widgets by frame. QT also has some accessibility problems. In apps made with any of these, they are either impossible to use with assistive technology (and therefore the keyboard) or they are very difficult to use.
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.)
Where this falls apart is commercial software. The issue is we use off-the-shelf frameworks and tools for commercial software. And then we don't train developers on how to write high-volume software.
Commercial software is THE power user use case. Your users will be using your software 8 hours a day, 5 days a week, for years. And still, the software is obtuse point-and-click garbage. Meanwhile commercial software from 25 years ago could be navigated at light speed.
That's part of the reason Excel can't be dethroned. Excel is from the old age of software, and that means that users can input and navigate at light speed. All these fancy tools claim to dethrone Excel, but when you actually use them you realize it's a goo goo ga ga Fisher Price level UI. Extreme amounts of whitespace, buttons hidden behind submenus of submenus (which you have to navigate by eye, by the way!), features stripped, UI constantly shuffling around between updates.
Look, that works fine for a website on the open web where you assume your users have never touched a computer before. That does not work for commercial software.
Not guaranteed but easy, because Windows has mnemonics, where you can associate arbitrarily nested menus with actions, and each menu can have its own mnemonic key, so that you press ALT, then, say, "k", then, maybe "m" and so on, following along with the menus as they drop down.
This way it becomes easy to memorize key sequences; start by navigating with arrow keys, then eventually speed up as you memorize each menu item's mnemonic key, and if you ever forget, just look at the menu.
It was the keyboard-friendliest idea ever, without requiring any sort of terminal. I'd even say friendlier than MacOS (heresy!!) or, yes, VIM (burn the witch!!!)
Even if you didn't have mnemonics, you could use tab, arrow keys and alt if needed, to navigate, and space to "click" buttons and such.
So even if the developer forgot to configure mnemonics, which was as easy as prefixing a letter with ampersand, you could navigate by keyboard. Sometimes tedious but beats not being able.
Well the two--building for power users vs for a general audience--often work against each other.
And trying to satisfy every audience at once is a good way to satisfy none. You don't want your app to be a Jack of all trades; focus is really valuable.
Devil's advocate: showing the relevant keyboard shortcuts in the UI can be overwhelming (or at least one of many parts that all together become overwhelming) to new users, while not having them shown at all makes them undiscoverable.
I think this is a bad reason. Even MS Office has made this work. But I've seen people act on this type of argument. If nothing else, it should be possible to have a settings menu where you can define your own. Even if no shortcuts are set by default and they aren't shown anywhere else in the UI, it will still be possible for a power user to make the best use of the program.
(Speaking of menu/drop-downs with underlined characters for alt commands.)
> This works poorly if you intend to localise your application. Great if you don't though.
Sure that's true. But remember M$ allowed you to fairly easily edit those underlined-characters in, oh, for example Office 2002 and 2003. Even if you didn't have a lot of default underlines in your current language settings, it is still possible for someone to add their own underline-shortcuts.
Back in those days, the first thing I did on any personal new install of Outlook, was to disable the shortcut that marked all email as being read. (That's cause I hit that button by accident too many times.)
It sounds like your complaint might be that it works poorly if you half-ass the localization process and assume that literal translation of strings is most or all of what localization means.
> showing the relevant keyboard shortcuts in the UI can be overwhelming
Every application did it for decades after the first Xerox guidelines up until Microsoft and Apple decided to retire the concept of usability some time around 2010.
Eh I think things like vimium have kinda solved this.
Push a button, every icon is now labeled with a key, type that key, counts as a click, done.
I get that this does NOT solve for say, someone who's blind (i guess you could announce them, not sure), but it is easy enough I've found even lower tech people are fine with it.
As always, a lot of the trick is communicating the interface and using modern standards, not "Well it's ctrl + insert because that's what it is on linux"
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.
No honestly some harshness is warranted, most of the people alive have internet access and a smartphone, this is a more ubiquitous activity than many others we require or expect accommodations from. This site has a lot of good to offer, but sometimes the bubble needs a reality check that their needs and concerns are even more niche than disabilities like
Blindness.
Most reasonable people want support for both keyboard and mouse-based navigation. For example, why did Edge and possible chrome, remove support for Back via the backspace key? Literally, why remove something that exists and that some people might use?
Same with some web forms where hitting enter in a text box does nothing. I expect it to submit a form, but very often, it does nothing.
I specifically had to disable that via about:config in Firefox ages ago because I pressed it by accident all the time. Often while I was going through a 30 point form, only to then lose all my progress. To be fair, browsers probably should try to not undo progress like that, so you can just go forward again and get right back where I started, but I've never trusted them to actually do that. I've been burned too many times.
I'm surprised the person responsible for <backspace> mapping to Back navigation didn't mandate that <del> would be super awesome for Forward navigation.
right now, i cannot even enable Backspace = go back on Edge. I am forced to use Edge on my work computer and i hate that this feature is gone. Not disabled, just gone.
About enter to auto submit, i've been running into this problem more often where some web frameworks just ignore the Enter key. There is a submit button, but i cannot trigger it via the enter key.
Every small feature is used by some subset of users, but if you don't trim your software from time to time then feature creep will eventually make it incoherent. Yes, it involves even small details like this one. I don't think learning another hotkey is a big problem, and anyone using keyboard navigation on the web should generally be at least aware of a ton of existing Vim-like navigation extensions (and even browsers)
> For example, why did Edge and possible chrome, remove support for Back via the backspace key?
Because alt+left is a better choice? Really f**ing annoying when some dumb javascript removes focus from a text box you're editing and the page navigates back.
Agreed. I'll say the same about accessibility. People really need to test for this more. If your app is not accessible I literally cannot use your app regardless of how useful it might be. This is pretty much why I currently don't use IDEs like Zed: even if I wanted to I can't because it presents no accessibility tree.
> For example, why did Edge and possible chrome, remove support for Back via the backspace key? Literally, why remove something that exists and that some people might use?
Because web pages don't preserve element focus well, web was originally meant for documents in the first place, not UIs. If you're trying to erase a character and the focus has been lost, you go back in history instead. It's a real existing problem in poorly designed pages, not a nefarious plot to annoy power users by Google, Microsoft, or Mozilla. It was always janky as hell.
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?
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.
Since you mentioned Windows, Microsoft made Ribbon which uses Vimperator-style navigation to make toolbars and buttons discoverable as long as you know one hotkey (Alt). It can also be hidden until triggered with a hotkey. This is miles ahead of most discoverability tricks in power user interfaces, including fuzzy command search which is not guaranteed to remain stable as new commands are added.
One downside to the ribbons that I see is that they somehow inverted the hierarchy between menus and toolbar buttons: Previously, menus were the slow but predictable way to find a command, and both toolbar buttons and keyboard shortcuts were just that - shortcuts. Menus were a sort of "ground truth" which commands existed. They also had a standard way to be navigable through the keyboard: You can press alt and then simply use the cursor keys.
With ribbons, the menus were gone and the toolbar buttons became the "ground truth", but in a much more haphazard way.
Fuzzy command search goes a bit back to menus, but as you say in a way that's much less guaranteed to be stable.
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"
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.
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.
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.
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!
Oh, finally somebody who gets it!
That was incidentally my major disappointment with vim: it is keyboard driven, but the UX wasn't designed to be a perfect keyboard experience (which I expected, given how old it is).
Some examples of what you are asking for can be found in videogames due to controllers
Keyboard specific focus + navigation, shortcuts, poupable command entry/console (eg ~ in mpv, or quake :D) with commands that interact/integrate with the GUI side.
"What does it mean though for a GUI to be keyboard-driven?"
For literally decades after they were state of the art, people who used old-school mainframe TUIs would still swear by them.
I think the key difference is that they would buffer inputs. You could be on the "Receipt" screen, and know that if you needed to enter the code for some rebate receipt or something, you could hit F6 - F2 - down - down - down - {start typing code}, and even if the UI took multiple seconds to actually get to the point that the code was being entered, the input would be kept.
Normal GUIs have discarded this for fairly good reasons. Especially when it comes to queuing mouse clicks. If you get down to the nitty-gritty of what it means to queue a "mouse click" it get very conceptually complicated. But you could create a GUI toolkit that still had the same idea integrated into it for a keyboard interface, if you have well-defined points where you are and are not accepting keyboard input.
I would submit that "keyboard-driven UI that is as intuitive as clicking with a mouse" is actually the wrong direction to cut on. You need to beat the conventional mouse GUI completely in some other dimension, one where it can't even compete. This is the only one I know of that has historical precedent.
The downside is that on a desktop I'm pretty sure you're looking at a completely new widget toolkit. Trying to force this on the current ones is going to be hard and could even be impossible.
If I were going to create a new web frontend framework, this is what I'd focus on to have an actual new feature that isn't just a respelling of the current set of features. And I can't guarantee that it won't also be missing something crucial, though, I think everything you need is actually there. You could even have modern nicities like, store the entire GUI field state transition diagram statically at the beginning and as the user types ahead of the GUI's current state, show them a rendered view of where they are going, e.g., the key sequence I showed above could be "[Rebates] -> [Rebate Receipt] -> [Name Field] -> [Address 1 Field] -> [Address 2 Field] -> [Rebate Code Field] -> [Entering {'A8F2-132A-9283'}]", live updating as it goes so if the user can just bang that out even while the first screen hasn't loaded they can even be sensibly editing the text input they're going to put in.
Combined with something as simple as making sure everything always has a keyboard shortcut in a defined format, which is conspicuously displayed every time you change something, e.g., every time the user clicks the Rebate Code Field you can also display something like "Ctrl-F R" or something so they also learn how to drive the screen with a keyboard and you would, if nothing else, have something different than what's out there today.
Anyone who wants to, steal this idea. I'm not going to do anything with it. I don't see this as something you want in every app necessarily, but people who spend hours a day in the same app for whatever reason would be confused for a week, then I bet you couldn't pry it from them with a crowbar.
The fundamental difference is that mouse input requires unpredictable motor movements. We can't queue mouse clicks because the user doesn't even know where a button is going to appear. Even if they did, the actual physical mouse movement needed to get there is different every time. There is a necessary mouse -> screen -> eyes -> hand -> mouse feedback loop for every action.
Keyboard input can, when designed well, be fully predictable and require no feedback loop with the computer. The motor movement involves a fixed set of physical buttons, which we can fairly easily train to press very reliably, and that training is then universally applicable across all software.
That is why you can buffer keyboard input but usually not mouse input. With keyboard input, I know what the software is going to do and I know exactly what hand movement will get it to do the next thing, so I can perform that movement even before it's ready. With mouse input, it's not really possible.
At this point what keeps me on Firefox is less the browser engine diversity than [tridactyl](https://tridactyl.xyz/), without which I feel almost helpless in a browser.
Keyboard driven is fine, when you have a keyboard. But many users are now on phones or tablets, with a severely limited keyboard that takes a big part of the screen. But they have a variety of gestures that regular desktop machines don't have. A good UI should happily handle both of these extremes, and everything in between.
"Just as it should be possible to perform every action with a pointing device, every action should also be possible with the keyboard."
"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.
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.
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.
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.
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.
Yeah, keyboard binding consistency is what I really want. Ideally, you could choose between Vim, Emacs, <whatever else> keybindings for the program you're using.
I think what's also needed is a standard way of navigating what I guess I'll call the "focus tree". For example, if I'm running Vim inside of a terminal multiplexer (eg: Zellij) inside of a terminal emulator inside of a tiling window manager (eg: xmonad)...
It would be GREAT if I could use Vi keybindings to navigate windows in whatever "focus layer" I'm at... and then have a "standard" keybinding to navigate up and down that tree (eg: "Ctrl + >" and "Ctrl + <").
Right now, everyone seems to solve the "focus tree" problem by trying to choose a control key combination that won't collide with any other process that might be listening for key chords at the same time.
Back in the early 1990s, mice were fragile enough that Apollo salespeople were trained to be able to do their demos keyboard-only as backup (at least for tradeshows) and that was just generally how interfaces were built. It wasn't an accessibility thing, it was a "we're demoing expensive systems to even more expensive people, it had better work" thing...
I moved to KDE from Gnome for a variety of reasons, but I genuinely miss Gnome and Native GTK apps. They weren't as customizable, but the features you did get work so well.
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.
> In fact, many GUI framework application guidelines explicitly encourage GUI application developers
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".
For example a GTK app main context menu can be triggered with F10. But this relies on the developer to correctly "tag" said context menu.
In simple cases it is obvious what to do, but in more complicated designs, where you may be able to achieve the same visual output in different ways, it may not be so obvious.
In that case, it is up to the developer as well to read and try to follow the published guidelines.
This is a very narrow viewpoint, considering the majority of computing is done on touch screens now. Sometimes keyboard controls are critical, sometimes they're not, sometimes your users don't care, sometimes they do. Sometimes a pointer is a better human interface for something, sometimes a purpose built controller is, sometimes a multi touch sensitive touchpad is. I wouldn't make an FPS that was just keyboard controls and the same is true of some other types of UIs. Just measure it and be creative and empathetic to how people will use your product who aren't like you and consider the physical interactions as a part of your design space and not just the software.
TUI, GUI.. we need a marriage of both, with configurable levels of integration, which controls to favour TUI or GUI.
If it's well done, no need for a mouse, but nice and easy to have. Add to this a thin glove checking for certain movement patterns when the user is not typing and voice to set certain things - all at once.
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.
Yeah I would rather just have a single interface(the terminal) for all of the tools that I use that are keyboard driven by default. There isn't anything I need from a GUI that the terminal doesn't give me.
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
A GUI is indeed superior to a TUI. And keyboard driven should be both. But neither is my preferred UI. I want CLI programs callable from my shell.
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.
> 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.
>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.
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.
I am kind of obsessed with keyboard shortcuts, ever since discovering Vim a million years ago. The Vim shortcuts are burned into my brain.
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.
Three levels of GUI workflow operation: touchpad < mouse < keyboard. This is the main reason people fall in love with programs like vim: with enough experience it allows one to completely eliminate interface friction.
I'll go one step further: anything you can do in a GUI should also be possible to do through a CLI and yes, also with code libraries. If webapps have n-tier architectures, then so should GUI software.
(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 do agree to some extent, but were GUIs not made specifically to reduce so much reliance on the keyboard? And a few people here did mention that this "fully keyboard-driven" workflow would probably be used by power users primarily.
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 submit that the point of the GUI was necessarily "anti-keyboard" as more "pro-discovery", plus adding gestures that would be difficult on a keyboard.
Keyboard interfaces can be, but not necessarily, quite opaque. There's a reason in the old days companies shipped keyboard overlays and function key templates to help users (or went all in with custom keyboards built for the application).
In contrast consider something like Wordstar where you pretty much just needed to memorize the three prefix keys, and if you pressed one and waiting, you'd get a menu describing all of the options.
Obviously, things like early Smalltalk and, probably, Xerox (having never used any of the early Xerox systems), relied heavily on the mouse, but even it had command accelerators.
The CUA standard was that crossover that Windows, and MOTIF, adopted. Much of that work is still with us today, and it worked well both on GUIs and TUIs (witness the old Turbo Pascal/C++ IDEs, and other applications). Those character based applications had to assume there was no mouse, but offer the flexibility of being good citizens should a mouse be present.
Agreed, but what "prevents" it is that making a good keyboard-driven UI takes a lot of taste, extra effort to build it, and it must be revisited any time the UI changes. It's duplicated work.
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.
Besides JavaFX[1] are there any free, open-source, object-oriented, event-driven, cross-platform, native GUI frameworks that allow for keyboard-accessible UIs? Preferably using a modern language such as Go.
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.
Worth noting that Windows 3.x Paint could be used entirely from the keyboard, as the arrow keys moved the cursor and you could position it with pixel-precision. This is in addition to the fact that the rest of the OS was also entirely usable without a mouse.
Where possible, there should be keyboard shortcuts/navigation.
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.
The problem with keyboard navigation is that there seems to be no mature GUI keyboard-first UX concept. "Mouse things" are the way they are, because they fit the mouse-way. We need the same for the keyboard-way. Until then, there seems to be no design concept that can just be copied.
This does not work great. What if you have a grid of 30 item, do you press 20 times tab to focus finally the item you want to interact with?
Keyboard design is much more, its also about how and where to place items, how things should move... it's a whole world. In the mouse world we have "discovered" those things and now we "just copy" other designs that we know work fine.
> What if you have a grid of 30 item, do you press 20 times tab to focus finally the item you want to interact with?
If this grid a central component of the application and navigation inside it is very common, I would argue that there should be a way to quickly move around the cells. The "how" is up to the specific application and the paradigms it promotes. For example, line navigation in vim is possible with "<N>G", but such a shortcut would seem absurd in another application.
I don't think this really addresses GP's comment as far as I understood it.
Your resource mostly describes how to make keyboard-based workflows accessible. But just because the full functionality of an app is keyboard accessible, doesn't mean that it works as well as the pointer-based approach - especially if you have an app with multiple menus, sidebars, headers, footers etc. Maybe you could tab through everything, but a pointer will be faster. This is where a "keyboard-first UX concept" is missing (from GP).
I think an interesting idea to solve this would be a "focus navigation mode". Enter this mode with 1 shortcut and then navigate between items with a few keys; like a combination of mnemonics and screen reader navigation e.g. jump between headers with "h" etc.
That's not what I mean. The site you linked is about how to make a mouse-first website more keyboard friendly, but what I would like to exist is a mature keyboard-first guide.
The hard part is, there seems to exist no UI & UX design language I can follow to create a nice keyboard-first app, so I have to think through everything (which is fun but tiring).
>there seems to be no mature GUI keyboard-first UX concept.
I don't know about 'first' because I don't see a reason to privilege keyboard workflows over mouse workflows given how ubiquitous the latter is but Windows has had, for literally decades a 35 page Keyboard UI spec. They've put a fair amount of effort in applications being navigable in a consistent way.
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.
Thats really true, small software thats easy to run, and launches instantly has a place in my heart as well. The get sh*t done centric workflow that TUIs offer is so unfortunately often lost in multiple layers of GUI controls...
I'm a keyboard based UI lover, but I wonder if the supportive crowd is, and will ever, be too small.
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. ^^
On the web, keyboard accessible web UIs are a WCAG 2.1.1 level A requirement - that's literally the most basic level of accessibility standard (unless you count 'failed' as a level). If your website / web app isn't achieving that then you haven't tried very hard.
Keyboard driven, and keyboard accessible are not the same thing.
I’ve made a web application at work able to be keyboard driven one time and exactly 0 users out of thousands made use of it. People just don’t want to pay the upfront cost. In the old TUI days it was the only way to use something so you had no choice.
To be completely keyboard inaccessible I’d argue that you almost have to try and achieve it.
This is something Windows and Mac OS got right in the 1990s. I remember reading specifically about it in terms of digital accessibility too at the time.
You are right. Maybe the wording is a little too absolute. If you gotta ship and later try to slowly address any shortcomings in different areas, this is also a step in the right direction in my opinion. Just don't completely forget about those areas just because you have already shipped by that point.
this is absolutely not true since December 2025.
the amount of "nice to have" items I've been commanding LLM to develop is a dream come true.
while being better at QAing i finally get the time to work on the things that got me into programming in the first place, which in the point where human interact with the machine.
Or even the original premise of agile, which was to iterate on it. But "iterate" these days means "onwards to the next feature that we'll only drive to MVP", not, "polish & fix bugs" or … do things like enhanced UI for power users.
I have seen more GUIs these days that don't support even the bare minimum of using tab to cycle through various fields and selector buttons. Which as I recall was introduced in like windows 3.0.
A few years back I started to try to use my computer by not touching the mouse. Ended up writing a bunch of Tampermonkey scripts for my most used web pages to add fast keyboard navigation shortcuts.
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.
I've thought how i dislike both keyboard and mouse navigation from an ergonomics standpoint. Fine motor control for hours. I'd low-key want a neuralink beacuse speech is too awkward. Maybe mixed with eye monitoring.
I've been on this kick for a long time. A few years ago I was exploring a UI design tool that was entirely keyboard-driven, using pneumonic keychords inspired by Vim: https://github.com/danielvaughn/stride
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.
Adding keyboard support gets very annoying after a while. I recently posted a new version a package I made that makes it really simple to add keyboard shortcuts to javascript apps: keyboardist.io
The mouse is amazing, if you have a good sensor, a mousepad and no mouse acceleration. Not many have this setup, but those who do can wield their cursor with insane speed and accuracy. Consider top osu! or Starcraft players.
I think we should also be finding ways to make things keyboard-driven that currently require a mouse. My side project is a keyboard centric flowchart editor which tries to merge the two between something typically 2D with pixel coordinates (normal flowchart software) and fitting it into a grid that has discrete coords so you can navigate with arrow keys.
The one UI invention many web UIs now add is the universal command search bar. I’m most familiar from it from Jetbrains IDEs where it’s been for over a decade and it is a remarkable upgrade on browsing menus. With the KeyPromoter extension on I even learned the keyboard shortcut over time. Good UI pattern and now this universal command search is everywhere: Cloudflare, Mercury, etc.
Similarly, under macOS in most apps ⌘⇧/ opens a full menubar search which can surface most app functionality from the keyboard. Not quite as good as a command palette but close, and devs don't need to do anything to opt in except populate the app's menus properly.
Well TIL. Great tip. I only ever hit that key combination when I look around Finder and find myself unable to go up one level easily from the icon bar - an action I do constantly.
It is excellent when I can do common tasks in an application without taking my hands off the keyboard. Especially utility apps like a calculator or password manager that I usually just need for a few seconds.
Bitwarden used to be keyboard friendly, but recent updates have removed those functions for reasons I can’t understand.
Command palettes are great in this regard. They make commands accessible and discoverable entirely from the keyboard. I'm happy to see them becoming more popular.
Honestly, it'd be nice if people remembered about keyboard controls more often. I'm not saying it should replace the mouse, but it'd be great if both options were kept around
My take in this case is to learn incrementally. Like the pebbles in the shoe, I remove the more painful one first (the shortcut for the action I do the most), get used to it, then remove next more painful., and so on. Usually I begin to get a little comfortable with 4 or 5 shortcuts.
I hate nothing more than when a random mistype on a website or app causing shit i don’t understand to happen without reasonable ways to undo it or discover it. I don’t really care if the app can be controlled with a keyboard i want the ui to be discverable and usefull.
This can happen if the applications exposes single keys as shortcuts. If they are "hidden" behind the different modifiers (i.e. Ctrl, Cmd, Alt), then mis-clicks should not be possible or should be more tolerated.
The "intuitiveness" argument is also related. You cannot rebind well-known shortcuts to different actions and expect the user to not get frustrated.
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.
Such a funny coincidence. I opened HN in this new, 100%-rust browser[1] I'm working on to actually test some keyboard fixes I did last night.
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!
This was my point in my comment[0] in that thread. I've used GUI Emacs for years, it's way better than the TUI version and fully keyboard driven.
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.
Honestly, they should be keyboard first. Yes, let all the mouse stuff work as normal, but choose keys so that the fastest way to navigate the app is with the keyboard whenever possible.
>But I want to oppose a recurring argument in favor of TUIs that in my opinion does not have a solid foundation. To paraphrase various commenters: TUIs should be preferred because they are keyboard-driven.
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.
Can we start with TUIs? At some point Claude code CLI stopped responding to the keys I had been using to scroll the presented plan and it seems only the mouse wheel works
People gave the ribbon interface a lot of shit but one thing they definitely got right was making absolutely every option reachable from some keyboard shortcut. Some of the shortcuts get a little long but you can just add those as a hotkey if you use them a lot.
I agree 100%. The mouse is great and I don't think GUIs should drop it or anything, but it's wonderful to have the ability to keep your hands on your keyboard when doing data entry tasks and the like. I also think that when you design for both keyboard and mouse input, it will force you to consider rough edges of your UI design in a way that you wouldn't have to if you were just designing for one. So the app will be better as a result.
Co-sign. This is one of the reasons I’ve always loved NetNewsWire as my RSS reader and few things have been able to displace it. Everything is doable by keyboard, and the keyboard commands are extremely logical and intuitive. You can FLY through your backlog.
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'm surprised there's only a single mention of tiling window managers here. No talk about i3[0] or hyprland[1]?
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.
My issue is that taking a strictly GUI driven approach makes you build an application (in the browser presumably) that will require more permissions than you would typically want in the terminal so TUIs win out by being in proximity to those tools (cat, ls, rm, etc) for development use cases
Keyboard driven UIs are easier to instrument by alternative interfaces and has very positive accessibility implications. However, "shoulds" in computing lead toward a "tyranny of compounding responsibilities"; adding interface complexity to a project, particularly the suggested alternative input vectors may cross an upfront and/or maintenance development cost limit for a project.
A lot of comments on VIM here. Vim is a terrible example and a pretty bad design overall, objectively. Legends of great productivity with vim is highly legendary, i.e. fiction. Classic Notepad/Word and similar Guis that have been widely adopted in Linux windowing systems are clearly superior and that's why they're so widely and silently adopted. Not a lot of fanfare for hierarchical GUI menus with keyboard shortcuts.
You don't really need to remember everything though. Mouse navigation does not need to go away. The keyboard shortcuts should be available if you opt to use them, after which point you will be able to memorize them in short time.
The intuitive part of my argument also falls under this. By following known conventions as close as possible, we can eliminate the need to remember the most common actions.
Additionally, it is important to present your shortcuts in a shortcut window/dialog in a logical way for when the user needs to remember something.
In any case, an excesive number of keyboard shortcuts can have a negative effect on usability, so this is also important to keep in mind.
Tool-tips, having an accelerator next to the item in the menu/context menu, accelerator underlines, god forbid documentation … UIs have long had ways of having a simple way and hinting at, documenting, or showing to the user how to accelerate if you want to get quicker.
Yes and no. The big advantage of a GUI is having interactive 2D coordinate input support (aka a pointer, or gestures.) While I think a keyboard can be a great control surface, that’s one thing it really lacks and only GUIs really offer. So to enforce that the whole GUI must be keyboard-drivable requires limiting the major advantage of the GUI. I’m a fan of the Emacs or Plan9 styles where the keyboard and pointer are able to be used together synergistically. You also see some of this in tools like video, DAW, and 2D/3D graphical scene editors.
I agree. I mention this briefly in one of the footnotes. There are some tasks that greatly benefit from the mouse (e.g photo editing tasks where arbitrary region point and click is required).
This does not contradict the argument. The rest of the interface, everything that is known and stable in advance, should be full keyboard-driven.
> We just need better, efficient and faster GUIs to put these TUIs to an end.
Well, yeah, it just that those GUIs failed to appear for at least 30 years.
> It is time to move on from using this arcane technology from the 60s-70s.
You mean the GUIs? They were being in development since the early 70s, you know, but they really have flourished in the 80s. So, it's already a 40-years-old paradigm that still haven't managed to displace another contemporary paradigm of TUIs. Well, who knows, maybe in 40 more years it'll make it.
Yikes, no! One of the reasons old timers like me say that using a computer has sucked a lot in the last ~20 years is the use of a browser as an interface to everything.
If you want to make an app that needs a browser to use, then please drastically improve the browser's interface. I mean, this is a no brainer. TUIs are way more superior to doing things via Safari/Firefox/Chrome.
Hard disagree. Most web interfaces are worse than most native UIs. Inconsistent rendering, keyboard shortcuts and navigation between apps, slow response times, and more.
There's a reason everyone who knows what Electron is bashes every "native" app built with Electron.
Keyboard shortcuts, navigation, and more are inconsistent in web apps. Will they work at all? Will they use different keys? No one knows. Will they respect my OS theming? What about my font choices or font sizes? Almost certainly not.
I work on ADA a lot for my company. Please put on some headphones, turn on the voice assistant of your OS, put on some blinders, and run your app or website… no mouse, just keyboard.
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.
I had to keep accessibility in mind a lot in my previous job (web development for a university). The thing that I consistently found was that, the more accessible a website was, the better the experience for everyone, not just people with disabilities.
I 100% agree. I've been working on a component library rebuild at work and accessibility is a key focus, granted I don't think that would be the case if some of our contracts didn't mandate it but it's fiiiiiine
I'm someone who enjoys this kind of work, especially when the target is a stylized drop down - I got to spend a week with the MDN page for the ARIA combobox open, trudging through all of the ins and outs of keyboard accessibility and I know I'm still missing a couple things (typing when the control is focused but not open, for example), and having clearly defined specs is something we don't seem to get a lot in webdev
Definitely not a substitute, and a bit slow, but GPT computer use is demonstrating an alternative path with live vision models. I'd be curious how this is fairing for those with vision impairments.
My father is blind, the only tech he knows how to use is a smart tv, when i build him custom apps the first thing i do is turn off talkback when the app opens, so i can control what tts says. The regular talkback is so so annoying and repetitive
Yeah unfortunately this seems to be something very few outside of bug tech dedicate resources to. Even for them it seems to be an afterthought, at least in my professional experience. It winds up another compliance checkbox just like security.
That's a good point. Accessibility is the next step that should also not be ignored. Navigating to the elements is one thing, but for the voice assistant to work properly it can be a little trickier.
What do you mean by "a tab is off?"
Using tab to cycle between interactive elements in a window or page. As soon as you tab and it goes somewhere unexpected, you're cooked.
Normally you press tab to move between widgets. I guess he means if the tab order hasn't been set up properly.
It's been a while since I've done actual development, but determining tabindex ordering was a very big deal in the early 2000s when clerks/admins were moving from legacy systems to the web. They did most of their jobs with a keyboard, and if you set up tabindexing so that they can use a keyboard for 90% of their job then they would fly through tasks. If you didn't then you'd have some very angry clients at the end of the project ;)
So just echoing that this is not just an accessibility thing, but just a good user interface design thing. If your UX designer isn't taking keyboards into account (jettison mobile first development into the sun please) then they have no business building business applications.
I worked on an accounting application once. We had the proper tab order written down on paper docs and checked/updated it regularly.
We would have been murdered by at least the point of sale people otherwise :)
The issue with accessibility is bots from scrapefly or browserbase will abuse website to death. There is reason why we can't have good things due to abuser like scrapefly, browser base, anchor browser etc... I had to turn off all the accessible selector and randomized html soup to make their life harder.
The solution is redirecting to an actual API or MCP with the same ability as your GUI, along with a real way to export your data. This is the future with how AI agents will work whether you like it or not. People are not going to want to deal with a GUI if an agent can do it better and faster for them.
Keyboard accessibility is one of those things that tends to get swept under the rug or forgotten about entirely alongside accessibility in general. The funny thing is that the former usually falls out of the latter.
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.
Funny that you bring macOS, because for _decades_ I've struggled with navigating it without a keyboard. Windows components however, especially old ones, are incredibly accessible
As a system macOS definitely has some holes in keyboard navigation, as well as a couple corners which are KB-navigable but the way to focus them is not immediately obvious.
On the app level, keyboard navigability depends on the developer. If they take the time to dot their I's and cross their T's it's between decent and great, but if they don't care it'll be bad.
MacOS has intentional holes in keyboard support. You have to go into settings and turn on a config for keyboard navigation to reach all elements. Apple intends for most users to navigate with a mouse.
It’s in the accessibility settings.
https://support.apple.com/en-za/guide/mac-help/mchlc06d1059/...
"Some holes"? That's an understatement.
There's no option to bring up a context menu with the keyboard. And there are no keyboard accelerators _AT_ _ALL_. Windows will underline the shortcut characters when you hold "alt".
The philosophy was that anything visible in a context menu should also be in the app-wide menu bar. Instead of bring up a context menu and click Copy, you would find the Copy menu item in the menu bar. Therefore such menu items can be assigned any keyboard shortcut by the user.
I quote from Apple https://developer.apple.com/design/human-interface-guideline...:
> Always make context menu items available in the main interface, too. […] In macOS, an app’s menu bar menus list all the app’s commands, including those in various context menus.
Therefore one can rightly conclude that there is no need for a key to bring up a context menu.
In this case it's not a context menu, it's just a menu. User experience is degraded, see GP's case. There is an expectation and a common paradigm which is intentionally ignored because the OS developers thought they knew better than the users.
This reminds me of frequent conversations with other developers when presented with a bug report. "That's not a bug, it's working as intended." The intention is wrong, then -- the bug is in the design, not the code, but it's still a bug.
> There's no option to bring up a context menu with the keyboard.
That used to be the case but has changed. Since at least macOS 15 the context menu key on typical keyboards is recognized and functions, and on other keyboards it can be opened with Ctrl+Return.
To reinforce your point, by default on macOS you can't use Tab to select different options in a dialog box. You have to enable that in System Settings -> Keyboard -> "Keyboard navigation" which is off by default.
>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.
Which ones, besides web frameworks pretending to be desktop ones? Most if not all frameworks I know support keyboard navigation.
I know of at least 5 different UI frameworks in different languages which are partially accessible or completely inaccessible. Some include Dlangui, Tkinter (although this is getting better), DearImGui... Really any UI that decides to draw it's widgets by frame. QT also has some accessibility problems. In apps made with any of these, they are either impossible to use with assistive technology (and therefore the keyboard) or they are very difficult to use.
It's not even in consideration anymore since the plaque of electron swept over desktop apps.
Are there any modern cross-platform GUI frameworks that do this well?
Unfortunately, the intersection between “modern” and “do this well” is pretty much the empty set.
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.)
Where this falls apart is commercial software. The issue is we use off-the-shelf frameworks and tools for commercial software. And then we don't train developers on how to write high-volume software.
Commercial software is THE power user use case. Your users will be using your software 8 hours a day, 5 days a week, for years. And still, the software is obtuse point-and-click garbage. Meanwhile commercial software from 25 years ago could be navigated at light speed.
That's part of the reason Excel can't be dethroned. Excel is from the old age of software, and that means that users can input and navigate at light speed. All these fancy tools claim to dethrone Excel, but when you actually use them you realize it's a goo goo ga ga Fisher Price level UI. Extreme amounts of whitespace, buttons hidden behind submenus of submenus (which you have to navigate by eye, by the way!), features stripped, UI constantly shuffling around between updates.
Look, that works fine for a website on the open web where you assume your users have never touched a computer before. That does not work for commercial software.
> UI constantly shuffling around between updates.
and then 365 came along ... an option to pull stock market data here, a LinkedIn connection there, oh look a wild copilot button appeared.
I think you vaaastly overestimate how excel is used by most users
if anything, excel exceeds in being MOUSE-driven - it's intuitive in what you press and what you drag
and that's kinda my problem with the TFA - author is not representative of typical user. Mouse interaction is the king
Basically everyone in a white collar job who is NOT a developer is using Excel. I'm a developer, even I have to use Excel at work.
Maybe by most users, but not by most users who use it for many hours daily for professional tasks (i.e. not just as a kind of tabular list editor).
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.
Which, if you made say a regular Win32 application, was guaranteed. These newfangled frameworks dropped the ball, if anything.
Not guaranteed but easy, because Windows has mnemonics, where you can associate arbitrarily nested menus with actions, and each menu can have its own mnemonic key, so that you press ALT, then, say, "k", then, maybe "m" and so on, following along with the menus as they drop down.
This way it becomes easy to memorize key sequences; start by navigating with arrow keys, then eventually speed up as you memorize each menu item's mnemonic key, and if you ever forget, just look at the menu.
It was the keyboard-friendliest idea ever, without requiring any sort of terminal. I'd even say friendlier than MacOS (heresy!!) or, yes, VIM (burn the witch!!!)
Even if you didn't have mnemonics, you could use tab, arrow keys and alt if needed, to navigate, and space to "click" buttons and such.
So even if the developer forgot to configure mnemonics, which was as easy as prefixing a letter with ampersand, you could navigate by keyboard. Sometimes tedious but beats not being able.
Well the two--building for power users vs for a general audience--often work against each other.
And trying to satisfy every audience at once is a good way to satisfy none. You don't want your app to be a Jack of all trades; focus is really valuable.
Do you have an example of how supporting a keyboard shortcut for every action could be bad for a general audience?
Devil's advocate: showing the relevant keyboard shortcuts in the UI can be overwhelming (or at least one of many parts that all together become overwhelming) to new users, while not having them shown at all makes them undiscoverable.
I think this is a bad reason. Even MS Office has made this work. But I've seen people act on this type of argument. If nothing else, it should be possible to have a settings menu where you can define your own. Even if no shortcuts are set by default and they aren't shown anywhere else in the UI, it will still be possible for a power user to make the best use of the program.
> showing the relevant keyboard shortcuts in the UI can be overwhelming
Underlining the accelerator key is subtle and shouldn't be overwelming. Keyboard navigation unaware users probably won't even notice.
This works poorly if you intend to localise your application. Great if you don't though.
(Speaking of menu/drop-downs with underlined characters for alt commands.)
> This works poorly if you intend to localise your application. Great if you don't though.
Sure that's true. But remember M$ allowed you to fairly easily edit those underlined-characters in, oh, for example Office 2002 and 2003. Even if you didn't have a lot of default underlines in your current language settings, it is still possible for someone to add their own underline-shortcuts.
Back in those days, the first thing I did on any personal new install of Outlook, was to disable the shortcut that marked all email as being read. (That's cause I hit that button by accident too many times.)
It sounds like your complaint might be that it works poorly if you half-ass the localization process and assume that literal translation of strings is most or all of what localization means.
I'm not sure how you read that from my comment.
To be fair to your point though, that's what most localisation of programs are these days.
Windows did both successfully.
I can't remember an example that didn't also include the shortcut written in full, but I might just be drawing a blank here. Care to give an example?
Wasn't easy to find!
https://www.augenbit.de/wiki/images/5/57/Arbeitsplatz.png
Yup, pretty sure I've seen the same sorts of things using Asian characters.
> showing the relevant keyboard shortcuts in the UI can be overwhelming
Every application did it for decades after the first Xerox guidelines up until Microsoft and Apple decided to retire the concept of usability some time around 2010.
something something smartphones
> Devil's advocate: showing the relevant keyboard shortcuts in the UI can be overwhelming
That is not a requirement, having access to menus, a master help shortcut ir fuzzy search actions shorcut are other options.
Another person here is arguing for accessibility, which may have been overlooked.
Eh I think things like vimium have kinda solved this.
Push a button, every icon is now labeled with a key, type that key, counts as a click, done.
I get that this does NOT solve for say, someone who's blind (i guess you could announce them, not sure), but it is easy enough I've found even lower tech people are fine with it.
As always, a lot of the trick is communicating the interface and using modern standards, not "Well it's ctrl + insert because that's what it is on linux"
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.
Power user experience is not the same across disciplines either.
God forbid I should ever be forced to use Blender or Inkscape with only buttons.
Why do you introduce the concept of being forced to in the conversation?
Because most people do not get to choose what software they use for working?
No honestly some harshness is warranted, most of the people alive have internet access and a smartphone, this is a more ubiquitous activity than many others we require or expect accommodations from. This site has a lot of good to offer, but sometimes the bubble needs a reality check that their needs and concerns are even more niche than disabilities like Blindness.
you are arguing against a strawman.
Most reasonable people want support for both keyboard and mouse-based navigation. For example, why did Edge and possible chrome, remove support for Back via the backspace key? Literally, why remove something that exists and that some people might use?
Same with some web forms where hitting enter in a text box does nothing. I expect it to submit a form, but very often, it does nothing.
I specifically had to disable that via about:config in Firefox ages ago because I pressed it by accident all the time. Often while I was going through a 30 point form, only to then lose all my progress. To be fair, browsers probably should try to not undo progress like that, so you can just go forward again and get right back where I started, but I've never trusted them to actually do that. I've been burned too many times.
I can kinda get that one.
> For example, why did Edge and possible chrome, remove support for Back via the backspace key?
Because people were triggering it by accident all the time. Firefox and Safari don't navigate back on backspace either.
Enter only auto-submits if there's a visible submit button or if there's just one input, and that behavior goes back as far as I can remember.
I'm surprised the person responsible for <backspace> mapping to Back navigation didn't mandate that <del> would be super awesome for Forward navigation.
right now, i cannot even enable Backspace = go back on Edge. I am forced to use Edge on my work computer and i hate that this feature is gone. Not disabled, just gone.
About enter to auto submit, i've been running into this problem more often where some web frameworks just ignore the Enter key. There is a submit button, but i cannot trigger it via the enter key.
Every small feature is used by some subset of users, but if you don't trim your software from time to time then feature creep will eventually make it incoherent. Yes, it involves even small details like this one. I don't think learning another hotkey is a big problem, and anyone using keyboard navigation on the web should generally be at least aware of a ton of existing Vim-like navigation extensions (and even browsers)
> For example, why did Edge and possible chrome, remove support for Back via the backspace key?
Because alt+left is a better choice? Really f**ing annoying when some dumb javascript removes focus from a text box you're editing and the page navigates back.
Agreed. I'll say the same about accessibility. People really need to test for this more. If your app is not accessible I literally cannot use your app regardless of how useful it might be. This is pretty much why I currently don't use IDEs like Zed: even if I wanted to I can't because it presents no accessibility tree.
> For example, why did Edge and possible chrome, remove support for Back via the backspace key? Literally, why remove something that exists and that some people might use?
Because web pages don't preserve element focus well, web was originally meant for documents in the first place, not UIs. If you're trying to erase a character and the focus has been lost, you go back in history instead. It's a real existing problem in poorly designed pages, not a nefarious plot to annoy power users by Google, Microsoft, or Mozilla. It was always janky as hell.
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?
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.
Since you mentioned Windows, Microsoft made Ribbon which uses Vimperator-style navigation to make toolbars and buttons discoverable as long as you know one hotkey (Alt). It can also be hidden until triggered with a hotkey. This is miles ahead of most discoverability tricks in power user interfaces, including fuzzy command search which is not guaranteed to remain stable as new commands are added.
One downside to the ribbons that I see is that they somehow inverted the hierarchy between menus and toolbar buttons: Previously, menus were the slow but predictable way to find a command, and both toolbar buttons and keyboard shortcuts were just that - shortcuts. Menus were a sort of "ground truth" which commands existed. They also had a standard way to be navigable through the keyboard: You can press alt and then simply use the cursor keys.
With ribbons, the menus were gone and the toolbar buttons became the "ground truth", but in a much more haphazard way.
Fuzzy command search goes a bit back to menus, but as you say in a way that's much less guaranteed to be stable.
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...
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.
> 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.
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.
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!
Oh, finally somebody who gets it! That was incidentally my major disappointment with vim: it is keyboard driven, but the UX wasn't designed to be a perfect keyboard experience (which I expected, given how old it is).
Some examples of what you are asking for can be found in videogames due to controllers
Even as a fairly confident nvim user, I still use and recommend <https://github.com/folke/which-key.nvim>
Even as a devoutember of the church of emacs I couldn't live without the emacs version of which-key [1]
[1] I was going to link to a repo, but I just learned that which-key is included in Emacs out of the box.
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
start with CUA standard.
Keyboard specific focus + navigation, shortcuts, poupable command entry/console (eg ~ in mpv, or quake :D) with commands that interact/integrate with the GUI side.
"What does it mean though for a GUI to be keyboard-driven?"
For literally decades after they were state of the art, people who used old-school mainframe TUIs would still swear by them.
I think the key difference is that they would buffer inputs. You could be on the "Receipt" screen, and know that if you needed to enter the code for some rebate receipt or something, you could hit F6 - F2 - down - down - down - {start typing code}, and even if the UI took multiple seconds to actually get to the point that the code was being entered, the input would be kept.
Normal GUIs have discarded this for fairly good reasons. Especially when it comes to queuing mouse clicks. If you get down to the nitty-gritty of what it means to queue a "mouse click" it get very conceptually complicated. But you could create a GUI toolkit that still had the same idea integrated into it for a keyboard interface, if you have well-defined points where you are and are not accepting keyboard input.
I would submit that "keyboard-driven UI that is as intuitive as clicking with a mouse" is actually the wrong direction to cut on. You need to beat the conventional mouse GUI completely in some other dimension, one where it can't even compete. This is the only one I know of that has historical precedent.
The downside is that on a desktop I'm pretty sure you're looking at a completely new widget toolkit. Trying to force this on the current ones is going to be hard and could even be impossible.
If I were going to create a new web frontend framework, this is what I'd focus on to have an actual new feature that isn't just a respelling of the current set of features. And I can't guarantee that it won't also be missing something crucial, though, I think everything you need is actually there. You could even have modern nicities like, store the entire GUI field state transition diagram statically at the beginning and as the user types ahead of the GUI's current state, show them a rendered view of where they are going, e.g., the key sequence I showed above could be "[Rebates] -> [Rebate Receipt] -> [Name Field] -> [Address 1 Field] -> [Address 2 Field] -> [Rebate Code Field] -> [Entering {'A8F2-132A-9283'}]", live updating as it goes so if the user can just bang that out even while the first screen hasn't loaded they can even be sensibly editing the text input they're going to put in.
Combined with something as simple as making sure everything always has a keyboard shortcut in a defined format, which is conspicuously displayed every time you change something, e.g., every time the user clicks the Rebate Code Field you can also display something like "Ctrl-F R" or something so they also learn how to drive the screen with a keyboard and you would, if nothing else, have something different than what's out there today.
Anyone who wants to, steal this idea. I'm not going to do anything with it. I don't see this as something you want in every app necessarily, but people who spend hours a day in the same app for whatever reason would be confused for a week, then I bet you couldn't pry it from them with a crowbar.
I love this idea. I also just checked out your blog (jerf.org) which also has some gems.
The fundamental difference is that mouse input requires unpredictable motor movements. We can't queue mouse clicks because the user doesn't even know where a button is going to appear. Even if they did, the actual physical mouse movement needed to get there is different every time. There is a necessary mouse -> screen -> eyes -> hand -> mouse feedback loop for every action.
Keyboard input can, when designed well, be fully predictable and require no feedback loop with the computer. The motor movement involves a fixed set of physical buttons, which we can fairly easily train to press very reliably, and that training is then universally applicable across all software.
That is why you can buffer keyboard input but usually not mouse input. With keyboard input, I know what the software is going to do and I know exactly what hand movement will get it to do the next thing, so I can perform that movement even before it's ready. With mouse input, it's not really possible.
At this point what keeps me on Firefox is less the browser engine diversity than [tridactyl](https://tridactyl.xyz/), without which I feel almost helpless in a browser.
Keyboard driven is fine, when you have a keyboard. But many users are now on phones or tablets, with a severely limited keyboard that takes a big part of the screen. But they have a variety of gestures that regular desktop machines don't have. A good UI should happily handle both of these extremes, and everything in between.
"Just as it should be possible to perform every action with a pointing device, every action should also be possible with the keyboard."
"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.
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.
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.
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.
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.
Yeah, keyboard binding consistency is what I really want. Ideally, you could choose between Vim, Emacs, <whatever else> keybindings for the program you're using.
I think what's also needed is a standard way of navigating what I guess I'll call the "focus tree". For example, if I'm running Vim inside of a terminal multiplexer (eg: Zellij) inside of a terminal emulator inside of a tiling window manager (eg: xmonad)...
It would be GREAT if I could use Vi keybindings to navigate windows in whatever "focus layer" I'm at... and then have a "standard" keybinding to navigate up and down that tree (eg: "Ctrl + >" and "Ctrl + <").
Right now, everyone seems to solve the "focus tree" problem by trying to choose a control key combination that won't collide with any other process that might be listening for key chords at the same time.
Back in the early 1990s, mice were fragile enough that Apollo salespeople were trained to be able to do their demos keyboard-only as backup (at least for tradeshows) and that was just generally how interfaces were built. It wasn't an accessibility thing, it was a "we're demoing expensive systems to even more expensive people, it had better work" thing...
I moved to KDE from Gnome for a variety of reasons, but I genuinely miss Gnome and Native GTK apps. They weren't as customizable, but the features you did get work so well.
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.
You can set your own shortcuts in KDE. And there is a setting in the screenshot tool to auto copy to the clipboard.
> In fact, many GUI framework application guidelines explicitly encourage GUI application developers
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".
In some cases they do.
For example a GTK app main context menu can be triggered with F10. But this relies on the developer to correctly "tag" said context menu.
In simple cases it is obvious what to do, but in more complicated designs, where you may be able to achieve the same visual output in different ways, it may not be so obvious.
In that case, it is up to the developer as well to read and try to follow the published guidelines.
It used to annoy me that on Windows I could press ENTER to close a message box, but on Mac I had to reach for the mouse.
This is a very narrow viewpoint, considering the majority of computing is done on touch screens now. Sometimes keyboard controls are critical, sometimes they're not, sometimes your users don't care, sometimes they do. Sometimes a pointer is a better human interface for something, sometimes a purpose built controller is, sometimes a multi touch sensitive touchpad is. I wouldn't make an FPS that was just keyboard controls and the same is true of some other types of UIs. Just measure it and be creative and empathetic to how people will use your product who aren't like you and consider the physical interactions as a part of your design space and not just the software.
TUI, GUI.. we need a marriage of both, with configurable levels of integration, which controls to favour TUI or GUI. If it's well done, no need for a mouse, but nice and easy to have. Add to this a thin glove checking for certain movement patterns when the user is not typing and voice to set certain things - all at once.
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.
Yeah I would rather just have a single interface(the terminal) for all of the tools that I use that are keyboard driven by default. There isn't anything I need from a GUI that the terminal doesn't give me.
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
>I also can't cleanly nest and stack GUI applications in tmux like I can with TUI programs.
Sounds like a window manager problem
A GUI is indeed superior to a TUI. And keyboard driven should be both. But neither is my preferred UI. I want CLI programs callable from my shell.
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.
Shortcat.app fills some of this gap.
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.
Something like this?
https://www.homerow.app/
> 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.
>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.
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.
OCR will always ultimately be guesswork. It's up to the font used whether 1/I/l/| or O/0 or -/‒/–/—/― can be differentiated.
I am kind of obsessed with keyboard shortcuts, ever since discovering Vim a million years ago. The Vim shortcuts are burned into my brain.
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.
I work for a company that for years has had a very old-school, terminal style POS. Lots of key shortcuts. Like, black/white text terminal POS.
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.
Three levels of GUI workflow operation: touchpad < mouse < keyboard. This is the main reason people fall in love with programs like vim: with enough experience it allows one to completely eliminate interface friction.
I'll go one step further: anything you can do in a GUI should also be possible to do through a CLI and yes, also with code libraries. If webapps have n-tier architectures, then so should GUI software.
(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 do agree to some extent, but were GUIs not made specifically to reduce so much reliance on the keyboard? And a few people here did mention that this "fully keyboard-driven" workflow would probably be used by power users primarily.
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 submit that the point of the GUI was necessarily "anti-keyboard" as more "pro-discovery", plus adding gestures that would be difficult on a keyboard.
Keyboard interfaces can be, but not necessarily, quite opaque. There's a reason in the old days companies shipped keyboard overlays and function key templates to help users (or went all in with custom keyboards built for the application).
In contrast consider something like Wordstar where you pretty much just needed to memorize the three prefix keys, and if you pressed one and waiting, you'd get a menu describing all of the options.
Obviously, things like early Smalltalk and, probably, Xerox (having never used any of the early Xerox systems), relied heavily on the mouse, but even it had command accelerators.
The CUA standard was that crossover that Windows, and MOTIF, adopted. Much of that work is still with us today, and it worked well both on GUIs and TUIs (witness the old Turbo Pascal/C++ IDEs, and other applications). Those character based applications had to assume there was no mouse, but offer the flexibility of being good citizens should a mouse be present.
I miss Windows 98/XP and its fully keyboard driven UIs
Agreed, but what "prevents" it is that making a good keyboard-driven UI takes a lot of taste, extra effort to build it, and it must be revisited any time the UI changes. It's duplicated work.
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.
> extra effort to build it
Also extra effort to use it. This is why we have the “how do I exit vim?” meme.
A good user interface needs escape hatches so users can keep their head above water while they learn to swim.
Most of what people want when they say keyboard-driven is closer to a cockpit (requires expert knowledge) than a general purpose UI.
Besides JavaFX[1] are there any free, open-source, object-oriented, event-driven, cross-platform, native GUI frameworks that allow for keyboard-accessible UIs? Preferably using a modern language such as Go.
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/
Worth noting that Windows 3.x Paint could be used entirely from the keyboard, as the arrow keys moved the cursor and you could position it with pixel-precision. This is in addition to the fact that the rest of the OS was also entirely usable without a mouse.
Where possible, there should be keyboard shortcuts/navigation.
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.
The problem with keyboard navigation is that there seems to be no mature GUI keyboard-first UX concept. "Mouse things" are the way they are, because they fit the mouse-way. We need the same for the keyboard-way. Until then, there seems to be no design concept that can just be copied.
Top of my head:
- Tab to move across fields.
- Left-to-right, top-to-bottom focus.
- Space to toggle togglable stuff.
- Alt-Down Arrow to deploy drop-down stuff.
- Arrows to move around.
- Enter/Esc to accept/discard a modal.
Or maybe I misunderstand the things you call "mouse things".
This does not work great. What if you have a grid of 30 item, do you press 20 times tab to focus finally the item you want to interact with?
Keyboard design is much more, its also about how and where to place items, how things should move... it's a whole world. In the mouse world we have "discovered" those things and now we "just copy" other designs that we know work fine.
- Underlined letter: Alt-<letter> takes you to that field.
- Spreadsheet-like stuff: arrows, PgDn, PgUp, Home, End, … move inside of it.
> What if you have a grid of 30 item, do you press 20 times tab to focus finally the item you want to interact with?
If this grid a central component of the application and navigation inside it is very common, I would argue that there should be a way to quickly move around the cells. The "how" is up to the specific application and the paradigms it promotes. For example, line navigation in vim is possible with "<N>G", but such a shortcut would seem absurd in another application.
I love VIM-like TUIs, but the discoverability of of them is absolutely awful.
There is, whether or not developers follow it is a different story.
https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface...
I don't think this really addresses GP's comment as far as I understood it.
Your resource mostly describes how to make keyboard-based workflows accessible. But just because the full functionality of an app is keyboard accessible, doesn't mean that it works as well as the pointer-based approach - especially if you have an app with multiple menus, sidebars, headers, footers etc. Maybe you could tab through everything, but a pointer will be faster. This is where a "keyboard-first UX concept" is missing (from GP).
I think an interesting idea to solve this would be a "focus navigation mode". Enter this mode with 1 shortcut and then navigate between items with a few keys; like a combination of mnemonics and screen reader navigation e.g. jump between headers with "h" etc.
That's not what I mean. The site you linked is about how to make a mouse-first website more keyboard friendly, but what I would like to exist is a mature keyboard-first guide.
I mean something like this (my wip keyboard-first file manager): https://ibb.co/G3WBW5C1
The hard part is, there seems to exist no UI & UX design language I can follow to create a nice keyboard-first app, so I have to think through everything (which is fun but tiring).
>there seems to be no mature GUI keyboard-first UX concept.
I don't know about 'first' because I don't see a reason to privilege keyboard workflows over mouse workflows given how ubiquitous the latter is but Windows has had, for literally decades a 35 page Keyboard UI spec. They've put a fair amount of effort in applications being navigable in a consistent way.
https://learn.microsoft.com/en-us/previous-versions/windows/...
I love TUIs.
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.
Thats really true, small software thats easy to run, and launches instantly has a place in my heart as well. The get sh*t done centric workflow that TUIs offer is so unfortunately often lost in multiple layers of GUI controls...
No. GUIs exist across a spectrum of form factors and use cases, many of which would be terrible with a keyboard.
I'm a keyboard based UI lover, but I wonder if the supportive crowd is, and will ever, be too small.
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. ^^
On the web, keyboard accessible web UIs are a WCAG 2.1.1 level A requirement - that's literally the most basic level of accessibility standard (unless you count 'failed' as a level). If your website / web app isn't achieving that then you haven't tried very hard.
Keyboard driven, and keyboard accessible are not the same thing.
I’ve made a web application at work able to be keyboard driven one time and exactly 0 users out of thousands made use of it. People just don’t want to pay the upfront cost. In the old TUI days it was the only way to use something so you had no choice.
To be completely keyboard inaccessible I’d argue that you almost have to try and achieve it.
Someone explain this to Apple
This is something Windows and Mac OS got right in the 1990s. I remember reading specifically about it in terms of digital accessibility too at the time.
> The takeaway is simple. Do not compromise on the user experience you provide with your application
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)
You are right. Maybe the wording is a little too absolute. If you gotta ship and later try to slowly address any shortcomings in different areas, this is also a step in the right direction in my opinion. Just don't completely forget about those areas just because you have already shipped by that point.
this is absolutely not true since December 2025. the amount of "nice to have" items I've been commanding LLM to develop is a dream come true.
while being better at QAing i finally get the time to work on the things that got me into programming in the first place, which in the point where human interact with the machine.
> We gotta make trade-offs
You could compromise on not-shipping-before-it's-ready.
Or even the original premise of agile, which was to iterate on it. But "iterate" these days means "onwards to the next feature that we'll only drive to MVP", not, "polish & fix bugs" or … do things like enhanced UI for power users.
Not if you have a deadline.
I have seen more GUIs these days that don't support even the bare minimum of using tab to cycle through various fields and selector buttons. Which as I recall was introduced in like windows 3.0.
Or page up/down.
I'd posit that less than a half a percentage of users have used the page up/down keys in the last year.
A few years back I started to try to use my computer by not touching the mouse. Ended up writing a bunch of Tampermonkey scripts for my most used web pages to add fast keyboard navigation shortcuts.
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.
You can always take it to the next level by using an extension like vimium[1].
[1]: https://github.com/philc/vimium/
Yes I tried it for a while, it can be nice.
I've thought how i dislike both keyboard and mouse navigation from an ergonomics standpoint. Fine motor control for hours. I'd low-key want a neuralink beacuse speech is too awkward. Maybe mixed with eye monitoring.
I've been on this kick for a long time. A few years ago I was exploring a UI design tool that was entirely keyboard-driven, using pneumonic keychords inspired by Vim: https://github.com/danielvaughn/stride
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.
Ideally you should have both. Every action should be doable by mouse only and by keyboard only. That way you can cater to all kinds of users.
Adding keyboard support gets very annoying after a while. I recently posted a new version a package I made that makes it really simple to add keyboard shortcuts to javascript apps: keyboardist.io
fully keyboard-driven is a high bar, I'd settle for prioritizing the most common actions for keyboard shortcuts.
I would love a return to function keys. You get 12, make 'em count.
The mouse is amazing, if you have a good sensor, a mousepad and no mouse acceleration. Not many have this setup, but those who do can wield their cursor with insane speed and accuracy. Consider top osu! or Starcraft players.
I use a cheap notebook Logitech mouse, have for years, it's light weight is easy on my wrist. And I'm a gamer but to the FPS type games as much.
In video games, you're typically resting one hand on the mouse and the other on the keyboard fairly consistently.
Going back and forth between the keyboard and the mouse is what's awful about bad interfaces in my opinion, not the mouse as a pointing device.
I think we should also be finding ways to make things keyboard-driven that currently require a mouse. My side project is a keyboard centric flowchart editor which tries to merge the two between something typically 2D with pixel coordinates (normal flowchart software) and fitting it into a grid that has discrete coords so you can navigate with arrow keys.
The one UI invention many web UIs now add is the universal command search bar. I’m most familiar from it from Jetbrains IDEs where it’s been for over a decade and it is a remarkable upgrade on browsing menus. With the KeyPromoter extension on I even learned the keyboard shortcut over time. Good UI pattern and now this universal command search is everywhere: Cloudflare, Mercury, etc.
Love it.
Similarly, under macOS in most apps ⌘⇧/ opens a full menubar search which can surface most app functionality from the keyboard. Not quite as good as a command palette but close, and devs don't need to do anything to opt in except populate the app's menus properly.
Well TIL. Great tip. I only ever hit that key combination when I look around Finder and find myself unable to go up one level easily from the icon bar - an action I do constantly.
Well said. Now I just need a universal way to maintain consistency of my F-keys across all applications, including various browsers.
It is excellent when I can do common tasks in an application without taking my hands off the keyboard. Especially utility apps like a calculator or password manager that I usually just need for a few seconds.
Bitwarden used to be keyboard friendly, but recent updates have removed those functions for reasons I can’t understand.
No.
I agree completely and that’s exactly what I did for my site:
https://vimgolf.ai
I agree, it's bad if like your mouse isn't working and you need to use a app that only works with a mouse
Command palettes are great in this regard. They make commands accessible and discoverable entirely from the keyboard. I'm happy to see them becoming more popular.
Honestly, it'd be nice if people remembered about keyboard controls more often. I'm not saying it should replace the mouse, but it'd be great if both options were kept around
Yes, for efficiently of course but at the very least for accessibility.
I really like this kind of thing but I wish there were more tutorials to help get good with keyboard shortcuts. vimtutor was lifesaving
My take in this case is to learn incrementally. Like the pebbles in the shoe, I remove the more painful one first (the shortcut for the action I do the most), get used to it, then remove next more painful., and so on. Usually I begin to get a little comfortable with 4 or 5 shortcuts.
I hate nothing more than when a random mistype on a website or app causing shit i don’t understand to happen without reasonable ways to undo it or discover it. I don’t really care if the app can be controlled with a keyboard i want the ui to be discverable and usefull.
This can happen if the applications exposes single keys as shortcuts. If they are "hidden" behind the different modifiers (i.e. Ctrl, Cmd, Alt), then mis-clicks should not be possible or should be more tolerated.
The "intuitiveness" argument is also related. You cannot rebind well-known shortcuts to different actions and expect the user to not get frustrated.
I agree, but it's not that easy.
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.
Such a funny coincidence. I opened HN in this new, 100%-rust browser[1] I'm working on to actually test some keyboard fixes I did last night.
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
This was my point in my comment[0] in that thread. I've used GUI Emacs for years, it's way better than the TUI version and fully keyboard driven.
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
Honestly, they should be keyboard first. Yes, let all the mouse stuff work as normal, but choose keys so that the fastest way to navigate the app is with the keyboard whenever possible.
>But I want to oppose a recurring argument in favor of TUIs that in my opinion does not have a solid foundation. To paraphrase various commenters: TUIs should be preferred because they are keyboard-driven.
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.
Can we start with TUIs? At some point Claude code CLI stopped responding to the keys I had been using to scroll the presented plan and it seems only the mouse wheel works
People gave the ribbon interface a lot of shit but one thing they definitely got right was making absolutely every option reachable from some keyboard shortcut. Some of the shortcuts get a little long but you can just add those as a hotkey if you use them a lot.
I agree 100%. The mouse is great and I don't think GUIs should drop it or anything, but it's wonderful to have the ability to keep your hands on your keyboard when doing data entry tasks and the like. I also think that when you design for both keyboard and mouse input, it will force you to consider rough edges of your UI design in a way that you wouldn't have to if you were just designing for one. So the app will be better as a result.
Co-sign. This is one of the reasons I’ve always loved NetNewsWire as my RSS reader and few things have been able to displace it. Everything is doable by keyboard, and the keyboard commands are extremely logical and intuitive. You can FLY through your backlog.
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'm surprised there's only a single mention of tiling window managers here. No talk about i3[0] or hyprland[1]?
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
Why though?
The way we are moving I believe soon we will be talking to the websites not just clicking or typing around...
Spin up a Windows 3.11 and later instance to try this out.
That title reads like a spoof of hackernews culture
My issue is that taking a strictly GUI driven approach makes you build an application (in the browser presumably) that will require more permissions than you would typically want in the terminal so TUIs win out by being in proximity to those tools (cat, ls, rm, etc) for development use cases
yes please ! even AI would appreciate this !
Keyboard driven UIs are easier to instrument by alternative interfaces and has very positive accessibility implications. However, "shoulds" in computing lead toward a "tyranny of compounding responsibilities"; adding interface complexity to a project, particularly the suggested alternative input vectors may cross an upfront and/or maintenance development cost limit for a project.
A lot of comments on VIM here. Vim is a terrible example and a pretty bad design overall, objectively. Legends of great productivity with vim is highly legendary, i.e. fiction. Classic Notepad/Word and similar Guis that have been widely adopted in Linux windowing systems are clearly superior and that's why they're so widely and silently adopted. Not a lot of fanfare for hierarchical GUI menus with keyboard shortcuts.
Your making a subjective statement not an objective one about VIM.
Objective would be making the statement that not all GUIs need to be keyboard-driven manged or have accessibility built-in.
Example, GUIs in automation are primary touchscreen driven and have user requirements base on the environment they are in.
GUI standards are objective to who the users actually are or will be.
But it is really hard to remember the shortcuts
You don't really need to remember everything though. Mouse navigation does not need to go away. The keyboard shortcuts should be available if you opt to use them, after which point you will be able to memorize them in short time.
The intuitive part of my argument also falls under this. By following known conventions as close as possible, we can eliminate the need to remember the most common actions.
Additionally, it is important to present your shortcuts in a shortcut window/dialog in a logical way for when the user needs to remember something.
In any case, an excesive number of keyboard shortcuts can have a negative effect on usability, so this is also important to keep in mind.
Tool-tips, having an accelerator next to the item in the menu/context menu, accelerator underlines, god forbid documentation … UIs have long had ways of having a simple way and hinting at, documenting, or showing to the user how to accelerate if you want to get quicker.
Why, are we speed running the de-evolution of UI?
Because not everyone has a mouse or is able to use a mouse. Accessibility matters.
Not everyone has a (non-screen) keyboard either, you know.
Right, so we should have both options.
Yes and no. The big advantage of a GUI is having interactive 2D coordinate input support (aka a pointer, or gestures.) While I think a keyboard can be a great control surface, that’s one thing it really lacks and only GUIs really offer. So to enforce that the whole GUI must be keyboard-drivable requires limiting the major advantage of the GUI. I’m a fan of the Emacs or Plan9 styles where the keyboard and pointer are able to be used together synergistically. You also see some of this in tools like video, DAW, and 2D/3D graphical scene editors.
I agree. I mention this briefly in one of the footnotes. There are some tasks that greatly benefit from the mouse (e.g photo editing tasks where arbitrary region point and click is required).
This does not contradict the argument. The rest of the interface, everything that is known and stable in advance, should be full keyboard-driven.
What's specifically is the limitation?
ain't no way my mom is learning vim
Read the article. The argument is not "GUIs should require keyboard navigation", it's "everything should be possible with the keyboard".
I'm glad the fad of TUIs are dying, I don't get the hype of them.
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/
> gpui.rs
I clicked. Never trust a gui library without screenshots.
I'll never quit building TUIs, though. I'm building more TUIs now than ever, with AI assistance making it easy.
> We just need better, efficient and faster GUIs to put these TUIs to an end.
I think, firstly, we need less meaningless red-tape shenanigans from MS/Apple to publish GUI apps
> We just need better, efficient and faster GUIs to put these TUIs to an end.
Well, yeah, it just that those GUIs failed to appear for at least 30 years.
> It is time to move on from using this arcane technology from the 60s-70s.
You mean the GUIs? They were being in development since the early 70s, you know, but they really have flourished in the 80s. So, it's already a 40-years-old paradigm that still haven't managed to displace another contemporary paradigm of TUIs. Well, who knows, maybe in 40 more years it'll make it.
TUIs are an abomination and most GUIs should just be web.
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.
> and most GUIs should just be web.
Yikes, no! One of the reasons old timers like me say that using a computer has sucked a lot in the last ~20 years is the use of a browser as an interface to everything.
If you want to make an app that needs a browser to use, then please drastically improve the browser's interface. I mean, this is a no brainer. TUIs are way more superior to doing things via Safari/Firefox/Chrome.
> most GUIs should just be web.
Hard disagree. Most web interfaces are worse than most native UIs. Inconsistent rendering, keyboard shortcuts and navigation between apps, slow response times, and more.
There's a reason everyone who knows what Electron is bashes every "native" app built with Electron.
yeah--the reason is the bloat and overhead electron brings.
nobody cares about the web layer
You're ignoring all of the other things I said.
Keyboard shortcuts, navigation, and more are inconsistent in web apps. Will they work at all? Will they use different keys? No one knows. Will they respect my OS theming? What about my font choices or font sizes? Almost certainly not.