Talk:Watchlist wishlist/Archive 1

After removing spam I tend to check the user contributions of the spammer to see what else they might have spammed. So, I second the motion/wish that there be the ability to add someone's "user contributions" to the watch list.

I would like the diff link in the watchlist show changes since my last visit, not just the diff of the last edit made to the page. Or maybe there should be two diff links. I can go view that diff in three clicks now, and it would be very convenient to be able to do it in just one. I guess this should not be very hard.

Are you using the extendedwatchlist preference ("Expand watchlist to show all changes, not just the most recent")?

Whoa, never noticed that. Just tried it, and it does not seem to be what I want. It looks like a diff of changes made within the span of the whole day, not just since my last visit.

Watchlists

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:

• How do users use their watchlist?
• What would be the best way to implement a global watchlist? What would it look like?
• What other changes would we need to make to the watchlist system and interface to make this work?
• What other changes would we want to make to the watchlist system and interface while we're at it?

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.

Made a start at Watchlist wishlist.

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

1. be small enough that nobody notices or complains
2. be small enough that grumblings don't lead to a "we won't stand for this" snowball of outrage
3. be opt-in
4. be opt-in for existing users, opt-out for new users
5. be easily opt-out for all users
6. be important enough to impose despite pissing people off

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.

Sure. See also my new essay, en:WP:Interface changes...

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:

• login, user prefs, user rights
• transclusion, tracking changes to shared files
• RC and its filters, other overview pages
• translation, workflow (marking pages as stale when those they depend on are changed or deleted)

A roadmap for this kind of support for cluster-level development might make it easier to see how to globalize watchlists and RC.

My team is proposing some changes to the database schema of the watchlist table which could potentially support a number of requested features (see the "use cases" section). Please comment.

One glaring deficiency in the watch system is its inability to cover categories.

Currently, when a user is watching a category, she will only get notified when someone edits the category page itself.

However, what a reasonable user expects, is to be notified whenever the "category page" changes, in other words, whenever a new page is added or removed from the category, or whenever a page that belongs to the category gets renamed.

a separate level of notification might be "whenever a page belonging to the category is modified", but if we want to support this, it needs to be controlled separately from the main thing, which is, to be notified when the content of the category changes. what i mean is, "watch the category" and "watch all the pages in category" should be two separate controls, and a user can choose one or the other (or both).

Please note that "watch all pages in category" should *not* be implemented by adding all the pages in the category to the watchlist: first, this will not cover pages who acquired the category after the user added the cat. to her watchlist, and 2nd, it is very much possible that the user was already watching some of these pages, then decides to watch the whole category, then decides that it's too much and removes the category watch. she should not lose the individual pages she was watching before.

peace.

This would be great. It would also be nice to have an option for cascading category watchlisting (that is, if you watchlist a category, its subcategories would also be watchlisted.)

It is possible to create a list of the oldest and newest items in a given category on the category page at least, limited to 50 (?) items on each list. This doesn't come close to a watchlist capability, of course.

It would be nice if pages were automatically removed from the watchlist after a specified period without the user editing it.

Even better might be if that were a default behavior unless the user "pinned" an item to the watchlist, ie, made it permanent. Other approaches might be keep items on the watchlist until some limit (eg, the effective maximum for editing the list of about 20K items or some size-based limit) was approached, the user sent an e-mail and a user-page message with enough time to edit the list, including "pinning" oldest items. If the owner fails to reduce the list below some level, the oldest "non-pinned" items would be removed. This would seem to cover a lot of the problematic situations at Wiktionary.

A helpful supplement might be to allow a user to edit chunks of the watchlist rather than the whole thing. Editing by namespace should not be too hard. Editing the oldest 10K items might work.

I get the feeling that at present the date that an item was added to the watchlist by a user is not retained.

It would have been really helpful if there was a possibility for watching only a specific topic instead of the whole page. for example, if you post on the reference desk, you'll get notify only about your specific question. thanks for considering my request

At Wiktionary, section watching would be of enormous value as watchers are almost always interested in one or at most a small number of L2 (= language at Wiktionary) sections on a given page. For example, test has nine language sections half of which have no connection to the English word test. Someone interested in the Hungarian work test generally has much less or no interest or expertise in the other languages.

I know we're at early stages yet, but I'd just like to flag that we will want to turn this from a list of suggestions into an actual "product" discussion page at some point - one with an overall objective for what and who watchlists are for, how they are meant to be used, and thus a rationale for each proposed change (and a quick evaluation of their technical complexity and dependencies), to inform a priority worklist. Happy to help out with this, of course.

I completely agree; feel free to organize the page (even with empty sections reflecting what you just mentioned) to better frame the content. I didn't use the word "product" in my communications because it usually scares away non-WMF people :)

YDone :-)

Thanks :)