If you already have a mobile device of recent vintage, commit to using it as your primary device for accessing your library's site and systems. If you are an employee of an academic or special library or other library where you are not also a frequent patron, consider becoming a mobile-only user of your local public library.

Give it a week or two. Document the experience. Use your website, OPAC, licensed resources, reservation forms, chat service, guides, the works. Don't limit yourself to those systems created by your library. If your users access it through your website, you bear some responsibility for the user experience, whether it's within your control or not.

Keep track of those resources or systems that automatically detect your mobile device and either notify you of a mobile interface or direct you there automatically. You will likely find some instances where you hit dead ends or where you're unable to access files, pages, or systems. Note especially when user-facing interfaces or systems are challenging or impossible to navigate. Are there interfaces in which you consistently found yourself inadvertently hitting the wrong links or buttons? Systems that appear to serve up files that your device is unable to load? How much longer does it take you to complete tasks as compared to your usual workflow?

As discussed above, e-book readers are available for nearly every smartphone platform, and most of the applications are free to install. Commit to using one of these tools to read your next book. Choose one of the many free public-domain titles that are available in these applications. Or take the plunge in the name of research and buy an e-book from the Kindle, iBooks, or Nook store. If your library subscribes to OverDrive (figure 24) or another e-book platform, try it, not as a library staff member, but as a reader.

This may be a humbling or frustrating experience. It will be eye-opening. It may also have very positive aspects. Note if there are situations where your mobility allows you to accomplish tasks that you couldn't if you needed to be seated at your regular workstation.

Did you see another passenger on the bus or train reading a book that you'd been meaning to request? Were you able to request it at that very moment from your mobile device rather than hoping to remember once you got to your desk? Were you able to read on your mobile device long into the night without disturbing your partner with a bedside light?

Keep track of all your observations, both positive and negative, and share them with your colleagues. Encourage them to do the same. You will quickly be able to develop a list of areas where you should improve your mobile user experience.

