game – ACRL TechConnect

LibraryQuest Levels Up

Almost a year ago, GVSU Libraries launched LibraryQuest, our mobile quest-based game. It was designed to teach users about library spaces and services in a way that (we hoped) would be fun and engaging. The game was released “into the wild” in the last week of August, 2013, which is the beginning of our fall semester. It ran continuously until late November, shortly after midterms (we wanted to end early enough in the semester that we still had students on campus for post-game assessment efforts). For details on the early development of the game, take a look at my earlier ACRL TechConnect post. This article will focus on what happened after launch.

Screenshot of one of the quests. — A screenshot from one of our simpler quests as it was being played.

Running the Game

Once the app was released, we settled on a schedule that would put out between three to five new quests each month the game ran. Designing quests is very time intensive, and 3-5 a month was all we could manage with the man and woman power we had available. We also had short duration quests run at random intervals to encourage students to keep checking the app. Over the course of the game, we created about 30 quests total. Almost all quests were designed with a specific educational objective in mind, such as showing students how a specific library system worked or where something or someone was in the physical building. Quests were chiefly designed by our Digital Initiatives Librarian (me) with help and support from our implementation team and other staff in the library as needed.

For most of the quests, we developed quest write-up sheets like this one: Raiders of the Lost…Bin. The sheets detailed the name of the quest, points, educational objective, steps, completion codes, and any other information that defined the quest. These sheets proved invaluable whenever a staff member needed to know something about a quest, which was often. Even simple quests like the one above required a fair amount of cooperation and coordination. For the raiders quest, we needed a special cataloging record created, we had to tag several plastic crowns and get them into our automatic storage and retrieval system.

For every quest players completed, they earned points. For every thirty points they earned, they were entered once in a drawing to win an iPad. This was a major component of the game’s advertising, since we imagined it would be the biggest draw to play (and we may not have been right, as you’ll see). Once the game closed in November, we held the drawing, publicized the winner, and then commenced a round of post-game assessment.

Thank You for Playing: Post-Game Assessment

When the game wrapped in mid-November, we took some time to examine the statistics the game had collected. One of our very talented design students created a game dashboard that showed all the metrics collected by the game database in graphic form. The final tally of registered players came in at 397. That means 397 people downloaded the app and logged in at least once (in case you’re curious, the total enrollment of GVSU is 25,000 students). This number probably includes a few non-students (since anyone could download the app), but we did some passes throughout the life of the game to remove non-student players from the tally and so feel confident that the vast majority of registered players are students. During development, we set a goal of having at least 300 registered players, based mostly on the cost of the game and how much money we had spent on other outreach efforts. So we did, technically, meet that goal, but a closer examination of the numbers paints a more nuanced picture of student participation.

A screenshot of the LibraryQuest Dashboard — A detail from our game dashboard. This part shows overall numbers and quest completion dates.

Of the registered players, 173 earned points, meaning they completed at least one quest. That means that 224 players downloaded the app and logged in at least once, but then failed to complete any quest content. Clearly, getting players to take the first step and get involved in the game was somehow problematic. There are any number of explanations for this, including encounters with technical problems that may have turned players off (the embedded QR code scanner was a problem throughout the life of the game), an unwillingness to travel to locations to do physical quests, or something else entirely. The maximum number of points you could earn was 625, which was attained by one person, although a few others came close. Players tended to cluster at the lower and middle of the point spectrum, which was entirely expected. Getting the maximum number of points required a high degree of dedication, since it meant paying very close attention to the app for all the temporary, randomly appearing quests.

A shot of a different aspect of the LibraryQuest Game dashboard. — Another detail from the game dashboard, showing acceptance and completion metrics for some of the quests. We used this extensively to determine which quests to retire at the end of the month.

In general, online-only quests were more popular than quests involving physical space, and were taken and completed more often. Of the top five most-completed quests, four are online-only. There are a number of possible explanations for this, including the observation offered by one of our survey recipients that possibly a lot of players were stationed at our downtown campus and didn’t want to travel to our Allendale campus, which is where most of the physical quests were located.

Finally, of our 397 registered users, only 60 registered in the second semester the game ran. The vast majority signed up soon after game launch, and registrations tapered off over time. This reinforced data we collected from other sources that suggested the game ran for too long and the pacing needed to be sped up.

