[Canvas] Feat: Keyboard shortcuts for nudging elements

[cqliu1]

Summary

Related to #23058.

This PR adds shortcuts to shift elements up, down, left, and right by intervals of 16px or 1px.

Keyboard Shortcuts added:

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• This was checked for cross-browser compatibility, including a check against IE11
  - [x] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
  - [ ] Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately
• This includes a feature addition or change that requires a release note and was labeled appropriately

[ryankeairns]

I wonder if we need all the shortcut permutations... could we make it be just one for each? Like 'Nudge by 1px' then the shortcut shows the 4 different arrow keys all on one line? or generically say [arrow keys]

[cqliu1]

@ryankeairns I have to map them all separately to perform different actions in public/lib/keymap which is what the shortcut reference uses to generate the content. I don't think there's a way we can combine them into one line

[elasticmachine]

Pinging @elastic/kibana-canvas

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[ryankeairns]

@cqliu1 ok.

Last question, it's actually 10px not 16px on the big nudge, right? I think 10px, in this case, is the best/expected result.

[cqliu1]

Yep, I was playing around with different numbers, but I can change it back to 10px.

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[monfera]

Sorry, I suggested 16px on vague recollection that design tools and grid systems use power of 2 increments, and this way, it's faster to cover a larger distance (accessibility), while it still takes a maximum of 8 small (1px) nudges to fine tune (8 px back or forth if the user ends up in the middle of the larger nudge). I just checked Google Sheets, it looks like it also uses around 10px.

The functionality is working well for individual nudges, and the element stops moving if I keep pressing the arrow, and it'll eventually teleport to the new location (on my backup machine that's 2014 vintage and my Key Repeatin System Preferences is set to highest). It's likely because every single increment is persisted now in Redux, otherwise, with the current approach, the element wouldn't move (ie. we can't just debounce). On every Redux access it'll also persist the element in the Elasticsearch index. While that could be debounced, it'd probably make asynchronous randomness worse, and it may not even be responsible for the lag.

So we seem to have these options:

1. On the assumption that people nudge with only a few keystrokes, it's good as it is (in this case, it's not too accessible for cover larger distances, though we lack accessible keyboard controls at the moment, eg. resize, rotate, selections etc.)
2. It's done through the layout engine, which, for the mouse drag now, only issues a Redux repositioning action only upon the end of the gesture (which in this case could be the keyup event)

As the linked issue expressly mentions accessibility, I feel like a keyboard-only user should be able to move an element at larger distances, ie. doing it via the deferred route with the layout engine, and perhaps using larger step sizes or adding another modifier key that induces larger jumps eg. 50-64px.

But I'm not sure if this improvement is needed in this specific PR or it should be a follow-up PR.

Any thoughts on this overall? Should we loop in MikeB as I'm second-guessing accessibility aspects.

[crob611]

Looks and works great for me.

I don't see any staggering like Robert mentioned, but definitely could see that being an issue with the constant update cycles happening. And having a persist happen on every press could also be an issue. Might be worth spending some time to think of some way to prevent that from happening.

Might also be a nice feature to have elements snap to edges as you nudge them that way, but that's definitely for another PR

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[ryankeairns]

👍 LGTM. I've longed for this feature and can't wait to use it! The functionality works as described and is a great addition as-is. +1 to handling any rough edges in a follow-up PR.

[monfera]

Great work, in agreement with those who spake before me!

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request