Keyboard shortcut registry

[myasonik]

Summary

Several teams have implemented their own keyboard shortcuts for various bits of UI throughout Kibana. This, on top of the keyboard shortcuts that EUI ships, are bound to start conflicting at some point.

Managing discovery of keyboard shortcuts also poses a challenge that no one has yet undertaken nor have the accessibility issues of shipping arbitrary keyboard shortcuts been tackled.

Goal

Provide a way for Kibana teams and EUI components to register their keyboard shortcuts to improve discoverability and allow for a central management of them from both a developer and a user perspective.

Do people want this?

Not including issues of people complaining about our tab order not being what they want or expect (which strong keyboard shortcuts could help mitigate):

• Canvas a lot of keyboard shortcuts
  • Related issues: [Canvas] Refactor keyboard shortcut handlers #42628, [Accessibility][Layout Engine] Suggestion: Layer Selector #25505, Keyboard Shortcuts: Positioning and Manipulation of Elements #23058, [Layout Engine] Page Manipulation #23060, Ability to copy pages across workpads #32783, [Layout Engine] Keyboard Shortcuts for page navigation: Page Basic Commands #23057, [meta] Canvas accessibility #23534
• Console has some keyboard shortcuts
  • Related issues: Support disabling keyboard shortcuts in Console #48410
• Navigational Search has a very prominent shortcut
• Lens hopes to add keyboard shortcuts in the future
• EUI has several keyboard shortcuts in DataGrid and Selectable
• Ace our legacy in-browser text editor ships with its own shortcuts
• Monaco our next-gen text editor
• Long standing request for a general purpose action palette (Create a command palette with hotkeys for Kibana #15019)

Functionality & features

MVP

• A service for developers to register their keyboard shortcuts to
  • Can manage uniqueness: Critical on a per-page basis but also good to know across different pages
• A UI for users to view all shortcuts available on the current page
  • Available in the help context menu and under a ? keyboard shortcut
• A system for EUI components to expose and register their shortcuts

Phase 2

• Allow users to edit and disable keyboard shortcuts through the UI
  • Can start off as a setting saved in local storage and can eventually migrate to a user setting when that is available. (Doesn’t make sense as a space setting because these customizations will often be driven by unique reasons such as working with specific assistive tech or power-user specific workflows.)
  • This unlocks the capability to provide single key shortcuts (WCAG 2.1.4, any of which would right now pose as an WCAG A failure)

Future work

• Allow users to see and edit all keyboard shortcuts throughout Kibana
  • Can live somewhere in advanced settings (Use case is more centered around admin changing something for everyone because of collisions with other software or a user wanting to disable all keyboard shortcuts)
• Allow users to set keyboard shortcuts for commands registered without a shortcut
  • For example, could register “Create a new table visualization” as an action without a default keyboard shortcut. A user may find it useful to add this as a shortcut if it is a common action for them.
  • Ties in with future work of Global Search (anything that is available in global search is a good candidate to being available at a keyboard shortcut)

Accessibility notes

• Shortcuts fall in 3 categories: Navigation (move focus to a specific element), Activation (perform a specific action that does not have focus and may or maynot be visible), or Both
• Keyboard shortcuts should never be the only means of performing an action and should not replace appropriate focus order
• Avoid using any modifier keys (Meta, Alt/Option, Caps lock, Insert, Scroll lock)
• Avoid differentiating between capital and lowercase letters
• There is an HTML attribute called accesskey — unfortunately, it largely doesn’t do anything and is buggy in places where it should do something so it’s best to avoid it entirely
• Though not super well supported, we can enhance keyboard shortcuts by adding aria-keyshortcuts. The largest difficulty here will be updating these values when customized by users

Not addressed

1. Should CoreUI prescribe specific keyboard shortcuts or only create a mechanism for other teams to register theirs?
   • Common keyboard shortcuts seem to be:

     g+	Go to...
     ?	Help
     j/k	Next/Previous

2. How to handle localization? (Do we want to at all?)
3. Does global search become an all purpose command palette or do we keep these UIs separate?
4. How do we differentiate component specific shortcuts (such as code editors, EUI’s upcoming markdown editor, and other EUI components), page specific shortcuts, and global shortcuts?

Examples

1. Gmail has an extensive keyboard shortcut page that’s always available
   

   a. And allows for individually configuring each option, giving an alternative, and resetting all of it back to defaults
   

2. Google Calendar has a more modern design of Gmail’s implementation (but the only control is a on/off toggle). Twitter, Feedly, Google Keep, Trello — all have similar designs and implementations.
   

3. GitHub shows you the keyboard settings available on the page you’re on and links out to all keyboard settings (and has no controls for them)
   

[elasticmachine]

Pinging @elastic/kibana-design (Team:Kibana-Design)

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[pgayvallet]

I don't foresee any major technical issue registering global or per-app shortcuts.

The tricky part here will be to find the correct API to let plugins register per-page shortcuts, as an application 'page' is a concept unknown from core. The plugins will probably have to manually refresh/update the shortcuts when the user transition from a page to another

[myasonik]

All our page transitions go through a single function, don't they? Could core use that transition as a signal to update the active shortcuts on a page?

Then shortcuts could hopefully be global, tied to an app, or tied to a URL.

But another difficulty would be what happens with certain EUI components registering shortcuts? Especially on pages like Dashboard where a lot of stuff is user driven, we'd need a way to register a shortcut from a rendered component, not from something like the plugin registry.

[pgayvallet]

All our page transitions go through a single function, don't they?

No, they don't necessarily go through application.navigateToApp. Applications can also navigate via their scoped history (history.push), which is what react-router's Link is doing.

We could eventually listen to the history from core and try to 'deduce' the page from here, but that could be harder than it sounds, for multiple reasons.

Also, I doubt that, in term of developer experience, registering everything during a plugin's startup would be the easiest approach. Most shortcuts are usually bounds to page-local handlers, meaning that registering everything for all their pages in advance would result in a way harder implementation for the consumers.

I really think 'per-page' shortcut could be dynamically added by the pages components.

e.g

const MyPage: FC = ({ params }: { params: AppMountParameters }) => {

   useEffect(() => {
      const unregister = params.shortcuts.register(myShortcuts);
      return () => unregister();
   }, [])
}

The example is exposing the local shortcut registry on AppMountParameters, I think it would be better than exposing it from a service, to restrict local shortcut registration to a given application's mount instead of the whole plugin. Global shortcuts would be registered using coreStart.shortcuts.registerGlobal()

This also has the upside that the shortcuts are not bound to the concept of 'pages', but of components instead. Nested routes could have multiple nested components adding potential shortcuts depending on the state of the app.

One downside is that we will not be able to detect shortcut conflicts during core's setup/start phase, and only when a potentially conflicting app is mounted.

[myasonik]

One downside is that we will not be able to detect shortcut conflicts during core's setup/start phase, and only when a potentially conflicting app is mounted.

I think that's a reasonable downside at least until it becomes a problem which could still be a long way away unless people start adding these all over very suddenly.

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[bhavyarm]

cc @1Copenut