Category: Catalog design

Interactions: requests

This article is going to focus on interactions that occur outside of My Account, although they all have interactions there as well that will be discussed later.

Standard requests
Requesting titles is one of the top actions (searching, renewing, and requesting), and over the years features had been added to the previous catalog at different times. This catalog allowed us to consolidate those features into a better user interface. Requesting is primarily done on the search results page, then the record display page and from a person’s My List list.

Requesting screenshot

The most common feature offered when placing a request is to select the pick up location (defaulted to their preferred pick up location). Some highly uncommon features that we added for all titles is the ability to choose how many to request and to suspend the request at the time of placing it (the user may select a specific date or leave it blank to suspend it indefinitely; the date picker is not presented on the screen unless the user checks that they wish to suspend, to minimize space used).

Requesting screenshot

We have one additional feature that is available if the criteria is met: choosing what type of binding is preferred. When this option is listed, the default is “first available”, meaning the user does not care whether the copy is hardcover or paperback. Those other two options are listed in the dropdown if we do have binding information, and that title has mixed binding options.

Looking at the data on the interface, the action verb “Request” is the header, followed by the title and author. In the primary body of the request modal is all the data we could provide to help facilitate the decisions a user may need to make. The first line contains the number of requests on the number of copies and in parentheses afterwards how many are currently suspended or inactive.

Request for shared account screenshot

The second line of information will vary depending on if you are logged in as yourself or as a shared account (a feature that will be explained later). So if it is your account, it reads “You have x requests of x total requests”, or if the user has switched to a shared account, that person’s name is listed in an effort to remind the user with whose account the request is being made (“SUSAN has x requests of x total requests”).

Requested button screenshot

Once the title is requested, the button changed to a light blue with the label “Requested” and, if on a waitlist, the position and of how many (e.g. 1 of 2). If suspended, the additional text will have the date suspended to (or if a date was not selected, the text is “Suspended forever”, since “indefinitely” is too long and not simple enough language for the range of a public library’s audience).

Cancel request screenshot

One feature I would like to modify is if a “Requested” button is clicked, it brings up a cancel alert. The “Requested” label changes to “Cancel” on hover, which is not touch device friendly. Rather, interacting with a “Requested” button should open a modal with more details about that user’s request with the “Cancel” request button in red as part of the action buttons (similar to borrowing digital titles described below). This would give the user a lot more control over that request from the other parts of the catalog rather than forcing them to go to My Account.

Digital requests

Digital request screenshot

As we investigated APIs provided by our digital collection vendors, we found OverDrive had the most robust features. It also has our largest ebook collection (over 110,000 titles). Because we do have a handful of other digital content vendors, we include the vendor name on the button even though the idea is to make accessing digital content seamless. So requesting a digital title does not require the user to go to another website. Rather, it opens in a similar request modal with slightly more information.

Digital request for shared account screenshot

Like standard requests, a digital request may be made on a shared account as well as one’s personal account. Rather than have pickup options though, it simply has a field for an email address to notify when the title is ready to borrow. The field is populated with the user’s email address on record, but the user has the ability to change it before submitting the request.

Additional information includes listing out the format options again to prevent users from having to wait for a title they may not be able to access. With OverDrive’s in-browser options, this does not often happen anymore unless the user was hoping to download the title to a specific device. We do also include a note that the title can only be access with a Internet-ready device, since physical books do not have this requirement. The hope is to ensure the user is aware that this is not a physical item.

Borrowing digital titles

Borrow now screenshot

Borrowing an OverDrive title can all be done directly in the catalog. If a title has a “Borrow now” button where the “Request” button usually is, once it is clicked the title gets “checked out” to that user and they are presented with the different options for accessing their digital copy and the “Borrow now” button becomes “Get now” with how long it will be before their access expires (i.e. “Expires in 21 days”).

Borrow now screenshot

