New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editor: Try a fixed block toolbar #2148

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
@youknowriad
Contributor

youknowriad commented Aug 2, 2017

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.

screen shot 2017-08-02 at 10 39 24

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

@youknowriad youknowriad self-assigned this Aug 2, 2017

@youknowriad youknowriad requested a review from jasmussen Aug 2, 2017

@codecov

This comment has been minimized.

Show comment
Hide comment
@codecov

codecov bot Aug 2, 2017

Codecov Report

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

Impacted file tree graph

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

codecov bot commented Aug 2, 2017

Codecov Report

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

Impacted file tree graph

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

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Aug 2, 2017

Contributor

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.

Contributor

jasmussen commented Aug 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Aug 2, 2017

Contributor

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

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

Contributor

youknowriad commented Aug 2, 2017

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 comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Aug 2, 2017

Contributor

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

Contributor

youknowriad commented Aug 2, 2017

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

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Aug 2, 2017

Contributor

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.

Contributor

jasmussen commented Aug 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Aug 2, 2017

Contributor

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

Contributor

youknowriad commented Aug 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Aug 2, 2017

Contributor

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.

Contributor

mtias commented Aug 2, 2017

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.

@mtias mtias added the Chrome label Aug 2, 2017

@StaggerLeee

This comment has been minimized.

Show comment
Hide comment
@StaggerLeee

StaggerLeee Aug 2, 2017

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.

StaggerLeee commented Aug 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Aug 2, 2017

Contributor

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?

Contributor

afercia commented Aug 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@karmatosed

karmatosed Aug 2, 2017

Member

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:

2017-08-02 at 14 56

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.

Member

karmatosed commented Aug 2, 2017

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:

2017-08-02 at 14 56

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

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Aug 2, 2017

Contributor

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 🙂

Contributor

afercia commented Aug 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@karmatosed

karmatosed Aug 2, 2017

Member

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

Member

karmatosed commented Aug 2, 2017

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

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Aug 2, 2017

Contributor

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

Contributor

youknowriad commented Aug 2, 2017

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

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Aug 2, 2017

Contributor

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.

Contributor

youknowriad commented Aug 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Aug 2, 2017

Contributor

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

Contributor

mtias commented Aug 2, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Aug 2, 2017

Contributor

Can you help us recruit them?

@karmatosed will ask around :)

Contributor

afercia commented Aug 2, 2017

Can you help us recruit them?

@karmatosed will ask around :)

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Aug 2, 2017

Contributor

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

Contributor

afercia commented Aug 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@melchoyce

melchoyce Aug 3, 2017

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:

image

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

melchoyce commented Aug 3, 2017

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:

image

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

@rianrietveld

This comment has been minimized.

Show comment
Hide comment
@rianrietveld

rianrietveld Aug 7, 2017

Member

User test results #2259

Member

rianrietveld commented Aug 7, 2017

User test results #2259

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Aug 7, 2017

Contributor

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

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

Contributor

afercia commented Aug 7, 2017

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

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

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Aug 14, 2017

Contributor

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.

Contributor

youknowriad commented Aug 14, 2017

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.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Aug 14, 2017

Contributor

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

Contributor

jasmussen commented Aug 14, 2017

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

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Aug 16, 2017

Contributor

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.

Contributor

youknowriad commented Aug 16, 2017

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.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Aug 16, 2017

Contributor

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.

Contributor

jasmussen commented Aug 16, 2017

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.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Aug 16, 2017

Contributor

CC: @annaephox

Contributor

jasmussen commented Aug 16, 2017

CC: @annaephox

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Aug 16, 2017

Contributor

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

Contributor

youknowriad commented Aug 16, 2017

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

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Aug 16, 2017

Contributor

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!

Contributor

jasmussen commented Aug 16, 2017

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!

@folletto

This comment has been minimized.

Show comment
Hide comment
@folletto

folletto Sep 29, 2017

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.

