Page MenuHomePhabricator

[ToC] scroll ToC automatically so that active article section is always visible in ToC sidebar
Closed, ResolvedPublic3 Estimated Story Points

Description

Description

Currently the "active" section link in the ToC gets bolded, corresponding to the active section of the page (i.e. the section you are currently reading). The intention behind this feature is that it makes the table of contents a more useful map of the article, providing a sort of "you are here" type indicator whenever you look at it.

For articles with many sections (example: Paris), if you have expanded one (or likely more than one) section, therefore causing the ToC to be taller than the given vertical space of the ToC container, as you scroll down the page you can get into a situation where the active section link is offscreen (i.e. below the "fold" of the ToC container).

To illustrate this, watch as I scroll below the "Culture" sub-sections on the Paris article:

The active section link is still being bolded, but you cannot see it because it's offscreen.

Solution

In this case we think that the ToC should scroll itself, such that the active section link can never be offscreen. We are evaluating two approaches to this solution:

Approach 1

Logic: if a the active ToC section heading is below the vertical center of the ToC, scroll the ToC so that the active section heading is above the vertical midpoint
Pros/cons: this results in more auto-scrolling of the ToC, but the auto-scrolls are smaller jumps
Demo: link to patchdemo
Screen recording:

Approach 2

Logic: if a the active ToC section heading is ~40px from the bottom of the ToC, scroll the ToC so the active section heading is towards the top of the ToC
Pros/cons: this results in less auto-scrolling of the ToC, but the auto-scrolls are larger jumps
Demo: https://patchdemo.wmflabs.org/wikis/5ec25f7054/wiki/Paris?useskin=vector-2022&tableofcontents=true
Screen recording:

