ACRL 2011: Mobile Websites

Another big topic at the ACRL Conference, and one in which I was particularly interested, was mobile websites. This is something we are working toward at my library.

I attended several presentations on this topic:

1. Mobilize Your Library: Creating a Mobile Website. Presenter: Micheal DeMars, California State University-Fullerton
2. The Library's Swiss-Army Knife: Using Smart Phones for Information Discovery, Content Delivery, and Inventory Management. Presenters: Stacy Brinkman, Jason Paul Michel, Jim Clarke, and Bo Brinkman; Miami University

From these presentations, I learned:

1. There are a few options for making library information available on mobile phones: create a mobile website, build an app, or a combination. Both of these institutions chose to create a mobile website - because it's easier, updating the code is simpler, and it's accessible on most devices.
2. If you use Google Analytics, it will show you how many mobile visits your website is getting, as well as which platforms (Android/iPhone/etc) people are using. One library focused on making a mobile website that worked well on Android and iPhone because that's how the vast majority of their users were accessing their site. For us, the iPad, iPhone, and Android appear to be the most important.
   
3. For a list of libraries with mobile websites, visit the Library Success wiki's M-Libraries list.
4. For best practices, see W3C: The Web and Mobile Devices, Apple iPhone Standards (presumably that's somewhere on this site, but I'm mostly seeing info specific to creating apps - maybe that's all they have?), Smashing Magazine, and Android Best Practices (see the list on the left for a section containing best practices).
5. Both libraries only included stuff that had been optimized for mobile devices.
   
6. Categories: Research/Search, Events, People, Help, social media icons (Facebook, Twitter, library blog), Hours, Ask Us (Texting), Computer Availability, Video Tutorials, etc. The two libraries varied on what they called things, but both included social media.
   
7. One library uses automatic detection to send phone users to the mobile site, the other has a mobile URL that they publicize. The one that uses automatic detection includes a link to the regular full site, but mentioned that it was hard to override the automatic detection mechanism.
8. Databases with mobile versions: EBSCOhost, JSTOR (beta), ARTSTOR, WorldCat.
   

Also, while Google-ing around for other stuff, I stumbled across iLibrarian: 7 Tools to Create a Mobile Library Website (without Technical Knowledge!).

Currently, we have enabled EBSCO's mobile site, we're about to start using Innovative Interfaces' AirPAC, and we are starting to plan out what all to include in a mobile site.

Redoing a library website

For many years, my library has been maintaining a number of websites with various degrees of success. IT recently redid the public university website, but before they did so there was an extensive library website available on it. We hardly ever touched it. It was viewed as mostly information for potential students, and there were no live links to databases and other resources. Thus, some of the information available on this site was rather out of date and perhaps even inaccurate.

As a second website, I maintain our subject guides via an external wiki. I update these quite frequently. This is the only site that we have the ability to update at present.

Finally, the main library website is located behind an intranet. This has been a source of frustration for a number of reasons. We are constrained within the restrictive parameters of a content management system. I recognize that most universities use content management systems for their websites, but the one used for our intranet has been particularly difficult in the past. To be fair to IT, I think it isn't quite as restrictive as it seems. However, we currently do not have the ability to make modifications on our own. This then means we have to bug IT every time we add a new database, remove one, need to update a description, etc. This would certainly become a lot of work for IT if we wanted to get much fancier with our design. A final source of frustration with the intranet is that we cannot link anyone directly to a page within it. They will just be bumped out to the main login screen. Once they login, they are taken to the first page as usual, instead of the one you hoped to link them to. This results in a lot of "click on blank, then blank, then blank" ad nauseum.

Thus, we decided it was high time to redo the website in such a way that we will have control over updating the content. We also want to have only one main library website to update instead of two. And, of course, we want a website on the public side of things so that we can link users directly to the information they need. After going through the proper channels and obtaining permission, we were able to start working towards a website that meets all these requirements. The subject guides will continue in their present form.

In order to make a website that will be helpful to everyone, we are doing a variety of testing. Thus far, we have conducted several focus groups (to be discussed further in a future post). We hope to do individual usability testing soon on the prototype of the new site. If usability testing reveals a variety of problems, we'll resort to other techniques, such as card sort.

I hope to continue posting as we move through this process. I am also very hopeful that all this testing will result in a highly user-friendly website for our patrons.