I've skimmed through the discussion so I might have missed it, but: what if we move the controls inside the existing top bar, and show them only when something is selected? No extra bar, no extra animations, and on mobile it could still pop-out to be a separate bar for space reasons.

Quick mock:

screen shot 2017-09-29 at 13 03 07

folletto commented Sep 29, 2017

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.

I've skimmed through the discussion so I might have missed it, but: what if we move the controls inside the existing top bar, and show them only when something is selected? No extra bar, no extra animations, and on mobile it could still pop-out to be a separate bar for space reasons.

Quick mock:

screen shot 2017-09-29 at 13 03 07

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Sep 29, 2017

Contributor

As already mentioned in a previous comment, this change would significantly worsen the keyboard navigation experience. I'd like everyone here to test with keyboard only (or imagine keyboard interaction with this change) before proposing a fixed toolbar.

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?

Imagine a post with multiple blocks. Should keyboard users then navigate through multiple posts before going back to the toolbar on the top? Or there should be some focus management (which I see very problematic)? How it is supposed to work? Anyone has taken this into consideration?

The best option is having the controls "in place", as close as possible to the area users are editing, and easy to discover and use. Worth noting the actual interaction with the block toolbars is still problematic for many other reasons, but this is out of the scope of this issue and already tracked on other issues.

Contributor

afercia commented Sep 29, 2017

As already mentioned in a previous comment, this change would significantly worsen the keyboard navigation experience. I'd like everyone here to test with keyboard only (or imagine keyboard interaction with this change) before proposing a fixed toolbar.

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?

Imagine a post with multiple blocks. Should keyboard users then navigate through multiple posts before going back to the toolbar on the top? Or there should be some focus management (which I see very problematic)? How it is supposed to work? Anyone has taken this into consideration?

The best option is having the controls "in place", as close as possible to the area users are editing, and easy to discover and use. Worth noting the actual interaction with the block toolbars is still problematic for many other reasons, but this is out of the scope of this issue and already tracked on other issues.

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Sep 29, 2017

Contributor

Imagine a post with multiple blocks. Should keyboard users then navigate through multiple posts before going back to the toolbar on the top? Or there should be some focus management (which I see very problematic)? How it is supposed to work? Anyone has taken this into consideration?

I was thinking of something similar to the inspector, a button close to the block and a shortcut to jump to the toolbar maybe

Contributor

youknowriad commented Sep 29, 2017

Imagine a post with multiple blocks. Should keyboard users then navigate through multiple posts before going back to the toolbar on the top? Or there should be some focus management (which I see very problematic)? How it is supposed to work? Anyone has taken this into consideration?

I was thinking of something similar to the inspector, a button close to the block and a shortcut to jump to the toolbar maybe

@folletto

This comment has been minimized.

Show comment
Hide comment
@folletto

folletto Sep 29, 2017

Anyone has taken this into consideration?

Yes, it's an important consideration. I agree that must be taken in consideration.

I started with the assumption that the current floating toolbar works, as I trusted it was already reviewed by you. If it does, the only difference would be that instead of showing attached visually, would be top aligned. There's no need to mutate DOM and JS behaviour. The only change could be placement.

One of the possible solutions could be CSS only, by having some of the position: relative to not constrain the positioning of the toolbar, thus making it placeable in the top bar. Let's find a solution together? :)

folletto commented Sep 29, 2017

Anyone has taken this into consideration?

Yes, it's an important consideration. I agree that must be taken in consideration.

I started with the assumption that the current floating toolbar works, as I trusted it was already reviewed by you. If it does, the only difference would be that instead of showing attached visually, would be top aligned. There's no need to mutate DOM and JS behaviour. The only change could be placement.

One of the possible solutions could be CSS only, by having some of the position: relative to not constrain the positioning of the toolbar, thus making it placeable in the top bar. Let's find a solution together? :)

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Sep 29, 2017

Contributor

I was thinking of something similar to the inspector, a button close to the block and a shortcut to jump to the toolbar maybe

