Breadcrumbs are Evil

I've been on a few projects where I've had to mess with breadcrumbs and they tend to be much more trouble than they're worth. It all starts simply enough: put the users path through the app on the page. Which isn't too hard.

Then the bugs come.

Like: "This page is linked to from page A but it really is more of a child of page B so the breadcrumbs should show page B and not A even if they come from A"

Or: "When I come to page X from the search on the front page it should have breadcrumbs with Y and Z because that's really what it's under."

And: "Page L is listed under K but should be under M (followed a few days later by) Page L is listed under M but should be under K"

Oh, you want a hierarchy. Which is hard.

First: There's now a new job to be filled: Taxonomist. Somebody is going to have to figure out where all the pages in the app fit in some sort of tree. And this list must be maintained.

Second: There must be code that manages all this. And since there are always exceptions to the rules of hierarchy it can get quite complicated.

Third: Although your customers don't really care where the page fits in the hierarchy, everyone else in the business does. A lot. So much so that there will be many (perhaps endless) arguments about exactly where things "belong."

All this will take plenty of time that could be used doing something that, you know, your customers may actually need. I guess I really don't have too much problem with "true" breadcrumbs (aside from the fact that I never use them and they're kind of a relic from the days of "Wow the internet is so complicated people will get lost!" and they can probably be replaced with a good search box) but what I really hate is when they act as a gateway drug to hierarchy.


Jeremiah said…
Truthfully, if you involve an Information Architect at the start of a project to build a proper taxonomy and site structure, you tend not not run into these problems. Yes, it's another body to have to pay but the benefits of a competent IA far outweigh the costs. Plus, you can make the IAs fight the good fight on organizing a site properly so that breadcrumbs aren't necessary at all.
reborg said…
I recently worked with breadcrumbs in the Radiant CMS. That was an easy situation: the CMS is hierarchical and breadcrumbs were just following were the page was in the tree. No hassle for the programmer. So the tree was implicitly maintained by who was managing the content. But I agree with you: if there are exceptions maybe tagging is a better solution. All the business people can be accommodated when there is no common agreement on the hierarchy: put another tag. I also agree on the fact that too much time spent on breadcrumbs is a bad smell: poorly designed web site or an upgrade to a tagging system required.
Anonymous said…
breadcrumbs work great for browsing product catalogs or for sites like ebay when searching for things to buy within obvious predefined groups.

that's about the only time I use them. that and sometimes large project wikis.
jeroen said…
it's important to understand that there are multiple "versions" of breadcrumb navigation

I personally think the the "path" version suits the term breadcrumb best. And I think it's quite a useless feature since you can just use your back button
Thiago Freire said…
I agree with you. Tags, tag clouds (or lists) and a search box are a more powerful combination.

About the Wikipedia article:
Nobody needs the Path version. The browser already has this. The Location is the most common, and totally sucks. And the Attribute uses tags (or categories). That's useful. A lot of blogs have this below the post title.

Popular posts from this blog

Point Inside a Polygon in Ruby

What's a Good Flog Score?

SICP Wasn’t Written for You