Keyboard Shortcut Editor - User Interface

[anjulalk]

The purpose of this post is to discuss possible layouts and designs for the new keyboard shortcut editor.

Special attention needs to be paid regarding the following points:

1. How to know if a shortcut is enabled, or disabled
2. Has the shortcut has been changed by the user, or is it the default value
3. How the current shortcut should be displayed
4. How to edit a shortcut
5. When editing a shortcut, how to
   i. Save or cancel the edited shortcut
   ii. Restore the shortcut to its default
6. How to import/export a current shortcut scheme

Below is my initial design for the Editor. I’ll discuss possible variations later in the post.

Keyboard shortcuts are shown in a table, along with a search box to filter shortcuts by their label.

1. How to know if a shortcut is enabled, or disabled

Disabled shortcuts don’t have their key combination in the relevant area, while enabled shortcuts do. In the above design, “Quit” command doesn’t have a shortcut in that field, therefore it’s disabled.

We can also add a label, such as “Disabled” or “None” in the shortcut field. But I think that would bring more clutter to the interface.

2. Has the shortcut has been changed by the user, or is it the default value

Default shortcuts have their commands in regular text, while user-changed ones are in italic formatted text.

An alternative would be to add a separate field to say if its the default value or from the user.

This layout is similar to VS Code. However, I think the original layout is better because it’s less clutter, simpler, and doesn’t waste a lot of space. The space is not worth the importance of the information shown there.

3. How the current shortcut should be displayed

Joplin is a cross-platform application built with Electron, and uses Accelerators to define the key combination of keyboard shortcuts. Due to the cross-platform nature, Joplin should use modifiers such as CommandOrControl and Alt instead of Option.

To improve the user experience, these modifiers will be converted to the current platform in the presentation layer. For example,

• CommandOrControl or CmdOrCtrl -> Cmd on macOS and Ctrl on other systems
• Super -> Cmd in macOS, Windows in, uh, Windows?
• Alt -> Option in macOS (This one is really optional though)

When saving the shortcuts, the process should be reversed for the sole purpose of making importing and exporting possible across different platforms.

4. How to edit a shortcut

The user would double click on the shortcut field of relevant command. Refer “New to-do” for an example. This shows a field which captures the pressed key combination.

If the user just hit Enter without pressing any key combination first, the shortcut would be disabled. To enable it, the user can again double click on the shortcut field (which is now empty) and press a key combination, and hit Enter.

5. i. When editing a shortcut, how to Save/Cancel the edited shortcut

In the above designs, the user is editing the shortcut for the “New to-do” command. Pressing “Enter” will save the shortcut, and pressing “Esc” will cancel and the previous value will retain.

Another method is adding two buttons, one to Save and one to Cancel. Refer below design (Ignore the “source” section)

I prefer the former because it’s just convenient to press Enter/Esc rather than using the mouse or using touch-pad to click on a button.

5. ii. When editing a shortcut, how to restore it to its default

I think a simple button next to the shortcut field would suffice, as shown in the first and second designs.

Optionally, we can display this reset button on all user-updated shortcuts as well. But this comes at a cost of users pressing it accidentally. That’s why I suggest only include it when the user is editing the shortcut.

6. How to import/export a shortcut scheme

Import and export buttons are located in the top right corner. “Export” will be disabled if there are no changes by the user and currently using the default shortcuts for all commands.

Thank you!

[tessus]

You brought up very good points and I have to think about them a bit.

However, one thing that stood out was the first question. When I wrote my previous post regarding disabling a shortcut I suggested to use a separate field enabled=true/false. Because I imagined the UI and a checkbox that says disabled, in which case the entire row would just be greyed out.

Setting the shortcut to null, negates the possibility to actually retain the shortcut in its disabled state. So in that case we can still grey out the row, but how do we actually disable it in the UI? We would need another button next to Cancel, Default, Save.

I will think about the other points you brought up.

[anjulalk]

How about just pressing Enter when the shortcut field is empty?

