Wp-calypso: Themes: Place non template-first themes behind a “more themes” option

[apeatling]

Switching from a template-first theme to an older theme that does not use Gutenberg templates is extremely painful. It retains the previous template-first theme's page template so the theme does not look anything like the theme they have just activated.

See the "Changing Designs" testing video on this post: p58i-8d4-p2

We must discourage our users from switching to older themes by placing them behind a "More Themes" button in the theme showcase. Only show them when the user hits this button, and include a notice that says "These themes are older, and may require more work to set up.".

[michaeldcain]

Some questions for discussion:

• Is this a better flow for all users, or just Gutenberg users?
• Is Template First Theme Switching enabled to all users, or just some subset (new users, locale, Gutenberg-only, etc.)? (/cc @obenland)
• Does it make our selection look too small?
• Should we include some blog themes (since they don't require the same amount of setup on switch)?
• Do we filter all showcase views by TFT initially, or just the first load? (i.e. search results)

@apeatling @rickybanister @ianstewart

[obenland]

Is Template First Theme Switching enabled to all users, or just some subset

It's enabled for everyone

[apeatling]

Is this a better flow for all users, or just Gutenberg users?

It's better for new users certainly, and they're all Gutenberg users. If you're not using Gutenberg, then it's not a great experience, so that's a lot of our older users. I suspect many of those never switch their theme though. Need data on that, but I don't think it should stop us making the change for all new users at least.

Does it make our selection look too small?

55% of theme activations are one of those template first themes. In user tests the users have sounded overwhelmed at the selection. The button should be a clear "There's more themes behind here!", so we're not removing them, if they want more they can get more.

Should we include some blog themes (since they don't require the same amount of setup on switch)?

I think this is fine, pick a few of the most popular blogging themes.

Do we filter all showcase views by TFT initially, or just the first load? (i.e. search results)

I don't have a strong opinion on this one, what are your thoughts?

[rickybanister]

The competitor we spend the most time talking about shows only 24 'popular' templates.

We do risk a perception that there aren't many options, but since there is no theme selection step now there could be an accidental perception that we offer just 1 to business customers.

And we start feeling pressure that the selection is limited, it might be a forcing function for us.

[apeatling]

Good points Rick -- user testing just these themes might also teach us if we need more or not.

[ianstewart]

We'll want to determine how to show/hide the all|free|premium filtering when we are limiting the first results to a select few themes. Perhaps only loading the whole magic search component when "More Themes" are revealed.

[vindl]

@apeatling @olaolusoga @shaunandrews I think that @Automattic/cylon will be able to tackle this one soon. Do you think still think that this is something that we should prioritize? And if yes, could we get some design ready for our next sprint?

[apeatling]

There is a bit of theme design in the Figma linked on the main 0-to-FSE post.

[noahtallen]

@apeatling Some q's since there are some different ways of navigating the themes screen:

• Should the search and filter function only work with template first themes?
• Would all themes become filterable and searchable when clicking the show more button?
• Additionally, there is mention of a modal telling users that those themes are older. Would that happen when trying to activate an older theme? Or when clicking on the "show older themes" button?

[shaunandrews]

Here's a quick design mockup for how we could focus the themes screen on the FSE-compatible themes, while still offering access to the full collection...

• Added a page heading based on the ongoing work on #37343
• Restructured the current theme banner, increasing the font-size for the theme name, removing the "Customize" button, and adding quick access to documentation and support pages for the theme.
• Reduced the width of the theme thumbnails at the 1024px viewport to help show as many themes as possible within the viewport. This obvious will change as the viewport changes; reducing the columns on smaller viewports and increasing the columns on larger viewports.
• Added a new button at the bottom to show all available themes.

Clicking on that new button will show the current search/filter system and all the available themes using infinite scroll:

[Addison-Stavlo]

I am wondering if moving the search bar is going to cause confusion with new and existing users, thinking "where is the search bar to filter these?". Will having the entire search feature limited to the non-template first themes cause clutter at some point if we end up having a larger and larger list of themes in the top level and they are never filterable?

I am wondering if we could keep the search bar above all the themes, but then have the search results divided by theme types. That is, matching results for 'recommended' themes would be in the top section, and the bottom section below the line would have the matching results for non recommended themes hiding behind the 'view all' or 'view more' button?

[shaunandrews]

cause confusion with new and existing users, thinking "where is the search bar to filter these?

For new users, the idea is that we would focus on FSE themes. For existing users, we could keep something similar to the current design showing the search at the top and all available themes without hiding them behind a button.

cause clutter at some point if we end up having a larger and larger list of themes in the top level and they are never filterable?

This could be a problem down the road, but right now its not. At some point in the future the concept of a theme will likely be less of an _thing_, and changing you site's style/design will happen within the block editor.

I am wondering if we could keep the search bar above all the themes, but then have the search results divided by theme types.

One of the things we've seen in user test is that the current token-based search UI is rather confusing and complicated.

[Addison-Stavlo]

That all makes sense to me. I will get started on this today.

[apeatling]

I love the simplification @shaunandrews. One confusion:

Clicking on that new button will show the current search/filter system and all the available themes using infinite scroll

Where is the new button?

[noahtallen]

There‘a a “view all 293 themes” button at the bottom of the first screenshot in https://github.com/Automattic/wp-calypso/issues/37285#issuecomment-554444917 :)

[apeatling]

Did I just fall for the "press any key" problem? 😛

[ianstewart]

Where would "uploaded themes" (when present) fall in the above design?

[shaunandrews]

Did I just fall for the "press any key" problem?

lol, yes. I meant new, as it a new button on the screen — it was in reference to the "view all" button.

Where would "uploaded themes" (when present) fall in the above design?

The button remains at the top-right of the recommended themes. It should look/work just as it does today.

[ianstewart]

Ah — meant this list …

When there are uploaded themes present would they appear above the recommended list?

[shaunandrews]

When there are uploaded themes present would they appear above the recommended list?

Ah, got you now. I didn't include it in the mockup, but yes any installed themes would appear above the recommended list.

[apeatling]

@noahtallen Are your questions answered by @shaunandrews's mockups? Or do you need more specific feedback?

Additionally, there is mention of a modal telling users that those themes are older. Would that happen when trying to activate an older theme? Or when clicking on the "show older themes" button?

This one I didn't envision as a modal, just a message at the top of the rendering of older themes after clicking the "View all 293 Themes" button.

[noahtallen]

Yes, they are answered!

[Addison-Stavlo]

To clarify, is this a change that should be active for all users or only sites that have FSE enabled?

[apeatling]

All users

[michaeldcain]

@apeatling all users or all new Gutenberg (new) users?

[apeatling]

I think since this does not limit accessing older themes, it can be all users? Are there issues you can foresee with doing that? /cc @michaeldcain?

[apeatling]

Having said this, if going out to all users has issues, just limiting to new users in the test-fse flow for now is entirely fine for milestone 2.

[vindl]

Having said this, if going out to all users has issues, just limiting to new users in the test-fse flow for now is entirely fine for milestone 2.

One thing to be mindful of here is that we probably don't want to tie this to FSE activation status, since changing to unsupported theme would change it, and we'd end up displaying old/existing theme showcase (might be confusing). FSE _eligibility_ might be better suited for determining when to display beta group flows.

[noahtallen]

True. If we want to do eligibility, we'll have to update the various API endpoints to add that tag on top of FSE activation

[apeatling]

FSE eligibility might be better suited for determining when to display beta group flows.

Can you explain what FSE eligibility means in this context?

[noahtallen]

FSE eligibility means that the site was stickered with "full-site-editing". Another way to think of it is this is the group of people who landed in the FSE enabled portion of the A/B test. It doesn't matter what theme they may have activated, so they may or may not see FSE flows. (That's what "is fse active" means -- do they see FSE on their site right now.)

Currently, the global styles plugin is based on FSE eligibility as an arbitrary limitation to do a gradual rollout.

It would be important to use that in this case because whether or not a site is eligible never changes in normal flows. So no matter what theme they activate, the value would stay the same.

[apeatling]

Thanks @noahtallen this makes sense. /cc @Addison-Stavlo to make sure we wrap the theme showcase changes around eligibility.

[vindl]

Thanks @noahtallen this makes sense. /cc @Addison-Stavlo to make sure we wrap the theme showcase changes around eligibility.

To clarify, my comment around eligibility was a note regarding the possibility of pursuing the following option:

Having said this, if going out to all users has issues, just limiting to new users in the test-fse flow for now is entirely fine for milestone 2.

But since the issues with that approach haven't been raised anywhere as far as I can see, it would be a lot easier to release this for all users (not gated), since we already have a PR ready for that.

[apeatling]

With a happiness heads up post, I'm okay with this.