per some ideas from @RHo, @Quiddity, and @Jdrewniak here is a version where all three menus are in the left sidebar. the Contents and Article tools are accordion style, so you can either open one or the other (this is necessary because they're both sticky, and if you had them both open at the same time with a long ToC you wouldn't be able to access the Article tools). The main menu is not sticky, and is able to sit on top of the other two menus.

link to prototype

I think the main drawback here is that you have to choose to either have the ToC open or the Article tools open

Keeping the main menu focused on navigation makes sense. However, I'm not sure it is worth it to do that at the cost of creating another generic container of options, as the "article tools" may represent.
If someone is looking for pages linking to the current article, do we expect them to go directly to the "article tools" menu, the hamburger menu, or the "Explore more" option next to the "view history" action?

Based on the above, some options that can be considered:

• Consider an alternative label for "Article tools" that makes it more specific so that most people clearly go there when looking for the type of actions it contains.
• Unify the "Article tools" under the "Explore more" option which seems more connected to the article. Given the change of placement you may want to consider how to redirect/educate users about it (keeping an "article tools" link on the main navigation menu that redirects users to the new placement, tooltips, etc.)

Another consideration is about the need to have all tools at hand and visible at once. Maybe article tools could use the same space as the table of contents. The table of contents could be a representation of the article and having a quick access to the tools could reuse the same space. In this way the left column may feel as less fragmented.

+1 to @Pginer-WMF's suggestions, particularly the option to integrate the article tools with the ToC in some way. This would make a fairer comparison to the version where the tools are pinnable on the RHS as it would then enable persistent access to the tools without toggling open the menu. It would also make sense for articles/content pages when there is no ToC (e.g., typical file pages on Commons, Wikidata items)

@Pginer-WMF thanks for your feedback. I would like to clarify some of your points:

If someone is looking for pages linking to the current article, do we expect them to go directly to the "article tools" menu, the hamburger menu, or the "Explore more" option next to the "view history" action?

Which prototype are you referring to here? Neither of the prototypes have all three menus you mention. In the first prototype there is a hamburger menu for global navigation, and then an "Explore more" (i.e. Article tools) menu in the article toolbar for article stuff. In the second prototype there is a hamburger menu, and an article tools menu below the table of contents.

Unify the "Article tools" under the "Explore more" option which seems more connected to the article.

This is what the first prototype does — moves all of the article-related links/navigation/tools to the article toolbar under the "Explore more" menu, which can be pinned for immediate access upon page load.

Another consideration is about the need to have all tools at hand and visible at once. Maybe article tools could use the same space as the table of contents.

Feedback from editors is that the article tools menu is important to have immediate access to upon page load. Considering we have the space on the right I don't see much of a drawback in letting people access both the table of contents and the article tools...why should they have to choose one or the other?

Reviewed our options with Alex. I think, based on testing an feedback, for now we will prioritize the following:

1. Persistent access to tools for logged-in folks that allows a way to hide for anons/reading workflows
2. Consistency in visual cues for functional menus vs content-based menus. The ToC is a core part of the reading experience and thus a case can be made that its styling should be unique.

This is leading us to lean towards the pinning menu version of the prototype (option 2 in the task description), with the first part (option 1) as the initial design until we can shift focus to separating the article tools from the rest of the menu. I'm particularly excited about the opportunities that the idea of "pinning" functionalities or pieces of navigation to the left or right could allow for in the future. Curious if anyone else has any immediate use cases that could also benefit from this treatment in the future.

In T300673#7688622, @alexhollender_WMF wrote:

@Pginer-WMF thanks for your feedback. I would like to clarify some of your points:

If someone is looking for pages linking to the current article, do we expect them to go directly to the "article tools" menu, the hamburger menu, or the "Explore more" option next to the "view history" action?

Which prototype are you referring to here? Neither of the prototypes have all three menus you mention. In the first prototype there is a hamburger menu for global navigation, and then an "Explore more" (i.e. Article tools) menu in the article toolbar for article stuff. In the second prototype there is a hamburger menu, and an article tools menu below the table of contents.

Unify the "Article tools" under the "Explore more" option which seems more connected to the article.

This is what the first prototype does — moves all of the article-related links/navigation/tools to the article toolbar under the "Explore more" menu, which can be pinned for immediate access upon page load.

Another consideration is about the need to have all tools at hand and visible at once. Maybe article tools could use the same space as the table of contents.

Feedback from editors is that the article tools menu is important to have immediate access to upon page load. Considering we have the space on the right I don't see much of a drawback in letting people access both the table of contents and the article tools...why should they have to choose one or the other?

My interpretation was that it is not choosing one over the other, but integrating the ToC and article tools together in some way into one side bar element, but presumably with some visual separator between the two.

I do like RHo's idea, for showing both (ToC and Page-tools) at once.

Related to my comment at T298900#7655145 - I think it would be very helpful to look at (demo) any prototype both with a medium-length ToC page (as shown above with Tuna and Orangutan), but also

• for a page with many headers and/or subheaders (e.g.1 and/or e.g.2 and/or (new example) e.g.3)
• for a page with few or zero headers (e.g.1 and/or e.g.2)

and also with a smaller-sized window (for people with laptops, and non-maximized browser-windows).

In T300673#7690528, @Quiddity wrote:

I do like RHo's idea, for showing both (ToC and Page-tools) at once.

As far as I can tell the only way to show the ToC and the page tools at the same time is to have the ToC on one side, and the page tools on the other, which is the whole point of the proposal : ) I don't understand how they could both be on the same side unless they were both rather short and scrolled internally, or in the case of someone with an unusually tall screen?

In T300673#7688955, @RHo wrote:

My interpretation was that it is not choosing one over the other, but integrating the ToC and article tools together in some way into one side bar element, but presumably with some visual separator between the two.

How do you see this working? The table of contents sticks to the top of the screen as you scroll down the page, and is often taller than the height of the page. I don't understand how the article tools could also be exposed at the same time, unless it was on the opposite side of the article.

@alexhollender_WMF I was guessing it would just expand the 2nd scrollbar for the left-hand sidebar. The scrollbar will appear for pages with long ToCs (or expanded ToCs with many subsections) anyway, and for short browser-windows, therefor this seems logical. E.g. https://di-sidebar-accordion-menus.web.app/WP:VPT -

In T300673#7690603, @alexhollender_WMF wrote:

In T300673#7688955, @RHo wrote:

My interpretation was that it is not choosing one over the other, but integrating the ToC and article tools together in some way into one side bar element, but presumably with some visual separator between the two.

How do you see this working? The table of contents sticks to the top of the screen as you scroll down the page, and is often taller than the height of the page. I don't understand how the article tools could also be exposed at the same time, unless it was on the opposite side of the article.

Here is an extremely quick and rough sketch to provide an idea of the exploration I was suggesting, in the scenario where there is a long ToC.

• Much in the same way the main menu is being reviewed for what items can be moved or removed, consolidate the links in the article tools either by moving/removing, or by reducing from multiple link lines to a menu of icon buttons (eg., Other projects could show projects as badges, Share actions as icons to download, print, etc)

I suggest this as another avenue to consider while it is still relatively early in exploration, I don't wish to be misinterpreted as saying this is the preferred solution by any means. However, I would also like to reiterate earlier feedback about not preferring the pinning option as it feels more fussy in having an extra action to make the tools persist, and that this other option could be preferred at least as an interim change by separating the tools out first and maintaining its position on same side as the current experience.

In T300673#7688622, @alexhollender_WMF wrote:

@Pginer-WMF thanks for your feedback. I would like to clarify some of your points:

If someone is looking for pages linking to the current article, do we expect them to go directly to the "article tools" menu, the hamburger menu, or the "Explore more" option next to the "view history" action?

Which prototype are you referring to here? Neither of the prototypes have all three menus you mention. In the first prototype there is a hamburger menu for global navigation, and then an "Explore more" (i.e. Article tools) menu in the article toolbar for article stuff. In the second prototype there is a hamburger menu, and an article tools menu below the table of contents.

I may be a bit confused. Currently with both Legacy and new vector there is a "more" option next to "read, edit, history, and watch" tabs if you have the user rights to do more advanced actions (such as move or purge the page):

Legacy Vector	New Vector

I thought the above "more" menu was the same as the "explore more" one you had in the image below (and it was not shown in other options but could be if the user had the appropriate rights):

Unify the "Article tools" under the "Explore more" option which seems more connected to the article.

This is what the first prototype does — moves all of the article-related links/navigation/tools to the article toolbar under the "Explore more" menu, which can be pinned for immediate access upon page load.

Ok. In that case, would the options to move and purge be part of this menu too when available or a separate one?
I think it makes sense to consolidate these options into one single menu since they are page-specific actions.

Another consideration is about the need to have all tools at hand and visible at once. Maybe article tools could use the same space as the table of contents.

Feedback from editors is that the article tools menu is important to have immediate access to upon page load. Considering we have the space on the right I don't see much of a drawback in letting people access both the table of contents and the article tools...why should they have to choose one or the other?

Even if there is space for it, everything we add comes with a cost in terms of the user attention and the effort to navigate through more options. Maybe it is useful to have both visible, but if not I think there is an opportunity to have just the tools you need in each scenario (immersed in the page content vs. manipulating the page as a whole).

In T300673#7704211, @Pginer-WMF wrote:

would the options to move and purge be part of this menu too when available or a separate one?
I think it makes sense to consolidate these options into one single menu since they are page-specific actions.

@Pginer-WMF this is something I am also wondering. Currently there are two main areas for tools, and several sections/menus within those areas:

Here are two approaches to consolidating these two areas:

Approach #1 — this is maybe a more literal mapping, and is similar to the approach Monobook takes where things are more flat vs. nested/structured. I think it has the tradeoff you mentioned where it can be difficult to guess/know/remember which tool is in which menu, but on the other hand if you do memorize it perhaps it's quicker to find stuff:

Approach #2 — this seems more familiar to me, and I think is what you were describing. It comes with the inverse tradeoff from the approach above — there's only one menu so you don't have to guess which menu to open, but maybe it takes longer to find something inside of the menu because it's large:

Now I will attempt to map these two approaches to the new, proposed design...

In approach #1 each menu is independently collapsible:

In approach #2 all of the menus are part of a single entity, and can only be expanded or collapsed altogether:

@ovasileva @Jdlrobson it would be great for y'all to weigh in here from your respective product and technical perspectives. We need to decide, at the very least, which approach we want to present in our upcoming round of community prototype testing.

cc @KieranMcCann for general awareness : )

I'm leaning towards collapsing all at once:

• I think it would create a more straightforward workflow (one button vs many for tools)
• We could do this as a first step and measure which items get the most clicks. If one of the sections is used significantly more, or less frequently than the others, we can reconsider
• It seems more straightforwards technically as the menus will always appear in the same order

That said, we can potentially add this to the questions for the prototype. In particular for tools like twinkle or move/delete/protect I can see an argument being made for the individual menus

I don't think there's any technical advantages of either approach.

The sidebar approach seems to work on the assumption that there is enough space to accommodate a menu on the right. what will we do when that's not the case? Hide them? Overlay the menus over the content? Push them to the end of the article?

In T300673#7758266, @Jdlrobson wrote:

The sidebar approach seems to work on the assumption that there is enough space to accommodate a menu on the right. what will we do when that's not the case? Hide them? Overlay the menus over the content? Push them to the end of the article?

yea, at a certain screen width (probably 1200px) we will need to collapse the pinned menu on the right. Maybe we could look into using the checkbox hack to make it easier to control the open/closed state via a media query?

The main complexity that keeps cycling through my mind, is how to keep the crucial tools that some editors use constantly (multiple times each minute, for some users of gadgets like Twinkle and MoreMenu - example) directly available to them, no matter what size they have their browser-window(s) set at.

@Quiddity I appreciate you continuing to advocate for the needs of editors, and continuing to push us to do more with the interface. To clarify:

...how to keep the crucial tools that some editors use constantly directly available to them, no matter what size they have their browser-window(s) set at.

This is not something we currently do, correct? My understanding is that those advanced tools are currently in menus, and therefore not directly available. If my understanding there is correct, to begin with we will be improving this situation for people who use those advanced tools by creating a tools sidebar where they are directly accessible:

As for what happens below 1200px, at that point we are really just out of space, as I've said before. Optimistically I could see someone creating a gadget that turns the tools sidebar into a floating menu panel below 1200px, something like:

