-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Update the design of the command center #49681
Conversation
Size Change: -865 B (0%) Total Size: 1.37 MB
ℹ️ View Unchanged
|
Thanks for taking a stab! I realize this keeps coming up for me, but I must be doing something wrong with my environment, I'm not seeing any difference in this branch:
A note that this may be best done separately, as that radius could/should be the new default radius for modals, so not just unique to this one: |
@jasmussen yeah that's not correct, would you mind trying to restart the build? |
For some reason, that worked, though I'm sure I tried this before. GIF showing the new: A few small notes. The gray highlight I in the mockup, I have from the URL dialog: No strong opinion on whether that's gray or blue, but would prefer we unify across those. A small detail, I search for "Con" and it finds first "Comments". It's fine that it finds that through the fuzzy stuff, but as you can see in the GIF, it keeps highlighting that. I feel like it should always highlight the top item, at least until you move the arrow keys. What do you think? The bold highlight looks great, nice. The icon is 16x16, it should be 24x24: The search field font is 16px in this branch, I bumped it all the way to 20px in my mockup. This is not a strong opinion, but it makes it feel more substantial to me. I'd love a broader design opinion on this. Finally, there's a question of what the placeholder text should be. In my mockup I have some fairly boilerplate text:
The good thing about that is that it's short! That allows for a less wide modal, makes it feel more manageable and friendly in a way. It's 400px wide in the mockups, we can go wider than that, but it feels a bit too wide in this branch as is. Speaking of, this branch says:
In principle, the tip is useful, but I wonder:
A single unified alternative to start with might be something like:
Mainly this is driven by the instinct: the less text, the more likely it is to be read. Similar to our:
What do you think? |
I also like the short placeholder personally. and I'm going to update here with the design feedback only. The thing about searches... is still unclear and I'd prefer to address separately. |
I think I've addressed all the design feedback. |
Looks great to me: Upon second thought, perhaps the search field could be slightly wider, perhaps a nice round 480px max-width: I also appreciate that the top edge of the modal stays fixed even as it grows vertically. I think there are lots of little things we can improve here, and I'd love feedback from @richtabor specifically as he has separte mockups for this. I imagine many are back to review this tomorrow. What do you think? |
400px felt too small indeed. I've update the width and I'm happy to wait for more feedback. |
Flaky tests detected in ea79690. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4666290481
|
I do not recall this modal having a close button. Can you work it into the design? It does need one. I will be able to do a more solid review of this once the related shortcut PR lands and makes this easier to access on Windows. |
5806355
to
ea79690
Compare
So far as I've seen the trend is towards the blue. E.g. Inserter items, tertiary buttons, list view. The gray feels 'old' to me. I'm not a fan of using icons as the only differentiator. How will we communicate what is a post category vs a product category if they appear together in search results? We don't necessarily need to solve this here, but it's going to come up as soon as we add support for taxonomies. |
@youknowriad, is the input value debounced? In that case, the issue might have been resolved by #49234. We still need to override the core polyfill and use one generated by the plugin. |
@Mamaduka no, I don't think so, also your link is wrong :P |
@youknowriad, I'm out of the practice copy-pasting issues 😄 I fixed the link. |
@Mamaduka so you're saying that once we "override" core polyfills by the Gutenberg plugin, the issue will fix itself? |
I should point out that while it's plausible that #49234 would help with performance, I wasn't able to measure any impact while working on that change, and ended up submitting it more out of cleanliness and removing unnecessary code than anything else. If you are able to measure a performance improvement, though, please do let me know, as I'd love to know more! |
It input font size feels quite bit, especially in relation to the menu items. It's one of the largest font sizes within the editor. Perhaps dropping it down to And units around the input feel off when there are results (too much space above): We could probably reduce the padding on the items, which would better align with the input text as well: |
I pushed some updates based on the Figma we've been working in: It would be nice to include a 'Type' chip in each item so that you can easily tell what's what – the icon isn't always obvious. Probably fine to do that in a follow-up though :) |
I was thinking the radius change should happen separately, it likely needs a README update. But I don't mind bundling it in here if you all are okay with it. Maybe time to switch to the modern color scheme? :D |
Maybe 🤣 The radius is only applied to the command center. Agree it would be nice to update all modals though, and that should happen separately. I guess I'll revert that here. |
This reverts commit bc6ed51.
Are we ready to ship this for now? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels like a solid step in the right direction. Let's land this as it's a strong improvement over what's shipping. Here's a GIF showing the commandbar, searching for "con" and finding the "Contacto" page, searching for "add" and finding "add new post", pressing Enter to navigate there, and it working as intended:
The visuals will look stronger still when #49870 lands.
One gotcha, which is more of a question. If I search for add
(including the space) I would expect to see results for both "add new post" and "add new page", but I get that only for add
. This isn't critical to get right, but it would be a nice optimization if we could, because it would avoid a weird "no results" flicker if I'm typing out "add new post" as my command.
Yeah, search is a bit weird (it's internal to the library we use) but I'm going to see how we can improve that. |
Related to #48457
Alternative to #49658
What?
This PR updates the design of the command center per @jasmussen's mockups:
Note I'm seeing a weird design glitch on Safari when I search quickly. Not sure exactly where it comes from.
Testing Instructions
1- Open the experiments page
2- Enable the command center
3- Navigate to the site editor
4- Hit cmd+k and try using the command center.