This post is about regression, but not the kind that involves formulas and computations. It’s about regression as the opposite of progression. As in going backwards. Losing ground. Regression is what has happened to a key library statistics software application, the recently revised Find Your Library tool available on the Institute for Museum & Library Services (IMLS) website. This new version appeared in the past year, exactly when I’m not sure. The original version was made available several years back (I recall first using it in 2007). The purpose of both versions is to provide access to statistical data kept in the Public Libraries Survey (PLS) datafiles. PLS is the annual survey that has gathered U.S. public library statistics since 1988.
In my opinion the Find Your Library application deserves a grade of D on functionality, by which I mean how well the software does what users need done. Its main flaw is the lack of support for multiple search terms. Further on I describe the problems this causes for libraries in search of their own PLS data. I mention this here just to note that multiple search terms have been integral to library online catalogs since the early 1980’s. Which means the IMLS tool’s search function represents a regression of, say, 35 years!
On user-friendliness and usability I give the application an F. The system fails to give users clear directions about how to find their library’s data. Instead, its organization, layout, headings, labels, and instructions are almost uniformly confusing. Plus, the system has no HELP function or FAQ. Add to this the extraneous content that takes up most of the screen real estate, and this system puts libraries seeking their data at a disadvantage.
If my assessment has any truth to it, there is no reason to lay full blame on the application’s programmers. Due to the inevitable compromises that system development projects entail, along with constraints built into programming platforms, software like this is not unusual. In fact, inadequate software systems are common in the information technology industry, including the several multi-million dollar failures described here. This problem is part of the industry’s culture. It is, you could say, systemic. As Alan Cooper, creator of Visual Basic, writes:
Most digital products [hardware and software] emerge from the development process like a sci-fi monster emerging from a bubbling tank. Instead of planning and executing with a focus on satisfying the needs of the people who use their products, companies end up creating solutions that—while technically advanced—are difficult to use and control…[Programmers] are often given incomplete, myopic, confusing, and sometimes contradictory instructions and are forced to make significant decisions about the user experience with little time or knowledge of how people will actually use their creations.1,2
This is why I suspect that the biggest failure in the design of the IMLS tool was the lack of deliberate user review. The application is awkward and inflexible compared to the earlier version. Especially since that version had a companion application, Compare Your Library, which let users retrieve and download multiple libraries’ data for comparison purposes. This second application has been replaced by the IMLS Data Catalog. The Data Catalog is also technically advanced but has regressed in terms of usability, an argument I’ll save for a later post.
The re-design of the Find Your Library application seems to have been inspired by recent trends like open data, data hacking, data digging, and data diving. The tool definitely has a 21st century look and feel: an interactive geographical map, multiple interactive data visualizations, and easy links for sharing content on Facebook, Twitter, Instagram, and YouTube. With these 21st century trappings the application seems updated and cool. Except, as I say, it is anything but an improvement. Let me show you why.
At first I thought that this one user interface quirk I noticed was not worth mentioning. However, because it sets the tone for the entire interaction between the software and humans, I decided to report it. On the first page, shown in the image below, users will suppose that they should click on the image with the finger pointing to the magnifying glass icon. Oops! Sorry for the miscue! The designers mean for users to click on the text in the plain green box instead. Almost a trick, since the image is so engaging and the green box so nondescript. But this innocuous design decision signals what’s in store for users—a guessing game about how the system works and what it does.
Tricky IMLS Public Libraries Survey main menu.
This miscue is just one of many instances where the system’s designers ignored the user experience. But let’s proceed. Clicking the green box gets us to the application’s main page shown here:
Find Your Library tool main page. Click image to link to page on IMLS website.
This appears to be a reasonable menu. Users familiar with PLS jargon will step through the options without much difficulty. But other users, for instance, the 5,350 U.S. public libraries serving communities of 5,000 or fewer residents, may not. The name of the 1st option, Explore Library Systems, along with terminology like administrative entities and system-level organizational characteristics, may put off libraries like these. The libraries won’t think these terms apply to them.
Examining option 2, Explore Library Outlets, may make libraries new to the system, and those who use it infrequently, wonder if they are outlets or outcasts in this system! If they choose option 2, they’ll see it leads to only 5 actual measures: hours open annually, weeks open, number of bookmobiles, square footage, and county population. The rest are administrative information such as phone number, county name (but not state), locale type, and a few others. Typically, these aren’t the data libraries are looking for.
I’m not sure how libraries will interpret the 3rd option, Look Up FSCS ID’s. Maybe they will be familiar with FSCS ID’s and will have reason to use the option. But it doesn’t matter because the option is redundant. It leads to the same data display that is accessible via the 2nd option. Meaning the 3rd option is just taking up menu space. (It could be useful to provide libraries with the opposite search, where entering an FSCS ID retrieves the data for the library associated with that ID. That would actually make the IMLS tool a bit more usable for reasons I’ll explain in a later post.)
We don’t need to step through the rest of the menu.3 The point is that, consistent with Alan Cooper’s diagnosis, the menu apes the mechanics and jargon of the underlying technology instead of being geared to the needs of the human users. Nothing in this menu clearly informs users how to get to the data they’re seeking. Libraries want to find statistical data about their own and other libraries’ expenditures, circulation, eBook collections, registered borrowers, Internet computer use, hours open, and the like. Shouldn’t it be possible to use plain English instructions on this page that will guide libraries to these?
As it is, novice and infrequent Find Your Library users will figure out that they should use the 1st option, which will lead them to the Explore Library Systems main page shown below:
Note: The appearance and sizing of the application’s pages differ depending on the device and browser used. Images shown in this post are from my desktop’s 23” screen using FireFox. A few images are cropped at the bottom edges to save space here.
Given the name of this IMLS application, you’d expect the page shown would concentrate on finding a library’s data. But it doesn’t. Instead, it is filled with extraneous content. One-third of the display is taken up by the spacious title area. Fortunately, users can scroll down to move the oversized title out of the way as seen here:
Explore Library Systems initial search page scrolled down to hide title area. Click to see larger image. (See note above about page appearance.)
Scrolling the title area out of view doesn’t help much, as the page is still filled with extraneous content. The map of the Americas, which occupies 2/3 of the display, has little to do with U.S. libraries finding their own data. The 4 rectangular boxes at the left occupy 1/3 of the display.4
The top box turns out to be the only relevant item on the page. This is where the search field that users need is located. This search box occupies only 1/10 of the page. Not that a giant area is required, especially since the system restricts users to a single search term. But this area should be central to the page or emphasized in a way that users’ eyes will move directly to it.
The search field is labeled LIBRARY NAME (LIBNAME), indicating that this is the only PLS data item that users can search by. In the search field in the screen below I entered the term bad river, which caused the system to display BAD RIVER PUBLIC TRIBAL LIBRARY in the drop-down menu at the left:
Explore Library Systems page with library name entered in search field. Click to see larger image.
This drop-down menu is quite helpful, the nicest thing about the whole application, I’d say. (Unless users get caught in its one trap that I’ll describe later.) The menu is quick to display a list of one or more suggested library names matching the pattern of characters as you type. Clicking on an entry in the menu produced this display:
Explore Library Systems page showing library data retrieved. Click to see larger image.
Finally, we’ve found a library’s PLS data or at least some of them! The data appear in the large, mostly blank rectangle to the right, below a darker strip of column headings. (Towards the end of this post we’ll look closer at how the data are displayed.) This rectangle is actually an expanded version of the search box originally located at the left. This is why the search key LIBRARY NAME remains as the title.
Users can enter a different library name in the search field to retrieve a different library as shown here (see red arrow):
Explore Library Systems page with new search characters typed in. Click to see larger image.
Here the drop-down menu displayed a list of libraries found in the PLS datafile based on the characters I entered, LOS. When I clicked on an item in the drop-down menu, the tool retrieved the data for the library I selected. This caused the data for the prior library to disappear. So, users are not able to retrieve and view different libraries simultaneously. Which makes you wonder what all the blank space on the page is for.
Anyway, notice in the image above that the map moved to the left and shrank in size. There is no particular reason for this other than the need to plant the map somewhere. Notice also that Texas is now even more prominent. Having Texas highlighted in bold has nothing to do with my search, which retrieved a Native American tribal library from Wisconsin. It would be nice to be able to close the map, but the application does not allow this. As a result, users wishing to share their search results via whatever social media they frequent are forced to share the great state of Texas, too!
Now we can get to the main defect in the application’s search function. If users search on a library name that, by coincidence, is shared with other public libraries in different counties or states, that common name shows up in the search drop-down menu only once. There is no indication that the name belongs to other libraries also. Only after users click on that name will they discover that the system retrieves multiple matching libraries as seen here:
Explore Library Systems search that retrieved 3 libraries with identical names. Click to see larger image.
So now we see the Find Your Library system finding data that libraries aren’t seeking! Sure, the system works technically since it retrieves the desired library’s data. But, the data for the 3 Akron Public Libraries in Alabama, Colorado, and Iowa are inextricably linked. The system will not allow these libraries to be retrieved and displayed separately. This means that Akronites wanting to view their data must visually block out data rows for the other Akron libraries. As must any other libraries whose names match other U.S. libraries (see below).
This system behavior may not seem like a big deal, but it is. As Alan Cooper observes in his 2004 book, The Inmates Are Running the Asylum, computer systems can be callous and degrading towards users. In the case of duplicate library names, the application simply decrees that these libraries do not merit a separate listing of their data. Nowadays most of us have become desensitized to the inconveniences and offenses that technology subjects us to so that we just shrug them off. But, it is disrespectful to libraries to expect them to view their data intertwined with other libraries’ data.
Besides, the impact of this searching defect is greater than one might expect. In the 2014 PLS datafile there are 1,320 libraries who share identical names with other U.S. libraries. That’s 14% of the libraries in the file. The most notable matching name is Oxford Public Library shown here:
Either the Find Your Libraries programmers didn’t do enough digging into the PLS data or they did not understand how libraries search for data. Which raises the question, what made this search result seem like a good idea in the first place? Or who, when they saw this behavior during testing, did not wonder about its purpose? When a pointless feature like this appears in a technology product, you know the design method fell short.
The system’s single search term restriction also causes problems in the Explore Library Outlets option. To see this, first we need to confirm something using the Explore Library Systems search. Note in the image below that when I typing multnomah in the LIBRARY NAME search field the system displayed a drop-down menu containing a single item, Multnomah County Library (see red arrow):
Explore Library Systems search using the term multnomah. Click to see larger image. See footnote
The system locates the library based on the first word of its name. When I clicked on that single name listed in the menu, the system displayed Multnomah County Library’s data as shown here:
Explore Library Systems page showing Multnomah County Library data. Click to see larger image.
So we’ve confirmed that the search term multnomah will get us to Multnomah County Library’s data. Next, going to Explore Library Outlets and using the same search term in the LIBRARY NAME search field (see red arrow), I got this display:
Explore Library Outlets page showing Multnomah County Library outlets were unfound. Click to see larger image.
For some reason the Explore Library Outlets page layout differs from the Explore Library Systems. (I’ll discuss the system’s unexplained layout changes in another post.) Nevertheless, the search area still appears at the top left. The No data found matching your search term message (see blue arrow) indicates that the application could not find library outlets (branches and/or bookmobiles) based on the same search term I used on the Explore Library Systems page (see red arrow). The application thinks that Multnomah County Library has no branches. Interesting, since this large Portland, Oregon library system has 19 branches.
Here’s the reason for this technical mishap: Despite the label LIBRARY NAME in the Explore Library Outlets search field, the system actually searches by outlet name.5 Therefore, users seeking branches or bookmobiles must know their exact names. Further, the main library’s name will only work for those libraries, with or without branches, that are listed as outlets in the outlet datafile. This means that the Finding Your Library application cannot reliably retrieve all outlets associated with a main library (library system). Again, these data can only be found if users know each outlet’s official name. Another oversight in a tool ostensibly designed to find library data.
It’s amazing how quickly this system can switch from a not finding data libraries are seeking mode into a finding data that libraries aren’t seeking mode. If the library happens to share the same branch (outlet) name with other U.S. libraries, the Explore Library Outlets search retrieves multiple outlet records, just as we saw in Explore Library Systems. I found a way to trick the tool (which I won’t take time to share right now) into showing me Multnomah County Library’s branch names. I used one of these names, Capitol Hill Library, in the Explore Library Outlets search field. Here’s what the system retrieved:
Explore Library Outlets search that retrieved 2 outlets with identical names. Click to see larger image.
Searching for Multnomah County Library ‘s Capitol Hill branch also retrieved the Capitol Hill branch from Oklahoma’s Midwest City Library! Fun, huh? Although the Explore Library Outlets page has a separate search area for the term COUNTY, the system does not permit users to search on LIBRARY NAME and COUNTY at the same time. Being able to search on these would alleviate this problem.
This deficiency and those I already described make it clear that the IMLS Find Your Library tool’s single search term design is a mistake. It prevents libraries from getting access to the information they’re seeking. Libraries need to be able to qualify their searches with other terms, at least by COUNTY and STATE when searching library systems, and LIBRARY NAME, FSCS ID, and COUNTY when searching outlets. The FSCS ID search term should retrieve all outlet records associated with a main library. Designers would need to figure out how a search by LIBRARY NAME should work.
Finally, we ought to look at how PLS data are presented once they’re found. As seen in some of the images above, each library’s data are displayed in the large window at the right, in a row (or rows) of 7 to perhaps 9 columns. There are more than 80 data items in the PLS library systems datafile. So, users must scroll right to see the rest of these. I’ve captured a few images of this process shown below. The top window segment shows how the data are displayed initially, the 2nd, after scrolling 1 click to the right, and the 3rd, after scrolling to the far right:
3 horizontal segments of New Baden Public Library’s PLS data (see narrative above). Click any window/segment to see larger image.
Having the data strung left to right in a limited space and an arbitrary order is too cumbersome. Those seeking one or two PLS data item values may find this workable. But users needing to view multiple items, or compare a specific data item with others, are forced to scroll back and forth repeatedly.
Besides the horizontal layout, other aspects of the display make viewing the data difficult. Users may not be bothered by the inverse (white on blue) font in the column headings, or the pale font of the data values (see image above). But these low-visibility design choices take a toll on users’ eyes when combined with the display’s other anomalies. For instance, users must beware of how column headings can extend outside the display, making them easy to miss or misread as shown here:
Column headings can be inadvertently clipped . Click to see larger image.
Roughly 35 years ago personal computer spreadsheet software had avoided this design flaw. But here we see it re-introduced in the 21st century data digging programming platform which the Find Your Library application was built with upon.
Another anomaly is how columns are unevenly spaced across the data row. This irregularity is because the system sizes columns based on heading text or data values, whichever are wider. Besides this, inconsistent alignment of the data values themselves adds to the visual confusion. Note in the above image how some data values are right-aligned and others left-aligned. Another design detail to keep users on their toes!
It would have helped users to render the data columns in darker text on a light background. And to replace the white and blue headings with a simple underline across the entire row. Also, bolder vertical column delimiters would make it easier for users to tell where the irregular columns begin and end.
Returning to the earlier image of 3 horizontal window segments, the data appear left-to-right roughly in the order they appear in the PLS datafile. The datafile begins, first, with items pertaining to library identification (name, address, county), community characteristics (library type, population counts, geographic type), and service outlets. Followed by a trove of items describing library inputs and resources (staffing, revenues, expenditures, collection counts such as print volumes, databases, eBooks). Next, multiple output measures describing services provided (visits, circulation, programs, electronic usage). And finally miscellaneous administrative items (geographical region, locale type).
The PLS datafile documentation contains headings denoting this order, a helpful addition that is missing from the Find Your Library display. With this display users have to know the data order intimately to determine where the items they seek might be. All the time dealing with the display difficulties just described.
Designers did make minor changes to the data order. Note in the top window of the image above that the STATE column tells us New Baden Public Library is located in Illinois. However, to see the library’s city we have to scroll to the far right at least 10 clicks.
This is the only software I have ever seen where the city field is so disassociated from the state field! Of course, geospatial coordinates are the thing nowadays. City names are totally passe when you can get an up-to-the-minute satellite photo of the location! Accordingly, the designers assume that users only need a city name on those rare occasions when they want to send snail mail to the library. In the PLS datafile documentation the city field is labeled CITY. However, in their application the designers re-named CITY as MAILING CITY. A mis-classification, perhaps, for small towns and villages where a mailing address city can differ from the actual name of the town or village.
Another instance of misunderstood user needs. Locating CITY and COUNTY next to LIBRARY NAME and STATE would enable users to confirm which library they retrieved. Did they accidentally retrieve Alameda County Library in Fremont, CA instead of Alameda Free Library in Alameda, CA? To answer the question definitively users have to traverse 10+ clicks to the right where the ADDRESS, CITY, and COUNTY fields have been shifted.
Data arrayed in wide rows, as in spreadsheets, have advantages (comparing nearby rows, sorting and filtering, copying and pasting) and disadvantages (back-and-forth scrolling, accidentally skipping over data, inability to compare distant columns). But in the Find Your Library display users get all of the disadvantages with none of the advantages. The diving/hacking/digging programming platform that the IMLS tool is built on (as is the IMLS Data Catalog) insists that users view their data the way computers have organized them. Then the IMLS designers make things worse by shrinking the data display to make room for irrelevant content, the map and interactive graphs. (On a tablet or smartphone the data display is ridiculously cramped. I’ll show some of the displays in a later post.)
I’m sorry. I cannot see how this new application is an improvement in any way. I admit to outright nostalgia, of course. The earlier version of the Find Your Library tool was so much better. That version had an intuitive user interface, readable screens, and coherently arranged data. Plus, in those days they had the quaint practice of displaying only those items which users requested when specifying their initial search. Probably a bit boring for 21st century distraction-driven users. But these features did save time and seemed to prevent mistakes. And generally met users needs effectively.
Speaking of distractions, look for my next post where I’ll review Find Your Library’s extra data-diving attractions.
1 Cooper, A. About Face: The Essentials of Interaction Design, 4th ed., 2014, 6-7.
2 Poor user interface design won’t be news to technology users everywhere. WordPress, which boasts “running 27% of the Internet,” is a case in point. It is full of time-wasting and inane features. Like the auto-save: When the internal timer that periodically saves my document to the cloud encounters a problem, the application jerks me away from my work and flashes a bright red marquee in my face, bemoaning the fact that this calamity has occurred. (Does my document need to be saved every 10 seconds?) No excuse me’s or I beg your pardon’s. Leaving me to find my way back to where I was typing. Weirdly, when I preview a post, the software displays this bizarre phrase while it’s formatting my document: Beep beep boop. I’m not kidding! Having 27% of the Internet powered by these people is a scary thought!
3 The 5th option is misnamed, as it doesn’t provide any further detail than is available via the other options. All of these lead to the level of detail found in the PLS datafiles. This 5th option provides the same data in different formats and groupings.
4 In some device displays the bottom of the map may extend below the bottom edge.
5 In the PLS outlets datafile this data item is simply labeled Name.