FSE: Page Template Selector UI Updates

[shaunandrews]

We'd like to move away from the existing modal we have today for page templates, which looks like this:

Along with this, we've heard in usability tests that people are wanting to see larger, more detailed previews of templates before choosing. I've worked up a few options for us to consider and implement.

The first one (A) shows a grid of thumbnails on the left, with a large preview area on the right. Hovering over a thumbnail populates the preview and allows you to see the template in more detail. Clicking on a thumbnail selects that template and populates the editor with the blocks.

The second one (B) is similar, but the interactions are different. Instead of hovering, you'd click on a thumbnail to populate the preview area. Then, you'd click on the newly appearing "Use this template" button to select the template.

-- Things to discuss:

• Which option do you prefer?
• Do you foresee any accessibility issues with either option?
• Mobile and responsive options. Obviously any hover affect is out of the questions. I imagine a swipe-able horizontal list of larger thumbnails without the need to show a bigger preview. This also brings up a discussion point around rendering template thumbnails/previews with mobile styling/breakpoints in place.
• How to switch templates after choosing one for the first time. This likely brings up further discussion around how we can map edited content from one template to another.

[getdave]

Thanks for doing this @shaunandrews. I agree these changes will improve the UX a lot.

Option B for me is a clear winner. This is mainly based on my knowledge of a11y guidelines, namely this one:

3.2.1 On Focus: When any component receives focus, it does not initiate a change of context. (Level A)

As a result I would suggest that using hover/focus (as in Option A) to initiate a change of state in the preview isn't a suitable interaction method for users. Therefore Option B is preferable.

Mobile and responsive options.

I'd say a swipeable list seems like a good option, but we'd have to include some visual "device" to clearly indicate that more templates are present (perhaps showing "ghosted" prev/next options in the carousel?). It would be great to see some explorations around these if possible (not sure how you typically prefer to approach "designing for devices").

This also brings up a discussion point around rendering template thumbnails/previews with mobile styling/breakpoints in place.

In theory, the work we've just completed on the BlockPreview component will enable this by default (although I'd need to test this to be sure).

TBH I feel inclusion of dynamic Block previews is a prerequisite to any of these changes as create static screenshots isn't going to be manageable/scalable.

How to switch templates after choosing one for the first time.

This comes up time and again and for good reason. We need to come up with a UX flow and UI for this.

Please note, however, as far as I'm aware the work to enable Block Template reconciliation within the Editor isn't quite there yet (cc @youknowriad who may be able to confirm ). As a result, we cannot easily "swap out" the Template within the same page unless no edits have been made to the content. Once the user makes edits the only way to allow them to choose a new Template would be for them to create a new Page from scratch - we could disable a notice/warning to the user about this?

[frontdevde]

If we go for Option B, we're introducing an additional click to the flow. We need to make it very obvious how to proceed after clicking a thumbnail and showing the preview. If we don't, we potentially risk seeing a steep decrease in usage. I'm not sure if the "Use this template" button is obvious enough yet?

[getdave]

Also, how do you dismiss this view? Imagine I'm a user who just wants to ignore this screen and "get on with it"? I'm wondering whether we still need a means to "dismiss"?

[getdave]

This is now underway at https://github.com/Automattic/wp-calypso/issues/35232

[apeatling]

Just noting that it's happening in the modal first, and then should be easier to transfer into the editor.

[apeatling]

How to switch templates after choosing one for the first time. This likely brings up further discussion around how we can map edited content from one template to another.

This is the biggest missing piece for me, and something we need to have worked out before we implement this change.

[shaunandrews]

Just noting that it's happening in the modal first, and then should be easier to transfer into the editor.

Can you explain why?

This is the biggest missing piece for me, and something we need to have worked out before we implement this change.

Are you suggesting that we can’t implement the UI changes until we solve the problem of switching templates? Or are you saying that before we allow switching, we need to solve the problem of mapping content?

[apeatling]

Can you explain why?

Discussed this in slack but to sum up:

1. Unknowns with the design and not having you there to answer. The comments were that it wasn’t fully baked yet. Although I think those questions have mostly been worked through in the modal implementation now.

2. The modal is a known entity and should be quick to implement the preview in. Moving to the editor could bring up technical issues that delay it.

3. It seemed like a logical next step that would get the preview shipped in one sprint. Then spend the next sprint refining and moving to the editor, and dealing with any issues.

Are you suggesting that we can’t implement the UI changes until we solve the problem of switching templates? Or are you saying that before we allow switching, we need to solve the problem of mapping content?

I'm saying that we know a pain point is switching between templates. The preview might solve that, so I'm willing to hold off on this concern until we get this stage shipped. Mapping content is a big and gnarly challenge that I don't foresee us tackling for some time.

[shaunandrews]

I'm saying that we know a pain point is switching between templates. The preview might solve that, so I'm willing to hold off on this concern until we get this stage shipped. Mapping content is a big and gnarly challenge that I don't foresee us tackling for some time

Makes total sense.

