Breadcrumbs
Breadcrumbs is the term used to describe a series of links presented at the top left of the content area (activity frame) which allow the user to see where he/she is in context with the information architecture of the application.
It is important at this time to make a distinction between breadcrumbs and what I call historical links.
Historical Links
As the name implies historical links are a list of links (normally presented horizontally) of previously visited by the user in that current session. The URLs that populate historical links do not represent the information architecture and as such while they allow the customer to back track more easily do little to illustrate current application context.
Breadcrumbs
Like historical links breadcrumbs provide a list of links however in this case the links are aligned with the information architecture of the application. In this case the links show then end user a clear representation of current context as well as providing an alternative method to navigate up the information hierarchy.
To illustrate this distinction lets take an application with the following information architecture. The steps taken by the user are denoted in red…
The following are the links lists after the fifth navigation step…
Some would argue that historical links offer more value to the end user than breadcrumbs due to the extra detail they provide users on session history. However with this comes a number of disadvantages:
- Scaling issueScreen real-estate quickly becomes an issue after five or so pages have been visited within any one session
- Invalid linksIn many cases links to previously visited pages will expire making the linkage invalid
- Native browser support alreadyAll browsers support page history natively reducing the value add of historical links significantly
- Information overloadLarge link lists further add to the complexity of the user experience
- Promotes off take of previously viewed/old contentHistorical links do not help the user understand where he/she is within an application only where he/she has been before. Assuming the user has already completed his/her tasks in the previously visited pages it is facilitation of navigation to unviewed/new content that should be the focus of the UI design rather than the promotion of old content.
Breadcrumbs are regarded as superior alternative to historical links due to the following advantages:
- ScalingIt is very rare that breadcrumbs links will grow to over five items. In the case where this happens often it is likely there is an information architecture strategy issue to be solved ahead of time.
- Valid linksBreadcrumbs tend to be comprised of valid links due to their information architecture alignment.
- No native browser supportThe back button in browsers takes you to the previously visited page - it does not take into account the information architecture and as such the addition of breadcrumbs is net new functionality.
- Information simplificationWhile it is true breadcrumbs do add complexity to the user interface they are relatively simple in comparison with historical links.
- Promotes off take of unviewed/new contentClear illustration of information architecture context helps to make the process of navigation to new content simpler for users.
Breadcrumbs are presented in a pretty generic manner in most web applications. They tend to appear in the top left of the content area (activity frame) just above or below the page name. Each link is normally separated with a non linked character or image. The link description is normally populated with the "page name" for that URL…
Normally the current page is shown as the last element in the breadcrumb and not linked.
Composer breadcrumbs support implications
It is proposed that support of breadcrumbs be included as part of IAD support. With IAD support in Composer the addition of breadcrumbs should be trivial.
I envision breadcrumb support would take the form of a new widget being added to the controls pane in the interface screen. By dragging the breadcrumb widget to an interface the user could configure its formatting by right clicking and altering the following properties:
- Type (font, color, size etc)
- Separator (character, image, upload image)
Page Name
The page name is an obvious pattern it is just the presentation of the page name within the content area (activity frame)…
Automation of the page name within Composer would allow end users to effect the Page Names presented in the simulation of the application from the activity screen by changing the description of the interface icons in the activity flow pane.
Composer page name support implications
I envision page name support would take the form of a new widget being added to the controls pane of the interface screen. By dragging the page name to an interface the user could configure its formatting by right clicking and altering the following properties:
- Type (font, color, size etc)
Posts