In addition to data collected from the game itself, we also put out two surveys over the course of the game. The first was a mid-game survey that asked questions about quest design (what quests students liked or didn’t like, and why). Responses to this survey were bewilderingly contradictory. Students would cite a quest as their favorite, while others would cite the exact same quest as their least favorite (and often for the same reasons). The qualitative post-game evaluation we did provides some possible explanation for this (see below). The second survey was a simple post-game questionnaire that asked whether students had enjoyed the game, whether they’d learned something, and if this was something we should continue doing. We also asked if they had learned anything, and if so, what they had learned. 90% of the respondents to this survey indicated that they had learned something about the library, that they thought this was a good idea, and that it was something we should do again.

Finally, we offered players points and free coffee to come in to the library and spend 15-20 minutes talking to us about their experience playing the game. We kept questions short and simple to keep within the time window. We asked about overall impressions of the game, if the students would change anything, if they learned anything (and if so, what) and about what quests they liked or didn’t like and why. The general tone of the feedback was very positive. Students seemed intrigued by the idea and appreciated that the library was trying to teach in nontraditional, self-directed ways. When asked to sum up their overall impressions of the game, students said things like “Very well done, but could be improved upon”or “good but needs polish,” or my personal favorite: “an effective use of bribery to learn about the library.”

One of the things we asked people about was whether the game had changed how they thought about the library. They typically answered that it wasn’t so much that the game had changed how they thought about the library so much as it changed the way they thought about themselves in relation to it. They used words like “”aware,” “confident,” and “knowledgeable.” They felt like they knew more about what they could do here and what we could do for them. Their retention of some of the quest content was remarkable, including library-specific lingo and knowledge of specific procedures (like how to use the retrieval system and how document delivery worked).

Players noted a variety of problems with the game. Some were technical in nature. The game app takes a long time to load, likely because of the way the back-end is designed. Some of them didn’t like the facebook login. Stability on android devices was problematic (this is no surprise, as developing the android version was by far the more problematic part of developing the app). Other problems were nontechnical, including quest content that didn’t work or took too long (my own lack of experience designing quests is to blame), communication issues (there’s no way to let us know when quest content doesn’t work), the flow and pacing of new quests (more content faster), and marketing issues. These problems may in part account for the low on boarding numbers in terms of players that actually completed content.

They also had a variety of reasons for playing. While most cited the iPad grand prize as the major motivator, several of them said they wanted to learn about the library or were curious about the game, and that they thought it might be fun. This may explain differing reactions to the quest content survey that so confused me. People who just wanted to have fun were irked by quests that had an overt educational goal. Students who just wanted the iPad didn’t want to do lengthy or complex quests. Students who loved games for the fun wanted very hard quests that challenged them. This diversity of desire is something all game developers struggle to cope with, and it’s a challenge for designing popular games that appeal to a wide variety of people.

Where to Go from Here

Deciding whether or not Library Quest has been successful depends greatly on what angle you look at the results from. On one hand, the game absolutely taught people things. Students in the survey and interviews were able to list concrete things they knew how to do, often in detail and using terminology directly from the game. One student proudly showed us a book she had gotten from ILL, which she hadn’t known how to use before she played. On the other hand, the overall participation was low, especially when contrasted against the expense and staff time of creating and running the game. Looking only at the money spent (approximately $14,700), it’s easy to calculate an output of about $85 per student reached (173 with points) in development, prizes, and advertising. The challenge is creating engaging games that are appealing to a large number of students in a way that’s economical in terms of staff time and resources.

After looking at all of this data and talking to Yeti CGI, our development partners, we feel there is still a great deal for us to learn here, and the results are promising enough that we should continue to experiment. Both organizations feel there is still a great deal to learn about making games in physical space and that we’ve just scratched the surface of what we might be able to do. With the lessons we have learned from this round of the game, we are looking to completely redesign the way the game app works, as well as revise the game into a shorter, leaner experience that does not require as much content or run so long. In addition, we are seeking campus partners who would be interested in using the app in classes, as part of student life events, or in campus orientation. Even if these events don’t directly involve the library, we can learn from the experience how to design better quest content that the library can use. Embedding the app in smaller and more fixed events helps with marketing and cost issues.

