Talk:Readers/Reader Experience/Reading lists

Important distinction between public and private lists

I can see no reason the community would have any significant concerns or objections to the current project. However out of an abundance of caution, and in the interest of averting hypothetical future issues, I wanted to make note of a past project involving public lists. It was called Gather. As far as I'm aware it was conceived and built to completion effectively without informing the community, with no meaningful community review or input. Things got a bit ugly because the Foundation lacked effective mechanisms to receive and act on feedback that there was a problem with the project. The developers saw it as a simple and obviously unobjectionable project. They assumed the community would do the work of policing any illegal or offensive content, like we do with all other content. Implicit in that assumption is that the project wasn't viable without active community support to police the content.

The community was actively unwilling to police public article lists. To oversimplify: The community is willing to do crappy drudge-work when it's necessary to support the noble public encyclopedia, but not willing to be unpaid moderators for what is essentially private-users'-social-media-content. The community was also unwilling or unable to create and apply moderation criteria for the public lists, but it would be complicated to explain why it is so problematic compared to the policing and moderation work we currently do.

As far as I'm aware absolutely none of this is relevant to the current work. However I would strongly request that the primary documentation on this project include a prominent note for the future. Everyone on the current team will eventually move on. Years from now some new team could take up work on this project, unaware of the issues. I would suggest emphatically documenting that public lists failed in the past, and that no attempt be made to make these lists public without (1) thoroughly understanding why Gather failed and (2) getting active buy in from the community. Alsee (talk) 01:37, 7 December 2025 (UTC)

Thanks for flagging this @Alsee. The Gather project and the issues around public lists are known to the team, and several people involved in this work were also around at that time and are aware of the context and lessons learned.

As you said, even though the current project does not propose public lists or assume community moderation of user-generated list content, we should explicitly document Gather and why public lists failed is well taken. Teams change over time, and capturing this will help ensure these issues aren’t unintentionally revisited in the future. We’ll make sure this history is clearly noted in the primary project documentation.

Do you have any other thoughts or feedback about reading lists? Would you consider using them in your editing work or reading practice? EBlackorby-WMF (talk) 15:59, 16 December 2025 (UTC)

Watchlist-star location & allowing notes

Came here after I saw the mockup on the right and meant to ask for the watchlist button to not be moved (I have the Tools sidebar always collapsed) but now I'm not so sure anymore if that's a problem and might have to use this a while.

It would be great if one could allow notes for bookmarked pages – see also m:Community Wishlist/W437. Prototyperspective (talk) 22:46, 20 January 2026 (UTC)

Thanks @Prototyperspective! For the watchlist button question, we're still thinking that through. For the future beta feature, if the beta feature is toggled on, they will get access to reading list, but the save/reading list buttons will be primary buttons. if it's toggled off, they won't be able to save articles, but they will keep their watchstar as primary. Later on we may be able to introduce a settings toggle for whether people want watchstar or save as their primary button. Curious your thoughts on that.

I'll pass along the Notes for watchlisted pages wishlist to some folks working on the Editing teams, interesting idea! EBlackorby-WMF (talk) 22:11, 3 February 2026 (UTC)

Yes, it's good to enable the user to customize it to their liking via a setting. I think it should have three selectable (dropdown) values: watchstar, bookmark button, or both as primary buttons. The question then would just be what to make the default.

Making the bookmarks button the default incentivizes people to use that which can keep the watchlist not as overflooded, checked more consistently and to increase adoption of the feature; making the watchlist the default incentivizes watchlisting pages which is very important early on when users get started, and for having more people check more pages, and also bookmarks are rarely checked while watchlist pages are frequently seen on the watchlist. Unsure which would be best; maybe bookmarks button for those users with >100 articles on the watchlist and watchlist button for all the rest?

Thanks! Maybe the notes idea would be best to combine with both the new watchlist labels and bookmarks. Prototyperspective (talk) 18:04, 4 February 2026 (UTC)

Prior community wish

See m:Community Wishlist Survey 2021/Mobile and apps/Have Apps reading lists available on Destop/Mobile. The two pages do not link to each other. It was highly supported in the survey. Prototyperspective (talk) 18:11, 27 February 2026 (UTC)

@Prototyperspective, thank you for linking! We were definitely inspired by this one. I'll add it to the documentation to make it clearer. EBlackorby-WMF (talk) 16:44, 26 March 2026 (UTC)

Thanks. Also related is W505: Show recommended articles on Wikipedia Main page on desktop & mobile web, not just in app of the ongoing Wishlist. Prototyperspective (talk) 17:11, 26 March 2026 (UTC)

Don't replace watchlist menu icon

Tracked in Phabricator
Task T424600

Tracked in Phabricator
Task T426453

