User:Ocaasi/INFY
Gamestorming: Making The Wikipedia Adventure[edit]
Could learning to edit Wikipedia be engaging and fun? I set out for an answer to that question this spring as part of an Individual Engagement Grant. I wanted to to experiment with turning frustration and confusion into confidence and enjoyment by drawing on developments in game design and onboarding. Gamified onboarding works, was the hypothesis. The Wikipedia Adventure (TWA) was the labratory.
The notion of turning Wikipedia into some sort of game is a horror to many, so I was careful first to draw a clear line between a game that teaches and a game which is editing itself. The Wikipedia Adventure exists in its own world--actually in the user's own userspace, and it's neatly marked off as separate from Wikipedia's actual articles.
Inspiration and research[edit]
The idea for the game originated back in 2011 when hundreds of repeated questions from new editors convinced me that there must be a better way to get people through the gauntles of common problems they face in theif first few months. I wrote a 12-level script during a long summer, and then it languished as I looked for a coder to develop it. (Derek Coetzee made a great go of it at first). When the Wikimedia Foundation's Editor Engagement Experiments team released Guided Tours in 2012, I suddenly had an engine for the script to take off.
The first area of research for me was zeroing in on the major pain points which new editors face, those obstacles which cause frustration and hurt retention. Many hours at the irc help channel, the Wikipedia Help Desk, and the Teahouse gave me lots of good instincts. Building on that work with new editors, I also conducted usability 'needfinding' interviews to focus on the skills new editors often struggle to complete.
The second area of research was understanding gamification, game dynamics, motivation and engagement. In winter of 2012 myself, Anya Shyrokova, Heather Walls, Jonathan Morgan and Siko Bouterse piloted a badge program in the Teahouse, which inspired a lot of the conceptual thinking. I delved further into books and presentations. There were many I poured over, but the sure standouts were: A New Culture of Learning by Douglas Thomas, Game Frame by Aaron Dignan, and Reality Is Broken by Jane McGonigal
Putting the pieces in place[edit]
Siko Bouterse was invaluable in helping me craft the script into a cohesive and accessible seven-mission journey. The script takes users on a journey to edit a simulated verion of the article on Earth, a topic that I hoped would seem universal. Siko then showed me a fantastic interactive text program called Twine, which let me usability-test and refine the language without having to worry about code and formatting.
The script had an emerging theme which I captured in a word cloud and explored through an image moodboard. Heather Walls' phenomenal sense of playful design helped me move from a cluster of common phrases and 40 inspiring but disparate images to a visually striking and sparkly-fun theme that immerses the game-player on an interstellar trek through Wikipedia--a galactic carnival of humanity. Think space ferris wheel and supernova fireworks.
We chose a space theme to reflect the vastly ambitious mission of Wikipedia. We chose the avatar because that was human-like but not representative of a particular race or gender. We used colors that would neither be seen as stereotypically masculine nor feminine but were generally upbeat and inviting. We used graphics that lightheartedly suggested accomplishment, travel, and exploration in a way that contrasted to the often difficult technical, social, and policy-oriented challenges new editors typically face. The tone in the script was designed to be engaging and accessible without pandering or being pedantic--more like a helpful guide who can show you around than an expert who speaks at you. I laid out all of these elements in storyboard and set off to travel.
I attended the GSummit conference to learn more about game design, the Amsterdam Hackathon for Javascript lessons, and the Open Help conference for thinking about the role of play in collaboration and learning (See the talk: Fun Is Serious Business). I also visited the Wikimedia Foundation twice to meet with Heather and Siko to set the design in motion (and give a tech talk about the game.).
Developer Matthew Flaschen helped introduce me to Guided Tours and enabled me to gradually expand its functionality from a basic way to guide editors around pages to a versatile platform for a narrative. I also owe a shout-out to Martijn Hoekstra who patiently walked me through the basics of bugfixing code--a sorely needed and appreciated lesson.
A key component I wanted to build into TWA was simulated interactions between the game-player and other editors. For that I worked with Nischay Nahata, who brilliantly coded the game to seem interactive using the mediawiki Edit API. When a user in the game clicks the button to advance the tour, they may just send themselves a message to their user talk subpage from a fellow (fictional) adventurer who needs a hand, has a tip, or wants to help.
Learning and challenges[edit]
The project has proceeded smoothly; the main obstacle has simply been working on so many different pieces at the same time. While one mission is being built, another is being refined, and bugs in code discovered along the way, needing replacement throughout the game.
Time-management has been a puzzle. I have both done than I thought possible, and it all took longer than expected. Problems arose that I didn't forsee, both with creative and technical issues, and they don't resolve predictably. Especially challenging has been trying to stay uptodate with the recent major changes to the user interface with Echo and Visual Editor, designing to hit a moving target. Key has been to always keep working on something, even if it's not the exact piece I needed. And when I've been stuck on something for more than a few days, I ask someone who knows more about it than me for help. Setting deadlines hasn't always work out as planned, but they proved helpful even when I needed them to be flexible; they kept me tethered to a progressing timeline.
The best advice I received early on was that creative people cannot read your mind. In other words, to clearly but kindly point out what you want, what you like, what you don't like as much, what you need done by approximately when. This was helpful.
Reflections and next steps[edit]
Building a real thing is more like a painting than an assembly line. You have a sketch. You erase and redraw. You lay down base colors. You get perspective, and then go back in and reshape. You add details to different parts of the canvas at different times. It comes together in series as much as in sequence and the sense that the final destination is reachable doesn't really come together until the majority of the work is already finished.
Making something that other people can use is a very unique process with its own rhythm. Moral support from IE Grant staff has been tremendous and has given me wise counsel, help getting unstuck, reminders of inspiration, and good humor about a long and involved process.
Over the next 3 months, I'll be iterating and bug-fixing based on feedback, and then collecting metrics on use and impact to see how it's working. This is an experiment, after all. In order to make that happen I need your help me alpha test the game so that I can really let the community kick the tires. Hopefully it won't all fall apart. If it does, we'll rebuild it better. That's how progress happens.
Want to try it out? Start the Adventure. Let me know what you think!
INFY[edit]
If you're a hardened, uber-competent, technical powerhouse, Wikipedia policy wonk, or policy guru... please read this message.
It's not for you. The Wikipedia Adventure, just like the Teahouse, Articles for Creation, and irc help chat are not for you. You don't need it. You figured out this maze on your own. Congratulations. Seriously, it took hundreds of hours of practice, reading, dedication; it took intelligence, persistence, dedication, and savvy. I went down the same path.
I also went down a different path, when I started helping new editors. The same frustrations, same sense of bewilderment, confusion, lack of confidence coming up over and over again. These are not hypothetical. We know from Sue Gardener's survey research that women in particular feel our environment is time-consuming, conflict-oriented, unintuitive, and ripe with opportunities for public failure.
You didn't have a problem with those things, because you had time, conflict-tolerance, technical intuition, and thick skin.
But not everyone does. And what worked for you won't work for everyone different than you.
To presume that those people are somehow less capable of contributing, less bright, or less committed to our mission, is not just arrogance, it's dangerous. Those people we have missed along the way are valueable. They bring a range of life experiences, interests, learning styles, personalities, and opinions that our project will benefit from.
To look at something you don't like and assume that it's obviously 'for kids' or 'not fit for an encyclopedia' is like a linux hacker looking at an iphone and writing it off as a child's toy. Don't make that mistake. Technology should be intuitive. Learning should be enjoyable. Dialogue should be constructive. Design should be appealing.
We have tried reaching academics. The education program tries this deeply. But new editors pre-college, in college, and out of college....get stuck. Because they're not you. Don't make the mistake of thinking they or their varied peers are not the part of this movement. That's simply not your call to make.
Contributing to our amazing project should feel good. It takes hard work to thrive in our community, but do not hold the obstacles new editors face as some badge of honor or competency. That's just wrong. Think about the thing in your life you struggled to learn, and how you might have appreciated someone to help show you the ropes. It's elitist and unkind to write off people from the help they crave in an approach that will work for them.
And that's the crux of the matter: intentional, social, supportive, friendly, personal, playful design works.
Look at the Teahouse data:
- Teahouse visitors compared to invited non-visitors
| Metric | Control group | Teahouse group | Contrast |
|---|---|---|---|
| Average retention (weeks with at least 1 edit) | 5.02 weeks | 8.57 weeks | 1.7x retention |
| Average number of articles edited | 58.7 articles | 116.9 articles | 2.0x articles edited |
| Average talk page edits | 36.5 edits | 85.6 edits | 2.4x talk page edits |
| Average article space edits | 129.6 edits | 360.4 edits | 2.8x article edits |
| Average total edits (all namespaces) | 182.1 edits | 532.4 edits | 2.9x total edits |
| Percentage of women | 9% | 29% | 3.2x female editors |
This is not about taking over Wikipedia with glitter and unicorns. It's about giving different people entry points into our process that *work for them*. What worked for you may not, did not, or has not worked for them. So when you see a new project like this, kindy remember four words: it's not for you. It wasn't ever or anyway. And that's ok. Because you made it just fine. You're not the problem. Except until you foreclose an opportunity for others to follow in your footsteps. Then that's a problem. And we need to talk about it.
What an experiment means[edit]
The Wikipedia Adventure was designed to attract a diverse college-aged demographic. A concern was raised that the game might appeal to a younger audience. First off, it was certainly not designed to target them. The tour was indeed designed to be welcoming and lighthearted while also instructional. But the content of the tour is our core policies and editing mechanics, similar to other introductory help pages or tutorials. To say the game was targeted at kids is not just incorrect, and off-point (we welcome competent editors of any age), but I think it more broadly presumes an underlying conceit that design which is simple and engaging (or even fun) cannot also facilitate meaningful intellectual pursuit. My hypothesis is that there's no such contradiction, and as an experiment, that's precisely what The Wikipedia Adventure sets out to explore. It's also worth mentioning that this approach will not work for everyone, and it's certainly not aimed at established and well-tested editors. They have made already it through the obstacles. Instead this is one possible entry point that an editor may find useful, and if it appeals to them, and they go on to keep contributing constructively to our project, then that's a success.
Check out the project page at WP:TWA. And when it's ready for testing, play it through once and share your thoughts. Please remember that this project is for the many potential great editors who struggle to currently participate, despite their best intentions. We're better off as a community to teach them properly and have their contributions.
Second, we don't know who the adventure will work for or won't because we haven't tested it yet and we have no data. This is an experiment. It needs to run.
It's entirely possible that an owl would be a better guide than an astronaut, or that a library different theme would be more conducive to academic specialists than a space theme. I do hope the design will appeal to non-gamer and older adults precisely types because it's friendly and inviting; my hunch is also that it will not turn off serious thinkers because the content in the game is consistent with our other help/introductory/onboarding materials. So, these are tone issues, and tone issues are going to be subjective, at least until we have some data and can test variations.
At this point the design is set for round 1. A good amount of work went into the them and it wouldn't be possible to change course. However that's not to say that there couldn't be many iterations on tour content and design. Indeed, that's one of the great aspects of Guided Tours--it's completely rebrandable and recyclable. If something doesn't work, we can change it. If we want to adapt to a different audience, we can build it. We have a plurality of options and entry points, and that is a good thing.