2011 Mover & Shaker award

Yesterday the 2011 list of Library Journal’s Movers & Shakers was announced, and I’m an honoree! Together with my coworker Emily King, we were recognized for our work on UNC’s first campus-wide Alternate Reality Game last year (among other projects).

I’m extremely honored and equally humbled by this. Thank you to all who nominated us! But this award wasn’t given in a vacuum – I wouldn’t have accomplished much of anything without the support of all my amazing co-workers and contacts.

Seeing myself listed alongside so many amazing libraryland folks is very surreal. And that doesn’t even cover previous years’ honorees – many of whom I consider mentors and idols.

Fellow honoree Bobbi Newman did a great job of compiling links to all of this year’s Movers & Shakers.

Upcoming presentation: Computers in Libraries 2011

I’m very excited to be presenting briefly at Computers in Libraries in DC next week! Come see me at 4:30 on Monday, 3/21. I’m not quite sure where I’ll be, but I’m part of the Cybertour series of quick presentations. Here’s my slides in advance, though they probably make more sense if you hear my talking that goes with them:

Libraries as techshops

I respect the people at Make Magazine quite a bit. I may not always be skilled enough to replicate their impressive DIY instructions, but they make me want to improve those skills and tend to have unique perspectives on fixing problems.

So when one of their writers speculates at length about the future of public libraries, I stop and listen.

That piece provides an interesting option – can libraries be retooled as public-access techshops? We’re lucky enough to have a techshop locally here in the Triangle. The basic idea is that members have access to a large variety of tools, from hammers on up to laser cutters and 3d printers. I’ve toured the space before, and it completely makes me want to build things. I have a 2 month membership credit waiting to be used, and what keeps stopping me is that I simply can’t decide what to work on. Too many options!

I don’t know if converting public libraries to the techshop (or similar) model is viable – I’m especially concerned as to whether a tax base would support a library concept that doesn’t involve books – but this article makes me wish I worked in a public library so I could find out.

[As a side note, the concept makes excellent further reading to go with Eli Neiburger’s recent “Libraries are screwed” talks (1,2). ]

Take ebrary’s survey… please.

Last week I ran across a link (via Paul Pival) to ebrary’s current survey about the future of their platform. If you have any experience with ebrary, you’re likely as frustrated with their UI and limitations as I am. So you should go take it. I’ll wait.

Good, you’re back! When I first saw this survey I was very excited. Ebrary as it stands right now is an awful user experience and interface, to the point that I often order a print copy of a book for work instead of an ebrary copy. And while I’m excited that they want to improve, even this survey itself shows how far they have to go: it uses terminology (“tethered systems”) that I’ve never encountered in this context before, and honestly the whole thing doesn’t make a lot of sense to me. One question seems to imply that mobile apps can be used on desktop machines. If such a major provider of academic library ebooks thinks that’s true… well they genuinely need our help.

So take the survey, if you haven’t already. It sounds like they’re at least considering some sort of offline reading ability, which is a step in the right direction and should be encouraged.

Death of a Middleman

Related to the HarperCollins/Overdrive fiasco*, Jason Griffey makes a couple of ominous points over at Library Renewal. I want to focus on one bit in particular:

“It is vital that libraries find a way to move out of the middle-man between vendor and patron, and even out from between publishers and patrons. In the world of the digital, disintermediation is the rule.”

This is something I’ve wrestled with for a while now, and almost been afraid to articulate. Heretical statement time: In the Overdrive->Library->User chain of loaning library ebooks, why does the library have to be part of that deal?

Overdrive has the potential to be the Netflix streaming option of ebooks. What happens when they decide to offer a direct subscription option to individual users? And what if that individual subscription cost is less than an individual’s library-related tax burden? Which option is more appealing to support?

Jason’s right – we need to step out of the middleman role in this equation. And we need to do it fast, before it’s too late. I don’t have the answers about how to redefine ourselves in regard to the new reality. But if any good comes out of the HarperCollins nonsense, it can at least start the conversation.

*(Sarah Houghton-Jan has analyzed the situation far more insightfully than I ever could.)

Wake up, citation styles!

Everyone, including the New York Times, seems to be hailing Amazon’s decision to add page numbers to the Kindle.

