Interesting idea @melchoyce.

My first reaction was how by moving them to the bottom it makes the block more 'blocky' - which is a weird thing to say but something this makes me feel. Is the border showing on click or on hover? I think I have less of an issue with it on click than if it's on hover. Another interesting visual this makes at least your examples look like a Polaroid image, super interesting how my brain went to there.

That's my first reaction though, digging a little more I do think there's merit into exploring a different position for the interaction icons on a block. I think what is gained her is absolutely a way that works better across all screens, that we should hold as a guide as further explorations happen.

I do think we lose some context to the interactions. For example, a block with a taller placeholder would have those interactions not directly visible. I feel that's going to be a hitch that could add up to less discoverability.

All of this said, I am absolutely not saying what we have now should be the way forward. Are you up for iterating and maybe exploring more? I really hope you are.

I think visually this is nice. It's essentially the mobile UI, on the desktop breakpoint, and it's something I've considered both as a plan B if the side UI didn't work out, or perhaps for nested contexts.

Since then we've both made strides with the side UI, most recently in https://github.com/WordPress/gutenberg/pull/6141, and we've gotten it to work decently well in nested contexts as well, though that aspect still needs some love.

Althougn not as pretty, the main benefits of having this UI on the side, are,

1. that they can appear on hover
2. they don't expand the footprint of the block

1 is especially important, as from the start it's been an explicit goal to make sure drag and drop is _additive_, and not the primary form of interaction with placing, reordering and sorting blocks. If we place them below the block, presumably they would appear on click, which would make it secondary to drag and drop which would always work on hover.

2 could be important depending on how we deal with the side UI in nested contexts. Right now we're facing some challenges in https://github.com/WordPress/gutenberg/pull/5452#issuecomment-380721863, and although I'm sure we'll be able to solve those, the fact that the footprint doesn't change helps.

All of this is not to say "can't work" — it could very well work. A waaaay old mockup had this UI as an overlay in the corner:

So all in all, good ideas, and good to keep them in the noodle as avenues that can be explored depending on the feedback we receive release to release!

Is the border showing on click or on hover?

Just on click. Hover would be similar to how it works now.

Are you up for iterating and maybe exploring more? I really hope you are.

Always 👍

they don't expand the footprint of the block

Yeah, definitely an issue with this idea. Even in this prototype you can see some jumping around because of the sizing change.

So all in all, good ideas, and good to keep them in the noodle as avenues that can be explored depending on the feedback we receive release to release!

👍 👍

I do think we lose some context to the interactions. For example, a block with a taller placeholder would have those interactions not directly visible. I feel that's going to be a hitch that could add up to less discoverability.

Althougn not as pretty, the main benefits of having this UI on the side, are,

1. that they can appear on hover
2. they don't expand the footprint of the block

I think one way to solve these problems would be to have the block tools toolbar appear on top of the blocks below and not increase the space the block actually takes up in the editor. As for discoverability with tall blocks, the toolbar could be made sticky so that if you scroll up, the toolbar does not go off-screen. (It still disappears when not hovering over the block, of course, and perhaps it could only appear when hovering the lower part of the block that is currently visible, similar to how the side controls currently work.) It could also just take up as much space as necessary to show all the buttons, and not take up a whole row of empty space in between 2 sets of controls like it does in the mockup in the main post of this issue.

+1 Just to note that this could also help to improve the tab order of the UI controls around the blocks. As mentioned in https://github.com/WordPress/gutenberg/issues/5694#issuecomment-386645531 the mobile UI has the "side controls" placed in a more logical way. See the animated GIF that illustrates the tab order, you can compare with the previous GIF with the tab order in the desktop view in a previous comment https://github.com/WordPress/gutenberg/issues/5694#issuecomment-384619052

Also to take into consideration:

3976 proposes a third option to place the block toolbar (the formatting toolbar) below the block; it would be great to consider a design with both the block toolbar _and_ the side controls placed below the block to see if that could work.

1934 as a general issue about consistency of the tab order

This could also have an impact on solving some of the issues raised in #6272.

As for discoverability with tall blocks, the toolbar could be made sticky so that if you scroll up, the toolbar does not go off-screen.

Yep, that's what happens with the top formatting toolbar too:

Reading through all the awesome feedback here it seems this solves a number of issues going forward and today with accessibility. That in mind, I think we should work on maybe some iterations here and then move into a PR to prototype. Would you be up for doing that @melchoyce?

Yeah, I can take another look.

+10 for trying this out.

This is what the block UI looks like when I shrink down the width of my browser window. (If I shrink it some more, the block toolbar moves below the block, but that is not relevant to what I am suggesting.)

