Exploring the design space of keyboard shortcuts

[hikchoi]

• Dendron is built on top of VSCode that is already a very complex system itself that can be used with an arbitrary number of user contributed extensions.
• With a constantly growing number of commands, we have to start discussing how we want to manage keyboard shortcuts for Dendron.
• The goal of this discussion is to keep track of the ideas pertaining to design decisions about default keyboard shortcuts of existing / new Dendron commands, how to minimize friction to users that already have a working mental model and expectation of how a keybinding should work on a text editor (or an extension that relies heavily on a text editing base software), and so on.

If you had any difficulties getting used to the keyboard shortcuts of Dendron commands, feel free to express it here as they are valuable insights to how we want to move forward with shortcuts. More general thoughts on this matter is of course welcome as well :)

[hikchoi]

A feedback from a Discord user about clashing keybindings prompted this discussion.
I happen to have opened an issue that addresses the exact concern a while ago so I'll start by linking that here : #481

[ddbrierton]

I haven’t been using Dendron long enough for any keybinding to have become a reflex yet, so I wouldn’t mind if they all changed!

I don’t know what the correct technical term is, but some key binding in VS Code are “melodies” rather than “chords”. By “chord” I mean all keys depressed simultaneously, e.g. “cmd-shift-n” for new window; and by “melody” I mean a key combination followed by another, so Zen mode is triggered by “cmd-k” followed by “z”.

On my VS Code “alt-d” (for Dendron) is currently free. So we could use “melodies” starting with “alt-d” followed by another key for a whole slew of Dendron commands.

[xypnox]

I use Ctrl+M <chord> for this as M stood for markdown for me and I have chorded a few actions with it. I am also open to other chords but I like the idea of having a central chord for dendron as well.

[hikchoi]

as mentioned here I think an approach like this would isolate the dendron specific keybindings (until there is a conflict with a very popular chord sequence outside of Dendron, of course).

as for making this a default, I have some questions that I'm asking myself (that I have not yet explored deeply yet):

1. How much of a mental barrier would a chorded keybinding introduce? Would a person who are mostly used to keybindings that use one or two modifiers be put off by the extra step of sequencing the keys? If so, is avoiding the conflict by isolating the set of keybindings into a central chord worth the barrier it creates?
2. With the extra step of sequencing the chords, how do we avoid keybindings that are hard to maneuver?

[ghost]

maybe we could look into an integration of which-key that would reduce the friction of needing to remember the keybindings. Since we would have a dendron menü that lists all commands, while still being keyboard user friendly.

[vicrdguez]

maybe we could look into an integration of which-key that would reduce the friction of needing to remember the keybindings.

I'm using exactly this, which-key is awesome for this situation and I have all the dendron commands grouped together, but in my case I use vim keybindings so the leader key space on normal mode is not a problem. Not sure which leader key would work for people not using modal editing.

[simkimsia]

I installed which-key but i am still confused. Not using vscode-vim .

Can advise?

[simkimsia]

Came over from #1587. I have a clash with cmd + shift + down which triggers lookup. Typically most people use cmd+shift+down to select current line till end of file

[fnurl]

Yes, I think one principle regarding keyboard bindings that all applications should have is to "stay away" from global OS bindings, such as Cmd+C/Ctrl+C etc. which the above binding should be categorized as.

[chmac]

I think a key question is are you interested in supporting non developer users? If yes, you likely have 2 groups of users. Those who use VSCode & Dendron exclusively for notes, and those who use it for development + Dendron. We could call them Users and Developers.

For example, I've been recommending the digital garden concept to a few people recently. Most of the non developers I spoke to preferred the visual appearance and relative simplicity (compared to VS+Dendron) of logseq. While I (developer) prefer the flexibility and power of Dendron. Personally, I'm considering using VSCodium for Dendron exclusively, and VSCode for my development. That would put me in both categories in some way.

Users - Likely expect simple to remember shortcuts that are similar to other programs. So only chords. They also likely don't care if you overwrite default actions in VSCode, because they don't use VSCode, they only use Dendron.

Developers - Likely already have a lot of shortcuts configured and don't want Dendron to compete with them. In this case, using a melody approach would make a lot of sense. One activation command to remember for dendron, then shortcuts which are more easily remembered because they're somewhat mnemonic.

[Sidenote]: One other note to add, GitHub uses multi key shortcuts on their web ui. g i (melody) for issues, etc. I'd say this is evidence that the pattern is becoming more widely known.

In an ideal world, Dendron would support both. During install / setup, ask users if they want to overwrite default shortcuts, or if they prefer the melody approach.

[fnurl]

I wrote earlier that I think that applications should "stay away" from global OS bindings. Another area I that should not be overridden lightly are default VSCode bindings. One such example is how Dendron has bound Cmd+Shift+S (macOS) which defaults to "Save as..." in VSCode to "Create New Scratch Note".

I think that using sequence keybindings with a separate namespace (prefix) for the extension is a good way to go. Alt/Opt+D was suggested earlier.

Coming from vim, it is not uncommon to allow the user to specify a plugin leader key which is then used as the keyboard binding prefix for all plugin key bindings. I'm not sure if that is possible in VSCode, but that would allow the user to choose a leader keybinding that is available to them. I e.g. use the PlantUML extension that adds a binding to Alt/Opt+D, so if Dendron had had a key sequence system with a customizable leader binding, I could have opted to use another keyboard binding as my Dendron prefix if the default one is already taken in my setup.

[pjboro]

This is a very reasonable answer. Overwriting default shortcuts of the operating system or the host application (vscode) is a very inconvenient practice. Users learn these functionalities by heart over the years and going against these chords that are so hard-wired into their brains is really spoiling the UX. Not being able to insert a line below using Ctrl + Enter shortcut makes me sad every time I edit my notes.

Coming from vim, it is not uncommon to allow the user to specify a plugin leader key which is then used as the keyboard binding prefix for all plugin key bindings.

I did not use vim extensively, but thought-through keybindings and sequences are one of its winning traits.

I'm not sure whether dendron could move away from already overwritten shortcuts, but IMHO it should definitely abstain from overwriting any further ones. If restoring default vscode behaviour would be possible - the faster the better. I suppose dendron will become more popular (it's great in its niche) and it would be great to spare new users some pain and make them feel more at home.

[ghost]

After looking a bit at the VSCode Extensions Api and Contribution Points I figured, that it would Require a bit more work then just providing a Config option to set a Leader key.

We would need to detect the config change, and then check if the User already has defined Keybindings. (For dendron that differ from the default ones) Ask the user if he wants to overwrite these keybindings with new chorded ones Based on the default, wants to add the specified Leader as a first chord, or wants to replace the first chord key with the selected leader key.

Furthermore we would need to consider, if the default Keybindings already provide a chorded key binding do we then want to replace the first part of that chord with the newly selected leader key.

I guess I could create an example extension that provides this functionality.