The lack of page numbers (when you can change font size in a book, the number of ‘pages’ in the title grows or shrinks) has been a long-time critique of the Kindle, at least back to Princeton’s 2009 pilot program. The critique often specifically centers on one question: How do I cite a Kindle text in established styles without page numbers?

This always rings hollow to me. The problem isn’t with the Kindle, it’s with the citation styles themselves. Kindles already provide ‘location’ numbers, an identifier linked to each bit of text regardless of font size or subjective page number. Why can’t that just be used instead of a page number? It’s more exact than a mere page number could ever hope to be. And isn’t that the whole purpose of citations? Being able to pinpoint the original source? The APA Style blog seems hell-bent on taking an alternate, overly complicated route instead.

I suppose this is a moot argument. The styles won, Amazon is adding page numbers. And I understand that it’s hard to use a location identifier if you don’t have access to a Kindle. But why should digital text have to constrain itself to the way things have always been? Why are citation styles so inflexible?

How I learned to stop worrying and love the Kindle

I’ve ranted before on multiple occasions about my issues with the current state of the commercial ebook setup.

Then I got a Kindle for Christmas.

I haven’t quite done a 180, but after truly giving the Amazon ebook ecosystem a fair chance I’m more willing to highlight the positives of the experience.

Like Sarah, I feel like a bit of a library traitor in admitting all this. But, things I really like about my Kindle:

  • Portability. A Kindle is much lighter than most hardcover novels. It’s also much easier to read on the bus, where I often have to stand. I can read the Kindle with one hand, and keep myself upright with the other.
  • Cross-device sync. if I have a few minutes to kill while waiting in line, I read a few pages of a book on my phone. When I get back to the Kindle, it knows where I left off. if I need to do serious work with a book, I move to my PC. It all just works, pretty seamlessly. I wish the sync feature was more robust than a simple ‘furthest page read’ notion, and that I could sync non-Amazon content across devices in the same way. But it’s still very handy.
  • Note-taking & highlighting. For reading non-fiction, a Kindle is invaluable. I’ve never been one to scribble margin notes as I read, mostly because I know I’ll never go back and find them all later. But the Kindle puts all notes & highlights in a centralized, web-accessible location. For serious non-fiction this adds real utility to a book that paper copies simply can’t provide. It helps in fiction too. I find myself highlighting the quotes I really like, and now they’ll be much easier to track down in the future.

These are all things that move a book beyond paper. I think I may have been too hung up on the things that Amazon’s ebooks take away from a purchased print title – loanability to friends (Amazon’s new title loan feature is so crippled that it’s useless), library use (nonexistent), resale (nonexistent), etc. While those are still issues (in some cases major ones), I haven’t previously focused enough on the extra features Amazon adds to a purchased title.

I still adamantly refuse to pay more for an ebook title than the print version, and I’ll keep that stance until the issues I listed above are addressed. But I’m now ok with paying a price equal to the print title’s. I’m giving some features up, but also gaining others in exchange. Features which greatly enhance the way I consume text.

The issue of ebooks and libraries is a larger one, which I’m more and more pessimistic about, and a topic for another time (libraryrenewal.org did recently restore a bit of my hope). But as a reader, if not a librarian, I’ve learned to love the experience the Kindle provides. I guess the title of this post is a bit of a lie – I didn’t really stop worrying, but I now worry a little less.

Virgin’s Project – app overkill

cover of Project, issue 1Earlier this week, Virgin launched an interesting new project. It’s called, well, ‘Project’. Project is essentially an iPad-only magazine. The key word is only. I’d link you to an article in the magazine, but I can’t.

See, Project has no real web presence. They maintain a blog, but that blog’s content is entirely separate from the app’s articles. The only way to read those articles is via the iPad app ($2.99/issue). This restriction cuts to the heart of my ongoing concern with app culture. As I’ve said before, Apps lock up data and go against one of the central ideas and advantages of the open web – the ability to link between pages.

Project could have the most fascinating articles in the world, and nobody would know. The Project app has no copy/paste option, no real export ability at all. The only included export feature (and I use that word loosely) is emailing a screenshot of one page of an article to someone. I’d be embarrassed to share info with anybody that way.

Without the ability to link articles, Project loses out on the magic Google juice. The only way to find text in the article is by random browsing through the pages. Nobody will ever just stumble across a Project article unless they were specifically looking for it in the first place.

