Try forward slash keyboard shortcut for command palette #52386
Conversation
|
Size Change: +11 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 7a4ea96. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5477893577
|
There was a problem hiding this comment.
@stokesman Ctrl+Shift+P does not work in Firefox on Windows due to that command being reserved for private browsing window. Any ideas on how to get around that? Ctrl+/ is working perfectly.
Both commands test great in Google Chrome on Windows.
|
I feel it makes sense to use the foreword slash as a shortcut to the command palette.
In Chrome, pressing Ctrl+Shift+P when the developer tools are open will launch the browser's command tool. Conversely, when the developer tools are not open, the print modal appears in my environment. Personally, I would hesitate to overwrite either browser shortcut, so the alias may not be necessary. |
|
Thanks for the feedback Alex and Aki 🙇. I'm not sure an aliased shortcut is necessary. The only reason I had for it was in case of a third-party plugin that has a code-editing view with a shortcut for toggling comments because that would likely conflict with the primary shortcut. So if we want to include an alias we'll likely want a better one. |
|
Ctrl+Shift+P is also used to open the commands menu in other applications such as VS Code for example. That is why I think we might really think about making this shortcut work on Windows. |
stokesman
force-pushed
the
try/slash-shortcut-command
branch
from
7a4ea96 to
b4e8502
Compare
|
Alex, I looked into it and Firefox makes overriding certain shortcuts from javascript impossible. So like CodeSandbox does for example, we could use Ctrl+Shift+P, but it's not going to work in Firefox (and that goes for MacOS as well). I looked at what StackBlitz and GitHub.dev are doing and they use F1 for the command palette. That seems good and I'd guess they've done their homework on general availability so I've changed the alias to that. Still, I wouldn't say an alias is necessary so if there’s any controversy about it we could move forward without it. |
|
@stokesman Sounds good. Adopting a common pattern makes me feel better. |
There was a problem hiding this comment.
Thanks for your hard work!
I looked at what StackBlitz and GitHub.dev are doing and they use F1 for the command palette. That seems good and I'd guess they've done their homework on general availability so I've changed the alias to that. Still, I wouldn't say an alias is necessary so if there’s any controversy about it we could move forward without it.
On Windows and Linux, Chrome uses the F1 key to open the Help Center page. Looking at the shortcut list, this shortcut does not appear to exist on the Mac, so overwriting it might not have a significant impact, what do you think?
I imagine it is acceptable to override F1 🤷♂️. I had a vague memory of it commonly being used for help shortcuts. macOS has ⌘+Shift+? for opening the “Help” menu of the current application. Thanks for taking a closer look Aki 🙌. |
|
I'm pulling in and replying to the parts of @richtabor’s #51737 (comment) that regarded using forward slash.
This is not about preference. It's suggested primarily by internal precedence; the forward slash is already used in the contextual inserter shortcut. Secondarily is external precedence in other applications, e.g. Figma.
I agree it makes sense to pick one that’s easy to use and there are other options. However, has forward slash not been proven given its use for the slash inserter since 2017 (beside its widespread use in other applications)? Have we ever seen complaints about it? Maybe @annezazu would know. Also, if a person has to find the forward slash aren't they accustomed to finding keys anyway—i.e. not a touch typist? It doesn't seem like they'd complain.
We can also alias the shortcut. I had tried CMD+P here actually but didn't like that it can annoyingly trigger the system Print dialog in cases of focus loss that still happen sometimes in Gutenberg. |
If I'm reading this right, I haven't seen big complaints about the / inserter but I do know it's difficult to find and is the lesser used of the inserter methods. |
noisysocks
added
the
Needs Decision
|
Reading through #51737 it seems that there isn't a consensus about changing this. Cmd+K is consistent with other web apps despite its flaws. CC. @WordPress/gutenberg-core @WordPress/gutenberg-design in case I'm wrong but I think this is a |
|
Thanks Anne for the response 🙇 . When you say it's difficult to find I take you mean the inserter itself. I was trying to find out if the forward slash character was reported as hard to utilize. It's my most used inserter method, BTW. Thanks Robert 👏 Before I reply to some of the points you bring up let me appeal with the third option of moving forward with both shortcuts. Should that not be a way to have consensus?
Being like other web apps isn’t great when it compromises your own app’s design. Also, consistent with which other web apps? This PR is more like Figma, StackBlitz and GitHub.dev. What research informs us of which is better for WP audience? Gleaning that requires some study and there's not much to leverage without it.
Those points also support moving forward with this PR—perhaps more so. The idea that command-based link UX can be as good as the current one is speculative at this point. If it doesn't work out CMD+K either remains crippled or we have to justify a clunkier link creation UX. |
|
Ultimately I see the solution as keyboard shortcut customizability. This is even more important for international keyboards where, for example, the region-hopping shortcut is cumbersome to access on a Danish keyboard at the moment. If such a feature lands, we have some opportunities:
Any combination of the above. And ⌘P is just an example as inspired from VSCode. |
|
Hello, I wanted to add my understanding of the aspects here:
|
|
I haven't looked through the code and tested this PR, but with |
|
I just wanted to link this article here, as I think it does an excellent overview of this design pattern - https://maggieappleton.com/command-bar. |
|
I'd vote for the suggested shortcuts
Worth also reminding that browsers behave differently when pressing the Shift key, they may or may not emit the same event.key value. See #45019 where depending on the browser, pressing For this reason I'd recommend to add e2e tests for this shortcut and make the tests run with all browsers, not only with Chrome. Worth also recommending that while developing this kind of shortcuts should always be manually tested with all browsers, not only macOS Chrome. |
|
Hi @stokesman, are you available and able to refresh the pull request and solve the merge conflicts? |
stokesman
force-pushed
the
try/slash-shortcut-command
branch
from
b4e8502 to
8322fdd
Compare
|
I've rebased and fixed conflicts. I've given it a quick test and everything seems okay. |
|
First of all, thanks for addressing this issue. However, I am not convinced by the solutions proposed. Using the If modifying the behavior depending on the context is not an option, the customizability that @jasmussen explained seems the best path forward to me. |
|
I agree with the sentiment that we should not obscure the command palette keyboard functionality. As I mentioned in #51737 (comment), we probably need to stop the link control from opening via command + k when you don’t have any text selected. That would solve the unexpected behavior, and command + k can invoke LinkControl when you expect it to, while invoking the command center when you expect that. |
Yes, Control/CMD + K is somewhat standard in the industry but it has always been used for adding links, since ages. Historically, that's what this shortcut has always been used for. Alternative usages came later, In the same way, it's the convention WordPress has being using since ages. I'd think it's important to consider that alternative usages of the Control/CMD + K shortcut are typically implemented in highly specialized software or web applications. As developers / web designers / advanced users, we are used to use these tools and we are, in a way, a little biased. Average WordPress users don't use those tools. They are just used to mentally associate Control/CMD + K to 'add link'. I'm not sure we should change this mental association that has been in place since forever.
I'm not sure a contextual based behavior would be ideal. More likely, it would be less discoverable, potentially confusing, unpredictable, and hard to maintain / test for. Also, the feedback about the current context would be mostly visual. There is nothing that would inform users in a semantic, accessible, way that 'you are now in context xyz, the shortcut will behave in a different way'. I'd think that controls (whether they are part of the user interface or keyboard shortcuts) that change their default action contextually rarely provide a good user experience.
Rather, #3218 as mentioned by @noisysocks would be a more comprehensive solution. Overall, I'd think simplicity is key. Can we just keep it simple please? No context change please. |
|
As an aside: I just had an idea regarding #3218 which is allowing users to customize the modifier keys rather than the entire set of shortcuts. I'll detail on that issue. |
|
One more thought: To me, the Command palette is close to the concept of the macOS Spotlight. Mac users are familiar with this kind of UI and they know it can be invoked by pressing Microsoft does have a similar tool as well. Not by default though. The Microsoft PowerToys set of utilities do provide a PowerToys Run tool that is similar to Spotlight. Not surprisingly it can be invoked by pressing Both tools establish a pattern where some modifier key plus the Wouldn't make sense to use the same pattern for the Command palette? |
Overriding an OS command with an active WordPress window would negate the OS command, which I'd imagine would be quite frustrating. |
|
I don't understand how is the UX of "knowing when to press cmd+k" better than not having to know "when", but only "what"? 😁 The UX of:
all the time - really seems a better experience, even compared to that the fleeting warm and fuzzy that cmd+k "works like it does in Notion". It's good to have industry standard UX patterns, but in this case as I also summarized above the industry we mention has a different context (a non text editing one) than our editor. The part of the industry dealing with text editing does not employ this small UX convenience for the same reasons we're struggling with here. |
I didn't mean to override the OS's |
As I mentioned earlier, the palette will be more obscured with obscure shortcuts. I don't think we should change the shortcut, rather resolve the bug at hand. Otherwise we're asking people to change behavior without any benefits to doing so. It'd be nice if we can each set the command to whatever we'd each like, but the default should remain as it is today. In this potential case, the benefit to the changed behavior is that you made a choice to pick whatever shortcut you fancy. There's a positive experience to change. Otherwise, changing the shortcut is a nearly arbitrary decision that will certainly lead to confusion, further obscuring the command palette. |
|
There are three problems with implementing:
|
|
As an alternative approach, if we change the command palette shortcuts, we might be able to provide UX like the one below to reduce the load on the user. In other words, the specifications are like this.
This idea was inspired by the UX in Slack. Slack offers another shortcut when you select text and press
WordPress, especially the Site Editor, has implemented this kind of UX that prompts users for new information. For example, you may have seen a Notice component with the following text:
|
What's the harm in just opening command palette, instead of rendering a notice on how to open it? The Slack example is when you try to do something not intended. It's a negative response to what you're trying to accomplish. We should avoid these if possible. |
|
@richtabor what @t-hamano suggested is about how to make this transition from cmd+k to cmd+/ work in a friendly UX. So we apply the changes to this PR, cmd+/ is the new key for command palette but we should that nice toast for those:
|
I'm not sure the palette is 'obscured' because of the associated shortcut, whatever the shortcut is. The command palette is inehrently a hidden feature. Users aren't aware of the existence of the command palette because it's not visually exposed in the UI. If making it more discoverable is desirable, I'd suggest to simply make it visible. by adding a visible control to open it.
I wonder how many amongst the average WordPress users expect Cmd+k to open a command palette. In my opinion this argumentation is highly biased by the fact that, as designers and developers, we are advanced users and we are used to use many different kind of software and a few of them use this Cmd+k convention. I don't think the vast majority of WordPress users expect Cmd+k to open a command palette so I find the argumentation about changing the shortcut a bit pointless.
I kindly disagree. The 'default' expectation for Cmd+k is to add a link. |
What?
Changes the keyboard shortcut for the command palette.
Why?
The current shortcut is conflicted with the longstanding shortcut for adding a link to rich text and that breaks the intended global availability of the command palette shortcut.
To fix #51737
How?
Testing Instructions
In either the Site or Post editors launch the command palette by pressing:
Test it from a rich text area too and delight in the lack of conflict 🎊 .