Because the app design is so expensive, we are looking into the possibility of a research partnership with Yeti CGI. We could both benefit from learning more about how mobile gaming works in a physical space, and sharing those lessons would get us Yeti’s help rebuilding the app as well as working with us to figure out content creation and pacing, without another huge outlay of development capital. We are also looking at ways to turn the game development itself into an educational opportunity. By working with our campus mobile app development lab, we can provide opportunities for GVSU students to learn app design. Yeti is looking at making more of the game’s technical architecture open (for example, we are thinking about having all quest content marked up in XML) so that students can build custom interfaces and tools for the game.

Finally, we are looking at grants to support running and revising the game. Our initial advertising and incentives budgets were very low, and we are curious to see what would happen if we put significant resources into those areas. Would we see bigger numbers? Would other kinds of rewards in addition to the iPad (something asked for by students) entice players into completing more quest content? Understanding exactly how much money needs to be put into incentives and advertising can help quantify the total cost of running a large, open game for libraries, which would be valuable information for other libraries contemplating running large-scale games.

Get the LibraryQuest App: (iPhone, Android)

About our Guest Author:
Kyle Felker is the Digital Initiatives Librarian at Grand Valley State University Libraries, where he has worked since February of 2012. He is also a longtime gamer. He can be reached at felkerk@gvsu.edu, or on twitter @gwydion9.

Library Quest: Developing a Mobile Game App for A Library

This is the story of Library Quest (iPhone, Android), the App That (Almost) Wasn’t. It’s a (somewhat) cautionary tale of one library’s effort to leverage gamification and mobile devices to create a new and different way of orienting students to library services and collections. Many libraries are interested in the possibilities offered by both games and mobile devices, and they should be. But developing for mobile platforms is new and largely uncharted territory for libraries, and while there have been some encouraging developments in creating games in library instruction, other avenues of game creation are mostly unexplored. This is what we learned developing our first mobile app and our first large-scale game…at the same time!

Login Screen — The login screen for the completed game. We use integrated Facebook login for a host of technical reasons.

Development of the Concept: Questing for Knowledge

The saga of Library Quest began in February of 2012, when I came on board at Grand Valley State University Libraries as Digital Initiatives Librarian. I had been reading some books on gamification and was interested in finding a problem that the concept might solve. I found two. First, we were about to open a new 65 million dollar library building, and we needed ways to take advantage of the upsurge of interest we knew this would create. How could we get people curious about the building to learn more about our services, and to strengthen that into a connection with us? Second, GVSU libraries, like many other libraries, was struggling with service awareness issues. Comments by our users in the service dimension of our latest implementation of Libqual+ indicated that many patrons missed out on using services like inter-library loan because they were unaware that they existed. Students often are not interested in engaging with the library until they need something specific from us, and when that need is filled, their interest declines sharply. How could we orient students to library services and create more awareness of what we could do for them?

We designed a very simple game to address both problems. It would be a quest or task based game, in which students actively engaged with our services and spaces, earning points and rewards as they did so. The game app would offer tasks to students, verify their progress through multistep tasks by asking users to input alphanumeric codes or by scanning QR codes (which we ended up putting on decals that could be stuck to any flat surface). Because this was an active game, it seemed natural to target it at mobile devices, so that people could play as they explored. The mobile marketplace is more or less evenly split between iOS and Android devices, so we knew we wanted the game to be available on both platforms. This became the core concept for Library Quest. Library administration gave the idea their blessing and approval to use our technology development budget, around $12,000, to develop the game. Back up and read that sentence over if you need to, and yes, that entire budget was for one mobile app. The expense of building apps is the first thing to wrap your mind around if you want to create one. While people often think of apps as somehow being smaller and simpler than desktop programs, the reality is very different.

The main game screen. We found a tabbed view worked best, with quests that are available in one tab, quests that have been accepted but not completed in another, and finished quests in the third.

We contracted with Yeti CGI, a outside game development firm, to do the coding. This was essential-app development is complicated and we didn’t have the necessary skills or experience in-house. If we hadn’t used an outside developer, the game app would never have gotten off the ground. We had never worked with a game-development company before, and Yeti had never worked with a library, although they had ties to higher education and were enthusiastic about the project. Working with an outside developer always carries certain risks and advantages, and communication is always an issue.