The watchlist is one of the most important features for regular editors. While I appreciate your work on reading lists (especially given the frequent confusion by mobile app users who can't find the feature on desktop / mobile browsers), I believe it shouldn't replace the watchlist icon. It takes an extra click to navigate to the watchlist unless I disable the reading list beta feature entirely – should be the other way around: Leave the watchlist icon where it used to be and move the reading list icon to the drop-down menu in V22 (or at least offer a preference which icon users want to show by default). Johannnes89 (talk) 13:53, 20 April 2026 (UTC)

Following up on this: I have wanted this feature (a synced reading list) for a while, and I'm excited to use it when in its final form. But I am disabling it now because it's important for me to have the watchlist available without an extra click. Do consider the option to have both enabled simultaneously. And, separately, I would encourage reflection on iconography. The watchlist has a "saved filters" icon that looks pretty similar to the saved articles icon. Thanks for all your hard work! SSR07 (talk) 15:05, 20 April 2026 (UTC)

Hi @SSR07, thanks for this feedback! You can definitely have both enabled simultaneously. The watch function just moved to side toolbar for this beta feature rather than the watchstar. In the final feature rollout you will be able to personalize which icon to have at the top versus the sidebar (so you will be able to choose whether to have the watchstar at the top of the page, or the save icon.) EBlackorby-WMF (talk) 18:28, 22 April 2026 (UTC)

This may be off topic, but are there any plans to make the toolbar fully customisable? I think that'd be a lot more intuitive than just having these two specific icons be switchable. Regardless, I do hope you know that your work is appreciated! It must be difficult being tasked with redesigning such a widely used interface. Loytra (talk) 08:51, 7 May 2026 (UTC)

Same here! As an editor the watchlist is way more important to me than the reading list (though I like both). I got really confused because I had "Automatically enable most beta features" enabled and the button was suddenly switched. From muscle memory I automatically go to that button to open the watchlist. HurricaneZeta (talk) 19:16, 20 April 2026 (UTC)

It's hard to believe that anyone will have more than a few dozen articles saved to their reading list, while there may be hundreds of articles on one's watchlist. They're being added automatically with some page actions, so having an easy-access button to remove them from the list is a must. I don't think hiding the star button was a reasonable decision, tbh. If you want people to notice the new option, add the new button but keep the old. pon_or (talk) 19:16, 20 April 2026 (UTC)

I said this in May 2025 when this feature was in development so I can only +1 again here. This design decision is extremely weird and violates principle of least astonishment in a major way, even if you’re not a very experienced editor. And then it makes people choose between having access to beta feature or having easy access to watchlist, which is pretty much the most important special page available to registered users (even if some WMF designers at times didn’t agree). stjn^[ru] 00:26, 21 April 2026 (UTC)

@Stjn, I think what happened was that they did not consider the scenario of editors having beta features enabled by default and instead assumed folks who would be using this feature would be new users or users who had explicitly opted in. Sohom (talk) 03:57, 21 April 2026 (UTC)

(No need to ping.) I think either way it is not something that should’ve been pushed to production. What happens when a reader becomes an editor? How do they get real access to the most useful feature on the website without turning off this feature entirely? I’ve asked this question on Discord when the feature was developed and didn’t really get a response, but it’s exactly why any such button should’ve only been added in addition instead of replacing anything. stjn^[ru] 10:12, 21 April 2026 (UTC)

I came here to add my voice to this. I was excited when I heard this feature was in beta, enabled it for a minute, and turned it off once I realized I'd lose my watchlist button. Seems like a poor design choice. I'll be looking forward to seeing where this ends up. MediaKyle (talk) 00:39, 21 April 2026 (UTC)

Agree. For contributors, the Watchlist is where the action is and the icon needs to be easily accessible without extra configuration. If we want to convert new readers to eventually become contributors, they need to be able to find the Watchlist easily, too.

I'm also a little concerned that the "star" to watch pages disappeared and was supplanted by the "save" icon. I would expect to have the choice of both: either watch the page, or save the page, or both...? Cielquiparle (talk) 05:47, 21 April 2026 (UTC)

i strongly agree with this. surely the reading list icon and watchlist icon can be next to each other, right? Ltbdl (talk) 12:08, 21 April 2026 (UTC)

Hi @Ltbdl, thanks for this feedback. The reason we didn't place both buttons next to each other was because 1) it was really confusing to non-editors, who could not distinguish the different functions between the two icons and 2) it further clutters the already tight menu space, making things tougher to read on smaller screens and mobile. While we definitely see the appeal of having both buttons in the same menu, it didn't perform well from a usability standpoint. EBlackorby-WMF (talk) 15:54, 21 April 2026 (UTC)

Ditto; although I am aware that some editors prefer reading articles for leisure, the vast majority of editors use the watchlist function. Per Ltbdl, I think both icons can coexist. Alternatively, when an editor creates a new account, they could be given a choice as to whether they want the button to be their reading list or watchlist, perhaps through some pop-up window? Icepinner (talk) 13:14, 21 April 2026 (UTC)

Oh as an update, I've turned off the automatic beta feature functions on my settings just to get my watchlist icon back. Just saying. Icepinner (talk) 01:05, 26 April 2026 (UTC)

+1 Please put the watchlist icon back!!!! I'm disabling it for now but I'd happily have both on the bar without it feeling too cluttered. JacobTheRox (talk) 14:22, 21 April 2026 (UTC)

I don't edit much as I am not comfortable with it yet and don't have much time, but I agree that adding both to the bar will be fine and not make it feel too cluttered. Most users are more casual users than editors, and therefore would rather want to save something for Reading than wanting constant updates via Watchlist for editing.

Perhaps users can be allowed to re-arrange the positions of their icons (Reading List, Watchlist) and tabs (Page, Discussion, Read, Edit source, and View history) to their liking, and select which they want on the bar vs hidden in a dropdown.

It can perhaps be implemented in the same way as browser extensions / top bar browser layout with spacers and dropdowns. Some layout limits can still be imposed (like keeping Page and Discussion to the left and the others on the right) if spacers are difficult to implement. Users can then freely choose where they want their icons in a configuration that best suits their needs.

I do not think natively putting the Reading List under a dropdown will encourage users to use it -- casual users likely won't know that Wikipedia has that feature unless they already use the app, so they won't go look for it either in a dropdown or otherwise.

Casual users are more likely to save articles for reading (Reading List) than editing (Watchlist), but are also less likely to just click dropdowns to see what is there. Currently, these users either save articles by:

(1) using their browser's Bookmarks / Reading List / tab groups -- doesn't always easily sync across devices for various reasons (like using different browsers), and even if synced is often unwieldly to navigate, so there's less chance of them returning* to read it,

(2) sending the article to themselves via email / messaging app -- either as a link, or by exporting the article as a .pdf (more effort than clicking save, also less chance of returning*),

(3) using the Watchlist feature out of necessity -- as mentioned, they probably do not care about all the updates and do not want more emails / notifications -- and would prefer a Reading List, since it links to the latest article update anyways,

(4) attempting to remember to read it later, then close the article never to return*.

• likely returning only for articles that are somewhat important to them / is a burning question or interest.

If hidden in a dropdown, they'll likely only find it if they know it is a feature on the mobile app, and/or look up how to save Wikipedia pages to their account, learn about it on social media, or there's a banner / note informing them of the feature (and maybe the difference between Watchlist and Reading List).

While I agree that Watchlist is important for editors, keeping both or allowing users to select which to display (only Watchlist, only Reading List, or both) would likely be optimal. CuriousPantologyCat (talk) 10:45, 8 July 2026 (UTC)

I was coming here to say this: the Watchlist is the most important source of "updates" for registered accounts, substituting reading list for watchlist is a disaster in the making. We already have an unregistered user interface that makes editing behaviours a "secondary" citizen to the reader's needs, forcing a reading-only function onto editors.... is just a recipe for making the learning process as a new editor harder. We have a long history of these kinds of features showing up in the mobile apps and displacing the possibility of mobile editing, pushing it to desktop and the mobile web as well, is not good faith.Sadads (talk) 15:36, 21 April 2026 (UTC)

Hi @Johannnes89, thanks for your feedback and apologies for any confusion here! While in beta mode, we opted to swap the watchstar default with the reading list save icon. We did this to allow us to gather the clearest possible data and feedback about the efficacy of the save articles feature while we're in the data collection and analysis period.

However, we absolutely plan to offer a preference toggle that would allow users to select which button is default in their menus when we roll out widely in July. EBlackorby-WMF (talk) 15:51, 21 April 2026 (UTC)

Thanks for your reply. Like many other users (I've read similar comments to the ones above on the enwiki Discord server and on dewiki's village pump) I have just disabled the beta feature due to the watchlist icon being replaced – even though I would be happy to test reading lists. Not sure if you get the data you want if experienced users disable the feature instead of actually testing it because the desired preference toggle isn't available yet... Johannnes89 (talk) 16:13, 21 April 2026 (UTC)

Just noting that the watchstar is not removed... it is moved to the more drop-down menu. If you have the menu pinned to the right side it is available with one click.

Is the issue here the lack of icon and existing position or us this something that just requires adapting to a new user interface? Jdlrobson (talk) 19:37, 21 April 2026 (UTC)

There's a "watch" menu option but that’s not what we are talking about. Our issue is about the watchlist icon in the top menu bar which is hidden in the V22 drop-down with reading lists enabled. Quick access to the watchlist is probably the single most important action for experienced users who typically watch hundreds or thousands of pages. Johannnes89 (talk) 21:31, 21 April 2026 (UTC)

People don't like making more clicks than necessary, as was already known after having to convince Vector 2022 team to add a watchlist button to the user links menu in the first place. What should've been done here was making the watch icon into a text label while keeping it at the same prominence (and absolutely not touching hard-won watchlist link in the user menu). stjn^[ru] 21:33, 21 April 2026 (UTC)

Got it. Note @Ponor and @Cielquiparle do seem to be referring to the watchstar for adding/removing items too so this was mostly aimed at them in case they missed the fact it was moved to the toolbox. There is a workaround for the watchlist button below. Jdlrobson (talk) 16:55, 22 April 2026 (UTC)

@Jdlrobson I keep all my drop-down menus closed, there's almost nothing there that I need on a regular basis (and the menu is already overcrowded). While I do have a few articles saved for later reading in the Android app, I don't think I'll use the new feature button that much, and absolutely not as often as the watchstar. I'm fine with this being a temporary change. People who are here mostly to read will probably find the reading list option more interesting than us, hard-core users. pon_or (talk) 17:14, 22 April 2026 (UTC)

@Jdlrobson the watchstar is also used to indicate that I'm watching a page temporarily (watchlist expiry) which is not covered by the "(un)watch" option in the right menu. Johannnes89 (talk) 06:09, 24 April 2026 (UTC)

Tracked in Phabricator
Task T424571

Jon (WMF) (talk) 19:31, 27 April 2026 (UTC)

Will both be an option? That would be my preference. JacobTheRox (talk) 19:51, 21 April 2026 (UTC)

+1, The idea that we should replace the Watchlist icon with a "Saved pages" icon just to collect data is really funny.--Frettie (talk) 13:30, 22 April 2026 (UTC)

I just came here to say the same; I have deactivated my automatic opt-in to new beta features and the reading list feature to regain simple access to my watchlist. ToBeFree (talk) 00:02, 23 April 2026 (UTC)

As have I, which is a shame as it presumably means I won't be automatically enrolled JacobTheRox (talk) 09:06, 25 April 2026 (UTC)

I agree. The button's position made me disable the feature on desktop altogether. Michael21107 (talk) 17:53, 23 April 2026 (UTC)

Agree - this is a bad change. Please bring back the watchlist. Cinaroot (talk) 05:29, 25 April 2026 (UTC)

if people want to workaround this in the mean time you can add the following CSS to Special:Mypage/vector-2022.css - just note it might not work very well if you have lots of gadgets or a smaller monitor

html body header .vector-user-links #pt-readinglists-2 ~ #pt-watchlist-2 {
		display: block !important;
}

