ISSN 1940­5758Issue 23, 2014­01­17

The Road to Responsive: University of Toronto Libraries’ Journey toa New Library Catalogue Interface

With the recent surge in the mobile device market and an ever expanding patron base with increasingly divergent levels oftechnical ability, the University of Toronto Libraries embarked on the development of a new catalogue discovery layer to fitthe needs of its diverse users. The result: a mobile­friendly, flexible and intuitive web application that brings the full power ofa faceted library catalogue to users without compromising quality or performance, employing Responsive Web Designprinciples.

By Lisa Gayhart, Bilal Khalid, Gordon Belray

Figure 1. Sample Responsive Layouts (enlarge)

Introduction

With the recent surge in the mobile device market and an ever expanding patron base with increasingly divergent levels oftechnical ability, the University of Toronto Libraries embarked on the development of a new catalogue discovery layer inearly 2012. The goal: provide an app­like experience for our users through modern and familiar web design patterns thatis information­centric and brings our content to our users. The result: a mobile­friendly, flexible and intuitive webapplication that brings the full power of a faceted library catalogue to users without compromising quality or performance,employing Responsive Web Design (RWD) principles.

Responsive Web Design and Designing for the User Experience

“It is the pervading law of all things organic and inorganic, of all things physical and metaphysical, of allthings human and all things superhuman, of all true manifestations of the head, of the heart, of the soul, thatthe life is recognizable in its expression, that form ever follows function. This is the law.” [1]

The results of good design are barely noticed or considered, nor should they be. Design should be clear, intuitive, and

responsive, ultimately guided by the same laws of “form follows function” or as Don Norman of Apple would coin moreconcisely as “User Experience Design (UX).” [2]

Figure 2. UX Design Layers (enlarge)

For us, UX design is a non­linear multi­tiered approach to software development. We weren’t developing the cataloguefrom scratch: we leveraged our experience, knowledge, and history of users’ interactions of the existing catalogue (whichwe also developed) as a foundation for improvement. While a primary focus was making the catalogue responsive, aredesign also allowed us to enhance the overall user experience. The mobile first strategy as outlined by Luke Wroblewski[3], although compelling, wasn’t practical in our case as the majority of users (93% as of the writing of this paper and 2months into the launch of the RWD catalogue) come to us from a desktop environment.

Our design challenge: take the current desktop environment and scale it to mobile screens and everything in­between.

Stats and Specs

The University of Toronto Library catalogue is a collection of almost 7.5 million bibiographic records, 2.7 million authorityrecords, and 12 million item records. There are, on average, between 10,000­15,000 transactions per day (record updatesand item checkouts/renewals/returns) and the catalogue web application receives over 250,000 visitors per month,responsible for an average of 1.2 million pageviews.

A brief background of the web application and its various front­end and back­end components:

The front­end of the web application is written using the Freemarker template engine, with jQuery and CSS3 providingthe interaction and styling to the rendered HTML.

The back­end is comprised of Java objects and servlets organized in a Model­View­Controller pattern.

The primary data source for the catalogue is Endeca Enterprise Search and Index, which is accessed via theirproprietary Java API. Supplementary data is stored in MySQL and the interface for connectivity is the MyBatisPersistence Framework.

Data is processed into Endeca indexes (called “dgraphs”) via various shell and Python scripts, which pull the contentfrom the library system’s SirsiDynix Unicorn ILS. The SirsiDynix API and Oracle SQL queries are used to export datafrom the ILS.

Figure 3. Device usage tracked in Google Analytics. (enlarge)

Front­End Design

Continuity for users was an important consideration when redesigning the library catalogue. Web users in general tend toappreciate consistency and predictability: accordingly, we aimed to minimize any confusion from the switch to a newdesign, especially for long­time users of the service. As a result, the site experience has remained largely unchanged forthe desktop: the search box remains at the top of the page; search results retain a two­column layout (for facets and resultitems); and record details are contained in a dedicated space [4]. On smaller devices, the facets column is tucked awayinto an off­canvas layout that can be accessed via a button and the search results column expands to fill the width of thedevice. The layout is also “orientation­friendly,” meaning that any interactions in the portrait orientation are preserved inlandscape orientation.

Figure 4. Device Parameters and Media Query breakpoints. (enlarge)

RWD best practice recommends em based media queries to allow for user initiated zooming on browsers, so simply divideyour screen resolution by 16 to convert pixel widths to ems.

