The table of contents is intentionally disabled on page views in mobile so this request might be "invalid by design". :-/

@Aklapper Yes, I certanily didn't think it was done accidentally ;). That said, it isn't totally true that the ToC is disabled in mobile, it's just that it disappears as part of the responsive design when the size of the page gets too small. As I said, it's understandable when the headers are collapsed automatically (would look somewhat redundant), but with Javascript disabled, it's actually quite counter-productive.

I think that if Javascript were used to disable the ToC, then it would fall back gracefully, but if that is not acceptable for some reason, there are the other two options.

I've been working on a solution to this problem. Basically the ToC will be showed on all types of devices (with or without support for JS). Then I progressively enhance it for devices that support JS. I create a floating button that sits at the bottom right of the page. When the user clicks on that button an overlay will open with the table of contents (the original ToC will still be present at the top of the page). I also got rid of section toggling as the above solution makes it redundant. Here is my patch: https://gerrit.wikimedia.org/r/#/c/313628/
(first in the series of 3 - the others are linked in gerrit).

@bmansurov I'm a bit hard-pressed to endorse a solution with a floating overlay, since I personally hate that sort of thing and I'd much rather see collapsable sections than a floating overlay, but I suppose it doesn't matter too much since I'm disabling Javascript anyway.

That said, I would say that if you are going that route, it would be good to be aware that <noscript> tags may not reliably provide fallback code (see: https://phabricator.wikimedia.org/T147027). If you're going to create a floating ToC, it should definitely be done such that the ToC is dynamically disabled by Javascript, not dynamically enabled with a fallback. I'm not quite sure how to see the full diff, but I don't see any <noscript> tags in the diff, so I assume that's the strategy you used.

@0x0077BE, just to be clear - the button that opens the ToC overlay is floating, the ToC overlay itself takes up the whole screen similar to how we show languages, categories, search, etc.

So the way it works is that, all pages get a ToC similar to the desktop site. And pages that have JS will get a button in addition to the existing ToC on the top of the page. The user doesn't even have to see the ToC overlay if they wish to do so. They can always scroll to the top of the page to see it.

I agree that the table of contents would be very useful. Collapsed headers are not sufficient on most articles (in a way, they even make navigation more difficult: if headers were not collapsed, at least you could search a word into the page and find what you are looking for without opening all headers one by one).

Of course the TOC should not appear by default, so there should be a button or something to show it. The solution described above by @bmansurov looked very promising.

I ran into this at Wikisource: I was about to complain that there is no TOC on the Scriptorium (the central Project chat page) which made it incredibly hard to navigate on a mobile. In attempting to screenshot it with a browser in mobile mode, I discovered that there actually is a TOC, it's just hidden below 720px (i.e. on any phone):

.toc {
 display:none;
...
}

@media screen and (min-width:720px) {
 .toc {
  display:table
 }
 .toc .toctitle {
  visibility:visible
 }
}

I'm not sure why it was decided that phones are least deserving of a TOC, but enWS now has the following hack in Mediawiki:Mobile.css to override the Minerva defaults (right below the hack to address T236608):

/* In what universe does it make sense to HIDE the TOC on smaller screens? 
 * By default in Minerva, TOCs are hidden under 768px, which completely torpedos
 * the ability to navigate a long page on a phone.
 * So make that behaviour the default always. */
.toc {
	display:table
}
.toc .toctitle {
	visibility:visible
}

The TOC is collapsed by default anyway, so the UX is pretty much as you'd expect:

On load (showing why a page with multiple top-level sections is a nightmare to navigate when sections are collapsed by default):

After opening:

Change 731296 had a related patch set uploaded (by Inductiveload; author: Inductiveload):

[mediawiki/skins/MinervaNeue@master] Make TOCs visible on all mobile screens

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

Got some more context here.

I'm not sure why it was decided that phones are least deserving of a TOC

The mobile site does not show the table of contents as the collapsed sections are the table of contents. This design is based on data relating to an A/B test which we ran collapsing/expanding sections by default to see how users interacted with the mobile site. It showed that which shows the site is more intuitive and effective to the majority of users of the site in current form. I don't have time to dig out the details here right now but it's on meta wikimedia somewhere if you want to hunt for it.

That aside, we recognize understanding where in the document you are is useful. For that reason, a new table of contents is currently in the works (https://phabricator.wikimedia.org/T273473), based on the https://www.mediawiki.org/wiki/Reading/Web/Projects/In-page_Navigation#Recommendation here. We're be doing this in desktop first, with the plan to consolidate these later. Revealing it as you've done in the patch doesn't really help towards this goal.

The maintaining team agrees your change would help users without JavaScript, so if you wanted to scope the change to pages with the client-nojs class on the body tag that would be useful, but otherwise we believe the collapsed sections are more than sufficient.

The UX experience has got a little room for improvement if you do that. For example the table of contents is not full width:

enWS now has the following hack in Mediawiki:Mobile.css to override the Minerva defaults (right below the hack to address T236608):

Note I recommend you don't do this. Mobile.css loads late via JavaScript, so this will result in an annoying shift of content for many users on slow connections, not too dissimilar from how banners appear and shift your page, meaning you'll likely annoying a lot of users with this change. If you simulate a slow connection in your web browser it should be quite evident.
You are free to use user CSS to reveal this in the meantime for your own needs but I don't think it's fair for you to make a decision on behalf of everyone without the data to back that up.

@alexhollender could you create a new task for the work we plan to do with the table of contents so it's clearer what our roadmap is here e.g. when and what can be expected. Perhaps @Inductiveload is interested in helping us get there faster.

Visit https://en.wikisource.org/wiki/Wikisource:Scriptorium on a phone, find and edit a section and let me know how that goes for you.

In T147026#7438886, @Inductiveload wrote:

Visit https://en.wikisource.org/wiki/Wikisource:Scriptorium on a phone, find and edit a section and let me know how that goes for you.

If you are asking for the table of contents on the Wikisource (project namespace) that seems like an understandable and reasonable request as someone who has experienced challenges with editing this page, but I don't think we should solve that by introducing the table of contents on all articles.

The WS portal NS is another one which commonly has deeply (i.e. greater than one level) nested levels, as well as the Help. We do not, generally, have any wiki ToCs in mainspace, because most mainspace pages are a single "section" each.

If the research you are referring to is this: https://meta.wikimedia.org/wiki/Research:Collapsed_vs_uncollapsed_section_view_on_mobile_web, then I do not see how that supports a conclusion that people do not prefer a ToC, since neither arm of the A/B contained a ToC at all. If anything (and using time-on-page does not really allow the drawing of this conclusion), it shows people prefer having the collapsed-section pseudo-TOC over no ToC at all (which is a pretty obvious conclusion if you ask me, because some kind of ToC is more useful than no kind of ToC).

Moreover, the research linked to by the stub new-ToC issue T273473 (https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Repository/Sticky_Header_and_Table_of_Contents_User_Testing) says that:

Participants prioritized persistent access - the best-performing prototype was the persistent one across all tests
Participants prioritized having more information - prototypes that contained all sections and subsections performed better
Participants did not want the ToC to overlap the content, even in the cases where it was supplementary to the main toc at the top of the page
Participants liked getting a sense of location within the article and noted that additions like bolding the title or the section helped with their orientation

@Inductiveload thanks for raising this. I am having a little bit of trouble trying to follow what is being proposed here and why. I think it could be helpful to separate out the various situations and solutions in the task description. So far I understand:

1. When js is not enabled, all pages could benefit from a table of contents, because the sections are uncollapsed, and therefore don't form a pseudo-TOC

What are the other specific situations and reasoning for having an additional toc?

@alexhollender As I said in both my comments just above, a very good example is the Wikisource Scriptorium: https://en.wikisource.org/wiki/Wikisource:Scriptorium. It's organised into multiple sections, with a subsection for each topic "thread". The entire page is archived regularly, but it's currently 85,000 words long (longer than Harry Potter and the Philosopher's Stone).

There is no way to find a topic without opening the relevant section and then spam-scrolling until you find the right sub-section. It's a complete nightmare to use. You can't just use find in page, the sections are collapsed.

This goes for reading Wikipedia as well, by the way. Try finding "American aviation" in the https://en.wikipedia.org/wiki/United_States article. Where is it? You won't have any idea until you guess that it's under "Economy" and then scroll down about 10 screenfuls to Transportation, then it's somewhere in there. You can't even "Find in Page" until you've expanded the right section!

The same goes for most user pages in Wiki mode (the one that is actually functional if you want to, say, amend a comment): because the sections that are expanded seem to be "sticky" on page reload, you can't actually "see" this allegedly A/B tested pseudo-TOC of collapsed sections if you've previously expanded any section except the very last. So you're back to spam-scrolling, looking for the section you think might be on the page.

Try it yourself: go to https://en.wikisource.org/wiki/Wikisource:Scriptorium on a phone (browser phone mode is cheating unless you do not touch the mouse or keyboard) and try to comment on the section about T.S. Eliot without using the ToC.

Also, since the Scriptorium, allied discussion spaces and user pages are the about the only part of WS that are even vaguely possible to edit in any meaningful sense due a near-complete lack of mobile editing capabilities, having these exact page rendered basically non-navigable is a very strange choice to me.

@Inductiveload thank you for clarifying. To summarize:

1. When js is not enabled, all pages could benefit from a table of contents, because the sections are uncollapsed, and therefore don't form a pseudo-TOC
2. It is not possible with the current pseudo-toc solution, to easily navigate to sub-sections of articles. This is particularly an issue on certain types of discussion pages (e.g. try finding "Author:T. S. Eliot‎ vs Author:Thomas Stearns Eliot" in https://en.m.wikisource.org/wiki/Wikisource:Scriptorium), and on articles with many large sections & sub-sections (e.g. try finding "American aviation" in https://en.wikipedia.org/wiki/United_States)

@alexhollender Yes, that's a fair summary. Also

• It is not possible to get any overview (whether or not you want to navigate to it, you do want to know if it exists) of the content of any page which has either:
  • any headings below the top level (i.e. beyond what is in the pseudo-TOC), and/or,
  • any sections that are "stickily expanded" when the page loads, and/or,
  • The user has "expand all sections" enabled in their mobile settings

Also instead of A/B testing based on the highly suspect metric of time-on-page as a proxy of "success", I suggest a hallway test: choose the United States article, with default settings, take a phone into the hallway, hand it to someone who is not an engineer and ask them to tell you how many miles of road there are in the US.

Furthermore, if the question is "should we show the ToC or not?" I do suggest that at least one of the arms of the test does actually contain the ToC in question.

Thanks Inductiveload for explaining this issue so clearly. I share everything you said.

It does not apply only to large articles, but also to mid-size articles, and to most non-stub articles. And I fail to understand why the excellent solution you provided (a simple "Contents" link, since the TOC would be collapsed by default) would cause any nuisance to anybody. The fact that Mobile.css is loaded late is not sufficient to remove the possibility to access to sub-sections of articles.

Thanks Seudo!

The fact that Mobile.css is loaded late is not sufficient to remove the possibility to access to sub-sections of articles.

I agree, but also this only matters because the Mobile.css is used at enWS to undo the built-in TOC hiding mechanism. If you just don't hide the TOC in the first place (e.g. patch 731296), there is no such issue: the TOC is there immediately on page load.

Change 731296 abandoned by Jdlrobson:

[mediawiki/skins/MinervaNeue@master] Make TOCs visible on all mobile screens

Reason:

Not going to happen like this. Let's continue on Phabricator to work out a better general solution.

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