So the user would first double click on the shortcut field, and then just press Enter without pressing any key combination.

[tessus]

This could work, since Enter without modifiers can’t really be a shortcut anyway.

This should be mentioned either at the top or the bottom of the UI screen as a remark.

[anjulalk]

I’ll add it to the post. Thanks for pointing that out. Completely missed it!

[tessus]

Something else came to mind. Duplicate shortcurts are in fact allowed, depending on the context.

focus is on:

• editor
• notebook list
• note list
• …

[anjulalk]

There is an issue with detecting duplicates according to the context.

Correct me if I’m wrong, but I couldn’t find any shortcuts (or menu commands) that will be disabled or enabled, or have their action changed depending on what the user is focused on. So all shortcuts are enabled, at all times.

For example, even if the user is focused on the note list, “Bold” command is still enabled. Therefore I’m having trouble figuring out how it’d be compatible.

[tessus]

I think we require Laurent’s input on this. He has the say about the architecture after all.

[laurent]

Not sure what’s the question?

To de-duplicate we have the context - so Ctrl+A means selecting all notes in the note list, or selecting all text in the text editor. I believe that’s the Source column in your mockup?

As for the shortcuts being enabled/disabled, it’s up to the component to handle this at the moment. For example, formatting shortcuts are disabled when only the note viewer is visible.

[anjulalk]

Sorry if I wasn’t being clear.

The question was should we allow duplicate keyboard shortcuts for actions if for example, one of them is only allowed in note list, and the other one is only allowed in note body.

@laurent

Ctrl+A means selecting all notes in the note list, or selecting all text in the text editor.

Both of those actions are presented as one action: “Select all” to the user. There’s only one shortcut associated with it. This is about two different actions.

If the user is focused on note body, all keyboard shortcuts are enabled and usable as per my understanding. This makes having the same keyboard shortcut for any two or more distinct actions impossible in any other case.

Moreover, I think it’s better to only allow an unique keyboard shortcut for each action as a user experience measure. But that’s just my opinion.

@laurent

I believe that’s the Source column in your mockup?

Source was actually just an indicator for the user to see if they’ve changed the shortcut or it’s still the default. It was just an alternative suggestion. For example, it’d say “Default” if user hasn’t changed it, and “User” if he/she has. I was suggesting it as an alternate to just show commands whose shortcuts have been changed in italics and others in regular text.

My understanding about shortcut context was, since they’re already handled well with menu items (“Select all” meaning two different things, menu items automatically disabled when unavailable, etc.) we wouldn’t need to pay special attention to that area in the keyboard shortcut editor.

[tessus]

@laurent can you please clarify that, otherwise Anjula is stuck and can’t continue.

[laurent]

Ok will check a bit later.

[laurent]

If there's question, then there's a question mark missing somewhere

The issue is to whether we should allow two different shortcuts for two different actions, and disambiguate based on the context? If that's the question then yes that should be allowed.

But on the other hand there's no context column in the mockup so I'm not sure what's the status of it? I guess it's whatever is logical: if the primary key is the shortcut, then there can't be twice the same shortcut. If the primary key is shortcut/context then there can be twice the same shortcut.

[anjulalk]

I think we should go with unique shortcuts for each action, mainly because Joplin doesn’t have a lot of shortcuts. Another benefit is the user don’t have to change the focus beforehand executing a keyboard shortcut.

As I was saying, currently all shortcuts are enabled when the user is editing the note body. That’s why I didn’t include a context field in the mock-ups. (Even if I did, then it’d be “Default” for everything…) Therefore having context-limited shortcuts are not useful at the moment, in my humble opinion.

[laurent]

I agree it’s not currently useful but it feels like the kind of thing that would be hard to add back later on, while it’s relatively easy now. But maybe I’m missing something.

What would be useful is to see your current data structure for the shortcuts, actions, etc. as that would inform what we can support or not. In fact, you should maybe have a separate post for this where you keep it up-to-date based on your discussions with Tessus and me?