The “Get from OverDrive” modal is similar in layout to the request modal, with the header followed immediately by the title and author. In the main content area is more detailed information for when access to the title will expire, e.g. “Your loan expires on Sunday, 07/17/2016 at 10:20 AM.” At this point, the user must select the format to get a copy. Otherwise, they have the option to return the title (“Return title”) or get it later (“Get later”). If a format is chosen, the “Get now” button is enabled. Depending on the format, the copy may be downloaded, or another browser window opened with the title loaded, or the user may be sent to Amazon to finish the transaction (so to speak).

Because some users are new to digital content, we added a short line with two links to help them navigate what can feel like an arduous process even with it built into the catalog. We link to our “Ask Us” services and to the “OverDrive Help” section, even though this could pull them out of the standard workflow (and it should, if the user isn’t quite sure what to do).

As mentioned above, the “Borrow now” button becomes “Get now” once the user has clicked “Borrow now”. This opens the modal with selecting format options (and for returning the title) again. If a format was already selected, the button’s label is “Get again” instead. We originally used the verb “Download”, but several of the format options no longer require downloading. “Get”, a rather broad verb, was the most encompassing word we could come up with.

Magazine/Journal requests

Request magazine screenshot

Hennepin uses the term “magazine” rather than “journal” for its broader scope and meaning for our broader audience. Magazine titles have a unique property that makes it a different experience than standard requesting. First, we do allow requesting magazines in the catalog, down to specific issues as a user would expect. In the previous catalog, the feature was tucked away, which discouraged users. However, in this catalog, we put it in the exact same places as the other request buttons, creating a more consistent interface. Funny enough, this caused some initial confusion for some staff.

If a title is a magazine format, the request modal will list all the available issues that may be requested from newest to oldest. And although the dropdown displays multiple issues, it only accepts one issue per request rather than multiple issues per request. Displaying multiple issues was to help scroll through them rather than to allow multiple selections. To account for the fact that we have a handful of users that would like to request multiple issues from a title, once the request is placed the “Request” button does not then change to “Cancel” when clicked again but rather allows another request modal. A user needs to go to My Account Requests to manage the request (or contact the library).

The requests are made at the item level (as needed to ensure the right issue is requested), so we are able to offer the ability to place multiple requests like this. We have a script that determines what library location should be assigned the item-level request (if more than one library has the issue) so the user is not required to select a specific item themselves.

While we have several different requesting scenarios, again, we attempted to make the interface as consistent and seamless as possible to the user while providing the options needed for that format. It is at minimum a two-click process (the initial “Request” button, then “Request” again in the modal), but for the number of features and data we are able to provide with that second click, we felt it worthwhile.


Log in isn’t a particularly “sexy” feature of an application, but it is nonetheless a crucial component to a good user experience. It is a step that needs to blend into the workflow with little disruption to attaining the real goal of performing an action or seeing an individual’s personal information. So while this feature needs to be obvious and simple to use, it also needs to be integrated everywhere with minimal hassle to the user.

Navigation screenshot

We chose to use action words for our labels, which is why it is “log in” rather than “login&rquo;. “Log in” links or buttons often have a home in the upper right corner of the page, and we followed this practice as well. If someone clicks the link, they are brought to a full log in page, although other integration points check if the user is logged in and if not will first load it as a modal (a content box overlaying the page the user is on) before continuing (in an effort to make it as seamless as possible). For instance, if a user sees a title on the search results page and clicks “Request”, the request action first checks if the user is logged in. If not, the login modal loads first. When the user successfully logs in, the login modal returns them to the point in the workflow they were disrupted in so, in this case, the request modal loads.

Login page screenshot

The login form previously offered the ability to “remember me”, which stored the user’s barcode and pin in clear text on whatever computer they were using at the time. When building our own catalog, this unsecure method was abandoned so the “remember me” option would only store the barcode number in a cookie and leave the PIN to the user to handle. Many modern browsers offer to store input field data, so we relied on those options for users who were less concerned about security and would rather have less taxing log in experiences. Because the previous catalog had offered the store both, we did have some unsatisfied users.

