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)

No tags

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.

No tags

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

No tags

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.

No tags

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

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.

No tags

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.

No tags

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.

No tags

Ridethecity.com is one of the coolest Google maps mashups I’ve seen lately. It centers on NYC, and is dedicated to finding bike routes around the city. It combines Google’s automatic pathfinding routines with the site’s creators’ personal knowledge of biking around the city. There are three options for planning a route: safest route, safe route, and most direct route. Direct will stick you mostly on roads, while safe and safest stick with varying degrees to bike paths and greenways. The safest selection will often take riders out of their way to find bike-friendly routes. I wonder – with topographic data now in Google maps, could a site like this also calculate bike routes with the least uphill distance possible? I’ve been riding my bike around Chapel Hill quite a bit, and Ridethecity makes me wish there was a similar site for my area.

This is a great example of making refined automatic routines even more useful by injecting a heavy dose of personal human expertise. It makes me wish we could get more open access to the inner workings of the databases that libraries pay so much for. What fun and useful mods would result?

No tags

I’m now convinced that Twitter’s killer app is conferences and other large scale in-person gatherings.

In Anaheim we organized meetups, kept tabs on concurrent sessions we couldn’t all attend, helped each other navigate the buildings, pointed out overlooked sessions, discussed sessions while they were going on, and even played a game.

I’ve conversed with a lot of the people I saw at ALA via twitter for a while now, and it was wonderful to put faces with names! And having a pre-formed group of people to coordinate with took a lot of the stress out of the conference for me. I spent less time wandering aimlessly and more time being productive.

The coolest example, for sheer scale, was when we organized a 10 person meetup at Disneyland on the fly, converging from tons of different locations, using nothing but twitter.

If twitter can get their stability issues under control before everybody jumps ship (which could unfortunately be any day now), it’ll be a wonderful thing. None of the replacement options out there seem to be quite as right for this kind of environment. So I’m crossing my fingers that we’ll be using twitter at ALA ‘09.

No tags

This was another panel presentation, each member spoke for a bit about the topic. I neglected to write down the presenters’ names, unfortunately, but did get their home institutions.

UC Merced’s setup was particularly interesting to me – as a new university, they were able to build their library’s policies and functions from the ground up. They do not have librarians regularly on the reference desk, instead relying on student workers to refer patrons to specialists as needed and emphasizing contact via digital means whenever possible. We’re moving a bit toward this model at UNC, and I liked seeing what a reference department could look like after a full transition to that model.

Appalachian State University has been experimenting with providing service via ActiveWorlds. I’m not sure that virtual worlds are the place to go just yet – I don’t think there’s enough concentrated population of our users there for it to be worth the effort of widespread implementation. But, that said, I’m glad that somebody is experimenting with it. They emphasized that we can’t create and abandon a service point – we must be fully committed to new projects.

Ohio University has experimented with reference service via video chat. Kiosks were placed in the stacks and connected to librarians via skype. They went unused. The kiosk was then moved near the main entrance, where it has generated about 1-2 questions per day. Being close to in-person access points limits its usefulness. They may try to come up with a better location later. The presenter pointed out that video chat is a new technology, just hitting the mainstream, and users may not be ready to use it in a non-personal fashion. This turned out to be a proof of concept project, and not a full success. It’s a very good example of how to develop and revise a new service method, and I’m very glad that ASU was so willing to share about something less than fully successful.

No tags