One thing we could have done more of at this stage was spend time working on game concept and doing paper prototyping of that concept. In his book Game Design Workshop, author Tracey Fullerton stresses two key components in designing a good game: defining the experience you want the player to have, and doing paper prototyping. Defining the game experience from the player’s perspective forces the game designer to ask questions about how the game will play that it might not otherwise occur to them to ask. Will this be a group or a solo experience? Where will the fun come from? How will the player negotiate the rules structure of the game? What choices will they have at what points? As author Jane McGonigal notes, educational games often fail because they do not put the fun first, which is another way of saying that they haven’t fully thought through the player’s experience. Everything in the game: rules, rewards, format, etc. should be shaped from the concept of the experience the designer wants to give the player. Early concepts can and should be tested with paper prototyping. It’s a lot easier to change rules structure for a game made with paper, scissors, and glue than with code and developers (and a lot less expensive). In retrospect, we could have spent more time talking about experience and more time doing paper prototypes before we had Yeti start writing code. While our game is pretty solid, we may have missed opportunities to be more innovative or provide a stronger gameplay experience.

Concept to conception: Wireframing and Usability Testing

The first few months of development were spent creating, approving, and testing paper wireframes of the interface and art concepts. While we perhaps should have done more concept prototyping, we did do plenty of usability testing of the game interface as it developed, starting with the paper prototypes and continuing into the initial beta version of the game. That is certainly something I would recommend that anyone else do as well. Like a website or anything else that people are expected to use, a mobile app interface needs to be intuitive and conform to user expectations about how it should operate, and just as in website design, the only way to create an interface that does so is to engage in cycles of iterative testing with actual users. For games, this is particularly important because they are supposed to be fun, and nothing is less fun than struggling with poor interface design.

A side note related to usability: one of the things that surfaced in doing prototype testing of the app was that giving players tasks involving library resources and watching them try to accomplish those tasks turns out to be an excellent way of testing space and service design as well. There were times when students were struggling not with the interface, but with the library! Insufficient signage, space layout that was not clear, assumed knowledge of or access to information the students had no way of knowing, were all things became apparent in watching students try to do tasks that should have been simple. It serves as a reminder that usability concepts apply to the physical world as much as they do to the web, and that we can and should test services in the real world the same way we test them in virtual spaces.

A quest in progress. We can insert images and links into quest screens, which allows us to use webpages and images as clues.

Development: Where the Rubber Meets the Phone

Involving an outside developer made the game possible, but it also meant that we had to temper our expectations about the scale of app development. This became much more apparent once we’d gotten past paper prototyping and began testing beta versions of the game. There were several ideas that we developed early on, such as notifications of new quests, and an elaborate title system, that had to be put aside as the game evolved because of cost, and because developing other features that were more central to gameplay turned out to be more difficult than anticipated. For example, one of the core concepts of the game was that students would be able to scan QR codes to verify that they had visited specific locations. Because mobile phone users do not typically have QR code reader software installed, Yeti built QR code reader functionality into the game app. This made scanning the code a more seamless part of gameplay, but getting the scanner software to work well on both the android and iOS versions proved a major challenge (and one that’s still vexing us somewhat at launch). Tweaks to improve stability and performance on iOS threw off the android version, and vice versa. Despite the existence of programs like Phonegap and Adobe Air, which will supposedly produce versions of the software that run on both platforms, there can still be a significant amount of work involved in tuning the different versions to get them to work well.

Developing apps that work on the android platform is particularly difficult and expensive. While Apple has been accused of having a fetish for control, their proprietary approach to their mobile operating system produces a development environment that is, compared to android, easy to navigate. This is because android is usually heavily modified by specific carriers and manufacturers to run on their hardware. Which means that if you want to ensure that your app runs well on an android device, the app must be tested and debugged on that specific combination of android version and hardware. Multiply the 12 major versions of android still commonly used by the hundreds of devices that run it, and you begin to have an idea of the scope of the problem facing a developer. While android only accounts for 50% of our potential player base, it easily took up 80% of the time we spent with Yeti debugging, and the result is an app that we are sure works on only a small selection of android devices out there. By contrast, it works perfectly well on all but the very oldest versions of iOS.

Publishing a Mobile App: (Almost) Failure to Launch

When work began on Library Quest, our campus had no formal approval process for mobile apps, and the campus store accounts were controlled by our student mobile app development lab. In the year and a half we spent building it, control of the campus store accounts was moved to our campus IT department, and formal guidelines and a process for publishing mobile apps started to materialize. All of which made perfect sense, as more and more campus entities were starting to develop mobile apps and campus was rightly concerned about branding and quality issues, as well as ensuring any apps that were published furthered the university’s teaching and research mission. However, this resulted in us trying to navigate an approval process as it materialized around us very late in development, with requests coming in for changes to the game appearance to bring it into like with new branding standards when the game was almost complete.

It was here the game almost foundered as it was being launched. During some of the discussions, it surfaced that one of the commercial apps being used by the university for campus orientation bore some superficial resemblance to Library Quest in terms of functionality, and the concern was raised that our app might be viewed as a copy. University counsel got involved. For a while, it seemed the app might be scrapped entirely, before it ever got out to the students! If there had been a clear approval process when we began the app, we could have dealt with this at the outset, when the game was still in the conceptual phase. We could have either modified the concept, or addressed the concern before any development was done. Fortunately, it was decided that the risk was minimal and we were allowed to proceed.

A quest completion screen for one of our test quests. These screens stick around when the quest is done, forming a kind of personalized FAQ about library services and spaces.

Post-Launch: Game On!

As I write this, it’s over a year since Library Quest was conceived and it has just been released “into the wild” on the Apple and Google Play stores. We’ve yet to begin the major advertising push for the game, but it already has over 50 registered users. While we’ve learned a great deal, some of the most important questions about this project are still up in the air. Can we orient students using a game? Will they learn anything? How will they react to an attempt to engage with them on mobile devices? There are not really a lot of established ways to measure success for this kind of project, since very few libraries have done anything remotely like it. We projected early on in development that we wanted to see at least 300 registered users, and that we wanted at least 50 of them to earn the maximum number of points the game offered. Other metrics for success are “squishier,” and involve doing surveys and focus groups once the game wraps to see what reactions students had to the game. If we aren’t satisfied with performance at the end of the year, either because we didn’t have enough users or because the response was not positive, then we will look for ways to repurpose the app, perhaps as part of classroom teaching in our information literacy program, or as part of more focused and smaller scale campus orientation activities.

Even if it’s wildly successful, the game will eventually need to wind down, at least temporarily. While the effort-reward cycle that games create can stimulate engagement, keeping that cycle going requires effort and resources. In the case of Library Quest, this would include the money we’ve spent on our prizes and the effort and time we spend developing quests and promoting the game. If Library Quest endures, we see it having a cyclical life that’s dependent on the academic year. We would start it anew each fall, promoting it to incoming freshmen, and then wrap it up near the end of our winter semester, using the summers to assess and re-engineer quests and tweak the app.

Lessons Learned: How to Avoid Being a Cautionary Tale

Check to see if your campus has an approval process and a set of guidelines for publishing mobile apps. If it doesn’t, do not proceed until they exist. Lack of such a process until very late in development almost killed our game. Volunteer to help draft these guidelines and help create the process, if you need to. There should be some identified campus app experts for you to talk to before you begin work, so you can ask about apps already in use and about any licensing agreements campus may have. There should be a mechanism to get your concept approved at the outset, as well as the finished product.
Do not underestimate the power of paper. Define your game’s concept early, and test it intensively with paper prototypes and actual users. Think about the experience you want the players to have, as well as what you want to teach them. That’s a long way of saying “think about how to make it fun.” Do all of this before you touch a line of code.
Keep testing throughout development. Test your wireframes, test your beta version, test, test, test with actual players. And pay attention to anything your testing might be telling you about things outside the game, especially if the game interfaces with the physical world at all.
Be aware that mobile app development is hard, complex, and expensive. Apps seem smaller because they’re on small devices, but in terms of complexity, they are anything but. Developing cross-platform will be difficult (but probably necessary), and supporting android will be an ongoing challenge. Wherever possible, keep it simple. Define your core functionality (what does the app *have* to do to accomplish its mission) and classify everything else you’d like it to do as potentially droppable features.
Consider your game’s life-cycle at the outset. How long do you need it to run to do what you want it to do? How much effort and money will you need to spend to keep it going for that long? When will it wind down?

References

Fullerton, Tracy. Game Design Workshop (4th Edition). Amsterdam, Morgan Kaufmann. 2008

McGonigal, Jane. Reality is Broken: Why Games Make us Better and How they Can Change the World. Penguin Press, New York. 2011

Why Gamify and What to Avoid in Library Gamification

In my last post, “Applying Game Dynamics to Library Services,” I presented several ideas for applying game dynamics to library services. After the post, I have received a comment like this, which I thought worthwhile to further explore.

What about the risk of gamification – the fact that it can deprive people of internal motivation for serious activities by offering superficial external rewards?

