Wikimedia Blog/Drafts/Gamestorming: Making The Wikipedia Adventure
Gamestorming: Making The Wikipedia Adventure
Could learning to edit Wikipedia be engaging and fun? I set out to answer that question this spring as part of an Individual Engagement Grant. I wanted to figure out a way to turn frustration and confusion into confidence and enjoyment by drawing on game design and onboarding. Gamified onboarding works, was my hypothesis. The Wikipedia Adventure (TWA) was the laboratory.
The notion of turning Wikipedia into a game might sound like an inappropriate idea to many, so I was sure to draw a clear line between a game that teaches and a game which actually edits. The Wikipedia Adventure exists in its own world--actually in the user's own user-space--and it's neatly marked off as separate from Wikipedia's real articles.
Inspiration and research
The idea for the game originated back in 2011 when I received the same questions from new editors over and over again, convincing me that there had to be a better way to get people through the gauntlet of common problems during initial months. I wrote a 12-level script during a long summer, then waited as I looked for a coder to develop it. (Derek Coetzee took a good crack at it). 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.
My first research consisted of zeroing in on the major problem points which new editors face; the obstacles that cause the most frustration and hurt retention. Many hours at the irc help channel, the Wikipedia Help Desk, and the Teahouse gave me loads of insight. Building on that, I worked with new editors and conducted usability 'needfinding' interviews to focus on the skills new editors often struggle to acquire.
The second area of research was understanding gamification, game dynamics, motivation and engagement. In the 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
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 version of the Wikipedia "Earth" article, a topic I felt was 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 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. I laid out all of these elements in storyboard and set off to travel.
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 with more narrative. I also owe a shout-out to Martijn Hoekstra who patiently walked me through the basics of bug-fixing code--a sorely needed and greatly 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 can send a message to the talk subpage of a fellow (fictional) adventurer who needs a hand, has a tip, or wants to help.
Learning and challenges
The project has progressed smoothly; the main obstacle has been working on so many different pieces at the same time. While one mission is being built, another is being refined. Bugs in code are always discovered along the way, which constantly need replacement.
Especially challenging has been trying to stay up-to-date with major changes to the user interface with Notifications and Visual Editor, designing to hit a moving target. The key has been to always keep working on something, even if it's something you won't utilize immediately. When I've been stuck on something for more than a few days, I often ask someone who knows more about it than me for help. Setting and meeting deadlines hasn't always work out as planned, but they proved helpful in the sense that they keep me tethered to a progressing timeline.
The best advice I received early on was that creative people cannot read your mind, In other words, you have to clearly but kindly point out what you want, what you like, what you don't like, and what you need. This was truly helpful.
Reflections and next steps
Building an interactive game is not an assembly line, but rather a more like composing a painting. 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.
Over the next month, I'll be iterating and bug-fixing based on user feedback, and collecting metrics on use and impact. In order to make all this happen I need your help as alpha testers. Hopefully it won't all fall apart. If it does, we'll rebuild it better. That's how progress happens.