Brian’s comment at RemainingRelevant should resonate with many of us:

Something to consider about why libraries end up with bad interfaces (at least as far as catalogs go) is that it might be that the people who use the interface (and help the public use it) are not the people who decide which interface to use.

When it comes to demanding better from vendors [...] consortiums like mine seem to place more emphasis on “cheap and reliable” than in “useful to the patrons.”

More than identifying individual vendors, I’d like this to be a discussion about our decision making processes. Let’s look carefully at how we got here — not to point fingers (for we are all responsible), but to plot a path out and try to make sure we never find ourselves here again.

As Karen points out: it’s not enough to nod our heads in a knowing sigh, “the genius moment for you or anyone else will be figuring out what to do with it!”

It’s corny, but I’m serious. If you’ve taken the pledge, you’ll know to look skeptically at every product. You’ll ask yourself and a mix of likely users how it could be better. And you won’t buy anything or renew any contract on anything that sucks. There is no consortium, no institution that can afford to throw away money on products that can’t deliver the ease of use and quality of experience that users expect from competing (and more familiar) tools elsewhere on the internet.

The real challenge, of course, is making sure everybody involved with every decision-making process understands this.

compare, decision, decision making, market, market forces, process, software, suck, sucks, sucky, the pledge, training, usability, vendors

A: Because we compare them to the wrong things.

I’m in training today for a piece of software used in libraries. It’s the second of three days of training and things aren’t going well. Some stuff doesn’t work, some things don’t work the first (second, third…ninth) time, and other things just don’t make sense. At lunch, one of the other participants mentioned to the trainer that some of the activities in the software seemed to have too many steps, too many places to go wrong, too many turns between beginning and end.

The answer began by explaining that the most analogous activity would be the acquisition of books for the collection. Adding a book to the collection requires first identifying the book, reading the reviews, choosing to purchase, identifying a vendor and cost, identifying funding, ordering, receiving, cataloging…

The list went on, perhaps with too much detail, but it landed on the following: “there are at least 12 steps to just putting a book on the shelf. When you think about it like that, our software is easy.”

I bit my tongue at that moment, but I’ve been grinding my teeth about it since.

Here’s what’s eating me: You can compare one unlikable thing to any other unlikable thing and come out ahead, but what about “real-world” comparisons?

Paul Graham explains in his “Hardest Lessons For Startups To Learn” essay that developers often compare themselves to the wrong things, misunderstanding who their competition is:

A lot of startups worry “what if Google builds something like us?”

What you should fear, as a startup, is not the established players, but other startups you don’t know exist yet. They’re way more dangerous than Google because, like you, they’re cornered animals.

Looking just at existing competitors can give you a false sense of security. You should compete against what someone else could be doing, not just what you can see people doing. A corollary is that you shouldn’t relax just because you have no visible competitors yet. No matter what your idea, there’s someone else out there working on the same thing. (emphasis added)

Graham is talking to startups, but switch some words around and you’ll get my message: if you compare yourself to something that sucks, you’ll only be able to say you’re more or less sucky.

A better comparison for this product would have been against flickr, where activities that are closely analogous to those in the software we’re being trained on often require only one step. And taking Graham’s advice, the best way to approach it would be constantly ask “can we do this better?” “Could a competitor we don’t yet know about do this better?”

(Aside: social software is that which gets spammed, that which gets you laid, and that which you’ll need no training on.)

Please, stand with me now and repeat:

When something sucks I will say so. When vendors spout crap I will call them on it. My staff deserve good tools, my users need good tools, and I can’t afford to buy stuff that sucks.

Together, we’ll fix the world one product at a time.

bad answers, compare, comparison, competition, crap, developers, development, failure, future libraries, lib20, libraries, library 2.0, software, startups, suck, sucks, sucky, training, vendors