Jdlrobson (talk) 00:54, 22 April 2026 (UTC)

Like many others I initially deactivated the "automatically enable most beta features" option (for the first time in 10+ years as a Wikipedian). Then I decided to reactivate the beta feature option and tried your CSS (via my global.css) which made the watchlist icon appear again, but not the reading list icon. When I reverted the CSS change [1] and kept all beta features activated to test something, the reading list icon still wasn't visible (even after clearing my cache and trying in another browser). Johannnes89 (talk) 07:08, 26 April 2026 (UTC)

"I just came here to say the same; I have deactivated my automatic opt-in to new beta features"

Thje Beta-Team have lost now the really active beta testers for all future test! That was a very stupid idea! ~2026-24437-27 (talk) 10:42, 23 April 2026 (UTC)

Joining chorus here to say I was really surprised. Violated my muscle memory. I like the page reader as a concept, but not as a direct replacement for my more useful and similarly looking watchlist icon. Shushugah (talk) 22:04, 23 April 2026 (UTC)

1. metoo.

the decision to disappear the watchlist star is counterproductive.

i could live with migrating the add/remove linkettes to the tools menu - i do not add/remove pages from my watchlist all that often - but i miss the immediate visual indication of "this page is/isn't on your watchlist".

disappearing the watchlist star made me cancel this beta feature, and from this discussion it's clear i'm not the only one. this decision cost the feature a loss of beta-testers. my guess is, it's a significant loss.

