Library mobile apps vs web apps - Some analysis

In a previous post entitled, What are mobile friendly library sites offering? A survey.
I surveyed over 40 mobile friendly library pages. Since then this number has almost doubled, and I expect that the list here will top 100 by the end of the year.

Of course, mobile friendly sites or library web apps are not the only option. The other option is to create mobile apps. These have being a less popular option because it takes a lot of work to create a mobile  app, and unlike web apps (which are basically webpages configured for mobile surfing), mobile apps require more programming and in some cases such as iPhone apps, require that you pay a fee to list on Apple's itune.

However  Stop the App Madness , advocates libraries concentrate on their web app & forget about mobile apps. It points out that

1. You need to spend a lot more effort on creating mobile apps for each platform (iPhone, Android, Blackberry)

2. HTML5 will eventually allow web apps to be as functionally rich as any mobile app.

That said a study has shown that mobile apps, or at least iPhone apps are more usable than mobile friendly web apps. Part of the reason could be that mobile apps are usually faster since they can be designed to just draw data from servers, while everything else occurs locally.

It has also being suggested that mobile apps can do among other things , use the phone's camera, accelerometers and to be available offline which cannot be done via a web app. In the past location based services was available only on a mobile app but not web app, but with HTML5 now, this isn't true anymore. The other main reason it seems to me to use a mobile app rather than a web app is the former allows the use of push notifications , though this will probably change later .

As iPhone mobile apps are in the lead now, I will just look at that. I looked through my list of iPhone library apps and did further searching and came up with 25 mobile library apps. Similar to my earlier effort, with library web apps, I looked through them and tried to classify them by features offered.

The results are available in this public google docs

I've exclude library apps that are basically virtual tours (e.g. Library of Congress Virtual Tour, John Murray Archive , UPLA, ugl4eva, Denver Public Library Creating Communities,NC State Wolf walk), unofficial or other apps that are basically just mobile opacs that allow searching and placing of holds (e.g Library SG, San Francisco Public Library Mobile,
Ottawa (Canada) Libraries, Libraries: Australia, HongKong Libraries, UPLA, Bookzee, BookMyne, JapanLibrarian, Libraries Pollen etc) or Library archive apps (e.g SbekPH Baldwin, SbekPH UF Archives ), or limited library apps which a specific function such as blogs (iPLibrary) or Milli Kutuphane (which shows occupancy rates of reading rooms in National library of Turkey), ask-Wa (chat), OCLS Shake it! (Orange County Library System) which has a entertaining recommendation system. as the focus here is on mobile apps that are competitive with mobile web library apps.

Some analysis

A very popular option taken by libraries is to use Boopise to create mobile apps. A massive 16 out of 25 (64%)  library mobile apps were created using Boopise. Patrick Hochstenbach of UGent Library has blogged and presented on what it involves.

Currently only 10 out of 25 are apps for academic libraries so Public libraries are in the slight lead here

In contrast by my rough count out of 80 mobile web apps (list here), at least 60 out of 80 (or at least 75%) are for academic libraries!

If you do the math it means there are roughly

	Mobile app	Web app	Total
Academic Library	10	60	70
Public Library	15	20	35
Total	25 (24%)	80 (76%)	105

As you might expect given the ease of creating web apps, in total web apps dominate mobile apps making up 76% of the total (note some libraries have both). There are generally more academic libraries supporting mobile than Public libraries, but interestingly, of libraries supporting mobile, only 14% of academic libraries have a mobile app, 43% of public libraries do.

I wonder why there is this difference.

One possibility perhaps is as most academic libraries already have mobile web sites there is less need for mobile apps, though that doesn't explain why they went for mobile sites in the first place, while public libraries generally don't.

Then it hit me. I will explain this later.

Because Boopie apps makes up the majority (16 out of 25) in terms of layout of the app, they are all very similar compared to the variety of  library web apps. See below.





As you can see above, they are all in the same style, what I call the "row" style.

The other 9 library mobile apps (see below) are somewhat similar to most iphone apps with a row of options at the bottom. Compared to Boopie apps they tend to be simple with fewer functionalities with some exceptions. MabeeLibrary has a fairly full featured app. OPPL ilibrary has a particularly interesting function. It allows you to "Display your library account barcode for fast and easy check-out". If I'm not wrong this is the same function as CardStar (which I blogged about) , where instead of carrying your library car around, the barcode is saved on your iphone which you can use in-lieu of your library card.


None currently use what I call the "Grid" or "iphone" layout style which is increasingly popular in mobile web apps.

As you will see in the next section, the "Grid" style is actually quite popular with another class of mobile apps.

University wide mobile apps

University libraries have one additional complication that most public libraries do not as there exists university wide mobile apps. A quick scan of the iPhone apps store shows that there are hundreds of University wide mobile apps!

What I discovered was that most did not have a explicit option/menu for libraries. While it is likely that even without an explicit library option, some library related information is embedded say locations via maps, contact numbers, events & possibly videos & podcasts (if the library is part of a university wide initiative) it's unlikely that major library functions like catalogue is available.

In fact, even with libraries that had a separate library menu option, most simply link to the library mobile opac. There are exceptions. See below for 12 university mobile apps that embed a library option which contains more than just OPAC. This range from simple "contact" pages in the OPAC page (e.g. iStandford) to almost full blown options like those in Rice University (Fondren Library) and Loyola (Loyola University Chicago)

List is also available in google docs



Below are the 24 university mobile apps which have a explicit library option.



The most striking thing about these university mobile apps is that the majority are in the "grid" layout style. The reason for that is the majority of these university mobile app are actually "powered" by Blackboard.

There are in fact 2 University wide mobile apps using Boopsie, LoboMobile and Oxy Mobile (Occidental College) and these of course are not in a "grid" layout.

Incidentally the majority of university wide apps even those without library options are using BlackBoard. The next most popular option seems to be be by Straxis (23) which uses a row style, but so far I haven't seen any with a library option.



Some thoughts

The question is how does a library fit into a university wide mobile app?

If you are a university library and you go ahead to develop a full blown web app for your library. Then the university goes on to create a mobile app, do you build all your capabilities into the mobile app (is this easy if you already have mobile web app?) Or do you ask them to link out to your web app?

Worse yet.. if you build a university library app (say by Boopsie) , what happens if the university decides to later build a university wide app (say by Blackboard)? Then you would have two apps! For example case of this seems to have already occurred for the University of Vanderbilt and University of Toronto. Would it be better to have one mobile app? I don't know.

Hmm perhaps this explains why academic libraries are slow to build mobile apps, preferring to build web apps?


In the next post, I'm going to drill in further into specific features (are features such as landscape mode, GPS, mobile used?) and to compare the mobile app versus the library web app (if both are available), to see what differences there are between the two. Are libraries using them for different purposes?