Page MenuHomePhabricator

Replace “tools” text button on article nav with an ellipsis icon.
Closed, ResolvedPublic3 Estimated Story Points

Description

Background

To help preserve space and reduce visual clutter, we should replace the existing “tools” text button with an ellipsis icon. This would align the Desktop experience more closely with Minerva - where the same actions are already accessed through an overflow menu pattern. Recent addition of a Watch label (which was essential to improve clarity and usability), has increased the amount of text in the navigation and so by doing applying this change we can reclaim some of the space on article nav when the menu is not pinned.

User story

As a user, I want page tools to be presented in a consistent and familiar way across devices, so that I can easily find actions and have the nav look less cluttered.

Design requirements

Proposed

Vector.png (1,440×791 px, 375 KB)

Current menu on minerva for reference

Minerva.png (384×699 px, 107 KB)


Requirements

Acceptance criteria

  • Replace the Tools text button in the page actions navigation with an ellipsis icon similar to Minerva
  • Ensure that the correct level of spacing and hover effects are applied to it. Check Figma
  • Make sure the keyboard navigation and screen reader support remains intact.
  • Make sure the experience within the drop down (when clicked on the icon) or when the menu is pinned to the side remains the same.

BDD

Scenario: a user has the same UX (feature parity) with ellipsis icon as with the previous tools text button

Given a user is on any page on wikipedia
When ellipsis menu button is present
And s user is clicks on the ellipses button
Then all previous tools menu items should be there

Test Steps

  • check Desktop/mobile (tablet included) for the ellipsis menu to be present
  • click on the ellipsis menu to see that all Tools menu options are present there
  • check for the visual spacing between all icons in the toolbelt
  • general accessibility check
  • screen reader accessibility check

Communication criteria

Add if this needs an announcement or discussion.

Rollback plan

Describe the rollback plan in production for this task if something goes wrong.

This task was created by Version 1.0.0 of the Reader Experience team task template using phabulous.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Jdlrobson-WMF set the point value for this task to 3.Jun 16 2026, 5:30 PM

👍🏼
The Tools menu is not only for tools, so this makes sense.