(additional visual aids for understanding both approaches are here: T301150#7707873)

Acceptance criteria

  • The bolded section heading in the ToC should always be visible on screen
  • The bolded section should scroll to the middle of the TOC when it reaches 100px from the bottom or top of the TOC
  • The smooth scrolling transition should be off for users with the 'prefers-reduced-motion' setting

Developer notes

It's possible to leverage Element.scrollIntoView() so that the current active state of the TOC section is visible within the view port as it corresponds to the visibility of the main content section while scrolling.

Initial testing of this method inside the activateSection() function of tableOfContents.js seems to produce the desired effect:

tocSection.scrollIntoView( { block: 'center' } );

Purportedly the options parameter is not supported in Safari, but preliminary testing seems to indicate otherwise. It may be that older versions of Safari are not supported. Seems that people have had success with this polyfill in the wild.

There is no IE support for this method but presumably the no-js solution for sticky TOC will suffice for this use case - otherwise we would need to use a polyfill.

Pending design review, we may want to experiment with the different optional parameters that define properties like scrolling behavior, block positioning, etc.

QA Results - Beta (patchdemo)

ACStatusDetails
1T301150#7836955
2T301150#7836955
3T301150#7836955

QA Results - Prod

ACStatusDetails
1T301150#7839700
2T301150#7839700
3T301150#7839700

QA Results - Prod

ACStatusDetails
1T301150#7859504
2T301150#7859504
3T301150#7859504

Event Timeline

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

I wanted to discuss two slightly different approaches here:

Approach 1
  • Logic: if a the active ToC section heading is below the vertical center of the ToC, scroll the ToC so that the active section heading is above the vertical midpoint
  • Pros/cons: this results in more auto-scrolling of the ToC, but the auto-scrolls are smaller jumps

Here are two examples of how this looks:

Google docsModern Wikipedia

an attempt to illustrate this approach...as soon as we get past section 6, which is right in the vertical center of the toc, it scrolls section 7 into view:

frame 1frame 2
image.png (1×2 px, 212 KB)
image.png (1×2 px, 213 KB)
Approach 2
  • Logic: if a the active ToC section heading is ~40px from the bottom of the ToC, scroll the ToC so the active section heading is towards the top of the ToC
  • Pros/cons: this results in less auto-scrolling of the ToC, but the auto-scrolls are larger jumps
frame 1frame 2
image.png (1×2 px, 212 KB)
image.png (1×2 px, 211 KB)

@Jdlrobson @cjming — I'm having a difficult time prototyping these options myself. i'm wondering if it would be possible to build this in such a way that we can try out these two approaches on beta or patchdemo to help us decide which feels better? cc @ovasileva @RHo

hi @alexhollender_WMF - I think this should be do-able -- the TOC is a bit in flux atm until the latest big patch lands but I'm fairly certain we can throw up both options on patchdemo for your all's review

Change 769479 had a related patch set uploaded (by Bernard Wang; author: Bernard Wang):

[mediawiki/skins/Vector@master] Scroll active TOC links into view when past threshold

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

Change 769530 had a related patch set uploaded (by Bernard Wang; author: Bernard Wang):

[mediawiki/skins/Vector@master] Scroll active TOC links into view when past TOC midpoint

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

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

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

@alexhollender_WMF I've put together patchdemos for each approach:
Approach 1 scroll to midpoint
Approach 2 scroll at threshold

Note that approach 1 is a bit weird at the moment, if you scroll slowly you might notice the page jumping a bit. This will be fixed in the final patch, so hopefully its not too distracting that you cant evaluate between the two approaches.
Also let me know if for whatever reason you need to test this in the beta cluster instead of patchdemo.

@bwang thanks for setting these up.

The first one seems to scroll the page back up to the top as soon as I get to the second section: https://imgur.com/a/UZ57UVt

The second one is working as expected, though the intended design is for the ToC to be scrolled such that the active section below the threshold ends up in the middle of the ToC. See Approach 2 > Frame 2 here T301150#7707873. Let me know if that makes sense.

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

https://patchdemo.wmflabs.org/wikis/9362be03f6/w/

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

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

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

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

OK here are the updated patchdemos, let me know if they look right now
Approach 1
Approach 2

@RHo @Pginer-WMF it would be great to get your thoughts on this. If you are able, kindly review the Description, and Solutions sections in the task description. Trying to decide between approach 1 and approach 2.

My thoughts: I prefer approach 2 because the ToC moves much less as I'm scrolling down the page. In approach 1 I find the additional movement of the ToC distracting.


@bwang thanks so much for updating the patchdemos and sorry for the delay. two things:

  • is it possible to avoid the auto-scrolling of the ToC in cases where people click on a section link in the ToC?
  • there seems to be a bug in the patchdemo for approach 2, check this out:

@alexhollender_WMF - both of these seem fine to me, I think it's okay to move forward with option 2

@RHo @Pginer-WMF it would be great to get your thoughts on this. If you are able, kindly review the Description, and Solutions sections in the task description. Trying to decide between approach 1 and approach 2.
My thoughts: I prefer approach 2 because the ToC moves much less as I'm scrolling down the page. In approach 1 I find the additional movement of the ToC distracting.

I agree with Olga that both approaches seem pretty good! I can see what you mean about approach 1 having more movement but wonder if this is less noticeable for someone reading through an article and scrolling more slowly, vs doing a quick scan through where maybe the extra movement is better for orientation at a glance?
Also, I'm wondering if the action/option to expand all ToC sections still in consideration? If it's less likely that the h3+ levels will be shown then it makes both approaches even more similar in behaviour (both have minimal auto-scrolling movement).


@bwang thanks so much for updating the patchdemos and sorry for the delay. two things:

  • is it possible to avoid the auto-scrolling of the ToC in cases where people click on a section link in the ToC?
  • there seems to be a bug in the patchdemo for approach 2, check this out:

I agree with Olga that both approaches seem pretty good! I can see what you mean about approach 1 having more movement but wonder if this is less noticeable for someone reading through an article and scrolling more slowly, vs doing a quick scan through where maybe the extra movement is better for orientation at a glance?
Also, I'm wondering if the action/option to expand all ToC sections still in consideration? If it's less likely that the h3+ levels will be shown then it makes both approaches even more similar in behaviour (both have minimal auto-scrolling movement).

@RHo thanks for your feedback. Interesting point about scroll-speed, that makes sense. The slower someone is scrolling the less distracting the auto-scrolling of the ToC will be. I guess another, related factor is how short sections (and sub-sections) are. Even if you're scrolling kinda slow, but there are super short sections/sub-sections, there could still be a bit of movement within the ToC with approach 1. Which is then related to your question about expand-all (because will the sub-section links even be expanded in the ToC). Apologies for not following up with you about expand-all — we decided not to include that functionality for now, here is our report: T302426. So yea, I think your high-level point is probably most important: this isn't going to happen very often.

@RHo @Pginer-WMF it would be great to get your thoughts on this. If you are able, kindly review the Description, and Solutions sections in the task description. Trying to decide between approach 1 and approach 2.

First, thanks for providing the videos and prototypes that are super helpful for this context. I think both approaches work well, with my preference also being for approach 2.

There are a couple of small aspects that may be worth trying:

  • Using smooth scrolling for the ToC. The main page moves smoothly as the user scrolls, while the table of contents jumps. I'm not sure if both moving more continuously would feel natural or may feel as too many moving pieces, but I think it is worth checking.
  • When a ToC element is put back into viewport, the jump feels a bit too large. Moving the active element above where I was expecting, which may require some extra effort to reorient. A shorter distance would imply a higher number of jumps, but maybe that's ok if each feels more fluent.

As mentioned, minor tweaks to try (and discard if don't contribute to make the experience more fluent!)

@Pginer-WMF thanks for your feedback. Great point about smooth scrolling, we will explore that. Regarding the size of the jump...I guess it's difficult to know where people's eyes are focused in terms of vertical position on the page. I know there's a lot of data around how people initially scan a page (e.g. text scanning patterns), but I haven't found as much regarding the vertical segment of the screen that people sort of settle into as they're scrolling through a page. I've always just assumed people are focused in this region, but really I'm unsure:

image.png (1×2 px, 1 MB)

@bwang would it be possible for you to try out smooth scrolling for the auto-scroll on approach 2?

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

https://patchdemo.wmflabs.org/wikis/5ec25f7054/w/

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

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

Change 774555 had a related patch set uploaded (by Bernard Wang; author: Bernard Wang):

[mediawiki/skins/Vector@master] Scroll active TOC links into view when past threshold

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

I've updated both patch demos to have smooth scrolling
Approach 1
Approach 2

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

  • When a ToC element is put back into viewport, the jump feels a bit too large. Moving the active element above where I was expecting, which may require some extra effort to reorient. A shorter distance would imply a higher number of jumps, but maybe that's ok if each feels more fluent.

This sounds similar to a version I had tried during development, figured I'd put up a patch demo for it too for discussion. It's similar to Approach 2 but instead of jumping to the midpoint when the active section reaches the threshold, it does a smaller jump so that the section is right above the threshold.
Approach 3

@bwang thanks for updating these. let's move forward with approach 2 with smooth scrolling. have you taken a look at the bug I mentioned in T301150#7792984? it seems to still be happening

Change 769530 abandoned by Bernard Wang:

[mediawiki/skins/Vector@master] Scroll active TOC links to TOC midpoint

Reason:

Abandoning in favor of https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/769479

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

Change 774555 abandoned by Bernard Wang:

[mediawiki/skins/Vector@master] Scroll active TOC links into view when past threshold

Reason:

Abandoning in favor of https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/769479

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

Thanks for the updated prototypes! The smooth scroll versions seem a good improvement.
Looking at version 2 the movement feels quite natural to me (I no longer have the impression of the jump feeling too large).

There seems to be an issue with scrolling subsections
Browser: Firefox/Chrome; Test article Singapore, state:

Screen Shot 2022-03-30 at 1.14.49 PM.png (1×1 px, 354 KB)

When I scroll to references it jumps to the top of the table of contents

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

https://patchdemo.wmflabs.org/wikis/0e7125720d/w/

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

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

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

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

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

https://patchdemo.wmflabs.org/wikis/69ad931262/w/

@Jdlrobson Is that issue from testing on the patchdemo or locally? Nevermind I can reproduce, and it should be fixed.

https://patchdemo.wmflabs.org/wikis/242a8fd7fe/wiki/Douglas_Adams?useskin=vector-2022&tableofcontents=true

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

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

https://patchdemo.wmflabs.org/wikis/3f19102148/w/

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

Change 769479 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Scroll active TOC links to midpoint when past threshold

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

@bwang I'm not seeing the bug anymore 👍

one more thing I meant to ask about — would it be possible to avoid triggering the auto-scroll in the situation where someone clicks on a ToC link? e.g. in this situation the ToC would not auto-scroll (until the person then scrolled a little bit):

Test Result - Beta

Status: ✅ PASS
Environment: Patch demo (769479,10)
OS: macOS Monterey
Browser: Chrome
Device: MBP
Emulated Device:NA

Test Artifact(s):

QA Steps

✅ AC1: The bolded section heading in the ToC should always be visible on screen

Screen Recording 2022-04-06 at 4.27.41 PM.mov.gif (461×899 px, 3 MB)

✅ AC2: The bolded section should scroll to the middle of the TOC when it reaches 100px from the bottom or top of the TOC

Screen Recording 2022-04-06 at 4.25.13 PM.mov.gif (576×1 px, 1 MB)

✅ AC3: The smooth scrolling transition should be off for users with the 'prefers-reduced-motion' setting

Screen Recording 2022-04-06 at 4.31.32 PM.mov.gif (576×1 px, 3 MB)

Edtadros subscribed.

Test Result - Prod

Status:: ❌ FAIL
Environment: enwiki
OS: macOS Monterey
Browser: Chrome
Device: MBP
Emulated Device:NA

Test Artifact(s):

QA Steps

❌ AC1: The bolded section heading in the ToC should always be visible on screen
I don't see any bolding

❌ AC2: The bolded section should scroll to the middle of the TOC when it reaches 100px from the bottom or top of the TOC
The TOC isn't scrolling

⬜ AC3: The smooth scrolling transition should be off for users with the 'prefers-reduced-motion' setting
Not tested because scrolling didn't work

https://en.wikipedia.org/wiki/Neil_Gaiman?tableofcontents=1

Screen Recording 2022-04-07 at 3.04.54 PM.mov.gif (702×596 px, 2 MB)

We'll have to test this in production next Thursday. There was a bug this week that broke this (fixed by https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/777444).

Test Result - Prod

Status:: ✅ PASS
Environment: enwiki
OS: macOS Monterey
Browser: Chrome
Device: MBP
Emulated Device:NA

Test Artifact(s):

QA Steps

✅ AC1: The bolded section heading in the ToC should always be visible on screen
✅ AC2: The bolded section should scroll to the middle of the TOC when it reaches 100px from the bottom or top of the TOC

Screen Recording 2022-04-16 at 5.29.47 PM.mov.gif (460×510 px, 2 MB)

✅ AC3: The smooth scrolling transition should be off for users with the 'prefers-reduced-motion' setting

Screen Recording 2022-04-16 at 5.32.22 PM.mov.gif (460×510 px, 3 MB)

Looks good, resolving. cc @alexhollender_WMF in case you want to take another look

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

https://patchdemo.wmflabs.org/wikis/242a8fd7fe/w/