[shaunandrews]

Building on option B, I threw together a quick experiment for how we could add some transitions to the experience:

[shaunandrews]

Picking up on mobile, I've tried a few options.

The first is a series of swipe-able cards:

This might work, but poses a few challenges:

• As the number of templates increases, it will be unwieldy to swipe between them all — its already looking a little cumbersome with 9 templates.
• We'd need to be careful with the position of elements at the bottom of the viewport (like the dot pager above) as there might be browser chrome taking up space.

The second option keeps the grid of thumbnails and uses a sheet-like overlay to show the larger preview and button to continue:

Its worth noting the animation above uses an up/down motion for the larger preview, but we could just as easily use a left/right motion.

[shaunandrews]

Picking this back up, I think it might make sense to put the select button in the top toolbar and hide all the other Gutenberg icons and buttons. Something like this:

This helps focus the UI, and keeps the next actions in a consistent place. This lines up with the direction that the onboarding work is heading. /cc @ianstewart @Automattic/ajax

[obenland]

@shaunandrews Just to clarify, button in the tool bar instead of the thumbnails? Or in addition to?

Edit: And it seems this mockup is re-introducing a closing X at the top left, which feels like it's back to being a modal?

[getdave]

Let's also (somewhat) view this in the context that the work to move the buttons inside each thumbnail has already been worked on...

[shaunandrews]

button in the tool bar instead of the thumbnails? Or in addition to?

Instead. This design moves the button from within the thumbnails into Gutenbergs top toolbar. This is more consistent with the Publish button, and also with the way the onboarding designs are going.

And it seems this mockup is re-introducing a closing X at the top left

With the FSE plugin, Gutenberg uses an X at the top left. This wasn't intended to be new, its already there.

it's back to being a modal?

Its not an overlay on top of Gutenberg — this is Gutenberg. The white toolbar at the top is Gutenberg's toolbar. I've hidden the irrelevant icons and buttons, and added our select button ("Create a {templateName} page") in place of the publish button.

the work to move the buttons inside each thumbnail has already been worked on...

I can appreciate the fact that there's been work done on the previous design. I know it can be frustrating to have the design change after some coding has taken place, but I think moving the button solves a lot of problems related to line-length, translations, and accessibility.

[getdave]

This design moves the button from within the thumbnails into Gutenbergs top toolbar.

Ok I understand what you mean now. @Automattic/ajax we need to understand the impact on our estimates. Unless I'm mistaken this changes the scope quite a bit as the code implications are large.

...also with the way the onboarding designs are going.

Can I see these designs via an appropriate obfuscated link? I don't have this context. Apologies.

I know it can be frustrating to have the design change after some coding has taken place...

Appreciate you acknowledging this 😄 .

Sometimes, that's how things roll. I'm sure we don't expect this to become the norm, so I'm ok with it.

Nonetheless, as a team, we need to be also ok with acknowledging how changing direction at this point will impact our velocity and capacity during this iteration.

We now need to circle back to "planning" mode and figure out how this affects things. I'll reach out to @obenland now.

...I think moving the button solves a lot of problems related to line-length, translations, and accessibility.

You could be right. From an a11y POV, however, I have concerns that the toolbar region is largely divorced from the main editor body area in the document markup structure.

This means there will be no standard way to make the "confirm" button related to the template selection area. This means that we're going to need to think very carefully about how screen reader users can perceive that the "confirm" button is in a separate region of the page.

I'm on BST so please leave all your thoughts here and I'll take a look in the morning.

Thanks again.

[retrofox]

I can appreciate the fact that there's been work done on the previous design. I know it can be frustrating to have the design change after some coding has taken place, but I think moving the button solves a lot of problems related to line-length, translations, and accessibility.

Since we've already started to work on this, even PR is in Ready For Review state, I wonder if we can iterate later after once the changes are merged, considering that the whole feature won't be shipped to production either.

[obenland]

With the FSE plugin, Gutenberg uses an X at the top left. This wasn't intended to be new, its already there.

In that case we don't have to worry about it then. Good :)

I know it can be frustrating to have the design change after some coding has taken place

I take that also on me, I should have made sure you were in the planning meeting on Monday. But yes, this is a less than ideal situation. We'll throw out #36235, create a new ticket to move the button to the toolbar, and scope that. /cc @apeatling

[obenland]

Created #36323 to explore the new button placement

[ianstewart]

...also with the way the onboarding designs are going.

@getdave I put together a quick sketch based on some convos with @shaunandrews and @mtias about how we might be able to use Shaun's design in the Onboarding work we're doing. It's in Figma — let me know if you have any questions or thoughts!

[getdave]

let me know if you have any questions or thoughts!

Thanks for sharing @ianstewart. Much appreciated.

My main concern is highlighted above in relation to the accessibility implications. If those are considering in advance during Design this will make implementation in an accessible manner a lot more likely.

If we're introducing significant UI patterns such as this, we have to consider a11y. I'm sure you are already on it but I always feel obligated to mention it.