UNC Archives - Page 2 of 2

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!

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

eBooks – Who’s doing it right?

I’ve spent a lot of time lately thinking (and writing) about eBooks, usually taking a pretty negative slant toward existing eBook publishers and vendors. DRM, distribution models, even publication timelines – much of it is a huge mess.

But I don’t want to seem too negative – I still think eBooks as a concept hold massive promise. It’s just many of the current implementations that’re flawed. So who’s doing it right? Here’s a handful of companies and products which I think are on the right track:

1. SpringerLink
Much of my thinking centers on the consumer publishing eBook panopoly – the Kindles, Nooks, and similar devices of the world. But there’s of course an academic side to things too. I have major beefs with a lot of the vendors and publishers who provide eBook packages to universities & colleges. Most of these are a topic for another post. But one thing I want to cover here: Many of them commit one of my pet peeve sins by making the books non-downloadable. They can’t be used on any kind of personal eReader device, or even viewed on a PC without an internet connection. But the SpringerLink collection that we subscribe to at UNC provides simple, clean, downloadable PDFs. There’s no password protection on the files, no DRM, no clunky web client we’re forced to use. They trust users to download a chapter and use it responsibly. As a result they’re the first eBook collection I search and show to students.

Sure, I wish SpringerLink had a more flexible format than PDF, but this is a step in the right direction. While other vendors like eBrary are rushing to finish off what will no doubt be limiting device-specific apps for their content, Springer lets readers choose how to consume their text.

2. Fictionwise
Fictionwise.com isn’t perfect, but they’re still my favorite eBook retailer. They sell a large portion of their titles DRM-free, which means they can be read on virtually any device or computer in perpetuity. There’s no license keys to maintain, no chance of a distributor retroactively taking back a sale. They also provide an archive of my purchases – I first bought a title from them in 2003, and I can re-download that book as much as I want today. I can even still get to the titles I purchased which they no longer sell. I wish their catalog of non-DRMed books would grow, especially among current bestsellers, but Fictionwise is still the only place I buy my eBooks from today.

(One caveat – Barnes & Noble bought Fictionwise last year. I hope B&N lets FW keep its independence.)

3. Calibre
eBook file formats are far from standardized. There’s .epub, .lrf, .html, .mobi, .pdf… the alphabet soup goes on forever. And of course no one device or program supports them all. The situation is a head-scratcher, and that confusion costs consumers & students time and money. Once upon a time it was a nightmare trying to convert from one format to another. Then along came Calibre.

Think of it like itunes for eBooks. It converts from almost any format to any other format, provides sophisticated yet user-friendly metadata management, and even syncs files with eReader devices. As a bonus, it’s open source & free to download!
Calibre single-handedly increased my ability to read eBooks by roughly 100% (my very scientific measurement, yes), and decreased my frustration even more. It doesn’t work with files locked down via DRM, but that’s a fault of vendors and not Calibre.

4. Comics by Comixology
Technically this is about comics, not simple text, but either way it’s still eBooks of a different sort. Comics by Comixology (henceforth referred to as simply ‘Comixology’) is an iPhone app which sells downloadable comic books. Many of them are adapted from print versions, but optimized very well for the iPhone & iPod Touch’s smaller screen. Panels zoom in and out and flow together. And in a first for digital comics, Comixology even sells issues from many major print publishers like Marvel and Image.

The comics only function on the iDevices, of course, which is something that would usually bug me. But the user experience is so good that I’m willing to overlook it for now. And then comes what I like best about Comixology – the price. Most issues are either $.99 or $1.99, which frankly is what a comic book should cost in any form. Many print comics now cost $3.99, and then after that ripoff I have to find somewhere to store them. As a result, my comic buying in the last couple years has dropped way off.

So $.99 for something I don’t have to find storage space for is a very attractive alternative to me. Example: I recently wanted to read the newest Atomic Robo collection. Amazon charges $12.89 for the print version, down from an $18.95 list price. I picked up the whole thing on Comixology for $4.95, and had a great digital reading experience without taking up space on my living room shelves. Cost effectiveness trumps a lot for me. Many times publishers charge resellers like Amazon the same wholesale price for both print copies and eBooks. This baffles me to no end. Comixology and their content providers recognize how much cheaper digital distribution is, and adjusted their prices accordingly.

I consume comics differently than I consume books. Comics by Comixology (despite their awkward name) is smart enough to realize that I’m not alone in this, and found a way to make the restrictions I usually foam at the mouth over become a palatable choice.

(note: Comixology has multiple apps for the iPhone, and I’m talking about the one specifically called ‘Comics by Comixology’ here.)

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:

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.

ALA 2008: What is the future of face-to-face reference?

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.

Libraryh3lp – Javascript based IM reference service

My supervisor, Pam Sessoms, has spent years building up the IM reference service throughout campus at UNC. Up until recently, we’ve been using a combination of a custom Pidgin client and Meebo widgets to make the system run. But recently we swapped out the Meebo widget for a custom javascript-based chat widget that Pam and her husband have coded up on their own.

It’s still pretty early in development, but I think their ‘libraryh3lp’ system is an amazing step forward. For one thing, javascript has a much higher compatibility rate than Meebo, which relies on flash. I even got it to work on my iPod touch’s browser! It is also much better from an accessibility point of view, and plays nicer with screen readers for the visually impaired. Also also, the service runs on a custom Jabber server which gives the library much more internal control than relying on a third party network.

Eventually routing and queueing functions will be added, steering the product much more toward library-based usefulness than any of the IM clients currently out there. I’m really excited to see where this goes!
Here’s the project wiki: http://libraryh3lp.com/wiki/Main_Page

And the Google Code page: http://code.google.com/p/libraryh3lp/

And lastly, you can sign up for an account and get your widget up and running with these instructions:
http://code.google.com/p/libraryh3lp/wiki/WebChat

Changes: Chapel Hill-Bound!

Starting November 5th, I’ll have a new job – “Reference Librarian for Emerging Technologies” at UNC Chapel Hill – Davis Library! The full position description is online here for now.

The decision to leave UAH was a hard one, and I’ll genuinely miss working with everybody there – I’ve learned an immeasurable amount from them all and was able to get experience in just about any area you can think of. But this is a good move for me, and I can’t pass up the opportunity.

So, it’s going to be a busy couple of months 🙂 I’m really looking forward to getting started.