Enable the user to switch which entity is being previewed in the template editor

[jameskoster]

The existing flow from editing a post to editing the post template creates a view where the user is editing a template with a specific entity loaded in to provide context.

In the site editor it is also currently possible to edit a template without any context, and see placeholder content in lieu of actual post data.

Since all the pieces exist to do so, we should consider allowing the user to switch which entity is being previewed while editing a template. This will be a useful tool to ensure that any template edits in the current session will play nicely with a variety of compatible entires.

We can utilise the "View" menu (proposed in #27847) to contain this affordance.

Because the organisation of content can get quite complicated on larger sites, we might use the drilldown pattern from the site editor navigation to keep this menu simple:

https://user-images.githubusercontent.com/846565/105729744-710c6b00-5f25-11eb-9cfb-5c3fcf9e8212.mp4

It is (hopefully) quite easy to imagine different sections for different content types.

Once content is selected, an interstitial indicates which blocks are looking up post data.

[wittwitsan]

From the Design Triage today, we agreed that this feature would be interesting to try out. The workflow seems logical and natural as a user.

As the Preview/View button drop down is suitable area to view an aspect of the web site. The feature fits in there.

It would also be nice with some feedback from @shaunandrews and @joen as well.

[shaunandrews]

Generally I like the idea; I think the View menu is a good place for this functionality.

Would the list of entities include all of them, or some curated list of "favorites" or example content? I wonder how the menu would look/work if there was, say, 30 different items. There'd probably need to be a way to search.

The drilldown pattern works if you have more than a few items. If there's only 5 items, it might be better to just display them without the need to drilldown.

[jameskoster]

Would the list of entities include all of them

To begin with I think it would include all entities that resolve to display the current template. There could indeed be a lot of data there, so some kind of search / pagination would be good to explore.

The drilldown pattern works if you have more than a few items. If there's only 5 items, it might be better to just display them without the need to drilldown.

Agreed. This needs a little more exploration work for different situations. For example if a site only has an index template then everything from single post entries to author archives will utilise that template, and subsequently everything could be used to populate that template as a preview while editing it. That is where the drilldown will come in to its own.

[kellychoffman]

I'm not so sure. Viewing how this page will look on a mobile app and selecting which content to pre-fill the template with feel very different from one another and I'm not sure I'd think to look in this dropdown menu for this. A sidebar section could give you more room and make it more discoverable.

Small copy suggestion: Sample text instead of "None".

[jameskoster]

Viewing how this page will look on a mobile app and selecting which content to pre-fill the template with feel very different from one another

While I agree they are different exercises, I still think they are related in the sense that their shared purpose is to provide an illustration of how the template will render in different circumstances. Perhaps there's a better label(s) we could use for the menu and its options?

A sidebar section could give you more room and make it more discoverable.

This is true, but conflicts with the principle that the sidebar is for settings, which this is not. So I am hesitant to put this there. The only other location I can think that might work is the template dropdown:

Small copy suggestion: Sample text instead of "None".

👍

[youknowriad]

Right now, the template editor is a child of the post editor but this proposal make it different and it blurs the lines between the template editor and the site editor. For this reason, I think it's a bit too soon to do what's being proposed here. It also raises bigger questions like: Why I'm being shown "Post A" when I'm editing "Post B".

If we want to consider the "template editor" as its own screen, that just means remove it in favor of edit-site.

[porg]

History

• Until v15: Very blurry line between Site Editor and Block Editor.
• Since v16: Clear distinguishing between editing a template vs. a concrete page-instance.

Usability — Self observation

• Helps orientation/onboarding for beginners and inattentive pros.

• But for pros: Template editing with concrete instances is SO MUCH MORE powerful than with sample/placeholder content. The difference is like day & night!

• Update: Tested v16.1.2: You can have the Site Editor open with a concrete page, but only to some degree, namely

  • You can then still do some template design tasks
  • e.g. Styles Panel can be fully accessed
  • But not all template design tasks!
  • e.g. List View (the Block outline in the left side panel) uses abstractions,
    • Does not show all elements of the template
    • Shows no template parts
  • No possibility to edit template parts inline the template
    • So important to see AND edit them side-by-side

User Experience — Professional Opinion

• Having these stricter segregated modes is honestly a step back in regards in the FSE UX.

• Leads to the oldschool behavior: "Edit here, preview there"

  • Site-Editor-Screen °1: Concrete page instance

  • Site-Editor-Screen °2: Template with placeholder content + Back button (leads to °1)

  • Reload, Reload, Reload… or switch back/forth → Oldschool 1990ies webdesign behavior

  • This is a real big regression

• The intermix of Site Editor and Block Editor as in v15 in comparison was really very progressive!

[porg]

Food for thought: "Full" (!) as in "Full Site Editing" — Stick true to that.

• Wanna swap out template part header-fluid against was a departure from that goal and see how that visually interacts with concrete page instance X and its rather long headline, or page instance Y and its very strong hero image?
  • All that was possible in v15!
• Now in v16: Too many steps inbetween which disrupt the flow.
  • That way design ain't fun anymore.
  • But again gets chunked along strict technical boundaries.
  • Less WYSIWYG. More "save and oldschool".

I know it's hard. But it must be possible! Elegantly. That's the UX design challenge here!

[youknowriad]

Hey @jameskoster what's left here after the introduction of the content editing in the site editor?

[jameskoster]

@youknowriad this is a slightly different flow that isn't covered yet.

Example: You're editing the single-post template and want to preview how your changes look when applied to a few different posts. Perhaps one is more text-heavy, another more image-heavy. Or one has hundreds of comments. That kind of thing.

I don't think it's high priority and there may be a better, more holistic way to capture it such as providing a way to preview unsaved changes in the site editor.

[jarekmorawski]

Loved reading through the discussion so far. We run into this problem while redesigning WooCommerce blocks. When editing a product page, knowing what it's going to look like for different products and product types is crucial. I came up with a few ideas that I think could apply beyond Woo's use cases.

There’s nothing in the current UI that we’d link to how the editing is done except for the controls in the top left corner. Perhaps we’d have an extra context toggle where the user could choose to show/hide the template and choose the template’s context? We’d default to placeholders, of course.

Note that we're also surfacing controls for different product states, like on sale or featured. This is important because depending on the store's setup, the PDP may look different when the product goes out of stock or is put on sale.

As an alternative, I looked at displaying the content controls in the Template tab in the Inspector. It makes sense on the surface, but then most settings there are about the block's appearance or shopper's experience and it can be confusing to see there something that's purely an editing tool (hence why I think a tool-first approach above may be more logical).

We'd compliment either solution with a dismissible notice informing the user about the currently edited template variation.

On top of all that, I looked at a dedicated mode, which would let the user pick the content while previewing the template. This, however, would be a major departure from the current flows and poses certain risks to extensibility.

https://github.com/WordPress/gutenberg/assets/79307566/6acdc3a3-1c77-4446-b565-f6ff115b4c88

I look forward to hearing from you. Do any of the solutions above solve the problem? Is there anything we can learn from them to push the work forward? As I mentioned earlier, preview content support is essential to a good store editing experience in WooCommerce and I'd love to get things off the ground and continue refining the UX later on.

[jameskoster]

Thanks for sharing. Instead of a whole new menu, I wonder if the menu in your first concept could be integrated with the current View menu somehow? To tidy things up a little Status and Stock could be flyouts, making use of DropdownMenuRadioItem / DropdownMenuCheckboxItem.

[jarekmorawski]

Sure! I think that works well, but only if the preview button stays in the top bar (I believe it's too important of an action to be tucked away in a dropdown).

Content:

Settings:

[jameskoster]

Could work. A quick mockup based on core templates / DropdownMenu V2 components, and factoring in zoom controls: