Poor topic navigation with new 'Show more' ToC layout

[guardrex]

Is your feature request related to a problem? Please describe.

Well, I think it's a problem, but I'll file it as a feature reversion request.

You recently implemented a new "feature" that's a pain in the keester for the sidebar topic ToC, where it now loads collapsed ...

This is horribad for finding known sections in topics. Now, I must click an extra time almost every time I open a topic to get to content that I know is present ...

Describe the solution you'd like

PLEASE REVERT this choice back to displaying ALL of the topic's sections —OR— make it so that my browser remembers to leave the topic ToC open every time I visit any MS doc set.

Describe alternatives you've considered

Shooting myself!? 👦🔫😆 Seriously tho, there's no alternative. You'll force me, and thousands of other devs, to click a gazillion more times in docs to discover and reach content with this new layout.

🇺🇦

[ascott18]

This is absolutely dreadful. What on earth were you guys thinking? The point of a table of contents is to provide a quick overview of the content of the article, and to allow quick navigation to a specific section. This completely removes any semblance of "quick".

The new TOC also is not sticky at the top of the viewport like the old one one, meaning if you want to jump to another section on a page, you have to scroll all the way to the top of the page just to view the TOC.

[ascott18]

Got fed up and made a userscript (for Tampermonkey/Greasemonkey) to mostly work around this. Restores the sticky position and auto-expands. Does not have the old feature of having a marker on the section that is currently scrolled into the viewport.

https://gist.github.com/ascott18/e4d652624959289595da18bb17f0265f

[gewarren]

Some feedback on "In this article", @keziamicro.

[guardrex]

One more note on this in case it's assigned for design/work: It would be cool if we had more control over how deep the ToC shows heading levels. I have a few topics where most of the content is broken down by H3. The H3s are under a few very broad H2s. The ToC is fairly useless at getting to the content because it doesn't show H3s.

This is a somewhat separate problem from the 'Show More' design for In this article, but it might be something that you want to consider addressing at the same time. Let me know if you'd prefer a separate issue for it. If so, I'll open one and provide a link to the live doc that I'm referring to.

[guardrex]

@Powerhelmsman @shirgoldbird ...

Hello! May I ask you to comment on this issue? This issue seems to have gone into a ⚫ black hole ⚫ here 😄. I noticed that you were in control of aspects of the UI design per https://github.com/MicrosoftDocs/feedback/issues/446, so I thought you might be able to help shed some light on this issue.

Was it felt (or determined from testing) that the expanded topic ToC was cluttering the UI and making navigation confusing for readers? If that's correct, was data collected on an expanded versus collapsed topic ToC (e.g., A-B testing)? If an A-B test was executed, do you mind describing the test, especially the subject sample?

The .NET doc set is a reference doc set. After these articles are initially accessed, developers must return to the doc set many times to specific sections of our articles to add new features to their apps or modify their apps' features. I've even been told by many readers over the years that when they access the .NET docs for the first time that they don't read the entire doc set top-to-bottom. On initial contact, many developers merely read the first few fundamentals-focused articles and skim the rest of the doc set. They consume the docs on more of an ad-hoc basis thereafter, dipping in here and there to see how ASP.NET Core has changed from the old .NET Framework for specific features described in specific article sections.

Whether or not developers read the whole doc set at the outset, all developers are now required to execute an extra click virtually 100% of the time to find information in articles when they're seeking a bit of content buried in a section somewhere. They often know that a given article contains a section that they'd like to revisit, but they can't find and reach the section quickly with the articles loading with collapsed topic ToCs. Making matters worse, readers must execute that extra click on every article loaded, which leads to my next question.

Was giving readers the option to leave the topic ToC in an expanded state considered? A button that sets/removes a cookie to configure the topic ToC's state across articles would've probably resolved this problem. Additionally, such a feature along with additional data collection would indicate if loading the ToC in an expanded state is the more popular choice among readers of a particular doc set, probably leading to the ultimate decision on how to load the topic ToC in the first place ... and that leads to a final question about the default load state even if individual readers can choose to override the choice made by Microsoft via a button in the UI.

It might be best to allow the Microsoft managers of the individual doc sets to decide how the topic ToC should load. I think the managers of the .NET doc set would like the topic ToC to default to always expanded. The managers here know the community well, speak with them constantly about how they're consuming the .NET doc set, and probably can either guess well what's best or actually test with this subset of readers to determine what's best for .NET docs ... then individual readers could override that initial choice if they wish via a button in the UI.