Page MenuHomePhabricator

[Goal] Table of contents on narrow screens in vector-2022
Open, HighPublic

Authored By
alexhollender_WMF
Apr 21 2022, 7:50 PM
Referenced Files
F35146043: image.png
May 16 2022, 7:30 PM
F35071425: 2022-04-27_20-58.png
Apr 28 2022, 5:53 AM
F35071422: Zoom and browser.jpg
Apr 28 2022, 5:53 AM
F35071448: 2022-04-27_22-07.png
Apr 28 2022, 5:53 AM
F35071420: 2022-04-27_02-07.png
Apr 28 2022, 5:53 AM
F35071424: 2022-04-27_01-29.png
Apr 28 2022, 5:53 AM
F35071423: 2022-04-27_20-57.png
Apr 28 2022, 5:53 AM
F35070922: image.png
Apr 27 2022, 9:28 PM

Description

Description

Narrow screens present a layout challenge for the updated table of contents. Because we believe that the table of contents is useful for people with narrow screens, we would like to find a solution for how to provide it to them.

The challenge

Because the new table of contents is positioned to the side of the article, and is fixed in place, as the screen gets smaller the article eventually gets squished:

browser width: 850px
image.png (1×1 px, 807 KB)

Central question: at what width should we collapse/move the table of contents?


Possible solutions

We have thought of three general solutions so far (please feel free to add others):

1. Inline, after the lead section
This is a straightforward solution. The table of contents gets positioned inline for narrow screens. The main drawback here is that you cannot access the table of contents once you have scrolled down the page.

Screen Shot 2022-04-21 at 3.37.05 PM.png (839×851 px, 186 KB)

prototype: https://di-article-tools-da959.web.app/Bleach_(Nirvana_album)


2. Floating button + sidebar
There is a button to the side of the article, clicking on it opens the table of contents in a sidebar. The button is fixed position so it is always available. There are several options for the design and position of the button. One example is shown below.

Screen Shot 2022-04-21 at 3.40.49 PM.png (796×852 px, 269 KB)
Screen Shot 2022-04-21 at 3.40.59 PM.png (791×851 px, 250 KB)

prototype: https://di-toc-floating-button-sidebar.web.app/Bleach_(Nirvana_album)


3. Collapsed sections
Article sections are collapsed. The collapsed sections create a sort of pseudo-table of contents. The main drawback to this solution is that the information on the page is less discoverable because it's collapsed. You can no longer just scroll & read. Additionally you can't use "find in page". Note: this is what we do on the mobile website.

Screen Shot 2022-04-21 at 3.46.54 PM.png (747×850 px, 115 KB)

prototype: https://di-toc-collapsible-sections.web.app/Bleach_(Nirvana_album)


3b. Collapsible sections (but not collapsed)

Screen Shot 2022-04-27 at 10.23.57 AM.png (776×905 px, 211 KB)

4. No table of contents
Hide the table of contents for narrow screens

Related Objects

Event Timeline

I vote that collapsed sections should at least be an option. You can add a button to collapse/uncollapse all.

Noting that Bawl has a very similar looking collapse option for talk pages. In Bawl the collapse/uncollapse all is added to #firstHeading.