Aside from that I do not yet see any broadly applicable solution that satisfies our interface needs around the primacy of the Table of Contents, the minimum width of the article content, and a degree of consistency between reader and editor layouts.

In T300673#7789385, @alexhollender_WMF wrote:

@Quiddity I appreciate you continuing to advocate for the needs of editors, and continuing to push us to do more with the interface. To clarify:

...how to keep the crucial tools that some editors use constantly directly available to them, no matter what size they have their browser-window(s) set at.

This is not something we currently do, correct? My understanding is that those advanced tools are currently in menus, and therefore not directly available. If my understanding there is correct, to begin with we will be improving this situation [...]

[Pre-Note: One of your proposals above might be perfect already! I'm just having difficulty imagining how they might work-in-practice based on static-screenshots and descriptions... But to explain what I'm thinking, here are more details. :-) ]

Ah, I used imprecise language, sorry! What I meant was:
Editors on Desktop that use Twinkle (for example) currently have direct access to the "TW" menu item, and it's in a very consistent location. I.e.

• As an editor, who is currently scrolled to the top of the page, I can reach a menu item with 4 actions: Move mouse to "TW"; Click; Move mouse to item; Click.

Or with the Default page-tools in the "Tools" sidebar menu:

• As an admin, who is currently scrolled to the top of the page, I can access the Special:Block page for a user with 2 actions: Move mouse to "Block user"; Click.

Or with the MoreMenu gadget:

• As an editor, who is currently scrolled to the top of the page, I can access the "Protection log" entry with 6 actions: Move mouse to "User"; Click; Move mouse to "User logs..." submenu; Move mouse right; Move mouse to "Protection log"; Click. [video recording: F35011421 ]

The consistent locations enable my mouse-movements to be very muscle-memory driven, which is a huge benefit for someone trying to work rapidly.

That said, I should emphasize: I do really like the idea of making these sub-menu items directly available, as some of your proposals above would do. Is there a newer live-prototype link available that we could interact with?

Re: 1200px limits - my own use-case, is that I frequently work on a laptop screen with 2 windows side-by-side. That results in ~960px wide windows (Screenshot: F35011436). However, I don't know how common that setup is, and grok it might be an edge-case-too-far!

I agree the options/constraints are hugely complicated, and I'm sorry I can't help think of any other optimal solutions. Hope these notes help.

@Quiddity thanks for the clarifications. I've got an updated prototype which will hopefully help guide our conversation towards more specificity: https://di-article-tools-2.web.app/Blue_whale.

Regarding your concern about tools and menus moving around: I realized something (which you will see in the prototype) that I think will allow us to avoid auto-collapsing the tools menu at smaller widths. Between 1200–1000px we are going to collapse the ToC (see T298898), which I think means that we can allow the tools menu to stay open, ultimately allowing editors to make their own decision about the tradeoff between less width for the content & visibility of the tools menu. In the screen recording below I show that situation, along with a few other aspects of the updated prototype.

@Jdlrobson has raised a potential technical constraint around offering the "pinning"/"collapsing" functionality for the article tools menu, which is a key part of the current proposal. As discussed previously, the article tools need to be immediately available (i.e. "pinned") for some folks, however other folks (maybe because they have smaller screens, or because they use those tools less) will not want the article tools pinned. So, if we are unable to offer pinning/collapsing of the article tools we will need another approach.

I've gone back and fleshed out an approach we discussed earlier (original comment: T300673#7673047, follow-up from @RHo which suggests how to push this further: T300673#7691301). This approach still splits the sidebar menu into two menus (global navigation, tools), however instead of moving the tools menu to the far side of the article (across from the ToC), it keeps the tools menu on the left, by the table of contents.

There are two versions of this approach:

Version 1 (tools menu above the ToC)	prototype
logged-out	logged-out, no ToC	logged-in

Version 2 (tools menu below ToC)	prototype
logged-out	logged-out, no ToC	logged-in

Some things to consider / try:

• try logged-out and logged-in
  • when logged-out the tools menu is collapsed by default
  • when logged-in the tools menu is expanded by default
• try pages with shorter and longer ToCs
  • shorter ToC example: version 1, version 2
  • longer ToC example: version 1, version 2
