SUBSCRIBE NOW!

Vol. 31 No. 2 — March 2011

Virtual Spaces—The Current Situation

Prior to the evolution of Web 2.0, the web was used primarily as a place to retrieve information or accomplish specific tasks. Over the past few years, websites have evolved from being basic information portals into virtual spaces that are places to hang out, to discover, and to socialize. Libraries have struggled to implement the characteristics of online spaces that we have become accustomed to through our interactions with Google, Facebook, and Twitter. These characteristics have become core elements of the online architecture that libraries want to incorporate into their virtual space.

One of the reasons that libraries are lagging behind in their virtual spaces is that librarians are not in control of these spaces in the same way that they are with their physical spaces. For example, librarians and staff are able to arrange floor plans, relocate collections, and update a building’s aesthetics to best meet the needs of their customers. But when was the last time you moved your search box, added a link to share, or integrated social content into your catalog?

Several factors are at play here. For the most part, libraries have managed to maintain a web presence on their own, but tight budgets have generated a market for companies to create and manage library catalogs. These companies have responded by offering products that are far more advanced than most libraries could afford to develop on their own. They provide catalogs within a range of qualities and costs. Because libraries cannot afford to pay for custom catalogs, one or two solutions are provided for all customers. Homogenization occurs as a handful of industry leaders are privileged with the task of shaping the virtual spaces of libraries across the country.

So, libraries do not have a single virtual space that represents their collections and services—instead, they have linked multiple disparate spaces. With one virtual space for the library, another for the catalog, yet others for databases, ebooks, and readers’ advisory services (just to name a few), the virtual library sends customers bouncing around from place to place. This approach is fundamentally disconnected from recent innovations that engage visitors in today’s online world.

Is it then possible for the library to incorporate elements of modern online architecture that would encourage a greater sense of community when visiting the virtual library? Can libraries begin to shape their virtual spaces, amalgamate numerous online spaces, and create a unique virtual library space for their communities? At both MacEwan and YRL, there is a strong belief that overcoming these challenges is within our means. There is a willingness to take risks, and librarians are encouraged to experiment with new technologies that can make these things possible.

Open Data Initiatives

To achieve the kind of end-user experience that librarians want to offer, libraries need access to data from the providers they contract with for services such as the integrated library system, library databases, and user reviews. The companies that supply these services should open closed systems and encourage library lead development of virtual spaces that incorporate all of the services libraries offer online.

The key to success when designing a virtual discovery space is having access to the data on the ILS server. At the most basic technical level, a discovery system is designed to communicate with the ILS through an application programming interface (API), which acts as a translator by securely sending and receiving data between the ILS and the discovery platform. Depending on the API, this may or may not be a straightforward process. A well-constructed API will be granular, meaning that it can return and request very specific results. An inefficient API design will return more data than may be needed, which will increase the time it takes the discovery system to process and present the data into information that is displayed to the end user.

The ILS at YRL is developed by Polaris Library Systems. It is built on Microsoft SQL Server, and its database schema is open to system administrators. The result is barrier-free access to the ILS data. Making access even easier is the availability of a Polaris API, which has streamlined the process of accessing all of the functions of the catalog. Access to the library’s ILS via an API means that with access to the appropriate skill set, a library can shape a catalog by strategically organizing functions and data in ways that the library deems most appropriate for its community.

The Power of Analytics

With access to the Polaris API, YRL had the tools to redefine the library’s virtual space. Before this could begin, an analysis of how the current catalog was being used was required to identify which services had been successful. Many catalogs are rich with features, but how many of these features are being used? How much of that functionality has been discovered by the end user? An analysis of these questions was used to steer the development of the new discovery system.

Focus groups are one way of learning how a catalog is used, but this can be a costly and time-consuming process. Website analytics are an accurate and expedient method of identifying current successes and failures. Many libraries use server logs or web analytics tools to track usage patterns on their websites. Tracking these same metrics on the library catalog is far less common because in many cases it is simply not possible to link an external analytics engine to the library catalog. Fortunately, the Polaris catalog system administrator settings enable libraries to link external analytics providers. As a result, YRL began tracking usage metrics with Google Analytics shortly after its launch in early 2009. Therefore, ample data were available to assist in making decisions about features to include in a new discovery platform.

The analytics from the catalog identified three main trends. First, the basic search feature was used for approximately 96% of all searches, while the advanced search features were used for the remaining 4% of total searches. Second, patron account features were very popular. Third, all of the remaining functions of the catalog not related to searching or the patron account were rarely used. These trends were established early on and continued with only slight variations in the months following the launch of the catalog.

This analysis proved the relative simplicity of the catalog. This is not to say that library catalogs are simply conceived and designed, but rather that the end user’s activity is limited in relation to the functionality set that is available to him or her. Why is it that so many catalog features are not used? Perhaps the answer lies in the design of library catalogs. Most catalogs are simply not intuitive, and their architecture has not evolved to reflect recent online innovations.

The ‘Heavy Lifting’ Begins

Access to catalog analytics and the Polaris API meant that YRL had the tools to begin planning a discovery platform design. Data from Google Analytics identified the need for the library to offer end users a convenient way to visit the library using mobile platforms. Using Google Analytics to observe the kinds of browsers and operating systems that end users preferred, librarians decided to begin by designing a platform for the iPad. The decision to begin development of a discovery system for a mobile device meant that the library would be committing to an area that was quickly growing but did not yet have the massive usership of the library catalog. Working in an area that was not yet established to be a core library service meant that there would be more room to experiment and less pressure to conform to traditional standards.

Depending on the resources available to any given library, developing a discovery interface can be accomplished in several ways. The ability to use the ILS API is key, and accessing this is the first and most important step. Beyond access to an API, a library with skilled developers and design professionals on staff can begin work immediately. In-house development has the potential to yield excellent results that reflect changes based on what has and hasn’t worked well to date. In-house development also means that librarians are working closely with or alongside developers to shape the final result. Analytical data will clearly determine what shaping is needed, but observations and experiences from librarians and staff will also inform the process.

Not all libraries can employ developers in-house. Outsourcing the development to professionals is a viable solution that is often cheaper and faster than developing in-house. The drawback to this method is that an outsourced agency will require definitive start and end dates to any project, thus leaving less opportunity for the post-live evolution of the interface that is required to make improvements based on how end users interact with it. On the upside, outsourcing will ensure that professionals with a diverse skill set—professionals including graphic designers, engineers, and developers—are committed to the project from start to finish.

Discovery on the iPad. YRL’s first attempt at creating a discovery platform resulted in an application for the iPad that integrated content from five separate providers into a single, engaging, and easy-to-use interface. A simplified search and discovery interface embeds cover art and user reviews and integrates a readers’ advisory service and location-aware maps to identify branch locations. Cover art is retrieved from Syndetics, and user reviews originate with ChiliFresh.com. The similar titles readers’ advisory feature is driven by EBSCO’s NoveList database. Maps are integrated from Google and are combined with location awareness capabilities of Apple’s iOS software. All five services are accessed using separate APIs.

The project was completed and publicly released on May 28, 2010. The platform as a whole and the extension of the library to operate efficiently and conveniently on mobile devices was very well received. One of the most notable successes for libraries in the consortium was seeing an increase in holds placed by boys aged 12–15. This change was attributed through observation to be a direct result of the new discovery platform and its extension to nontraditional channels including the iPad and iPhone (a streamlined version for iPhone and iPod touch was also released). Due to the overwhelming success of the project, plans to integrate content from other external services such as Project Gutenberg and electronic media from OverDrive, Inc. are currently underway.

Music discovery. At MacEwan, plans for a discovery platform that is built on similar foundations as YRL’s iPad app are currently in progress. Students currently enrolled in MacEwan’s music programs have access to thousands of sound recordings and scores through the MacEwan Library, but these materials are not convenient to locate using the library catalog. According to the findings of a needs assessment of library services to music students and faculty, those who use the collections most often find materials by physically browsing in the library instead of using the catalog. The library finds itself competing with the conveniences of online music services and illegal downloading of music because the library is not available to its end users online in the convenient ways that students and faculty have come to expect.

To respond to these expectations, MacEwan Library plans to develop a discovery interface that draws on metadata from external services including www.allmusic.com and Gracenote to enhance the virtual presentation of music materials. The interface will incorporate architectural elements found in popular music spaces online and will take the format of an iPhone app and a Mac app. The iPhone app will appeal to the larger student body, and the Mac app will serve as an enhanced version for “power users” such as music students who have a MacBook requirement in their programs. It is expected that this interface will serve as a model for future projects that will improve virtual discovery of all library materials.

Compatibility Concerns

Many libraries are concerned with taking on projects of this magnitude because of the staff or skills resources required to support them. These concerns are well-founded, especially when it comes to web-related projects that see high volumes of traffic and need to be compatible with several browsers and operating systems. On the other hand, apps are built on a simple principle that does not fail as easily as we might expect. The reason for this is that apps are designed to run locally on a specific device and operating system, thus eliminating many compatibility issues. This is especially true with Apple devices, where the number of operating system versions is limited to only two. Apple developers get plenty of advance notice about upgrades and version control that is easy to manage using iTunes Connect. Apple takes care of deploying the apps to end users through the App Store. Apple also employs a team to evaluate every app submission, which ensures that all software requirements and human interface guidelines are met. Developers tend to dislike Apple’s stringent submission guidelines, but as an end user of the app, or as someone responsible for projects of this nature in a library, these quality control measures are a second insurance policy that guarantees an excellent final product.

Conclusion