The ubiquitous book – anytime, anywhere

I recently finished reading Cory Doctorow’s latest novel, For The Win. I’m not crazy about the book itself (a topic for another time), but the reading experience was different, more fluid, and ultimately better than what I’m used to.

Thanks to publisher Tor’s generosity at ALA 2010 last month I have a copy of the book in hardcover. And thanks to Doctorow’s business model of giving away free ebook versions of his works I had the text in e format too. This is the first time I’ve read a book while having access to both e and print versions at the same time.

As much as I enjoy my Sony Reader, a print book is still my personal ideal for most of the novel reading I do. I use the Sony primarily for convenience, like when I don’t want to carry a large hardcover on the bus. But if I’m sitting on the couch I still prefer a standard print book experience. With access to both print and e versions I was able to jump back and forth between the two, using whichever provided a superior experience at the moment.

And actually I had 3 options – Hardcover, Sony Reader, and the Aldiko ebook reader app on my phone. (Doctorow provides his ebooks in a variety of DRM-free formats compatible with a large number of devices.) I read the hardcover on the couch, the Sony on the bus, and a few pages here and there on the phone whenever I had some waiting in line time. It was convenient, easy, and I got through the book much faster than I would have otherwise.

But now I’m spoiled! Doctorow’s ebook give-away model is pretty unique, not many other authors do it. I’m not going to buy a book in both print and e, and library ebook options are pretty anemic. The only way this would happen again is if I pull titles from Project Gutenberg. But I’m not much of a classics reader, and Gutenberg doesn’t have a lot from my to-read list.

While I don’t think it’ll ever happen, I’d love for a purchase of a print copy to come with a free ebook counterpart. I’d even pay a little extra for the option, and the bonus to researchers of having a searchable text to supplement the print could be a considerable advantage.

Barcode scanning: Closing the app gap

I still think a lot (some might say too much) about what libraries’ mobile presence should be like. I’m still mostly happy with the decision to make a webapp instead of an app, but every once in a while I want to do something a webapp can’t. Barcode search has always been at the top of that list. We’ve got all that ISBN data in the catalog, and every book in a bookstore has an ISBN barcode. Matching those two things up would be pretty convenient. Why spend money on a book if it sits in the stacks above my head every day already, right? It’s also a feature that’s definitively mobile – it doesn’t really make any sense to search via barcode scan on a desktop browser. The best use case for catalog search via barcode scan is when I’m out and about in a bookstore, not sitting at my desk.

But webapps can’t access a phone’s camera. And no camera means no barcode scanning.

Both Android and iPhone have a number of barcode scanning apps available – including Zxing and RedLaser, respectively. Thankfully developers of both included ways to invoke those scanners from a webpage! More info on how to do this is here and here. It’s not too difficult – the only technical skill involved is understanding how to build catalog search URL.

Earlier this month we built barcode scan searches into our mobile catalog. It only works on Android and iPhone devices, and requires that Zxing or RedLaser is installed first. So it’s not a seamless experience and requires some explanation to users. I’m still working out those kinks, but was both comfortable with and excited enough about this feature to push it out with a beta label. It’s live on our mobile site at www.lib.unc.edu/m

Webapps still can’t do everything, but with a little creativity the functionality gaps close up a bit. I can’t tell you how happy I am that I was able to add barcode search to the site with a simple link instead of learning to code in Objective C 🙂

Here’s a video of barcode search in action on Android:

Geolocation at ALA 2010!

Screenshot on a DroidAs I’ve mentioned before, summer is often my most productive time of the year at work. Especially when it comes to special projects. Last summer I focused on developing a mobile site, and this summer I’m looking into the potential of geolocation in websites. My ultimate goal is to mash up GIS data with our special collections and a user’s current position. I’m not there yet. But I do have a system up and running that might provide some utility at ALA in DC next week!