Jeff Bridges wanders through a Project article via videoI understand that Project wants to experiment with magazines in the emerging tablet world. And it admittedly has some nice features integrating video and slideshows into the pages (Jeff Bridges wanders around the cover and a couple of interior pages while you read (see screenshot), and the effect is not unlike a photograph from Harry Potter). But locking all the content inside an app is a huge misstep.

Why not go after the tablet market with an HTML5 webpage instead? I’m willing to bet that 90% or more of Project’s multimedia functionality could be replicated on the open web. The result would be cross-platform (other future tablets could read it too), and the content would be linkable and Googleable. Lock it behind a subscription wall if that’s the desired business model, whatever. But on the open web users could at least stumble on an abstract or summary. Just put it on the web somehow. I’m not saying Project’s content is particularly amazing, but with the existing model how would anybody even find out? It’s impossible to post a link to an article on my blog, twitter account, or anywhere else.

Or please, at least allow readers to copy and paste text snippets. If I ever wanted to quote a Project article, I’d have to transcribe the text word by word. In the year 2010, that’s insane.

Apps have their place, but locked-down magazines aren’t it. This kind of thing hurts the internet.

LILRC Presentation

Last week I had the opportunity to talk with the friendly folks at the Long Island Library Resources Council about mobile web development for libraries. I had a ton of fun, and the group had some great questions! Thanks everyone!

My slides are embedded here, and the original powerpoint file is available at http://bit.ly/LILRCmobile

(note that the animations don’t work on Slideshare)

Android’s App Inventor: Drag and Drop Programming

It took a while, but Friday afternoon I finally got an invite to use Google’s App Inventor program. What is App Inventor? It’s Google’s attempt to simplify building apps for Android devices. Apps are built using a drag and drop interface, and reflected instantly on a connected Android device.
App Inventor UI screenshot

I was skeptical about the system’s ability to produce apps of any real functionality, but I was happy to be proven mostly wrong. Building a well-structured UI is admittedly almost impossible, with only basic layout and design tools available. But the app inventor does provide easy access to surprisingly complex elements of the Android functionality. The GPS, barcode scanner, camera, speech recognition, and accelerometer are among the tools easily usable via drag and drop. After placing buttons and labels to design the UI, a separate drag and drop interface is used to establish how those elements interact with each other. A series of blocks click into each other, with a bit of typing to provide some details.

Blocks Editor

It’s a nice system, and my skepticism about App Inventor’s potential beyond the toy level was quickly overcome. I ran through the first tutorial app (touch the picture of a cat and it meows! This didn’t help my skepticism…) in a few minutes. Less than an hour later I’d built an app to search the UNC catalog via an ISBN barcode scan. It relies heavily on our existing catalog webapp to do the actual search, but still! I mastered using the barcode scanner for apps in less than an hour. My previous attempt at Android programming (in Java, before App Inventor existed) took me four hours to build an app that simply displays an image. And that simple task drew on every single bit of programming know-how I could dredge up from my undergrad days.

The barrier to entry for using App Inventor is almost absurdly low. My slight background in programming did help, and I would have taken a bit longer if I wasn’t familiar with things like variables and function returns. But the point of App Inventor is that I wasn’t required to know those things in advance. I could have picked it up in a little extra time. This kind of setup seems perfect for intro-level computer science courses, teaching basic programming concepts while retaining the satisfaction of seeing a fully functional app at the end. Google definitely realizes this and is targeting educators as potential users.

App Inventor is clearly still a beta product, with some notable limitations. Apps built in App Inventor can’t be distributed in the Android Market. The install files need to be manually distributed to phones. There’s also no resulting Java source code to tweak for more advanced purposes. And disappointingly, using APIs beyond a prescribed few (Twitter, Amazon, etc) involves more complicated Python coding. There’s also some strange odds and ends, like not being able to change the app’s icon.

I’m not under any illusions that App Inventor apps will someday replace Java-coded apps. But it got me excited about programming in a way I haven’t been in years. That’s gotta count for something.

If you’d like to try the barcode scanner app I built and see what App Inventor is capable of, here’s the installable apk file: http://dl.dropbox.com/u/905114/UNC_Catalog.apk