The problem with breadcrumb trails

The other day I was chatting with some of the designers at work about secondary navigation and the subject of breadcrumb trails came up. Breadcrumb trails are those bits of navigation summed up by Jakob Nielsen as:

a single line of text to show a page’s location in the site hierarchy. While secondary, this navigation technique is increasingly beneficial to users.

and illustrated on Wikipedia by:

Home page > Section page > Subsection page

For reasons which will hopefully become clear the whole subject of breadcrumb trails vexes me and rather than shout into Twitter I thought I’d type up some thoughts so here goes.

Types of breadcrumb trail

There are 2 main types of breadcrumb trail:

  • path based trails show the path the user has navigated through to arrive at the current page
  • location based trails show where the page is located in the ‘website hierarchy’

Both of these are problematic so let’s deal with each in turn.

Path based breadcrumb trails

The first thought most people have when confronted by the concept of a breadcrumb trail is Hansel and Gretel. In the story the children were led into the forest and as they walked dropped a trail of bread crumbs. The intention was to retrace their steps out of the forest by following the trail of breadcrumbs (at least until the birds ate them).

The important point is that Hansel and Gretel weren’t conducting a topographical study of the forest. The trail they laid down was particular to their journey. If Alice and Bob had been wandering round the same forest on the same day they might have left a trail of cookie crumbs or even traced out their journey with string. The 2 journeys might have crossed or merged for a while but each trail would be individual to the trail maker(s).

The path based breadcrumb trail is the same principle but traced out in pages the user has taken to get to the page they’re on now. So what’s wrong with that?

If you’re a user experience person you’ve probably heard developers talking about REST and RESTful APIs and possibly thought REST was just techy stuff that doesn’t impact on UX. This would be wrong. From a developer point of view REST provides an architectural style for working with the grain of the web. And the grain of the web is HTTP and HTTP is stateless.

So what does that mean? It means when you ask for a page across the web the only data sent in the request is (HTTP) get me this resource and a tiny bit of incidental header information (what representation / format you want the resource in – desktop HTML, mobile HTML, RSS; which languages do you prefer etc). When the server receives the request it doesn’t know or need to know anything about the requester. In short HTTP does not know who you are, does not know ‘where’ you are, does not care where you’ve come from.

There are various reasons given for this design style; some of them technical, some of them ethical. As ever the ethical arguments are far more interesting so:

The Web is designed as a universal space. Its universality is its most important facet. I spend many hours giving talks just to emphasize this point. The success of the Web stems from its universality as do most of the architectural constraints.

is my favourite quote from Tim Berners-Lee. It’s the universality of the web that led to the design decision of stateless HTTP and the widespread adoption of REST as a way to work with that design. Put simply anybody with a PC and a web connection can request a page on the web and they’ll get the same content; regardless of geographic location, accessibility requirements, gender, ethnic background, relative poverty and all other external factors. And it’s the statelessness of HTTP that allows search bots to crawl (and index) pages just like any other user.

You can of course choose to work against the basic grain of the web and use cookies to track users and their journeys across your site. If you do choose that route then it’s possible to dynamically generate a path based breadcrumb trail unique to that user’s navigation path. But that functionality doesn’t come out of the box; you’re just giving yourself more code to write and maintain. And that code will just replicate functionality already built into the browser: the back button and browser history.

It’s possibly also worth pointing out that any navigation links designed to be seen by a single user are not, by definition, seen by any other user. This includes search bots which are to all intents and purposes just very dumb users. Any effort you put into creating links through user specific path based breadcrumbs will not be seen or followed by Google et al so will accrue no extra SEO juice and won’t make your content any more findable by other users. Besides which…

…it’s really not about where you’ve come from

One of my main bugbears with usability testing is the tendency to sit the user down in front of a browser already open at the homepage of the site to be tested. There’s an expectation that user experience is a matter of navigating hierarchies from homepage to section page to sub-section page to content page. If this were true then path based breadcrumb trails might make some sense.

But in reality how many of your journeys start at a site homepage? And how many start from a Google search or a blog post link or an RSS feed or a link shared by friends in Facebook or Twitter. You can easily find yourself deep inside a site structure without ever needing to navigate through that site structure. In which case a path based trail becomes meaningless.

In fairness Jakob Neilson points out pretty much the same thing in the ‘Hierarchy or History’ section of his post:

Offering users a Hansel-and-Gretel-style history trail is basically useless, because it simply duplicates functionality offered by the Back button, which is the Web’s second-most-used feature.

A history trail can also be confusing: users often wander in circles or go to the wrong site sections. Having each point in a confused progression at the top of the current page doesn’t offer much help.

