Hi, in my understanding, it is one additional click? How does that "break a common workflow"?
Also, how often do you have to log in?

In T288638#7277114, @Aklapper wrote:

Hi, in my understanding, it is one additional click? How does that "break a common workflow"?

It is not just one additional click, but I need to move the cursor to the correct menu entry. It is significantly more effort, especially for such an important page. I'm quite certain that if we could only have one icon in the upper right-hand corner, most editors would choose a link to their watchlist. Do you have data on how often each of the links in the "traditional" skins is clicked on?

Also, how often do you have to log in?

I'm not sure I follow your line of thought here. As far as I can see, the log in process is unchanged?

I'm not sure I follow your line of thought here. As far as I can see, the log in process is unchanged?

I asked as you wrote "It's what I click right after I log in" so I wonder why you have to log in so often (using different devices across places?), wondering why you would not directly start at Special:Watchlist (e.g. via a bookmark in your browser) and keep that page opened.

In T288638#7279145, @Aklapper wrote:

[...] I wonder why you have to log in so often (using different devices across places?), wondering why you would not directly start at Special:Watchlist (e.g. via a bookmark in your browser) and keep that page opened.

Sure, I can add a bookmark or modify the skin through my custom JS/CSS. But since from my point of view the watchlist is one of the most important features for logged-in users, I would like to advocate for the link being visible and easy to reach by default. Wikipedia's interface for logged-in users should strive to provide the best possible editing and curating experience, without the need to rely on third-party functionality.

If your user research conclusively shows that most people really don't need the link to the watchlist, I'm happy to find a workaround. However, I would be very surprised to learn that people are more interested in directly accessing their past notifications (the icons are visible whether there are new notifications or not) than in directly accessing their watchlist.

Please consider my request as feedback from a long-time user and not as a general opposition to cleaning up the UI. I think that hiding links to e.g. user settings or Beta features makes a lot of sense and is a great step towards a more modern and beginner-friendly UI. Same goes for hiding the navigation bar on the left, which contains a lot of seldomly used links.

(I login almost every time I visit Wikipedia for editing purposes because I want to make sure I don't expose my user name when screen-sharing in non-Wikimedia contexts.)

Je soutiens la demande de Cirdan : je clique sur le bouton de liste de suivi plusieurs fois par jour, il m'est beaucoup plus utile que le bouton des notifications. (in poor english :// I support Cirdan's request: I click on the watchlist button several times a day, it is much more useful than the notifications button.// )

@Cirdan please see T288794 which was just merged. There, I have provided a link to a JS user script that adds the Watchlist link back, shown as just a star.

Like you, I think this is something that should be the default, and not brought back through a hacky JS script.

If there is usage research that shows most users don't use the Watchlist link (i.e. don't visit the Watchlist), I would like to see the numbers too. That would be important to know; it has been my long lasting fear that the introduction of Echo and the reliance on push notifications (pings) has deterred users from using Watchlist and as a result, conversations in which pings don't happen are being missed and vandalism is being found much later too (in the Watchlist days, people would find vandalism because they would see the page change in their Watchlist, which they visited often).

Out of curiosity, if the problem statement is "it takes 2 clicks " couldn't this be fixed by learning and using the keyboard access keys?

Control+⌥ Option+l opens watchlist page for me.

https://en.wikipedia.org/wiki/Wikipedia:Keyboard_shortcuts