Here’s the site, designed for mobile devices: http://www.hiddenpeanuts.com/ala I pulled the 18 program sites out of ALA’s list of programs, and plotted them on a google map. Then it plots the user on the same map via the phone’s GPS signal. I’ve tested it on an iPhone and Android phones, but I think it should work on webkit-based Blackberries and maybe even the Palm Pre too. (Update: Turns out the Pre doesn’t support geolocation via javascript. boo, indeed!) I’d love feedback on how those devices work (or don’t).

Obviously the site won’t show you much unless you happen to be in DC while loading it up 🙂 So here’s a demo which simulates the user being in DC.

I’m very interested in any feedback on this system. I know that the interface needs (a lot of) work, but this is as good as I’m likely to have time for before ALA. I’m also open to suggestions on what details about each location would be helpful to have on the mobile site. For now it’s just address and phone number.

Educause ELI Online Spring Focus Session

Today I presented briefly on mobile site-related things as part of Educause’s Online Spring Focus Session on mobile learning. Someone asked for my slides, so here they are! My previous slides from Handheld Librarian expand on a lot of what’s here.

Today’s slides, on slideshare:

(A couple of images got scrambled in the process of uploading to SlideShare, but all the content is intact)

Handheld Librarian & Mobile stats

I’ll be speaking later today as part of the Handheld Librarian II online conference. My Powerpoint slides are already online here, but I wanted to note some things I’ll be talking about that didn’t make it into the slides:

First, while there’s many other available frameworks than just the two I talk about, I do want to specifically point out the MIT Mobile Web project. The folks over at NCSU have done a great job implementing it with their library’s mobile site. They’re talking about it in a session right after mine, so I won’t be covering it in too much detail. MIT’s code is fairly robust, but also much more complex to get set up and running than iUI or Jason Clark’s work.

Second, some interesting stats. From two separate reports, both with data about December 2009. Looking at them side by side:

-Apple has 25.9% of the US smartphone market share (in devices sold), but iPhones also make up 54% of US mobile web traffic.

-Android has just 5.2% of the US smartphone market share (in devices sold), but makes up 27% of US mobile web traffic.

-Blackberries have an astonishing 41.6% of the US smartphone market share (in devices sold), but make up just 10% of US mobile web traffic.

There’s an important lesson here to keep in mind when choosing which devices to support with a mobile website. At first glance, looking at Blackberries’ market share alone, they seem to be the platform to support – it’ll get the most users in, right? Not when they use just 10% of all mobile web traffic! The heaviest users, the people we should be targeting now with our services, are on Android and iPhone. By supporting their combined 31.1% market share of devices with our our mobile sites, we’re available for 81% of mobile web traffic. That’s a pretty solid return on investment. I’m not surprised by these results, but it’s always nice to have numbers to back up intuition.

This isn’t to say that blackberries should be ignored – they’re just not the best target audience for a pilot program.

Mobile apps vs. Mobile web

Apple loves to tout their 100,000+ iPhone apps. Android recently topped a respectable 20,000. These are both impressive numbers, but how often do we really need an app instead of the good old-fashioned web?

Apps lock up data and go against one of the central ideas and advantages of the open web – the ability to link between pages.

A user recently asked if our mobile app could add links to Worldcat items from our own mobile catalog items. I didn’t know the answer, but thought it sounded like a worthwhile addition if possible. I remembered seeing a Worldcat mobile interface a while back, and went looking for it once again. I found that Worldcat recently moved from a mobile website version to a mobile app version.

A mobile website is pretty self-explanitory. It’s a website formatted for a mobile screen that you load in a browser. It’s part of the web as a whole. A mobile app is more like any application on a computer – you launch it, do what you need to, then close it down. But mobile apps as they exist today are largely walled gardens, and don’t share data with each other easily (if at all). So while Worldcat has all their records very nicely displayed in this app, it’s impossible for our local catalog to link to them from the browser*.

