The role of the TOC in a bottom-up information architecture

Is there still a place for a TOC in a bottom-up information architecture? Yes, but its role is different.

This is another in my series following up on the questions asked in my TC Dojo webinar on bottom-up information architecture.

Q: Is the TOC dead then? I’m used to structuring content based on an analysis of user tasks, presenting the product secondarily. That becomes the structure? Where do you put the topics?

A: In a very real sense, it is top-down architecture that has killed the TOC. Bottom-up architecture might actually save it, but in a different form and playing a different role.

The basic issue here is one of scale. As I have pointed out before, search does not scale down. Small information sets are hard to search effectively because the search engine does not have enough data to make effective relevance calculations, and users don’t know enough about the scope of the content to form reasonable queries.

TOCs, on the other hand, do not scale up. Put too much stuff in a TOC and it either becomes too long to scan or two deeply nested to navigate effectively. And the more stuff you add, the less consistent any form of classification or organization becomes. You end up with a Frankenbook.

Typical online documentation sets today comprise the material that was once part of several separate manuals. This is essential. No reader is going to tolerate many separate help files. Even for a captive help system, the rule is the same: there is one help system where there might before have been several manuals. This creates a TOC well beyond the scale where it can be effective.

The real problem for tech docs is that the typical size of a major documentation set actually falls between two stools, being too big for a TOC yet too small to be searched effectively. This is why linking is particularly important for tech docs: it is the only navigation tool that really fits the scale of a typical documentation set.

It is also why we still need the TOC, but in a modified form. A comprehensive TOC of the whole doc set will be too large to be useful, but since search will not always be effective either, we need ways to help people find their way round. Smaller, more focussed TOCs can be a big help.

The most important thing about these smaller TOCs is that they should be built around aspects of the subject matter and user experience. This means that they will not all fit beneath each other in a neat hierarchy. Thus there is no longer a question of whether task should be primary and the product secondary, or the other way round. You can have a table of contents of tasks and a table of contents of product features, and a table of contents of anything else you like.

Naturally, you want people to be able to access these lists/TOCs when they are interested in that particular aspect of the subject matter. That can be done both from the top down, by offering multiple TOCs from a home page, and from the bottom up by, for example, linking to a list of roles when you mention a role.

You also have to consider that while the trend in user behavior is definitely toward search, some user will still start at the top, and some will use the TOC as a means for orienting themselves. For something as large as Wikipedia, orienting yourself in the whole thing makes no sense, but for a large doc set, it is still something some people will want or need to do from time to time.

For them you can provide a high-level TOC that is aimed at orienting them to the subject matter and the scope of the documentation set. Including everything would not accomplish this goal. A TOC used for high-level orientation should be designed specifically to accomplish that purpose. In this sense, a TOC is not an external master structure, but a specialized type of topic within the overall architecture.

In some sense, it was always like this. A TOC is just another page in a book, just another page or pane in a help system. It gives a place to other pages only based on the implicit contract with the user that they will start with the TOC — a contract expressed by putting the TOC at the front of a book or in the sidebar of a help system. But search and hypertext break that contract. The TOC no longer gives a “place” to everything else because it no longer occupies the default place itself.

This is what it means to say that every page is page one. There is no one page that is the default place that gives location to all the other pages. Every page is page one, and so every page must give a place to the pages related to it. This also means that no one page has to give a place to every other page directly. Every page will have a place in the network, a place defined by how other pages connect to it. But you may have to traverse more than one page to get there.

It may sound inefficient that the connections can be indirect like this, but information foraging theory shows us that this is actually a more efficient way to navigate content. Successful navigation depends on a strong information scent, and it is hard to provide a strong information sent for every page in a  list of thousands of pages. What is more, information finding is generally a process of wayfinding in the subject matter as much as in the content set. Each piece of content tells us something about the subject that leads us to the next piece of content.

In this world, the role of the TOC is not so much to be the universal starting point, but to be a local junction and distribution point at key points in the network of relationships across the content set. This can certainly include a role as the default starting point for those who do not jump directly to another, but in that role it should provide an entry into the network rather than attempting to map the entire thing from the top down.