Preview limited Global Styles by default

[mmtr]

Fixes https://github.com/Automattic/dotcom-forge/issues/2267

Proposed Changes

• Custom styles are previewed by default, so there is less confusion around the site-editor and the front-end not matching up.
• Both the site editor and the post editor display now a global notice when Global Styles are limited. Previous sidebar notices in the site editor have been removed. This notice has the following actions:
  • Upgrade now (primary): Visible in both editors – It opens the Plans page in a new tab.
  • Remove custom styles (link): Visible in the site editor only – It resets the styles to defaults (it’s easy and safe to do so in the editor). Once we have a support page explaining how to remove custom styles, we can show it in the post editor too.
• Add a new notice to the view canvas.
• Updates the E2E test to use the view canvas mode since that's the only place where we have a fragile CSS selector.

Frontend

Before	After

Site editor (view canvas)

Before	After

Site editor (edit canvas)

Before	After

Post editor

Before	After

Testing Instructions

• Apply these changes to your sandbox.
• Sandbox a free site that uses Global Styles.
• Open the site editor.
• Make sure there is a global notice at the top of the editor.
• Make sure the "Upgrade now" action opens the Plans page.
• Make sure the "Remove custom styles" action resets the styles to defaults.
• Make sure the notice goes aways when there aren't custom styles.
• Open the post editor.
• Make sure the custom styles are visible.
• Make sure there is a global notice at the top of the editor.
• Make sure the "Upgrade now" action opens the Plans page.
• Make sure the "Preview your site" opens the frontend without custom styles previewed.
• Visit the frontend.
• Make sure custom styles are previewed by default.
• Use the Calypso live link below.
• Go to /setup/newsletter.
• Pick a "premium" color.
• As soon as the site is created, sandbox it.
• Get to the Launchpad's last step.
• Ensure the preview is using the "premium" color.
• Follow E2E tests setup instructions from https://github.com/Automattic/wp-calypso/tree/trunk/test/e2e
• Sandbox the primary site of the simpleSiteFreePlanUser user.
• Run the E2E test:
  • Desktop: yarn workspace wp-e2e-tests test -- specs/fse/fse__limited-global-styles.ts
  • Mobile: yarn workspace wp-e2e-tests test:mobile -- specs/fse/fse__limited-global-styles.ts

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-67229

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-67229&env=jetpack

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~71 bytes removed 📉 [gzipped])