peace. קיפודנחש (talk) 17:46, 24 April 2026 (UTC)

+1. The watchlist link is too important to editor workflow to remove. If WMF folks think that reading lists are equal in weight to the watchlist (which is debatable), or want to market it a bit to give it a chance to become popular, then perhaps both links/icons should be included side by side? –Novem Linguae (talk) 05:47, 25 April 2026 (UTC)

Could we have side-by-side on desktop only, if mobile screen crowding is the reason for forcing the choice between one or the other? Cielquiparle (talk) 05:22, 28 April 2026 (UTC)

Thanks for this.

We've heard the feedback and appreciate it. It helped us learn something really important, namely that we need to better consider the way that using beta feature functionality to test ideas for readers can affect, or in worst cases, break, editor workflows. Not doing this for the reading list icon/watchstar issue was a major oversight. The team is going to take this lesson and think about it for planning future beta feature testing, which we'll communicate as we figure it out.

To clarify, the purpose of this beta test was not 'should we replace the watchstar with the reading list icon?' it was 'do readers find value in the reading list feature?'. We therefore needed somewhere visible to put the icon for the purpose of visibility during testing in order to validate the reading list idea and function, but it was not intended as a permanent location - or at least not without a lot more thinking through where to put it and how it impacts both editors and readers. We will not roll out the feature without a configurable toggle for the button, and we are open to design ideas and changes.EBlackorby-WMF (talk) 19:41, 28 April 2026 (UTC)

I just would like to say that I also have disabled the new feature after a few minutes of testing due to its bad position in the user interface. The watchlist is the tool for working on any wiki, so it must be retained in the page header. What's more, on a desktop there is plenty of space available to place a new bookmarks icon next to the regular watchlist. No need to hide the watchlist in the drop-down menu. Very sorry, but this way I won't use the new feature, I won't even test it any further. Looking forward for a new stylesheet. Aschmidt (talk) 19:23, 28 April 2026 (UTC)

This is absolutely incompatible with the thrust of meta:Wikimedia Foundation Annual Plan/2025-2026/Global Trends/Users with extended rights. If "the gateway role to becoming a user with extended rights is patrolling", then hiding one of the most basic tools for patrolling from any user is putting a big roadblock in the funnel. Chipmunkdavis (talk) 17:07, 1 May 2026 (UTC)

Thanks @Chipmunkdavis, definitely heard on the importance of the watchstar to users with extended rights. Just a note that it would not be hidden from editors, only readers – defined as people with accounts with zero edits. The evidence suggests that people don't tend to start editing from the watchstar, and that they begin to really utilize the watchstar only after their first 100 edits, so we wouldn't anticipate this negatively impacting newcomers. For editors at any stange in their journey toward patrolling, they would still see the watchstar. That said, all of this is still very much under review and subject to change based on community feedback. EBlackorby-WMF (talk) 18:29, 1 May 2026 (UTC)

My note was that as defined by the Annual Plan the watchstar is important to all users, not just those with extended rights. 100 edits is very early, it's good news that those with 100 edits begin to use their access to this fundamental feature. Chipmunkdavis (talk) 02:50, 2 May 2026 (UTC)

Hello, personally this function made me disable the “all on” by default on the beta functions. I strongly agree that the OS button should not be replaced. I saw up here that we’ll be able to personalize it but for the moment I just turned it off GiovanniPen (talk) 08:10, 3 May 2026 (UTC)

I think you misunderstand -- the watchlist is the mechanism for registered users to interact with eachother without understanding the technical complexity of the wikis -- removing it from the interface for users with less than 100 edits -- means that they won't try to play with the tool --- its not a confusing interface feature, removing it removes a fundamental mechanic of being part of the community (watching pages you care about, and interacting with others who do that). Reading is not a fundamentally social thing, you don't need a list or an account, contributing is a social thing and you need to be able to see other people as soon as you create the account. Sadads (talk) 03:19, 14 May 2026 (UTC)

