Monthly Archives: April 2004

Breadcrumb navigation

There has been a fascinating discussion among information architects and web designers about the usefulness of breadcrumb trails. Mark Hurst of Good Experience talks about the page paradigm, Peter Merholz mostly disagrees, and Christine Wodtke offers her two cents. Here’s part of what Steve Krug had to say about the topic in his book, “Don’t Make Me Think”:

“For most sites, I don’t think Breadcrumbs alone are a good navigation scheme. They’re not a good replacement for showing at least the top two layers of the hierarchy, because they don’t reveal enough. They give you a view, but it’s like a view with blinders. It’s not that you can’t make your way around using just Breadcrumbs. It’s that they’re not a good way to present most sites.

“Don’t get my wrong. Done right, Breadcrumbs are self-explanatory, they don’t take up much room, and they provide a convenient, consistent way to do two of the things you need to do most often: back up a level or go Home.”

Mark might argue that “back up a level” is more often accomplished with the browser’s back button, eliminating one of the points above. (Although the book actually has a whole chapter on this stuff, to be fair to Mr. Krug.)

Yesterday, Andrei Herasimchuk wrote that navigation doesn’t actually exist. Instead, he argues, there are only ways of finding things, and some of them have nothing to do with conveying the user’s position. He does a good job of framing the different needs of large collections of web pages vs. web applications. Clearly there is a “where am I” to hierarchical sets of data. Users feel as if they are moving between pages that have relationships, and making those relationships clear in the interface (via category lists or breadcrumb trials) minimizes how much the user is required to think about where they are, and how to get someplace else.

Amazon, on the other hand, is a web application. While there are clear navigation elements (browsing category pages, or using the primary navigation to jump between books and DVDs), most of the time the user doesn’t get lost because they aren’t moving. Instead of saying “I am on the search results page”, they might say “I am searching for a book”. The experience is dominated with tasks: “I’m adding something to my shopping cart”, “I’m buying this book”, “I’m changing my credit card information.”

Or maybe they are just randomly clicking on featured products. It all feels effortless to the user because Amazon has done such a great job with their search and recommendation system.

Brenda Laurel gave an interesting keynote address at SXSW Interactive this year, one which I have trouble summarizing in any meaningful way, and thankfully has nothing to do with this discussion. But a dozen years earlier, she edited a compilation of essays on user interface design from the perspective of the teams at Apple. The book is called “The Art of Human-Computer Interface Design”, and one essay by Abigail Sellen and Anne Nicol hits to the heart of this issue of navigation. Here’s a snippet:

“The number of questions concerning navigation is very much application-dependent. Typically they arise most frequently with applications that are structurally complex and that contain a large amount of information. Hypertext-based software is one obvious example; hierarchically structured systems are another. Users tend to make heavy use of spacial metaphors: they report feeling ‘lost,’ speak of going ‘up’ and ‘down’ between levels or going ‘in’ and ‘out’ of situations.

“Users often spontaneously construct spacial mental models or mental ‘maps’ in order to move easily from one context to another. This has obvious implications for design. Reducing the memory lead on the user is one benefit of making these mental ‘maps’ explicit. Users can refer to the map instead of trying to retrieve information from memory to tell them ‘where they are.’ Another benefit is that a map can form the basis of a mental model on which the user relies to infer how to get from point A to point B without having to keep in mind a set of procedures for navigation. Thus, by exploiting spatial metaphors and allowing the user to make the inference, designers can help users avoid having to ask the question, ‘How do I get from point A to point B?’”

Good points to think about. Instead of attempting to wrap this up with some insightful comment, I’m going to go build stuff.

Usable software, and just shipping it

A few loosely connected weblog posts I read today…

John Gruber, “Ronco Spray-On Usability”:

“UI development is the hard part. And it’s not the last step, it’s the first step. In my estimation, the difference between:

  • software that performs function X; and
  • software that performs function X, with an intuitive well-designed user interface

isn’t just a little bit of extra work. It’s not even twice the work. It’s an entire order of magnitude more work. Developing software with a good UI requires both aptitude and a lot of hard work.”

Rick Roe, “The Good, the Bad, and the Tog”:

“The whole point of graphical user interfaces is that they balance efficiency with intuitiveness. An intuitive interface may make some tasks take longer to complete than they could in an interface designed for maximum efficiency, but you can learn it on the spot instead of having to take time digging through documentation.”

Andre Torrez, “Even You Can Do It”:

“Stop talking about it an just build it. Don’t make it too complicated. Don’t spend so much time planning on events that will never happen. Programmers, good programmers, are known for over-engineering to save time later down the road. The problem is that you can over-engineer yourself out of wanting to do the site.”