Bawl can now collapse sections on articles as well. @alexhollender_WMF is there some sort of standard or known convention for when the chevron points up or down? I have the opposite of what you have. I felt it made more sense for the arrow to point at where the content is, not where it goes, but if this is contrary to convention (I can't think of any good examples to look up) I may have to flip my chevrons.

ovasileva triaged this task as Medium priority.Apr 25 2022, 8:42 AM

Per Alex, we're waiting on data for this one so assigning to Olga.

@AlexisJazz collapsed sections is an option. can you expand on why you like it?

regarding the direction of the arrow, good question. I'm not sure there's a standard or best practice. From older web interfaces I'm familiar with this pattern:

image.png (826×836 px, 36 KB)

from there, an iteration such as flipping the closed section arrows to point up seems reasonable:

image.png (826×836 px, 35 KB)

however, against that logic, when looking at this in practice on mobile web (which I think is the main use case for this) the current pattern (which is the opposite of what is shown above) also feels right, because intuitively I feel like I can tap on them to expand them:

down.png (489×455 px, 35 KB)

versus the other two possibilities, which feel a bit less so:

up.png (475×463 px, 32 KB)
right.png (474×461 px, 32 KB)

Option 1: "Inline after the lead section" has some advantages.

  1. It resembles the previous state and allows the menu to go back to its previous narrower form (now that it doesn't have to match widths with the ToC which needs to be wider). This will probably leave people that like narrow windows largely unaffected.
  2. Yes, in that case, there's no floating ToC any more, but then if the window is that narrow, there's no room for one anyway.

Option 2: "Floating button with sidebar" - how accessible is this for people who say only use the keyboard for navigation? For narrow windows, which we're trying to address here, it creates a bit of a modality, where they're either in "TOC mode" or "reading mode" because you can't do both. Is this desirable?

ovasileva raised the priority of this task from Medium to High.Apr 26 2022, 10:38 AM

@AlexisJazz collapsed sections is an option. can you expand on why you like it?

Chances are this is like the "invert mouse/joystick/controller stick" option in many games. For some people it's one way, for others it's the other. I started a straw poll on enwiki.

As for what I like about it: it's the only option that is somewhat useful. I simply barely use the TOC.

  • If my screen is small an inline TOC just means more crap to scroll past, so option 1 is a bust.
  • If my screen is small there's no room for a sidebar so option 2 is a bust. Also not a big fan of elements with a <s>fixed</s> sticky position. Fixed can be annoying to, but sticky AAAAARGH.
  • Which leaves option 3. It doesn't scroll when you expand a section, so there's no disorientation. And the scrollbar is much smaller. But you do need a collapse/expand all button.

@AlexisJazz thanks for that comment. Also thanks for starting the straw poll — curious what people think.

@TheDJ if you have a moment could you add some thoughts here. Particularly curious about why you make your screen narrow, and whether or not the table of contents is useful to you when your screen is narrow.

I'm a bit confused as to why the ToC/sidebar has suddenly become so large. The size used in the prototypes seems much more natural on my screen (like https://en-toc.wmcloud.org/wiki/Moon). Now the content of the page is aligned at the right side of the screen, while the sidebar/ToC uses a lot of space on the left, also due to imo unnecessarily large margins. I am aware that the overall design will be improved at the end, but the proportions right now don't seem to make sense to me. And if I make my browser window smaller (which happens automatically whenever I use the browser tools to look at the HTML), in my eyes it is very weird that only the page content but not the sidebar becomes narrow. Also, I think this behaviour interferes with responsive design based on screen width: if I want my templates to react to the available space, I now have to calculate the width of the content instead of the full screen for Vector 2022 (so no more 720px breakpoints).

I'm a bit confused as to why the ToC/sidebar has suddenly become so large.

Can you please include a screenshot, as well as noting whether or not your browser window is zoomed in at all? What you see in production should match the prototype...

Well, the width of the sidebar is given in rem, as far as I can see, so there must have been a change in that (I compare with the previous state, as I had been testing the new ToC for a while already). I do not use any zoom for my browser window. The random example is from https://de.wikipedia.org/wiki/Kalifornischer_Wacholder.

2022-04-26 (2).png (915×1 px, 809 KB)

Also, I think this behaviour interferes with responsive design based on screen width: if I want my templates to react to the available space, I now have to calculate the width of the content instead of the full screen for Vector 2022 (so no more 720px breakpoints).

This is the big flaw with media queries and why many people have been pushing for container queries:
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Container_Queries

This is not a new problem, we already had this issue as people write responsive rules with legacy Vector in mind which work differently on Minerva. Unfortunately, the only way to support all skins is to have different breakpoints for different skins (I remember hitting this problem when working on the English Wikipedia main page)

Also, I think this behaviour interferes with responsive design based on screen width: if I want my templates to react to the available space, I now have to calculate the width of the content instead of the full screen for Vector 2022 (so no more 720px breakpoints).

This is the big flaw with media queries and why many people have been pushing for container queries:
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Container_Queries

This is not a new problem, we already had this issue as people write responsive rules with legacy Vector in mind which work differently on Minerva. Unfortunately, the only way to support all skins is to have different breakpoints for different skins (I remember hitting this problem when working on the English Wikipedia main page)

Or find a reasonable good enough for everyone, which is actually what the en.wp main page does. Most styles are like that on en at least.

Container queries will be nice but will only help a limited subset since a) css-sanitizer isn't really maintained actively, and b) it implements new properties and values more to what is fully standardized and less to what browsers support, and c) we still have to care about older browsers.

hi @alexhollender_WMF, fwiw I'm partial to showing the two options (2 or 3) that enables some level of navigation without having to find the ToC again by scrolling to the very top.
Of the two, Option 2 is better at orienting the user as to where they are in the article (which I think was one of the findings from ToC user research?), and also closer to the non-narrow Desktop ToC design so in that respect could be less jarring for the case of when people are changing the screen to narrow on desktop.
However, I do find the position of the ToC menu button is a bit awkward/in no man's land, so perhaps earlier explorations you made where it was part of a sticker header (with the section header?) could be explored? Another earlier iteration that I was partial to was the literal "rail" with the dots (https://di-toc-floating.web.app/Vampire) which was good at satisfying the orientation aspect, but perhaps that is less accessible and a bit fussy in practice.

@TheDJ if you have a moment could you add some thoughts here. Particularly curious about why you make your screen narrow, and whether or not the table of contents is useful to you when your screen is narrow.

Ok, i make my screen narrow because I have a 27" screen. Because of that i often split the screen in 3rds or halves and everything in between that. Before the ToC I could make the page readable again by hiding the sidebar, but the ToC cannot be hidden. Partially this is a content problem as well, as infoboxes don't adapt to dimensions either, but it was a considerable change from before and also one that wasn't nearly as egregious as in prototype testing (the ToC there seemed much narrower ?)

I do like having a ToC, but it is secondary to content.

Screenshot 2022-04-27 at 14.55.02.png (776×3 px, 582 KB)

This screenshot clearly shows that the width of the ToC in production is wider than in the prototype. In the prototype the left side of the article text could start around 270px (see top ruler). In the production setup it starts no earlier than at 350px. It might not look like much at face value, but it's a 30% increase. That's the difference between a 22em and a 30em infobox. That eats into available article space a lot.

Part of this seems to be that the prototype actually has a different overall margin of the page. The left margin in production is almost three times that of the prototype i think?

Exactly, thanks for the direct comparison! I really don’t understand what the reason for the new width and the unnecessary margins is. When I had first seen it on the beta cluster, I thought it was just a temporary design problem.

This is not a new problem, we already had this issue as people write responsive rules with legacy Vector in mind which work differently on Minerva. Unfortunately, the only way to support all skins is to have different breakpoints for different skins (I remember hitting this problem when working on the English Wikipedia main page)

There is a way around this of course:

  1. Hard code the breakpoint for each skin for all css that needs to adapt
  2. Or probably easier use classes for different content layouts, then use media queries and https://developer.mozilla.org/en-US/docs/Web/API/Window/matchMedia to apply those classes to the content. (layout jump possible though)

@TheDJ thanks for the comparison. I think with a few small changes we can get the space back...the screenshots below are from a 1120px wide browser window:

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

updated prototype: https://di-toc-with-menu-above.web.app/Butterfly
more info in T307004

I'm in a similar situation to TheDJ. I constantly used tiled windows, both on a 14" laptop screen, and a 24" desktop screen. This results in windows that are between ~750px to ~1200px wide.

Overall, I think it would be helpful to re-evaluate the quantity of margin and padding for various elements, and [waves hands magically!] make them responsive. I.e. At steadily smaller window sizes, it would be great if the margins and padding steadily reduced to almost zero.

[Caveat: I don't know how much browser-performance load this adds? E.g. I've got 8 copies of w:en:Moon open (plus other stuff) and everything is getting sluggish when I resize any of them... I don't know if that's related though.]

E.g. I've been using these 2 custom CSS files, to try to 'fix' it for myself. These were working well for the last few months, at all screen sizes, in both vector and vector-2022, and with the vector-2022 sidebar expanded and collapsed.

It even worked well at sub-700px window-widths, as I previously had the #mw-panel {position: absolute !important} invoked 100% of the time, so the uncollapsed sidebar just became an overlay when I needed it.

After the recent ToC change, the main 2 things that frustrate me sizing-wise (when I'm using my custom CSS) are:

  • The sticky header not activating at smaller window sizes
  • the ToC not being accessible at smaller window sizes.

TLDR:
I believe it is possible and reasonable (and desirable!) to have the ToC show up as a sidebar at sub-1000px widths, even down to 750px.
Below that size, I'd prefer either Option 1 or Option 2.
I'd strongly dislike Option 3 (collapsing sections) per my previous comments and essay/notes.

Examples:
Vector vs Vector-2022 (without skin-customization)

2022-04-27_02-07.png (944×962 px, 294 KB)
2022-04-27_01-29.png (942×1 px, 608 KB)

My normal setup on desktop (left window is ~900px wide)

Zoom and browser.jpg (977×1 px, 362 KB)

Before/After my tweaks

before:
2022-04-27_20-58.png (939×1 px, 579 KB)
after:
2022-04-27_20-57.png (944×1 px, 524 KB)
before/after:
2022-04-27_22-07.png (1×1 px, 547 KB)

Just wanted to leave a comment with the current status from the team's side

  1. We have increased the threshold for which the ToC currently hides to 1000px T306904: [ToC] Increase threshold for ToC collapsing to 1000px . This is a temporary fix until we decide what the optimum solution would be for narrow screens, the conversation around which will continue in this task
  2. We are beginning the work on reducing the margins for screens between 1000px - 1200px, as per @alexhollender_WMF' s proposal above. We will track this in T307004: Fix spacing/margins for screens between 1000 and 1200 px and will probably have the implementation ready within the next few days
  3. By the end of this week/early next week we hope to have clear next steps on our preference of the options within this task, which will provide a more permanent state for narrow screens.

Personally, I am leaning towards option 2 as it seems the most technically straightforward and it allows us to potentially introduce collapsing of the ToC throughout the experience. That said, as @alexhollender_WMF has pointed out, it might introduce some awkwardness when used alongside the main menu, as it would introduce a second collapsible menu with slightly different functionality

Option 3 (collapsible sections) doesn't exclude 1 (in-line ToC) or 2 (pop-up ToC). Minerva on tablet or phone-landscape widths has both 1+3.

iOS app uses variations of 2. On phone it's a slide-over and on tablet a slide-beside the content, both are full-height. But the mobile app has both a top and bottom bar to activate functions from.

We have site-nav, site-tools, page-tools, and page-toc, all of which we might want to be pop-over or pinnable. (Not to mention user functions.) I note Olga and Alex have also commented about having two collapsible menus on the left. How about some kind of mode selector across the top of the left and right side-bars? The side-bars themselves could be pop-up or fixed depending on viewport size and user pinning.

(Choosing between left and right for different items may be a separate discussion, but I'm picturing something where the left and right panels are containers, and the content sub-panels – ToC, nav, tools – each have a move-to-other-side option.)

Finally, I want to point out that floating/sticky elements on iOS are a problem. I have to drag-scroll the page some indeterminate amount to get the VE toolbar back after it scrolls away. And I managed to dissolve the adhesive from the sticky header in the Desktop Improvements Prototype 4. There mightn't be much you can do about that as a platform limitation, but I do hope we don't come to a point where Vector 2022 is not expected to function on mobile devices.

@XanonymusX @TheDJ @Quiddity @AlexisJazz two updates:

  1. we've reduced the width of the table of contents and the surrounding space for screens below 1200px wide. will be in production soon, in the meantime you can check out: https://patchdemo.wmflabs.org/wikis/66a7113371/wiki/Paris?useskin=vector-2022&tableofcontents=1
  1. we've got a prototype that makes the table of contents collapsible at any width, and also makes it available on smaller screens when you're scrolled down on the page (similar to option 2 in the task description), you can check that out here: https://di-collapsible-menus.web.app/Brown_bear

Thanks for mentioning this discussion @Jdlrobson. After the first shock for the change (the usual one) I have noted that it is difficult to navigate the article because we can't see the ToC after we have gone down. I proposed in T308032 to double the ToC, but yes, it may be tricky. We have to think in a way to show the ToC in the first sight, because [I DON'T HAVE DIRECT PROOF OF THIS] people normally is going directly to the section they want to read, and navigating down to find the ToC makes it more difficult.

The biggest UI problem I'm seeing with the TOC on vector-2022 is on narrower screens, there is a control to collapse the left sidebar, which should free up space - except all of that verticle space is still consumed by the TOC (or empty space for the TOC). Perhaps if it collapsed with the sidebar?

Xaosflux renamed this task from [ToC] Table of contents on narrow screens to [ToC] Table of contents on narrow screens in vector-2022.May 12 2022, 2:09 PM

For the "Option 1" (Put the TOC inline) is there an existing css/js that can make this happen, or would it require development?

The biggest UI problem I'm seeing with the TOC on vector-2022 is on narrower screens, there is a control to collapse the left sidebar, which should free up space - except all of that verticle space is still consumed by the TOC (or empty space for the TOC). Perhaps if it collapsed with the sidebar?

have you seen these tasks?

Something to remember: People using Vector on "narrow screens" are likely to be mobile users who dislike the (Minerva) mobile site. So a "solution" that makes Vector more like Minerva (e.g. collapsed sections) is exactly the wrong one. That would leave no escape, except logging in from every device, and every private tab, just to read a page.

Something to remember: People using Vector on "narrow screens" are likely to be mobile users who dislike the (Minerva) mobile site.

@suffusion_of_yellow , no, that's not true. Narrow screen doesn't mean mobile screen. Vector (intentionally) doesn't define a viewport, so users there will never get a narrow screen. Users on a mobile device will continue to see the desktop site with a desktop viewport zoomed out like so:

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

NOTE: We have decided to move forward with a modified version of solution #2. To view the prototype please visit https://di-collapsible-menus.web.app/Brown_bear and make your screen 1000px wide (or less)

@suffusion_of_yellow , no, that's not true. Narrow screen doesn't mean mobile screen. Vector (intentionally) doesn't define a viewport, so users there will never get a narrow screen. Users on a mobile device will continue to see the desktop site with a desktop viewport zoomed out like so:

I said "likely" not "certain". And I don't see a TOC on my phone (360x720, pixel ratio 3.0) in Vector-2022. My general point is that if the user scrolled down and clicked on that "desktop site" link, there must be something about Minerva that they don't like. So, as a general principle, y'all should try to make the skins not like each other. I am (now) pleased to see that you're not going to collapse the sections, for example.

ovasileva renamed this task from [ToC] Table of contents on narrow screens in vector-2022 to [Goal] Table of contents on narrow screens in vector-2022.May 18 2022, 2:53 PM