1126461 - Page buttons overlap content when TOC is collapsed

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: Wiki pages, defect)

Description

[John Karahalis [:openjck]]

What did you do?
================
1. Visit https://developer.mozilla.org/docs/Web/CSS/border-radius
2. Shrink the page width until the TOC disappears
3. Scroll down

What happened?
==============
The page buttons (Languages, Edit, etc.) overlap the text content.

What should have happened?
==========================
The page buttons should have a solid white background.

Is there anything else we should know?
======================================

Comment 1

[John Karahalis [:openjck]]

https://i.imgur.com/7EVxykc.png

Comment 2

[Will Bamberg [:wbamberg]]

Also, the buttons sometimes show up on the left. For example, https://developer.mozilla.org/en-US/docs/Tools/Page_Inspector/UI_Tour#Rules_view: https://imgur.com/aSecbKa.

Also, I might be misunderstanding the idea here, but... while I can see that this change makes it easier to edit documents, and is therefore pleasing to editors, it seems to steal screen real estate from content, so perhaps being less pleasing to the (presumably) much larger number of readers who have no intention of editing. Are we sure this is the right tradeoff?

Comment 3

[John Karahalis [:openjck]]

Thanks for letting us know. I updated the pull request with another fix.

You raise a good point about balancing user experiences for different types of users. The user experience of reading the site is especially important given that readers outnumber editors. The goal with the feature was to convert readers into editors, rather than making work easier for existing editors. According to the numbers we ran, it did have the effect we predicted, by encouraging 37% more readers to edit.

There are still some readers who only want to read. We should pay attention to their reactions. If the button is annoying to them, we can evaluate whether it's worth the 37% increase in edits.

Comment 4

[Luke Crouch [:groovecoder]]

(How) can we measure "less pleasing to readers"? ;) Time on page? Session Duration?

Comment 5

[John Karahalis [:openjck]]

Qualitative research would be even better for that sort of thing. Time on page and session duration might be correlated with appreciation for the design, but they could also change for other reasons. For example, a person might spend less time on the page because they are more inspired to edit, or because the edit button is so readily available.

Comment 7

[Will Bamberg [:wbamberg]]

Honestly, IMO, taking content space away from readers for this is not a good tradeoff. It's different when it can live in the ToC column, that's fine. But perhaps it could be non-sticky if the ToC column is hidden?

Comment 8

[David Walsh :davidwalsh]

Yes, that's what I'll implement

Comment 9

[MDN Team (:mdn-dev)]

Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/aff0cb649a66311e089bf32b8c6d93d68da39e19
fix bug 1126461 - Don't sticky buttons when on smaller screens

https://github.com/mozilla/kuma/commit/4eb0d7bb2bb4bfb873b186a9fe27c5ee3abc78af
Merge pull request #3137 from darkwing/1126461-better-sticky

fix bug 1126461 - Don't sticky buttons when on smaller screens