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.

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.

I recently had a revelation when I made an extended qwerty midi controller app that permanently shows the states and functions of all keys including when modifiers are held.

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

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

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

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.)

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?

I use Vimium [0] for this very reason -- highly recommend it! Although admittedly this only solves for a fully keyboard-driven _browser_ experience.

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

last time i built a crud app (oh maybe about 24 years ago) i made it a point to do this. i remember watching the payroll people fly through their terminal mode vax vms applications with such speed and dexterity that it would make any unix admin well versed in the art of the command line blush and it made me think "oh yeah, all these 90s point and click guis got it all wrong. if people are required to make heavy use of a system at work, they would prefer a learning curve followed by speed, comfort and dexterity over an easier learning curve that trades dexterity for discoverability."

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

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

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

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.

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.

One of the pieces of software I sell is motorsports timing software [0], it has a GUI for newbs, but at the bottom of every window is a little bar that shows the list of shortcuts. People pick them up quickly!

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

[0] https://sidewaysdata.com

Couldn't agree more, but I think it's majorly a "geek" thing. I'm using i3 on my personal linux and aerospace on my work mac ; vimium in the browser, Neru on the other apps (does something similar to Neru). I recently ended up finding a way to create user-scripts for electron app and since then I'm adding vimium-esque extensions (e.g. in Teams) wherever I go.

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

"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.

> 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".

https://vimium.github.io/

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

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

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.

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.

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.

Given Bloomberg Terminal's success, and all the IBM terminals at warehouses and big stores - this is more than apparent. But only few understand UI to design it right.

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.

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.

For people who want to navigate browsers only with the keyboard, I recommend vimium https://vimium.github.io/

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

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

And tablets should have a "direct touch only, all options present mode" (no long-presses, no drags, no drags from edge, no swipes." It would really improve accessibility.

There is much more to it.

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

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

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

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

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.

In the latest app my company is working on, we deliberately wanted to support usage over SSH.

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

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

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

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.

> 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.

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.

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...

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.

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 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.

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.

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

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.

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/

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.

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.

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.

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.

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.

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.

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.

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'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. ^^

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.

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.

> 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)

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 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.

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.

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.

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.

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.

No. GUIs exist across a spectrum of form factors and use cases, many of which would be terrible with a keyboard.

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.

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.

I agree completely and that’s exactly what I did for my site:

https://vimgolf.ai

I miss Windows 98/XP and its fully keyboard driven UIs

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

I really like this kind of thing but I wish there were more tutorials to help get good with keyboard shortcuts. vimtutor was lifesaving

Yes, for efficiently of course but at the very least for accessibility.

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

to a man with an LLM everything looks like a nail

Someone explain this to Apple

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.

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

>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.

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

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.

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.

I am sad to see what happened with GTK. It seems gtk2 was the last good GTK version. Then it went downhill from there.

Why though?

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

No.

Well said. Now I just need a universal way to maintain consistency of my F-keys across all applications, including various browsers.

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

Spin up a Windows 3.11 and later instance to try this out.

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

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 !

But it is really hard to remember the shortcuts

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.

Why, are we speed running the de-evolution of UI?

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.

ain't no way my mom is learning vim

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/

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.