People are complaining about the block toolbar showing up constantly and disturbing their writing flow, this PR explores the possibility to use a fixed a block toolbar at the top. And its content change depending on the selected block.

Not done yet:

• The freeform block shows the toolbar differently, we need to tackle it separately
• Hide this toolbar when the blocks are deselected or when a block doesn't have any control (or maybe show the permalink like shown when focusing the post title)
• Use this same toolbar for the multiselection toolbar

Codecov Report

Merging #2148 into master will decrease coverage by <.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #2148      +/-   ##
==========================================
- Coverage   26.54%   26.53%   -0.01%     
==========================================
  Files         157      157              
  Lines        4853     4854       +1     
  Branches      818      818              
==========================================
  Hits         1288     1288              
- Misses       3012     3013       +1     
  Partials      553      553

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3947282...2eb3988. Read the comment docs.

Hah, nice, interestingly I just explored something similar with the toolbar in #2151.

I like this more than I thought I would. I'd like to chew on it for a bit, and perhaps also run it by @afercia. But my gut reaction is positive. CC: @melchoyce @karmatosed

Edit: we'd probably want some centering going on.

Hah, nice, interestingly I just explored something similar with the toolbar in #2151.

I was going to say the same in your PR :)

This also has the advantage of reducing the mental-shift when switching from the existing editor (toolbar still at the top)

The primary disadvantage, potentially, could be that some of the context is lost a little bit. This could definitely affect the tie-in to customization, so pinging @melchoyce and @westonruter here. Also @mtias.

The primary disadvantage, potentially, could be that some of the context is lost a little bit. This could definitely affect the tie-in to customization,

Under the hood, this toolbar can be placed wherever we want in a different editor. For example, the customization could decide to include it above the blocks, or in a sidebar...

I don't dislike this (my original concepts when we were starting had a similar concept but at the bottom). But I think it's trying to address a problem that is not of visual design, but of interaction patterns. The UI should not show when you are in "writing" mode, thus not obscuring anything. The problem is how we define "writing" mode.

It sounds like Helen got to a situation where hitting "enter" was showing the UI. That is a bug and we should fix it. Hitting "enter" when you are writing should never show UI.

The other problem is with mousemoves. Perhaps we should disable the functionality that shows the UI when moving the mouse, or make sure that you hover the toolbar area, or add a delay.

I think we should focus on these very evident interaction shortcomings and fix them before making any call regarding the visual design.

I dont like it.
Just slight page scroll and User will not know where is his/her ass, and what they are editing.

All editors similar to Gutenberg show toolbar where it is now. Do not overcomplicate it.
But, if it solves for you all hardness of coding for mobile and smaller devices, lack of space, go for it, why not.

I'd tend to agree with @mtias. Maybe worth considering to better define what "writing mode" is. I'd also consider a shortcut to make the toolbar appear and receive focus on demand, see #552.

The big problem I see with a fixed toolbar is keyboard interaction. Where the toolbar is placed exactly in the source order? How I move focus to the toolbar using only the keyboard?

I have for a while had a lot of issues with the current toolbar because of a simple app I use called PopClip (it has a lot of things that help me interact with content, accessibility things and also just things that make life easier), this is the experience I get:

Now I don't suggest we design for my not so common case, but it has always meant the toolbar was a bit of a bothersome issue for me.

Flipping the thought process, I also prefer design wise having as much as possible context to actions. I can see that being lost the further things get from the content.

One thing I really like that I think covers best of both worlds is a 'shadowing toolbars'. These appear where you need, when you need. A basic level of this is one that follows you around at the top, away from the blocks. A more complex is similar to what @mtias is saying where it appears just when needed.

A little caution here though as to a lot of people saying what a user will or won't do, without drawing on our examples we have in tests and feedback. Maybe we can focus on the input we have right now and a solution which solves this. If we don't have enough, lets run some tests. We could also usability test some different options, we have that option.

If we don't have enough, lets run some tests. We could also usability test some different options, we have that option.

I'd love to see some user testing sessions include also at least: 1 keyboard user, 1 screen reader user, 1 speech recognition software user 🙂

@afercia as would I. Can you help us recruit them?

Worth noting Ghost use this approach but with a toolbar at the bottom.

Another small advantage I'm finding here is the simplicity of the technical solution. Our actual solution is not that simple, it requires us to know if the mouse is moving, if we're typing, if we stopped typing... while this is way simpler, we only need to know the selected block.

Experience shows that often the simplest solutions are the best ones.

@youknowriad not sure I agree, because I'd still like the UI to not be visible when I'm typing even if it's fixed top/bottom.

Can you help us recruit them?

@karmatosed will ask around :)

Worth noting Ghost use this approach but with a toolbar at the bottom.

@youknowriad I'd like to move a lot of things at the bottom 🙂 #467

I imagine the inspector will end up being a lot more important than floating toolbars when it comes to customization and layout, with the exception of page/post content (which we might explore making editable via Gutenberg at first anyway). I do find the current implementation a little clunky, so I think @mtias's suggestions are all thing we should try, for sure.

However, I also wouldn't object to us trying out a docked toolbar, maybe more like this with it fixed and centered with the content, either on the top or the bottom:

(Though I do worry it could get lost on the bottom)

User test results #2259

@afercia as would I. Can you help us recruit them?

@karmatosed @rianrietveld is going to ping you about this, she has some volunteers :)

What about this PR? Should we close it?

I really think we should go this road (whether show a fixed toolbar at the top or the bottom, but without centring it IMO) but this is probably not a priority right now and we could revisit later.

I think we should keep it open! I still like it. I don't yet know if it's a perfect fit for us. Even if we need to re-do the PR down the road if we decide to do it (because of rebases), I think it's worth having this open, as it communicates yes, we are considering this. Which we are ;)

Another argument for this is that we could decide to always hide the block surroundings (borders, arrows, delete, and cog buttons) unless the block is hovered.

There's also good feedback in this analysis: https://go.tinymce.com/blog/gutenberg-editor-success-lies-timing/ — which would be partially addressed by a docked toolbar.

CC: @annaephox

I pushed this exploration a bit further hiding the surroundings unless we hover a block.

I'm still digging this, even though I also think the current toolbar can work for us. In other words, if popular opinion and tests suggest this is it, then I'm all onboard.

I do think, though, that we'll probably want to always show the toolbar, even if nothing is selected. We'll want to think about what to show there instead — a tip? Seems like we should be able to solve this in a clean way.

Alternately, we'd want to test whether it was sensible that the toolbar expands like to does — we might even want to add a little animation so it very quickly appears on click (like .1s appear animation).

Finally, I think we'd want to center the toolbar items in the box. Like provide a 700px maxwidth to a centered container.

Nice work!