Yesterday, at GLAMcamp London we discussed a large variety of things. One of them was doing more ‘crowdsourcing’ and ‘gamification’. I don’t like either term much but the general idea works a bit like this.
Currently, a lot of tasks on Wikipedia and other Wikimedia projects are high-intensity. Think about reviewing a featured article. It requires a lot of thinking, and a lot more typing.
Some people today used the term ‘crowdsourcing’ for what we need to work on, but that’s inaccurate: the issue isn’t crowdsourcing but splitting up high-intensity tasks into lots of small modular tasks that can be done without a great deal of prior context or time investment. ‘Crowdsourcing’ applies to non-modular tasks too: think of all the people who ‘crowdsource’ amateur videos. Producing a TV ad isn’t a modular task. The term ‘crowdsourcing’ is so general as to be useless. What we are actually talking about is tasks with a high degree of modularity (aka. low intensity/low commitment) vs. tasks with a low degree of modularity (high intensity/high commitment).1
The low degree of modularity tasks also happen to be the sort of tasks it is easy to do on a mobile device: a smartphone or tablet device like an iPad, iPhone, Blackberry, Android device etc.
There will be some tasks which it will be impossible to turn into ultra-modular tasks. Writing a Good Article (GA) review will be hard to do on a smartphone. In fact, most article writing tasks will probably never get any more modular than it currently is.
Speaking personally, two things stand out as a perfect example of tasks on Wikipedia that are low intensity and highly modular:
- Reviewing Articles for Creation.
- Reviewing edits during the Pending Changes trial.
Both of these tasks are reasonably low intensity: they don’t require a lot of creativity, and can be done without typing. They are the sort of tasks I have done quite successfully on mobile devices.
If we can identify specific places where this kind of modularity can be used, we can build interfaces to help people who aren’t very active on Wikipedia to clear backlogs. Take images lacking descriptions.
Imagine this. After a busy day at work, you pull out a phone on the bus. It downloads a batch of random photos that lack descriptions (from Commons and/or English Wikipedia) and starts displaying them. You swipe to advance to the next one. At the bottom of the screen is a button that says “Identify”. You eventually run across a photo of a cat, tap ‘Identify’, choose what it is from a series of menus, and it places it into a review category with some basic information (‘Cats to check’!) and adds a description to the talk page. Later, an experienced user will check it and copy it into the description.
On English Wikipedia, images needing descriptions has a backlog of over 10,000. Imagine if an iPhone app became reasonably popular and there were a community of 1,000 people doing on average one or two image descriptions a week each. You only need a few hundred a day to be able to start really kicking the backlogs away.
We do some user testing, wrap this in a suitable interface: it may very minimal – getting to see completely random images may be enough of a Pavlovian trick to get a few people to tag some images. Or it may require fancy game mechanics: RPG-style levels, or perhaps a leaderboard. Perhaps just getting out of the way and making it convenient. Perhaps a mixture of things. Whatever. You test it and find out. It’s just like on Wikipedia: some people contribute to get barnstars, some to get high edit counts, some just for the love of the subject, some for the community and so on.
Wikipedia does a great job providing work for high-intensity committed users: there’s a lot more featured articles to write. But there is so much to do that is low-intensity, low-commitment and highly modularised. If the whole community has a think about it, they can undoubtedly come up with tasks that can be done on mobile phones. The specification is clear: set a task that takes no more than three minutes, requires no more than 140 characters of text input and can be done without reading more than one mobile phone screenful of text.
Make it easy and compelling to start doing these low intensity tasks, and it easily builds up into doing more complicated things. Just think about things experienced Wikipedians do frequently with Twinkle. Now imagine that for half the time on-wiki, you aren’t allowed to edit and can only use Twinkle: this is getting closer to the experience for the mobile user.
How does this fit with my views on gamification? Quite easy: I’m reasonably pragmatic. I still think that you will find much more enjoyment in life if you commit to work as part of an engaging community of meaning than you will through gamification. My earlier post is about how individuals act, and more importantly about how individuals should act. I think about things like this in the same way I think about something like needle exchange programmes. Yes, the world would probably suck less if there were less heroin addicts, but while heroin addicts exist, they should be able to get a clean needle, because having a heroin addict getting HIV from a dirty needle is like a real life serious business version of the jwz line about using regular expressions: “Now you have two problems.”
I’m not wild about gamification, but I’m even less wild about having 10,000+ images on Wikipedia lacking descriptions. If one solves the other, or many other similar tasks, I’m willing to do a deal with the devil. I don’t like the concept of social media either (for reasons I haven’t explained in a systematic fashion yet, for which I apologise) but that doesn’t mean I’m going to sit in the corner and refuse to use Twitter or Facebook to make some kind of point. I’m not that pig-headed.
The important thing is that we need to find ways of not only getting over the stagnating number of active editors, but actively jump into trying to design new kinds of ways for contributors to participate in free culture projects. One of the sources of conservatism in the Wikipedia community is this idea that there is a very limited pool of Wikipedians: ten thousand or so on English Wikipedia, with a limited amount of manpower. This trope has turned up in innumerable discussions over proposals, most recently in the pending changes trials. But what is important to note is that we collectively have power to determine how easy it is to participate in the community. And producing the sort of interactions that those goofy buzzwords “gamification” and “crowdsourcing” point very vaguely towards might help and that we should think about them.
p.s. How does this fit into GLAM? Simple. When GLAM ambassadors are thinking about how to engage the community, think about how to engage the low-intensity community as well as the sort of heroic people who churn out five GAs before breakfast. And if something like a ‘simple image description’ interface were built, it should be possible to make that available for GLAM projects.
‘Modularity’ in this sense is discussed in more detail by Yochai Benkler in The Wealth of Networks. ↩