Decide on and design template block placeholders for the editor

[frontdevde]

Context

For the WooCommerce Store Editing Templates v1, we're converting a set of WooCommerce PHP templates to a block each. Initially, the goal is not to create fully-featured blocks but instead create one basic block per PHP template that renders a placeholder in the editor and the template on the Frontend.

Goal

The goal of this particular issue is to decide on the placeholder design and copy for the editor.

Ideas

We created some basic prototypes to demonstrate the design challenge and offer some initial ideas on potential solutions.

Option 1: simple text-based placeholder

The first option would be to display a simple text-based placeholder that provides the merchant with an explanation that a) they are seeing a placeholder they can move and add blocks around and b) that the placeholder will be replaced by the related WooCommerce template on the Frontend.

This simple option has a couple of key advantages:

• Its compact size makes it easy for a merchant to move around and edit the page with other blocks. For example, if they'd like to move the template block into a column layout, it's easier to move a compact block than a prominent wireframe placeholder like below.
• It's very straightforward to implement. Given that these placeholders are a temporary stopgap solution, it is at least up for debate on how much work should go into creating them.

Note: we just used the Notice component inside the Placeholder component for the prototype here. As per Block Editor Handbook it sounds like the Notice should only be used for top-level notices. We'd have to use something else here.

Option 2: text-based replica placeholder

The second option is inspired by the recent effort of unifying Site Editing block placeholders. In situations in which the blocks have no data to reference, the blocks are now showing basic descriptions in place of where the relevant elements would be e.g. "Product title" where the title of the product would show.

The main downsides of this option are:

• Given that the placeholder mimics the actual template that will be rendered on the Frontend, the placeholder can get very large which makes it difficult for a merchant to move it around in the editor. The user experience arguably isn't great.
• Implementing this option means we'll have to basically replicate each entire template in the editor. Given that these placeholders are a temporary stopgap solution, it is up for debate if this is worth the time commitment required.

Option 3.1: wireframe replica placeholder

The third option is inspired by the navigation block empty state placeholder. In situations in which the block has no data, it's showing a basic wireframe representation of the content.

The main downsides of this option are:

• Given that the placeholder mimics the actual template that will be rendered on the Frontend, the placeholder can get very large which makes it difficult for a merchant to move it around in the editor. The user experience arguably isn't great.
• While this option is a little less involved than option 2, implementing this option still means we'll have to basically replicate each entire template in the editor. Given that these placeholders are a temporary stopgap solution, it is up for debate if this is worth the time commitment required.

Option 3.2: image-based wireframe replica placeholder

A potential solution to reducing the time investment for this option could be to just include an image wireframe representing the template. The assumption here is that designing these wireframes in Figma would probably be quicker than building out each wireframe with actual markup/styles?

[vivialice]

I prefer Option 2 because it gives a clearer idea of the space the block will take up in proportion to the other elements. Even though there is more "dead space" to scroll through to add additional blocks, it gives a better idea of the hierarchy of the page. Option 3 also solves this but gets a bit messy with all the text placeholders.

I hear and understand the concerns around investing the time into a more complex solution. I like the more detailed explainer copy on 3.2, so I'd suggest combining a few elements. If this solution is too time-consuming to implement, I'd recommend Option 1 with some revised explainer copy.

A couple of things I wanted to check:

• Is the explainer copy in the notice based on something else we have? When considering the target reader may not be as technically inclined, they may not understand terms like "frontend". I have made a suggested rewrite in the mockup, but I'm not a copywriter, so welcome any thoughts!
• How are the wireframe examples generated? Is it based on an actual block or have you built it that way with CSS?

Suggestions

The ideas I have are below. To summarise:

• I find the colour on the wireframes above too heavy and they don't need to be a point of focus so if we can use them this way, I suggest lightening them
• Copy edit for less technical readers as mentioned above
• Proportional sizing relative to the size of the actual block in the live site.
• Simplified wireframe preview. (I don't feel it's as essential to outline every detail in the actual template as it is to represent its layout.)

Hope this is helpful 😄

[frontdevde]

Summary of decisions made in discussion slack-archives/C02FL3X7KR6/p1635420504039500:

• We're going to go with design 1 (intro copy + image-based replica wireframe).
• @vivialice will provide one wireframe per template as SVG.
• On mobile, we will not show the wireframe but a shorter grey box instead (see design 2).

[frontdevde]

Closing this issue as we now have the placeholder designs we need:
template-placeholders.zip. Thank you, @vivialice!