Page MenuHomePhabricator

[Page tools] Make page tools menu sticky
Closed, ResolvedPublic3 Estimated Story Points

Description

NOTE: Blockers for this work: T317898, T317900

Description

Being able to access the page tools when scrolled down the page (i.e. not just at the top of the page) can be useful for people. Having a sticky page tools menu also means the page tools menu will match the behavior of the table of contents.

Notes:

  • similar to the table of contents the page tools menu will need a max-height and overflow: scroll

Acceptance criteria

  • Make sure that the Page tools handles overflow nicely. Similar to the TOC, it should have a fade at the bottom when its max-height is exceeded.

QA steps

  1. Visit https://en.wikipedia.beta.wmflabs.org/wiki/Cat when logged-in. Make sure you are using a username that can see the sticky header (I believe we still have A/B code running on beta for the sticky header)
  2. Scroll down so that page tools is sticky
  3. Resize the bottom of your viewport so that a scrollbar appears in page tools. Ensure the scroll indicator at the bottom is also visible when not scrolled to the bottom of the TOC.

Because this patch also changed some styles related to the TOC, please also ensure that the TOC remains usable when its scrollbar appears and when it is:

  1. In the sidebar
  2. In the sticky header
  3. In the page toolbar

https://phabricator.wikimedia.org/T318169#8617071
https://phabricator.wikimedia.org/T318169#8620520

QA Results - Beta

ACStatusDetails
1T318169#8617071
2T318169#8617071

QA Results - Prod

ACStatusDetails
1T318169#8620520
2T318169#8620520

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Nick will update the ticket with information about how to handle overflow (including a fade out effect) to mimic table of contents.

Would it be in scope of this task to also make it configurable (even if only to logged in editors) as to which of the two sidebars the floating tools menu docks itself into? I'm sure I'm not the only editor who would prefer to have it on the left hand side, either before or after the table of contents.

And while I recognise this is not a task directly relating to the ToC, so this may be better asked on another task, but would making the sidebar that it docks to also configurable not also be of benefit to editors and readers of non-English language Wikis, where text is read right-to-left instead of left-to-right? In the same way that left-to-right readers have their ToC to the left of the content area, right-to-left readers may wish to have their ToC to the right of their content area.

bwang removed bwang as the assignee of this task.Jan 31 2023, 5:57 PM
bwang moved this task from Doing to Ready for Development on the Web-Team FY2022-23 Q3 Sprint 2 board.
bwang subscribed.

Thanks for this question @Sideswipe9th. Can you expand on why you would prefer to have the tools menu on the left side? In case you haven't already seen it here is a discussion we had that relates to your question: T300673: [Design spike] Consider changes to main menu. One challenge we explored with putting the page tools on the left is that we can't have two sticky/fixed menus (table of contents, and page tools) on one side.

I'm more than happy to @ovasileva !

I'll state upfront that I'm an editor and reader who prefers unlimited width content. I find that I suffer less eye strain when reading horizontally than vertically. Having two floating sidebars, one at each side of the screen narrows the content area significantly enough that I will rather quickly start getting eye strain related headaches.

As an editor, the amount of time that I interact with the ToC is pretty limited. If I'm on an article, I'll use it to jump straight to the section I wish to edit and then proceed to the edit view. In the edit view, there is no ToC, so all that's left on the left sidebar is the Main Menu content, and a handful of user created tools that have yet to update to move their links to the toolbar on the right. The list of the user created tools I use can be found at :en:User:Sideswipe9th/common.js. Pretty much all of the Main Menu content, with the exception of any tools that have not yet updated to be on the right sidebar, is of no use to me whenever I'm actively editing a page, it's just a bunch of blue links I never click on. Now while I can hide the Main Menu and gain that otherwise wasted space at the left side of my screen back, doing so results in my edit view and edit preview being inconsistent in layout with the primary article view, because on the main article view I've not hidden the ToC.

This might be easier explained with a series of screenshots.

image.png (1×1 px, 477 KB)

This screenshot is the Bread article on enwiki. I've got the Main Menu and ToC docked to the right side of the screen, and the Tools bar hidden. Even if I hide the main menu, there will still be a sidebar at the left of my screen because of the presence of the ToC. If I want to edit the Preparation section, I'll click it in the ToC to navigate to it, and then hit Edit Source.

image.png (1×1 px, 211 KB)

This screenshot is the Editing view of the Preparation section. I've got the Main Menu docked on the right side of the screen. The ToC is absent because I'm editing a section. There's a couple of tools visible on the left side, because they've not been updated to move to the right side.

