Posted by ckardaris 15 hours ago
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
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.
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.
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.
How to exit is literally the second thing `vimtutor` teaches you, after hjkl cursor movement.
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.
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!
- 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.
- Spreadsheet-like stuff: arrows, PgDn, PgUp, Home, End, … move inside of it.
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).
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/...