GUIs should be fully keyboard-driven

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

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.

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.

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

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

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

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.

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

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 really like this kind of thing but I wish there were more tutorials to help get good with keyboard shortcuts. vimtutor was lifesaving

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

But it is really hard to remember the shortcuts

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.

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

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

yes please ! even AI would appreciate this !

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'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/

ain't no way my mom is learning vim

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.