Month: April 2016

Search box

Search screenshot
Mobile search screenshot


The word “catalog” is a library device that refers to a system of indexing an inventory of materials that are available in a collection and displaying rudimentary characteristics of an indexed item. Prior to the redesign, “catalog” was a link to the native catalog’s interface and acted as a main access point to the primary feature of the library’s online presence.

Ideally, the search box on a library site is synonymous with “catalog”, and hence a visible label shouldn’t be necessary (still recommended to use a < label > field but hidden to provide context for screen reader users, e.g. < label class="sr-only" >Search< /label >). However, most libraries have at least three primary searches: catalog, website, and online databases (most of them via a single interface). To make a single search for a library, the preferred interface is a bento box. I would suggest it needs to be more algorithmically intelligent than that, but that is currently beyond the scope of this project.

Because of our three-search situation, we ended up with a tabbed search feature with the label “Books, movies, music”. I have several ideas for moving away from tabs, which have poor visibility and clarity (the “website” label in particular, since its scope is quite ambiguous to most users that consider the catalog and other modules such as events to be part of the library website, or they think it’s similar to a Google search engine to find websites). The “catalog” label represents the top three popular generic types of materials.


All of the search options are keyword, so no “title starts with” or other obscure options most search engines buried long ago.

By default, the index is set to “All”. This index contains an incredible amount of data, which I will go into detail in a later post. To summarize, it includes all the bibliographic data (everything in a MARC record from 010-899 a la SolrMARC), item data (primarily holdings data), and external data from vendors such as Syndetics, NoveList, and OverDrive. We then apply general boosts to specific fields, and a special popularity boost that makes an incredible difference. Users may search by call number, ISBN, keywords, or simply submit a blank search (this will return the most popular titles in the system due to the popularity boosting).

Because we did not provide pre-limiting options (the most desired by users were location and format), we instead included the fixed limit options as specialized query parameters. For example, “harry potter dvd” would boost the dvd format limit.This followed in line with the idea of natural language processing, but pre-limits would have helped to define the scope of the tools available (e.g. the user would know “dvd” was an option because it would have been listed). Synonyms were intended to be added, so a search for “harry potter movie” would have also boosted movie formats such as dvd. Fixed-value limits that can be queried like this include: format, age level, language, and fiction/nonfiction.

The other index options are mostly standard: title, author, subject, and series. Series is based on book series and had some lack of clarity or at least functionality that users expected. What is indexed are the official names a series has (MARC 4xx and 80x-83x), but users wanted not only the series titles but the titles themselves (MARC 20x-24x). So a search for “game of thrones” would return a result. However, in order for A Game of Thrones to come back in the results, the user currently has to know and enter “song of ice and fire”.

Authors originally did not include cross referencing as well, which was added during the beta preview to staff (e.g. searching “robert galbraith” would return “J.K. Rowling” titles). However, the cross-referenced data is not displayed in the record anywhere, so users at times struggle to understand why an entry would be in the result set. We never had an opportunity to dissect cross-references to determine if we could find a reasonable display, since it contains the vast amount of data including spelling variations for multiple languages.

Advanced search

More search options screenshot

When considering more complex search functionality, the initial concepts included an advanced search page. However, looking at industry equivalents such as Amazon and Barnes and Noble, finding an advanced search page was a painful task. If one existed, it was buried. Our competitors relied on smart algorithms in their basic search to manage the bulk of the usage, and that is what library users also have come to expect.

Our algorithm for searching is good in some aspects, but the search itself lacks some basic features such as spellcheck and auto-suggest and we could store even more data and synonyms. An advanced search was determined useful, but the search and more search options became a part of every page rather than have its own home. Labeled “more search options” for plain language, it is a downward-opening tab on the “books, movies, music” tab. The tab itself is lost in the low contrast sea of blues and greys, one of our ongoing accessibility problems.

The more options box appends four more index-specific input fields, a brief instruction for using wildcards, the ability to “clear all text”, and an additional search button (both search buttons would submit the full form). The basic search does also have a clear-text-from-input-field “x” that was introduced with mobile devices to aid in clearing fields with a single tap, but the “clear all text” button removes all the field’s values.

If a different index was selected for the basic search, such as “title”, as soon as the user engages one of the more search options fields, the main search field reverts back to “all”, locks it in, and migrates the value that was there into its respective input in the advanced search form. This allows the user to explore the options without switching to it without intent.

