Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shortcuts for Move up (T) / Move down (Y) are bad as T and Y are neighboring keys only on QWERTY keyboards - Better use arrow keys plus modifiers #51645

Open
porg opened this issue Jun 19, 2023 · 5 comments
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Enhancement A suggestion for improvement.

Comments

@porg
Copy link

porg commented Jun 19, 2023

  • Add keyboard shortcuts for moving blocks #10455 seems to have been done through an Anglosaxon perspective without i18n in mind
  • It assigned "Move up" to ⇧-⌥-⌘-T and "Move down" to ⇧-⌥-⌘-Y
    • Putting keyboard shortcut counterparts/antonyms as keyboard neighbors can make sense
    • But the T and Y key are neighbors only on a QWERTZ keyboard layout
  • Also the shortcuts for "Move up/down/left/right" should rather be combined with the arrow keys
    • Because "move cursor" / "move selection" / "extend selection" are conceptually related tasks, likely conducted sequentially, hence using the arrow keys and just varying the modifier keys is established best practise.
    • No need to re-invent the wheel, as best practise take macOS Cocoa native text selection commands, outliner/mindmap software for indenting/outdenting/grouping and also graphics/layout software.
@porg porg changed the title Shortcuts for Move up (T) / Move down (Y) is bad as T and Y are neighboring keys only on QWERTY keyboards - Better use arrow keys plus modifiers Shortcuts for Move up (T) / Move down (Y) are bad as T and Y are neighboring keys only on QWERTY keyboards - Better use arrow keys plus modifiers Jun 19, 2023
@porg
Copy link
Author

porg commented Jun 19, 2023

Hi,
I ping you, as you were originally involved:
@ZebulanStanphill as you opened #10455
@ntsekouras as you coded #23276

@hanneslsm
Copy link

Oh, wow. It never came to my mind that T and Y could be neighbouring keys. I always struggled with remembering the shortcuts lol

When tackling this issue, we should not forget that Add before & Add after have similar shortcuts.

@porg
Copy link
Author

porg commented Jun 19, 2023

  • As an experienced UX designer I have seen bad i18n far too often, hence easily spotted the root cause for this.
  • Yes ofc Add before & Add after must holistically be integrated into this whole shortcut set.

@talldan
Copy link
Contributor

talldan commented Jun 20, 2023

I don't think it was possible to use arrow keys, otherwise arrow keys would definitely have been used.

WordPress has generally taken the approach of not overriding existing text manipulation, browser and OS shortcuts, and unfortunately that leaves very few options. I think arrow keys are almost entirely reserved for text manipulation or OS level shortcuts.

@kathrynwp kathrynwp added [Type] Enhancement A suggestion for improvement. [a11y] Keyboard & Focus labels Jun 26, 2023
@porg
Copy link
Author

porg commented Jun 27, 2023

  1. Not overriding keyboard shortcuts and not overriding the right click context-menu leaves only the possibilities for a rather mediocre UX on Desktop devices, given that the Block Editor already has and foresee-able will get quite many shortcuts. Many web apps dare to do this and do this really well. And feel very native and efficient that way.

  2. Also to strive for cross platform consistency regarding shortcuts is ok. But not at all cost. In some regards the differences should be respected.

    • For an individual user it is more beneficial if shortcuts are consistent with the platform and other apps they use on a daily basis (high probability)
    • …rather than being able to operate WordPress when cycling between different Desktop OS (far less likely).

@priethor priethor added [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). and removed [a11y] Keyboard & Focus labels Jul 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

5 participants