Very few of us own or carry more than one current-generation mobile device, even gadget obsessives like your author (though once there's a contract-free Android equivalent of the iPod Touch, I expect that to change). The mobile device landscape is diverse, and becoming more so each day as new and worthy competitors to the established platforms enter the stage. So while our individual experiences with a single mobile device are instructive in creating a mobile strategy, they will not represent the diversity of our user base.

Canvass your staff, users, friends, family, whatever it takes, and find a willing group of people who carry a representative sample of the most popular smartphones and operating systems on the market. If I were convening such a group today, I'd hope to have a user each with an iPhone, a Palm Pre or Pixi, a device running the current and at least one past version of Android (such as 2.1 and 2.2), and user each for a recent BlackBerry device running the 6.0 version of the operating system and one with an earlier version. Windows Phone 7 devices may take some time to penetrate the market, but if you can find someone who uses one, so much the better. If possible, convene the users together on-site with a few of your public services, systems, and IT staff. It may be useful to use an opaque projector to display users’ handsets on a screen so not everyone has to hover over the users’ shoulders. Appoint at least one person to take detailed notes.

Ideally your focus group would consist of more users than staff, in which case you can begin by asking about their typical usage patterns for your services and systems. Do they typically access your systems from their home or work? Or from workstations in the library? Do they use your licensed databases, indexes, or e-books? If so, which ones? Do they often reserve books or other materials online for pickup in the library? Perhaps most importantly, are they already using their mobile device to interact with the library? If so, how?

Once you've established a list of your users’ typical tasks, ask each user to walk your staff through any library tasks for which he or she is already typically using a mobile device. As is often the case, expect to see some usage patterns that you don't expect. Rarely do our preconceived notions of our users’ methods match the reality. Next, ask users to step through typical nonmobile library tasks. Can they easily browse your collection? Access their account information?

With each of these sites, services, and tools, document what works, how well it works, and what doesn't work. You'll likely find that with ample zooming, tapping, and fiddling with tiny controls, your mobile users can accomplish a great deal with their devices. You will also likely find some tasks they can't accomplish. Finally, expect to find some tasks that, though possible, are challenging or time-consuming enough in the mobile environment that your users are unlikely to attempt them again.

This process should give you a good idea of where your library currently stands: which of your tools and services are usable, which may be frustrating, and which are downright broken for mobile users on various platforms. Once you have this list to start from, you can undertake one of four methods for beginning to develop your mobile service:

• Revamp your website for mobile-friendliness.
• Develop a mobile website.
• Develop mobile web applications (by which I mean applications that run within a mobile device's web browser).
• Develop native mobile applications.

We'll explore these options in the next sections.

In your audit of your website and other tools using various mobile devices, you likely found that the vast majority of tasks can be accomplished by mobile users, provided they have requisite patience. You also likely found some situations where users are stymied by code or multimedia that was designed for desktop users without regard for alternative platforms. Even if you have limited staff resources, there are some steps you can take to improve your existing site and make it more mobile-friendly.

If you have a little more time and resources to devote to your library's mobile strategy, consider developing a basic mobile website. It doesn't need to be anything fancy in order for it to be useful. By repurposing some basic content and linking to third-party mobile tools, you can likely cobble together a site that will be just what your users need when they want to access your library info on the go.

If you have access to sufficient developer expertise, you may consider adding levels of functionality to your mobile website by creating custom interfaces for your local systems, such as your OPAC, federated search, ILL, and circulation/account system. Increasingly these systems offer application programming interfaces (APIs) that allow for programmatic interaction with other applications. Such APIs in an OPAC or ILS might, for instance, allow you to take the input from a simple web form and pass it to the OPAC as a search query, then receive the results of that search back as a data stream that you can skin appropriately for your mobile web application.

You may be able to craft a similarly mobile-optimized interface for a link resolver, allowing users to search or browse for electronic journal titles. At the University of Minnesota, our developer John Barneson realized that while publishers and other vendors didn't consistently offer mobile versions of their sites, our federated search tool had a robust API, allowing him to create a mobile-optimized search interface not only for traditional federated searching, but for searches targeted to single databases. Using the API meant that we could, in one fell swoop, have a mobile search interface for any of our databases that were compatible with our federated search tool (figure 32).

When libraries begin to devote the time and resources necessary to create these more complex mobile tools, it's important to spend some time thinking about not just what is possible, but what's truly appropriate to present to mobile users. It is possible to direct users to Ebsco's mobile interface, or even to bring them directly into the database via a mobile federated search interface. And once there, it is possible, on the vast majority of smartphones, to open up PDF files containing the full text of articles. However, the prospect of reading these PDFs on most mobile devices is still quite unappealing. The layout of most PDFs has been optimized for 8½-by-11-inch paper in portrait orientation, and, let's be honest, they're a pain to read on an average laptop screen, much less a mobile screen that may be as small as one tenth the size.

So, reading full-text PDFs is possible, but not necessarily appropriate. In considering common contexts of mobile device use, it's more appropriate to think of the user not in the mindset of concerted researching, but instead in brief moments of verification. Rather than working to support complete digestion of an information object, we should optimize our web applications around discovery and, most importantly, marking or holding for later retrieval. The appropriate calls to action in a mobile library web application should be “bookmark this,” “request this item,” “e-mail me these records,” and so on.

There is one gee-whiz mobile web application feature that I'd like to see more libraries implement. Most smartphone browsers support the draft HTML5 Geolocation API, which allows the user to grant webpages access to the phone's location information. Likewise, many licensed electronic resource agreements allow for free public access on site in the library. How cool would it be to create your library web application such that users could be authenticated into your electronic resources on their mobile devices by proving that they were in your library via geolocation? Very cool is the answer.

W3C's Geolocation API Specification

http://dev.w3.org/geo/api/spec-source.html

As mentioned earlier in this report, the iOS App Store for iPhone, iPod Touch, and iPad has been a juggernaut. In the two and a half years since the App Store opened its virtual doors within Apple's iTunes media management and syncing application, more than 250,000 applications have become available, and have been downloaded over 6.5 billion times. Developers of paid iOS applications split the sale price 70/30 with Apple, and by mid-2010 the 70 percent that Apple pays developers had topped $1 billion.²

The Android Marketplace has lagged behind the iOS App Store in the number of applications available for download, the number of applications downloaded by users, and the profits realized by developers. However, as Android adoption nears or surpasses that of iOS, the Android development scene has begun to blossom.

Apps have truly become the watchword of this new mobile renaissance. But you probably shouldn't build one.

Let me explain. There are three reasons why you might want to build a native mobile app:

1. Profit: It's clear that it's possible to make money building software for mobile devices, especially for iOS.
2. Native device functionality: If you have an idea for an application that requires access to the camera, the compass, the tilt sensor, you won't be able to do that with a web app.
3. Exposure: You may assume that simply having an app will burnish your reputation among the cutting edge and provide opportunities for press releases.

So, to examine each of these reasons. First, if you manage to figure out a way for your library to turn a profit with a native app other than by jamming it full of advertising, call me. With some notable exceptions, we're not in the business of making a profit, nor for charging for our services. So, unless you have a very unusual library or some very unusual collections that would lend themselves both to mobile applications and to monetization, it's unlikely that profit is an appropriate motivation for building an app.

Implementing native device functionality can be very, very cool. Apps like RedLaser (owned by eBay) use the iPhone or iPod Touch camera to scan UPC barcodes so you can compare prices on items across various online resellers. They've also partnered with WorldCat so that when you scan a book you can see if it's available in a local library. RedLaser even provides an SDK for its barcode scanning function, meaning a library could craft its own app using this technology. Functionality like this is simply not available through anything other than a native app.

There's no doubt that having mobile apps provides an opportunity to talk up the cutting-edge developments at your library. However, it's no longer the case that simply having an app will drive users to your library. Between the various smartphone platforms, there are nearly half a million applications available, and a library application with local or regional reach is unlikely to make it into the “top download” charts that drive massive adoption.

There is one overarching reason why you might not want to build a native mobile app: If you want to do it well, it's expensive.

Craig Hockenberry, the developer of the popular iOS Twitter client Twitterrific recently responded online to a programmer who speculated that the app likely took 160 hours of development time and 40 hours of graphic design time (plus another month for testing). Hockenberry implied that estimate must have been generated under the influence of illicit substances. A recent update to the program had in fact taken more than 1,100 developer hours and 225 designer hours. He estimated the total cost at nearly a quarter of a million dollars in time and expenses.³

Now, Twitterrific is a highly polished application, but at its core, it's simply a mobile-native interface for Twitter's API. It's not that much different conceptually from what a library's native app might look like, except that a library's app would likely be more complicated and involve creating an interface for a number of different systems’ APIs. And Twitterrific is only for iOS. Developing for Android, BlackBerry, webOS, or Windows Phone 7 would require a complete re-creation of the code, as these platforms share almost no common elements.

It is certainly possible to create native applications on the cheap. There are some tools like PhoneGap that provide options for building a single application that can be deployed to multiple mobile platforms. If you already have a mobile website, it's possible to package it in an application that acts as a simplified web browser dedicated to your site. However, in doing so you're asking your users to take the additional steps of downloading and installing an application and are offering no additional functionality to justify their effort. Worse, unless you devote developer time to creating data that can be stored locally on the users’ mobile device, you've created an application that won't work offline, one of the key differentiating factors of apps versus the Web.

PhoneGap

www.phonegap.com