Editor: Try a fixed block toolbar

[youknowriad]

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]

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

Impacted Files	Coverage Δ
blocks/block-controls/index.js	0% <ø> (ø)	⬆️
blocks/editable/index.js	10.87% <ø> (ø)	⬆️
editor/post-title/index.js	0% <0%> (ø)	⬆️
editor/modes/visual-editor/block.js	0% <0%> (ø)	⬆️
editor/modes/visual-editor/index.js	0% <0%> (ø)	⬆️

---

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.

[jasmussen]

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.

[youknowriad]

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

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

[youknowriad]

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

[jasmussen]

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.

[youknowriad]

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

[mtias]

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.

[StaggerLeee]

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.

[afercia]

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?

[karmatosed]

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.

[afercia]

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 🙂

[karmatosed]

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

[youknowriad]

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

[youknowriad]

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.

[mtias]

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

[afercia]

Can you help us recruit them?

@karmatosed will ask around :)

[afercia]

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

[melchoyce]

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)

[rianrietveld]

User test results #2259

[afercia]

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

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

[afercia]

I started with the assumption that the current floating toolbar works

That works as placement in the source order. What doesn't work is the continuous appearing/disappearing of the toolbars, which is highly confusing for users.

The only change could be [CSS] placement.

Interesting. While for the WCAG the placement in the source order must match the visual order, maybe it's something worth considering, at one condition:

The more I think at navigation through blocks and interaction with them, the more I'm convinced that interaction with blocks should be standardized, see
Keyboard interaction: standardize the blocks behavior #2031

Once that would be done, the following step would be establishing a sort of "Edit mode":

• navigation with keyboard focuses only the blocks
• once users reach the block they want to edit, some command (Enter?) switches the block in Edit mode, moves focus inside of it, the toolbar appears
• when a block is edited, the rest of the interface becomes "inert". The only focusable controls are the edited block and its toolbar (wherever it is placed) and that's the condition mentioned above
• once done editing, a command (Escape? a "Done" button?) exits the block from Edit mode
• navigation through block can continue with the Tab key
• navigation through the toolbar controls still to define, in my opinion it should work like an ARIA toolbar: just one Tab stop and all the controls reachable only with arrow keys

[folletto]

The more I think at navigation through blocks and interaction with them, the more I'm convinced that interaction with blocks should be standardized

100% agreed. My perspective is that the idea of blocks is to bring in also that kind of level of standardization. :)

[mtias]

This is something we have been back and forth in design so much, that I think it might warrant a quick toggle setting so we can test for real and get a better impression of the tradeoffs. I've heard very solid arguments for both proposals, and I think we are exhausting what we can accomplish in discussion form. I also don't feel there's a clear winner yet, so would like to give us the room to test the two.

@youknowriad do you think we could target the toolbar easily to two slots based on a setting?

[youknowriad]

@youknowriad do you think we could target the toolbar easily to two slots based on a setting?

I think it's doable yes, with some hacky CSS though. What kind of setting are you thinking of? An URL setting? a toggle somewhere in the UI? I'll probably have to rebuild this from scratch but not a big deal.

[youknowriad]

Also which one of the "fixed" toolbar design do you think is best?

• Fixed not centered (could also be at the bottom like ghost)
• Fixed centered but with a 100% border
• Fixed centered but with a border limited to the content area Editor: Try a fixed block toolbar #2148 (comment)
• Fixed and centered in the header Editor: Try a fixed block toolbar #2148 (comment)

I personally still prefer the first one visually but happy to try any other alternative.

[jasmussen]

I like these two:

• Fixed centered but with a border limited to the content area Editor: Try a fixed block toolbar #2148 (comment)
• Fixed and centered in the header Editor: Try a fixed block toolbar #2148 (comment)

though I'd prefer a full-width bar instead of the centered bar.

[afercia]

I can't second this approach of trying new things just considering a visual perspective. As already noted, this change is an accessibility regression and to make it accessible it would require relevant changes that should be included here. They can't be "added later" because there's no guarantee we'll be able to find a good solution. Any relevant UI change should already include accessibility.

[jasmussen]