We tend to associate the library with learning, research, scholarship, and something serious. By contrast, games make us think of fun. For this reason, it is natural to worry about a library or any library-related activities such as reading, studying, researching becoming frivolous and trivial by gamification. In an effort to address this concern, I will point out that (a) gamification is a society-wide trend (and as such, highly likely to become not so frivolous after all), (b) what to avoid in gamifying libraries, and (c) what the limit of gamification is in this post. The key to successful gamification is to harness its impressive power while being fully aware of its limit so that you won’t overestimate what you can achieve with it.

Why gamify?

SCVNGR plans to create a game platform as Facebook built a social platform.

Gamification is not just a hot topic in libraries or higher education. It is a much bigger society-wide trend. In a similar way in which Facebook has evolved from a single website to practically ‘the’ social platform and layer of the real world with over 900 million active users as of May 2012, now a game layer is slowly being built on top of the real world. Just as the social layer effectively fused social elements into the world, the game layer brings gaming elements into reality. A game layer that we can compare to Facebook has not yet emerged. Nor is clear how far gamification will penetrate our daily activities. But we can imagine what a semi-universal social platform is going to be like from location-based smartphone apps such as Foursquare and Gowalla. Instead of building a virtual world for a game, these apps gamify the real world. Our mundane everyday activities in the non-game context turn into gaming opportunities for rewards like badges, points, rankings, and statuses.

But why apply game design elements to the non-game context in the first place? The short answer is that people are more motivated, engaged, and often achieve more in games than in the real world. Why are people better at a game than in real life? It is because games offer an environment intentionally designed to provide people with optimal experience by means of various gaming mechanisms and dynamics. Games make people perform better in the way the real world does not. It was in this context that a game designer and game studies researcher, Jane McGonigal, stated that reality is broken.”¹ Gamification aims at extracting those game mechanisms and apply them to reality in order to make the real world experience more interesting and engaging.

Gabe Zichermann’s definition of gamificaion as “the process of game-thinking and game mechanics to engage users and solve problems” expresses the goal of gamification well.² In this definition lies a good answer to the question of why libraries need to pay attention to games and game dynamics. Game dynamics can raise library users’ level of engagement with library resources, programs, and services. They can help library users to solve problems more effectively and quickly by making the process fun. A good example of such gamification is the NCSU Mobile Scanvenger Hunt, which was described in the previous post here in ACRL TechConnect blog.

What to avoid in library gamification

Since games can induce strong motivation and spur a high level of productivity, it is easy to overestimate the power of game dynamics. Perhaps, everything we do will turn into a game one day and we will be the slaves of omnipresent games that demand ever more motivation and productivity than we can summon! However, not all games are fun or worth playing. Designing good game experiences is nothing but easy.

The first thing to avoid in gamification is poor gamification. Gamification can easily backfire if it is poorly designed. Creating a library game or gamifying certain aspects of a library doesn’t guarantee that it will be successful with its target group. Games that are too challenging or too boring are both poorly designed games. Naturally, it is much more difficult to design and create a good game than a bad one. The quality of the game – i.e. how fun it is – can make or break your library’s gamification project.

Second, one can over-gamify and make everything into a game. This is quite unlikely to happen at a library. But it is still important to remember that people’s attention is limited in amount. The more information we have to process and digest, the scarcer our attention becomes. If a library offers many different games or a variety of gamified experiences all at once, users may become overwhelmed and tired. For this reason, in pioneering the application of game dynamics to libraries, the best approach might be to start small and simple.

Third, a game that is organization-centered rather than user-centered can be worse than no game at all. A game with organization-centered design uses external rewards to increase the organization’s bottom line in the short term.³ Games designed this way attempt to control behavior with rewards. Once users feel the game is playing them rather than they are playing the game, however, they are likely to have a negative feeling towards the game and the organization. While a library doesn’t have the goal of maximizing profits like a business, which can easily drive a business to lean towards organization-centered gamification, it is entirely possible for a library to design a game that is too heavily focused on the educational aspect of the game, for example. Such gamification is likely to result in lukewarm responses from library patrons if what they are looking for is fun more than anything else. This doesn’t mean that gamification cannot make a significant contribution to learning. It means that successful gamification should bring out learning as a natural by-product of pleasant and fun experiences, not as a forced outcome.

Harnessing the power of game dynamics