Finally, a history trail is useless for users who arrive directly at a page deep within the site.

All this is true but it’s only part of the truth. The real point is that path based breadcrumb trails work against the most fundamental design decision of the web: universality through statelessness. By choosing to layer state behaviour over the top of HTTP you’re choosing to pick a fight with HTTP. As ever it’s best to pick your fights with care…

Location based breadcrumb trails

In the same post Jakob Neilson goes on to say:

breadcrumbs show their greatest usability benefit [for users arriving directly at a page deep within a site], but only if you implement them correctly – as a way to visualize the current page’s location in the site’s information architecture. Breadcrumbs should show the site hierarchy, not the user’s history.

But what’s meant by ‘site hierarchy’?

Hierarchy and ‘old’ media

Imagine you’re in proud possession of a set of box sets of Doctor Who series 1-4. Each box has 4, 5 or 6 DVDs. Each DVD has 2 or 3 episodes. Each episode has 10 or so chapters:

This structure is obviously mono-hierarchical; each thing has a single parent. So the chapter belongs to one episode, the episode is on one disc, the disc is in one box set. It’s the same pattern with tracks on CDs, chapters in books, sections in newspapers…

With ‘old’ media the physical constraints of the delivery mechanisms enforce a mono-hierarchical structure. Which makes it easy to signpost to users ‘where’ they are. An article in a newspaper can be in the news section or the comment section or the sport section or the culture section but it’s only ever found in one (physical) place (unless there’s a cock-up at the printing press). So it gets an appropriate section banner and a page number and a page position.

But how does this map to the web?

Files and folders, sections and subsections, identifiers and locations

The first point is people like to organise things. And they do this by categorising, sub-categorising and filing appropriately, dividing up the world into sets and sub-sets and sub-sub-sets… Many of the physical methods of categorisation have survived as metaphors into the digital world. So we have folders and files and inboxes and sent items and trash cans.

In the early days of the web the easiest way to publish pages was to stick a web server on a Unix box and point to the folder you wanted to expose. All the folders inside that folder and all the folders inside those folders and all the files in all the folders were suddenly exposed to the world via HTTP. And because of the basic configuration of web servers they were exposed according to the folder structure on the server. So a logo image filed in a folder called new, filed in a folder called branding, filed in a folder called images would get the URL /images/branding/new/logo.jpg. It was around this time that people started to talk about URLs (mapping resources to document locations on web servers) rather than HTTP URIs (file location independent identifiers for resources).

Obviously file and folder structures are also mono-hierarchical; it’s not possible for a file to be in 2 folders simultaneously. And the easiest and most obvious way to build site navigation was to follow this hierarchical pattern. So start at the home page, navigate to a section page, navigate to a sub-section page and navigate to a ‘content’ page; just as you navigate through folders and files on your local hard drive. Occasionally some sideways movement was permitted but mostly it was down, down, up, down….

Many of the early battles in Information Architecture were about warping the filing systems and hierarchies that made sense inside businesses into filing systems and hierarchies that made sense to users. But it was still about defining, exposing and navigating hierarchies of information / pages. In this context the location based breadcrumb trail made sense. As Neilson says the job of the location based breadcrumb trails is to show the site hierarchy and if you have a simple, well-defined hierarchy why not let users see where they are in it? So location based breadcrumb trails make sense for simple sites. The problem comes with…

Complex sites and breadcrumb trails

Most modern websites are no longer built by serving static files out of folders on web servers. Instead pages are assembled on the fly as and when users request them by pulling data out of a database and content out of a CMS, munging together with feeds from other places and gluing the whole lot together with some HTML and a dash of CSS. (Actually, when I say most I have no idea of the proportions of dynamic vs static websites but all the usual suspects (Amazon, Facebook, Twitter, Flickr etc) work dynamically.) Constructing a site dynamically makes it much easier to publish many, many pages; both aggregation pages and content pages. The end result is a flatter site with more complex polyhierarchical structures that don’t fit into the traditional IA discipline of categorisation and filing.

The problem is wholly contained sets within sets within sets are a bad way to model most things. Real things in real life just don’t lend themselves to being described as leafs in a mono-hierarchical taxonomy. It’s here that I part company with Neilson who, in the same post, goes on to say:

For non-hierarchical sites, breadcrumbs are useful only if you can find a way to show the current page’s relation to more abstract or general concepts. For example, if you allow users to winnow a large product database by specifying attributes (of relevance to users, of course), the breadcrumb trail can list the attributes that have been selected so far. A toy site might have breadcrumbs like these: Home > Girls > 5-6 years > Outdoor play