image.png (1×1 px, 360 KB)

In this screenshot, pretend I've made some changes and I'm previewing how they look as rendered. Because I have the Main Menu docked, I see an output that is pretty similar to how it will look whenever I'm back at the article view after clicking publish.

image.png (1×1 px, 219 KB)

In this screenshot, I've hidden the Main Menu, and docked the Tools menu. Because I've hidden the Main Menu, and there's no ToC in the edit view, my content area immediately expands to take up the now vacant space.

image.png (1×1 px, 359 KB)

Finally in this screenshot, again pretend I've made some changes and I'm previewing to see how it will look as rendered. However because I've hidden the Main Menu, and the ToC does not exist on the edit view, I see an output that is pretty different to how it will look whenever I've finished editing and have published my changes. The sidebar that will be there as soon as I've published is missing entirely, as is the space that it otherwise takes up. I've noticed that this will affect the placement of images relative to the text and sections that they should be present in, and occasionally affect the rendering of tables.

When looking at the linked task, I find the video by alexhollender posted on 2 February 2022 (T300673#7673047 ) to be an improvement over the current situation. Having only one of the Article Tools or ToC open at a time in a left docked sidebar is not much of an issue as an editor, because the ToC straight up doesn't exist whenever I'm editing content.

That being said, I'm a little unclear as to why in that prototype both the ToC and AT panes need to be in an accordion box for both lists to be floating, other than for possible stylistic reasons. Nor why you're unable to have two sticky menus on the same side. The current version of the ToC doesn't use an accordion, and I don't see an obvious reason from looking at the HTML and CSS output why <div id="vector-page-tools" class="vector-page-tools vector-pinnable-element"> can't just be another child of <div id="vector-toc" class="vector-toc vector-pinnable-element"> with or without an accordion on it. I'm able to mock this up pretty quickly with my browser's developer tools, and can be seen in the screenshots below, and the only thing that seems broken from a quick re-parenting of that div is that the scrollbar for the docked sidebar doesn't extend the full height of the page, but that seems to be exhibiting the same behaviour as the current live version of the floating ToC anyway.

image.png (1×476 px, 73 KB)

image.png (173×1 px, 27 KB)

@alexhollender_WMF What is the ideal amount of vertical space from the top of the page tools (and the TOC) to the bottom of the sticky header? In the prototype, it looks like this space is smaller than what is currently in production (please see below)

Prototype

prototype-space.png (1×3 px, 2 MB)

Production

space-prod.png (1×3 px, 3 MB)

Also, what is the desired max-height? I assumed it would be 100vh - height of sticky header but then I noticed T319315

Change 886437 had a related patch set uploaded (by Nray; author: Nray):

[mediawiki/skins/Vector@master] Make page tools sticky

https://gerrit.wikimedia.org/r/886437

just discussed with @nray

@alexhollender_WMF What is the ideal amount of vertical space from the top of the page tools (and the TOC) to the bottom of the sticky header? In the prototype, it looks like this space is smaller than what is currently in production (please see below)

the prototype is correct. I think the margin on the top of the ToC got increased when we made the main menu pin-able, to ensure that those two menus aren't too close together. One way to get around this might be to adjust the top property on the toc container (currently set to top: 3.125rem !important;)

Also, what is the desired max-height? I assumed it would be 100vh - height of sticky header but then I noticed T319315

It should be 98vh - height of sticky header (so that there's still a small amount of space below it). As described in T319315, this approach has a small downside: on some unique pages like wp:ANI you won't be able to scroll all the way to the bottom of the TOC from the top of the page (without double-scrolling). But it's got the bigger upside of the TOC taking up as much available space once you've scrolled down any amount, which is what people have been asking for.

nray moved this task from Doing to Code Review on the Web-Team FY2022-23 Q3 Sprint 2 board.
Mabualruz moved this task from Code Review to QA on the Web-Team FY2022-23 Q3 Sprint 2 board.
Mabualruz subscribed.

Change 886437 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Make page tools sticky

https://gerrit.wikimedia.org/r/886437

Change 887418 had a related patch set uploaded (by Nray; author: Nray):

[mediawiki/skins/Vector@master] Moving padding-bottom to mixin-vector-scroll-indicator

https://gerrit.wikimedia.org/r/887418

nray moved this task from QA to Code Review on the Web-Team FY2022-23 Q3 Sprint 2 board.
nray added a subscriber: Edtadros.

Moving this to code review for a follow-up suggested by @bwang: https://gerrit.wikimedia.org/r/887418

Change 887418 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Moving padding-bottom to mixin-vector-scroll-indicator

https://gerrit.wikimedia.org/r/887418

nray updated the task description. (Show Details)
nray updated the task description. (Show Details)

@alexhollender_WMF This and T319315 are now on beta (e.g. https://en.wikipedia.beta.wmflabs.org/wiki/Dog) if you'd like to design review.

A question came up during code review whether we want the space from the top of the TOC/page tools to the top of the viewport when logged-out to match the space from the top of the TOC/page tools to the bottom of the sticky header when logged-in. I noticed in the prototype that this space is different, so that is reflected in the code, but is that intentional?:

2023-02-08_15-20-43.png (1×3 px, 1 MB)

2023-02-08_15-21-42.png (1×3 px, 1 MB)

^^ cc @bwang as he asked this question during code review

@alexhollender_WMF This and T319315 are now on beta (e.g. https://en.wikipedia.beta.wmflabs.org/wiki/Dog) if you'd like to design review.

awesome. I think it's looking good all around.

tall TOC at top of pagetall TOC in middle of page
logged out
Screenshot 2023-02-09 at 10.34.20 AM.png (813×1 px, 623 KB)
Screenshot 2023-02-09 at 10.35.29 AM.png (811×1 px, 625 KB)
logged in
Screenshot 2023-02-09 at 10.29.37 AM.png (811×1 px, 645 KB)
Screenshot 2023-02-09 at 10.29.52 AM.png (811×1 px, 536 KB)
tall page tools menu at top of pagetall page tools menu in middle of page
Screenshot 2023-02-09 at 10.37.01 AM.png (770×1 px, 602 KB)
Screenshot 2023-02-09 at 10.37.16 AM.png (775×1 px, 616 KB)

A question came up during code review whether we want the space from the top of the TOC/page tools to the top of the viewport when logged-out to match the space from the top of the TOC/page tools to the bottom of the sticky header when logged-in. I noticed in the prototype that this space is different, so that is reflected in the code, but is that intentional?:

2023-02-08_15-20-43.png (1×3 px, 1 MB)
2023-02-08_15-21-42.png (1×3 px, 1 MB)

Ah my bad on that. That difference is not intentional. Below I've documented what I'm currently seeing in production and on beta. I think we can have a consistent amount of space here for both logged-in and logged-out of 30px.

logged-outlogged-in
beta
image.png (986×1 px, 126 KB)
image.png (930×1 px, 118 KB)
production
image.png (724×818 px, 51 KB)
image.png (958×1 px, 119 KB)

Small thing, is it possible to remove this gap between the top of the TOC and the top of the screen, while still maintaining the same amount of distance from the top of the TOC and the top of the screen when you're at the top of the page?

Screenshot 2023-02-09 at 10.35.29 AM.png (612×732 px, 205 KB)

Something is a little bit wrong with "Add interlanguage links" in the "tall TOC" screen shots. It is a little bit too far to the left, and the left edge of "A" and "l" are being cut off.

Change 888109 had a related patch set uploaded (by Nray; author: Nray):

[mediawiki/skins/Vector@master] Increase space between top of TOC/Page tools and top of viewport

https://gerrit.wikimedia.org/r/888109

Test wiki created on Patch demo by NRay (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/ff11c52245/w

nray moved this task from Code Review to QA on the Web-Team FY2022-23 Q3 Sprint 2 board.

Waiting for this to land on beta and then will hand over to @Edtadros

Change 888109 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Make space between top of TOC/Page tools and top of viewport/bottom of sticky header 30px

https://gerrit.wikimedia.org/r/888109

Test Result - Beta

Status: ✅ PASS
Environment: beta/xyzwiki
OS: macOS Ventura
Browser: Chrome
Device: MBP
Emulated Device:NA

Test Artifact(s):

QA Steps

Visit https://en.wikipedia.beta.wmflabs.org/wiki/Cat when logged-in. Make sure you are using a username that can see the sticky header (I believe we still have A/B code running on beta for the sticky header)
Scroll down so that page tools is sticky
Resize the bottom of your viewport so that a scrollbar appears in page tools.
✅ AC1: Ensure the scroll indicator at the bottom is also visible when not scrolled to the bottom of the TOC.
✅ AC2: Because this patch also changed some styles related to the TOC, please also ensure that the TOC remains usable when its scrollbar appears and when it is:

In the sidebar

Screen Recording 2023-02-14 at 5.13.59 PM.mov.gif (466×1 px, 746 KB)

In the sticky header
Screen Recording 2023-02-14 at 5.14.26 PM.mov.gif (466×1 px, 886 KB)

In the page toolbar
Screen Recording 2023-02-14 at 5.15.06 PM.mov.gif (466×1 px, 1 MB)

@nray , the only issue I see is that when the viewport is vertically small, you can't scroll to the bottom of either the TOC or the pagetools. I was about 430px in the screengrabs. Here you can see that at some point the page has to scroll to see the rest of both the TOC and pagetools.

Screen Recording 2023-02-14 at 5.22.19 PM.mov.gif (466×1 px, 1 MB)

Hi. Wanted to check this out, but creating an account is not working on beta.
https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:CreateAccount

[Y@yysNLyqzFa4FLcOCLCqQAAAFQ] /w/index.php?title=Special:CreateAccount FileBackendError: Iterator page I/O error.

Backtrace:

from /srv/mediawiki/php-master/includes/libs/filebackend/SwiftFileBackend.php(952)
#0 /srv/mediawiki/php-master/includes/libs/filebackend/fileiteration/SwiftFileBackendDirList.php(39): SwiftFileBackend->getDirListPageInternal(string, string, NULL, integer, array)
#1 /srv/mediawiki/php-master/includes/libs/filebackend/fileiteration/SwiftFileBackendList.php(112): SwiftFileBackendDirList->pageFromList(string, string, NULL, integer, array)
#2 /srv/mediawiki/php-master/extensions/ConfirmEdit/FancyCaptcha/includes/FancyCaptcha.php(233): SwiftFileBackendList->rewind()

@Edtadros I think this is a pass based on Alex's comments on T319315:

You can see how the scrolling stops before reaching the bottom of the TOC, and then the secondary scroll scrolls the entire page, allowing you to get to the bottom of the TOC.

@Nux It has currently been deployed to all group 0 wikis (e.g. https://www.mediawiki.org/wiki/WYSIWYG_editor) and is scheduled to deploy to group 1 (e.g. cawiki) today and group 2 (e.g. enwiki) tomorrow

I'm more than happy to @ovasileva !

@Sideswipe9th thanks so much for all of these details, and sorry for such a delay in responding.

If I’m understanding correctly the primary reason you want the tools menu on the left is to make more room for the article text. I assume you’re already using the full-width setting to maximize the amount of space for the article text, yes?

It seems like you have a secondary concern around ensuring that the article in edit mode matches the article in read mode. I agree with you that they should match. I believe this is related to the version of the editor you are using (2010 vs. 2017 wikitext editor). I believe if you enable all Beta features it will switch you to the 2017 editors, and then when you are in edit mode (Visual or Source) the area for the table of contents is always reserved. My understanding is that for the 2010 wikitext editor, the reason it is full-width by default is to make extra room for the "Preview" feature. The preview allows you to see how wikitext (and I think specifically templates) will be rendered, though as you point out it has the downside of not reflecting how the layout in general will look.

Screenshot 2023-02-15 at 2.19.45 PM.png (862×1 px, 400 KB)

Regarding your question of why we couldn’t have all three menus in the left sidebar: we could (link to demo). The tradeoff is that if you do that, you can’t have both the table of contents and the tools menu immediately available when you arrive on a page. It sounds like, for you, that isn’t as important as having the extra room for the article text (which of course goes back to line-length preferences, which is the initial divergence between the current layout and your preference).

Test Result - Prod

Status: ✅ PASS
Environment: cawiki
OS: macOS Ventura
Browser: Chrome
Device: MBP
Emulated Device:NA

Test Artifact(s):

QA Steps

Visit https://en.wikipedia.beta.wmflabs.org/wiki/Cat when logged-in. Make sure you are using a username that can see the sticky header (I believe we still have A/B code running on beta for the sticky header)
Scroll down so that page tools is sticky
Resize the bottom of your viewport so that a scrollbar appears in page tools.
✅ AC1: Ensure the scroll indicator at the bottom is also visible when not scrolled to the bottom of the TOC.
✅ AC2: Because this patch also changed some styles related to the TOC, please also ensure that the TOC remains usable when its scrollbar appears and when it is:

In the sidebar

Screen Recording 2023-02-15 at 4.41.07 PM.mov.gif (610×1 px, 1 MB)

In the sticky header
Screen Recording 2023-02-15 at 4.39.18 PM.mov.gif (610×1 px, 2 MB)

In the page toolbar
Screen Recording 2023-02-15 at 4.39.42 PM.mov.gif (610×1 px, 2 MB)

Test wiki on Patch demo by NRay (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/ff11c52245/w/