Display block tools underneath the block, instead of to the sides

[melchoyce]

I think we should consider showing the block tools underneath the block, instead of to the sides of the block.

Before

After

Why

• As we start moving into the Customization focus, we'll inevitably take up more horizontal room within the Editor. Displaying the tools underneath the block provides more room for full-width elements.
• We've already started to see this in nested blocks, but columns of blocks intersect in tight and uncomfortable ways. Putting the tools underneath the block frees up room and helps fix the issue of overlapping blocks.
• We don't have a lot of horizontal space on mobile. Putting the tools beneath the block means it'll work better on small screens, where there's vertical space.

cc @karmatosed @jasmussen

[karmatosed]

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.

[jasmussen]

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 #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 #5452 (comment), 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!

[melchoyce]

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!

👍 👍

[ZebulanStanphill]

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.

[afercia]

+1 Just to note that this could also help to improve the tab order of the UI controls around the blocks. As mentioned in #5694 (comment) 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 #5694 (comment)

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

[chrisvanpatten]

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

[afercia]

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:

[karmatosed]

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?

[melchoyce]

Yeah, I can take another look.

[samikeijonen]

+10 for trying this out.

[ZebulanStanphill]

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.

[ZebulanStanphill]

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.

[ZebulanStanphill]

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.)

[karmatosed]

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.

[chrisvanpatten]

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:

• Child block side UI doesn't reposition in align-wide/full #7646 → with controls being positioned above/below, you don't have to worry about accommodating side UI
• Consider tweaking nested block side action styles #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
• Editor pop-up editing symbols need to be theme BG color neutral #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
• Drag & Drop: Change to use hover label as the draggable handle #7114/Allow dragging block from hover title #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.

[karmatosed]

@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.

[afercia]

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:

[karmatosed]

@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.

[chrisvanpatten]

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

[ZebulanStanphill]

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.

[chrisvanpatten]

@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.

[ZebulanStanphill]

@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:

[karmatosed]

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.

[chrisvanpatten]

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… 🙂

[ZebulanStanphill]

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 Use nested blocks for quotes #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.

[padraigobeirn]

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).

[ZebulanStanphill]

@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.

[ZebulanStanphill]

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.

[chrisvanpatten]

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.

[ZebulanStanphill]

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?

[ZebulanStanphill]

@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/

[ZebulanStanphill]

@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.

[ZebulanStanphill]

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.

[ZebulanStanphill]

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.

[jasmussen]

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.

[ZebulanStanphill]

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.

[karmatosed]

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.

[ZebulanStanphill]

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.

[mtias]

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.