[previous installments of WDLfC: Introduction, Part 1, Part 2, Part 3]
So, after a lengthy delay, we return to the ongoing series. We’ve seen some of the nifty ways that abstraction can influence web design in both the broadest and narrowest realms (overall style and component design, respectively). In this installment, we’ll look at the benefits abstraction can produce when applied at a level somewhere in between - in the design of one aspect of site navigation, the sitemap.
As sites get larger and more complicated, they get usually more difficult to move around in (sites that avoid this phenomenon are often supported by exceptionally talented and underpaid information architects). Categories multiply, topics reproduce, modules appear spontaneously - eventually, it becomes so difficult to find anything among the competing options that people stop trying.
One of the first things many IAs will build when confronted with such a cluttered mess is a sitemap; it’s a way to get a handle on what’s out there so that they can move forward with the redesign of the content structure with open eyes. During their efforts, the sitemap gets revised again and again, ending finally as a thing of beauty (at least when compared to the original). Is it any wonder, then, that the proud IA will often include the sitemap on the final site somewhere, both as a testament to the blood, sweat, and tears that went into the structure and as a final aid to users trying to find that one crucial page?
Ah, but let’s focus on that last-straw-bending user for a moment. Say she has tried every other option (searching, browsing, asking the Delphic oracle, looking over her friends’ shoulders) and still can’t find the page she needs. She’s stumbled across the sitemap - Aha! At last, a way to find what I need! But will the unvarnished reality of the sitemap really help her? If the site is large, might not the burden of searching through a complete sitemap be just as heavy as searching through the site?
Here’s where abstraction comes in - remember, abstraction is the removal of irrelevant details. For the sitemap of an ecommerce site, that might mean eliminating product pages. For an informational site, it may mean removing entry pages (or even some levels of entry types). The optimal level of detail to include on a sitemap depends upon the goals of the site. As such, I can’t tell you in advance what it will be; I can, however, tell you that for most sites with any significant amount of content, that optimal level won’t be the individual page level.
OK, so for most of the series so far I’ve just been talking - I’ve presented no evidence to back up my claims. In this case, however, I’ve got something that is (somewhat) relevant. Compare this image with this one. The first image is the London tube map as represented in 1930; the second as it was represented in 1933 (and as it is still shown today). The history of the Tube map is a fascinating one for my purposes, as it clearly shows the utility of abstraction in navigation design. Previous Tube maps were realistic, accurately scaled, and hard to use. Beck’s abstracted Tube maps were simple, uniform, and easier to use. To the extent that physical maps and sitemaps are similar, then, abstraction at least deserves a shot. Try it out - your users might thank you.
