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.

IMG_0101
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.

photo
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.
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
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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

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.  

 

Tips for Making Your First Mobile App a Success

About a year ago we launched the Gimme Engine (gimme.scottsdalelibrary.org) – a mobile web book recommendation engine.  Choose one of the categories – Gimme a Clue, Gimme Something Good to Eat, etc – and the Engine will offer you a staff-recommended book from the Scottsdale Public Library collection, complete with summary, staff review, and a quick link to the mobile catalog to check availability or reserve.

Since launch, our app and the Gimme Engine Brain Trust that created it have won a number of awards – including a 2012 OITP Cutting Edge Technology in Library Services award.  What’s our secret?  We are happy to share what we learned in our process with the hope it will help you in your next technology process.

Find out what your users (and future users) want

When our team got together for the first time we had more ideas than we knew what to do with – everything from a mobile formatted version of our web site to a Dewey-caching in library scavenger hunt. We soon realized that in order for us to create a successful, and more importantly, sustainable mobile app, we needed to poll our customers and find out what exactly they want out of a mobile app. Though we had done some basic surveys of staff in the past, we didn’t feel that we were the experts best suited to properly create & distribute a survey that would ultimately drive our entire project.

We hired a local experience design agency called Forty to craft a survey to get the information we so desperately needed. Forty also helped distribute the survey via their social media, email lists and other outlets. This meant that in addition to our customer we would get responses from non-customers as well. This would help us understand if there was a difference in need between customers and future-customers (at least that is how we like to think of our ‘non customers’.)

What they want might be what you already have

There was in fact no real difference between customers and non customer need in the survey results but one thing was clear:  current and future customers had no idea that we already had a mobile catalog with most of the standard functionality that they wanted.  Great, we thought, just get the word out about the mobile catalog and our job is done!  Then we realized no, we still have all this LSTA money that the Arizona State Library was nice enough to give us . . . we should probably spend that out.

Maximize your resources

So we looked at the highest items on the list that we didn’t have in mobile – book reviews and staff recommendations.  That’s when we decided to make the book recommendation app.  As it turned out we already had a lot of the raw materials for the project.  Staff was already doing book reviews and posting them on GoodReads.  We had content enrichment services for bib data and book jackets(Syndetics).  And we had the mobile catalog and the ability to generate RSS feeds of items in the collection (AirPAC and FeedBuilder from Innovative Interfaces).  All we needed was someone with enough experience to put that together.

Back to Forty for the design work and to hire a programmer.  We had so little money to work with that I thought for sure the end result would use a rubber band.  But when we sat down with the programmer not only was he able to do the project he actually saved us $3,000 in expected software costs by putting together the feeds, mobile catalog, content enrichment with some JavaScript and the GoodReads API.  The end result is a very simple, easy to care for web-based app that keeps working as long as we keep feeding it the raw materials – staff book reviews.

Maximize your expertise

From the outset of this project, we engaged all levels of staff. This was critical to ensuring that whatever product we created would be supported throughout the organization, as well as vetted to ensure that we didn’t leave out any crucial elements.  One of those elements was the encoding that allowed FeedBuilder to pick up the items for Gimme.  A quick chat with the catalogers solved that problem – they created a series statement utilizing controlled vocabulary that would identify the item as belonging to a particular Gimme category and pasted the review into the MARC record. By adding Library staff review_[gimmeCategory] in the 830 field of each record and indexing it, not only were we able to create a constant flow of records for the Gimme feeds we were able to give all library staff easy access to these reviews when searching in the catalog.

The other process we had to create was a standardized way for people to submit reviews.  Here we called on the cataloging group, the folks who where posting to GoodReads, and our IT department to create a book review form on SharePoint.  The form itself was easy – staff at any level go to SharePoint (which functions as our intranet), type in their name, info about the book and their review and submit.   The catalogers and GoodReads group developed a process to “hand off” reviews that ensure that it gets encoded, posted in both the catalog and GoodReads,  and at all times is associated with the ISBN of the same edition so that everything seems to magically link together.  Having staff who don’t normally interact working together on the share outcome certainly fostered a sense of ownership and respect in the group.

Don’t just build it . . . make it fun

Once the Gimme engine design was complete, and we had the back end programming to make it work, we were ready to unleash Gimme out into the world. Our biggest concern was that Gimme would get lost amongst all of the other products and services the library offered. One evening while cooking a delicious shepherd’s pie, a light bulb went off over Ann’s head. Since we were using our library staff book recommendations to fuel Gimme, why not turn our Staff in marketing vehicles? The next day a call went out to staff asking whoever wished to help to come forward. The end result was 15 life-sized cardboard cut outs of library staffers, highlighting their personalities. Attached to each was a ‘speech bubble’ that directed customers to go to http://gimme.scottsdalelibrary.org to see what books that staff member recommended.

The next phase was to create floor decals to put in various spots in our five library branches, so as customers walked through the library they would gain exposure to Gimme. We created corresponding buttons for staff to wear, which helped spur conversions and questions from customers, “What is Gimme?” This marketing plan engaged all level of staff, which helped make the launch of Gimme a success.

One year later the Gimme Engine is continuing to grow with new categories and increasing stats.  Not only was the project a success but it by integrating the various workflows we’ve been able to make it, as well as doing fun reviews by staff, part of our culture.  We hope that our experience can help you in some way make your next project as successful as the Gimme Engine.

 

About Our Guest Authors:

Aimee Fifarek is the Library Technologies and Content Senior Manager for the Scottsdale Public Library in Arizona.  She has an MLIS and an MA in English from University of Wisconsin-Milwaukee and spent 6 years as the Systems Librarian at Louisiana State University in Baton Rouge before going to Scottsdale.  Her professional interests include ebook platforms & development, self-publishing, and mobile technologies.  She can be found on Twitter @aimeelee.

Ann Porter is the Community Relations Coordinator at the Scottsdale Public Library. She has over 11 years of marketing, PR and media relations experience, working for organizations such as a major cosmetics company, an online retargeting agency that was recently purchased by Ebay and for a major NFL team.