Users, in usability testing, thought format and location limits would be in the basic search’s index dropdown or in the more search options.

New search

Search with limits
New search modal

One feature native catalogs consistently offer is the ability to perform a “new search” or “start over” (using III’s Millennium interface as an example). However, we observed NO ONE used the button unless explicitly instructed to. If performing a string of different queries, nearly every user simply changed the keywords. So the button got the boot. It didn’t have anywhere to link to anyway, since the search box didn’t have a home of its own.

But what about the searches we asked users to perform that encouraged use of limits? The limits were applied, but did the user intend to keep the limits and simply modify the existing keyword query, or was the user performing a whole new search? And did that new search intend to stay within the selected parameters (e.g. looking for this year’s English cookbooks to a new search for this year’s English dvds)? Who were we to tell the user how to do their searching?

My solution was to ask the user directly. If no limits were applied, changing the query doesn’t matter. We take the cognitive load off the user if they did apply limits and did not remember to remove them when switching gears by checking if limits were applied and if the query itself changed substantially (that is, if the root query was still in the search string, we leave the user alone). However, if limits were applied and the base query changed significantly, a “new search” modal comes up.

The modal presents the limits and offers the ability to uncheck any of them or simply remove them all by clicking the “Search no limits” button. For ease of use, the “Search with limits” is already in focus so power users (staff are most likely to find themselves in this situation when helping patrons find materials) can perform a search quickly hitting the enter key once to submit the search and once more to accept the “Search with limits” option.

When the “new search” button was removed and this put in its place, I was uncertain how users would react to it. Amazon doesn’t do it, and in fact I could find no search interface with limits/filters that gave the user the option at all. Most, when the query changed, would simply clear the limits. The feedback was initially mixed, but many usability participants when given this option expressed delight. Improving the change detection algorithm (written in JS) would make it an even more useful tool.

Ideas based on feedback

Remove the tabs and change to a select dropdown. The tabs in mobile especially caused confusion, so utilizing the dropdown instead provides more expected functionality. Initially, some users (primarily staff) also missed the “title begins with”, which would be a “browse search”. At one point we had considered implementing it, so I integrated the concept into the design based on Northeastern University’s interface: http://onesearch.northeastern.edu

Basic search concept
Mobile basic search concept

The basic search eliminates the specific index search for the catalog and improves the algorithm instead. The dropdown is next to the action button because the thought order is different. Instead of thinking “the title I want is To Kill a Mockingbird”, the scope becomes a secondary feature that one can consider right before submitting a query. Depending on the strength of the single-search (“all”) interface, it would be first, or last. This is arguable, but then again, this is only a concept lacking testing.

To the right is the ability to toggle the more search options or into browse search mode. Placing the links next to the search rather than below at larger screen sizes saves some vertical real estate.

More options concept
Mobile more search options concept

The more search options is extended to include pre-limits as well as the ability to choose what index to add search terms to. The tool would mostly support staff, but some power users expressed interest in materials distributed by specific publishers (such as Christian fiction and manga titles) or the ability to more specifically select publication ranges. These users are very few, but employing the UX concept of edge cases becoming stress cases, the existing functionality would not be obvious (one would need to sort by publication date and slog through the results).

Browse search concept
Mobile browse search concept

For the search browse, a new search box with a query types dropdown would replace the main search. The results would simply “drop” the user in the middle of a large referential index with cross-reference data available primarily from authority records. The links would then execute a keyword query.

These ideas remain conceptual and have not had any testing to provide proof of concept.

Supporting patrons experience homelessness, extreme poverty, and high mobility

The purpose of this research was to determine how web technology impacts user experiences in libraries for often overlooked groups of people. For ease of describing these audiences, I will be grouping users experiencing homelessness, extreme poverty, and high mobility (such as teens couch hopping) as the “disenfranchised”. This loosely ties in those who are experiencing physical and mental accessibility concerns.

This is a slightly modified version of an internal proposal for the library-built catalog so does not cover the full spectrum of modifications that could be made to improve the online catalog experience. I may come back to edit this so the concepts and ideas are more flushed out.

Research summary

Disenfranchised users often have mobile devices and use them as a primary source of data and communication. They are likely going through traumatic and stressful points in their lives.