Aschmidt and GiovanniPen said above what I just came to this page to say about my experience. I also concur strongly with Sadads. This was a bad mistake and lessons need to be learned about how to interact with the community before altering a core element of the UI.  — Hex • talk 09:21, 11 June 2026 (UTC)

I haven't edited for a few weeks. I have new pictures to attach to an article so I came back to look at recent changes to my watchlist before I do my work. And suddenly what looked like the usual icon took me to Saved Pages instead. I know how to get to the watchlist from the menu, but the only icon I ever use is now gone, and there is no setting to restore it. Is the system assuming that an Wikipedian with an explicit account would prefer a personal Saved Pages over a Watchlist? I find that hard to believe. But then perhaps I am the odd one out there. Why can't Saved Pages be a view of my watch list? Or a labeled/personally-classified version of a simple list of pages I watch? Just thought to put in my two cents. Fred Hsu (talk) 22:54, 11 May 2026 (UTC)

Hello, I would also be interested in an option for both.

I think the reading list as a default, with the watchlist as a secondary action in a menu, is very good.

But for my personal use case, I’d like to be able to have it at an equal with the reading list, both in the navigation and in the page actions.

Those are the options I imagine:

• Reading list primary (default)
• Watchlist primary
• Both reading and watch lists primary (what I would check)

For existing users, I also wonder if hiding the watchlist from one day to another is the best UX. Could there be a check, for instance whether there is at least 1 item in the watchlist? Or some similar data.

• For logged-out and new users, show reading list as primary
• For existing users that have no item in their watchlist at the time of the feature launch, show reading list as primary too
• For users that have items in their watchlist at launch, you could for instance: display both as primary, and open a little popup presenting the feature and enabling to choose between the three display options above

Additionally, I think the stars for watchlists are becoming a little ambiguous now, since stars are also used for bookmarking in browsers, social networks, etc. Could the iconography for the watchlist be updated, for instance to an eye?

Great project otherwise, looking forward to see how this feature evolves. Also can’t wait to have it on Commons as a native replacement for Commons:Help:Favorites! Nclm (talk) 16:08, 15 May 2026 (UTC)

@Nclm Thank you for all of this! Super helpful ideas that the team is thinking through as we continue to refine this feature.

The plan for the full feature was always to default to showing the watchstar for anyone with at least 1 item saved to the watchlist. It would only show the bookmark as default to logged-in users who had never saved anything to their watchlist, and even then, it would still be configurable.

That being said, based on the feedback shared here, we are now revising the design to test out offering both watchstar and bookmark buttons as default.

We've also heard from a lot of people similar thoughts on potentially changing the watchstar icon, and that's definitely something we're open to exploring more. EBlackorby-WMF (talk) 16:49, 11 June 2026 (UTC)

phab:T426453 is now up. Looks like the revised proposal is now to have both on desktop, reading lists only on Minerva, and on desktop add the word "watch" next to the watchstar so that readers don't think it's a bookmark. –Novem Linguae (talk) 05:45, 16 May 2026 (UTC)

Great work on the tool, but could you please allow the star icon next to the save icon in the watchlist? It's really annoying that the option to add pages to the watchlist isn't showing up.Althair (talk) 16:59, 1 June 2026 (UTC)

Hi @Althair, with our new design revisions [see Phabricator:T426453] the star icon will remain next to the save icon on desktop. These changes should roll out during the beta period so you'll be able to see and test them soon. EBlackorby-WMF (talk) 16:52, 8 June 2026 (UTC)

Thanks for the redesign. I've tested it and now I switched it off again for keeps because I do not need the feature. Aschmidt (talk) 22:19, 18 June 2026 (UTC)

I like the idea but I've had to turn it off because it hides the "Add to watchlist" button from the sticky bar at the top of the article when scrolling FaviFake (talk) 11:40, 20 June 2026 (UTC)

Some items there cant be deleted

I have items in saved that don't show as saved on the page, so I can't delete yhem, and when I clik add to saved, it just creates a second identical item. Smeagol 17 (talk) 21:02, 20 April 2026 (UTC)

Hi there! Thanks for raising this. We discovered an issue where articles names were not normalized in a standard way in the API previously, causing some duplicates like the items showing up in your saved list! We have prepared a fix that should roll out next week that will retroactively remove these duplicates from your list. HFan-WMF (talk) 19:47, 21 April 2026 (UTC)

Lets use that desktop space

I started using this experiment today, and I quickly learned a few things....This is a very prominent location for something that had a different function before!!! If this project is claiming that space, I think it should make better use of it. For instance:

1. Explain what this page is/does with a (dismissible) preface
2. Give me a link to quickly get to my watchlist (button next to Tools menu?)
3. The tiles, could have a vertical action bar to on their right side, to DO stuff with them (remove/watch)
4. I want to quickly move a bookmark to my watchlist, and/or see if it already is on my watchlist
5. When did I add this ? (5 weeks ago)
6. How many bookmarks do i have ?
7. Group in collections... with drag and drop
8. Then delete an entire collection
9. Get creative

The point being, if we want this to succeed I need more value for a feature this prominent. —TheDJ (Not WMF) (talk • contribs) 11:54, 24 April 2026 (UTC)

Oh, and one note. any metrics about how often this feature is opened, are going to be heavily skewed by me accidentally choosing this, instead of watchlist. So please take that into account when collecting metrics to proof the popularity of this feature. —TheDJ (Not WMF) (talk • contribs) 12:03, 24 April 2026 (UTC)

