Edit site: Block toolbar overlaps Top toolbar

[MichaelArestad]

With full site editing, blocks can be positioned directly below the top toolbar. When these blocks are selected, how/where should we present the block toolbar that doesn't cover the top toolbar?

Here's an example of what I'm talking about:

1. Fixed toolbar

Try the prototype

This would only appear when editing in a full site (or template) view.

No block selected:

Template block selected:

Benefits

1. No overlap with the top toolbar
2. The editing canvas remains in one place.
3. Persistent access to the template/page selector

2. Mind the gap

This concepts adds a gap between the top bar and the selected block only when needed. @shaunandrews mocked up this animation to give you an idea of how it could work:

I riffed on that a little here:

Benefits

1. No overlap with top toolbar
2. Uses regular block toolbar

Thoughts?

This was prompted by a discussion in Slack.

Source Figma file

[youknowriad]

Another potential solution is to add a small gap around the whole canvas similar to how we do in mobile/tablet previews

[mapk]

I really dig your riff on the second option there! The diagonal lines are sweet 😍 .

The blue border on the selected template part should probably give more space around the content IMO if we're using a border.

Something to keep in mind too is the Top Toolbar setting. When the screen gets too narrow, it drops down into a secondary toolbar.

Maybe this can help inform some of the direction here; positively or negatively.

[MichaelArestad]

Another potential solution is to add a small gap around the whole canvas similar to how we do in mobile/tablet previews

Good point! Will take a closer look at that next. Thanks!

Something to keep in mind too is the Top Toolbar setting. When the screen gets too narrow, it drops down into a secondary toolbar.

@mapk That's the same mechanism I was hoping would be used here since that's essentially what it is.

[karmatosed]

I have to admit my first reaction to seeing a second section is hesitancy. After analysing this I think it's because it feels almost claustrophobic as an experience. That said, I value the move from the sidebar and know on smaller screens there simply isn't the space in the toolbar.

I would love to see exploring around moving styling like spacing into a 'style' option, this could mean absorbing into the toolbar could happen until a smaller breakpoint. I think even in by block examples, this could clear the space there.

In seeing the 'bounce in' I do notice myself leaning against this. It feels removed from the experience. What I do like though is it keeps the toolbar, which feels key. Of all of them, I feel the later iterations are circling closer to a solution. I would lean away from diagonal repeating lines as these can move, animate for some people. Other options I would recommend exploring are a light shade, as noted just having a gap and maybe subtle dots (again being cautious about visual animation).

[jasmussen]

Thank you again Michael for high fidelity mockups and a well-laid out challenge description in the ticket! It really helps keep the discussion focused.

It seems important in this case to zoom in with extra clarity on the top toolbar aspect — Michael and Mark you both touch on it: "that's what this is".

A couple of the fundamental principles of the block editor are that everything is a block, and the way to simplify toolbars is to ensure that block toolbars are always contextual. As a principle this has helped guide a ton of decisions; it's why the Image toolbar does not have a "Bold" button, because it doesn't make sense to make an image bold. This is in contrast to classic editing interfaces like Google Docs where you can in fact make an image bold — it just doesn't make any visible difference.

In that vein, whenever you see block-contextual tools, they are in the block toolbar. And the block toolbar is placed either by the block (default) or in the top (Top Toolbar option). We should be very careful in mixing the two. In that vein, it feels wrong to me to make the fixed toolbar contextual, because this is the provenance of the top toolbar option.

The above frames the conversation in a slightly different light: which controls are block-contextual, and which are global?

• Template: Home is definitely global, it feels at home in the permant top toolbar (editor bar). But mainly, perhaps, when you're actually editing the template, otherwise it is likely to just confuse. If you need to change templates, that feels sufficiently advanced to put in the sidebar.
• Page: Home: also definitely global. Is this needed? I've gone back and forth on this, bouncing between the value in being able to name a page that doesn't have a Title block, and thinking it's fine to see this on page creation only. Perhaps it could have editor bar placement when editing pages, not posts?
• Group icon: definitely contextual, this is the block toolbar.
• Pixel paddings: I'd avoid this if at all possible as it encourages hard-coding random paddings that are neither responsive friendly or conducive to changing site layouts. But also block contextual.
• Discard changes — do we truly need this when we have prominent undo/redo buttons?

I like the chip treatment in the footer!

[shaunandrews]

Similar to my GIF in the original post, we could transition the canvas surface down revealing the editor's background surface (which we also expose with the new device preview button):

[MichaelArestad]

@shaunandrews I dig it. I'd like to see this route in action.

I do like how it makes clear exactly what the page canvas is rather than adding extra padding at the top. This is particularly important in the site editing mode as we need to present as accurate a preview as we can.

[shaunandrews]

Its worth noting that the current solution to this is a hard-coded padding applied to the top of the editor's canvas. This does cause some persistent extra space, but it also avoids any movement of elements on the screen.

[MichaelArestad]

This seems to no longer be an issue. Closing this for now.