I agree that GUIs should be able to be entirely keyboard driven: it is critical for many accessibility input methods.
I disagree with it being easy.
It is easy to make a UI in which everything is accessible from the keyboard - you just have to have a unique binding for every option.
Actually making a keyboard accessible interface means you need to have correct ordering of options, you have to ensure that your app is doing the right thing for the host platform, not what you think should be correct, not what your primary platform does. It needs to do what the user of the platform expects, because that's what they're using.
You also can't just defer to endless chords: many people who use what appears to your application to be a keyboard, are not actually using a keyboard, chords are often very slow and clunky.
Another thing I've seen is proponents of modal interfaces claiming that they're superior, but if the interface is modal you need someway for the user to know that - things like vim basically rely on the character in the bottom left forcing people to basically try to do something and get the feedback of the action being disallowed, while at the same time contending with some things that they do being permitted because the mode they're in does have an associated action, just not the one the user was trying to do.
UI is hard.
It does not matter what the renderer is (e.g. a GUI app being displayed in a terminal is still a GUI app so needs to consider both control modes), and simply saying "you can do everything from a keyboard" does not make it good, and it certainly does not make it "easy".
Unless the quality of the interface does not matter.
What do you think about Vimium's UI? https://youtu.be/t67Sn0RGK54
I specifically find the F key (to press a button on the page) interesting. It's modal, but it pops up indicators of what keys you need to press next, so you know what mode it is currently in. It's not faster than the mouse, but it's still reasonably convenient for navigation if I don't have one plugged in.
Command palettes (like M-x in emacs) are helpful here, though they're not great for context-specific discoverability. This led Nextjournal to the "command bar", as they explain along some historical background on the problem (e.g. lisp machines, which-key). Disclaimer: I used to work with this team, but not on this project.
I don't know emacs, but "command palette" is one way how I'd describe the traditional menu bar. Macintosh computers have a menu search and i think that's a good idea. In my gui lib, I do menus as auto-generated from annotated functions and arguments whenever I can, which also can be exposed as script things (though that's sometimes awkward).
100%, when you look at Emacs and the number of ways you can set it up to have special commands, macros, keybindings that work in some modes only (like Python mode, or markdown mode) or commands that work everywhere, or contextual menus based on previous actions... The layer you need to actually make events behave correctly based on input is very complex.
My standard reminder: there is already a standard for this, and it's called CUA.
Windows complies. Xfce is very good. MATE, LXQt, LXDE, and some others make a stab at it, mainly in visual layout. KDE is quite poor because they reinvented the whole thing without understanding how and why it works. Ubuntu's old Unity desktip is excellent at it, despite looking more Mac-like.
GNOME is atrocious at it because they've ripped out most of the controls without having any plan for what to replace them with.
Most what are now called "traditional" desktops -- you know, taskbar, start menu, tray, something like a 2-pane file manager -- are vaguely compliant.
You already know how to use it it's just that everyone has forgotten there is an actual original Thing here that every modern GUI and most TUIs apes without knowing what it's copying or why.
I'm a raving fan of the command pallet or it's adult friend the find any action since there are a finite number of chords that I can remember as one switches between applications and operating systems but describing the action almost always works. Bonus points if the "find action" indicates the currently bound shortcut, so it can serve as a quick reference
I think that M-x or its : sibling also quality, although without the quick reference part. I actually backed a Kickstarter project that was trying to bring that M-x behavior to some of the popular gui toolkits to enable it in a lot more apps but it didn't shake out, presumably because it was way harder than they thought (heh, Kickstarter, amirite?!)
Yep. Much better title. But I guess the title might've been intentionally made clickbaity by trying to sound like it's a hotter take than it actually is.
More than default keyboard shortcuts what I want is customizability. Because of the wide variance in keyboards and humans there is no single keybinding layout that will work well for everybody. It should be possible to bind one or multiple(!) keys to any action the user may want to execute. This applies to both GUI and TUI apps.
olliej | a day ago
I agree that GUIs should be able to be entirely keyboard driven: it is critical for many accessibility input methods.
I disagree with it being easy.
It is easy to make a UI in which everything is accessible from the keyboard - you just have to have a unique binding for every option.
Actually making a keyboard accessible interface means you need to have correct ordering of options, you have to ensure that your app is doing the right thing for the host platform, not what you think should be correct, not what your primary platform does. It needs to do what the user of the platform expects, because that's what they're using.
You also can't just defer to endless chords: many people who use what appears to your application to be a keyboard, are not actually using a keyboard, chords are often very slow and clunky.
Another thing I've seen is proponents of modal interfaces claiming that they're superior, but if the interface is modal you need someway for the user to know that - things like vim basically rely on the character in the bottom left forcing people to basically try to do something and get the feedback of the action being disallowed, while at the same time contending with some things that they do being permitted because the mode they're in does have an associated action, just not the one the user was trying to do.
UI is hard.
It does not matter what the renderer is (e.g. a GUI app being displayed in a terminal is still a GUI app so needs to consider both control modes), and simply saying "you can do everything from a keyboard" does not make it good, and it certainly does not make it "easy".
Unless the quality of the interface does not matter.
[OP] an_origamian | a day ago
What do you think about Vimium's UI?
https://youtu.be/t67Sn0RGK54
I specifically find the F key (to press a button on the page) interesting. It's modal, but it pops up indicators of what keys you need to press next, so you know what mode it is currently in. It's not faster than the mouse, but it's still reasonably convenient for navigation if I don't have one plugged in.
daveliepmann | 19 hours ago
Command palettes (like
M-xin emacs) are helpful here, though they're not great for context-specific discoverability. This led Nextjournal to the "command bar", as they explain along some historical background on the problem (e.g. lisp machines,which-key). Disclaimer: I used to work with this team, but not on this project.adam_d_ruppe | 15 hours ago
I don't know emacs, but "command palette" is one way how I'd describe the traditional menu bar. Macintosh computers have a menu search and i think that's a good idea. In my gui lib, I do menus as auto-generated from annotated functions and arguments whenever I can, which also can be exposed as script things (though that's sometimes awkward).
daveliepmann | 12 hours ago
The magic of
M-xis that every interactive function in emacs has a name that can be found+invoked like menu search with that short keystroke.natfu | 14 hours ago
100%, when you look at Emacs and the number of ways you can set it up to have special commands, macros, keybindings that work in some modes only (like Python mode, or markdown mode) or commands that work everywhere, or contextual menus based on previous actions... The layer you need to actually make events behave correctly based on input is very complex.
lproven | 17 hours ago
My standard reminder: there is already a standard for this, and it's called CUA.
Windows complies. Xfce is very good. MATE, LXQt, LXDE, and some others make a stab at it, mainly in visual layout. KDE is quite poor because they reinvented the whole thing without understanding how and why it works. Ubuntu's old Unity desktip is excellent at it, despite looking more Mac-like.
GNOME is atrocious at it because they've ripped out most of the controls without having any plan for what to replace them with.
Most what are now called "traditional" desktops -- you know, taskbar, start menu, tray, something like a 2-pane file manager -- are vaguely compliant.
You already know how to use it it's just that everyone has forgotten there is an actual original Thing here that every modern GUI and most TUIs apes without knowing what it's copying or why.
downrightnifty | 11 hours ago
Anywhere I can read more about this? The Alt+[letter] mnemonics seem to work on most of the KDE applications I've tried, at least.
datboi | a day ago
Reading this just reminds me that I wish more applications implemented modal editing/navigation :(
mdaniel | a day ago
I'm a raving fan of the command pallet or it's adult friend the find any action since there are a finite number of chords that I can remember as one switches between applications and operating systems but describing the action almost always works. Bonus points if the "find action" indicates the currently bound shortcut, so it can serve as a quick reference
I think that
M-xor its:sibling also quality, although without the quick reference part. I actually backed a Kickstarter project that was trying to bring that M-x behavior to some of the popular gui toolkits to enable it in a lot more apps but it didn't shake out, presumably because it was way harder than they thought (heh, Kickstarter, amirite?!)ayba | 19 hours ago
GUIs should be fully keyboard-drivable*
RaphGL | 17 hours ago
Yep. Much better title. But I guess the title might've been intentionally made clickbaity by trying to sound like it's a hotter take than it actually is.
donio | 6 hours ago
More than default keyboard shortcuts what I want is customizability. Because of the wide variance in keyboards and humans there is no single keybinding layout that will work well for everybody. It should be possible to bind one or multiple(!) keys to any action the user may want to execute. This applies to both GUI and TUI apps.