Breadcrumbs: where you are or where you've been?
I had an interesting discussion with a colleague about breadcrumbs recently. He was doing some work on design patterns and the issue of breadcrumbs came up. The initial pattern proposal basically mirrored Jakob Nielson's recent article on breadcrumbs. In other words, breadcrumbs should show where a user is in the navigation rather than showing them where they've been. As Nielson puts it, "Breadcrumbs should show the site hierarchy, not the user's history."
Of course, the obvious problem with this is that many sites are not hierarchical. So Nielson immediately follows up the statement above by saying, "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." Further proof that confidence is often more persuasive than knowledge, I suppose.
The interesting question from my point of view was whether Nielson's pithy, unambiguous guidance applied to web applications. In most web applications, users don't navigate directly to sub-pages in the application (one of the primary benefits to hierarchical breadcrumbs, according to Nielson) , applications are often not hierarchical (for example, they include tasks), they discourage the use of the browser Back button (which Nielson think removes the need for history), and there are often omnipresent navigation panes that assist users in understanding where there are in the object hierarchy.
For example, let's say I'm in the process of performing a multi-step process like checking out of an online store. As part of this process, the application provides the option to leave the main task path to perform other actions (like creating a profile). How would a hierarchical breadcrumb trail work in this case? Not at all, as far as I can tell. If the user chooses to leave the profile creation task and return to the checkout process, should they use the Back button? Perhaps, but provided a breadcrumb trail that allows the application to handle the move has obvious benefits.
Perhaps breadcrumb patterns are more complicated than they first appear.
2 comments:
Terry, I've pondered the same topic many times. Recently, after presenting the "Edit Page" wireframe for a web-based CMS application to stakeholders, I was asked to add a You Are Here (YAH) breacrumb. As an IA, I understand the concept and have used it on many a static website.
But for a web app with no defined "this page sits under this one" I'd purposely left it out. Users would arrive at most screens to accomplish one particular task (in this case to make edits) and should use the submit/cancel buttons to proceed/go back.
In the end we are providing users a sense of place with static text in a non-clickable, you-are-here-in-the-process sort of way ("You are editing: Page path & name"). I'll have to find out in beta testing if users are confused as to where they are or are looking for a clickable breadcrumb. But my hunch after looking at many other web and software applications is the always-accessible menu system, and clear mechanisms for moving forward or back (submit/cancel) will be enough.
So I'm with you...sometimes breadcrumbs just don't apply, especially in applications.
In those types of situations, we usually keep the breadcrumb, but we use it as a history rather than a YAH. The Cancel button ought to be sufficient, but it seems that because we use breadcrumbs extensively in the rest of the application, users get nervous when they end up someplace without one. Like they've somehow navigated to a place so remote and scary that we can't even tell them where they are! Yikes!
So we basically duplicate the Back button (which we don't want people to use anyway) and the Cancel button. So far, users don't seem to get confused... but sometimes the architects do. =)
Post a Comment