@TheDJ these are all great ideas. The feature is intentionally kept relatively small in scope right now while we get it set up and rolled out, but we definitely hope to build upon it with additions like these. Collections in particular is something we want to explore more, as well as categories and personal usage information [like recency and numbers].

We're finding people love saving and don't always think to revisit [the classic 'million tabs bookmarked and left unread' scenario], so we'd like to think about ways to make returning to saved articles more of a common behavior. Curious if you have any ideas in that regard?

Also, noted on the metrics, thanks for pointing that out. EBlackorby-WMF (talk) 21:28, 24 April 2026 (UTC)

My point is, you cannot keep it small AND take over that spot. —TheDJ (Not WMF) (talk • contribs) 07:55, 25 April 2026 (UTC)

Perhaps there can be a "random article from your saved list" on the home page? I think I've seen it in the app before.

I really like the idea of adding Collections, and wanted to add it to my "What do you think of this feature" poll comment but clicked away accidentally before typing it, so it submitted without that addition.

It would be great if you could have an article in more than one Collection (treating them as "labels" instead of "folders") -- the Japanese language might fall under the atomic Collection of "Writing Systems", "Languages", and "Japanese"... but reading my saved articles on e.g. different Writing Systems means that I must find it in each language's saved Collection (Egyptian, Chinese, Arabian, Greek, Norse, Japanese, Russian, etc.) between everything else I saved about the respective language (main page, detail pages on grammar, counting, etc.).

Conversly, splitting a Writing System from its language into a separate Collection removes fundamental knowledge of the language itself. If I want to read my saved Japanese articles, I also want its main Language page and the Writing System page.

I also don't want to add everything under one mixed Collection, because not all pages fulfill the collective criteria (not all Languages have their own Writing System), and when I want to save a Collection (e.g. specific language) offline on my app for reference, I don't need all my language pages nor do I have space for them.

Since Wikipedia is essentially a collection of atomic knowledge pages all linked together, it makes sense that the saved article Collections system works similar. Thanks for everything you guys do to make things nicer for us. CuriousPantologyCat (talk) 11:38, 8 July 2026 (UTC)

activating with old vector (2010) skin

is there any known trick to do this? it's ok if the trick requires js. CSS, whatever.

will be grateful for any clue. maybe someone with AI access can ask?

peace. קיפודנחש (talk) 02:11, 27 April 2026 (UTC)

Hi @קיפודנחש, unfortunately it's only supported in Vector 2022 and Minerva currently. We added this limitation in response to a bug found in Monobook and additionally are no longer adding features to older skins. I will circle back if there's any further details. EBlackorby-WMF (talk) 16:35, 27 April 2026 (UTC)

New user feedback on en.wiki

Hello, I think this post(permalink) relates to reading lists. It requests the ability to sort the list into mini-lists. Chipmunkdavis (talk) 13:29, 18 May 2026 (UTC)

Oh hey! Thank you! I don't know how to link stuff yet so i just reposted something similar but then i saw your comment after so looks like i didn't even need to! appreciate you! SideraConscia (talk) 16:45, 20 May 2026 (UTC)

Thanks for linking here! It absolutely relates and it's great to gather more ideas for this feature. Mini-lists is definitely something we'd like to explore once we get the basic reading lists rolled out. EBlackorby-WMF (talk) 18:56, 20 May 2026 (UTC)

Hello,

I'd like to second this. In addition to being able to add notes to saved articles (mentioned above), I would find it important to be able to categorize the saves. I believe that this is currently a feature on the mobile app, a development I'd much appreciate on desktop, with the appropriate interconnection.

Keep up the great work!

Best,

Napets007 (talk) 04:19, 13 June 2026 (UTC)

Personal Lists for our saved pages

I would absolutely love the ability to sort all my saved pages into nameable lists. I've been loving the, saved pages beta feature, but the issue is that Ill just end up saving a ton of pages I'm interested in, that are all just randomly scattered and disorganized under the one long saved pages list making them very difficult to find later. I would just so appreciate the ability to create lists, name those lists, as well as a save to chosen list function. That way I can categorize, organize, and easily find the specific page Id like to go back to. I was just told that this, or something similar to this, exists within the iOS and Android Wikipedia apps which is awesome!! That being said it would still be so nice to have this ability on the official WIkipedia website, as that's what I mostly use with a windows pc. Anyways thought id just suggest it, hope this is the right place to do so. Thanks for reading <33 SideraConscia (talk) 16:37, 20 May 2026 (UTC)

Thanks for this @SideraConscia! We are definitely interested in exploring giving users the ability to categorize and organize their saved articles. In the future we're even thinking it could be interesting to look into the possibility to save quotes, highlights, images, and so forth from articles into themed collections. Right now we're most focused on rescoping the design with respect to community feedback on watchstar/bookmark icons for the feature rollout, but once the full feature is released and stable, we're excited to explore with the community ways to build upon it. So please do continue to share your thoughts and ideas here, and we'll keep you posted on how this work develops. EBlackorby-WMF (talk) 18:59, 20 May 2026 (UTC)

I agree with this - the option to sort according to self-created categories, date, etc., is essential for this to have utility. Unless I am missing something, what's the point of creating saved pages in categories if you can't go directly to that/those categories? WikSearch1 (talk) 20:14, 27 May 2026 (UTC)

appreciate you !! <3 totally agree haha otherwise id never find anything!! SideraConscia (talk) 23:48, 30 May 2026 (UTC)

Seconding this suggestion, it would be so great to be able to sort into saveable lists! Glad the people behind it are interested in exploring this option, hopefully it'll come soon :D Felinaex (talk) 05:58, 8 June 2026 (UTC)