• some pages don't have a ToC, so in those cases the tools menu will be by itself in the sidebar (and likely collapsed for logged-out folks)
  • no ToC: version 1, version 2
• try scrolling up and down with the tools menu open and collapsed, and see how the sticky stuff works

Pros/Cons of this approach vs. the current proposal:

• Pros
  • one sidebar instead of two (bit more simple, no content squeeze)
  • tools are in a familiar position for experienced contributors
• Cons
  • showing the tools menu along with the ToC results in the interface starting to compete with / distract from the content
  • article tools are not consolidated to one part of the screen
  • a bit more complexity with scrolling / sticky elements
  • can't see full tools menu and full ToC at the same time
  • slightly awkward layout when logged-out on a page with no ToC

@RHo @Pginer-WMF @Quiddity @ovasileva it would be great if you all could take a look at this approach and help flesh out the pros/cons list. Thank you!
cc @Jdlrobson

@alexhollender_WMF did you happen to think about perhaps having a tabbed approach where you can have either the ToC or editor tools open and perhaps that van persist across pages? I know there is an extra layer of complexity when dealing with toggling and remembering what a preference is (user preferences perhaps, I don't know) but it could enable people to have a preferred menu type open (by default perhaps), retain the familiarity for editors of where the tools are and best of all, not have to squeeze the content <- as that is precisely what they would want to be interacting with anyway, right?

Thanks for sharing these, Alex. some quick comments below.

My main concern is for the tools to push down the Table of Contents (which is great to have it as a featured element showing a content-first approach). So for Version 1, I'd consider to keep the tools collapsed even for logged-in users (expanded status could be remembered).

For version 2, it is true that tools can be pushed down too, but learning they are at the end of the table of contents may be less of a problem for the more expert users interested in them. You may consider whether to show the sections expanded by default in long tables of contents. Having them collapsed when there are many items in the ToC can keep the length more reasonable for both processing the ToC at a glance and finding the tools below.

An aside minor comment, for the tools menu you may consider labelling it jus as "Tools". The "menu" part seems not to add much.

+1 for a tabs prototype. If you use "TOC" and "Tools" there should be room for 3 tabs. (I would create a third tab for my users scripts.)

I love how the new sidebar design works with new tabs design :-). I saw those tabs on Tar's presentation on Polish Wzlot and I really like them. And now I also like the new menu :-)

One thing about the layout. I think eventually you should put all this in a grid (main layout). This way users would be able to prepare their own layout easily (make their own areas). At this point I don't think you have to support IE with anything except maybe showing content in a readable way, so a very basic fallback can be provided.
https://developer.mozilla.org/en-US/docs/Web/CSS/grid-template-areas

One more thing... I wouldn't agree with this con: "showing the tools menu along with the ToC results in the interface starting to compete with / distract from the content".
Wikipedia is editable. Wikipedia is community. Tools are not a distraction. They are Wikipedia on the same level the content is. Another team -- Growth -- tries to attract new visitors and retain old ones.
Note that I don't want to pick on words. That probably might have just been badly phrased... But do keep in mind that while allowing readers to be less distracted, it would actually be good if they are distracted with ways to contribute. Readers should want to fix things. Should know they can fix things. Should know they can ask to fix things. Should know they can ask for help. It is not a distraction. It should be one of the goals. We need fresh blood all the time ;-)

One thing about the layout. I think eventually you should put all this in a grid (main layout).

@Nux already on it! I am currently working on this in T303484.

Note that I don't want to pick on words.

We appreciate that :D

it would actually be good if they are distracted with ways to contribute. Readers should want to fix things. Should know they can fix things. Should know they can ask to fix things. Should know they can ask for help. It is not a distraction. It should be one of the goals. We need fresh blood all the time

Absolutely right! This is part of our basic flywheel (find content -> view it -> edit and provide more better content -> find -> ...). We work closely with Growth and Editing to ensure that our changes are integral. Together, we plan on making the entry points to the community properly exposed in the interface (that's our part) and effective (that's Growth's part). That's the general approach.

Hi @alexhollender_WMF - late to comment but I prefer version 2 with tools after ToC for the same reasons as @Pginer-WMF.