Bien sur, je peux "apprendre" à utiliser un raccourci clavier (merci, après 17 ans de contributions je ne le connaissais pas), je peux aussi utiliser les favoris de mon navigateur mais.... la nouvelle interface est-elle faite pour créer des obstacles et obliger les gens à "apprendre" des raccourci, ou bien est-elle destinée à faciliter l'accès au contributeur non geek?
Of course I can "learn" how to use a keyboard shortcut (thanks, after 17 years of contributions I didn't know it), I can also use my browser's bookmarks but.... is the new interface meant to create obstacles and force people to "learn" shortcuts, or is it meant to make access easier for the non-geek contributor?

In T288638#7281583, @Jdlrobson wrote:

Out of curiosity, if the problem statement is "it takes 2 clicks " couldn't this be fixed by learning and using the keyboard access keys?

Control+⌥ Option+l opens watchlist page for me.

https://en.wikipedia.org/wiki/Wikipedia:Keyboard_shortcuts

That is three key presses; and for those of us who work on different OS's, that is two sets of three key presses where the key combinations are indeed different.

Simply put: if you really think the problem is the number of clicks, you have misunderstood the issue. The problem is with "ease of use". If you made the link appear at a random location on the screen each time, it would still be only one click away, but it wouldn't be easy to use. The drop down solution is also not as easy to use as a link that is consistently shown in the same place of every page, especially, in a place that is already familiar to the users. And asking users to learn a new three-key shortcut is not a solution either, from an ease of use perspective.

Long story short, I can see this task to be addressed in one of two ways: either developers agree to bring back the Watchlist link, or they don't in which case the JS script I wrote will likely turn into a gadget that nearly every wiki will have and some (many?) will enable by default. You can't just make things harder to use and then try to force users to do it your way. At least not in an extendible platform like MediaWiki.

PS: You is not referring to you as a person; it is colloquial you, referring to developers of the new Vector.

Simply put: if you really think the problem is the number of clicks, you have misunderstood the issue.

The understanding was my goal for the question, so thank you all for the feedback. I am still curious to get to the heart of the issue here, as to me (personally) an extra click link is a small price to pay for helping people not familiar with the interface by reducing clutter, but I can emphasize that my experience is not going to be the same as everybody else's.

Note, we are building a sticky header next (T283505) and are talking about allowing user customization to incorporate frequently used features which will reduce the need to scroll to the top of the page to access the feature, so it such a gadget would likely be made redundant by this change. The prototype is at https://di-community-round-2.web.app/Audre_Lorde (and Chrome only).

As a word of warning the HTML for the interface is in flux as we add further support for icons, so the gadget would likely need to be revised a few times as we complete the journey.

@alexhollender and @ovasileva are better placed than me to talk about the design and product roadmap.

@Jdlrobson I anticipated as much, and will be on the ready to keep revising the JS user script/gadget for the months to come.

The sticky header is a great feature and I look forward to it. It doesn't change the argument above though; i.e., sticky header increases ease of use for all of those user links, but it would still be incrementally better if we would keep the Watchlist there too, and not inside a dropdown menu.

Customization is also a great feature to look forward to. Maybe we can allow users to add the Watchlist star back, through their preferences? And may be some wikis could ask for that to be turned on by default?

But all of the above are multi-month solutions for a problem we just introduced, and there is a quicker fix here which I am not convinced why is being ignored: why not just listen to the community feedback and add the star back right now? There doesn't seem to be specific evidence regarding the usage of this feature or lack thereof, so the best "data" you have is the community feedback; if the community asks for it to be back, why hesitate? Do you really think the additional "clutter" from this is substantial enough to delay the decision?

@Huji one challenge with adding more icons to that bar, is we're attempting to make the menu responsive. If you resize the browser you'll note the space becomes less available, but I think if acceptable, the newly proposed links could just be hidden.

if the community asks for it to be back, why hesitate?

I don't think it's ever good to make a snap decision based on a handful of people. Adding a new icon is definitely feasible, but we do have data around watchlist usage so maybe we should wait for that first as well as some input from others ?

Out of curiosity, if the problem statement is "it takes 2 clicks " couldn't this be fixed by learning and using the keyboard access keys?

As I said above, I can also just add the link back myself, but that's not the point.

In T288638#7281968, @Jdlrobson wrote:

I am still curious to get to the heart of the issue here, as to me (personally) an extra click link is a small price to pay for helping people not familiar with the interface by reducing clutter, but I can emphasize that my experience is not going to be the same as everybody else's.

I get that you're trying to simplify the interface, but the watchlist is the page at the center of curating Wikipedia articles. It's one of the first things we teach new editors, it's what casual editors use to check up on what's happened in the past weeks, it's what long-time editors use to keep track of discussions and changes across their articles of interest. Until you removed the link, it would have never occurred to me that this would even be considered. (I'm very happy to see the Beta and Settings and Logout links move into a menu, and I'm fine with the Contributions link disappearing as well, even though personally I would keep it visible at all times.)

Adding a new icon is definitely feasible, but we do have data around watchlist usage so maybe we should wait for that first as well as some input from others?

Could you please give more insight into the data that you have gathered? I'm very curious to see and learn. Have you run any user tests with different types of users to determine which links to keep as first-class citizens?

In T288638#7282230, @Jdlrobson wrote:

if the community asks for it to be back, why hesitate?

I don't think it's ever good to make a snap decision based on a handful of people. Adding a new icon is definitely feasible, but we do have data around watchlist usage so maybe we should wait for that first as well as some input from others ?

In principle; I agree. However, we are not taking about a net new feature request here. The change has caused a regression (a feature that existed has been taken away) and it has been met with criticism. Also, the decision behind the regression was based on heuristics, not based on hard evidence. Given those, I would set the bar lower here.

we're attempting to make the menu responsive. If you resize the browser you'll note the space becomes less available, but I think if acceptable, the newly proposed links could just be hidden.

I am aware. Did you try the JS tool I created? Even in the narrowest window size, it still works just fine. There is exactly room for one more link, and we are asking for exactly one.

If the idea is decreasing the number of icons in the bar merging the alerts and notices ones would be better, at least I never understood which is the difference between those two kinds of notifications, just that some notifications go to one and the others go to the other one.

Also, the main problem I see with hiding the watchlist button by default is the discoverability of the feature. If the add/remove to watchlist button is important enough to hide the edit button in the "More" dropdown before the add/remove to watchlist button in narrow screen widths, why is the button to access that watchlist hidden by default? I would understand hiding it in the dropdown when there isn't enough space, but hiding it by default decreases drastically its discoverability.

See also a alternate : change the order of buttons in the new user menu - https://phabricator.wikimedia.org/T288913

Quick update: on fawiki, I turned the user script to a gadget based on user feedback. You can now find it at fa:MediaWiki:Gadget-watchlist-icon.js. It is also smarter now, and will only get activated in new Vector.

I second the request.

I personally also use my user contributions to access the pages I have edited recently and to follow-up on discussions, not sure how common that is.

I do the same (dozens of times every day), and I guess other experienced users too.

That watchlist and user contribs are hidden may not be a big deal for new users, but it is for experienced users. Maybe the best thing to do is to allow registered users to easily customize which links are directly accessible without using the new droplist menu.

Just want to leave a note here that we are monitoring this discussion as well as usage data. We want to make sure that our change does not lead to a significant decrease in usage of the watchlist itself directly from the page (vs a bookmark, for example). I'd also like to second @Jdlrobson's point that the sticky header will also make this functionality additionally easier to find.

That said, we are exploring a few different options on presenting the watchlist in an easier manner and hope to have an update and decision made on next steps by the end of this week.

@Jdlrobson gave me a good suggestion for the gadget to be more resilient to future changes and I also just made it compatible with both LTR and RTL interfaces.

When paid developers (who don't seem to use the site as power editors or vandal fighter or ...) destroy the workflow of thousands of free editors and some of them complain, I fully expect to restore the software back to what worked.
If you still need to explore options: Do it! But do it AFTER restoring the workflow and BEFORE destroying it again with other tests!! There have been clear stated expectations about this point, when the new prototype was shown (including the feedback of over 300 users!).

Another bad side effect of changes like this is the lost faith and trust in the new skin. We explain the new chances and why something old has to be changed and a day later new users just see that nothing works anymore as expected. No information in advance, no explanation, no plan .... sorry but this can't be the standard for a tech company in the 21st century as this is not a platform for script-kiddies.

Hi @Mirer, please see and follow https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette and https://www.mediawiki.org/wiki/Code_of_Conduct if you would like to be active in Wikimedia Phabricator. Thanks for your understanding and for keeping a respectful tone.

In T288638#7285276, @ovasileva wrote:

That said, we are exploring a few different options on presenting the watchlist in an easier manner and hope to have an update and decision made on next steps by the end of this week.

I believe it's helpful to approach this question using the 'Obvious, Easy, Possible framework':

Obvious is all about always. The thing(s) people do all the time, the always stuff, should be obvious. The core, the epicenter, the essence of the product should be obvious.

Beyond obvious, you’ll find easy. The things that should be easy are the things that people do frequently, but not always. It all depends on your product, and your customer, but when you build a product you should know the difference between the things people do all the time and the things they do often. This can be hard, and will often lead to the most internal debates, but it’s important to think deeply about the difference between always and often so you get this right.

And finally are the things that are possible. These are things people do sometimes. Rarely, even. So they don’t need to be front and center, but they need to be possible.

If I may, I suggest that we take the menu items and group them into the three categories. This categorization should be based on the feedback here (mostly experienced editors, it seems), usage data, and tests with new editors.

Based on my belief that "editing and curating an encyclopedia" is the core of the 'product' Wikipedia for editors, this is what I believe this looks like:

Obvious

• Watchlist
• Sandbox (for wikis where this is the default way to start new articles, perhaps rather "create draft"?)

Easy

• Talk
• Notifications
• Contributions

Possible

• User page (placed here because it is seldomly needed/edited, but if the user name is shown permanently, which makes sense in my opinion, it should continue to link to the user page)
• Preferences
• Beta
• Translations
• Uploaded Media (that's "obvious" or "easy" for Commons)
• Logout

From my perspective the updated user tools area is meant to be a flexible (and in a perfect world configurable). From our first conversations about it as a team we anticipated that some people would have strong preferences about certain tools/links being accessible directly in the header, while other people would feel okay with them being in the menu. As I understand it there are several different kinds of editors, and each have their own workflows and preferences. I didn't anticipate getting this "right" at the beginning. The whole reason we are putting prototypes, and releasing to a limited number of wikis is because we anticipate, and very much want, to get feedback, and then make changes accordingly : )

I appreciate this discussion — it's great to get feedback, and as @ovasileva mentioned we're paying close attention to it. And at the same time I feel a bit saddened, because it feels like the people giving us feedback don't trust us, or at the very least are not assuming good faith.

Surprisingly only two people mentioned the watchlist needing to be outside of the menu during our prototype testing. If we had heard from more people about the Watchlist we would have been more aware of this need earlier on. Now we are hearing from you all, which is great, but again I wish it could be a more collaborative, constructive, trusting discussion.

Because the design was meant to be flexible I don't think such a change (whether it be Watchlist, Sandbox, or some other tool that a certain group of editors find to be important) is difficult to accommodate:

I do wonder if the Watchlist is used as commonly on other projects (e.g. Wikidata, Commons, etc.), or if it's more Wikipedia-specific?

Also +1 to @Agabi10's idea of combining Alerts and Notices. Unfortunately our team won't be taking on that challenge during this project, however I think it's a great idea which has been detailed here T142981.

In T288638#7296733, @alexhollender wrote:

... it feels like the people giving us feedback don't trust us, or at the very least are not assuming good faith

I am sorry if you feel that way. But I don't think your feelings are wrong. I, for one, lost some of my trust in this process.

Trust is created by consistency over time. It is much harder to create trust than to break it. An easy way to break trust is by breaking consistency.

It has been consistently easy for me to access the most used features of user-links which for me--and I argue, for many experienced users--includes the notifications and the watchlist. The moment this consistency is broken, I lose my trust of the product, and by that token, of the team behind the product.

Your team has a tough job. It is no surprise that your team works based on small incremental changes and small scale testing (that is how Agile works) but it is a bit surprising that once you get push back, you don't quickly correct your course. "It will be configurable" is not an Agile answer; for a user who just lost some of his trust, that translates to "we get to it when we get to it".

It saddens me too.

In T288638#7296733, @alexhollender wrote:

Surprisingly only two people mentioned the watchlist needing to be outside of the menu during our prototype testing. If we had heard from more people about the Watchlist we would have been more aware of this need earlier on. Now we are hearing from you all, which is great, but again I wish it could be a more collaborative, constructive, trusting discussion.

Great observation. I was one of the prototype testers, but the prototype does not do a good job in mocking up my on-wiki workflow so I had no reason to check a non-functioning Watchlist on the prototype and I did not even notice that the Watchlist was moved into the menu. Good example of when prototypes are necessary but not sufficient steps in UI evaluation. To complement it, you need live pilot tests (like you did now) and a mentality of being ready to quickly course correct based on feedback from live testers.

I am personally mixed between the goal of staying sober by default, and the need ''of fast'' for experienced users. Also, I understand why only notifications are outside the menu, because they are not links, they open a box with all our notifications.

I see three sustainable solutions for actualy dissatisfied users if Watchlist and Contribution remain in the submenu :

• Get used to this change and develop a form of automatism afterwards
• Use keyboard shortcut
• Use a gadget or or an integrated preference system

In T288638#7296733, @alexhollender wrote:

at the same time I feel a bit saddened, because it feels like the people giving us feedback don't trust us, or at the very least are not assuming good faith.

I can only speak for myself, of course, but my feedback and suggestions are in no way a sign of mistrust or written under the assumption of anything but good faith. I'm sure that we share much of the same goals around the UI. Since I know from personal experience how difficult it is to design features/interfaces for a diverse group of users and how valuable every bit of feedback can be, I've tried to offer early feedback and suggest possible questions to look into. (I'm also aware that my usage of Wikipedia's UI might not be what everybody else does but at the same time I know that many users rely on workflows that can seem peculiar even to fellow editors and are therefore easily broken by seemingly miniscule UI changes.)

I believe that the two sub-tasks you are now working on are exactly the right next steps to take, I'm looking forward to learning more about watchlist usage in different user groups and projects.

In T288638#7314454, @Cirdan wrote:

In T288638#7296733, @alexhollender wrote:

at the same time I feel a bit saddened, because it feels like the people giving us feedback don't trust us, or at the very least are not assuming good faith.

I can only speak for myself, of course, but my feedback and suggestions are in no way a sign of mistrust or written under the assumption of anything but good faith. I'm sure that we share much of the same goals around the UI. Since I know from personal experience how difficult it is to design features/interfaces for a diverse group of users and how valuable every bit of feedback can be, I've tried to offer early feedback and suggest possible questions to look into. (I'm also aware that my usage of Wikipedia's UI might not be what everybody else does but at the same time I know that many users rely on workflows that can seem peculiar even to fellow editors and are therefore easily broken by seemingly miniscule UI changes.)

I believe that the two sub-tasks you are now working on are exactly the right next steps to take, I'm looking forward to learning more about watchlist usage in different user groups and projects.

@Cirdan thanks for your note clarifying your intentions, and I apologize for generalizing about all of the people who have provided feedback.

One thing that is maybe worth considering is your language in the task description, specifically "I'm very certain that this is quite common among Wikipedia authors". I personally try to phrase things as questions, rather than statements, especially if I don't have data to show. I wonder how the tone of the task description might have changed, and perhaps invited a more collaborative discussion, if you had said "I wonder if this is common for other editors as well?". For me the way you phrased it perhaps added a sense of urgency that, again just in my experience, isn't necessarily helpful to a collaborative and clear problem solving process.

Je pense que, lorsqu'on teste une nouvelle interface bureau sur des wiki non anglophones, et que des gens font l'effort de s'exprimer dans une langue qui n'est pas leur langue maternelle, il n'est pas très judicieux de leur reprocher leur «language» ou leur «way you phrased». Cela ne me parait pas très inclusif. Je pense que je ne reviendrai plus faire des retours qui me semblaient constructifs.

@HB I appreciate you calling attention to that, and I am sorry if my attempt to discuss language/phrasing with @Cirdan makes you feel excluded, or seems like a non-inclusive action in general. Language barriers make these discussions more difficult in my experience. For whatever it's worth, according to their user page @Cirdan is: en-4, This user has near native speaker knowledge of English.

In T288638#7328969, @alexhollender wrote:

One thing that is maybe worth considering is your language in the task description, specifically "I'm very certain that this is quite common among Wikipedia authors". I personally try to phrase things as questions, rather than statements, especially if I don't have data to show. I wonder how the tone of the task description might have changed, and perhaps invited a more collaborative discussion, if you had said "I wonder if this is common for other editors as well?". For me the way you phrased it perhaps added a sense of urgency that, again just in my experience, isn't necessarily helpful to a collaborative and clear problem solving process.

I appreciate the feedback regarding the language! I have slightly revised the task description to clarify that this statement in particular is based on my (non-representative, but extensive) observations.

In T288638#7336690, @alexhollender wrote:

@HB I appreciate you calling attention to that, and I am sorry if my attempt to discuss language/phrasing with @Cirdan makes you feel excluded, or seems like a non-inclusive action in general. Language barriers make these discussions more difficult in my experience. For whatever it's worth, according to their user page @Cirdan is: en-4, This user has near native speaker knowledge of English.

While I'm not a native speaker, I do write and speak English frequently in my professional life and I value Alex' attempt to help me understand why my phrasing lead to the impression that I was mistrusting the team or making unsubstantiated statements. @HB, while I fully agree that can be very difficult for non-native speakers to find the right tone and we should all keep this in mind, I believe that in this instance, the "miscommunication" can be fully attributed to the difficulties of written communication. (I doubt that Alex would have had the same impression if we had spoken face to face.)

I just wanted to say I appreciate the great example set here by @Cirdan and @alexhollender with regards to giving and receiving feedback in a civil manner. Sending you both wikilove!

100% agree with Cirdan's request and seconding his observations. The Watchlist (together with the My Contributions page) more or less serves as Wikipedia's 'user dashboard', so it should be as accessible as possible.

If I may add a suggestion: We should merge the 'notifications' and 'messages' buttons. I never understood the difference between the two anyway (seriously!). (Maybe I should file a separate bug for this...)

In T288638#7382823, @Gnom1 wrote:

If I may add a suggestion: We should merge the 'notifications' and 'messages' buttons. I never understood the difference between the two anyway (seriously!). (Maybe I should file a separate bug for this...)

👍, we have a task for that here T142981

For some anecdata, I've been using Timeless for 4 (?) years and I have to say, clicking through to the Watchlist (and Contribs and whatever else happens to be in that portal on a given day) does not present me with any issues whatsoever. (And I chronically am clicking those two links, so I agree they're important.)

Taking it out of anecdata land, there are going to be tradeoffs for whatever happens. I do not think the 'arbitrary links' version of the world is sustainable, especially if, as I expect, new Vector intends to become the default interface at the mobile as well as desktop resolutions.

@Izno thanks for your comment.

In T288638#7535311, @Izno wrote:

Taking it out of anecdata land, there are going to be tradeoffs for whatever happens.

I very much agree with this and think that "tradeoffs" is a helpful framing to think about all of these changes with.

Just leaving a note here that T289619: Move Watchlist button outside user menu dropdown is on this week's train and will be available next Thursday to all wikis.