I'm afraid it's a too complicated and unintuitive interaction. Also, how to jump back from the toolbar to the block currently being edited? Not a surprise (for sure not for me) we're starting to get feedback and comments like #2801:

The editor is rather inaccessible. I am blind, so use a screen reader to read my computer. I tested with orca on linux so far, and it... failed pretty miserably. While tabbing around the interface, buttons would seem to be there then not there at random intervals, and some controls I could access (for example the disabled move buttons when you only have one block) suddenly disappeared entirely upon adding another block ...

Contributor

afercia commented Sep 29, 2017

I was thinking of something similar to the inspector, a button close to the block and a shortcut to jump to the toolbar maybe

I'm afraid it's a too complicated and unintuitive interaction. Also, how to jump back from the toolbar to the block currently being edited? Not a surprise (for sure not for me) we're starting to get feedback and comments like #2801:

The editor is rather inaccessible. I am blind, so use a screen reader to read my computer. I tested with orca on linux so far, and it... failed pretty miserably. While tabbing around the interface, buttons would seem to be there then not there at random intervals, and some controls I could access (for example the disabled move buttons when you only have one block) suddenly disappeared entirely upon adding another block ...

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Sep 29, 2017

Contributor

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
Contributor

afercia commented Sep 29, 2017

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

This comment has been minimized.

Show comment
Hide comment
@folletto

folletto Oct 2, 2017

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

folletto commented Oct 2, 2017

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

@hedgefield hedgefield referenced this pull request Oct 3, 2017

Closed

blank #2867

@mtias

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Oct 3, 2017

Contributor

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?

Contributor

mtias commented Oct 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Oct 3, 2017

Contributor

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

Contributor

youknowriad commented Oct 3, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Oct 3, 2017

Contributor

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 #2148 (comment)
  • Fixed and centered in the header #2148 (comment)

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

Contributor

youknowriad commented Oct 3, 2017

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 #2148 (comment)
  • Fixed and centered in the header #2148 (comment)

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

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Oct 3, 2017

Contributor

I like these two:

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

Contributor

jasmussen commented Oct 3, 2017

I like these two:

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

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Oct 3, 2017

Contributor

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.

Contributor

afercia commented Oct 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Oct 4, 2017

Contributor

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?

Contributor

jasmussen commented Oct 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Oct 4, 2017

Contributor

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

Contributor

afercia commented Oct 4, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Oct 4, 2017

Contributor

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?

Contributor

jasmussen commented Oct 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Oct 4, 2017

Contributor

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

31015166-a3073954-a516-11e7-8ca8-987f56863879

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.

Contributor

afercia commented Oct 4, 2017

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

31015166-a3073954-a516-11e7-8ca8-987f56863879

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

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Oct 4, 2017

Contributor

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

screenshot_20171004-100651

screenshot_20171004-100705

Contributor

jasmussen commented Oct 4, 2017

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

screenshot_20171004-100651

screenshot_20171004-100705

@hedgefield

This comment has been minimized.

Show comment
Hide comment
@hedgefield

hedgefield Oct 4, 2017

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.

miniblock2

miniblock1

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

hedgefield commented Oct 4, 2017

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.

miniblock2

miniblock1

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

This comment has been minimized.

Show comment
Hide comment
@anna-harrison

anna-harrison Oct 6, 2017

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)

anna-harrison commented Oct 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
@folletto

folletto Oct 6, 2017

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.

folletto commented Oct 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
@hedgefield

hedgefield Oct 9, 2017

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.

hedgefield commented Oct 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@folletto

folletto Oct 11, 2017

@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)?

folletto commented Oct 11, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Oct 11, 2017

Contributor

@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

Contributor

afercia commented Oct 11, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Oct 12, 2017

Contributor

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

Contributor

youknowriad commented Oct 12, 2017

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

@youknowriad youknowriad deleted the try/fixed-block-toolbar branch Oct 12, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment