UAA/APU Consortium Library
I’m doing a presentation with my colleague Judy Green called “Search Engine Secrets and the Information Bubble” at the Pacific Northwest Library Association Conference which is in Anchorage this year. My part of the presentation is about how to escape the bubble.
We have a funny problem with WorldCat.org and at our library. When you are in the library or on campus and search Worldcat, our library appears to be 257 miles away when trying to find copies in a library nearby. It works fine if you are off campus somewhere else in town. So what gives? OCLC is looking a the IP address of the browser and doing a lookup to determine zip code location. Unfortunately, the lookup for our IP addresses on campus thinks we are in Fairbanks because that is where the statewide university system connects to the broader Internet.
We reported this to OCLC 3 years ago when we first noticed it. They had no way to specify or customize how IP addresses were associated with zip codes since they used an unspecified external service for their geo mapping. They offered that when WorldCat Local came it might be fixed. Turns out that’s not true. A couple of months ago we came up with a work around, not sure why it took so long for us to think of it. When we link to WorldCat on our website, we include the Ezproxy prefix so the site is included in the proxy server. We’ve configured the proxy server to automatically authenticate users on campus so they don’t have to login but to continue proxying the WorldCat website. Since Ezproxy is a URL rewriting proxy, we then use a search and replace command to insert the correct zip code:
Title Consortium Library WorldCat Local
URL http://consortiumlibrary.worldcat.org
DJ worldcat.org
Find &referer=
Replace &loc=99508&referer=
It’s not perfect. It only works when users access WorldCat from the library website. If users on campus go directly to WorldCat or end up there from GoogleBooks they will have a Fairbanks zip code. Since OCLC seems unable to offer a real fix, my colleague had the clever idea of contacting geo IP services and getting them to correct the zip code for our IP ranges. Maybe we will get lucky and fix the one that OCLC uses.
Last week we debuted a mobile version of the library website using the techniques we developed for the mobile library catalog. We automatically redirect to the mobile site for a selection of mobile browsers (iPhone/iTouch, Android, Palm WebOS, Blackberry, Mobile Opera, Mobile Firefox, and Symbian s60) that covers a broad segment of the smartphone and high-end feature phones. In addition, we have a link to the mobile site on the front page so users of mobile browsers we may have missed can make their own choice. Also, low bandwidth users might prefer the mobile site.
The mobile home page is laid out with a set of icons to selected resources on the library website with an emphasis on those that might be more useful for mobile users. However, we took a different approach than some web developers which only make a selection of pages available via the mobile version. Instead we make every page on the main website available in the mobile version. Mobile users also have the ability to toggle to the full website if needed.
Another nice feature is that we link to the mobile version of library resources when possible. For example, we link to the mobile version of the Ebsco databases like Academic Search Premier. We will keep our eye on other vendors and link to their mobile versions when they become available.
Finally, the work we did to make a mobile version of the website allowed us to easily add a text version for screen readers and non-graphical browsers. We had text version before but only for the home page, now the entire website is available in a text version. A link to the text version displays at the top of the page for screen readers and non-graphical browsers but is hidden from regular web browsers.
We just debuted a mobile version of our library catalog optimized for display on the iPhone. Our library system vendor is working on an iPhone application which we are investigating. But developing html pages optimized for a mobile browser has a number of advantages over a dedicated application:
Our library catalog runs on SirsiDynix Web2 (not to be confused with Web 2.0) but the customization could probably be made to most web-based catalogs. We borrowed design ideas from the great folks at NCSU Libraries. They’ve done some great work on providing library content to mobile devices. Thanks guys!
It’s interesting to see all the positive articles and blog posts about Drupal and libraries. Three years ago, we were looking for a solution to provide an intranet portal for our library and choose Drupal for several reasons–LAMP, free, strong community, flexible, etc. We setup a portal for library staff, offered training on content creation, and made many customizations, including an extensive taxonomy of categories to control access based on group membership. We even migrated the content of our main public website into Drupal as a first step to providing a “MyLibrary” level of personalization.
Then we started to have second thoughts. Performance on the web server plummeted because of Drupal’s inefficiency. We had to turn on caching for the public website, compress css and javascript files, move MySQL to another server, and finally upgrade to a new server. In addition, library staff were avoiding the intranet portal, primarily because the extensive taxonomy made finding and creating content difficult . As the new system administrator (my colleague who set up and customized our Drupal installation had left for another job), I was having a hard time maintaining updates for the numerous Drupal modules and core. Trying to change customizations was difficult. It was a very steep learning curve.
A year ago, we surveyed library staff about communication methods within the library, with some focus on Drupal as the intranet portal. We identified what worked (incident reports, pre-authenticated links to other web applications, rss feeds) and what did not (finding content, creating content). In addition, we identified several areas where the intranet portal competed with more traditional forms of information sharing in the organization–mailing lists for discussion and network drives for sharing files. People were unsure what was the most appropriate venue for a given piece of information.
We also identified a need for some library staff to have a public web presence (their “own” space) as well as a more flexible way to create path finders or research guides. The thought of try to get our Drupal installation to do this was daunting. So instead, we began adopting “best-of-bred” solutions–WordPressMU for individual or group websites and LibGuides for research guides. Library staff adoption of WordPressMU and LibGuides has been relatively painless, sometimes even bordering on enthusiastic.
In addition, we migrated the main public website to MODx, a very flexible CMS/CMF that allows considerable freedom in terms of design and functionality with an easy to use in-line editor for library staff. We plan to move several ancillary websites into MODx during the coming year.
So where does that leave us with Drupal and our library intranet? For many months I had been convinced that we had to abandoned Drupal and migrate to another platform–(Sharepoint, Liferay Social Office, Elgg, OpenGoo…). But along came Open Atrium, an “intranet-in-a-box” based on Drupal. Open Atrium provides workspaces which are places for teams to collaborate. This “sense of place” was a major element missing from our Drupal intranet portal.
We are in the process of upgrading our intranet to Open Atrium, moving content into separate workspaces. We will start with very basic features and then add enhancements. In addition, we will be using Drush, powerful command line tool, to manage the underlying Drupal installation. I can’t believe we are sticking with Drupal for now. The ultimate goal is a tool that improves communication and information sharing within the library. We’ll see how it goes.