Login page screenshot

Because the login form could load in a modal or as a separate page, the “Cancel” button had to be slightly more intelligent as well so if clicked while in a modal the modal would close and if on a separate page, it would redirect the user back to where they were (or to the home page if that referrer was lost). Also because it had its own page, the login links in the navigation needed to be disabled to prevent the user from trying, without seeming success, to log in or access My Account.

The login form is always accompanied with the ability to apply for a library card to gain access to services that the user may not have access to yet. We provide an online form for users to obtain some basic yet immediate functionality, although most user scenarios will then require bringing in verification of residency to “unlock” full access.

My Account

My Account menu screenshot

Aside from the more obvious “Log in” link in the top navigation, the primary navigation also includes a link to My Account, with a CSS driven submenu to go directly to a specific section of My Account. If not logged in, the user is again directed to the login page, and once logged in, the user is redirected to the page they were interested in.

Guest accounts

Login screenshot

In the early 2000s, Hennepin County Library launched one of the first social networks based on reading called BookSpace. It allowed people not registered with the library to join in sharing booklists, comments, and a few other features. When building the catalog, we maintained those services by setting up two types of LDAP accounts for users: patrons and web users. By default, all patrons were also web users, but web users were not required to be patrons. One had to be a patron to have access to specific features, primarily circulation-based (requesting, checking out items, accessing online resources, etc).

Guest account form screenshot

Guest accounts can be created with as little as username and password, but we do recommend email address as well for access recovery. Users could create a guest account from a link provided on the login form. For registered patrons, they could set up a username and password as well that would then be tied to their full account. This option is available in My Account Settings, and allows people to log in with username and password instead of barcode and PIN, which is often easier for people to remember. As with the barcode/PIN form, a user may choose to be “remembered”, but only the username and not password (unless they use a third party technology) for security reasons.

Both login options are presented on the form via tabs.

Alerts and logged in

Alerts screenshot

A problem with having log in actions integrated throughout the catalog (and website), is users may not see critical messages that are often found on My Account pages. At the same time, a user should also not need to break out of their workflow by being forced to their My Account section when logging in.

Once a user is logged in, the “Log in” link in the upper right becomes a “Log out” button and has two additional elements: a dropdown with the user’s name in it as well as some basic My Account navigation and a potential triangular orange alert icon that is unobtrusive but also stands out against the orange and grey color palette. The user is also likely to notice it as it is within the visual window of the primary navigation and right next to the “Log out” link. So regardless of where or how the user logged into the website or catalog, if something requires their attention in My Account they should have a hint to check it out built into the navigation.

Pseudo SSO
The catalog and website are two separate products (the catalog built as a separate application while the website was built in a CMS called Sitecore), but the mixed technology we implemented should not impact the user’s experience. The experience should be one of seamlessness and continuity, so the user always feels they are still using the library website. This also includes users who “see” the page differently, meaning visually the website and catalog are cohesive, but the code is also cohesive and creates a very similar experience for those using adaptive technologies such as JAWS.

This was a significant challenge because the catalog is built on HTTPS (with ColdFusion) while the website is only available over HTTP (with ASP.NET; HTTP is something we have been working to upgrade to HTTPS, but the process is very slow). So how do we provide that seamless experience for all users over very different technology that browsers are supposed to not trust when mixed?

The catalog was a non-issue, since the authentication tools were built in that environment and the code easily integrated. The website is in the situation of receiving secure content on an unsecure page. We went old school, once I researched and found that the technology is supported by adaptive technology. The homely iframe. Essentially, we didn’t give the unsecure page secure content. We created a section of the page that was secure and delivered to it. Making an iframe responsive in all browsers in both logged in and out states that could be different sizes (depending on the person’s name), was tricky. In the end, though, a person’s session remains alive while on the website and the experience feels mostly seamless, offering the same level of functionality to the user anywhere on our primary web presence.

Log out and timing out

Log out mobile options screenshot

Previously, logging out might never truly happen if the plain text cookies were saved on a machine. However, again in an effort to provide a more secure experience, sessions expire after twenty minutes of inactivity. Because the session is refreshed with each page load and interaction (e.g. clicking a button), this time limitation did not cause too many issues that we heard about.

One place this could cause user frustration is when writing a review. Some users write long reviews or simply take more than twenty minutes to do it. The initial modal call when clicking on “Write a review” resets the timeout length, but how awful is it when you don’t realize you’ve taken too long to fill something out just to lose all that work? So not only do all interactions (including submitting actions such as a request or a review) check logged in status when initiating and retains information to return the user back to the workflow, it also checks logged in status when the person should already be logged in, in case of a timing out. And if the user has timed out, that data is retained as they re-log in.

While the interface does do this, it can still trigger a sense of panic that the data might be lost. Without evidence that users abandon the action before trying to re-log in, our twenty minute inactive session seems to have been long enough for most cases.

Forgot PIN/password
We offer an online self-invoked PIN and password reset option for those that have provided us an email address. Forgot PIN is presented on the barcode/PIN form and password for the username tab.

When changing PIN, we ask for the barcode rather than an email address, as email addresses may be attached to multiple patron accounts. Unfortunately, guest accounts do not offer a somewhat private unique access point (usernames are displayed in the catalog), we may only offer the change password feature to accounts that have a unique email address. If not, they must kick it old school and contact the library.

Once submitted, the user gets an email containing a link that is valid for three hours that takes them to a page to set a new PIN/password. Overall we also do not limit the number of times a user mistypes a PIN or password as that punishes the user.

So, while logging in isn’t really what one would call a “feature”, building in user experience safety nets and retaining broad and high levels of service to all our existing users within the new product was very important to us as library and programming professionals. It also took a lot of effort, but effort well spent for the seamless experience achieved.

Record display

Record display screenshot

The individual record’s display page starts with some basic navigation to return to results or to page to the previous or next record of the result list. It also features a near replica of the search result’s entry for the title, but with larger cover art, possible Google Book preview (launches a modal when the cover art is clicked), and the ability to enlarge the cover to its full size. To aid in navigation, we added an in-page menu that includes counts for number of copies and reviews.

Record display screenshot

Below the “hero” area is all the “additional information”. This is ordered in what we determined was most to least critical or desired by users: Copies/Subscriptions, Details (including NoveList series), Reviews (professional from Syndetics as well as user submitted, and ratings), You May Also Like (includes staff generated lists and NoveList similar titles/series lists), Contents, Author Notes, and Staff Display. How to display the data went through several iterations from tabs and some mixed uses of carousels and other tools, and finally settling with accordions. Accordions gives the users the most flexibility in choosing what they want displayed, and especially, printed. We found several users still preferred printing titles, which is less than ideal from an up-to-date data perspective, but it also meant the page needed to be printer friendly.

The accordions operate independently to allow the user to have more than one open at a time, and by default the first four (Copies/Subscriptions, Details, Reviews, and You May Also Like) are expanded. To help minimize the initial length of the page (eases scanning), each accordion is truncated (if necessary) with an arrow button to view more of that section. This “view more” arrow hasn’t been as obvious to users, so one question I have is whether it’s best to display everything up front (all the accordions open with all the content inside them exposed) more similarly to Amazon’s “everything in your face” method than to attempt for a cleaner look.


Record display screenshot
Record display screenshot

The holdings information is displayed in tabular format with the following columns: library, shelf location, call number, binding (if available), status, and checked in toggle. The library is linked to a location modal that displays the library’s address, main contact information, hours, and a map.

Record display screenshot

The last column, checked in, is a bit of a librarian pun. To keep the column small, I simply used a checkbox with the word “in” following it. So when a user clicks the checkbox, it’s “checked in”. Ha ha, get it? “In” on its own stands up fairly well as a label, and we use a green check only for this column (again, to keep it narrow) to represent the copy as available. The data displayed here is pulled directly from the system rather than the index to keep it as up to date as possible.

Record display screenshot

For digital titles, we display different data. In a list style, we show the total number of copies with how many are available vs. checked out, and the formats available.

Record display screenshot

Journals, or magazines as we have labeled them, have an additional “Subscriptions” box above the copies accordion, relabeled as “Issues”. Both sets of data are displayed in tabular format, although the issues has additional functionality for users to locate a specific item. This functionality is added with DataTables, a fantastic javascript library for adding functionality to tables. For our “Issues” table, we have the ability to search (keyword), sort the columns, navigate with pagination, and modify how many entries are shown “per page”.


Record display screenshot
Record display screenshot

Details was a little fun to figure out because we could decide what parts of the data were more important and determine their display order and labels. Again, we only display the first four pieces of data before the user must expand to see more: description, published, author, and subjects. These display as traditional catalogs would, in their full MARC glory. Authors and subjects are hyperlinked to perform their respective searches. When the “view more” arrow button is clicked, the remaining data (genres, notes, relevant numbers) is displayed.

Also always displayed, if available, is the additional series information from NoveList. We used the NoveList API to display the data more closely to our design, utilizing the carousel tool being used elsewhere on the website. As with the other areas of the website, we only present the first 10 entries in a series in the carousel and offer a “View all” button to open the series as a new page. This isn’t the best decision because it was driven by interface limitations (a series like the Hardy Boys, with over 200 titles, does not display well in this particular carousel primarily due to its mobile interface where the “dots” that represent how many “pages” the carousel has multiplies drastically).


Record display screenshot

Reviews come from two sources: Syndetics and BookLens (our users’ reviews, as well as the users of other libraries in the region). We present the professional reviews from Syndetics first, since users have said they are more interested in professional reviews, and if any submitted reviews are available they are displayed next (again, using Datatables for sorting capabilities but not displaying them to look like a table). The code for each review does utilize microformat syntax, although the catalog itself is currently not available for search engines to “read”.

Because reviews can be lengthy, they are displayed truncated to 300 characters in blockquote format. The patron reviews section includes interactive components for writing or editing a review as well as reading the existing ones. Each patron review has the username, when it was posted, a rating if provided, and the review text. It also does truncate to 300 characters to manage page length.

We followed Amazon’s method of sorting for the reviews. Deciding how best to allow a user to sort reviews was difficult in part because we allow half star ratings. The sorting portion itself was not too difficult, using date and rating for ordering (“newest to oldest”, “oldest to newest”, “loved to disliked”, “disliked to loved”). We did not think users were too interested in filtering reviews to such a level of granularity as by the half star, and Amazon’s method seemed a good option to replicate. The second “sorting” (it’s actually filtering) dropdown thus has these options: “all ratings”, “all positive”, and “all critical”. People seem to be mostly interested in those that rated it highly or poorly, so filtering does not include “3 star” ratings as that is simply middle of the road.

In addition, users are able to flag a review (“report abuse”). This delves into BookLens functionality, so I will not go into detail about how this process works, but we do add an additional “are you sure?” layer that is not included in the BookLens widget (we, of course, opted to use their API). So if a user accidentally clicks on the “Report abuse” link, a confirmation alert appears stating “Reporting this review will alert staff. Are you sure you wish to report this review?” with buttons to “report this” and to “cancel”.

You May Also Like

Record display screenshot

This is our recommendation section and contains lists generated by staff and lists provided by NoveList. We put any staff generated “if you like…” lists first, as they are the most relevant, followed by any other staff generated lists (including awards lists) the title is found on. Once those are listed, we look for any NoveList lists (similar titles and similar series) to append. Each list is displayed as a carousel with brief descriptions of the title or why the title was chosen popping up on hover.

Record display screenshot

To once again minimize the length of the page, if more than one list is tied to a title, we only display the first one and the user must expand to see the rest. Each carousel follows the same rules regarding how many entries are in each one and the “View all” button-link. The idea here, again, is seamlessness and consistency in the user experience regardless of where the data is coming from (and how much we need to “massage” said data to create that seamless experience).

Contents, Author Notes, and Staff Display

Record display screenshot

The remaining content accordions are by default closed, although I would now argue that “contents” needs to be more prominent (such as replacing the “series” section on the details accordion) when the format is “music CD”, since it lists the audio tracks. If Contents or Authors Notes are not available for a title (You May Also Like as well), that section is not display on the page.

Record display screenshot

Contents comes from Syndetics and primarily includes audio track listings for CDs and chapter titles for books. Author Notes also comes from Syndetics and is just that, whatever content they have, often a short biography, of the author for a title.

Staff Display is the traditional librarian-esque MARC display of the record. It does not represent all the data we have for the record, since we expanded this using the Solr indices we built to ingest all the data and make it available to the catalog, but it does display everything from the librarian’s software. Mostly this does not seem very useful for standard users, but we do provide the option for the best transparency.

SERP: Entry data

The search results page holds up to 30 record entries per page, and each entry is divided into three main columns styled specifically for types of information digesting. In mobile mode, the first and third columns are combined but the mobile interface maintains full functionality and content.

Entry screenshotEntry mobile screenshot

Column 1: cover art

The first column is for fast scanning and is surprisingly overlooked as a critical component for title discovery. Originally we used large images and scaled them down with CSS to provide crisper graphics for retina displays (setting the image’s width to 100% and the containing box to a fixed pixel width, 115px at full screen), but this led to unnecessarily large page loads. Using medium-sized images worked perfectly fine with little quality loss noticeable on retina displays.

The provider for the majority of the images is Syndetics (which we cached locally for quicker response time), but they did not provide the majority of cover art for digital content, and much of our government documents and other less common formats simply didn’t have cover art. To improve these experiences, we used the Overdrive APIs to pull in cover art for their titles, and for everything else we generated “fake” covers using CSS. The no-image covers are color coded (books have blue backgrounds, dvds green, journals yellow, and so forth), have the title on them, and a large format icon. Doing so allowed us to to maintain the quick scan for the left column.

The image, or non-image image, is a link to the record display page.

 Entry screenshot

Column 2: in depth content

This is the bulk of the content and most text heavy. The title is bold, larger, and links to the record display. If the entry is part of a series, the series or list of series displays in parentheses after the title. These are individual links that perform a keyword series search. Originally, they were listed below the author and labeled as series. After usability testing, we learned they were not noticed there, prompting a move to the more prominent location (similar to GoodReads). However, usability testing after the change proved little improvement in identifying the content as series information.

Directly beneath the title is the author linked to an author search and preceded by the word “by”, if one exists. The author, however, is modified from the authoritative form, which in most cases includes birth/death dates, so that only the name appears. The hyperlink, however, contains the full authoritative form and performs the search against the author index for the most accurate results. Rather than display the author’s birth/death dates, in parentheses after the link is the publication date. We had some concern this might confuse users, but we found this to be untrue. In fact, when people sought out the publication date (often to determine order for series titles), they saw it.

Six months after launch, we added ratings using a tool in collaboration with the University of Minnesota and other regional libraries. This tool, BookLens, offers three types of ratings: average rating (if ratings exist for the title), predicted rating (based on the user’s other ratings and how they compare to other users who have rated the title), and the user’s rating (if the user rated that title). Because of the multiple states of ratings, it was necessary to include a textual label for ease of clarity. The labels are, respectively: “Average rating”, “You might rate this”, and “Your rating” with colors being grey, light blue, and dark blue. For average ratings, the number of ratings used to compile the average is displayed in parentheses after the stars. Displaying the number of ratings an average is based on was determined to be critical to better represent the rating. After the ratings is a small speech bubble followed by another parenthetical number to represent the number of reviews. This is linked to the reviews section of the record display page.

The next line is the collection code, which is a combination of the audience + fiction/nonfiction (if applicable) + format, e.g. New Adult Fiction Book. If the title has no copies but has some on order, this statement is added to the collection code, e.g. New Adult Fiction Book (on order). One feature that was asked for by several usability participants was to know what e-formats were available before placing a request. The formats were listed on the record display page as well as the requesting modal, but this required additional digging. Ideally, the format limit would include the breakdown of e-format types, but a simple patch job was implemented in the interim by placing the formats after the collection code, e.g. Adult Fiction eBook (EPUB, Kindle, Read online). This is only done for OverDrive, currently.

Another critical piece of information that often is not easily represented using cataloging standards is the length or duration of the title from the 300 MARC field. We built an algorithm to extract, where possible, that data and transform it into AP style. So for a DVD, the description looks something like “1 videodisc (124 minutes) : sound, color ; 4 3/4 in.” This, for a typical user, makes that critical bit of information somewhat lost. We do display the 300 field in its full glory on the record display page, but the next line after the collection code/format contains, when possible, the AP style version of it, e.g. “1 disc (2 hours, 4 minutes)”. Some additional examples:

  • 376 pages : illustration ; 22 cm. becomes 376 pages
  • vi, 309 p. : ill. ; 24 cm becomes 309 pages
  • 10 sound discs (ca. 12 hr.) : digital ; 4 3/4 in. becomes 10 discs (12 hours)
  • 2 audio discs (2 1/2 hr.) : digital, CD audio ; 4 3/4 in. becomes 2 discs (2 hours, 30 minutes)
  • 1 videodisc (approximately 95 min.) : sound, color ; 4 3/4 in. becomes 1 disc (1 hour, 35 minutes)

The title, author, publication date, collection (audience, format, etc), and duration are all considered critical pieces of data for determining initially whether the title meets the criteria. One additional piece that is often overlooked on a search results page is the summary. This is hard to add well without overwhelming the user. The summary was originally in a hover action on the cover art. However, this prevented mobile users from accessing it easily. So after a few months, we chose to “expose” the summary along with the other data, separating it from the rest of the content with a horizontal rule as well as displaying only the first 300 characters, if longer, with a “see more” link. This reduced how much length was added to the page, but length was certainly added. We also continue to struggle with “dirty” markup in the MARC records (HTML insertion that breaks the “see more” code); we have some code in place to strip most of it out, but some still get through causing some of the descriptions to display fully rather than truncated.

A pseudo column exists in this middle data-rich column — a format icon that floats to the top right. In some early designs, the icon preceded the collection code, but this forced it to be the size of the text and was lost in the “sea of characters” around it. The icons are custom made and turned into a font for ease of scaling and loading time. They are hidden by screen readers intentionally, since the collection code includes format, but they do have a tooltip (on click event since hover events are spotty on touch devices) that do reveal the textual label of the format. Positioning the larger icon to the right of the primary content also places it very near the action buttons in the third column (on tablet and desktop), which may reduce requests placed on the right title but wrong format.

Call numbers and remote vs. in-library
One decision we made was to not display any call number data unless the user was inside a library. Before we added the duration data, the call number existed on its own separate line just below the collection code. Once the duration was added, the call number was placed after the collection code information. It is not as visible in this location, but the space saved by not having an extra line was important to keeping the total page length in check.

The call number that is displayed checks whether the location the user is in has a copy first and will display that. If not, it then looks at all the call numbers and pulls the most common call number used. Because of a retroactive call number project several years ago, this is often sufficient. In the case of a tie, the call number used in our regular collections is used first.

Column 3: actions

After a user has scanned the data from the first two columns that determined this title is potentially what they are seeking, they must now make the decisions about acquiring it for use. The third column contains action buttons as well as the current availability of the title. These all have different states based on the user’s data, if logged in, and the title’s availability status.

Request button
We display a large amount on the button itself. For a standard request, it simply reads “Request”. If it’s a digital title, it is “Digital request” if truly unavailable and “Borrow now” if a “copy” is available. When a user clicks on a digital borrow/request button, JS first hits our availability service to verify its availability. If during the time the page loaded and the user clicked the button the title’s status changed, the user will be prompted to either place a digital request instead or to borrow now, depending on the alternate status. Other “requestable” statuses (not logged in) include “Not requestable” (button is disabled), “In-library use only” (button is disabled), etc.

Add to list button
Lists are one feature that can cause a good deal of confusion for some users, and finding a label that is most accurate was challenging. In fact, we use “add to list” because it is legacy from the previous system, so existing users were already familiar with the service. Before coming to that conclusion, some ideas revolved around “book bag” or “wishlist” or “save for later”. Frankly, the entire workflow for this button was modified multiple times before coming to what it is now, and it is back on the design board to improve and simplify. All titles may be added to a list, so while not logged in, this button doesn’t provide much additional information.

Displaying the availability summary at this point was critical so users could determine whether they would go to a library location, request, save it for later (add to a list), or possibly rule it out completely. We present all the relevant data to make that determination:

  • the summary statement
    Available, displayed in green, bold, and with the number of libraries in parentheses afterwards, e.g. 10 libraries, which then has a click tooltip with the list of libraries; Not available (in normal text); Limited access (also in green and bold but often means it cannot leave the library); and Available off-site (in normal text, with a tooltip that provides additional information for how long to expect a copy to come in). This, again, aids in scanning.
  • the number of copies and requests
    Some library interfaces attempt to calculate for the user the wait time, which will always be a guestimate since we can never know if someone will return it early, late (or never), or what location it might need to travel to and from. We present the facts alone, and if more copies have been ordered we include an additional line that separates that count (e.g. 200 copies on order) for the user to best assess the situation.
  • any additional notes
    If a title cannot leave the library, in red text is the message “in-library use only”.

Because timeliness is important for this information, and our index rate hovered around 60-90 minutes, these statements became a point of frustration for users. The catalog appeared to be “lying”, when a user would see it is available and it was not by the time they got to the library. This happened frequently enough that we built an availability service that, on page load, checks what is in the index with the most recent data and refreshes it via Javascript if inaccurate. This happens every five minutes, in case the user sits on the page and expects the availability to still be accurate. We built this feature in for OverDrive content as well.

Entry screenshot Entry screenshot

Personalized data

If the user isn’t logged in when clicking either of the action buttons, the login modal comes up first. Once the user logs in, they are given the next modal (the request modal or add to list modal) to provide least interruption to the flow. A logged in user get a much better experience, however.

Let’s start with a scenario. A user is reading the latest Hardy Boys series and wants to get the next one but doesn’t quite remember what has already been requested and what one is already checked out. If logged in, the Request and Add to list buttons become a wealth of personal information that will help inform the user what appropriate action to take. So if a title has already been requested, the button changed to a disabled “style” with the label “Requested” and subtext with the current status (e.g. 1 of 2, In transit, Held until xx/xx/xx). If the title is already checked out, the request button is styled normally but includes the subtext “My copy due xx/xx/xx”. So for the user who wants the next book in the series, looking at the search results they can see they’ve already requested the next book and the one they already have checked out.

The “Add to list” button is similar. The colors inverse with a check in front of the label to indicate a title has already been saved for later. Not only that, but if the title was saved to multiple lists, the text is slightly different: Add to list > On a list > On lists.

All of this information is available right where the user needs it when making decisions about titles in the catalog.