Chronic homelessness in the U.S. is a very small percentage (7.3%); many who are experiencing homelessness are in a temporary situation and working to get back into a home. See The State of Homelessness in America report for more details.

Based on a survey conducted by Silicon Valley-based Community Technology Alliance in March 2013, 69% of low income and unsheltered people (498 surveyed) owned a mobile phone, and of that 54% had data access.

A study from 2011 surveyed 169 homeless youth in Los Angeles and found that 62% had a mobile phone.

A fantastic study done in San Diego looked into plans as well and found most mobile phones were prepaid with unlimited text and talk. Cricket was the carrier of choice likely due to its physical proximity (physical locations), which offers a basic plan at $40 monthly with 2.5GB data plan. According to Cricket’s phone plans, data access can start at 4G speeds but are reduced to 128Kbps when the allowance is used up.

According to the Census Bureau, those in near poverty have these demographics: they have less than a high school education, more women than men, they are predominantly black and young (under 18).

Minnesota saw a 6% increase of homelessness in 2013. The Wilder report from 2012 (focusing on Minnesota specifically) identified that 42% of homeless adults are white and 38% are black. Most (77%) that are 18 and older have a high school diploma or GED. Violence is often associated with homelessness, either experienced before (as a cause) or during (almost 20% were physically or sexually assaulted). For youth, a common cause is sexual orientation (around 40% for 18-22 year olds). Eviction is the primary cause for homelessness (38%), followed by reduced hours at work.

Technology considerations

One noticeable theme is that many of the recommended features also improve the experience for the general public, so while they should benefit this specific audience greatly, many of these would be beneficial to implement in general.


Change the catalog to keyword based querying, allowing for more natural language queries. This shift makes content more accessible to a wider audiences, specifically impacting those with fewer means and/or less education.

  • Improve natural language processing in searching, e.g. with synonyms (removes the barrier of understanding library jargon, for example a user may type “harry potter movie” and the algorithm can boost the relevancy of DVD/Blu-ray formats for “harry potter”).
  • Build a bento or alternative single search and make all resources findable (removes the barrier of understanding the content breakdown and different search techniques with different search-related products). (I would label the search “all” and the catalog specific search “books and media”.)
  • Build dynamic search suggestions (removes some spelling dependencies and provides immediate feedback before committing to a query). Alternatively, this could load possible queries and the number of results, or even more dynamically act like Google with immediate result updating as the user types.
  • Improved No Results logic (e.g. change AND to OR) paired with spellcheck tool (that checks against author name index as well) to ensure a user never gets a “No Results” page (post-search spelling variations offer search progress instead of dead end).


The experience of library catalogs on mobile devices has been often cited by users as undesirable for several reasons including lack of a well-designed responsive layout. Especially ignored is the problem with limited data plans.

  • Minify the code and combine all in one file for CSS and one file for javascript (this reduces the amount of data transfer and requests to the server).
  • Image optimization (server tools are available to automate image size optimization, which could be applied to the cover art server as well as the few images used for the website design).
  • Improve the mobile and responsive experience, especially for Android devices. The BootStrap Framework (v3) utilizes functionality for its features such as modals that have provided bad experiences (such as faulty z-indexing layering that results in triggering content beneath the content).
  • Change the method of search engine results page (SERP) layouts so the list display does not load the cover art (to make the transition between the different layouts quick, this was all written with CSS so all the content loads and is simply styled differently; allowing this choice to be stored either in a cookie or in a personalized setting would drastically reduce load time for those who prefer the text only option).
  • Build in search customization/preferences including pre-select limits (e.g. English only language filter), preferred layout, and preferred sort (although the user needs to log in for preferences to take effect, this removes any extra page loads currently needed for post-search modifications).
  • Test My Account pages for someone who may have limited data in a patron record (e.g. lack a phone number, address) to ensure the pages and services respond appropriately.

Extending access (additional considerations)

Larger projects to implement that would increase visibility and provide ease for our more diverse users would include globalization and Linked Data efforts.

  • Globalization, or offering web content in multiple languages, could reach immigrant communities. General studies indicate ESL residents can be a significant portion of struggling community members that also often do not understand the fundamental differences of public libraries in America. If a default global language was selected, algorithm boosts based on language could be an added feature (that could be opted out of) so if Spanish were chosen as the default interface language, Spanish titles would have a higher boost over other languages. The benefit, usefulness, and maintenance problems with this feature would require further investigation.
  • Exposing the catalog’s holding data to search engines via Linked Data could increase visibility to non-library users to find cost-free services for the materials they are seeking. How this might work is a person does a Google search for The Fault in Our Stars book, the content box on Google’s search results page could include not only the summary but the library holdings information.


Designs on Mobility: Perceptions of Mobile Phones Among the Homeless (2014)

Cricket Wireless Cell Phone Plans

Tech Alliance Keeps Homeless Connected through Mobile4All

A Homeless Man and His iPhone

Here’s What Homeless People Think About Internet Access at Seattle’s ‘Tent Cities’

Cell Phone Use Among Homeless Youth (2011)

The State of Homelessness in America 2014

Poverty (Living in Near Poverty in the United States: 1966-2012)

Homelessness in Minnesota

Homeless in Minnesota (2013)

Survey Shows: 5 Key Reasons People are Homeless in Minnesota (2013)

Hennepin County 2012 Minnesota Homeless Study

The overview

Before I delve into all the minute details of very specific features that were considered and/or built for the catalog, some context is necessary to understand the scope and impact of the endeavor our team undertook.

I began my work for the Hennepin County Library in May 2013, but the vision of building our own catalog started prior to my arrival. The project was rolled into an overarching plan to transform the entire online experience. I will not focus on how we got to where we were to begin building such a product, since my involvement was minimal. However, I can say that at the time we had the full support of library administration and, summarily, no product available could meet all the requirements we had (this continues to be true).

Hennepin’s library system consists of 41 libraries within a 600 sq mi county that includes Minneapolis, MN. The population is approximately 1.2 million with around 800,000 active users registered at the libraries. In the system are about 1.6 million titles with 9 million copies, however, a couple million items remain uncataloged. Library usage is relatively high and stable.

The team

Originally, the team consisted of four developers (three holding MLIS degrees) and four senior librarians whose primary responsibilities are online content. A developer and another senior librarian joined the team about six months before the initial launch in October 2014.

Of the developers, one had expertise in server and data management, one was the systems librarian, one was a utilitarian developer mostly writing server-side programming, and one (me) wrote front end code. We had shared knowledge in several areas. The fifth developer was also front end focused.

The tools

SirsiDynix Horizon ILS customized using an in-library built API
Solr using SolrMARC, LDAP, and SQL databases
ColdFusion (chosen for the team’s existing knowledge)
Twitter Bootstrap and jQuery
Git code management
APIs from content vendors (including Syndetics, NoveList, OverDrive, and BookLens)
Agile development process

The style

Much of the basic styling came from the design delivered from a local web design company for the library’s website, with the dominant grays and blues to match the county’s website design done by the same company. The library developed its interface within those and the library’s existing style constraints.

The why

When looking at the existing market, none of the products provided the features the library wanted, and most interfaces did not allow for the customization that would best support the community. A fully integrated, seamless experience that supports accessibility and built on a responsive platform (not retrofitted) with clean code that we could expand and improve with feedback. The catalog is a primary access point whose experience quality could be controlled. And the resources were available to do it.

The initial launch

Development began March 2013 by using Blacklight’s Solr implementation as a foundation. With the preliminary index built, catalog design could begin. The catalog (and My Account) was built in six main phases: server and index set up, catalog search and results, record display, login (including guest accounts) with My Account and requesting and renewing, remaining account pages, and the remaining planned features such as account sharing and OverDrive integration.

Each phase was released to staff for testing and feedback, and in July of 2014, a beta version of the new catalog and My Account was released to the public. The official release occurred in October 2014.

Looking back, building a complete catalog, single sign on, and My Account in less than two years is impressive for a team consisting of four developers for over half that time. Halfway through the development the new styles were delivered and interface rewritten with Twitter Bootstrap. Conversations occurred weekly with stakeholders and content librarians. Usability testing ran in tandem. But many features also did not make it in the initial launch with an abbreviated development timeline.



The content of this section is based solely on my perspectives primarily while working on building a public library catalog with the Hennepin County Library. My views or recollections of discussions do not represent the organization. This is a series of posts that represent my experience and thoughts as a front end user experience developer working on a team of mostly eight people over the course of two and a half years.