I noticed that the block inserter appears next to the up/down movement controls. If this kind of UI were used for all screen sizes like this issue is proposing, then perhaps the current block appender could be removed from nested block contexts, making the editor look more like the front-end by removing the always-present extra space added by every block appender for each level of nesting. (I also suggested an alternative solution to the appender-eating-up-space issue in #6834.)

Also, this is just a side note, but is the Remove button supposed to be to the right of the More Options button, or should it be on the left? In most UI designs, ellipsis menus are placed on the far right.

Another idea:

Show these block controls on the bottom on hover, but in this state, they do not take up any space on the page, and instead appear on top of whatever is below the hovered block (just like the block toolbar does for blocks above the current one) or perhaps on top of the hovered block. The block controls on the bottom should also not be an uninterrupted white bar on hover, but 2 smaller bars on each side, similar to the block toolbar, in order to make the controls take up less space and not cover up as much.

When you would select a block, the block controls at the bottom would take up space, increasing the visual footprint of the block and pushing the blocks below out of the way, like how when you select an Image block the caption placeholder appears. This would make it easier to select the block below if it was a vertically short block like a single-line Paragraph block.

This approach would allow you to keep the benefits of the current on-hover controls allowing you to easily move/delete blocks without first selecting them, while also making sure that the controls do not cover up anything when the block is being edited, making it easier to then select a different block.

One more idea:

Allow the entire block controls bar (and the block toolbar) to double as a drag handle (including the buttons, like how GTK header bars work). I think this would pretty much solve the drag-and-drop discoverability issue, especially in the context of selected blocks, where the bottom controls bar looks like it is part of the block in the mockups in the initial post, and therefore users would probably be more likely to think of trying to use it as a drag handle.

Contrast that with the current situation where the sides of the block do not look like they are part of the block, and it is therefore not that obvious that they can act as drag handles, and there is also the issue where single-line Paragraph blocks hardly have any empty space on their sides to drag from. (And since the side control buttons can not be currently used as drag handles unless they are disabled, the issue is made even worse.)

Lots of awesome discussion around this, let's seen if I can give some summary feedback to hopefully give you something to move into iteration with @melchoyce.

Overall I think I need to feel this in a prototype and a lot of my thoughts I think can be eased with that. However there are a few considerations I would like worked into a mock:

• A solution for tall blocks.
• A less 'blocky' feeling: this may be just showing the placeholder states in a mock, I am reading it as more obvious with these changes.
• Showing how this works with nesting.

I would love to see how this also adapts to different devices, my thinking is there is less variation and that could be a great thing.

@SuperGeniusZeb some interesting thoughts you have there. I would like to see where Mel gets with the above iterations. I think doubling up UI for dragging handles is something for now to avoid, there are nesting changes being worked on I would like to get in there. I am not saying we won't iterate, but this UI isn't specifically for that. I also think you can infer belonging without being explicit visually and where it becomes too explicit is where the negative feeling of blocks comes in - it feels close and too limiting.

I was noodling around on #7211 and in the context of that work I discovered #7646, and that brought me back to this idea, which really feels like the best solution for a bunch of problems.

This ticket would, directly or indirectly, fix a whole bunch of things:

• #7646 → with controls being positioned above/below, you don't have to worry about accommodating side UI
• #7182 → controls like the ones in the mockups on this ticket are directly connected to the block and would have consistent UI regardless of nesting level
• #6451 → if top/bottom toolbars have a solid background, you don't have to worry about figuring out how to make controls visible on dark backgrounds
• #7114/#6265 → If you use a full width toolbar like in some of the above mockups, you can use the empty area for dragging/dropping

All this to say that, if there's still a chance a change this big could land in Gutenberg, I think it could solve a lot of problems and make a lot of things easier :) I'm going to join in the fun and work on some mockups/concepts hopefully this weekend.

@chrisvanpatten just to add perspective this issue is about controls not toolbar being moved to the bottom. That would cause a lot more issues of usability. Just checking as some issues you link seem to be around toolbars.

I'd be totally in favor of trying this, as it improves a lot the tab order. A quick update: the remove "trash" button has been moved within the ellipsis menu. I'd also suggest to try to meet the proximity of controls principle and place the ellipsis button immediately to the right of the movers. Not sure why it should stay so far to the right:

@afercia as they are different controls I think having the ellipsis on the right makes sense. Let's explore that as a step one. We need to focus on exploring the following:

A solution for tall blocks.
A less 'blocky' feeling: this may be just showing the placeholder states in a mock, I am reading it as more obvious with these changes.
Showing how this works with nesting.

These points need exploring to determine the route from this promising point.

@karmatosed I was using confusing lingo - I meant controls, not toolbars. The toolbars are already on top - nothing to change there :)

I just made some mockups of what I imagine the block tools could look like if put under the block. Note that in these mockups, the block tools never take up any space, only acting as overlays like the block toolbars on desktop. The blocks are also selected in these mockups. If only hovering over a block, the block toolbars on top would not be shown. Also keep in mind that the bottom controls could still only appear when hovering near them like the current side controls.

Normal:

When bottom of a block is off-screen:

(Side note: the Image block toolbar does not match the one in these mockups as it has different options in its block toolbar.)

Given the issues with the block tools being on the sides and the several benefits of having them on the bottom, I am now convinced that having them on the bottom is the way to go.

@SuperGeniusZeb That's basically exactly what I was thinking except I was going to position the more options button with the up/down arrow instead of to the right, as a combined toolbar.

@chrisvanpatten Yeah, I would not mind either way if the controls were separated or not.

Here are some more mockups:

Hover:

Selected with fullwidth bar that takes up space (rather than just being an overlay) like on mobile and could double as a drag handle:

I have to say I think we're in a little danger of this becoming too blocky... that's a weird way of describing this but going with it :) For example, the hover shown in last mock is quite intense. I think we have to seeing this go more for what Mel showed in first image that's got one less border and it really does help not having that.

I took the first mocks and removed the trash can to get what I think would be best to progress with:

We don't need the extra borders and we don't need the weight added. This way it allows easy dragging without the unusual hovering outlines.

@karmatosed I modified your mockup to show what it would look like when you hovered over a block:

And here it is with the block selected and the block toolbar shown:

(I also updated the Image block placeholder to match the current one in Gutenberg.)

Something that kind of confuses me about having no upper border on the controls: are the controls still on a white background? Does this mean the entire block has a white background behind it? That sounds like it would cause issues in nested contexts where a block is nested in a container with a dark background, as selecting (and/or hovering) would cause the background of the block to change, which would look quite jarring.

Something that kind of confuses me about having no upper border on the controls: are the controls still on a white background? Does this mean the entire block has a white background behind it?

It does but the controls have targets. I think it's worth showing and avoids the block visual issues without. This absolutely needs exploring in nesting, however without the background it would get even worse in nesting visually.

It does but the controls have targets. I think it's worth showing and avoids the block visual issues without. This absolutely needs exploring in nesting, however without the background it would get even worse in nesting visually.

Agreed, and having the background also solves #6451.

I do not like having that big empty bar shown on hover in those last mockups. Ideally, you would want to cover up as little of the surrounding blocks as possible on hover, but this covers up quite a lot of the block below. How about something like this?

