Has anyone seen any paradigms they really like for keyboard-navigating big, abstract mediums that aren't text? i really like how text can be keyboard navigated easily. Where your cursor + attention is about to go is always clear and we've invented lots of ways to accelerate getting your cursor to where you want it to go. How does that play out in things that aren't text though, like all the flow based languages we're seeing, or tools like Webflow that are trying to make it fast to create trees of stuff? Are we destined for slower mouse based interfaces that don't leverage muscle memory as much?

I find folding cumbersome due to a lack of mapped, memorized, and practiced keys for performing the higher level navigation actions I would want to execute.

Check out Grant’s work: https://constraint.systems He does experimental design tools with a Vim vibe to it.

I’ve been investigating this a bit. I made a prototype of a keyboard-oriented html/css editor a while ago, haven’t revisited it since but you might find it interesting as a non-text example of keyboard UI. Also seconding @Prathyush, check out grant’s work! https://twitter.com/yoshikischmitz/status/1185189779521953798?s=21

Yoshiki I see it's been about a year since those tweets—maybe time to resume that project? 😛 (really cool though—don't think I'd seen that before)

@Harry Brundage check out my demo of Flowsheets for some keyboard-based navigation:

thanks for these links friends!

they mention how wikipedia is a perfect case for mouse UI in that twitter thread and keyboard navigation would be awful for that kind of content

Another keyboard navigation pattern I like is vimperator’s hint-mode for clicking on links, tho it can get crowded. I wonder if one could make a hierarchical version of it to reduce visual clutter: https://en.m.wikipedia.org/wiki/Vimperator

Superhuman.com is doing a really great job on this front. It's an email client that encourages you to be 100% keyboard-driven. Mouse is optional. Everything is set up very intuitively.

^ an interesting thing about superhuman is the culture and aesthetic they’ve fostered around keyboard shortcuts. I feel like they’ve made keyboard shortcuts cool and sexy, this desirable skill to master, and kinda turned it into a fun game of mastery.(tho I’m not the target audience, being someone that writes at most a couple emails a week) The VIM community also has a culture of respect for high keyboard usage but... well VIM isn’t quite as cool(I say this as a long time user)

Negative points for the rather invasive on-boarding of superhuman. They want loads of personal details before you get anywhere. I was put off by the 'fill in a load of details and a questionnaire, and then later we'll let you in for 30$ approach....'

@yoshiki Keyboard shortcuts are like learning a musical instrument: there are pluses and minuses. Is this particular instrument worth mastering?

@yoshiki a nice example of that sort of "jump to it" keyboard interface (that I use all the time) is `ace-jump-mode`:

FWIW, I use https://github.com/easymotion/vim-easymotion for the same thing in Vim.

i was reading about Kakoune the other day (https://cosine.blue/2019-09-06-kakoune.html) and they made a really interesting insight into the vim motion commands that i really like

Whereas vi’s keystroke language follows verb-object order, Kakoune inverts that by following object-verb order. In real terms, that means you make a selection (object) before deciding what to do (verb) with it. The object might be a character, word, sentence, paragraph, parenthetical, regular expression, you name it; the verb might be delete, yank (copy), change, indent, or even transformative operations like lint, format, uppercase, etc. In Kakoune, it is with this reversed grammar, this postfix notation, that you interactively sweep up a group or groups of characters before acting on them. That way if your object isn’t quite right, you can immediately correct it without having to undo and redo your verb.

Totally agree with the above point about difficulty navigating layout you don’t control with the keyboard. In general navigation seems to be the trickiest bit of making an application keyboard centric. On the keyboard the basic movement is really only (up, down, left, right) and if the layout makes it unclear where those directions will take you it’s hard to make it feel really good/be usable. Fixed layout ui’s can get away with some navigation that doesn’t make as much sense since the user can gain familiarity. Fluid layouts like a flowchart editor inherently dont have natural up/down/left/right navigation that will be quick and intuitive. I think the interaction model of jumping around to the nodes and edges of the flowchart is just not well suited to the keyboard as an input device. For flowcharts + keyboard maybe the right approach is going with the ‘grain’ of the keyboard and build a really good graphviz (or graphviz like language) editor with augmented text as the primary interaction mode. And then have mouse manipulation as a secondary interaction for smaller layout tweaks. That way you could assemble graphs as fast as you can type. Another route would be to build on a different input device better suited to the task of flowchart construction like ipad