Worldcat’s regular (non-mobile) site is very linkable. If I want to link you to The Mysterious Benedict Society’s record, I just have to give you this to click on. That’ll still work in a mobile browser of course, but the resulting page is clunky to view on a smaller screen. When OCLC has obviously gone to a lot of effort to get their data into a mobile format, it just seems a shame to ultimately lock it away from other developers inside an app.

And believe me, a native app for a phone takes a lot of effort. I originally tried to write one for the UNC catalog, but the fact that I’m not much of an Objective C programmer reared its ugly head and I had to abandon the effort. The return on the massive investment of my time and effort it would have taken to code an app just didn’t make sense. And a library catalog app wouldn’t even have any extra functionality over the mobile website catalog I ended up with. Our mobile site works on almost any modern smartphone, but if I’d somehow managed to bang out an iPhone app that app would work exclusively on iPhones. I’d have to start from scratch again to get the catalog working on an Android or Palm phone, and what about the countless phones that don’t run apps at all? They’d be left out in the cold.

On the flip side, Apps certainly do have their time and place. They have greater access to the phone’s hardware than a browser, and can use things like the phone’s camera in ways that a mobile website currently can’t. But unless a hardware ability is central to an app’s purpose for being, I’d be hard-pressed to justify developing a full app instead of a mobile website. And now that many mobile browsers can access the phone’s GPS information, a webapp can actually do some basics of what were formerly hardware tasks. For example: I’ve become minorly hooked on the location-based service Gowalla lately, and Gowalla has no Android app – just a mobile website that can use the phone’s GPS to find where I am. It works really well. Full apps are also useful for offline tasks, since they allow caching of data & tools locally for use when there’s no connection to the web.

And apps do have an undeniable coolness factor. It’s a lot more impressive to say “Download our app in iTunes” than to give someone a URL to a mobile site.

But our library catalog & website don’t need a camera, and the very nature of a catalog is searching for information online – nothing can be stored locally in a way that makes any sense. Having a deliverable end product also wins out over the coolness factor with me, especially since I never could have completed the ‘cooler’ project in the first place 🙂

For the current state of the mobile web, I don’t think a mobile app’s advantages are enough for libraries. It’s important to get our information into as many of our users’ mobile devices as we can, and as quickly as possible. An app might come later; if the publishing world ever permits libraries to loan eBooks in a usable fashion, then sure a library eReader app would make sense to develop. But for now, when most of our mobile work is repackaging web data we already have into a new format, a mobile website is the way to go. It’s quicker to develop, works on more devices, preserves linkability, exposes our mobile pages for other developers to build on, and maintains the core functionality we’ve spent so much time developing for our non-mobile websites along the way.

(*As a side note, I did eventually dig up Worldcat’s old mobile web catalog. It still exists! But it doesn’t support direct linking either. This is another thing I’ve run into repeatedly – another argument/rant/post for another time.)

UNC Libraries’ mobile site

The summer is often my most productive time of year, especially when it comes to special projects. This summer I put my time into developing a mobile version of our website. I’m excited to announce that it went live last week, and I’m extremely happy with the results.

The mobile site is at www.lib.unc.edu/m

First, please note that it may or may not work quite right on standard desktop browsers. But take a look at it on an iPhone/iPod touch, Android phone, or Palm Pre. Any of those should work just fine, though some bits & pieces are optimized for apple’s devices. There’s also a plain text version at www.lib.unc.edu/m/plain, which any mobile device anywhere should be able to process in some fashion.

The fancier version was built with the iUI framework I mentioned previously. I’m amazed by how easy it was to develop with the framework – it really did all the heavy lifting of formatting and animation, leaving me to merely write the content.

But it wasn’t quite so easy to get what I consider the centerpiece of our mobile effort up and running: our mobile catalog. That was actually the whole reason I started a mobile site plan in the first place – I (and a number of users I informally talked to) wanted to be able to look up books while wandering the stacks. Our non-mobile catalog functions on a small mobile screen, but it was very much less than ideal and a bit tough to navigate. After exploring a few dead end avenues, I got lucky and discovered that our Endeca-based catalog has a built-in method for returning search results in XML. Using php I recrafted that XML into a mobile-appropriate page.

I’d like to particularly note that a mobile catalog would be impossible if we didn’t have Endeca as our catalog front end. III/Millennium, our underlying ILS, locks up our catalog and provides no easy way to get at the underlying data. And on a related note, while compiling a list of mobile-friendly database/article interfaces from vendors themselves I was appalled at how few exist. Ingenta, IEEE, and Refworks were the only three major ones I found. This is a plea for openness to ILS providers and other library vendors – if you’re not going to build these things yourself, please give us data-level or API access to the sources we’re paying you for. We can build some pretty cool stuff, if only you’ll let us.

Dept. of Public Information

Walking out of work recently, I encountered this flyer on the library’s public bulletin board:
1204081622.jpg

LOST
ourselves.
To find, please contact the UNC Department of Public Information and receive your
REWARD

The pulltabs to take with you have this link: http://departmentofpublicinformation.blogspot.com

The blog is an interesting collection of links and chronicle of events staged by this group around campus to promote knowledge of student rights on campus.

This is a great example of a semi-ARGish method being used to promote distribution of knowledge and education! One event even led people to relevant books on the library’s shelves.

It’s sort of odd to see the blog promoted now, when there hasn’t been an update for almost a month, but maybe something new will be happening soon. The flyer seems to be grabbing students’ interest – yesterday afternoon there were five pulltabs remaining, and as I write this there’s only one.

Alternate Reality Games and Information Literacy

One area where ARGs have near-unlimited potential is in teaching information literacy skills. By placing the skills’ use in the framework of a game, students/players become more invested and enthusiastic about learning these skills. In fact, they often may not realize they’re being taught at all. Here’s some random bits & pieces from the ACRL’s Information Literacy Competency Standards, with brief notes on how ARG players develop and use these skills while playing an ARG:

  • “Recognize that existing information can be combined with original thought, experimentation, and/or analysis to produce new information.” – ARGs require exactly this kind of thinking. Players must use their original thoughts to solve puzzles and interact with characters (existing information) via analysis and experimentation.
  • “Identify the value and differences of potential resources in a variety of formats (multimedia, database, website, book)” – Many ARGs require balancing information from a variety of source formats including websites, books, raw data, music, games, movies, etc.
  • “Create a system for organizing information” – Take a look at the amazingly in-depth and well organized wiki for the recent Dark Knight ARG here: http://batman.wikibruce.com/Home This was entirely player-made.
  • “Utilize technology for studying the interaction of ideas and other phenomena” – ARGs by their very nature require the use of many kinds of technology including GPS devices, smartphones, computers, cameras (still and video) audio recordings, etc. Players are encouraged to study and investigate the world around them.
  • “Validate understanding and interpretation of the information through discourse with other individuals…” – The Unforums are an example of a vibrant community of ARG players discussing and playing games with each other.
  • “Apply new and prior information to the planning and creation of a particular product or performance.” – Players must take information from previous parts of the game and decide where to apply it in order to move forward.
  • “Manipulate digital text, images, and data, as needed, transferring them from their original locations and formats to a new context.” – This is a very generically worded skill, but ARGs can still teach it. See any of the examples I’ve listed above.

Games4Learning: Alternate Reality Games

Last Friday I gave a presentation as part of UNC’s wonderful Games4Learning initiative on Alternate Reality Games (ARGs). I think these games have a huge potential to be used as a teaching tool for both social issues and information literacy. I’ll be writing more about this topic in coming days & weeks, but for now here’s my slides: http://www.hiddenpeanuts.com/permanent/haefele-args.ppt

They may not entirely make sense without my narration, but I wanted to get them linked. I’ll try to give some context in upcoming posts.