This is the second of the questions from my TC Dojo presentation on Information Architecture Bottom Up.
Q: What happens when the information is behind a wall, such as proprietary applications? How is a bottom-up approach better in that type of scenario?
A: The Web is the ultimate bottom-up information architecture. The Web is far far to big and too complex to ever be navigated top down. Yahoo’s top-down directory of the Web, created when the Web was still relatively small, was recently shuttered, after having been irrelevant for many years.
At the other end of the scale, a booklet of a few pages cannot really be navigated bottom-up. It does not offer enough entry points, and any attempt to search it would be futile. Unless you already knew exactly what was in it, almost no query would deliver any hits. Such a document can only be navigated by scanning or simply reading through. Make it just a little bit bigger, and a TOC becomes practical, while search remains problematic.
Put those small pieces of content on the Web and people will find them with Google. Search works there because it searches everything. Few searches will turn up our small booklet because it is not relevant to most of them. But it will show up where it is relevant.
But it is a different story when it is not on the Web.
The first problem is that if it is not on the Web, people may not try to navigate it at all. For an increasing number of people, the first thing they do when they have a technical question is Google for an answer. If they don’t find one, many will conclude there isn’t one.
I hear some writers say that they want to avoid sending the reader off to Google. But this assumes that the first place the reader looks is in the manual, and that they go to Google only if the manual fails them. That is not how it works today. People are more likely to go to Google first and the manual second or never.
Except in the most extreme circumstances (missile silos, nuclear power plants, Fort Knox) we need to get our content on the Web if we want it to remain relevant.
For various reasons, though, many organizations still exist in keeping their technical content behind a login. Until we can convince management that it needs to be on the Web, we have to create content that works in isolation.
Content does not have to reach the scale of the Web to become too large for a single TOC. Most significant documentation sets are substantially bigger than a single TOC and handle effectively. At the same time, it is not workable in an online environment to offer many individual books or help systems.
People expect to search from one place. When books were delivered in the box with a product, we narrowed the search field down for people by putting the right book in the right box. But when people look for information on our web site, they have to narrow the search field for themselves. If you have only a few products, people may be able to do that by choosing from a list, but if the list gets long or complex, people are more likely to turn to site search.
People turn to search because the information space is too large and complex to navigate top down, and because Google has taught them that searching works.
The problem is, searching a site does not work nearly as well as searching the Web. Search is a big data problem. It is about identifying the preferred resource for a given query, and a Web search engine like Google has millions of data points about the queries people make and the resources they choose to draw on to make good recommendations. Your site search as little or none of that. The search in your help system has still less. Even if they have the technology to search like Google, they don’t have the data.
What all this means is that if people do log in to your site to use your documentation, they are probably going to start by searching, and their search has a good chance of not working very well.
Relying on a TOC alone is not going to help much, because the TOC will probably be too big to be useful, and people are not particularly likely to use it, since Google has trained them to search. In other words, your readers are likely going to try to navigate your material in a bottom-up fashion, and the attempt may well be disappointing.
To improve the odds of the reader’s bottom-up navigation attempts being successful, the best thing we can do is to create a bottom-up architecture for our content.
Since one of the pillars of bottom-up architecture — search — is compromised by having too small a data set and not enough user history, we need to make sure that the other elements of a bottom up architecture work really well.
Those elements are Every Page is Page One topics, and rich and effective linking.
Every Page is Page One topics ensure that the reader always lands on a page that functions independently. They do not have to work their way backwards through a TOC to find a starting point or puzzle out references to points made in “earlier” topics.
Links ensure that if the reader is not in the right place, they have a way to get there rather than going back to the search results. And if the reader needs additional material to fully understand what the current topic is talking about, links make topics on those subjects easily accessible.
John Carroll’s research showed that people were navigating content bottom-up even before the Web. The Web has confirmed and supported that behavior. Readers bring the habits and expectations of the Web to behind-the-wall content, but many of the Web’s best information finding features are not available behind the wall. Given this, creating a robust and effective bottom-up information architecture is even more important behind the wall than it is for material visible to the public Web.