As suggested before, the arrow movers and ellipsis could double as drag handles, and/or the hover title could be a drag handle. (See #7114.)

@SuperGeniusZeb whilst I understand your points in this case having the blocks outlined really isn't great visually. Lets stick with the mock I made based on Mel's awesome work to see it into prototype.

Something I just realized about having a white background appear behind selected blocks: what about blocks with a white (or otherwise light-colored) text color meant to be seen in a dark-colored area (provided by something like the Container block)? Having a white background for the entire block would not work in this instance.

The background is around the toolbar which is always going to have those controls.

@SuperGeniusZeb Yeah I don't see the white background impacting the block itself, only the controls. Practically it could be something like this:

Or the padding could potentially be removed (I really like this approach but it's obviously a bigger question that has implications w/ drag and drop. Still think it's worth considering):

@chrisvanpatten I like that last mockup. I do not think drag-and-drop would be an issue since the bottom bar could as a drag handle (and potentially the buttons in the bar would work as one as well). You could even add a drag handle icon to the bottom bar on hover or just always have one there to indicate you can drag the block using it.

With this approach I see no reason to keep the draggable area near the borders of the block. Removing that padding could also help make the block hover/selected outlines be closer to the actual borders of the block, since they would no longer have to account for having that drag space and would only have to adjust to be larger than the actual block in cases of nesting to make selecting parent blocks easier. (Selecting parent blocks would be less of an issue if stuff like the mockup in this comment in #6459 was implemented.)

@SuperGeniusZeb

You could even add a drag handle icon to the bottom bar on hover or just always have one there to indicate you can drag the block using it.

Great idea 💡

I think let's leave the draggable area to one side and implement this. It's important to focus on getting the thing this is solving resolved first. I have to say I am not sure an icon is the right approach, that said let's revisit once we have this implemented without that.

@karmatosed

I think let's leave the draggable area to one side and implement this.

I am not quite sure what this means? Which side?

Glad to see this is going to happen. Just a quick reminder that it's not just about visual placement. For a11y, visual order and tab order (DOM order) should match so these "block tools" should actually be moved after the block editable area in the markup.

One nice benefit of switching to controls below the block is that it opens up the side space to allow for the sibling inserter to be redesigned to something like the ones in Squarespace if the current design runs into issues. The current side controls would have overlapped this kind of inserter and would look cluttered, but with the controls moved to the bottom, this is no longer an issue.

https://support.squarespace.com/hc/en-us/articles/206991377-Adding-blocks#toc-insert-points

Just commented about this on #7500. I was wondering how successive paragraphs would look with this design? I think having the bar at the bottom would result in quite a big gap between paragraphs.

@talldan Quoting myself from #7500:

The block controls would not take up space on hover (just like they and the block toolbar do not take up space now), and as far as I can tell it is not even decided yet if they would take up space on a selected block. And of course, the controls would only be shown for blocks that are either selected or being hovered over. The standard distance between blocks should be unaffected by the change; only the selected block may be affected.

This looks really good, I'm all for it.

One thing to consider in this which we've not before. What about long blocks? What happens to those and the bottom of the editor screen with blocks?

You mean when the block is so long it scrolls out of view? I'd say before that happens people will have seen how it works and know where to find it. We'd just have to test whether that gets annoying if you write a lot of long paragraphs on a tiny screen. But I like that it mirrors the mobile experience better. Which concerns do you have for the last block in a post?

How would they see if their first block was a really long block?

We should at least add a NUX tip about it ;) but what you're worried about is the case that someone opens an existing post that maybe is one long paragraph or hasn't converted to blocks correctly? It's possible... If they start a new post they almost certainly will see it on the first placeholder block, right?

Thinking about this, I don't see an exploration here of putting the controls at the top of the block, which could be an option. Did a quick mockup for that. (Combining the bars is also mentioned here)

If a block is too tall wouldn’t the bottom controls get stuck to the bottom of the screen, like how the top controls get stuck to the top or how it works in mobile?

@hedgefield I like that a lot but it doesn't work well in narrow contexts (like a columns block), or with long toolbars.

@hedgefield @chrisvanpatten Perhaps the arrow/ellipsis controls could move below (or above) the formatting controls in cases of thinner widths?

@karmatosed I would say the controls could be sticky and remain visible at the bottom of the screen. However, this causes this issue of the controls covering up the line you are trying to write in a Paragraph every time you start writing (presumably they would be hidden during typing like how it works now). But anyway that solution seems questionable.

Going back to the mockup by @hedgefield, however, that could allow the controls to be sticky just like the formatting tools without getting in the way. Of course, the toolbar would have to be responsive and the arrow movers and ellipsis should ideally move below/above/somewhere for thin blocks.

There is also the concern of accessibility. The mockup by @hedgefield has all the controls coming before the block visually. Ideally they should come after the block in the markup. Theoretically you could use CSS to allow the controls to come after the block in the markup but appear above it visually. However, I am not sure how difficult this is to implement in practice, and I do not know if an inconsistency between visual appearance and source order should happen. I personally do not mind it, as having all block controls appear after the block in the markup make finding the controls via the keyboard much more intuitive since you can tab forwards into them rather than having to go backwards.

and I do not know if an inconsistency between visual appearance and source order should happen is desirable

It's not desirable at a point there's a specific WCAG Success Criterion for that:
https://www.w3.org/TR/WCAG21/#focus-order

I would say the controls could be sticky and remain visible at the bottom of the screen. However, this causes this issue of the controls covering up the line you are trying to write in a Paragraph every time you start writing (presumably they would be hidden during typing like how it works now). But anyway that solution seems questionable.

Actually, thinking about it some more, the controls actually would not cover up the last line in a Paragraph unless the Paragraph was right next to the bottom of the screen, so #353 could make this a non-issue. And even without #353, you could still just scroll down (which is what most people do anyway), and as mentioned before, the controls would also only show when you moved your mouse. I have changed my mind. This could work!

What it would look like for wide blocks:

What it would look like for thin blocks:

Even thinner blocks (think 8 columns or something):

I think I am really starting to like this design. For wider blocks, I am not sure if the arrow mover controls should go to the left of the formatting controls or to the right, though.

Thanks for the explorations, however combining everything in one line is merging different actions into one place. I am unsure that makes sense. We also have the consideration of what happens when someone sticks a toolbar to the top - they are choosing to not have something 'in place' and now the controls are. That feels like a less than experience as we can't have block controls in the toolbar - that would be very odd to experience.

however combining everything in one line is merging different actions into one place.

To play devil's advocate, isn't that, by definition, the purpose of a toolbar?

To add further, while I can understand the idea behind separating certain controls, I'm not sure there's a compelling enough argument for it in this case. A toolbar is a toolbar; putting all the controls for a given block in one place makes logical sense, rather than coming up with fuzzy reasons why certain tools belong in certain places while other tools belong in other places that plugins will inevitably ignore anyway.

@karmatosed How about separating the controls via color?

@SuperGeniusZeb unfortunately that doesn't solve my other points no and I am not sure it does work.

I really think in this case it's a case of trying to fit a design that is thought to work over getting the one that will work. How about stepping back and considering the other points I raised?

@chrisvanpatten a toolbar isn't by definition a place to put everything, to be useful a toolbar has to have context and order. You have to as a user expect what is there to be the right options. Whilst we can debate what the meaning of a singular word is for a while - it's fun to do that - we can't loose sight of the fact this combines far too many things at once and would be a problem for more people.

@karmatosed Okay then. Let’s go back to having the editing toolbar on top:

(Not sure if that blue line above the bar should be there or not.)

Is there anything wrong with this design? The editing toolbar could be made to appear after the block in the source order for accessibility; it is not ideal, but since putting the editing toolbar below the block does not seem to be a viable option, it seems to be the only thing we can do.

Also, I just had an idea: what if the bar on the bottom was partially transparent on hover? Would that make it feel lighter?

@SuperGeniusZeb just to get views can I suggest we have less colourful mocks? I understand what is being suggested but letting the interface stand on it's own would be easier without the visual complexity.

Just to get a next step mock. @SuperGeniusZeb what does the above look like in context of a screen (normal desktop size) and a very long block? What does it also look like with a block right at the bottom? Ideally let's park for a little the transparency and consider my comment about focusing on the UI not colors this time, it should help us all gauge.

Some mockups:

With border at top of controls bar

Without border at top of controls bar

Notice that the toolbar does not take up any space on hover, but it does when the block is selected.

While making these mockups, I noticed something: what should be done in situations like this?

There is a conflict here between showing both the formatting toolbar of the selected block and the bottom controls of the hovered block. If the formatting toolbar was at the bottom (or if the block controls were all at the top), this would not be a problem, but here the combination of controls shown below and controls shown above blocks creates an issue.

The best solution I can think of would be to make the hovered block and its toolbar have a higher z-index and appear on top of the block below and its formatting toolbar. I am not sure this is the right approach, though. Here is a mockup of what this would look like:

And again, without the border between the bottom bar and the block content:

I do not really like the idea of the hovered block overlapping the selected one, but otherwise I see no way of using the bottom bars of hovered blocks directly above selected ones. Are you sure it would not be better to just have all the controls in a single bar on the top or bottom, at least on desktop? It would certainly prevent issues like this.

@SuperGeniusZeb I somehow had missed those mockups. Thanks for making them!

That's a really great point I hadn't thought about (hovering the block above the selected block). That's definitely a problem. As the resident page builder expert, are there any other similar patterns in other page builders, with layered toolbars like this?

Also, for what it's worth, I think the toolbars should always be hovered, selected or not. Having it _sometimes_ take up space will lead to jumpy content which is a more awkward experience overall.

@chrisvanpatten All the page builders that I have seen only have controls (except maybe a sibling inserter) shown at the top of a module/widget. Divi is one of the best examples, in my opinion:

https://supergeniuszeb.com/wp-content/uploads/2018/06/Divi-Visual-Builder-add-button-responsiveness-demonstration.webm

Not shown in the video, the formatting toolbar in Divi appears when you click the text in a module, and appears in a little pop-up above the line you are writing.

Elementor does nearly the same thing.

In Beaver Builder, clicking the text in a widget will cause the block controls toolbar to be replaced by the formatting toolbar until your mouse moves outside of the borders of the widget, which will cause the standard block controls to appear when you next hover the widget, though you can still type in the widget. Clicking the text again will make the formatting toolbar replace the standard toolbar again.

Also, for what it's worth, I think the toolbars should always be hovered, selected or not. Having it sometimes take up space will lead to jumpy content which is a more awkward experience overall.

True, but I worry about the implications this has for having a clean UI. If you have the formatting toolbar overlapping some of the above content, that is alright. But then if you add a full-width bar to the bottom of the block, now you are overlapping a lot of other content.

Ideally, you would want all controls to be on the top or bottom of the block. That would prevent toolbars overlapping each other in most cases. For the sake of accessibility, putting the controls on the bottom would be ideal. However, you may run into issues where the toolbars are overlapping the content you are writing in something like a Paragraph block. It should be noted, however, that only the formatting toolbar is really needed to be visible at all times, since the arrow movers and ellipsis are not something that would be used nearly as often. Also, if the currently-being-edited part of content of a block is kept far enough away from the bottom of the screen, then the formatting toolbar will not have to overlap it.

If putting the controls on the bottom feels too awkward, then it seems like the next best option is to put them all on the top. Of course, there is the potential issue of the controls looking awkward for thin blocks.

In cases of desktop versus mobile, you can usually get away with shifting the position of toolbars. Right now the formatting toolbar and other controls are all shown below the currently selected block and take up space on mobile.

In cases of wide blocks versus thin blocks, however, moving controls around for the thinner blocks may feel awkward. The most consistent look may be to have the formatting toolbar on the top and the other controls on the bottom. But that brings us back to the issue of overlapping toolbars and the increased amount of content overlap.

Gutenberg is designed around the idea that the appearance of the selected block is optimized for editing, so I think having toolbars take up physical space is not so bad, as long as you make selecting the block only move stuff around the block, and not move the selected block itself.

In the end, I feel like these mockups are still a pretty good option. It is not perfect, but it makes sense from an accessibility perspective, it does not look too awkward, it is consistent with mobile, and it should rarely result in overlapping toolbars.

Some notes about how this would work:

The controls take up no space on hover, but do take up space when the block is selected. When hovering a block, only the arrow movers and ellipsis is shown, but selecting the block makes the formatting toolbar appear, which pushes the other controls downward. This is probably the biggest issue with this design. I think to make this work best, you would want the content of the block pushed upward when selecting a block by clicking the movers/ellipsis toolbar, but you would want the toolbars to move if you selected the block by clicking the content area.

When a block stretches below the content area, the arrow movers and ellipsis will be off-screen, but the formatting toolbar will stay visible, being sticky to the bottom of the screen (or content editor area).

If this is not the best solution, then I would go for basically the same thing, but with the controls all on top, with the movers/ellipsis appearing above the formatting toolbar for thin blocks, and perhaps to the left of the formatting controls for wide blocks. Mobile could still look like it does now.

Another thought: you could get rid of both the shifting controls issue and the toolbars overlapping each other issue if you simply did not show any controls on hover. That would make showing toolbars on both the top and bottom of blocks much less of an issue. But of course, you lose the benefits of having controls shown on hover. I am not really sure whether that is the direction that anyone wants to go, but I am starting to wonder if it is necessary.

I have to say the idea of the hovered block overlapping isn't one I like either. This needs some more thought I think. The idea of controls taking up different space potentially on hover feels a little awkward.

The controls take up no space on hover, but do take up space when the block is selected. When hovering a block, only the arrow movers and ellipsis is shown, but selecting the block makes the formatting toolbar appear, which pushes the other controls downward. This is probably the biggest issue with this design.

I think this is a big issue with the mocks. What else could happen?

Whilst looking at page builders is one aspect, what about other apps and products? Is this solved somewhere else?

@karmatosed

Whilst looking at page builders is one aspect, what about other apps and products? Is this solved somewhere else?

Trying to find analogous examples of UI that Gutenberg could use is difficult, because almost nothing has to account for all the things Gutenberg does.

A lot of simpler/older page builder plugins do not have to worry about covering up the content of their equivalent of a block, because all content editing is done in a modal or sidebar. This frees them up to allow their module controls to overlap the content.

Even in cases like Divi or Beaver Builder, where you can edit the text without opening a modal/sidebar, the modal/sidebar is still the primary way of editing. Divi and Beaver Builder both show what is essentially a perfect replica of the front-end, without having to worry about having to optimize for things like using them as a text editor or ensuring that the majority of the major block content can be edited inline at the block.

Additionally, both in page builders and other builder-ish UIs, nesting tends to be far less of a problem due to restrictions on what can be nested. Divi has a strict Section→Row (with columns built-in)→Module setup (albeit with some Specialty Sections devised for some common nested column situtations). Beaver Builder only allows columns to be nested in columns, as does Elementor. They control the only kind of object that can have multiple layers of nesting. Everything is in a Section with a single row by default. There is no unlimited layers of nested blocks with potential for any combination of custom blocks that use nesting for various purposes and various styles like what Gutenberg allows.

Divi can color code its controls for sections, rows, and modules because it has a strict structure and there can be no custom module that acts a section or row. (This also allows it to show multiple inserter buttons on the same line, but with different colors to distinguish what each will do.) In the majority of builders, modules are separate from layout elements. Beaver Builder can do similar things because of the separation of modules and layout elements.

If you look at things that are not page builders, like text editors, you can see that those do not have to worry about all the things that page builders have to deal with. If you look at most page builders, they do not handle text editor stuff through direct inline WYSIWYG controls.

What Gutenberg is trying to do is unique. It is trying to be a WYSIWYG-except-for-the-selected-block-which-is-optimized-for-editing page builder that is also a full textual editor, and everything from sections to columns to widgets are all the same kind of object: blocks.

Basically, this is a complicated issue because Gutenberg is trying to do several different things at the same time that seemingly nothing else tries to do. :stuck_out_tongue:

Anyway, here is a list of things that could be looked at to see how they handle block/module/widget UI:

WordPress plugins/themes

• Avada (Fusion Builder)
• BeTheme (Muffin Builder)
• Beaver Builder
• Divi (Divi Builder)
• Elementor
• Oxygen
• SiteOrigin Page Builder
• Thrive Architect
• Visual Composer
• X & Pro by Themeco

Website builders outside of WordPress

• Drupal
• Squarespace
• Weebly
• Wix

Things that are not page builders but are kind of similar to one

• MailChimp
• Notion

Those are all I know of right now.

There is a problem with the sibling inserter: it always overlaps the content of the selected block. This problem gets even worse when you try to get rid of things like the automatic margins on each block to make Gutenberg more WYSIWYG.

The solution? Well, if we are going to add a bar to the bottom of blocks, why not just throw the sibling inserter into that bar as well?

Also, I just came up with a way to make the border on the hovered variant look a bit less jarring. Just change the color of border that divides the block content from the bottom bar!

Benefits include:

• Sibling inserter never overlaps the content of the selected block. This means there should now be no UI that ever overlaps the content of the selected block except for the sticky formatting toolbar, which does not cover the content if you just scroll upwards or are just typing and not moving the mouse.
• Sibling inserter now appears in the same order as the HTML tab order, which is good for accessibility.
• Sibling inserter now appears below blocks instead of above. This makes more sense, in my opinion.
• Sibling inserter is always visible for the selected block (except maybe when typing if the controls are still made invisible like they are now)
• Consistency with mobile UI.
• All margins and inner padding of blocks could be removed, and the block borders could be changed back to being the actual size of the block, all without the block UI getting in the way of the content of the block.

Bonus points if the sibling inserter is changed to open the inserter menu directly (as discussed in #7271) rather than inserting an empty Paragraph block.

Of course, the question of what happens when you hover the block above the selected one is still an issue. However, I do not think this really bothers me that much. All you have to do is click the block to select it and see the controls, and if the hover controls are shown below the currently selected block, that is alright since the selected block is supposed to be the focus.

I think this is a good design to move forward with. I think all the positives outweigh the negatives, and I think it is definitely better than what exists right now. What do you folks think?

I mocked up how this looks if both top and bottom toolbars overlap, and how it would look if the hovered block always takes the highest z-index over a selected block.

I like this a lot, but it has one small problem… single line blocks are out of luck, because they'll be almost completely hidden underneath the bottom control bar.

@chrisvanpatten I was thinking that the bottom bar would actually take up space when the block is selected. I think that would fix the single-line block issue. Could you make a mockup to show what that look like? Also, what is it like if the hovered block does not overlap the selected block?

Also, perhaps there should be a shadow below the bottom bar when it overlaps something.

@SuperGeniusZeb I really strongly oppose having the bottom bar take up space — that leads to jumping UI. Reusable blocks do that now when you select them and it drives me nuts.

(EDIT: To elaborate, it makes things really tough for mouse users because you can't really rely on things being in the same spot from one moment to another. It causes a lot of awkwardness.)

@chrisvanpatten

I am mainly thinking that in the context of writing posts, you probably would not want to cover up the paragraph below the one you are typing in. Right now it looks like the Paragraph block below the selected one is missing its first line. I think I would prefer the surrounding blocks jumping a little when you select one to not being able to see the top of the block after the one I am currently editing. Personally, the jumping around does not bother me much.

It is fairly common in Gutenberg for something to change size when you select it: Image caption placeholders, Quote citation placeholders, the placeholder/inserter in the Gallery, and the Reusable blocks, as you mentioned. Gutenberg is generally designed around the idea that the appearance of a block should be optimized for editing when it is selected. I would say that makes it okay to make the block height get taller due to the bottom bar taking up space.

Alternatively, perhaps the bottom bar could be made semi-transparent to make it a bit more clear that there is a block below it? How does that sound? I think I could be okay with that.

The only problem is that transparency is not used anywhere else in the Gutenberg UI. That is not to say that it should not be used... just that there are no existing examples of it, so we could be introducing a UI design inconsistency.

There is also the idea of getting rid of the empty space between the controls on the left and right, but that was shot down earlier in the ticket due to making the UI look too "blocky".

@chrisvanpatten All that said, I think I would still prefer your mockup over what exists right now. The first-line-of-following-block-appears-to-vanish issue is minor compared to all the things that either of our mockups would fix.

@SuperGeniusZeb I think what makes it particularly awkward in this case is that the controls are there when you hover. With all the other examples of jumping controls, at least they aren't there when you hover, they're only there on select.

I don't think this is worth abandoning because of the hover/select/jump/single-line paragraph issues, but definitely needs a little more thinking.

I'm still confident there's a solution in here somewhere… just have to keep iterating!

@chrisvanpatten

I think what makes it particularly awkward in this case is that the controls are there when you hover. With all the other examples of jumping controls, at least they aren't there when you hover, they're only there on select.

Well... you _could_ not have any controls shown on hover, but I think it is safe to assume that nobody really wants that. I know I certainly like the controls that are available on hover.

Anyway, how about transparency?

And if you want to dream a bit and wish that backdrop-filter was implemented in all major browsers, you could add some blur:

This is 60% opacity, by the way.

Opacity definitely helps, but I am unsure about introducing opacity into the equation. It feels a bit like cheating.

@chrisvanpatten Indeed, it does feel a bit like cheating... but what other options do we have?

We can't put the controls on the side, hence this issue existing in the first place.

We can't put the controls within the block, because that would cover up the content.

We can't put the controls on top because of the formatting bar already being there and the issues that would be caused for thin blocks.

Putting the controls on the bottom makes the most sense since it works better for accessibility, provides a convenient spot to throw in both the sibling inserter and drag handle and solve issues related to those, is more consistent with mobile, and works the best for thin blocks.

To reduce the space taken up by the bottom bar, there are really only a few things we could do:

• Decrease the height of the bar.
• Remove the empty space between the inserter/movers/drag handle and the ellipsis.
• Push the ellipsis to the left and remove the extra space on the right.
• Make it take up space when selected. (But you don't want this.)

Other than that, all that can be done is making it semi-transparent to make it visually feel lighter and make it easier to see what is below it.

Another thought: maybe the transparency thing would not feel like cheating if _both_ toolbars were transparent rather than just the bottom one.

Made some more mockups to try some of the things mentioned above.

Transparent toolbars:

No transparency:

I think I actually prefer it without transparency. What do you think? I think shrinking the width of the bottom bar has solved the overlapping-start-of-next-block issue. Of course, it will still happen at smaller widths... but that already happens with the formatting toolbar anyway, so I do not think it is really a problem here.

Also notice that I left a little space for a drag handle. It could have little greyed out dots that are often used in apps to represent drag handles, or it could have a drag icon shown on hover or all the time. Or it could just remain blank. It could also technically be a bit thinner, but I left it the width of a button for comfort.

Could this be it? Could this be the iteration good enough to replace the current one? _(Please say "yes". :stuck_out_tongue:)_

Thanks everyone for all the explorations made here. Jumping in just to add one more reason semi-transparency is not ideal: the icons contrast ratio with the background must be 4.5:1. Using semi-transparency would make that impossible, just think of an image with prevalent dark colors, or a paragraph with a dark background, or a theme with a dark background:

Thanks all for the excellent discussion here. It's heartening and delightful to see the passion with which this challenge is tackled.

I've been watching a bit from afar, having designed the initial configuration of the block — with a docked toolbar, the up/down arrows on the side, and eventually the ellipsis on the right. I added the ingredients so because I felt it was very useful to give the movers prime real estate as an alternative to drag and drop which is often fiddly and prone to error, whereas the movers are always predictable in their behavior.

I completely recognize the challenges this poses for nested blocks, and I've thought for a long time what the best solution was. What's in master — overlaying left and right even if nested — works, but isn't great either, I acknowledge that. Another option is to use the mobile UI — show the UI below the block when selected, which is sort of mocked up in various variants here, works, especially for mobile. But on desktop it can become very disruptive and jumpy when you just want to select a paragraph to make a small edit and everything jumps around. Similarly if the toolbar gets overlaid as in the latest version, it feels like it's leaning too far away from the writing experience, into the layout experience. This is the constant balance we've tried to achieve.

A second option is to go back to waaaay way old mockups I had, this one:

Perhaps with a few tweaks, it could be this:

But I don't love that. And _either_ this would make the movers visible only when the block is hovered, or we'd want to tweak the treatment a bit. It also makes the button hit areas several pixels smaller, which is not great for usability.

As such, those variants have not been considered so far because they did not feel superior to what we had. However posting here regardless in case they can inspire treatments to make it work.

The biggest issue I see with having combining the block tools with the hover label is that it creates an inconsistency between a selected and a hovered block, unless you want to start showing the label for selected blocks as well. And if you do that, then the label should not be within the block borders, but rather outside of it.

But even if you do that, you just run into the issues of having too many controls at the top of the block and having to figure out how to make that be consistent for both wide and thin blocks.

I firmly think that, with the exception of sticky toolbars that stay on-screen, none of the standard selected block UI should cover up any part of that block.

Having the block tools at the bottom provides a good spot to put the sibling inserter, which both helps attain the above no-overlap goal, while also making the sibling inserter more visible and solves its own overlapping issues. (I think the nested blocks update to the Quote block has not happened yet due to overlapping sibling inserters.)

Because of the sibling inserter and accessibility benefits, I think that being below the block is the best possible place to put the block tools.

Now, I did not think that making the controls much smaller was on the table, since making them smaller may make them harder to use, of course. However, since you don't seem to be against it, then why not try it?

How is this?

The buttons in the bottom bar (but not the icons) have been reduced in size from 38px to 32px, and I fixed an inconsistency in the spacing between the mover controls from the previous mockups. Note that you could make it a little smaller horizontally if the ellipsis button was thinner than the others (like the one in the top bar of the editor).

You could also decrease the size of the empty drag handle area to make the bar take up even less space. This would be even more viable if all the controls in the bar doubled as drag handles, like how the top bars of windows in GNOME work.

Note that on mobile, the controls would probably look almost exactly like they do in master, where the bars take up space and so making them larger is not an issue. This size reduction should only affects desktop users, and the controls are still usable by touch at this size.

I also did a small exploration with moving the controls into a top toolbar, which solves one set of problems… but when you select the block, you're back to having an Everything Toolbar that doesn't work in narrow contexts, which was a significant reason for this exploration in the first place.

I'm still trying to figure out how I feel about those last mockups. The controls hanging off the bottom feels kind of awkward to me. I'm not sure I have a better idea, it's just that it gets us back to that sort of blocky/fragmented feel that @karmatosed wanted to avoid.

Thanks everyone for all the work here. I am going to try and give some feedback but I have to say right now I don't feel this is ready to move into prototype. I still think there are problems with nesting and also different devices to solve but as I mentioned in previous comments I don't think the current track is right. I feel we are also yes heading back to the territory I already suggested we avoid in this.

I don't want to discourage exploring but right now I would suggest considering thinking of alternative suggestions. On big problem is that adding half tabs to the bottom is increasing visual density without gain. Let's think about what we are trying to solve here:

• What happens on different devices.
• Sibling inserting (although this could be fixed in other issues) or at least how it interacts.
• Nesting visibility and interacting ease.

The primary drive in all of this was how it responded and nesting.

Let's consider in what we create if we are increasing or decreasing usability. For example, using things like transparencies and layers whilst are ok for someone with normal vision, they don't for a whole lot of other people make it better. Think of complex layouts, ones with videos and lots of images. In this dense information structure what is being suggested doesn't hold up.

Think of complex layouts, ones with videos and lots of images. In this dense information structure what is being suggested doesn't hold up.

Yeah, I think this is the biggest point, and I'd add that density really _compounds_ in smaller spaces which is another part of the challenge. Nested blocks generally need all the same controls that non-nested blocks need, but they need to do it with a fraction of the space, and ideally in a non-unique way (e.g. nested blocks should generally resemble non-nested blocks; consistency begets usability).

Back to the drawing board… 🙂

Why I think my mockup is better than the current UI

I understand the desire to avoid a blocky look, but I have yet to find anything that is not blocky-looking, yet still just as functional. The problem is that you need to know the edges of the block you are working in, and you want the controls to both not cover up the content in the block, as well as cover up as little outside of the block. That pretty much guarantees a somewhat blocky look.

Just looking at the screenshot at the top of this issue, you can see how Gutenberg at one point had a very un-blocky block UI. But the problem with that UI was that it was hard to tell where the edges of a block were. That's why we have the UI we have now.

And when you throw in the issues with the sibling inserter, you realize that you need to make the sibling inserter button be outside of the content border of the block. Combine that with the point that you usually want to insert blocks after the current one (rather than before) and also the desire for increased accessibility, and you wind up having to have something like my latest mockup.

Personally, I would prefer this blocky UI over something that looks like the first mockups. Those first mockups look confusing due to the lack of border between content and controls, and the bars eat up a lot of unnecessary space. Since we don't want jumping UI, the bottom bar has to be an overlay over the content outside of the selected block, and so it should be as small as possible.

Additionally, I think my mockup is definitely better in nested contexts than the current one. As I will explain below, the overlapping toolbars/content situations are better with this UI than the previous one. And in nested contexts, you need to know the borders of a block even more, so a somewhat blocky look actually helps in this situation.

Overlapping toolbars are way less confusing and less likely to be a problem, since blocks are way less likely to be vertically small on small screens, compared to the likelihood of them being horizontally small on small screens, which caused issues with things like the Columns block. When a text block gets thinner, its text wraps and it becomes taller.

In nested contexts, hovering over the block above the current one will almost never cover up all the content of the block below, because either the block will be wide enough for the bottom bar to not cover it all, or else the block would be fairly tall and so it would still have room to select it.

Additionally, the bottom bar of a block should only appear when you hover the block, and not just when your mouse is near it. Due to the weird, invisible drag handles on the sides of blocks, that is not the case with the current UI.

To add on to the point above, it is only the block above the current one that can cover up anything in the selected block. The other 3 sides are completely fine, since hovering a horizontally adjacent block will cover up nothing in the current block, and hovered blocks do not have UI above them, so hovering the block below the selected one is fine as well.

Additionally, you could simply choose to not make hovered blocks never cover up the currently selected one, and that would result in literally zero overlapping issues with the selected block in nested contexts. Since hovered blocks only have a bar on the bottom, the one below the current one would never overlap the selected one. The only thing you give up in this situation is the ability to access the block tools for the block above the current one unless you select it.

Yet another idea: the bottom bar could be automatically hidden when you cursor hovers another block. It would not come back until you cursor moved into the borders of the block again. This could help even more in nested contexts.

On top of all of that, if you still want even less overlap issues in nested contexts, you can dock the formatting toolbar to the top bar of the editor. (This has no effect on mobile, but on mobile the bars take up space and overlap nothing, so there are no overlap issues in the first place.)

Overall, I think there are more situations improved by my latest mockup than situations that are made worse.

As it is, I think something like my mockup (or close to it) solves way more issues than it creates. In addition to the above, benefits include:

• Works for all block widths.
• Better accessibility for sibling inserter, movement controls, and ellipsis.
• Better visibility and discoverability for sibling inserter and drag handle.
• The drag areas on the side of the block can be removed, and the hover label does not have to become a drag handle (it is kind of small anyway).
• Sibling inserter is below blocks, which is where you usually want to use it (as opposed to above).
• No need for separate sibling inserter UI, reducing complexity.
• Sibling inserter no longer has overlap issues in nested contexts. (I think that is the reason #6520 has not happened yet.)
• The block UI surrounding a block never overlaps the content of that block.
• The automatic margins of blocks could be removed, and a block could have no inner padding whatsoever, and the block UI borders could be changed back to the actual content borders, and yet nothing in the content of the block would be overlapped by any controls. These kind of edge cases will happen with custom blocks, so it is good to account for them.
• All the block tools are fairly close together, making it easier to reach them all and discover them all, compared to the previous situation of the ellipsis and arrow movers being on opposite sides of the block.
• It is very clear what block the controls are attached to, compared to the confusion you often get with the current controls in nested contexts.
• The controls are more consistent with mobile.

So yeah, I think my mockup actually works better in nested contexts, and I think the blocky UI is hardly important compared to what you gain. What do you think? If you disagree, could you point out situations where the mockup would be significantly worse than the current UI and none of the previously mentioned suggestions would solve it?

There is... another... ~Skywalker~ idea

If all else fails, I do have one idea that would technically fix all the major issues. What if the formatting toolbar was always docked to the top like it was back in Gutenberg 1.6, but this time the movement controls and ellipsis would be shown above blocks instead of to the sides? (You could alternatively still have them on the bottom like my mockup.)

In this concept, the sibling inserter would not exist, because the inserter in the top bar of the editor would serve the same function, and in this context it would be closer in reach since the formatting toolbar would be in the same area.

The mobile UI would be exactly the same as it is right now. This change would only affect desktop (and maybe tablet) users.

But wait, there's more!

Actually, if you think about it, what's the difference between this idea and just having my mockup and enabling Fix Toolbar to Top? The only thing you gain by removing inline formatting toolbars entirely from mobile is the ability to have the movement controls and ellipsis shown above the blocks instead of below. And technically, that could just be part of the Fix Toolbar to Top option.

Compare to the current UI where Fix Toolbar to Top does not get rid of all the overlapping control issues since the side UI is still split between two sides and the confusing invisible drag handles are still there, and the sibling inserters still overlap in nested contexts, and etc.

Is it definitely set in stone for the future that each paragraph of text is a separate block? If so, the display of block tools would have to take into account multiple text-block selection (which I believe is coming at some stage).

@padraigobeirn That's a good point that I had forgotten about.

Notably, the controls in the current UI do not account for long selections. The movement controls and ellipsis stay at the top left and right of the first block in the selection. Even the formatting toolbar is only sticky for the first block in the selection. See #7962.

For the bottom bar in my mockups, you could theoretically make it work with multiple selections by having it stay sticky to the bottom of the screen when you scroll up. This sticky behavior may only be desirable for the selected block(s), however.

You know, I am really starting to think that Fix Toolbar to Top should be on by default.

As it is, there is really only so much you can do to fit so many controls around a block, and even with my latest mockups, there are still cases where the UI could feel crowded. There is also the concern about the UI feeling too blocky.

To resolve these issues, I think docking the formatting toolbar to the top should be the default. It saves space around a lot of the block, and drastically reduces the amount of possible controls overlap.

I think I still prefer the movement controls and ellipsis to be on the bottom, but they could also be moved to the top when the formatting toolbar is docked. Not having the formatting toolbar attached to the block would allow the block tools bar to be put in the bottom right or the top right as well, without looking awkward or eating up too much space.

I think I would prefer either bottom left or bottom right, though. That way, the controls come after the block both visually and in tab order, which makes the most sense to me. Throwing in the sibling inserter there after a block makes more sense than having it appear before a block.

Side note: I recently noticed that the email builder in Infusionsoft actually has its own "block" concept, and it has block tools (duplicate and delete) shown above blocks on the top right. The formatting controls appear in a bar at the top of the editor when your cursor enters a text area.

I recently noticed that the email builder in Infusionsoft actually has its own "block" concept, and it has block tools (duplicate and delete) shown above blocks on the top right. The formatting controls appear in a bar at the top of the editor when your cursor enters a text area.

Could you clip some screenshots of that interface @SuperGeniusZeb?

When I first started using Gutenberg I was definitely a "fix toolbar to top" person, but having used it for a while I'm not sure I'd want to go back. I totally recognise that the toolbar in many ways is the cause of all these problems — it's the most likely to have a lot of stuff that gets cut off in nested contexts, and takes up space you could use for the side controls — but having it paired with the block is just sooo nice. It keeps everything you need in one place, avoids a lot of eye motion and mouse movement, etc. I am surprised to say it now but I think that's something I wouldn't be able to live without.

Could you clip some screenshots of that interface @SuperGeniusZeb?

@chrisvanpatten No, I only had temporary access to it while helping someone.

I don't really feel strongly either way on fixed/not-fixed formatting toolbars, but I would lean towards fixed since it would help reduce visual clutter around blocks. Based off of user feedback, what do other people prefer and why?

@chrisvanpatten Found an article where someone talks about the email builder in Infusionsoft and has a video of it:

https://www.monkeypodmarketing.com/the-new-email-builder/

@chrisvanpatten Argh, I just checked and it looks like that video is out-of-date... it looks like back then the formatting toolbar was attached to blocks, like what Gutenberg does right now. Interesting that they changed it, though.

Some thoughts:

If you are going to insert a block in the middle of a post, you usually want to do it _after_ the one you have selected, right? You do not usually want to insert _before_ the selected block. Inserting after a block also makes sense from an accessibility perspective. Does anyone disagree with this? To me, this seems like a strong argument in favor of having sibling inserters appear somewhere near the bottom of a block.

Sibling inserters should not overlap the content of the selected block. Nothing should permanently overlap the content of the selected block. Does anyone disagree with this? This leads me to believe that sibling inserters should be positioned outside of the content of the selected block.

I point this out because I think that regardless of where the movement controls and ellipsis should go, the sibling inserter seems to have to appear in a sort of toolbar below the selected block, even if it is all by itself and/or the toolbar has no border/background. I guess it could look almost exactly like it does now, but shifted downwards and changed to appear below blocks, rather than above them.

Another thought: would it be an improvement over master to put the ellipsis on the same side as the movement arrows or vice-versa? That could solve a lot of the issues with overlapping controls in nested contexts, at the cost of having a taller amount of block UI on the left (or right) side of a block.

I just tried out #8836. I think that if it was merged, it could help reduce the heavy/blocky UI issues that a lot of the UI designs in this ticket seem to have.

In the tickets #9074 and #9075, I'm suggesting two baby-steps, inspired by this discussion, to mitigate and improve the situation. In the first one the suggestion is we move the Ellipsis/More button to the toolbar, so we only have one piece of side-UI (movers), and in the other there's a proposal to let the block toolbar collapse setions to better fit in thin contexts.

Just for the sake of keeping them up-to-date, I updated my mockups to account for the changes proposed by @jasmussen's tickets and the recent UI changes in 3.6:

Actually, moving the arrow movers below blocks may not even be necessary anymore if #9074 and #9075 are implemented. It might be just fine if they stay on the side of the block, since the ellipsis of adjacent blocks would no longer overlap them in things like columns. If solutions for #8880, #8881, and #8883 happened, and if #8836 and #8920 were implemented, then perhaps the UI would already be just fine for nested contexts. I am starting to lean towards it being okay for the up/down arrows to stay on the left side of the block.

That said, I still think the sibling inserter definitely belongs below blocks, though you could definitely just have the sibling inserter appear alone below blocks. Perhaps it could be centered like the current sibling inserter, but act and look like the up/down movement controls, appearing as a floating button below blocks when you are hovering inside the lower portion of a block.

Let's focus on getting the iterations in @jasmussen is working on in #9074 and #9075, then we can consider next steps. I totally get wanting to change a lot of things but let's balance.

Thanks to the aforementioned #9074 and #9075, as well as other issues and PRs like #8920 and #9197, I have decided that moving the arrow movers below the block no longer has many benefits.

Instead, I am now proposing that just the sibling inserter be moved below the block, acting and appearing as a floating control similar to the up/down movers. See #9202.

Let's close this one for now as many improvements have surfaced out of this and other discussions. The last few refinements to make are around the trailing inserter.