Device Testing

While developing, it was essential to test on as wide an array of devices and browsers as possible, matching the wide userbase we support. Beyond the standard desktop environments (e.g. various browsers in Windows, Mac OS and Linux), wealso tested on a variety of iOS, Android, Blackberry, and Windows Phone devices. Emulating real world situations meantour testing had to account for the latest smartphones (e.g. iPhone 5) as well as some of the older models (e.g. iPhone 3),and speeds ranging from LTE to 2g connections. For ease of layout development, we found a number of responsivebookmarklets and made good use of them, including the RWD Bookmarklet and ViewPort Resizer.

Our metrics indicate a need for continued support of older versions of Internet Explorer with approximately 8% of users stillusing IE8. Therefore our testing also expanded to these older browsers.

Figure 5. Search Results by device. (enlarge)

As a result of this testing, we made a number of CSS and JavaScript based enhancements within our code. We decided touse polyfills [5] to enable backwards compatibility: Respond.js allows older, non CSS3­compatible browsers to supportMedia Queries, which in turn uses the MatchMedia.js polyfill to execute media queries in JavaScript.

Looking back, deeper testing with our users would have exposed many issues we dealt with post­launch. Although weheld many sessions with users, they often listened and provided verbal feedback rather than performing hands on tasks. Inthe future, a more structured testing framework will be used to surface issues earlier in the development.

Three Component PagesThe catalogue interface is broken down into three main component pages: search results, record detail, and marked items.A landing search page exists but the majority of users come to the catalogue via the search engine on the library’s homepage.

The search results page offers faceted refinement, sorting and viewing options and less cluttered interface for catalogueitems.

Figure 6. Search Results component, desktop and mobile. (enlarge)

The detail page has a persistent “sticky” menu with options to jump to content and includes permitted uses, subject listings,enhanced data where it exists (summaries, reviews, table of contents, author information, etc.), and MARC view. Users cannavigate through their search results with previous/next buttons.

Figure 7. Record Detail View, desktop and mobile. (enlarge)

The marked record page contains items saved from the user’s session and has tools for emailing, importing into RefWorks,and exporting as CSV.

Figure 8. Marked Record View, tablet and mobile. (enlarge)

Figure 9. Off canvas layout for faceted searching. (enlarge)

An ongoing design challenge is determining an economy of content, making the most critical information highly visiblewhile hiding secondary content behind icons and detail pages. For example, we use a simple ‘in/out’ with red/greensignifiers [6] for item status, and the holding information has been re­ordered according to importance: status, library,location, and call number.

Figure 10. Holdings example. (enlarge)

Each item’s toolset is hidden and includes: detail view, request item, permanent link, RefWorks, cite, email, andMy.Library. A sharing icon accesses these options using jQuery and a hidden div.

Figure11. Individual record’s toolset on the search results page. (enlarge)

Economizing screen space is an integral part of designing for mobile devices. As some item titles are very long, a specialtruncation feature was implemented in JavaScript that trims long titles and paragraphs. A button becomes available to allthe user to view the full text when necessary. The snippetting occurs on page load and takes the viewport’s dimensionsinto account, meaning devices with larger screens that can comfortably display the content don’t trigger snippetting.

Figure 12. Title trimming option for long titles. (enlarge)

NavigationNavigation items across the search results and details screens are also responsive. Individual navigation actions arevisible on­screen when sufficient real­estate is available and collapse into dropdown menus otherwise. Similarly, coverjackets for records are responsive. No native responsive image solution currently exists for every web browser, so wehave made use of the picturefill.js library [7] to request images of different dimensions using a combination of MediaQueries and JavaScript.

Along with screen space considerations, we have also updated our interface to use more modern ways of navigation inthe now touch­friendly interface. For example, instead of a paging mechanism for search results, we have switched to lazy­loading results as the user scrolls to the bottom of the page. The ease of scrolling with touch devices makes this a morenatural experience than a full page reload. We have also introduced alternative layouts; there is a “text­only” displayoption available for search results along with the standard display, and a “tiled” display is scheduled to be released soon.

Figure 13. Full record and text only views. (enlarge)

HeadersSticky headers were implemented in both the search results and details screens, making it easier for users to jump tovarious parts of the page without requiring excessive scrolling.

Figure 14. Sticky header search results example. (enlarge)

In the previous iteration of the library catalogue, grouped records entries [8] were not as visible and our visitors oftenmissed important records. The search results page now indicates that items are “grouped” and there are two visualrepresentations indicating multiple items. Additionally, we developed the ability to ungroup records, the release of which ispending approval.

Figure 15.Grouped Records. (enlarge)

Icons and Book Jackets

Approximately 30% of catalogue items have publisher­provided covers. To create a more balanced row­item display forrecords without covers, we generate format icons through an in­house application that writes the record’s data ontocustom graphics. Format icons offer users a visual aesthetic and continuity similar to popular sites such as Amazon andprovide an immediate indication of what type of material is contained in the item record. We also offer a text only list ofsearch results, which was developed in response to several requests from librarians.

Figure 16. Examples of custom format icons. (enlarge)

Back­End Design

Improving search functionality, performance, and data­livenessAlong with developing a responsive front­end interface, we completely overhauled the application and servinginfrastructure with four goals: improved site performance; decreased page load time; high availability; and data currency.This work included restructuring the back­end web application, designing the server infrastructure for better performanceand redundancy, and overhauling the scripts that fetch the data from the ILS.

Application infrastructureDesigning the back­end to scale with user demand was a critical requirement. The library catalogue is one of the mostheavily used web applications at the University of Toronto. For example, over the month of October 2013 we averagedover 250,000 unique pageviews per week, resulting in over a million requests to the Endeca dgraph indexes per week.

The new architecture uses the open source HAProxy load balancer to process requests to both the web application andthe Endeca dgraph indexes. When an HTTP request arrives at http://search.library.utoronto.ca, HAProxy acts as a stickyload balancer in front of a cluster of virtualized web servers (currently seven) hosting the catalogue application. Each webserver in turn communicates with a cluster of dgraphs (currently three), using HAProxy to load balance the requests. Although normally powered by ten different servers, the entire application can run, if necessary, on only one web serverand one dgraph server.

Figure 17. Request – Response loop. (enlarge)

Running the application on multiple identical web servers not only improves performance under load but allows for addingmore front­end servers on demand during peak times, such as end of school term. The site uses several performanceenhancing techniques such as using Google’s mod_pagespeed Apache module to optimize and cache CSS andJavaScript files, an internal, heavily cached CDN for serving static content, and delivering cover images from a separateweb server to increase the number of simultaneous page element downloads.

Endeca dgraph performance is optimized by using servers with 128 GB of RAM to cache the entire index as well asmillions of queries, and by configuring the dgraph processes to make as efficient use as possible of multi­core CPUs. Wehave consistently achieved catalogue query result page load times of less than 2 seconds, very much in line with userexpectations of modern websites. [9]

Responsive Design, Responsive DataOne of the classic challenges in developing a catalogue that has been decoupled from the underlying ILS is ensuring thatthe data has been searched and delivered to users is current and accurate. Given that the catalogue data is stored inEndeca, and not directly being served from the ILS, we use a full and partial update model. A full update syncs the entireBibliographic, Item, Authority and Holding dataset from Unicorn to Endeca, whereas a partial update syncs data that hasbeen updated in a specific time interval. In our previous model, we used to handle Bibliographic and Item updatesseparately. For Bibliographic data: full updates once a week and partial updates once a day. For Items: full updates once aday, and partial updates every 20 minutes. This arrangement became fairly cumbersome and complex to maintain,especially since the partial updates didn’t capture all changes, and the full updates caused load issues on our Endeca

Index servers. In the new model, we have combined all of our various data sources (Bibliographic, Item, Authority etc),streamlined data retrieval into partial updates every 10 minutes, and more or less eliminated the need for full updates [10].Now, adds, deletes, and updates to all types of data is indexed and available to the web application within 10 minutes.

A Focus on Our UsersInformation Technology Services (ITS) at the University of Toronto Libraries is actively working towards improvingcommunications with our diverse user base of students, faculty, and staff. With a major change in service looming – thecomplete redesign of the library catalogue – we capitalized on the opportunity to manage this change with a structuredcommunications plan. The plan focused on increasing project and staff visibility, obtaining and incorporating userfeedback, and preparing users for the pending change in service. The communications plan detailed key messages, goalsand objectives, target audiences, available communications channels, stakeholders, budget, collateral to be created, andkey performance indicators. A timeline with specific deadlines was attached.

The catalogue team worked consistently to increase visibility of the project and its staff members. The low levels ofcommunication around past projects in ITS were acknowledged and the team committed to transparency around thedevelopment of the new library catalogue. Messaging around project status, opportunities for feedback, upcoming events,and next steps were disseminated in a consistent manner through a variety of communications channels [see Appendix].Internal communications were also increased to ensure that departmental staff were also aware of the project andtimelines.

AccessibilityUTL is committed to providing all users with equitable access to University of Toronto Libraries’ digital spaces, such as thelibrary catalogue, central libraries’ websites, and digital collections. We strive to ensure our web spaces conform to LevelAA standards, as per WCAG 2.0 and AODA (Accessibility for Ontarians with Disabilities Act) standards and timelines. Thiswork includes making sites compatible with assistive technologies, such as screen readers, as well as ensuring content isclear and understandable to a wide variety of users.

The catalogue team received training on developing with accessibility in mind, including attending the University ofGuelph’s Accessibility Conference in May 2013. Additionally, we were in contact with the University of Toronto’saccessibility office for advice on outreach and testing; reached out to resources at Scholars’ Portal and OCUL; andparticipated in the development of the Accessible Content E­Portal (ACE) Pilot Project. This information gathering andtraining allowed our team to run in­person and online usability tests with users with vision impairments and circulate abeta site link to contacts who represented users with disabilities.

The team worked with our Web Coordinator Librarian, who leads accessibility work for the library, to test the site at variousstages of development and provide recommendations for changes. Tools used for testing included Colour ContrastChecker, WAVE, JAWS, ChromeVox, and HTML_CodeSniffer. As users spend more time with the catalogue, we continueto gather feedback and subsequently improve accessibility features.

Managing ChangeManaging the impending change in service required targeted communications to users who were identified as highlyaffected by the change: faculty, librarians, and library staff. Since the catalogue was scheduled to transition at thebeginning of the fall semester (late August 2013), these users required appropriate lead time to get acquainted with thenew design and update teaching materials, LibGuides, and help videos. Demonstrations, feedback sessions, and trainingopportunities worked to give these users the tools they needed to prepare. Reaching the majority of these users was adifficult process: many were away during the summer months and not present to receive our attempts at outreach. In thefuture, it would be useful to avoid the summer months when communicating with these specific groups.

Promotion and FeedbackOpening and maintaining a two­way dialogue between the project team and our users was integral to the communicationseffort. Users were encouraged to submit comments and questions throughout the entire project and this message wasincluded in all outgoing communications. Feedback was received in many ways: dedicated project email address, onlinefeedback form embedded in the catalogue, paper comment forms, usability testing, focus groups, and throughconversation with project staff (verbal comments and meeting discussion notes were entered manually into our tracking

system).

To help users transition to the new library catalogue and encourage users to submit feedback, a link to the beta site wasdistributed early in the development of the new interface. The beta site ran publically for three months with online feedbackopen for the duration. The beta site was released in phases: first to early adopters identified by project staff, secondly todepartments who work closely with ITS, and finally to all users.

In­person events, such as drop in feedback sessions gave users an opportunity to meet the project’s staff members andengage in discussion. These events also worked to give a “face” to the project, make personal connections, and create avenue for impromptu brainstorming with users.

All feedback was managed through JIRA, an issue tracking and management web application. Using JIRA allowed us tocreate tickets for all feedback items, manage conversations, save users’ contact information, and export data for analysis.A central system also promoted better prioritization and planning within the team itself. All solicited feedback was reviewedand incorporated into the development of the catalogue at various stages, where applicable. Changes were thencommunicated back to users.

The launch day of the new library catalogue was also widely promoted. Staff were available to support users via phoneand email. Help pages and documentation were limited and users requested more detailed information. New pages arebeing developed and include video tutorials, created in coordination with Reference Services, to provide visual instructionon various catalogue features and functions. These videos will be repurposed and used to improve awareness of theRWD catalogue through the main library website, digital signage, and posters.

Overall, the targeted and consistent communications around this large change was well received. A short survey of staffmembers indicate that they were well aware of the project, were kept apprised of timelines, and felt that the project waswell communicated. Anecdotal evidence from library users suggests that most people were aware of the change in serviceand were prepared to make the transition. Based on this success, this approach to communications planning will be usedas a model for deploying new products in the future.

Future Directions

