Library Technology Committee Meeting Agenda
Wednesday, 4/20/2011
Topic: LibAnywhere Mobile Catalog / Mobile Access to the Library

green: action items
purple: followups from after meeting

1. What LibAnywhere does.

a. Summary:
· Allows users to search the library catalog with a mobile friendly interface.
· Displays availability as well as holdings information
· Can be the basis for an entire mobile site if we choose
· Features iPhone and Android apps for frequent library users

      • App would be good for frequent library users.
      • Website would be good for infrequent users.

b. Workflows for people accessing the library site and catalog from mobile devices using LibAnywhere. (See attached document.)

      • Option where things stay on Luwak except for catalog is the good one.
        • We don't want to update hours, etc. in more than one place.
      • Wm: what problem are we solving? Are we losing customers because of it?
        • K: better catalog interface for web users. If they try the catalog from a mobile device and it's a pain, they may not try it again.

c. Pricing: $1000 yearly subscription
For comparison, we have a two-year old quote for AirPAC (our catalog software’s mobile catalog module):

      • K: Are we giving people $1000 worth of a better catalog searching experience with this product?
      • Wm: $1000 is cheap.

2. Authentication issues from mobile devices (through LibAnywhere and generally).

a. George has expressed concerns about the patron authentication functions of LibAnywhere, so these functions have been disabled in the RPI LibAnywhere instance. (Patron authentication would allow patrons to place holds on items and access their patron record.) Are the concerns associated with (1) LibAnywhere specifically or (2) handing off RCS authentication to 3rd party sites in general?

      • Geo. has a general concern about passing RCS authentication . Anytime we're looking at passing RCS info to an outside party, John Fisher needs to be involved. Particularly, LibAnywhere uses HTTP instead of HTTPS, which makes it an automatic no-go.
        • Matt said he thinks they can do HTTPS, but he hadn't pursued it after we had initially shut down the authentication stuff. Is it possible that we might be able to get this approved? Fischer would need to talk to LibAnywhere. Wm. is pretty sure he wouldn't approve it - it's not a major contract.
        • We will not pursue the options in LibAnywhere that require authentication.

b. Also, are people able to authenticate to library services (patron record or proxy server) through mobile devices at all?

Katie could not accomplish either of these tasks using an Android phone:
· Link to any database that requires authentication from http://www.lib.rpi.edu/html/ml/alpha/all.html
· Access patron info from here: https://opac.lib.rpi.edu/patroninfo

In both cases, Katie got a web page not available" page ("The web page at https://opac.lib.rpi.edu/patroninfo (or proxied database url in that case) might be temporarily down or it may have moved permanently to a new web address") with a popup: "Data connectivity problem: The server failed to communicate. Try again later." Matt had similar results with an iPod Touch.

Katie was able to authenticate to ILLiad using an Android, though.

Are these authentication problems general to all mobile devices? Do we want people to be able to authenticate to the catalog and the proxy server from mobile devices? If so, how to proceed?

      • George couldn't do it either, until he downloaded Opera Mini (different browser). Alan Powell (in VCC) tried it with his newer Android, and was able to authenticate with no problem. Alan looked into it, he says that Google hasn't figured out a good way to update OS on Android, and browser on Androids is integral with the OS.
        • George reported after the meeting (4/21):
          "My phone had and completed an OS upgrade this morning (from Android 2.1 to 2.2.2 I believe.) I tested opac.lib.rpi.edu/login and libproxy.rpi.edu/menu and both logged in with no problems using the Android native browser. These had failed using the 2.1 native browser. Alan was on the money with this one." "I didn’t ask for the upgrade today – my phone alerted me that it was available, did I wish to complete it."
      • So, the answer is "buy a new phone". We can't guarantee a good mobile experience on any particular platform.
      • Tammy: do we have a sense of patrons' desire to get into these things?
        • We should look at the stats again (Google Analytics): what browsers (mobile/non) are people using to access the website, and where do they go? Has this changed much since last time we looked at this? Matt will find these and report back to the group.
          • Matt's email to group:
            • Things to note:Here are some Analytics reports on mobile usage for the past week and for the same week a year ago. I also have attached a report showing the percentage of change for each mobile device and the change in the overall share of total mobile usage for each device. Android use shot up 519%, from 21 visits this week a year ago to 130 this past week. iPad rose dramatically too, but I don't consider it a mobile device, not sure why Analytics does. Android also increased its overall share to the point where Android usage takes a bigger piece of the pie than iPhone and iPod combined.
          • Katie noted: I also noticed that visits from mobile devices from this past month are .78% of the site’s total visits, as opposed to .14% a year ago. Still a small percentage, but growing.
      • Geo: as phones develop, there will be less of a need for separate mobile website. the phones are handling the regular websites better.
      • Tammy tells about importance of getting to all the content, even if the website is crappy. She wants the hockey scores and she will stop at nothing to get them.
        • We looked at how to get to the rest of the website in both workflows. (Not just the hours, locations, contact, etc. that shows up at front page.)
      • Wm: wishes he could find location of books, location of rooms.
        • Tammy: would be helpful to find out where sections of stacks are.

3. Where do we go from here? Do we want to make a purchase recommendation at this time? If we're not ready, what additional information do we need to decide whether or not to recommend purchase? Are there any issues that need to be resolved?

      • Is it giving users $1000 of a better experience in searching the catalog?
        • Wm: $1000 seems cheap.
        • Tammy: do we want to take some steps ahead of this? Collect some stats?
          • We can collect previous stats in LibAnywhere. We should definitely look at how LibAnywhere or a promotional campaign affects mobile use of the catalog and website.
        • If we start some services like this, should we promote them?
          • Wm: QR code campaign might be a good way to tell how many people actually know what a QR code is / are savvy mobile users. - send people to a site, count them, redirect. Be mysterious with the QR code posters. We could put more explanatory information on the library's website, though.
      • Committee agrees to recommend it to Bob.We would like to review this product in a year, taking usage statistics into account.
        • Katie and Matt will make recommendation to Bob.
          • Bob approved spending the $1000 to subscribe to LibAnywhere for a year. Bob and Matt will talk to Kathy about making the payment.
      • Wm recommends changing over detection of browser and transformation to XSLT on the server side (instead of Javascript, which makes the user's device transform content) Matt will talk to Arlen about this.

LibAnyWhere URLS
The URL for the iphone/ipod version is:
The URL for other devices is:
In addition there is an iPhone/iPod app:
and an Android app:
Auctions online
Shopping Online