Games are played for fun, and the fun comes from their being ‘not’ real life where one’s action comes with inconvenient real-world consequences. For this reason, when a goal other than fun is imposed on it, the game begins to lose its magical effect on motivation and productivity. It is true that games can achieve amazing things. For example, the game FoldIt revealed the structure of a specific protein that long eluded biochemists.⁴ But people played this game not because the result would be revolutionary in science but because it was simply fun to play.

It is probably unrealistic to think that every task and project can be turned into a fun game. However, games can be used to make not-so-fun work into something less painful and even enjoyable to some degree, particularly when we lack motivation. In his book, Game Frame, Aaron Dignan cites the story of tennis player Andre Agassi.⁵ Agassi played a mental game of imagining the tennis ball machine as a black dragon spitting balls in an attempt to smite him. He did not hit 2,500 balls a day purely because it was fun. But by making the grueling practice into a game in his mind and tying the game with his own real-life goal of becoming a successful tennis player, he was able to endure the training and make the progress he needed.

In applying game dynamics to library services and programs, we can take either of two approaches:

The ultimate goal can be simply having fun in some library-related context. There is nothing wrong with this, and at minimum, it will make the library a more friendly and interesting place to patrons.
Or, we can utilize game dynamics to transform a more serious task or project (such as learning how to cite literature for a research paper) into something less painful and even enjoyable.

Gamification with little investment

Gamification is still a new trend. A pioneering gamification app, Gowalla lost to Foursquare in competition and was acquired by Facebook last December, and it is yet to be seen how Facebook will put Gowalla to use. Another gamification tool, Budge is closing down at the end of this month. For this reason, those who are interested in trying a gamification project at a library may wonder if the result will be worth investment.

In this early stage of gamification, it will be useful to remember that gamification doesn’t necessarily require complicated technology or huge investment. For example, you can run a successful game in your library instruction class with a pencil and paper. How about rewarding your library patrons who write to your library’s Facebook page and get most “likes” by other patrons? Or perhaps, a library can surprise and delight the first library patron who checks in your library’s Foursquare or Yelp page by offering a free coffee coupon at the library coffeeshop or simply awarding the Early-Bird badge? In gamification, imagination and creativity can go a long way.

What are your gamification ideas that can engage library patrons and enliven their library experience without huge investment? Share them with us here!

Notes

Jane McGonigal. Reality Is Broken: Why Games Make Us Better and How They Can Change the World. (New York: Penguin Press, 2011), 3. ↩
Gabe Zichermann and Christopher Cunningham. Gamification by Design: Implementing Game Mechanics in Web and Mobile Apps. (Sebastopol, CA: O’Reilly Media, 2011), xiv. ↩
The distinction between games with organization-centered design vs. those with user-centered is from Scott Nicholson, “A User-Centered Theoretical Framework for Meaningful Gamification,” (pre-print) http://scottnicholson.com/pubs/meaningfulframework.pdf. ↩
Elizabeth Armstrong Moore, “Foldit Game Leads to AIDS Research Breakthrough.” CNET, Sep. 19, 2011, http://news.cnet.com/8301-27083_3-20108365-247/foldit-game-leads-to-aids-research-breakthrough/. ↩
Aaron Dignan, Game Frame: Using Games as a Strategy for Success, (New York: Free Press, 2011), 80. ↩

Applying Game Dynamics to Library Services

There is a lot of talk about games at libraries. Public libraries in particular have been active in incorporating games in their programs and collections. Even for academic libraries, gaming is no longer a foreign topic. The 2012 Horizon Report sees Game-Based Learning to be on the 2-3 years horizon for adoption. That is not a very long time away from the present.

I am not going to talk about games here, of which I am a rather poor player in general. Instead, I would like to talk about game dynamics and how they can be applied to library services. I am really late for writing about this idea, which I heard about a few years ago. But probably now is as good a time as any as the Horizon Report this year mentions gaming.

A light bulb in my head lit up when I listened to the TED talk, “The game layer on top of the world” by Seth Priebatsch during my commute. (See the video below.) There, he talks about the game layer as something that is being built now after the social layer that Facebook has pretty much established. Just as the social layer has fundamentally changed the mode of human interaction and the way of our lives as a result, Priebatsch sees a similar potential in the game layer.

What has attracted my attention in this talk about the game layer was not so much the game per se as the impressive power the game dynamics wield to human beings. Once you hear those examples of the game dynamics, their impact is immediately obvious. But until now, I haven’t had a conscious understanding about how successful well-designed games can be at providing people with such engaging and immersive experience.