We plan on migrating a few remaining features from the previous iteration of the catalogue interface to the current one,such as virtual shelf browse, item location maps, and print on demand. Long term plans include developing anauthentication layer that would allow integration with other library services such as usage history, loan information,persistent marked records, item recommendations, and more. We would also like to facilitate interaction with social mediaby way of adding sharing options, as well as improving search engine optimization by introducing linked data into thecatalogue.

Although the catalogue has been launched to our users, the project continues to evolve and grow. We continue to receivefeedback from our users and make improvements and changes based on these suggestions. As always, we look forwardto discussion with the Code4Lib community through the Journal, Listserv, and in­person events.

References and Notes

[1] Sullivan, Louis H. (1896). “The Tall Office Building Artistically Considered”. Lippincott’s Magazine (March 1896): 403–409. Accessible via Internet Archive: https://archive.org/details/tallofficebuildi00sull.

[2] “I invented the term because I thought Human Interface and usability were too narrow: I wanted to cover all aspects ofthe person’s experience with a system, including industrial design, graphics, the interface, the physical interaction, and themanual.” http://uxdesign.com/ux­defined

[3] http://www.lukew.com/ff/entry.asp?933

[4] One key difference with record details: in our previous iteration the details loaded in a popup window atop the searchresults. We have now dedicated a full page to record details to give the content more breathing room.

[5] Polyfills are JavaScript libraries that emulate modern CSS3 and native browser functionality for older browsers.

[6] Replaces ‘in/N/A.’ The red/green with white text has a AAA accessibility pass for colour contrast and offers a text

alternative for users with difficulties discerning colour

[7] https://github.com/scottjehl/picturefill

[8] Grouped records employ an approximation of FRBR (Functional Requirements for Bibliographic Records), a modeldeveloped by IFLA which allows users to define relationships between the entities (eg. books) that provide links tonavigate through the relationships, creating new search paths

[9] See: http://www.webpagetest.org/result/131115_WQ_T73/

[10] Unless required for application changes or bug­fixes.

Appendix: Communications Channels

A summary of outreach and communications channels used:

Hosted in­person demonstrations and feedback sessions

Visited the Scarborough and Mississauga campuses for in­person events

Facilitated focus groups with staff and students

Performed individual usability tests

Created a dedicated email account for direct feedback

Distributed consistent staff email updates

Updated staff at University committee meetings

Updated at staff meetings in various library departments

Deployed digital signage in various library buildings

Distributed multiple news items in the University of Toronto Bulletin (an all­staff and alumni bi­monthly e­newsletter)

Included articles in departmental newsletters targeting faculty and students

Contacted faculty and departments through faculty liaison librarians

Created and distributed a new library catalogue brochure

Used the active social media accounts at all three campuses and the central University of Toronto accounts

Distributed messages to the Code4Lib Listserv asking for feedback and announcing the product launch

Created and distributed news items and website banner images (featured on the main library website and twocampus websites)

Created a project­specific webpage detailing the project’s purpose, progress, and next steps

Distributed rolling messaging via social media accounts and enews with Student Life (undergraduate focus),Graduate Student Union, the iSchool, and the Faculty of Arts & Science

Performed outreach to librarians and library staff with teaching duties to assist in updating instructional videos andonline Q/A

Created an online help page explaining new functions and icons

Participated in various professional activities, such as conference presentations, poster sessions, and articles

About the Authors

This work is licensed under a Creative Commons Attribution 3.0 United States License.

Lisa Gayhart is the Digital Communications Services Librarian in Information Technology Services at the University ofToronto Libraries. As the dedicated communications team member in ITS, her number one priority is to move library ITfrom the sidelines to the spotlight through structured and actionable communications.

Bilal Khalid is a Senior Application Developer at University of Toronto Libraries. He is responsible for the coredevelopment for the library catalogue, as well as other web development projects at the library. His interests include:emerging web technology trends, cross­platform development, and improving software development workflows.

Gordon Belray is an Information Architect at University of Toronto Libraries who specializes in User Experience (UX)design and server application development (FADIS and MyMedia). His current focus is on Responsive Web Design(RWD) and accessible design. He is a graduate of the Department of Art, University of Toronto.

Acknowledgement

This article expands upon “Your Library, Anywhere: A Responsive Library Catalogue at University of Toronto Libraries” aspublished in the Winter 2014 20(1) issue of OLA Access.

Subscribe to comments: For this article | For all articles