I don't see any sign here of "editor engagement" thinking about Watchlists. Deficiencies in the watchlist system are a very, very longstanding issue, and cross-wiki watchlists in particular would support editor engagement with smaller projects, and secondary projects like Commons and Meta. Sue Gardner raised a general bug about this (Requesting a user-centred rethink of how watchlists work) over a year ago - did anything happen? Does anyone care? Are watchlists just not sexy enough?
Hi Rd.
I think people care, but watchlists aren't at the top of the priority list right now. One reason might be that the users' needs and use cases aren't as straightforward and easy to understand as for other features, like Notifications. Another reason is probably that global watchlists couldn't be implemented until we had a consistent SUL system. Since SUL finalization is now well underway, now is the perfect time to restart talking about global watchlists.
I think it would really help if someone could consolidate the existing discussions, bugs, feature requests, etc. on a page like Global watchlist. The main focus of the page would be on a watchlist that works across wikis, but the page could probably also benefit from prioritization of other related features and enhancements of the watchlist interface itself.
Apart from prioritization, this would probably also benefit from consolidating input from many users, to be sure that the use cases we're talking about are consistent with how people use their watchlists.
Basically, the questions we'd need to answer so that developers can work on global watchlists are those:
Some of these questions can be answered by going through existing bugs and discussions on bugzilla and wiki pages, and some will probably require talking to users to get their perspective.
Would you be interested in helping with this? You don't have to do it alone; I'm sure many people would be glad to participate and organize that page. I can also help in recruiting people, particularly if we want people with different backgrounds (power users, designers to help design the interface, etc.).
As a long-time Wikimedian active on several wikis, I certainly feel your pain and I'd love to finally be able to use a global watchlist. Let me know if you think you could help.
Hi, there is already en:Wikipedia:Integrated, interwiki, global watchlists as a starting point. It was hoped that Echo would provide a step in that direction (Serving as a "global watchlist" isn't the effective purpose of the design but it ends up being a side-effect - Thread:Talk:Echo_(Notifications)/Bundling_and_expiry), but from Echo/Feature_requirements#Watchlist_features it seems not. I suppose a MediaWiki page may help pull some issues together for a wider rethink of watchlists... (Bugzilla bugs are an absolutely terrible way to discuss complex issues like this) but really it needs some developer attention (eg to clarify technical issues and choices), otherwise it's just blowing in the wind. Given how long it's been in the waiting, I rather think it needs WMF support to happen. If some assurance of WMF support were given, I'm sure we'd be overrun with volunteers to organise a discussion on what people want!
PS on the "what other things might people want", see eg en:Wikipedia:VPR#Temporary_Watchlist, which is actually what prompted me to have another look at the status of watchlist developments. Also watchlist grouping.
Awesome, thank you! I'll reach out to developers to see if we get some momentum behind this, and I'll also try to find other people interested in organizing and prioritizing this wishlist. In the meantime, feel free to continue to improve and add to it.
Watchlist wishlist is quite a mouthful :)
I've been agitating for more work on watchlists, which I think are a critical and, sadly, much-neglected feature in our arsenal. As a result, the mobile team has actually done a significant UI overhaul on watchlists on the mobile site. I'd urge you to visit en.m.wikipedia.org (or the .m version of any Wikimedia wiki) and check it out for yourself. In addition to addressing some of the power user problems highlighted in your wishlist (e.g., improving selection/clearing of items, adding a direct unwatch link in the watchlist view), we're also just generally trying to make watchlists easier to understand for new users, who are resoundingly mystified/terrified by the strange mishmash of jargon and input/selection menus they're presented with when they visit their watchlist. The underlying concept (save pages you care about, follow changes to them) is actually quite simple, but the archaic Internet 1.0 interface in which we couch the feature ensures that only the bravest souls will persevere to figure that out.
I should note that the one major impediment to doing more design and development work on the watchlist is not that nobody cares (I do!), but rather that highly active users are extremely attached to their preferred watchlist workflow, and disrupting that even a tiny bit (as was the case with the much-maligned green-stars-next-to-unviewed-changes experiment) tends to cause a huge stir. The benefit of implementing some of these ideas on mobile is that there is little pushback from the existing community, so we can truly reinvent the watchlist from the ground up; the corresponding drawback, unfortunately, is that it's hard to validate whether the ideas are successful or not when most highly active Wikimedians aren't using them.
The green stars were an idiotic test by some en.wiki sysop in response (!) to absurd opposition to the standard very simple bolding which all MediaWiki users are used to. I wouldn't use green stars as an example, and the bolding is not an experiment.
My point was that any change tends to polarize (and bolding was actually offered globally for a bit in the same green star period and resoundingly rejected by a large, vocal community contingent, IIRC, which is why it's still an opt-in gadget). Not offering all this as a justification for not making changes, but simply pointing out that the high visibility power user pushback factor is something that has to be taken into consideration when prioritizing work on a feature like this.
On the contrary - the bolding (to which the green stars was a response) is an episode worth learning from. It tells us again that highly active Wikimedians don't like interface changes (remember Vector?). There was a big request for comment, concluding that the new (to English Wikipedia) watchlist highlighting be opt-in, as described in en:Wikipedia:Customizing watchlists.
What we should learn from this and previous episodes is basically that any interface change should
It's worth observing of course that this list doesn't apply in isolation; it depends on how much prior discussion and testing the interface change had. Given good testing and community collaboration in design for something that's clearly an improvement, even an imposed change that annoys quite a few people will eventually be accepted.
I opposed only calling the bolding an experiment or the green stars an example. That was rather a typical example of how, when a bad change happens, the opposers rush to make it even worse, so that the uprise explodes and then there is too much blood around to think of reasonable solutions. If only nobody had touched the watchlist style for a couple days or a week at most, no green stars invasion would ever have happened, most bolding would have disappeared from the watchlists (because users visit pages) and everyone would have got used to it. This is what happened on all projects.
In reply to Rd's comment about how it would be easier to find people to organize specifications / bug reports / feature prioritization if they had some sort of guarantee that there will be developers willing to work with them to implement the changes, I've started a discussion on wikitech-l to see if developers were interested in working on that issue.
a global watchlist feature could be helpful for improving how Wikidata notifies editors of changes in related Wikidata items. First step, there are some parts of the watchlist and recent changes (watchlist shares a bit of code with RC) code in MediaWiki that are in desperate need of cleanup. It's on highish our todo list in order to support enhanced recent changes mode. Along with unified single login, that would help make a global watchlist feature more feasible. :)
Global watchlists would also make any work that Meta and Commons do on behalf of many projects, visible and trackable by the communities on those projects. They would minimize the importance of deciding 'which wiki to hold a conversation on' for global topics. And they would facilitate multilingual discussion.
This is particularly true if these features are developed along with a "watchfeed" which is not a personal single-user watchlist but a feed of updates from a set of related pages. Then anyone interested in a topic can help curate the watchfeed for that topic - across wikis and languages. And others who want to follow that topic will have an information-dense way to do so. RC really implements a special case of watchlisting; both benefit from similar views and filters. Though for performance reasons you might want to restrict who can add large categories, or "en.wp:*", to a watchfeed.
Perhaps part of the reason this idea keeps being put off, despite being much requested, is that cross-wiki code of any kind seems rare. Commons and WikiData transclusion, and SUL code, are exceptions. Ideally we would have more than a patch job for a single feature. The APIs should be expanded to include any cross-wiki calls for a cluster of related wikis. But a cluster of wikis sharing users, templates, media, and topics: these should not be treated like two totally unrelated wikis.
Cluster-level APIs might eventually touch on:
A roadmap for this kind of support for cluster-level development might make it easier to see how to globalize watchlists and RC.