According to Priebatsch, among those game dynamics are: (a) appointment dynamic, (b) influence & status, (c) progress dynamic, and (d) communal discovery. (He says that there are three more but he only mentions four in the talk.) Since he details what each of these dynamics mean in the talk below with clear examples, I am not going to repeat the explanation.

Seth Priebatsch: The game layer on top of the world

To simply put, these game dynamics are very powerful motivators for human action. Did you know that Farmville can change the behavior pattern of over 70 million people by simply changing a rule for how often a Farmville user needs to water the crop? The power of these game dynamics stems from the fact that they require meeting relatively simple conditions in return for attainable rewards. Games usually begin with simple tasks that award you with some goods and elevation in your status or level. Then gradually, the tasks become complicated for more challenging rewards. The game dynamics drive game players to plan and perform simple to complicated actions. These often motivate individuals to exert a significant level of diligence, creativity, and resourcefulness.

What is really cool about these game dynamics is that they are applicable to any human action in the real world, and not just in the gaming world. Sure, you can create a game to tap into people’s creativity and diligence. (In another TED talk, “Gaming can make a better world,” Jane McGonigal explores the possibility of harnessing the human energy and creativity spent on gaming to solve the real-world problems. See the video below.) But, you do not have to. You can just as easily embed these game dynamics outside the traditional game sphere. These dynamics tend to be quite effectively utilized in games. But they do not have to be restricted to online games.

So my question is whether these game dynamics can be applied to make library services more engaging and interesting to library users? Can libraries take advantage of these game dynamics to help library users to attain the goals that they themselves probably want to reach but often fail to?

Here are some of my thought-experiments applying game dynamics to library services.

Provide level-up experience for library users.
Suppose your user logs into a library proxy system every time for browsing library’s databases, e-books, and e-journals. How about based upon the time spent and the number and frequency of log-ins, allowing the user to level up from ‘novice library user’ to ‘super researcher’? Of course, you would probably want to use way more appealing terms such as “Paladin level 20 Killer Ninja Researcher” instead of “Super Researcher.”
Award some status and powers associated with library use that can be admired (with the addition of visible tokens for them).
Allow users to tweet, Facebook, and G+ their updated status and powers as they level up, so that it can be boasted to others. Status and power is meaningless unless it is looked up to by others in one’s own community. How about re-issuing library cards as in Judo with some sort of belt system: red belt, black belt, brown belt, white belt etc.? Add up some sleek mini-posters that celebrate some of those high belt status in the library space where everybody can see. Or even better something users can boast in their Facebook pages. It might just work to motivate library users to study more, read more, and research more.
Show the progress bar in library catalog.
The progress bar makes you goal-oriented. It gives you satisfaction whenever you move the bar one notch to the right. It makes you feel that you are moving towards something good. Why not show the progress bar in the library OPAC? If a user run a search, show the progress! If a user selects a record in the search results, move one notch up in the progress bar. If s/he clicks holdings or the links in the record, how about showing the Happy Face or a Dancing Penguin for a second before moving on? Humans have such a soft spot for positive feedback that if a required action is simple and easy enough, they might just do it for fun.
Color-code the status of checked-out books.
In the library’s “My Account” page, mark past-due books as red and newly checked-out books as green. Items that are about the midway of the check-out period can be in yellow. Or show it as an hourglass that loses its sand on the top part as you pass the due date of library books. This may make people more compelled to return the overdue items.
Library currency to accumulate and spend?
Let users to boast taking out and returning books from the library to others. Maybe give them points per transaction? Social reading is already a big phenomenon. Combined with a library, it can create even more fun experience. Maybe it can be just like Gowalla or Foursquare. Maybe users can trace their reading history and find others with a similar reading pattern. How about letting library users to accumulate and spend library points (or currency) for coffee at a library cafe? Now some students may seriously start reading.

Game dynamics are significant because they can be used to build a foundation for our willing participation in a project for our own optimum performance. Libraries have been an indispensable means for individuals who aspire for learning, experience, and knowledge, and serving those individuals has been always a crucial mission of libraries. Game dynamics can be utilized to help libraries to serve such mission more effectively.

PS. Also check out the talk below by Jane McGonigal about her explanation regarding why people are so much more successful at games than at the real life and how we may perhaps harness that potential to solve the real life problems.

Jane McGonigal: Gaming can make a better world