How not to Design a Library Book-Return Robot

Twitter Updates


San Francisco PechaKucha Night
San Francisco IxDA


I’m a geek, and I love technology—especially anything that automates boring, repetitive tasks. So I should be a huge fan of the barcode-scanner wielding, German-engineered book-return robot that the Foster City library installed a few years ago.


It’s way too slow, confusing, and unreliable.

Signage and Instructions

The most visible telltale of any poorly designed object or user interface is when it starts sprouting after-the-fact documentation.

For instance, there are tons of laminated letter-sized paper signs taped up at the Millbrae BART/Caltrain station, directing you where to go for particular trains. What? The expensive fixed and programmable signs designed into the station weren’t enough? Bad architect—no vino!

In the case of these robots, there are three additional laminated paper signs (and the most important are now fading—I would have hoped the librarians knew of UV-proof ink) on each of the machines. The etched-in text on the stainless steel and the programmable 19-inch color touchscreen weren’t enough? Bad designer—no martini!

Make the Right Customer Happy

The more egregious problem is that the library management who selected the technology vendor apparently thinks that the customer they were serving was the library staff.

Wrong. The customer they need to make happy is the library patron. Automating the sorting for the library staff is a nice secondary benefit. It’s an important benefit, but one that cannot be realized unless you solve the primary task of getting the patrons to use the fancy machine.

To accomplish this, the solution needs to have these properties:

  • Be easy to use
  • Be reliable
  • Be fast
  • Be better than the old method

But the extra signage shows these book robots are not easy to use. And while barcodes have been used in grocery stores for many decades, with an exceedingly low mis-scan rate, these machines are able to recognize barely one in ten of the books I present to them.

The requirement to scan books one-by-one combined with the high reject rate results in a system that is neither reliable nor fast.

And that combination makes it frustrating for the patron and worse than the old method. The only advantage for the patron is that if he or she puts up with these problems, they can get a return receipt when the library is closed.

The old method is still superior in all regards, for the patron at least.

  • I can drop a stack of books on the librarian’s desk, and ask for a return receipt.
  • The librarian might complain and point me to the machine outside, but will grudgingly give up and scan the books and issue the receipt—faster and with fewer errors than the machine.
  • Even with the complaining and pointing, the process is faster than using the machine. And doing it inside is much nicer, too.

Nothing about the new process is better than the old one, except for the after-hours return receipt.

And because the typical library patron response to this is to give up on the machine and use the manual book drop or pester the librarian, it’s not really better for the library staff, either.

Why Did This Fail?

The question of why is easy to answer. The library management viewed their customer as their staff, not their patrons.

The how is more interesting. Without having been involved in the selection, installation, and check-out, I can only base my conclusions based on external observation, my knowledge of barcode scanners, and a little bit of testing (on the order of 15 minutes worth).

During the installation, I was a frequent visitor to the library. The installation and check-out took far longer than the library had stated. From my vantage point, watching the Germans tweak the installation over the course of a month or two, it seemed likely to me that there were very few of these systems in existence, and that the library likely purchased a system that was still in development, or was built by a company that’s just not quite competent enough.

The components of this process barcode scanning, conveyor belts, and computer-driven sorting) are such old and established technologies that it should have been easy to find a ocmpany already expert at this.

Given these observations, I naturally expected that the fundamental problems with scanning resulted from politics and bad communication between the vendor and the library staff, and the acceptance process being different than real-world conditions.

You see, the barcode label for every book is protected by a layer of plastic. A shiny, glare-reflecting dust jacket on hardcover books, and a self-laminating covering on softcover books.

Acting on a hunch that the old-fashioned laser barcode scanners were having difficulty with the reflective covering over the barcodes, I roughed up the covering over several book barcodes with a ceramic nail file. But there was no improvement.

Perplexed, I decided to generate and print my own replacement barcode for one book. The library uses CODABAR—an old, simple code created by Pitney-Bowes. A few minutes on a barcode-generating webiste, and I was off to the library to test my theory.

But I fared only marginally better than with the real book, so something else was obviously wrong.

The Right Perspective Reveals All

Given the nature of how the books need to be held up to the outside scanner (the right side of the above picture), I had assumed the unit contained a modern multi-axis laser barcode scanner. These are standard issue at checkout stands across the globe, and use spinning mirrors or holograms to project a bird’s-nest of scan lines across the target area, to ensure quick reliable scanning, no matter the orientation of the object being scanned.

But that’s not what these book robot engineers used.

They used an old-fashioned, single-line scanner. One that requires the barcode to be placed precisely under the projected scanline. The scanline the library patron can’t see because the book is between the scanner and his eyes. (Thank God for that, since it is a laser!)

As soon as I discovered this, and held my books at an angle matching the scanner head, and made sure the laser line covered the barcode, my scan success rate and speed jumped up to what you’d expect from a grocery checkout line of 30 years ago.

The Problem Lies Deeper

But that’s just the first scanner.

Once you scan the book to open the magic door and place the book on the conveyor belt, there is a second barcode scanner that attempts to find the code.

Again, my success rate is miserable, and I resort to using the manual book drop. Again, there is an old-style single laser line scanner tucked inside.

If you feed more than one book at a time, and the first book is rejected, the machine chides you for not following the rules, and spits them all back out at you. Not nice.

This is not rocket science, it’s barcode scanning!

The solution is fairly straightforward. Rip out the linear laser barcode scanners, and replace them with multi-axis laser or image-based scanners, and test the system against a good cross-section of library materials before accepting (and paying for) the fixes from the vendor.

Oh, and hire new executive staff for the library. Preferably people who have run profitable businesses, instead of government bureaucracies/cost-centers.

Author: Peter Sheerin

Peter Sheerin is best known for the decade he spent as the Technical Editor of CADENCE magazine, where he was the acknowledged expert in Computer-Aided Design hardware and software. He has a long-standing passion for improving usability of software, hardware, and everyday objects that is always interwoven in his articles. Peter is available for freelance technical writing and product reviews, and is exploring career opportunities in interaction design. His pet personal project is exploring the best ways to harmonize visual, tactile, and audible symbols for improving the effectiveness of alerting systems.

Leave a Reply