Anti-Choice (or Pro-Simplicity) is Nice When You Can Get It

We’re knee-deep in our MetaLib implementation project, and as we do our best to make decisions about our interface, we keep removing all the extra links and options and tabs that clutter up the default interface. Do we really need two different ways to get to the database list? Do we really need both Simple and Advanced Search options when the Advanced search only adds one search box to the already existing search box? Do we really need a button to switch languages when we only have an English interface? Little by little we try to strike a balance between simplicity and function. One by one, buttons and options and tabs disappear and the interface starts to make a little more sense.

Then, today, I watched a TED talk in which Barry Schwartz talks about his theories about how increased choice does not, in fact, make for better decision-making outcomes. Apparently greater choice means (unsurprisingly) more brain time spent making decisions, but even beyond that it raises our expectations that the outcomes will be wonderful. When the outcome is just good and not absolutely amazing, we’re more easily disappointed now that our expectations have been raised. So while our decisions may actually be better, we’re less happy. If you want the long version of these theories, he has a whole book out: The Paradox of Choice. (Also, if you watch the TED talk you’ll notice at about minute 6:10 that even TED people don’t get wifi at their conference hotel. This makes me feel just a teensy bit better about every conference I’ve ever been to. But I digress.)

Being a librarian with search interfaces on the brain, I couldn’t help but think about all those calls for beautiful, simple, Google-like, single search boxes. It’s not a perfect analogy, but in both cases people hope that by reducing options, the experience will be improved. With the single search box, there’s never any doubt what you’re supposed to do or how to do it at least minimally effectively. It’s such a wonderful goal.

But there’s a catch. The simpler the interface is, the more powerful the behind-the-scenes mechanisms have to be. They have to do more interpretation of search terms, smarter retrieval, more robust relevance ranking. If I can’t specify how things should look when I’m done searching, then things had better be done in a way I would have anticipated to begin with or I’ll get frustrated with the lack of options to “fix” my results. Google didn’t get famous because it had a single search box. It got famous because that single search box yields consistent results based on an algorithm that’s incredibly complex and equally secret.

So while I’d love to be able to reduce our interface down to just a couple of well-chosen elements, we still have to compensate for the fact that the behind-the-scenes mechanisms just aren’t up to that kind of challenge. And so we’re left doing our balancing act: how much can we strip away in the interests of removing excess choice, and how much do we have to leave so that people can manipulate the system enough to get it to spit back results they can use.

5 thoughts on “Anti-Choice (or Pro-Simplicity) is Nice When You Can Get It

  1. Hi – We’re doing something similar, but with Webfeat. Are you working with the Metalib API to make your changes? I’m asking because Webfeat isn’t that customizable out of the box and we may have to.

    Thank you for the reference to the Barry Schwartz talk, that’s great food for thought.

    Along those lines, do you have any thoughts on the most usable way to do popup windows (as with SFX or another OpenURL system)? I’m finding that people find that so confusing, yet haven’t figured out the best solution.


  2. That reminds me of a cartoon I saw a while back. User stands in front of a bewildering array of choices in the shop window and says: “Don’t make me choose from what you’ve got, let me tell you what I want.”

  3. Happy New Year, CW. :)

    Ellie, we’re going to be taking a look at our SFX menu after we finish this MetaLib project. We’re pretty sure we haven’t come up with the most usable way to implement that, but we haven’t quite figured out what would be better. If you come up with a solution, please let me know!!

  4. Iris, when your library starts looking at your SFX menu, would you write about it here? I’d love to see what you and others are doing with the design and wording of the options that SFX presents to the user. I *know* that we’re not doing a good job with ours, but I’m at a loss as to what would be better, and by definition we can’t look at other libraries’ implementations.

    Getting back to your original post, I see your point about our systems not being as “smart” as Google (yet), but I also think that the kinds of information that our systems are trying to retrieve and present to the user are more complex than what’s in Google. Like for example, there are times when you really want your search results sorted by relevance, and other times when you really want them sorted by date, and only the user is going to be able to articulate which is which.

Comments are closed.