My apologies Andrea, I didn't mean to ignore your past statements. I assumed per your comment here, and per the latest mockup that Yoast provided in the core editor slack which also featured a docked toolbar, that there was a path ahead for this?

[afercia]

@joen my role in WordPress and my role at Yoast are two separate things :) Coincidentally, those mockups introduce the idea of a sort of "Edit mode", same as in my comment #2148 (comment)

My idea is that in the "Edit mode" the block, the toolbar (and maybe the sidebar) should be the only available and focusable controls and all the rest of the UI should becomes "inert". This could help accessibility as users will be in a sort of "modal" where they have to accomplish a task and the UI makes available only the controls for that task. This part is not mentioned in the mockup, that's a design experimentation.

My point here is that any experimentation should already include at least a vague idea of how accessibility should be addressed. Instead, what I see is just a visual approach. I'd like to point out again that when there are relevant UI changes, accessibility can't be added later as a bandaid solution, but should be integrated in the design process.

I'm not seeing this happening here, even after months we're collaborating, and that's honestly a bit disheartening.

[jasmussen]

Thank you for the clarification, very helpful. I'm sorry you feel this way and I completely understand where it is coming from. There's a lot to do here, and sometimes experimentation moves fast — in this case I mistakenly assumed that due to the fact that this was a CSS only change, combined with entering "edit mode" as you described in your comment could be done by simply starting to type or clicking with the mouse, the mockups already could be built in a way that satisfied your suggestions.

However I will try to deeply re-read and think about your comment, and try to make a new mockup as soon as I can. Is there anything else I can do?

[afercia]

Trying to expand a bit, see screenshot below to get an idea (the opacity layer is just for clarification):

If all the UI becomes "inert" except the edited block and its toolbar, then the position of the toolbar in the source doesn't matter so much. The only available and focusable controls would be the block itself and its toolbar. The tab order would cycle just through the block and its toolbar.

However, the technical challenge here is making all the rest of the UI not focusable and completely hidden to assistive technologies. I doubt there is a viable solution here and this is the reason why I think this experimentation can't address the underlying accessibility issues.

[jasmussen]

Very much appreciate your clarification. It sounds a lot like what Google Docs does on mobile:

[hedgefield]

I like that a lot, and I like the idea of an 'edit' mode. I should clarify on the yoast mockup, including it in the top toolbar there was purely visual. We wanted to try a fixed toolbar but I didn't like leaving so much whitespace so I put it there. But I could definitely see it as the contextual sticky toolbar that @melchoyce suggests above, or as temporarily taking full control of the top bar in 'edit mode' like in @jasmussen's google screenshots. I also wonder if we can't find a middle road by attaching it to the block in a better way.

The thing is that showing the toolbar next to the block all the time is distracting, but if you summon it manually (during some kind of edit mode), it doesn't have to be awkwardly squished between blocks, it can take the space it needs.

