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.
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.
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.
No clutter, but hints come as you stutter on what to press next
Some examples of what you are asking for can be found in videogames due to controllers
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.
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.
It’s in the accessibility settings.
https://support.apple.com/en-za/guide/mac-help/mchlc06d1059/...
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".
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.
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.
Which ones, besides web frameworks pretending to be desktop ones? Most if not all frameworks I know support keyboard navigation.
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.)
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.
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.
Underlining the accelerator key is subtle and shouldn't be overwelming. Keyboard navigation unaware users probably won't even notice.
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.
God forbid I should ever be forced to use Blender or Inkscape with only buttons.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
- 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".
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.
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.
https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface...
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.
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).
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.
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.
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 could compromise on not-shipping-before-it's-ready.
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.
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.
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’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.
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.
Bitwarden used to be keyboard friendly, but recent updates have removed those functions for reasons I can’t understand.
Love it.
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.
The "intuitiveness" argument is also related. You cannot rebind well-known shortcuts to different actions and expect the user to not get frustrated.
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!
The way we are moving I believe soon we will be talking to the websites not just clicking or typing around...
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.
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.
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.
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.
I think, firstly, we need less meaningless red-tape shenanigans from MS/Apple to publish GUI apps
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.
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.
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.
nobody cares about the web layer
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.
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.