I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
My suggestion is to surface these to the user. They're not discoverable - who would guess that you could switch between two layouts on one particular type of page by pressing "0" as long as an input field isn't highlighted?
They're nice things to have, but if the only way people find out is by accident they're going to miss out at best, and be confused at worst. Imagine pressing 0 one time and wondering why the site doesn't always look the same from one browser/day to the next.
I did try to add a comment over on forem, but it doesn't work: the submit button is glitchy and I can't click on anything!
I 100% agree, part of the idea behind this change was to make all shortcuts discoverable (in the code at least) rather than all being implemented however and wherever. We have an issue open, by @reobin
, where we're looking at how best to show users shortcuts and to document them programmatically so we don't have to make and maintain a large help file.
#10713 added a keyboard shortcut hook, and the migration for the current keyboard shortcuts to use the new hook has started. See #10878
Describe the solution you'd like
As suggested in #10713, the new hook could be used to populate a keyboard shortcut modal like GitHub's one:
The key ? would pop up that modal.
The details of the implementation have to be discussed. Using the hook to populate a keyboard shortcut store means that the modal would be different on a per-page basis depending on which shortcuts are used on the current page.
Also, they can't be added in there randomly. The shortcuts would need categorization, so the hook will probably need an update in order to receive the shortcuts categories.
Describe alternatives you've considered
It would be easier to just build a static modal, although less maintainable.
My suggestion is to surface these to the user. They're not discoverable - who would guess that you could switch between two layouts on one particular type of page by pressing "0" as long as an input field isn't highlighted?
They're nice things to have, but if the only way people find out is by accident they're going to miss out at best, and be confused at worst. Imagine pressing 0 one time and wondering why the site doesn't always look the same from one browser/day to the next.
I did try to add a comment over on forem, but it doesn't work: the submit button is glitchy and I can't click on anything!
I 100% agree, part of the idea behind this change was to make all shortcuts discoverable (in the code at least) rather than all being implemented however and wherever. We have an issue open, by @reobin , where we're looking at how best to show users shortcuts and to document them programmatically so we don't have to make and maintain a large help file.
#10713 added a keyboard shortcut hook, and the migration for the current keyboard shortcuts to use the new hook has started. See #10878
Describe the solution you'd like
As suggested in #10713, the new hook could be used to populate a keyboard shortcut modal like GitHub's one:
The key
?would pop up that modal.The details of the implementation have to be discussed. Using the hook to populate a keyboard shortcut store means that the modal would be different on a per-page basis depending on which shortcuts are used on the current page.
Also, they can't be added in there randomly. The shortcuts would need categorization, so the hook will probably need an update in order to receive the shortcuts categories.
Describe alternatives you've considered
It would be easier to just build a static modal, although less maintainable.
Additional context
#10468 #10713 #10878