Isolated template part editing view could use some refinement

[jameskoster]

Here's what editing a template part in isolation (via the sidebar menu in the Site Editor) looks like currently:

Here are a couple of opportunities for improvement I see:

• The boundaries of the template part are not clear.
• The template part occupies the entire width of the canvas, parts that render in narrower containers look odd in this context. Now that the canvas is inside an iframe perhaps we can add resize handles?
• The "Template" tab in the sidebar should read "Template part" and contain an option to set the name and area.

Any other thoughts?

[mtias]

A while ago we had this, with the separation on the backgrounds.

We should constrain the iframe to signal you are editing just a part. It'd be neat to support resizing the canvas to see how a unit scales responsively cc @ItsJonQ

[ItsJonQ]

The boundaries of the template part are not clear...

@jameskoster I agree with you and @mtias in that the Template Part editing view should focus on the part only. Not unlike seeing a single "frame" in Figma (or "Artboard" in some other apps like Illustrator)

I think having iFrame + resize handlers would be good for site editing in general :)

[jameskoster]

I think having iFrame + resize handlers would be good for site editing in general :)

One extra thing to consider here is the relationship between the desktop / tablet / mobile views in the "Preview" menu, and a user-specified width on the iframe.

Edit: Perhaps we add a "Custom" option there, which reveals the drag handles. This might be the default view for isolated template part editing.

[jameskoster]

Related: A loose "isolated" view for editing Reusable blocks was shared in #29337. Perhaps we can reuse some of the ideas there in our explorations here.

[annezazu]

Wanted to include some feedback from the second FSE call for testing:

I see the isolated view. Header area in the main layout. Header name in the top toolbar. An empty Block Inspector in the sidebar settings. Instead of an empty Block Inspector when first entering isolated view. A message saying “Viewing Header template” could come up in the empty Block Inspector area. As it would bring a confirmation that one is only seeing the Header template.

Perhaps adding in some sort of notice similar to the template editing notice would help here so people don't accidentally start building out a template in a template part for example. Ideally, similar to the template editing notice, it would be sticky: #28175

[jameskoster]

Realistically I don't think there's anything we can do to 100% stop folks from making this mistake, but general chrome optimisations will hopefully help.

On the subject of the block inspector, when you're editing something like a Template Part in isolation, I think the primary tab (normally "Post" or "Template") should be titled "Template Part" and contain all the relevant controls.

I'm working on designs for this at the moment and will hopefully have something to share soon :)

[jameskoster]

Here's an initial take on this:

isolated.edit.mode.mp4

The isolated editing view can be accessed from two locations:

1. The "Template Parts" section of the Sidebar Menu in the Site Editor
2. The ellipsis menu in the Template Part (and possibly Reusable Block) toolbar, as seen in the video

Once in isolation mode, the UI around the Template Part adapts in a number of ways:

1. In the Inspector, the "Block" tab from template editing view becomes a "Template Part" tab, akin to the Post / Page / Template tab, and the controls are migrated accordingly. This is potentially something we can expand upon in the future.
2. The Top Bar indicates that the Header is being edited.
3. A "< Back" button is revealed on the canvas which when clicked returns the user to the referring context
4. The Template Part is inset on the canvas, clearly indicating its boundaries
5. An input on the border of the Template Part allows users to test how it behaves at specific widths
6. A drag handle provides a looser equivalent of the above for quick-checks
7. A "Custom" option is added to the view options. This could even be something we bring to post and template editing in the future.

Thoughts and feedback:

• Do we need a cancel button along with the <Back button, so that folks can return to the thing they were editing and discard any changes to the Template Part?
• I based the drag handle styling on the block toolbar. Totally open to other suggestions there.
• Likewise the width input is a g2 unitinput, which hasn't been merged yet. So we may need a standard input in lieu of that.

[jameskoster]

Noticing a few other designs building around the concepts shared here. Might be time to assemble a draft PR since there hasn't been much design feedback.

[jameskoster]

Probably worth considering the part patterns will play in this environment, particularly some of the ideas we explored in #28737 (comment).

Edit: Also whether one might access isolated tp editing via the new persistent list view.

[jameskoster]

Also whether one might access isolated tp editing via the new persistent list view.

We could potentially include an action on the row to enable this:

[talldan]

A question about the button in List View ... how do we reconcile that with the desire to also have block movers and other UI (like editable block names) in List View?

It feels like trying to cram a lot in. I'm also ignoring the past resistance from the accessibility team when it comes to introducing grid keyboard interaction patterns in List View.

Could it be worth trying the list view toolbar idea again (#21372)? In the past some design contributors have been keen on this, some not so much, but it seems like every option explored has trade-offs.

---

Something separate that I've been thinking about—is there a reason to limit this feature to just Template Parts? Maybe template parts are where the feature is explored first, but it could also have value for other blocks (reusable, group). Almost an extension of the spotlight mode.

[mtias]

@talldan yes, starting with template parts because it's the one that needs it the most, but we should extend it to reusable blocks which are the other kind of symbol. I'd avoid adding it to normal blocks.

It's not yet clear what items would be exposed (movers, ellipsis, locking, spotlight/focus mode, insert before/after, delete, etc). The toolbar for list view feels quite disconnected from the item it handles. Actions on the item is a very common pattern in software that relies on layers, so i think we need to do our outmost to build something usable there.

[noisysocks]

Hi! @kevin940726 and I were just discussing this.

We're wondering about how the isolated template part editor that this issue refers to ties in with the isolated template editor that you can get to from the post editor. This one:

• Should both isolated editors look the same?
• Should a user be able to access the isolated template part editor via the isolated template editor?

[mtias]

We are not calling the template editor "isolated" because it has nothing to isolate: it's just the full template. They should converge visually in terms of the background color and the navigation ("<- Back").

Should a user be able to access the isolated template part editor via the isolated template editor?

Possibly yes, it's not yet established how exhaustive the template editor you invoke from a post / page view is going to be, but the ability to focus on a template part or reusable block should be indistinct regarding context.