I mentioned this in another ticket: can we treat the watchstar and bookmark icons as pure shortcuts, and have the spelled-out actions in the tools/overflow menu at all times – if having the icons only is problematic. (I don't think it is, since neither of the actions is destructive, and on the first press we get notified about what we did)

Thanks @Ponor for actively sharing your feedback on various tickets.

Re: the icons, I agree the actions are not destructive, but we should not rely on users to figure out the distinction through trial and error. While experienced editors may understand it, many readers and newer editors won't pay attention to the message or understand the difference right away. Ideally a good interface should make things clear before interaction and not require users to learn through trial an error.

As the discussion goes on T426453 I agree that clutter is a real issue here, and I think we should explore other ways to address it as mentioned by @Jdlrobson-WMF here (or resolve the core issue of having too many options there in the first place) without sacrificing clarity. I assure you that we are actively looking into the problems and finding solutions for some of the concerns raised. Not everyone may be seeing the same issues as people may have different resolutions and options in the nav. But for those encountering I am hopeful we can land on something that also keeps the options understandable.

Change #1304856 had a related patch set uploaded (by Stoyofuku-wmf; author: Stoyofuku-wmf):

[mediawiki/skins/Vector@master] Replace Tools button with vertical ellipsis

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

Test wiki created on Patch demo by SToyofuku-WMF using patch(es) linked to this task:
https://0110d210a8.catalyst.wmcloud.org/w/

@Sneha if you don't mind taking a look at the patchdemo ^ both logged in and logged out to make sure the positioning/layout looks right, I had to interpret the figma a bit since the bookmark icon doesn't seem to be in exactly the specified position

SToyofuku-WMF subscribed.

Okay - I tend to hold onto tickets I worked on until they're in an easily reviewable and finalized state, but if you'd prefer I'm happy to move it

@SToyofuku-WMF I reviewed the patch demo it works really well in terms of its position and hover states.

I had a question about the icon.

  • Are we using the base black here? I looks lighter.
  • The MenuButton icon I used in figma, the individual shapes are circles whereas they are square in the demo. I see Minerva also uses square. Can you confirm which icon we are using? Is it MenuButton or something else?

The bookmark icon looks a bit misaligned from everything in the menu but I hope that is being fixed somewhere else. The ellipsis icon placement looks good here.

I spoke with @Jdlrobson-WMF and I realized the icon I am using in figma is not the same as we have in codex. We are good to go with this for now. And I will review with Derek if we want to update that icon or not later.

Change #1304856 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Replace Tools button with vertical ellipsis

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

Change #1305444 had a related patch set uploaded (by Jdlrobson; author: Stoyofuku-wmf):

[mediawiki/skins/Vector@wmf/1.47.0-wmf.8] Replace Tools button with vertical ellipsis

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

Change #1305444 merged by jenkins-bot:

[mediawiki/skins/Vector@wmf/1.47.0-wmf.8] Replace Tools button with vertical ellipsis

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

Mentioned in SAL (#wikimedia-operations) [2026-06-24T22:59:27Z] <jdlrobson@deploy1003> Started scap sync-world: Backport for [[gerrit:1305191|Restore menu tab underline style (T428519)]], [[gerrit:1305499|Reduce watchstar icon size (T426131)]], [[gerrit:1305444|Replace Tools button with vertical ellipsis (T429258)]]

Mentioned in SAL (#wikimedia-operations) [2026-06-24T23:01:38Z] <jdlrobson@deploy1003> jdlrobson: Backport for [[gerrit:1305191|Restore menu tab underline style (T428519)]], [[gerrit:1305499|Reduce watchstar icon size (T426131)]], [[gerrit:1305444|Replace Tools button with vertical ellipsis (T429258)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-06-24T23:06:48Z] <jdlrobson@deploy1003> Finished scap sync-world: Backport for [[gerrit:1305191|Restore menu tab underline style (T428519)]], [[gerrit:1305499|Reduce watchstar icon size (T426131)]], [[gerrit:1305444|Replace Tools button with vertical ellipsis (T429258)]] (duration: 07m 21s)

This looks good from my side (minus all the alignment issues that are covered in other tickets).

I see this change went live some days ago. I find it very inconvenient: a colleague made a script to reverse the effect for me as a favor. For a new editor who may not need the options linked under tools, this is a trivial change. For experienced editors who use more specific tools frequently, the reduced size of the tools button is a serious inconvenience. Important native functionality (block, protect, contributions links) are location under this option, but more importantly a large number of user-scripted functions are placed here too. On en.wiki, page swapping, SPI scripts, teahouse scripts, copyvio scripts, and several others place their buttons in this menu. Uniformity across skins seems like an improvement too minor to justify this inconvenience.

This is a quibble, but since it's an ellipsis, I think it makes sense to make it appear at the end of the line. Currently, the Twinkle menu selection appears after it, and it looks a little weird that way.

This is a quibble, but since it's an ellipsis, I think it makes sense to make it appear at the end of the line. Currently, the Twinkle menu selection appears after it, and it looks a little weird that way.

This seems to be a choice by Twinkle the gadget. I've suggested this change to the gadget developers (but I have no control over whether they think this is a bug or not):
https://github.com/wikimedia-gadgets/twinkle/pull/2384

@Vanamonde93 we hear the feedback about touch area. We are considering either increasing it or limiting the change to smaller screens. Here's a demo for how the latter might behave if you want to give it a try:
https://ac5d16ab78.catalyst.wmcloud.org/wiki/Main_Page

Etonkovidova updated the task description. (Show Details)
Etonkovidova updated the task description. (Show Details)

Checked on testwiki wmf.91 and enwiki wmf.9`

Acceptance criteria

  • Replace the Tools text button in the page actions navigation with an ellipsis icon similar to Minerva
Desktopmobile
Screenshot 2026-06-30 at 4.44.55 PM.png (1,162×346 px, 82 KB)
Screenshot 2026-06-30 at 4.45.07 PM.png (1,153×530 px, 129 KB)
Screenshot 2026-06-30 at 4.24.52 PM.png (1,092×563 px, 165 KB)
Screenshot 2026-06-30 at 4.25.07 PM.png (419×638 px, 82 KB)
  • Ensure that the correct level of spacing and hover effects are applied to it. Check Figma
Screenshot 2026-06-30 at 4.54.22 PM.png (1,308×902 px, 179 KB)
Screenshot 2026-06-30 at 4.24.21 PM.png (1,180×396 px, 133 KB)
  • Make sure the keyboard navigation and screen reader support remains intact.
  • checked keyboard navigation anf screen reader (Silktide extension in chrome) - ✅ no issues

Run axe devTools and Chrome Lighthouse check.
#vector-page-tools-dropdown-checkbox element has a minor accessibility issue:

Screenshot 2026-06-30 at 8.27.51 PM.png (1,598×612 px, 142 KB)

Ensure role attribute has an appropriate value for the element
Element Location:
#vector-page-tools-dropdown-checkbox
<input type="checkbox" id="vector-page-tools-dropdown-checkbox" role="button" aria-haspopup="true" data-event-name="ui.dropdown-vector-page-tools-dropdown" class="vector-dropdown-checkbox " aria-label="Tools" aria-expanded="false">
  • Make sure the experience within the drop down (when clicked on the icon) or when the menu is pinned to the side remains the same.

✅ no issues

Please revert this change and put it back as a Tools submenu. No one asked for this. Tools is a really important part of the AfC reviewer workflow, NPP workflow, and general page maintenance workflow. Having it in a kebab menu is pointless, confusing, and makes it harder for the end-user to understand what is in this new menu.

Please revert, and stop changing things for no reason.

Thanks,

"No one asked for this" is objectively incorrect as someone created this ticket. Also, there were no objections brought up here until today, suggesting that many people were fine with the change. I am fine with the change for the stated reason ("To help preserve space and reduce visual clutter") as well as the statement made earlier that the menu includes more than just tools. Also, this is how many contemporary apps like web browsers situate a list of particular actions and links to tools or information.

I don't think this change is an improvement to the UI. It makes the target for opening the Tools menu uncomfortably small, replaces a clear label with an ambiguous and overused "three dots" icon, and reduces consistency with the adjacent controls. I don't think saving a small amount of horizontal space justifies the loss in clarity and ease of use. Space is much less constrained on the desktop site than on a mobile device.

In general, consistency across platforms or skins shouldn't be a primary goal that takes precedence over usability.

Finally, when we are making changes like this to the UI, there needs to be a better way to introduce these changes to users. Hiding an explanation in a UI element that users may not even be able to locate is less than ideal. That being said, I am still hoping this change is reconsidered and undone.

Have filed T431347 re the feedback, probably not the best idea to reopen a closed task.

"No one asked for this" is objectively incorrect as someone created this ticket. Also, there were no objections brought up here until today, suggesting that many people were fine with the change. I am fine with the change for the stated reason ("To help preserve space and reduce visual clutter") as well as the statement made earlier that the menu includes more than just tools. Also, this is how many contemporary apps like web browsers situate a list of particular actions and links to tools or information.

Yes because the fraction of Wikipedia editors who know what phabricator is, and then the fraction of those who click through to this issue, and the fraction of THOSE who bother to comment = consensus.

"No one asked for this" is objectively incorrect as someone created this ticket. Also, there were no objections brought up here until today, suggesting that many people were fine with the change. I am fine with the change for the stated reason ("To help preserve space and reduce visual clutter") as well as the statement made earlier that the menu includes more than just tools. Also, this is how many contemporary apps like web browsers situate a list of particular actions and links to tools or information.

Yes because the fraction of Wikipedia editors who know what phabricator is, and then the fraction of those who click through to this issue, and the fraction of THOSE who bother to comment = consensus.

That twists my point, which is to say you were the first to formally complain when quite of number of people "in the know" hadn't until you did. And believe me, if I didn't like it, I would have complained.

As for "consensus", I suppose developers could have stewed on this a little longer, taking time to accept more community input, but that wasn't what I was talking about.

Going to push back on StefenTower's argument here – I, too, found this change extremely annoying, but like Vanamonde I simply immediately reversed it using custom CSS and moved on with my life, assuming that such WMF interventions are non-negotiable. Now that I see this ticket, I am pleasantly surprised at the openness to limiting this change to screen sizes where it is necessary, which does not include the vast majority of users of the desktop view. That is absolutely the solution here. I also think the three dots icon is terrible at telling the user what's behind it. Maybe, in the spirit of a "Tools" menu, we could change it to a wrench icon? Or maybe, if the problem with "Tools" is that it does not only contain tools, we should reconsider dumping all of these unrelated features into a single dropdown menu...

Hi all, thank you very much for sharing your thoughts on this change. It is difficult to find perfect solutions that can address every situation (this change was also rooted in feedback from community members whose languages take up a lot more space than the tabs we have in enwiki), so we are grateful for your help in finding a good solution. Further changes are being proposed and discussed in https://phabricator.wikimedia.org/T428520#12060556. There are prototypes in that task that should hopefully show where we are hoping to get to. Your continued feedback there on the ideas being proposed is very welcome!

Going to push back on StefenTower's argument here – I, too, found this change extremely annoying, but like Vanamonde I simply immediately reversed it using custom CSS and moved on with my life, assuming that such WMF interventions are non-negotiable. Now that I see this ticket, I am pleasantly surprised at the openness to limiting this change to screen sizes where it is necessary, which does not include the vast majority of users of the desktop view. That is absolutely the solution here. I also think the three dots icon is terrible at telling the user what's behind it. Maybe, in the spirit of a "Tools" menu, we could change it to a wrench icon? Or maybe, if the problem with "Tools" is that it does not only contain tools, we should reconsider dumping all of these unrelated features into a single dropdown menu...

Seems like the solution to much of your concern is a tooltip, which is not without precedent already in the menu. It could read: "Miscellaneous actions and links to tools and information" (or something like that). Since we can assume people reading an encyclopedia can also read a tooltip that explains the ellipses, that should resolve users not knowing what it's for.

Also, per "dumping", I would suggest that adding yet another menu option takes us in an adverse direction with regards to what was trying to be solved with this ticket.

@Qcne: Please do not vandalize the correct status of a task in order to express disagreement with the idea in the task itself. Thanks.

I would suggest for the future that a change that impacts functionality and appearance for all users ought to be discussed more widely than solely at the task requesting it. Even the most clued-in editors are unlikely to have seen this change before it went live, and this is not a strong model for modifying editor tools, even if everyone involved is working in the best of faith.

Test wiki on Patch demo by SToyofuku-WMF using patch(es) linked to this task was deleted:

https://0110d210a8.catalyst.wmcloud.org/w/