There’s an obvious problem here. In real life sets are fuzzy and things can be ‘filed’ into multiple categories. Let’s pretend the toy being described by Neilson is a garden swing that’s also perfectly suited to a 5-6 year old boy. In this case journeys to the swing product page might be ‘Home > Girls > 5-6 years > Outdoor play’ or ‘Home > Boys > 5-6 years > Outdoor play’. If there’s an aggregation of all outdoor playthings there might be journeys like ‘Home > Outdoor play > Girls > 5-6 years’ and ‘Home > Outdoor play > Boys > 5-6 years. If the swing goes on sale there might be additional journeys like ‘Home > Offers > Outdoor play’ etc.

Now it’s not clear from the quote whether Neilson is only talking about breadcrumb trails on pages you navigate through on your way to the product page or also including the product page itself. But the problem remains. If the garden swing can be filed under multiple categories in your ‘site structure’ which ‘location’ does the product page breadcrumb trail display? There are 4 possible ways to deal with this:

  • drop the breadcrumb trail from your product pages. But the product pages are the most important pages on the website. They’re the pages you want to turn up in search results and be shared by users. I can’t imagine it was Neilson’s intent to show crumbtrails on aggregation pages but not on content pages so…
  • make the breadcrumb trail reflect the journey / attribute selection of the current user. Unless I’m misreading / misunderstanding Neilson this seems to be what he’s suggesting by the breadcrumb trail can list the attributes that have been selected so far. Quite how this differs from a path based breadcrumb trail confuses me. Again you’re serving one page at one URI that changes state depending on where the user has ‘come from’. Again you’re choosing to fight the statelessness of HTTP. And again the whole thing fails if the user has not navigated to that page via your ‘site structure’ but instead arrived via Google or Bing or a Twitter link or a link in an email…
  • Serve (almost) duplicate pages at every location the thing might be categorised under with the breadcrumb trail tweaked to reflect ‘location’. For all kinds of reasons (not least your Google juice and general sanity) serving duplicate pages is bad. It’s something you can do but really, really doesn’t come recommended.
  • Serve a single page at a single RESTful URI and make a call about which of the many potential categories is the most appropriate.

The latter option can be seen in use on The Guardian website which attempts to replicate the linear content category sectioning which works so well in the print edition into an inherently non-linear web form. So the Chelsea stand by John Terry and insist he took no money article has a location breadcrumb trail of:

whereas the High court overturns superinjunction granted to England captain John Terry article has a location breadcrumb trail of:

At some point in the past it’s possible (probable?) that the superinjunction story was linked to from the homepage, the sport page, the Chelsea page, the John Terry page etc. But someone has made the call that although the article could be filed under Football or Chelsea or John Terry or Press freedom it’s actually ‘more’ a press freedom story than it is a John Terry story.

The point I’m trying to make is that breadcrumb design for a non-hierarchical site is tricky. It’s particularly tricky for news and sport where a single story might belong ‘inside’ many categories. But if you’re lucky…

It isn’t about ‘site structure’, it’s about ‘thing structure’

Traditional IA has been about structuring websites in a way that journeys through the pages of those sites make the most amount of sense to the most amount of users. The Linked Data approach moves away from that, giving URIs to real life things, shaping pages around those things and promoting journeys that mirror the real life connections between those things.

Two examples are BBC Programmes and BBC Wildlife Finder. Neither of these sites are hierarchical and the ontologies they follow aren’t hierarchical either. An episode of Doctor Who might be ‘filed’ under Series 2 or Drama or Science Fiction or programmes starring David Tennant or programmes featuring Daleks or programmes on BBC Three on the 4th February 2010. So again location based breadcrumb trails are tricky. But like The Guardian one of the many possible hierarchies is chosen to act as the breadcrumb trail:

which is echoed in the navigation box on the right of the page:

The same navigation box also allows journeys to previous and next episodes in the story arc:

The interesting point is that the breadcrumb links all point to pages about things in the ontology – not to category / aggregation pages. So it’s less about reflecting ‘site structure’ and more about reflecting the relationship between real world things. Which is far easier to map to a user’s mental models.

Wildlife finder is similar but subtly different. The location breadcrumb at the top of the page is a reflection of ‘site structure’. In the original Wildlife Finder it didn’t exist but initial user testing found that many people felt ‘lost’ in the site structure so it was added in. Subsequent user testing found that its addition solved the ‘lost’ problem. So in an input / output duality sense it’s primarily an output mechanism; it makes far more sense as a marker of where you are than a navigation device to take you elsewhere.

Much more interesting is the Scientific Classification box which reflects ‘thing structure’ (in this case the taxonomic rank of the Polar Bear), establishes the ‘location’ of the thing the page is about and allows navigation by relationships between things rather than via ‘site structure’:

In summary

  • We need a new word for crumbtrails. Even seasoned UX professionals get misled by the Hansel and Gretel implications. Unfortunately ‘UX widgets that expose the location of the domain object in the ontology of things’ doesn’t quite cut it
  • Secondary navigation is hard; signposting current ‘location’ to a user is particularly hard. IAs need to worry as much about ‘thing structure’ as ‘site structure’
  • Building pages around things and building navigation around relationships between things makes life easier
  • HTTP and REST are not techy / developer / geeky things. They’re the fundamental building blocks on top of which all design and user experience is built

33 responses to “The problem with breadcrumb trails”

  1. Well, another epic post Mr Smethurst, I’ll be passing in around, thanks

  2. Superb article, Michael.

    Let me say upfront that RESTfulness and Statelessness are things that I’m only starting to come to terms with (possibly to my shame), being an interaction designer that used to be a tradesman/coder! In any case…
    I’ve been wrestling with the use of hierarchical navigation models and the use of ‘crumbs’ in the world of things with multiple nodes related to them.

    Perhaps a breadcrumb would be better called a ‘primary locator’? IE Acknowledging that a decision has been made about the node(s) above in the domain that most represent a ‘location’, and that its purpose is really about orienting a person in the domain (as the WF example shows).

    I imagine from your point of view that this still isn’t perfect as its still imposing a state on something which is stateless? But I think that’s interaction design – the place where the system meets a person. Is there a way of removing the presentation of this type of navigation / structure from the HTTP to maintain the purity of the HTTP???

    What I do like about the crumb is that its a simple and discrete form of primary navigation. Its not trying to expose insane levels of navigation. Its not a great *navigation* device at all really. Its mainly saying – this is where you are. This way, we can let contextual navigation be more of the focus of the way that people navigate the page.

  3. This is an excellent and useful post Michael – thank you.

  4. There are terms which we could appropriately use in the place of ‘breadcrumb’.
    Taxonomy ( is the practice and science of classification, whilst Ontology ( is a formal representation of a set of concepts within a domain and the relationships between those concepts.

  5. Great post Michael – I totally agree that the history-based breadcrumb is worse than useless, though like Andy I think that a well-judged hierarchial one can serve as a useful information scent to provide some classification context to the current document and give the user an idea of higher-order content categories available to them.

    One thing though – it’s “Nielsen”. As in Dennis.

  6. Agree with the others, great post.

    I dislike “crumbtrails,” to the point where I haven’t thought about them for a while. Framing them in terms of REST is quite interesting. My gut reaction would be to become uneasy in terms of caching, but yours argument is far better.

    One of the more interesting things that I get to deal with is working in a domain where the “real world things” are actually sites, which themselves fall into multiple categories. It’s quite difficult keeping the mental model simple when the relationships are actually specific biological relationships.

    Anyway, very nice post. I look forward to seeing more of your thoughts.

  7. Thanks for such a clearly articulated post… I had no trouble following your trail :-)

    So, as is becoming increasingly clear with the increasing inevitability of some kind of semantic web, the URI is where it’s at, not its URL offspring.

    I don’t see any reason why a link describing a ‘thing’ rather than a ‘location’ is any less able to provide the orientation users need and the full range of options as to what to do next (I nearly said “where to go next” then… but I would have meant where to go to find out more about the URL hyperlinked ‘thing’ in question of course).

    Tesco has begun to mark up some of its sites with RDFa (for example), although they have resisted the temptation to add a “thing crumbtrail” dynamically to the pages just yet.

    And as for a more concise name than “UX widgets that expose the location of the domain object in the ontology of things”, and given that “trail” is completely inappropriate now but that it’s equally useful to retain some atavistic reference, howsabout “domain object crumbs” or just “object crumbs”?

  8. Constructing a site dynamically makes it much easier to publish many, many pages; both aggregation pages and content pages”

    However, the useful content has to come from somewhere. Gosh! – that’ll be a *file* then. the rest is just marketing and windowdressing [1]. So – why not have the author and editor identify the content by a Ranganathan style Colon Classification appropriate to the nature of the presenting host.

    Perhaps people have noticed that the same book (remember them?) may be found in widely differing shelving locations according to the type of library?
    eg: _Zen and the Art of Motorcycle Maintenance_ – philosophy, travel, biography or fiction?

    It seems to me that we have four basic areas for description:

    The Journey
    The Location

    The Journey, as Tom says, is rightfully within the browser’s (and the Browser’s) domain – and should be handled that way. The “history” is useful, but for any given tab we should be able to display our tracks and branch (without losing the master sequence) out once more. A SVN for the journey … and that means saving the history trail when we “bookmark” something or save a resource.

    The Location – despite such well meaning efforts as purl – is pretty much a fixture until 404 time.
    “We are not lost … we are *here* … it is *home* that is lost “.

    The Directions – ah now! That is the interesting one – and I think the real philosophical debate to be had – the crumbtrail one is just scratching the surface. Is it Directions that the resource owner/hoster/creator gives out, or those of a user who starts from a given place (their “home”) or directions given to a fellow traveler (a person who changes location) … or those with a specific purpose. It’s the whole discovery/search thing once again.

    The Content – your take on it is not mine – it’s why Library students spend two years learning about classification – and classification for a purpose. I refer those interested to the “WWW space needs a card catalog for navigation” discussion I had back in May 94 and available via google still … Bit of a shame that 16 years on it’s still not sorted.

    Metadata has become a SOAPy tag soup of ephemeral bubbles with evanescent content and a lack of cohesive structure …

    All four need to be addressed as parts of an integrated solution – without them becoming some ineffectual homogenised veneer concealing and distracting from the true form and substance.

    (@Tom: Good to see you’re still in the business! )


    [1] The state of today’s WWW makes me yearn for the old days of gopher ….

    1. re your idea of a card catalog for a navigation, I assume you mean this: – is that a bit like publishing an ontology (e.g. to describe the content? Or are you talking about something more akin to the old Yahoo! approach to categories?

      1. Hi Scott, do you have a any guide of the css code I may use to create/replicate the breadcrumb????? I really want to create one for my upcoming site (wordpress one) but I am kind of a newbie to css. Help please!!!

  9. michaelsmethurst Avatar

    @duncan Cheers mate. Although epic as in good or epic as in long? :-) I only post once every 6 months so brevity feels like a luxury. Is my excuse anyway :-)

    @andy I think ‘primary locator’ works fine as a description when you’re talking about category navigation as your primary interface. But I still think there are better ways to organise stuff than categorisation. The “crumbtrail” on WF isn’t really about location in a domain; it’s about site structure. The scientific classification box handles all the domain orientation malarkey.

    The problem with having a primary categorisation is the complexity overhead it introduces. Not only does your data model need to know that a category can have many things and a thing can live in many categories you also need to build ‘primary category’ into your admin tool and employ people to make the primary category call. Which is all fine but you do need to give it some thought before you just go ahead and design.

    You asked ‘I imagine from your point of view that this still isn’t perfect as its still imposing a state on something which is stateless?’ No, it’s fine. So long as the ‘primary location’ state is stored in your data model / ‘business logic’ nothing breaks. It’s only when you attempt to build state on top of http that your problems start. So if you can build ‘primary locator’ state into your backend systems and find the people to maintain that there’s no problem. Just don’t design without thinking about the systems you’ll need to support that design. As ever I think it’s best to design from the domain / data model out.

    In answer to the “Is there a way of removing the presentation of this type of navigation / structure from the HTTP to maintain the purity of the HTTP???” If you’re talking about primary locator then yes. Model it in your data/business systems and employ people to maintain. If you’re talking about user journey tracking then no. On the web there is only http. (It’s possible that browser manufacturers could do something more obvious with browser history but given tab based browsing that’s not easy.)

    On the last point I think the concept of “contextual navigation” is probably worth a blog post in itself. Like breadcrumb trails the definition is slippy. To some people it just means all navigation that isn’t site ‘global’. So a primary location widget could be seen as contextual if the context is ‘site structure’. To other people it means navigation that’s specific to the document content (as opposed to document ‘location’). And to others it means navigation that’s specific to the concept(s) the document describes…

    @anthony Yup. I think the Wildlife Finder scientific classification box is both an ‘ontological widget’ and a ‘taxonomic widget’ cos in this case the aspect of the ontology exposed is taxonomical

    @mike I guess the point I’m making is not that they’re not useful, more that they’re difficult to get right.

    The more fundamental point is what you mean by hierarchy? Traditionally the web has been document focussed so we’ve taken the library science approach of document classification and called it ‘site structure’. The whole domain driven design / linked data meme is less about a web of (categorised) documents and more about a web of things. And things have relationships to other things.. Or… The Beatles were a band because they played music, not because a librarian decided to categorise them as such.

    And often those relationships are not mono-hierarchical. Wildlife Finder got lucky cos the main spine of the ontology is the biological taxonomy which, erm, is obviously a taxonomy. /programmes uses the spine of possible brand, possible series, episode which is also mono-hierarchical. (In truth it’s probably a simplification of reality cos you also get things like the Eastenders / Comic Relief special but in general it’s good enough.) But many domains / ontologies are not mono-hierarchical at which point ontological hierarchy widgets become impossible.

    Which is not so bad. Wikipedia is perfectly flat. It has no URI structure and no ‘site structure’. It does have some categorisation but you have to hunt to find it. But it’s easy to navigate cos all the links are contextual to content / concept. Or at least I’ve never felt ‘lost’ in wikipedia!?!

    And oops on the spelling. I would correct but I’ve lost my log in and at least this way he’s less likely to track to me down and expel me from the IA community :-)

    @eddie The caching argument is a great one and one I should have probably included. If the content at a URI is personalised to an individual it can’t be (http) cached. Again http used restfully (with appropriate expires headers) is the only sane solution.

    @philip I mostly agree. Navigation built around the relationships between things is easier to grasp than navigation built around categorisation (unless you’re a librarian). Probably worth pointing out that if you’re talking about a ‘domain object crumb’ that’s generated to reflect *your* journey through *things* you still have the same basic battle with http you have with a personalised crumb that’s generated to reflect *your* journey through *pages*. It’s not RESTful so not a good idea.

    @mgrimleigh I know the “serve from data store not file” probably sounds like a conceit but it really isn’t. You can take any number of examples: my Facebook profile page, a artist page, an Amazon product page, a /programmes episode page, a tweet and you’ll find… gosh! nothing that could conceivably be described as a *file* as ever existed.

    In the /programmes case the only file that ever gets created is a billing document for the broadcast. But the page represents an episode so might be the result of many broadcasts and many billings. Everything else (relationships to trailers, tracklists, chapters…) as never been a file. Just some rows in some tables in some database. There is no ‘author’.

    I suspect my answer to your main point might sound flippant but… I think library style classification schemas are incredibly useful for finding things… if you’re a librarian. For the rest of us not so sure.

    The other point is it really doesn’t scale to the web. The whole point of the web is low friction publishing. In this context librarianship just introduces friction. When my daughter hits teenage years and hopefully forms a rock and roll band I don’t want to be the one to tell her she can’t record a song because the librarians haven’t caught up with their artist classification work yet.

    Mainly though I think we fundamentally disagree on what the problem with the web we have is. From your comment (and especially the gopher reference) I’m assuming you see the web as a set of documents in need of library science style categorisation and hierarchies of knowledge organisation. The point my post was attempting to make (possibly badly) was that this librarian desire to categorise and structure documents is the problem not the solution and leads to warped notions like ‘site structure’. Personally I don’t want to spend 2 years on a course learning how to file and find things.

    So imo what the web does not need is a “card catalogue for navigation”. The problem is not how to get information to librarians; the problem is how to get information to everyone. And that is made easier by modelling real things and the relationships between real things and building navigation on top of those relationships. As Tom might say, “making the web human scale”. As I might say, “Not making the web librarian scale” :-)

    Anyway, suspect it’s taken me longer to write this reply than it took to the original post. Apologies for delay….

    1. Hi Michaelsmethurst, do you have a any guide of the css code I may use to create/replicate the breadcrumb????? I really want to create one for my upcoming site (wordpress one) but I am kind of a newbie to css. Help please!!!

  10. Nice article and summarisation of a difficult topic.

    A small point would be that your styling of unorder lists makes it slightly more difficult to read due to the changein font size.

  11. Great article, which raises some interesting points for thought. Two critical points, though:

    1. Doesn’t the whole nature of a ‘dynamic’ site go against the stateless HTTP model in the first place?

    2. I find it hugely ironic that, in a post all about UX, you’ve sized text in pixels. Just TEN pixels at that!

  12. I don’t get this “following around Jakob Nielsen” thing. Saying that “the back button is the most-used button in navigation” is an absolute load of rubbish and I know that many people that ARE NOT designers that are stuck up with themselves BUT IN FACT people who actually USE websites and have LITTLE TO NO knowledge of technology. I have watched them and seen that actually, BREADCRUMBS ARE USED. These “click tracking” studies seem to all be taken by designers, not actual users. Start caring about users and take your head out of your ass.

  13. Amazing article, very interresting! Thx.

  14. Thanks for this post, I found it very interesting. I’d agree that the first use of breadcrumbs is useless unless you’re performing a prescribed, linear set of actions which don’t require the designer to code any tracking.

    I think the second Nielsen–esque use can help visitors navigate sites if the document author simplifies the breadcrumb trail so that it doesn’t just reflect the site’s classification. Besides, I think the purpose here is to ‘rescue’ the lost user, rather than provide a way to explore related information.

    For example, let’s say you’ve parachuted into a blog post that’s been categorised ‘football’ and ‘law’. It may be helpful if the breadcrumb goes Home → Blog → John Terry is a lovely human being and the post header lists all the relevant categories.

    Obviously, this isn’t going to work on sites which are essentially a collection of articles (such as The Guardian).

  15. This is a very tidy post… However, for some reason I have now started to think about cheese on toast!! All that reading has given me the munchies!

  16. Thanks Michael for very interesting post!

  17. Great article that sums up the issues I’ve had myself, trying to figure out how to deal with breadcrumbs in a service where single items can belong to several categories. It seems that it’s best to forget the breadcrumb on the product page and only list the categories that the product belongs to.

    Anybody who’s been involved with breadcrubms may also find interesting what Jared Spool has written on the topic :

    BTW At some point you started writing Nielsen as Neilson.

  18. I’m way out of my depth here — just a user! ;) But, FWIW, a couple thoughts all the same:

    1. When visiting a (new) site, I need to know a way IN, not a way BACK, so breadcrumbs aren’t so helpful there, are they! That’s where navigation, or better, signposts (“where can I go from here?” come into it of course. And at this stage in my journey, some guidance is needed, some even pseudo-hierarchy imposed. For, as Harry Nilsson once intoned, “a point in every direction is the same as no point at all”.

    2. But taking up the non-hierarchical issue (and the Guardian example in particular), for me the common wiki feature of “What links here?” is an excellent not-a-breadcrumb trailblazer. If I’m on the John Terry stories, I might be there because of an interest in press freedom, in Chelsea, in Lives of the Rich and Famous, football (possibly) … or even because I’m following the career of Carlo Ancelotti! The “backlinks” presumably could get me in almost any of those directions.

    The difference between ##1 and 2 is that in #1, the site gives me a direction, whereas in #2, I’m told all the directions I can follow, and I pick the one of most interest — site-directed, or user-directed in other words.

    Now if only the many kinds of sites (and not just wikis) (imagine if the whole WWW worked that way!) had “what links here” possibilities, that would really open up things. Or so it seems to me at the moment!

  19. Very nice article. (@michaelsmethurst I am afraid I did track you down despite the misspelling of my name :-)

    One point, though: you quote me (correctly) as saying that breadcrumbs should reflect the site structure (when there is one) and then say that it’s better if they reflect the real-world relationships between things. This conflict can be resolved because it’s almost always best if the IA reflect users’ mental models of the real-world problem you’re trying to solve. [For example, that’s why card sorting studies are frequently used: ]

    It’s almost always *bad* when the IA reflects, say, the company’s internal structure or how the information was produced (as opposed to consumed). I have campaigned against company-centric IA so often that I guess I forgot to mention it in my breadcrumb article.

  20. […] The problem with breadcrumb trails « תגים: כללי […]

  21. […] The problem with breadcrumb trails « (tags: WS_blocked website navigation webdesign) […]

  22. First, let me say, great post! Really well written and argued – it has left me with loads to think about.

    As someone who is involved in the web but whose background is in psychology, the main thing that struck me about this post and what I really wanted to comment on is that in some ways what you have stumbled upon and are dealing with in breadcrumb trails is a debate that has raged in psychological circles for years – namely, how do people organise information?

    If breadcrumbs are designed to prevent the user from feeling ‘lost’ or to signpost their location, then in some ways they should be fundamentally built around the psychology of the user.

    I agree with you that path based trails are often meaningless and wholeheartedly agree with your point that “it’s not really about where you’ve come from” – I think these kinds of trails just lead to more confusion.

    I also agree with the multi-faceted points you make about location based trails and the difficulty in classifying categories and hierarchies within these trails. Unfortunately however, this is not a new debate nor one that is confined to the web. It is one that psychologists have been researching for decades. How do we learn different categories and how do we place new objects into categories? Unfortunately, there are no easy answers to this debate, either in psychology or on the web. Different schools of psychological theory have yet to agree on how we form representations of knowledge (Do we use images or words? Hierarchies or more abstract structures? And so on) and have yet to agree on how we mentally categorise such knowledge (Do we form categories based on prototypes? Exemplars? Based on similarities between objects? Based on theories?)

    This kind of debate is what underpins many of the difficulties presented by breadcrumb trails. The breadcrumb trail is trying to represent the location of a particular page in a way that is meaningful to the user, but even categorisation and classification from a user perspective is not simple.

    I like your ideas about ‘thing structure’ rather than ‘site structure’ as I think these ideas represent categorisation and classification much more from a psychological perspective. I also like the ideas on the Wildlife Finder of using multiple forms of classification as this begins to represent more of the complexity found in categorisation. However, I fear that in many instances this could lead to overly complex ‘trails’ and more confusion rather than less, so I’m not sure I would advocate this in too many instances.

    Overall, my general feeling is that there is so much overlap in the fields of psychology and the web (possibly unsurprisingly) and that we could all benefit hugely from merging the two more. Although I obviously haven’t really come up with any ‘answers’ here, I wonder if engaging in the ‘categorisation’ debate had in psychological circles could inform some of the problems found in online navigation.

    (If you are interested, I have also written a blog in response to your article that provides a little more detail as this comment was already getting rather lengthy! (

  23. michaelsmethurst Avatar

    @richard @bobby Sorry about font size. I just wrote the text – the css was inherited. Is my excuse :-)

    @bobby By dynamic i mean that the pages are assembled by the server as and when the user requests rather than served as files off a file system. But as soon as they’re assembled the web takes over to distribute so again it’s HTTP and it’s stateless.

    @xanti Erm, thanks for your thoughts. Quality of expression still counts…

    @david Pre-web hypertext systems worked pretty much like that so all links were bidirectional. I think it’s interesting but damned tricky in real life. Backlinks are useful if the page isn’t heavily referenced but imagine a heavily linked to wikipedia page listing all the inbound links? It’s gonna get heavy quickly if it’s every linking wikipedia article, blog post, tweet…

    @jakob Thanks and, erm, sorry for mispelling. I seem to have got it right for the first few paragraphs and got worse the more i typed. Is a wonder you didn’t end up as Jack :-)
    I take your point on the reflect users’ mental models stuff but i think that’s what i was trying to say by:
    “Many of the early battles in Information Architecture were about warping the filing systems and hierarchies that made sense inside businesses into filing systems and hierarchies that made sense to users”
    Not saying those battles are won by any stretch but I think we have to move on from just content and page categorisation and think about the concepts those pages describe and the structure of the links between those concepts. Not sure attempts to force the web into a filing system type metaphor ever really work…

    @debbie not much to say really > “my general feeling is that there is so much overlap in the fields of psychology and the web (possibly unsurprisingly) and that we could all benefit hugely from merging the two more” < totally agree :-)

  24. Really great article!

    I completely agree with where the article landed, and found myself getting anxious along the way. That visual hierarchy of “things” rather than site structure or path is spot on.

    I wonder if there has been any recent work regarding use of the back button as a means of navigation? How many people use it? How many people trust it? There have been several usability tests that I have observed that demonstrated to me how some folks just don’t use even their basic browser features. This might be something that changes over time, and that was a while ago.

    Anecdotally, I recall navigating the Amazon breadcrumb (categories) while I was shopping for Christmas gifts for kids, and liking it quite a bit. It was really a means of modifying my search criteria. It was there, so I used it, but it could have been done in a lot of other ways and been even effective for me. The way that EUI handled search criteria in the eBay desktop app, or the way the Mac Mail app handles search. It’s a search/browse hybrid approach that works really well, and feels a bit breadcrumby – though really it’s not a breadcrumb at all…

    Maybe context is key. It usually is. Some examples here are almost solely info-gathering situations. Shopping might be different and need some other model? I would love to see this idea systematically applied to a few contexts. You know, separate the apples from the oranges and see if the premise still holds as strong as it seems here.

  25. […] links to some of these). More often than not these discussion are not focused on REST per se, but on anything related to the Web, various specifics concerning current and future standards and so on. […]

  26. […] ‘The Problem with Breadcrumb Trails‘ by Tom […]

  27. I’m having just this problem with a new website I’m IAing which will have some pages that can be linked to from different sections ; so I guess one solution is to design a breadcrumb trail (which I like to call them biscuit trails) with more dimensions…

    Nice article BTW

  28. […] The Problem with Breadcrumb Trails – Tom Scott […]

  29. […] you consider your website to be a tree (which for all kinds of other reasons you really shouldn’t – the web is a web, not a tree) and your pages to be leaves, then fragment identifiers are […]

  30. I don’t understand that the comments stop in 2010, I am so LUCKY to found this article still in Google. This is the only article I found that made sense about breadcrumbs. Although I have to read it over again (native language is Dutch). Especially the ‘thing’ and ‘URI’ part I don’t get yet, but the main idea of breadcrumbs and when it’s not a solution I get now. One of the comments was telling about taxonomy. This actually is an other way of sorting content then files/folder how we used to do it. One blogpost can be in multiple category’s that way. The blogpost itself has it’s own URL, not related to upper category’s. I never thought about this ‘structure’ issues, but having problems with some websites right now this article was really helpfull.

Leave a Reply to Mike Atherton Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: