Let’s stop playing Frankenstein

Consider the monster from Mary Shelley’s Frankenstein:

The creature is described as being about eight feet (244 centimeters) in height, with translucent yellowish skin that “barely disguised the workings of the vessels and muscles underneath”, watery, glowing eyes, flowing black hair, black lips, and white teeth. (http://en.wikipedia.org/wiki/Frankenstein%27s_monster#Appearance)

I read that phrase describing the skin of the monster, that it “barely disguised the workings of the vessels and muscles underneath.”

My hands have worked on Web pages that were little more than that yellowish skin.

It’s no wonder customers fled in terror.

By now, most of my nameless monsters have died off, thanks to the hyper-life-cycle of the Web, but recently I gained a new perspective of how ungainly, ill-proportioned Web sites are created.


If you want to create a monster of a Web page, the trick is quite simple: Work, work, work at it, one page at a time. Write the code, make it work, make sure the forms submit. Whip up some error text, insert some confirmation screens. Check the boxes on your to-do list of functional requirements. Light it up, and let it out onto the world.

But wait…isn’t that how most of us get our jobs done? These days, we like to call this kind of heads down, busy-work “Agile.”


Step away from the keyboard, Doctor.

Pick up a pencil. Draw out the whole process from the point of view of each actor, be it a person or some agent like a search engine robot. Draw pictures using easy graphics, like Garrett’s visual vocabulary palette, and be sure to include every point of contact with an actor.

Having done this recently, it became clear immediately that there was a series of email messages interspersed amongst Web pages, and that those emails were as important as any single Web page.

Also, the timing of those emails was important. For instance, Jim uses a Web page to send an email message to his friend Bob. Jim then sends an instant message to Bob asking if he signed up yet, assuming that Bob did in fact receive that email message and was able to decipher it. Those are two tough assumptions.

Each piece of a larger process overlaps with its adjacent pieces in a series of feedback and feedforward communications. Once we have these communications, these pages, emails and so forth, laid out with balance, proportion, and clear purpose, a more beautiful creation can take hold.

Nurturing and shaping this flow of interactions between people using a system is a great step in putting an end to the monsters we’ve become so good at creating.

Once we’re into this process, we invariably realize there are many more questions to ask, but the point is this: Design processes, not pages.

Marking up breadcrumb navigation

Breadcrumb navigation is a secondary navigation system that usually represents a site visitor’s current position in the site, showing other pages above the current one in the site’s hierarchy.

In some sites, like those built with Dokuwiki, breadcrumbs actually show the history of the user’s session instead of the hierarchy of the user’s current position in the website.

Breadcrumb navigation is typically found at the top of a content region, and usually below primary tabbed navigation.

History? Bah, yesterday’s newspaper.

In his April 10, 2007 Alertbox, Breadcrumb Navigation Increasingly Useful, Jakob Nielsen declares, Breadcrumbs should show the site hierarchy, not the user’s history.

For the purposes of conceiving of solid, semantic markup, let’s agree with Nielsen. Breadcrumbs represent position in a site’s hierarchy.

Semantic values: hierarchy, location, current position

In hierarchical breadcrumb navigation, the following aspects of information are important.

  • Steps in the hierarchy that show broader sections of the site related to current position, i.e., the ancestors of the current page
  • The order of those steps
  • The ability to immediately jump to any ancestor page
  • Indication of the current page, which should not be linked

The markup

So, with those in mind, here is an example that provides just enough code and semantics, and little else.

<ol id="breadcrumbs">
<li><a href="../../../../../../">Kim Jong Il’s Favorite Widgets, LLC</a></li>
<li><a href="../../../../../">Military</a></li>
<li><a href="../../../../">Nuclear</a></li>
<li><a href="../../../">Warheads</a></li>
<li><a href="../../">Just for funsies</a></li>
<li><a href="../">2006</a></li>
<li class="current_page">Gilju, Hamgyong province, 0136 GMT</li>

This markup is fairly lean, yet does communicate the order of steps via the ordered list.

Note that the Project Cerbera website provides a nice discussion and some other examples of breadcrumbs markup that are in line with this approach.

The examples at Project Cerbera also show nested lists to indicate the nested nature of the links, but that is over-the-top. The simple ordered list sufficiently communicates the order of steps in the hierarchy, without providing additional markup noise for a screen reader to announce or a designer to style.


The breadcrumbs should strive to follow conventions.

  • Take up one line
  • Use a standard separator between steps, like >
  • Each step links to an appropriate page using standard link indicators (underlined and colored)
    • Except for the last step, which should be unlinked and represent the current page

Unstyled example

  1. Kim Jong Il’s Favorite Widgets, LLC
  2. Military
  3. Nuclear
  4. Warheads
  5. Just for funsies
  6. 2006
  7. Gilju, Hamgyong province, 0136 GMT

Styled example

Minor variations could include having the current page item be in a bold font, however, breadcrumbs are secondary navigation. They don’t need to attract much attention.

To reference the Project Cerbera site again, the examples there use a greater-than background-image on the list items. That technique may stand better in cross-browser tests than the use of the after pseudo-class used here.