Wanted to toss out another idea for research/consideration. meta:wikidata-game contains multiple gamified tasks that I'd consider friendlier for both new and mobile users than some of the suggestions I've seen for structured tasks. They have a few benefits: (1) having already been built/designed for short-term interaction, (2) any improvement to this tool is extended to the GLAM workers and others using this tool with new users, (3) the benefit of contributing to Wikidata instead of a single Wikipedia is that the benefits pass downstream to all language Wikipedias whose infoboxes are automatically pulling from the centralized Wikidata metadata. At the very least, worth checking out. I would be curious whether user research confirms that these types of games/interactions are interesting for new users (and thus could just use extra loops to make continued use more compelling) or whether these types of efforts do not impact user growth (which I think its maintainers and other GLAM workers would want to know).
Topic on Talk:Growth/Personalized first day/Structured tasks/Flow
Hi @Czar -- thanks for bringing this up. We are familiar with the Wikidata games, and they helped inspire these ideas around structured tasks. One of the issues with the Wikidata games is that newcomers don't understand about Wikidata, and are therefore not motivated to edit it -- but they do want to edit Wikipedia. I suppose, though, that edits to Wikidata could be wrapped in an experience that makes it clear that the user's edits will ultimately affect Wikipedias -- it's just that they themselves will not necessarily be able to go to a Wikipedia article and see their own handiwork. What do you think about this?
Regarding GLAMs, I think we're thinking along the same lines with structured tasks and campaigns. If the Growth features provide a feed of articles to work on, we could imagine communities setting up campaigns around specific topic areas, assembling lists of articles to work on, and then using Growth's suggested edits feed to make them available to campaign participants.
About the magnified benefits of contributing to Wikidata: I'm thinking about the other side of the coin. Would you be concerned that it would give newcomers too much power to allow them to essentially edit many Wikipedias at once through Wikidata?
newcomers don't understand about Wikidata, and are therefore not motivated to edit it
fwiw, if it were built into the WP app, I doubt newcomers interested in a random queue would care whether it's technically WD or WP (or care about the difference). It's also pretty cool to see when you're impacting X times the amount of Wikipedias with your edits. In your testing, have users shown an interest in wanting to go back and admire their handiwork? The novelty wears off after maybe the first check, if even the first check is necessary. Once you're into processing a random queue, it's just the thought of knowing that it's helping that keeps you going, in my experience. I would expect a nice visualization of one's contributions to more impactful than seeing a parameter added to a collapsed infobox in the app, for instance.
re: GLAMS, what follows is definitely a strong opinion loosely held, but I've participated in and organized a number of edit-a-thons and while the dashboards show X amount of edits (usually reflecting regulars who continue editing in the defined timeframe rather than actual newcomer contributions), they often miss the trees for the forest. It's far better to hook someone into editing typos on Wikipedia and have their lifetime contributions over teaching them a fairly intensive edit process in an hour that they are unlikely to revisit ever.
re: the other side of the coin, this may be surprising but I'd say the opposite! Wikidata (and Commons, for that matter) has a higher tolerance for mistakes because they lack either the people power or tools to review the volume of edits coming through the site. (As compared to ENWP, which has a bevy of tools and editors dedicated to patrolling even the most random of edits.) Either way, their communities are not going to want junk edits, of course, and if they view a tool as being a vector for abuse, they'll oppose it, but I would anticipate both WD and the other language WPs that use WD to see such an accessible tool as a boon to their basic work. mix-n-match is highly important matching metadata properties between trusted authority sources—anything that improves their own tools while bringing in and onboarding new users? Dreams come true!
In your testing, have users shown an interest in wanting to go back and admire their handiwork?
There are two main things that make me think users want to visually confirm/admire their Wikipedia edits, but I acknowledge that neither of them are conclusive -- it's more that they inform a theory we have. The first is from looking at the data on the newcomer homepage's "impact module", which lists the articles recently edited by the newcomer, along with how many pageviews the article has received since the newcomer's edit. In this image, you can see the impact module (lower right) for a user who has edited exactly one article (Diana Rossová). We see lots of newcomers clicking on the titles of the articles they've edited in the past. This may be because they want to continue editing the article, or it may be because they want to confirm that their edit is still there. More analysis would shed more light, but we haven't been able to prioritize this.
The other thing is anecdotal: our sense from events and editing workshops that when newcomers make their first edit to Wikipedia, a lightbulb goes on for them when they realize that their edit is live, and has actually changed Wikipedia. We want to make that moment happen for newcomers even when they're not at an event. In your experience at edit-a-thons, is this a real effect that we should try to cause?
Taking this all together, I think you're making good points that (a) a newcomer doesn't necessarily need to realize the difference between Wikipedia and Wikidata, and (b) there would certainly be good ways to help a newcomer see that their edit to Wikidata has impacted Wikipedia. We should think about this for future structured tasks -- it's more that I've wanted to shy away from the types of edits that only affect Wikidata, and don't reverberate into the Wikipedias.
It's far better to hook someone into editing typos on Wikipedia and have their lifetime contributions over teaching them a fairly intensive edit process in an hour that they are unlikely to revisit ever.
This totally makes sense, and is something that's come up as we've planned features that can help edit-a-thons. The question has been: what are edit-a-thons for? Is it more important to generate a bunch of articles, or to get as many newcomers as we can off on a start on their Wikipedia journey, even if that means less content from the event? In your experience, have you seen longtime Wikipedians come from these events?
re: the other side of the coin, this may be surprising but I'd say the opposite!
I guess that the higher tolerance for mistakes on Wikidata is what I'm worried about. Since we're targeting newcomers with these features, I think we should expect a fair amount of bad edits -- I'm thinking, like, someone who indiscriminately taps "Yes" on all the image suggestions they get. If those images get added directly to the Wikipedia they're on, then we can have high confidence that the edits will be patrolled, and someone will realize that user isn't using discretion, and then maybe warn/block them. But if the edits are going to Wikidata, and Wikidata doesn't have bandwidth to patrol them closely, then the bad edits would be making their way on to potentially dozens of Wikipedias without those wikis having a good way to patrol them.
On the other hand, though, it's possible to filter one's Wikipedia Watchlist (or Recent Changes) to include Wikidata edits. Do you know if that's commonly used?