Also I totally agree with everyone above me, talking about the watchlist. Personal lists shouldn't replace or move watchlists in anyway. Ideally they both sit right next to each other, in the same spot the watchlist icon has always been. All the icons can scootch to the middle a little bit to fit everything. There could be two similar but differentiating icons, indicating they are both different types of lists. I think there's plenty of room to add them both to the UI without one replacing the other.

Also, as a newcomer who has been just as interested in learning Wikicode, understanding how templates work, and figuring out how to contribute to Wikipedia (as well as other wikis), as i have been interested in learning random topics, collecting all the wiki pages i love, and reading. I don't see any need to leave the fun of beta features for only newcomers or to swap the savepage with watchlist. That being said, figuring this stuff out is what beta features are all about so I hope this is at all helpful haha, just thought id add my two cents! (: SideraConscia (talk) 23:44, 30 May 2026 (UTC)

Appreciate all of this, @SideraConscia! We're significantly updating the design to incorporate all the feedback we're receiving from editors, which we'll share on the project page. Thanks for giving us your thoughts and ideas. EBlackorby-WMF (talk) 16:08, 1 June 2026 (UTC)

commenting to hopefully bump this post up some . my preference would be that the saved pages features (categories, lists, saving quotes, images, etc., would take precedence over icon discussions/redesign . the star and the bookmark symbol seem good enough . but that's just my two cents; I'm extremely appreciative of any work the great people at WMF do :) TheBilldozer (talk) 08:36, 23 June 2026 (UTC)

Feedback on new design proposals

@SPatel (WMF) shared new designs on Phabricator. Some thoughts and questions:

• Why did you add "watch" to the watch star on Desktop but no label to the "save" icon (phab:T427226)? If there's an issue with distinguishing them, both should get a label – or none of them if you want to trust that people understand your onboarding dialog.
• Did you consider that the article top bar is more crowded for many users? Many large wikis show two buttons for editing articles per default ("edit" and "edit source" – e.g. German, French, Italian and Polish Wikipedia) – users can also activate this on other wikis like English Wikipedia via their preferences. And in non-English languages buttons take more space because non-English words are typically longer (e.g. "Nicht beobachten" in German instead of "unwatch") . Also some users choose to collapse the "tools" menu which takes additional space (and could even create the impression that the "save" icon illustrates the "tools" label). Example based on dewiki default settings and your mock-up: phab:F84390845.
• According to phab:T427226 the sticky header will only show the save action and hide the star to avoid confusion (unfortunately the task doesn't show a mock-up). Why did you decide to prioritise saving pages, even for logged-in users? I get that reading lists are important for readers and I like the feature as well, but watching pages is clearly more important for editor workflows.
• Related question: Why did you decide to prioritize saving pages over watching them for mobile users (phab:T427228)? The watch star is a long-established feature – unless your data shows that logged-in users will use the new feature more often, it should be the other way around (move "save" to the tools menu and keep the watch star where it is). Keep in mind that hiding the watch star doesn't just add an extra click for watching/unwatching a page, but also an extra click even for quickly checking if I'm watching the page I'm currently reading or not.
• I like the idea to show both icons for watchlist and reading list in the desktop header (phab:T427229) – and the proposal to fold both into the user menu on smaller screens.
• I like the onboarding dialog (phab:T427234) – but if you're worried about users being confused about watchlist vs. reading list, why don't you add an onboarding dialog for both features (or at least briefly mention watchlists and their purpose in the reading list onboarding)?

Johannnes89 (talk) 14:44, 26 May 2026 (UTC)

Thank you @Johannnes89 for raising these concerns. Sharing some rationale behind some of the current designs below:

Why save does not have label but watch does

• The save icon (bookmark) is universally known for bookmarking and does not require label for clarity. While star icon is universally known as favouriting/rating and needs a label to clarify what it means in our context. Having labels for both also means adding more to an already crowded space (as mentioned in your second point.)

Top bar being crowded

• We were informed about the other things in the space by editing team and also agree that labels can be longer in other languages. For now, we could resolve this by having a better responsive design, so items gets folded into tools menu as the viewport size shrinks. We are planning to do some cleanup with how items in the tool belt behave at different view ports. I think this is a good topic and we should have a separate discussion on what items makes sense to be shown above article - for e.g., if there are ways to optimize edit vs edit source in a way we don’t need to separate buttons, or if certain labels can be shortened such “view history” can be “revision” etc.

Sticky header

• I will add a mock in the ticket thanks for pointing that out. The rationale here is again that “Star” without a label can be confusing to readers and new editors. As sticky header does not allow us to put labels, we felt showing star would cause confusion as it may already be causing. Also our assumption here is that users may typically decide whether to Watch or Unwatch a page when they arrive on an article, whereas someone reading an article may decide to Save an article for later at any point during the reading experience - especially when they are in the middle of an article, unable to finish reading, and want to easily return to it later.

Prioritizing save over watch on mobile

• Again same reason of “Star” being confusing without label for readers and new editors. Also majority of users who create account will not have a use for Watch function immediately. Also there is more thinking explained on this phab ticket.
• For editors who have a need to use Watch more than “Save” function perhaps we could provide a way for them to switch? As they are less likely to get confused given they know and use the feature regularly.

Onboarding dialogue

• Ideally core UI actions should feel intuitive enough that they do not require explanation through onboarding or tutorials, since needing to explain functionality may indicate that the design itself is not clear. Also users often tend to skim past or dismiss pop-ups and onboarding prompts without fully reading them. Additionally , we may want to carefully evaluate what is the right onboarding for different types of users for e.g. if someone said they created an account for reading we may not need to share all editing features in onboarding just yet until the right moment arises.

Hope this helps clarify some of the design thinking behind the current approach. Happy to continue discussing this and finding better solutions. SPatel (WMF) (talk) 21:07, 27 May 2026 (UTC)

Apologies for not reacting (onwiki) to your detailed reply, too many to-dos 🙈 Thanks a lot for sharing your thoughts! I'm positive with the direction the project took after the recent discussions on Phabricator and Discord. Johannnes89 (talk) 19:13, 5 July 2026 (UTC)

Not working on ban.wiki

Tracked in Phabricator
Task T428002

Tracked in Phabricator
Task T428079

Hi @SPatel (WMF) and EBlackorby-WMF: , thanks again for this awesome feature. But this feature is not working on Balinese wikipedia. When click the icon always coming with this message An error has occurred: ⧼readinglists-db-error-no-such-project⧽ What should we do for that? Thanks in advance. Angayubagia (talk) 02:07, 3 June 2026 (UTC)

Thanks for reporting. We'll fix it as part of T428079 Jon (WMF) (talk) 18:00, 3 June 2026 (UTC)

There is a script we can run that will fix the issue, but e are fixing a few issues with the script to ensure it is safe to run. KFilbert-WMF (talk) 18:06, 3 June 2026 (UTC)

July of this year?

Why not a later time, like December of this year or January of next? Clearly, at #Don't replace watchlist menu icon, concerns about the Reading lead potentially replacing... or putting aside the star "Watchlist" icon haven't been eased yet, even with Phabricator tasks. Also, I hadn't discovered this Beta feature until just now. George Ho (talk) 18:55, 6 June 2026 (UTC)

Hi @George Ho thank you for the note. I definitely understand the thought process to delay further until all the kinks are smoothed out.

Before we roll out of beta into full production, we will edit the feature with feedback from editors and invite the community to try it with both watch and save functions available on desktop. That said, we have been working on this feature for over a year [we first shared it at Wikimania 2025] and it has been a longtime feature on the apps already. Since having a base version on web is a first effort to help us begin to reverse falling readership numbers, our preference is to get it out in July and keep iterating to make it better based on user behavior and community reception. EBlackorby-WMF (talk) 17:10, 8 June 2026 (UTC)

I created a task requesting expansion of Reading lists to other non-main namespaces (phab:T428348). What else can I convince you to delay making this permanent besides the #Don't replace watchlist menu icon thread? Also, the community–WMF relations from what I see has hit rock bottom lately. George Ho (talk) 17:17, 8 June 2026 (UTC)

@George Ho, Thanks for creating that ticket, someone from the team will respond there once they've had time to assess it further. Can I ask what issue or blocker you think delaying the feature will solve? Just want to make sure I understand so I can help advise the team accordingly. EBlackorby-WMF (talk) 18:47, 8 June 2026 (UTC)

Can I ask what issue or blocker you think delaying the feature will solve?

Hard question to answer, truthfully.

Can I ask what issue or blocker

What about the following tasks?: phab:T426502, phab:T424600, phab:T427229

As I see, there's a bug-related task: phab:T408229.

Also, you're planning to expand the feature those using temp. accounts (only if feature becomes permanent), right?: phab:T394568

delaying the feature will solve?

Besides being too rushed and premature IMO, I would hope you give assurances that the Watchlist feature and those using the feature aren't severely(?) affected. However, patience from those of the Watchlist era has been running out lately.

Again, I'm totally new to the Reading List feature again on mobile and for the first time on desktop view. Indeed, I still can't help using the Watchlist for pages on non-main namespaces.

Also, I'm very saddened that the updated expiry Watchlist options are no longer there. Rather we're still using the old version of the expiry Watchlist feature. What happened to it? George Ho (talk) 19:12, 8 June 2026 (UTC)

Got it. While the plan is to incorporate the feedback in the tickets you've linked here, we will still very much be hearing and incorporating community feedback before rolling out of beta into production. July is just the estimated time. All the tickets linked here are being actively worked on except the bug, which only affects browsers without Javascript so it's not very widespread.

For the Watchlist options, I'd recommend reaching out to the Moderator Tools team, which handles watchlist features. They would likely have better answers there! Thanks again for all your feedback and let me know if there's anything else I can answer. EBlackorby-WMF (talk) 20:25, 8 June 2026 (UTC)

Adding "list" layout in addition to "grid" layout?

Hello, I really adore this feature, thank you so much for making it!! I've been using it for the past week and would have two suggestions:

• 1. Would it be possible to have a "list" layout? I made some very basic examples to illustrate what I mean.

Currently, the layout looks like: (I will call it the grid layout)

.

It would be great if there was an option to have it look like this: (I will call it the list layout)

.

The user would be able to toggle between the options on the upper right, with waffle button for grid layout and hamburger button for list layout.

• 2. This is very very minor, but (assuming it would be easy to code) it might be fun to have a "Random article" option so people who have accumulated a lot of saved articles might have an easy solution if they aren't sure which of their articles they can read first.

(Caveat: I have 0 background in UI/UX)

Thank you for this feature, appreciate all the work you've done so far!! Felinaex (talk) 06:30, 8 June 2026 (UTC)

Hi @Felinaex, thanks so much for the comment and the mockups! Great to hear you're enjoying reading lists. A list view and random articles are definitely things we're considering for future updates. We're also considering exploring suggested articles based on what a user has already saved. Please feel free to share any other ideas you may have for expanding this feature. EBlackorby-WMF (talk) 17:47, 8 June 2026 (UTC)