mobile trendiness

So a lot of libraries are on the bandwagon of developing “mobile applications” or “mobile interfaces” for their services.

My impression — and I would love to be shown I’m wrong here — is that the thought process is generally like this:

1. Everyone is doing mobile, we should be too!
2. Our users have mobile devices now!
3. So let’s give them something, anything,  mobile. Just come up with something mobile please.
4. Profit.

The problem with this, is you have no particular reason to believe the random “something mobile” you come up with is actually useful to your users. Do your users want to do that thing you provided from a mobile device?  This is even before you get to evaluating whether your particular mobile interface succeeds in letting the user do that thing. But before you even start, you should have some reason to think your users want that thing, no? Maybe there’s something else they’d want even more than the thing you are giving them, wouldn’t it make more sense to spend your scarce development resources on that mystery thing?

I’m not saying it needs to be some statistically valid rigorous year long research.  Just get some information on what your users actually want to do mobile that comes from somewhere other than your imagination or “what all the other hip libraries are implementing”. Such as:

• Are there web services your library offers they are currently trying to use from mobile devices, and being left unsatisfied?
• Are there kinds of research or library service use they’d like to do from a mobile device, but aren’t even trying because they don’t think it’s possible? (Possibly because it really isn’t possible).
• Are there kinds of research or scholarly activities they are already doing from mobile devices, but not using library services, and you think the library could provide a useful supplement there? [This last one is very dangerous to use alone as a basis for development though, and I’ll explain why I think so later.]

How could you find these things?  Well, you can just ask some users.  Reference or liason librarians could just call up 5 or 10 of their regular patrons, and ask them.  Or ask people who come in (or call, or email) with reference questions, before they leave.  Or just go into your library and collar random patrons and ask them. Sure, or do some kind of publishable rigorous research, I’m not saying that wouldn’t be useful, I’m just saying we can get some information without that, and some is orders of magnitude better than NONE.  (Another way to answer the first bullet up there is to look at the logs of your existing web services to see how often mobile devices access them — but that’s really only useful if you can somehow identify those patrons to then ask them these questions. The app could potentially notice this in the web access as it happens and pop up a brief questionairre, if you have enough access to your app to make it do that, and enough development time to implement it.)

So, readers, help me out.  Does anyone know of any information on what users actually want to do with library services and mobile devices, that’s out there somewhere?   If your library is “doing mobile”, did you base it on any information, and can you share your information about your users? If your library already has “done mobile”, do you have any information about whether those services are actually deemed useful by your users?   [Remember the Great Library Facebook Rush of 200whenever? My impression is that all those library facebook apps don’t get much use.]

So why did I say very dangerous above?

Are there kinds of research or scholarly activities they are already doing from mobile devices, but not using library services, and you think the library could provide a useful supplement there?

The problem with using this to spur mobile development, is that the reason your users aren’t using library services for these things may have nothing to do with “mobile”.

It may be that your services simply don’t meet their needs whether on a mobile device or a “traditional” device!   This is actually my bias:  I suspect that most of our library web services are not good enough, are not in fact meeting our users needs. AND I think we can do better.  But only if we spend development resources on it.

Which is my bias, and my concern about following the mobile bandwagon just because it’s trendy. If our basic web services are already insufficient, then developing mobile interfaces is premature, and will only result in insufficient services delivered on a smaller more mobile screen.  And has an opportunity cost; we’re spending development resources on that instead of on improving our services.

So I’d say, first you improve your basic web services so you are sure — based on actual assessment and information from your users — that they are meeting user needs. Then you just make sure the web services you’ve already got display reasonably on a mobile device, which if you implemented them from the start  using contemporary web standards (good information architecture, good semantic HTML, information architecture,  CSS, unobtrusive Javascript, not Flash),  can be as simple as a bit of CSS (and maybe javascript) tweaking for mobile media . Which once you have your cards in order from the first steps, is not a large development effort with a large opportunity cost, it’s just adding the frosting on the great web services you’ve already got to serve users whether or not they are “mobile”.

And only then, is it time to start thinking about whether there’s a contribution to user needs to be made by developing fancy platform-specific mobile applications that really take advantage of the unique “affordances” of mobile platforms, individually or as a genre.

But most libraries don’t have the first steps yet.  It doesn’t make sense to develop mobile services until you have good services to deploy mobilely. Most libraries have a lot of work to do there, and by focusing on the mobile bandwagon, they’re misdirecting resources needed to meet all their users needs, mobile or not.  This is my own bias.   And I try to get people to agree by first asking:

How do you know the mobile service you are getting out there as quickly as possible actually do meet user wants or needs?