-
Notifications
You must be signed in to change notification settings - Fork 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
Site Editor: add WP.com Global Styles #46696
Comments
It would be nice to start seeing our colour schemes in here as well. |
I'll make a separate issue for the colour scheme idea. We'll likely be able to close this issue out with this one: 73-gh-view-design#issue-703691097 … if the site editor inherits our WP.com global style fonts updates. |
There have been some updates to the core global styles since this issue was created. We may really need to only do two things here to satisfy an MVP.
Current wpcom UI: |
👋 There's a few things here. Core is now in the middle of updating the component system and reviewing the design of the sidebars (starting with Global Styles in the Site Editor I believe), see WordPress/gutenberg#27331 and WordPress/gutenberg#27484 Until those efforts are settled, I don't think we'll start developing the mechanisms for 3rd parties to extend the UI of Global Styles. On the other hand, there's also a task to implement the necessary hooks to allow changing all of this at the infrastructure level, see WordPress/gutenberg#27504 |
@nosolosw what if those extension-points would be |
The site editor is already experimental, so I presume that should be enough as far as UI extension goes. My larger point was that the GS sidebar is changing, so it seems best to wait until that dust is settled to avoid duplicated work. |
@nosolosw I think it's fine (although I'm not familiar with details so bare that in mind!). It's generally more valuable for us on .com get all FSE flows into internal testing earlier (like, next month), rather than in a perfect-shape much later on. We're fully aware that it's a moving target and we're prepared for it. :-) |
+1 on adapting to the moving target. We'll need to do that from a UX standpoint for our Site Editor testing flow …
Current status for step four lands them in the site editor with a version of global styles in the Site Editor that offers one font interface, that doesn't match what they saw before they got to the site editor, and if they travel to the page or post editor, they'll only then see a UI that matches what they saw in the site editor. |
With FSE in a better shape, and having the pieces necessary for a true FSE experience, I question the value of the font pairing step in Gutenboarding. With Global styles, we can move the font selection step, and maybe preview into FSE where we could use a guidance system (TBD) to inform folks they can modify their site fonts with the global styles sidebar. Also, with global styles getting the needed attention in core, assuming the UI will be changing maybe for the better towards something more contextual that provides affordance. |
+1. I might keep a large preview after the design picker step though? Just because it gives you a chance to evaluate what you're selecting. That opinion on the preview isn't a blocker for my +1. Removing the font selection in onboarding also opens up a chance to be more creative with font pairings. Right now they're the design options are tied to the small list of pairings. |
This may require a UI update, refactoring, or simply replacing core font options with our own but we should reconcile the two versions of Global Styles that we have live now. Compare the (core) Typography module on the left with the (wpcom) Font Selection module on the right available in the Post Editor.
The text was updated successfully, but these errors were encountered: