Argus consultants, Steve Toub (an occasional contributor to Web Architect) and Chris Farnum, recently conducted a small usability study on the design of tables of contents. Besides wanting to increase their experience with usability testing, they were trying to get a sense of what is the best way to design a table of contents for a Web site.
Steve and Chris compared five different versions of a table of contents for the Argus Clearinghouse. Each person in the usability study group was asked to try four of six possible predetermined queries, afterwhich, they were asked to describe the one they liked best. This was by no means a scientific study, but rather one that Jakob Nielsen would refer to as discount usability.
Figure 1: Users seemed to like this. (Note: The page continues below the browser window.)
Figure 2: ...better than this.
Their findings were interesting: The subjects preferred the longer, more information-rich tables of contents (as shown in Fig. 1) over ones that had just major categories or major categories with scope notes (as shown in Fig. 2). In other words, they preferred a broader, shallower hierarchy, with many options on a single long page, over fewer options per page but a deeper hierarchy to click through. This seems to be increasingly corroborated by other, more scientific studies we've encountered. A paper by Kevin Larson and Mary Czerwinski, both of Microsoft Research, provides the results of a study with similar results, as well as excellent pointers to supporting literature. And even informal anecdotal surveys I've taken seem to point in the direction of broad and shallow over narrow and deep hierarchies.
This chills my blood.
Why? Because I've always felt that it was a really bad thing to present long pages chock full of links that users need to wade through. Wouldn't they get lost scrolling through a single page just as easily as if they have to click their way through a hierarchy of pages? Or simply forget (or not bother) to scroll down past the part of the page that shows in their browser?
I've seen so many pages that labor to compress as many links and other pieces of information as possible into that very limited piece of real estate known as the browser window. Some are monuments to page layout engineering. Granted, it's not a table of contents, but take a look at Excite's main page. It has (if I counted right) about 23 content groupings and 145 links. Pretty impressive! But, well, maybe it's just me, but I find it very difficult to navigate this page.
Figure 3: The first part of Excite's main page...
Figure 4: ...followed by the second part...
Figure 5: ...and finally, the third part. Excite is definitely not the tabloid of portals.
I've always felt that pages like this one miss the point: Their design addresses the question of, "How do we get a zillion things to fit onto one screen?", instead of "How do we select the right subset of things to include on the screen?". But, if the studies are right, then I'm wrong. Or am I?
Bear with me for a moment: I was leafing through Scott McCloud's book, Understanding Comics, and it really opened my eyes. What really struck me was his discussion (starting on p. 29) of why our culture is enthralled by the "simplified reality of the cartoon." Scott describes the power of reduced-content cartoon images as "amplification through simplification." Check this out:
Figure 6: How much information do you need to realize that a human face is being represented?
The iconic image to the far right is understood to represent the near-photographic image to the far left. Even if you saw it alone, without context, you'd know what it represents. Scott observes: "the fact that your mind is capable of taking a circle, two dots and a line and turning them into a face is nothing short of incredible! But still more incredible is the fact that you cannot avoid seeing a face here. Your mind won't let you!"
Enough about lines, dots, and circles: My point is that perhaps we need to be thinking about a simpler version of pages that use just enough information to tell the user the right story. Or, put differently, is there a "circle, two dots and a line" analog for, let's say, portal pages? Are there ways to give the user a useful model of what's there and yet display less content?
My gut feeling is that there is, but we may need to wait for these mental models to emerge over time, just as our ability to understand and extrapolate from cartoon images didn't happen overnight. Despite the reams that have been written about Web design over the past few years, the Web is still pretty short on design conventions that resonate the way that a line, two dots, and a circle can.
More on bottom-up architecture
In my last column, I introduced the concept of "bottom-up" information architecture, and some of the challenges we'll face as we try to get at the guts (really, smelly nasty entrails) of our content for purposes of document structuring and indexing. I mentioned XML in this context, but I'm afraid that for various reasons, the column came across as being more about XML than anything else. And, based on the overwhelming email response that I've received, a lot of you are really interested in XML. So, I should make something clear: I'm not an XML expert, although, like many of you, I'm learning a lot more about it very quickly. I do, however, feel that I have something to share about bottom-up architecture. But did I do it well in that last column? I don't know; I think I lost some of you. Heck, I'm not totally sure I completely know it myself. So, I'm reproducing a reader's email (and my response) that I hope will help clear things up:
I just read your article, "Bottom-Up Architecture" in Web Review. I must say you left me pretty confused. I finished it not having the foggiest idea what you mean by bottom-up architecture vs top-down architecture. Your examples did not help me understand your point at all.
Say I have to design an intranet for a medium-sized company. I assume I would begin this task by looking at all of their current internal documents, business processes, and work flow. I would then try to design the intranet to make the documents accessible to the right people at the right time, and to facilitate the processes and workflow. Would I be using top-down or bottom-up? What's the difference?
Every information system design or redesign involves a bit of both. Top-down would be the focus when a client asks you to design the intranet from scratch. Your job would be to ascertain what your client's goals are, who the target users are and what sorts of information and functionality they need, and what sort of constraints (e.g., budget, time, organizational politics) are present. Next, you would develop the top-levels (starting with the main page) of an information architecture which addresses the issues raised in your research. Finally, you would determine specific types of content needed to flesh out the architecture.
With a bottom-up approach, the client may tell you they have a large and disorganized collection of documents that need to be made more accessible. You might look for patterns in those documents that would allow you to determine a manageable number of common types. You then might develop templates to support these types and reauthor content along these lines. You also might determine ways of manually indexing these documents using controlled vocabularies which in turn support improved searching and browsing (through menus). And finally, you might devise rules for linking document types. All these efforts in turn have an effect on the top levels of the architecture.
Hope that helps!