Attaching it to the block and lifting the whole thing up makes it feel more like a robust whole to me. (For the purpose of this discussion, let's ignore my experimental placement of the icons.)

[anna-harrison]

Apologies for jumping in here a little late, hopefully can add in some points that will be useful to this discussion

My reading of the main cause of this issue is that the toolbar pops up and is distracting. The proposed solution tabled has been to try fixing the toolbar in some location, mainly to avoid the effects of something popping in and out, and disturbing the writing/reading flow.

A fixed toolbar solution has several complications. Firstly, we break accessibility. I won't reiterate the discussion, as it's well articulated above. Secondly, we break things independent of accessibility - I ran user tests on something quite similar to this last year, and we discovered that disconnecting the toolbar from the point of action resulted in 100% user test fails.

If we return back to the original cause of the issue, i.e. the toolbar pops up and is distracting. We have user tests that show that the likely cause of this is the timing with which we are popping up the toolbar. Perhaps it is worth exploring tweaking the timing of when the toolbar pops-up as an alternate solution to fixing the toolbar #(2279)

[folletto]

Thanks for your feedback Anna.

I think this is worth some clarification, that might have got lost in the discussion. The reason for this suggestion is that:

1. The toolbar covers the content — this is a quite major problem as the editor goal is to provide an interface that allows people to write and edit text. Having something that covers the previous content makes even the simple reading for continuity more difficult. Writing is the core of an editor, so if we can find a way to make it better, we should.
2. The toolbar pops up and distracts — this is related because there are lots of tricks in place to make the floating bar work without distracting (i.e. the work on making it auto-hide while typing), but it's separate because instead is more related to how it's presented. As you noted in the test you link, timing is certainly an issue. But even more, Medium doesn't have that toolbar at all (and has far fewer features, but that's out of scope for this thread).
3. The toolbar keeps moving — this is a minor one, but it plays deep into how perception and cognition work. Having a dedicated area builds up memory over time (so, it's not likely visible on first use), while a moving UI doesn't allow that because every time the person has to re-evaluate where the toolbar is. We minimized this by putting it close to the attention focus of the user, but that depends on how tall is the block.
4. The toolbar might get out of the screen — this is an edge case, but if the toolbar "slides out" then it will have to stick somewhere at the top regardless, like the proposals above, as it would be a problem if it slides out of view. This doesn't apply to small paragraphs, but it's a consideration.

This led us to think alternative ways to present a toolbar that won't cover content and won't distract the user, leading to this thread. The inspiration from this thread is solidly grounded in industry and design standards that evolved over decades: if you recall early apps used floating palettes, but over time more and more apps started having dedicated areas that showed the properties of what's selected. This is a common UI paradigm across desktop apps, and it has also demonstrated its scalability over time. See both consumer and professional apps like Word, Keynote, Photoshop, etc.

Accessibility wise, would be interesting to see for example other companies dealing with the same issue — how did they solve it? I know for example that Word Online has the updating toolbar at the top like the desktop app, and if thats accessible as Microsoft usually does, maybe we can analyze how they did it :)

We should try to prototype this one, evaluate how it performs against the current proposal, and if it works, find a way like the one that was suggested above to preserve its accessibility.

[hedgefield]

It got the same feeling of unrest from the points you describe too @folletto.

To point 2: I like the idea of it hiding when you're typing, I think that will help a lot, and will remove the desire for something like an edit mode.

To point 3: I noticed that too. It makes sense to me that it sticks to the top of the window when you scroll down, but sometimes it would stay there if you scroll up again, leaving it in the middle of the block. Fixing that behaviour would already help a lot.

And in general, something about the fact that it hovers slightly over two different blocks at once makes it feel out of place.

[folletto]

@afercia out of curiosity: how is TinyMCE currently accessible — given it has a static toolbar — and how other apps deal with that (i.e. Word in the online version)?

[afercia]

@folletto the TinyMCE toolbar is pretty accessible, but it's also immediately before the editing area so it's a bit different case. It implements Alt-F10 to move focus to the toolbar. It also uses role="toolbar" which is important for Windows screen readers (e.g. NVDA and JAWS) to correctly pass JS events to the browser. Also, when you make a selection in the edited text, then move to the toolbar, apply some formatting (e.g. bold), focus is moved back to the editor keeping the text selected, which is pretty nice. Selection is preserved also when pressing Escape from the toolbar.

A few considerations:

• since it's an ARIA toolbar (role="toolbar") navigation through the toolbar controls should happen with arrow keys only (no Tab) as specified in the ARIA Authoring Practices expected keyboard interaction: https://www.w3.org/TR/wai-aria-practices/#toolbar
• the toolbar should be labeled
• the TinyMCE demo uses also a menubar (WP doesn't)

Seems the "Toggle Toolbar" button (last one in the first row) breaks keyboard navigation: it is not possible to go through that button with both Tab or Arrow keys. I'm not sure but I think this depends on the WordPress implementation.

You can try it yourself, on the TinyMCE demo: https://www.tinymce.com/
Alt-F9 to focus the menubar
Alt-F10 to focus the formatting toolbar

[youknowriad]

Thanks everyone! I'm happy this PR served as a basis to discuss the fixed toolbar alternative. Based on this exploration, a lot of improvements already shipped and let's continue the discussion about the fixed toolbar in #2998