Add a command center to the site editor. #49330
Conversation
youknowriad
added
[Type] Feature
|
Size Change: +783 B (0%) Total Size: 1.37 MB
ℹ️ View Unchanged
|
|
A quick spin:
This feels really nice. Props to @SaxonF for initial work. Let's do a design pass on the modal that opens (CC: @jameskoster as well) so it feels at home with the componentry. Outside of that, in addition to the keyboard shortcut, we need a button to invoke this. Maybe that can be the search icon in the site hub:
There are some of the flows we can hopefully clarify a little with UI, placeholders, context, help text, focus styles etc. This GIF shows searching both content and commands, and illustrating some of the hiccips:
|
|
Thanks for the ping, I'm excited to dive into this next week!
I agree on the location. Search icon may be fine to start but this feature could eventually grow far beyond searching, so it might be worth exploring some different (maybe more abstract) options. A slightly random thought and probably not something for this PR; it would be interesting if the input could entertain dictation, so this interface can in the future become a way to 'talk to WordPress'. |
+1. If we launch with We can probably just copy over stylesheet from #49152 if we wanted to give this branch a stronger starting point, but can also just start fresh. |
|
I've added commands to navigate to "new page" or "new post". Thought I did it by actually navigating to the post editors page which leaves the site editor. I think there are arguments to be made for both approaches though. |
|
Also if you folks want to push a design/CSS changes here please feel free to do so. |
|
Flaky tests detected in 55e94f7. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4627378477
|
|
I spent some time playing with this today. Additional the the feedback already shared, here's some other thoughts / questions:
|
|
Made some tweaks here. I've used or own Modal component to allow focus outside to close. I borrowed some CSS from the other branch too. |
Using a back arrow in #49152 which seemed consistent with how other panels work.
If this ships with 6.3 along with some of the content vs template editing changes we are working on, I think we should keep people within the site editor. |
The page for creating a "post" in the site editor is a bit ackward to be honest, it's not really clear that you're actually creating a post while we already have a nice page that users are familiar with to create posts and pages. As things stand, personally, I feel it's better to just redirect them to the page they're familiar with but I'm not strongly opposed to improving the experience in the site editor either. |
|
I'd agree that keeping folks in the site editor is the long-term objective. But for the purpose of this PR it may not be ideal. We'll be exposing folks to the content/template issues, and excluding key functionality like drafts / revisions. Maybe we link to the post editor for now. As a follow-up task we can list the gaps we need to close and prioritise for 6.3? Alternatively, if we're worried about the disconnect we could keep the content creation commands on ice until those gaps are closed? |
I'd generally agree with this sentiment, notably the part about keeping things separate in the near term. But also add a little nuance: while under the hood the editors could be the same, I think it's useful for there to be a "Post-first" entry point, or a "Page-first" entry point for an editor. When I'm in a busy newsroom, I probably never want to see a header and a footer. And when I'm editing page-first, I don't want to have to worry about ensuring all my blocks are inside the Post Content block, lest they become global. If we truly are going to keep everything inside a single editor, those flows need to be super solid first. |
It is accessible in the site editor in edit mode too but when RichText is selected, ctrl + k is bound to the link format so it doesn't trigger the command centeR.
We need to decide whether we want "Search pages" and "search templates" to be different or not, same for "search posts". I made several updates based on your feedback, What's the next steps here? |
My inclination is that we should focus the flows around commands rather than navigation. Otherwise I fear we're going to end up re-creating the main navigation drilldown in the command center and confusing users about where to go to do different tasks. With that in mind, plus the fact I don't think it would scale all that well, I don't think we should include things like "Navigate to a page" as suggestions. Instead the default placeholder can instruct the user to search for content, or try commands. To delineate between different post types / taxonomies in results we could try something like the suggested design for link control:
|
That has a big impact on the API for the commands package. So we need to decide here. We can always start with a private API though while we figure things out.
It should be already the case |
|
I pushed some style updates. I'm not suggesting this is a final work, but it brings things a bit closer to the rest of the UI:
It can serve as a blank canvas from which we refine. A couple of other observations on general UX:
|
|
I've updated the PR with a new architecture (no nested tree) and added posts, templates and template parts. Let me know how it feels. |
|
I'm interested to hear what others think, but the full list of all-the-things that you see on-open feels a bit overwhelming. I suspect the usefulness will diminish quite quickly on large sites with 000's of posts. I'd lean towards only suggesting commands here:
We can try some other placeholders to inform folks they can search for content. Other than that:
Then there are a few items that might need to be follow-ups:
|
|
@jameskoster it depends largely on the context in which you invoke this. |
|
That's true. If you're in the full-screen editor working on a page, then it might be useful to see other recent pages, and the underling page template listed as suggestions. Or if you're at the root of the Design section then perhaps creating a new page or template would be more helpful. Should we figure out those contexts / suggestions for this PR, or separately? If separate, then in the mean time do we continue to list all-the-things in lieu of context? |
youknowriad
force-pushed
the
add/commands
branch
from
8d43c31 to
8cb81b7
Compare
|
Since there are still different opinions on how to organize and design the command center, and also in terms of behavior, I've added an "experiment" flag to the Gutenberg experiments page to enable the command center. This will allow us to ship this and iterate without impacting the users yet. We can remove the experiment flag when we think on the state of the command center is ready. |
|
@ntsekouras I've fixed the duplicated selected item issue. |
| await admin.visitSiteEditor(); | ||
| } ); | ||
|
|
||
| test.skip( 'Open the command center and navigate to the page create page', async ( { |
There was a problem hiding this comment.
Why do we want to add these skipped tests? Perhaps adding comments above would help?
There was a problem hiding this comment.
Because they're hidden behind a feature flag right now and we'll be removing the feature flag soon. I preferred to have the tests in place to allow us to iterate and I verified that the tests pass.
I tried enabling the feature flag using the global variable but it doesn't work because you need to trigger a "rerender". I think ideally we need utils in the e2e tests to enable and disable feature flags (navigate to the options screen and enable the flags), I'm pretty sure we had these at some point.
There was a problem hiding this comment.
Still, a comment above would be helpful for the readers (or reviewers) :).
navigate to the options screen and enable the flags
It's recommended to create this util as a requestUtil to speed up the process. You are welcome to create one!
|
@youknowriad Could you please create a follow-up and use the keycodes package to make this cross-platform? This is currently testable on Mac only due to the event.metaKey. If there is a way to make it work on Windows, I have not found it. |
|
@alexstine good call 👍 |
ndiego
added
[Type] Enhancement
|
Looks like the |
|
I could not even test this on Windows before this PR was merged. In a perfect world, this should not have gone into trunk without accessibility checks, sigh. This is also a 3rd-party component, hopefully it is fixable. Please ping me on the issue @afercia . This fell off the radar for me. :( |
@alexstine I'd agree this shouldn't have been released but that's not under my control. The broken accessibility of the combobox pattern provided by the I reported some of the main problems in a new issue at #50846 |
|
Connecting the dots here: #52930 |
| "wordpress", | ||
| "gutenberg", | ||
| "commands", | ||
| "k" |
There was a problem hiding this comment.
Hey @youknowriad 👋 What does this "k" keyword mean? Noticed this when reviewing #52987, when looking up what are the dependencies of the commands packages 🙂
There was a problem hiding this comment.
most packages call these cmd+k menus I guess :)
There was a problem hiding this comment.
I see, so it's not a typo 🙂 I haven't found any other packages using this keyword though.
There was a problem hiding this comment.
Fine to remove.
Alternative to #49152
see #48457
What?
The idea of this PR is to bootstrap a command center for WordPress that can be the home of any random command be it:
In this initial PR, the goal is to build the APIs and components for that command center but not necessarily to implement all the commands.
Here are the requirements guiding my work:
How?
@wordpress/commandspackage that serves as a store for the registered commands and provides the components to render the command center.cmdkpackage. There are alternatives but this one seem to be reasonable and accepted by the JS community. It's an implementation detail though and can be switched at any point.Todo
Testing Instructions
1- Open the site editor
2- Type cmd + k
3- Use the command center.