name                        parsed_size           gzip_size
write-flow                        -72 B  (-0.0%)      -18 B  (-0.0%)
videopress-flow                   -72 B  (-0.0%)      -18 B  (-0.0%)
link-in-bio-tld-flow              -72 B  (-0.0%)      -38 B  (-0.0%)
free-flow                         -72 B  (-0.0%)      -18 B  (-0.0%)
build-flow                        -72 B  (-0.0%)      -18 B  (-0.0%)
newsletter-post-setup-flow        -27 B  (-0.0%)      -15 B  (-0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[BogdanUngureanu]

LGTM! Should we wait shipping this until we clarify the nudges in the Post Editor? 🤔

[mmtr]

@BogdanUngureanu I think we should yeah. I started adding the notices locally but it's not quite ready yet.

[matticbot]

This PR modifies the release build for editing-toolkit

To test your changes on WordPress.com, run install-plugin.sh editing-toolkit update/preview-global-styles-default on your sandbox.

To deploy your changes after merging, see the documentation: PCYsg-mMA-p2

[dsas]

I'm unsure about 'Remove custom styles' it looks like a link, just like it does in other places. In those other places though it is a link, here it performs a destructive (but undoable) action

[dsas]

I know we want to encourage people more to Upgrading than resetting. But Upgrade now looks like a button and acts like a link, and Remove custom styles looks like a link and acts like a button.

Maybe they should both be buttons but with Upgrade now being a primary button and Remove custom styles being less emphasised.

[dsas]

Make sure the "Preview your site" opens the frontend without custom styles previewed.

This is different to the existing Preview menu:

I think this difference in behaviour is ok, but I think ideally the new button might need to be clearer that it's a preview without styles.

Might be good to steal the new tab icon as well 🤔 or otherwise warn people it's going to open in a new tab. It's good for a11y too.

[BogdanUngureanu]

I think this difference in behaviour is ok, but I think ideally the new button might need to be clearer that it's a preview without styles.

Even more, what if we move that button directly in the preview section? Is it possible to add another item to that menu? This way, both modes (preview with styles and preview without styles) are in the same place.

[dsas]

Looks like this now needs a very quick rebase

[BogdanUngureanu]

Gutenberg edge now offers support for customizing Pages in Site Editor. Should we remove the Remove styles button from Pages displayed in the Site Editor? The user might have the expectation that the change would only affect the page, not Site Wide. 🤔

[mmtr]

The user might have the expectation that the change would only affect the page, not Site Wide. 🤔

Wouldn't that be also the case when using the "Reset to defaults" button from the Styles sidebar (which is also available when editing pages in the site editor)?

Since they have a option to edit styles globally across the whole site, I think it's ok to have an action in the notice that affects the global styles.

[BogdanUngureanu]

Wouldn't that be also the case when using the "Reset to defaults" button from the Styles sidebar (which is also available when editing pages in the site editor)?

Since they have a option to edit styles globally across the whole site, I think it's ok to have an action in the notice that affects the global styles.

I think it's debatable. We are adding this option for users that aren't familiar with Global Styles. Otherwise, they'll just use the "Reset" from the Global Styles panel, so some confusion might be possible since they aren't familiar with how GS work.

Also, the notice is part of the editor UI whereas the reset is part of the Global Styles panel. Some users might consider that since the notice is in the editor, it might only affect that specific page. And, who knows, maybe that GS panel shouldn't be displayed for pages, in core. It's a pretty new addition (the pages) and most likely will be refined in the future.

[dsas]

We are adding this option for users that aren't familiar with Global Styles. Otherwise, they'll just use the "Reset" from the Global Styles panel, so some confusion might be possible since they aren't familiar with how GS work.

That's helpful - the venn diagram of users familiar with GS gating and users that know how to reset GS is probably a circle. It's not the sole reason - it's also much more convenient for everyone else.

And, who knows, maybe that GS panel shouldn't be displayed for pages, in core. It's a pretty new addition (the pages) and most likely will be refined in the future.

I can't see hiding GS panel on the GS roadmap, GB phase 2 roadmap or the plan for reintroducing content editing to the site editor. In the absence of it being mentioned I wouldn't place any weight on the GS panel maybe disappearing, I think that would also make a pretty weird and confusing UI. It wouldn't be possible to work on some GS for a combination of blocks that only appears on one page at present, but you know you're going to add more pages in future.

If it does happen, we'll react to it then. Lets not block something on hypothetical unknown futures especially if we can quickly and easily react to it if it materialises.

I think it's ok to have an action in the notice that affects the whole site. If it turns out to be a problem we can remove it. We could also consider rewording the button to be clear that it applies globally, but I'm not sure that is necessary myself.

[mmtr]

Some users might consider that since the notice is in the editor, it might only affect that specific page

Is not that also true when editing the homepage? How would you differentiate users who think that are editing only one page from those who are editing a site?

Or putting it in a different way, check these two videos:

Screen.Recording.2023-05-17.at.11.30.13.mov

Screen.Recording.2023-05-17.at.11.30.49.mov

Do you think we should hide the action in the second scenario despite editing exactly the same content?

[BogdanUngureanu]

Just did another testing session and everything looks nice! Let's ship it! 🐑

[dsas]

Non-blocking query: When removing styles I get a snack notice saying 'Site updated', should/could that message be something more relevant like 'Site customized styles updated'?

[davewhitley]

Great work! This is great to see almost shipped. The only reservation I have at this point is that perhaps it should have a close button that temporarily dismisses the notice. Now that it's big and in the forefront, this could be a problem. People might just want it out of the way because they are working on something not styles related and accidentally click "Remove all styles" just to dismiss the notice.

Not sure if this is still relevant but we do have a doc on removing custom styles https://wordpress.com/support/using-styles/#reset-all-styles

[mmtr]

Non-blocking query: When removing styles I get a snack notice saying 'Site updated', should/could that message be something more relevant like 'Site customized styles updated'?

We don't have control over that notice, it's generated by Core: https://github.com/WordPress/gutenberg/blob/a0a1fd51e542b5c97f166f7be1679c2858dbb96e/packages/editor/src/components/entities-saved-states/index.js#L211

The only reservation I have at this point is that perhaps it should have a close button that temporarily dismisses the notice.

I think that's a good idea! I'll add it before shipping this.

we do have a doc on removing custom styles

Nice! I'll add a link to that in a follow-up PR.

[a8ci18n]

This Pull Request is now available for translation here: https://translate.wordpress.com/deliverables/7995550

Thank you @mmtr for including a screenshot in the description! This is really helpful for our translators.

[a8ci18n]

Translation for this Pull Request has now been finished.