Reading/Web/Desktop Improvements/Features/Table of contents

A main goal of the Desktop Improvements project is to make frequently used tools more accessible to readers and editors. One of the most crucial of these tools is the table of contents (ToC), which is responsible for providing both contextual insight and navigation.

Currently, the ToC is only available at the top of the page, limiting its usefulness. We plan to make it a persistent element, available throughout the page. Our goal is to make it easier for readers and editors to reach the ToC, gain context, and navigate throughout the page without needing to scroll all the way to the top.

Background and Goals
A big focus of the Desktop Improvements project is to make our workflows and navigation clearer and easier to use. This has so far included work on a collapsible sidebar, introducing a sticky header, and now, our current focus - a new ToC. Currently:


 * The current ToC is available only at the top of the page. This makes it difficult to regain context and navigate within the page without having to scroll all the way up
 * For pages with a long lead/intro section, the ToC is not visible until you scroll down a bit
 * Users use the ToC to create a mental model of the page. This is similar to the role of the introduction to the page.  Users learn what the page contains, how long may be, what parts may be the longest, etc.  This becomes lost without the ability to reference the ToC more frequently
 * The ToC creates a lot of unused space on the page that could be used for displaying content and other functionality

The new, persistent table of contents will make it easier for readers to


 * Understand the context of the page
 * Navigate to different parts of the page throughout their reading experience, without having to scroll all the way back to the top of the page every time they want to access the table of contents

Use Cases

 * As a reader or editor, I want the ability to gain context (content and structure) about the page I am about to read
 * As a reader or editor, I want the ability to reference the next few sections in the page at any location in the page so that I can choose what to read next
 * As a reader or editor, I want the ability know how many sections a page has without having to scroll all the way up

Feature description and requirements
The table of contents will appear persistently on one side of the page. This table of contents will contain all sections and sub-sections available in previous versions of the ToC.

The ToC will contain the following functionality:


 * Collapsible sub-sections - for users that only want to view the highest level of section heading
 * Section bolding - the section currently on the page will be displayed as bold. Users will be able to identify where on the page they are currently located by noting the bolding within the ToC
 * Navigation - selecting a section within the table of contents will navigate to the appropriate section within the page
 * For screen widths smaller than 1000px, the ToC will collapse and the section titles will be used as a ToC



Prototype
General ToC functionality: https://en-toc.wmcloud.org/wiki/Moon

Collapsible section functionality: https://di-toc-collapsible-sections.web.app/Aretha_Franklin

User Testing with Readers and Editors
We performed user testing of the table of contents with readers and editors in three locations (Argentina, Ghana, Indonedia) and languages. Test participants were asked to interact with different versions of a persistent table of contents and to give their feedback on their preferred version. The test also included an open study of the way readers and editors perceived and used the table of contents. All users found the table of contents to be essential to the reading experience of Wikipedia for both navigational purposes as well as for setting the context for the page.

Main observations:
 * Testers prioritized persistent access - the best-performing prototype was the persistent one across all tests
 * Testers prioritized having more information - prototypes that contained all sections and subsections performed better
 * Testers 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
 * Testers liked getting a sense of location within the page and noted that additions like bolding the title or the section helped with their orientation

The results of the test were used to select the best performing of our prototypes and iterate to better fit the needs of the participants. See the full results of this test.

Prototype testing with editors
In December 2021, we performed prototype testing with logged-in users across 30 wikis. The test was designed to gather feedback on the usability and functionality of the table of contents.

As with most changes to the interface, moving the table of contents comes with some challenges. The main challenge here is: where should we put the Main menu and Article tools, which are currently located in the space that we’re moving the table of contents to?

Our short-term solution
As a short term solution the entire sidebar (including the Main menu and Article tools) will remain available in its current location, and will remain collapsible. When it is open it will push the table of contents down the page. Here is a screen recording of how it will work:

[screen recording]

We don’t think this is the optimal solution, it is more like a quick fix that will allow us to release the table of contents and keep moving forward. And we understand how this might feel like a step backwards to some, because the table of contents is now further down the page than it was previously. But don’t worry — we too think we can do better. Below is our proposal.

Our proposal
A few things we learned from recent community feedback, and from data collection, are informing our proposal:


 * 1) Most editors like the new location of the table of contents
 * 2) For some editors it is important to have article tools (e.g. What links here, Related changes, Wikidata item, etc.) available as soon as they land on a page
 * 3) Most of the global navigation items in the main menu (e.g. Current events, Contents, etc.) are used infrequently
 * 4) Some editors have large screens and would like the interface to make better use of the space on the far side of the article

Additionally, something that we’ve been trying to accomplish throughout this project is moving things into logical places. We think it makes sense for all of the article tools to be in one area, rather than the current situation where some of them are in the sidebar and others are in the article toolbar above the article. There are two main parts of our proposal:


 * 1) Splitting the sidebar into two menus: a main menu with global links, and an article tools menu with article-specific links
 * 2) Moving the article tools to the far side of the article, so that they are near the other article tools (History, Edit, Move, etc.)

Quantitative testing
We will be performing an A/B test of the functionality of the current versus new version of the table of contents.

Main Questions:
 * 1) Is the new table of contents is used more frequently than the previous table of contents
 * 2) Does the new table of contents reduce the need to scroll back to the top of the page
 * 3) Does the new table of contents decrease the time people spend scrolling/scrolling quickly (if possible)
 * 4) How does the new table of contents affect the time spent on a page