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

Make actions by the block as default not fixed to toolbar #3570

Closed
karmatosed opened this Issue Nov 20, 2017 · 7 comments

Comments

Projects
None yet
6 participants
@karmatosed
Member

karmatosed commented Nov 20, 2017

I did a batch of usability testing at WordCamp Milano, as did others. Time and time again the fixed actions to the toolbar came up with users not knowing where actions were and missing them. This has come up in #3334 also.

I am not suggest we remove the switching ability. What we need to do is after this do more testing and iteration. However, we by default should go back to action being by the block, like this:

2017-11-20 at 13 15

@anna-harrison

This comment has been minimized.

Show comment
Hide comment
@anna-harrison

anna-harrison Nov 21, 2017

Yes, this is tricky. There was a lot of discussion around this with links to related usability tests I ran earlier in the year in issue 2148 tl;dr the default setting should be fixed to block

A fixed [docked to top] 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.

@folletto and I discussed this in depth off-line, and Davide rightfully pointed out that the user tests referenced above were not identical, however, I believe that the cause underlying the friction is the same: there is too much visual disconnect between where the eye is focussed (i.e. on the block) and the location of the docked toolbar at the top of the page (which, even though it is contextual, and thus changes with each block, is too far away to be noticed)

Starting with the toolbar fixed to the block, and making the user explicitly dock to top should resolve the issue of discoverability raised here

anna-harrison commented Nov 21, 2017

Yes, this is tricky. There was a lot of discussion around this with links to related usability tests I ran earlier in the year in issue 2148 tl;dr the default setting should be fixed to block

A fixed [docked to top] 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.

@folletto and I discussed this in depth off-line, and Davide rightfully pointed out that the user tests referenced above were not identical, however, I believe that the cause underlying the friction is the same: there is too much visual disconnect between where the eye is focussed (i.e. on the block) and the location of the docked toolbar at the top of the page (which, even though it is contextual, and thus changes with each block, is too far away to be noticed)

Starting with the toolbar fixed to the block, and making the user explicitly dock to top should resolve the issue of discoverability raised here

@folletto

This comment has been minimized.

Show comment
Hide comment
@folletto

folletto Nov 22, 2017

there is too much visual disconnect between where the eye is focussed (i.e. on the block) and the location of the docked toolbar at the top of the page

I definitely agree here.

As much as I think it's better in the long term for a multitude of reasons to have it on top (no content covering, more extensible), I think the current approach is short-handing it: functionally effective, but not intuitive at first.

The problem I see now for someone not aware of that top bar are:

  1. No initial learning — the page loads with something already inside the bar. This means there's never a proper transition from "empty" to "something", thus there's no awareness that area will change.
  2. Mixed content — the toolbar is currently mixed with other icons, static, which again creates the expectation for that to never change.

It's notable that Office, that has a top-heavy UI so should be clear already "everything is up there", does a stark color and an animation when the otherwise static top bar changes:

cap-word-animation-bar

In short, given the test results I think we should probably provide the above as an option ("Dock this") or if we prefer structurally the bar at the top, we should work to offset its discoverability shortcomings with color, animations, a better initial state, a guidance for first use.

Note: I consider "Docking" an option here even if in general I'm against options for something like this because we would still need to code it for when the component scrolls out of view. So there would be no maintenance "saving" as docking code would have to exist regardless.

folletto commented Nov 22, 2017

there is too much visual disconnect between where the eye is focussed (i.e. on the block) and the location of the docked toolbar at the top of the page

I definitely agree here.

As much as I think it's better in the long term for a multitude of reasons to have it on top (no content covering, more extensible), I think the current approach is short-handing it: functionally effective, but not intuitive at first.

The problem I see now for someone not aware of that top bar are:

  1. No initial learning — the page loads with something already inside the bar. This means there's never a proper transition from "empty" to "something", thus there's no awareness that area will change.
  2. Mixed content — the toolbar is currently mixed with other icons, static, which again creates the expectation for that to never change.

It's notable that Office, that has a top-heavy UI so should be clear already "everything is up there", does a stark color and an animation when the otherwise static top bar changes:

cap-word-animation-bar

In short, given the test results I think we should probably provide the above as an option ("Dock this") or if we prefer structurally the bar at the top, we should work to offset its discoverability shortcomings with color, animations, a better initial state, a guidance for first use.

Note: I consider "Docking" an option here even if in general I'm against options for something like this because we would still need to code it for when the component scrolls out of view. So there would be no maintenance "saving" as docking code would have to exist regardless.

@karmatosed karmatosed added this to the Beta 1.8 milestone Nov 23, 2017

@karmatosed

This comment has been minimized.

Show comment
Hide comment
@karmatosed

karmatosed Nov 23, 2017

Member

I think it's important to get this default changed first. Then we can test and see. We can also then include any changes to the language we want and animation - I am all for that, but this issue should be about reversing the default. This needs doing sooner over later.

All tests are shouting right now that the default should be by the block, not the reverse. After we get this in let's test and iterate.

Member

karmatosed commented Nov 23, 2017

I think it's important to get this default changed first. Then we can test and see. We can also then include any changes to the language we want and animation - I am all for that, but this issue should be about reversing the default. This needs doing sooner over later.

All tests are shouting right now that the default should be by the block, not the reverse. After we get this in let's test and iterate.

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Nov 23, 2017

Contributor

Just to note that the fixed [docked to top] toolbar doesn't necessarily breaks accessibility. It depends on the implementation. Quoting from #2148 (comment)

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.

Contributor

afercia commented Nov 23, 2017

Just to note that the fixed [docked to top] toolbar doesn't necessarily breaks accessibility. It depends on the implementation. Quoting from #2148 (comment)

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.

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Nov 23, 2017

Contributor

Aside note: the fixed [docked to top] toolbar has the advantage that keyboard navigation through blocks becomes way "cleaner", with way less tab stops. Instead, docking the toolbars to the blocks re-introduces lots of tab stops between blocks.
The introduction of "navigation mode" and "edit mode" discussed on another issue could help with this, but then I'd consider to make "navigation mode" the default.

Contributor

afercia commented Nov 23, 2017

Aside note: the fixed [docked to top] toolbar has the advantage that keyboard navigation through blocks becomes way "cleaner", with way less tab stops. Instead, docking the toolbars to the blocks re-introduces lots of tab stops between blocks.
The introduction of "navigation mode" and "edit mode" discussed on another issue could help with this, but then I'd consider to make "navigation mode" the default.

@jorgefilipecosta

This comment has been minimized.

Show comment
Hide comment
@jorgefilipecosta

jorgefilipecosta Nov 23, 2017

Member

@karmatosed the change was applied.

Member

jorgefilipecosta commented Nov 23, 2017

@karmatosed the change was applied.

@karmatosed

This comment has been minimized.

Show comment
Hide comment
@karmatosed

karmatosed Nov 23, 2017

Member

@afercia just to be super clear we're not ditching that as an option, it's more the current iteration is causing a lot of usability issues for people. We definitely need to go back to the drawing board a little and iterate on things - consider if we have a fixed toolbar what approach we have.

Thanks @jorgefilipecosta, for now closing this as we can then test and get feedback. Great thoughts everyone, I am closing but they won't be not included in any iteration.

Member

karmatosed commented Nov 23, 2017

@afercia just to be super clear we're not ditching that as an option, it's more the current iteration is causing a lot of usability issues for people. We definitely need to go back to the drawing board a little and iterate on things - consider if we have a fixed toolbar what approach we have.

Thanks @jorgefilipecosta, for now closing this as we can then test and get feedback. Great thoughts everyone, I am closing but they won't be not included in any iteration.

@karmatosed karmatosed closed this Nov 23, 2017

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