Page MenuHomePhabricator

[ToC] Collapse article sections at small resolutions
Closed, DeclinedPublic

Description

Description

The new table of contents will display, persistently, to the side of the article. As the width of the screen gets smaller there is less and less space for the article content, and eventually it becomes difficult to read (especially when there is content, such as an image or an infobox, floated on the opposite side of the article text). For example:

Screen Shot 2022-01-10 at 1.01.23 PM.png (1×1 px, 484 KB)

In order to preserve the readability of the article we need a solution for screen widths below ~1000px.

Design

Following the example set by the mobile website, for screen widths below 1000px we will collapse the article sections, and they will therefore become a pseudo-ToC. With this we can remove the ToC to the side of the article, giving the space back to the article content. Link to prototype.

screenshotvideo
Screen Shot 2022-01-10 at 1.06.27 PM.png (1×1 px, 487 KB)

One important feature of this solution is that the section title sticks to the top of the screen. This makes the section easy to collapse which allows the person to return to the pseudo-ToC. Currently this is a little off in the prototype because when you collapse a section using the sticky section header, you do not end up in the correct scroll position (with the relevant section heading in view). Note: the sticky header will be hidden at this resolution, so there should not be a conflict between the sticky header and the sticky section headings.

Notes

  • This solution is similar to what the editing team (cc @iamjessklein) has been exploring for Talk pages. There may be an opportunity to combine our efforts.
  • We considered two other solutions here:
    1. displaying the ToC inline (i.e. in its current position) and adding a ToC dropdown within a sticky header that appears once you've scrolled passed the inline ToC (link to prototype)
      Screen Shot 2022-01-10 at 1.26.16 PM.png (1×1 px, 764 KB)
    2. displaying the ToC inline (i.e. in its current position) and adding a floating ToC button & drawer that appears once you've scrolled passed the inline ToC (link to prototype)
      Screen Shot 2022-01-10 at 1.30.23 PM.png (1×1 px, 1 MB)

Acceptance criteria

  • The table of contents should remain hidden at low resolutions
  • Sections should be collapsible
  • Default state of sections is ______

Related Objects

Event Timeline

alexhollender_WMF renamed this task from [ToC] hide ToC and collapse sections at small resolutions to [ToC] hide ToC and collapse article sections at small resolutions.Jan 10 2022, 5:23 PM
alexhollender_WMF created this task.

@ovasileva this may or may not be possible. We would need to talk to the parsing team, since that content comes from the parser. We've explored collapsing via the standard HTML previously and it isn't possible, which is why MobileFrontend formats the HTML to change this.

Further analysis of this ticket is not possible at this point without a meeting setup so this should probably go back to the backlog.

Jdlrobson reassigned this task from Edtadros to ovasileva.
Jdlrobson added a subscriber: Edtadros.

I think there are three components to this:

  1. hiding the TOC sidebar when the screen is narrow
  2. Sticking the current heading to the top of the screen when the screen is narrow
  3. Collapsing sections when the screen is narrow

I'd suggest breaking up the task into these three components, because the dependencies and difficulties are different for each:

  1. Hiding the TOC sidebar when the screen is narrow is pretty straightforward.
  2. Sticking the current heading to the top of the screen *ought* to be straightforward to do in JS and CSS. It's possible that some other wrapper elements might be needed, because the header tag and the various elements which "live with" the header (like section edit) are not always well-contained. So we can have a discussion about that if changes are needed.
  3. Collapsing sections when the screen is narrow is an old and large task, which will be possible within a year-ish (we hope), but can't easily be sped up. Some history: T8104, T179715, T114072, T55784.

(Also, it seems like automatically collapsing sections might lead to some nontrivial interactions eg, when a desktop user resizes their screen, or printability of the page when sections are collapsed, so it's worth thinking about that task separately.)

@ovasileva and I talked to @cscott. We won't be able to do this as part of our existing table of contents deliverable.

It seems that in 1.39 (October 2022) we might be able to experiment with this as part of Desktop Improvements (Vector 2022) by enabling it on certain wikis but there's nothing we can do about this on the short term. The downside of enabling Parsoid on certain wikis is that there are likely some issues with certain pages using certain templates.

Next steps: Olga to explore if some kind of pilot is worthwhile in our roadmap given that timeline.

an additional, alternative solution that @ovasileva and I discussed last week: for smaller screens we render the ToC inline (as it is currently), and don't offer any kind of additional ToC. we could perhaps offer a simple "Back to table of contents" or "Back to top" button.

FWIW lots of our mobile users have lamented the absence of a table of contents, so I think it's worth considering some kind of experience for mobile users other than collapsed sections. Worth checking out T147026 and T97581.

Change 771745 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] Table of contents should be hidden at lower resolutions

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

Change 771746 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] Add section collapsing to Vector

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

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

https://patchdemo.wmflabs.org/wikis/6b2351cd6a/w/

While analyzing T300975 I didn't find a solution I was satisfied with so I took a step back and thought "is there anyway we can do section collapsing without a change to the parser".

There is one way, but we need to think through it carefully and test pretty vigorously, particularly with an eye for performance. We could collapse all elements between headings to get the desired effect. This works on the basis that the parser always wraps content in elements. I've not 100% confirmed this, but my testing seems to suggest this is the case.

Take a look at the patch demo and patch and tell me if I'm crazy during estimation. If so I'll go back to the drawing board.
https://patchdemo.wmflabs.org/wikis/aa9fc17fc8/wiki/Spain?useskin=vector-2022

Change 771745 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Table of contents should be hidden at lower resolutions

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

Above merged patch takes care of hiding the new table of contents at low resolutions so remaining work is collapse article sections at small resolutions

Change 771746 abandoned by Jdlrobson:

[mediawiki/skins/Vector@master] Add section collapsing to Vector

Reason:

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

Personally, I have many long-standing thoughts about "collapsing" as a UX feature. I grok it is necessary or useful in many contexts, but I think the downsides are very important to keep in mind and often forgotten.
There are many risks and drawbacks, including accessibility, content-use, and content-maintenance. I've tried to summarize them concisely at https://www.mediawiki.org/wiki/User:Quiddity/Collapsing_and_hiding#Risks_and_drawbacks
In a nutshell: Knowledge that is harder to access, will be accessed less.

Jdlrobson renamed this task from [ToC] hide ToC and collapse article sections at small resolutions to [ToC] Collapse article sections at small resolutions.Mar 28 2022, 5:29 PM
Jdlrobson updated the task description. (Show Details)

@ovasileva I'm boldly moving this out of the board for now pending data around usage of the table of contents which we should have by end of this week.

@alexhollender_WMF - going to go ahead and close this ticket since we've moved most of the conversation to T306838: [API] New Vector search should not load wastefully large thumbnails

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

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