[MGNLUI-4934] Offer list of keyboard shortcuts Created: 30/Apr/15  Updated: 25/Nov/21

Status: Accepted
Project: Magnolia UI
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Epic Priority: Major
Reporter: Antti Hietala Assignee: Anja von Gunten
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLUI-4958 UI framework implementation and desig... Closed
relates to MGNLUI-6226 Hitting enter on usage metrics popup ... Open
relates to MGNLUI-4974 Implement keyboard navigation in tabu... Closed
duplicate
is duplicated by MGNLUI-1883 Create Concept for TAB based Keyboard... Closed
relation
Template:
Epic Name: Keyboard shortcuts
Acceptance criteria:
Empty
Date of First Response:

 Description   

Epic: Define and implement a small set of easy to remember keyboard shortcuts for main actions in the Magnolia 6 user interface.

High-level tasks

  1. Define a modern concept. Inspiration: J, K, or How to choose keyboard shortcuts for web applications
  2. Review current shortcuts. See DOCU-1728 for what works and what doesn't in Magnolia 6.
  3. Add new shortcuts for new actions introduced in Magnolia 6 such as moving focus to the Find Bar.
  4. Add visual cues for shortcuts so that users can discover them in the UI. 

Actual planned keyboard shortcuts:

https://wiki.magnolia-cms.com/display/UX/M6+Keyboard+navigation



 Comments   
Comment by Andreas Weder [ 24/Sep/15 ]

I see what you mean. My idea was indeed to come up with a first, convincing set, then expand on this and/or adjust it while we go. However, it will be difficult to change a mapping once we've defined it. Users will hate it, if keyboard commands they're used to change in a new release.

Solutions I see are:

  1. We indeed define a small set first, but take great care to choose only shortcuts that seem to be common by analysing often used tools. That raises the probability we'll come up with a stable set right away.
  2. We invest more time into a conclusive set of shortcuts.
  3. We invest into a UI allowing users to change shortcuts. Apart from the convenience and customization this brings, it would allow us to change mappings later on. If users are not satisfied with our changes, they could define their own shortcuts, i.e. revert back to the mappings they learned.

In addition, we might also want to consider investing into a "revealing" function that visually shows all keyboard shortcuts of all actions and UI elements currently in view (similar to pressing "TAB" in Asana task manager).

Comment by Aleksandr Pchelintcev [ 28/Sep/15 ]

I'd also revisit the strategy we currently have for shortcuts and try to eliminate hacks/inconsistencies, i.e:

  • Some shortcuts are hardcoded on the client-side of MagnoliaShell component (e.g. 1-3 for shell apps and 0/9)
  • Some shortcuts are partially hardcoded in dialog/editor impls (enter/escape)
  • Lots of components have to wrapped into Panel's

One option we could research (just a suggestion) is the jQuery's hotkeys plugin - looks pretty promising, allows to bind a shortcut an id/classname etc.

Comment by Mikaël Geljić [ 08/Jan/19 ]

pasting here too now that this is revived as an epic; here's a reference read on single-key shortcuts: J, K, or How to choose keyboard shortcuts for web applications

Comment by Cedric Reichenbach [ 21/Jan/19 ]

When defining keyboard shortcuts, I strongly suggest consulting the official W3 content accessibility guidelines section on keyboards (2.1). There are just 4 rules and pretty reasonable IMO, as well as up-to-date (published mid-2018).

Generated at Mon Feb 12 09:21:34 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.