In his blog post, Two Competing Help Models: One-Stop Shopping or Specialized Stores?, Tom Johnson explores the dilemma posed by trying to put a company’s help information on the Web using the old tri-pane help paradigm. Do you combine all the help for your product lines into one site with a master TOC, or do you put up multiple small sites with separate TOCs?
Tom shows that there are significant problems with both approaches, but he looks at it only from the top down perspective (which assumes that the reader first finds “the help” and then uses the search and browse mechanisms of the tri-pane help system to find specific pieces of content). Further problems become evident when we consider what is likely the more common case: that the reader Googles for a specific answer and lands not on “the help”, but on a specific page in the help.
To create an example from one of the sources that Tom cites, consider this page: https://docs.palantir.com/gotham/220.127.116.11/ontologymgr/wwhelp/wwhimpl/js/html/wwhelp.htm#href=objEditor.05.4.html
Here the TOC shows where the page is located in the hierarchy of the help system, but what does it do to locate the topic in its subject matter? Very little. In folded form, it is a high-level list of other subjects in the collection, few of which are likely to be relevant to the particular task that brought the user to this page. If the reader has specific questions arising from the people, places, objects, actions, and ideas mentioned in the topic, what does the TOC do to help them find more information on those subjects? Very little. For the most part, pursuing those subjects in the content set would mean starting top-down again at the top level of the TOC.
Every piece of content is rich in subject affinities. That is, the people, places, objects, actions, and ideas mentioned in the piece are connected to those people, places, objects, actions, and ideas, and thus have a connection (an “affinity”) to content that describes those people, places, objects, actions, and ideas. These affinities exist in every piece of content, but in most help content produced today, no means is provided to help the reader follow those affinities.
Yet it is those affinities that actually define the place of a topic in its broader subject area. A traditional book index is an ordered list of the subject affinities in the book. A hypertext link in a Web page is the expression of an affinity between the content in which it occurs and content it links to. Subject affinities anchor a piece of content in time, culture and the reader’s experience. Without subject affinities, it would float meaningless like a piece of nonsense verse: grammatically scannable, but semantically vacuous:
‘Twas brillig, and the slithy toves
Did gyre and gimble in the wabe;
All mimsy were the borogoves,
And the mome raths outgrabe.
When you seek to locate a piece of content in a collection, it is the subject affinities of the piece that provide the means to relate it to the rest of the collection. “Locating a piece of content in a collection” is another way of saying, “organize a collection of content”, but it comes at it from a different angle. It is a topic-centric way of looking at it, rather than a collection-centric view.
Adopting a topic-centric view of organization is important because as our collections become larger and more dynamic, it becomes more and more difficult to establish and maintain a static organizational frame for an information set, or to navigate a collection using a fixed table of contents.
When the user has landed in your help by way of a Google search, in search of information on a particular problem they are trying to solve, what kinds of additional information are they likely to need if the current topic does not entirely satisfy their needs? It is not information from other general categories of the help system, which is what the TOC provides. It is information related to the subject affinities of the current topic.
Consider this very brief Wikipedia article on the Manicouagan crater in Quebec: http://en.wikipedia.org/wiki/Manicouagan_crater
Here are just a few of the subject affinities it has:
- Geographic coordinates
- Municipal location
- Place in time
- Relationship to historical events (extinctions)
- Photography from space
The article makes every one of these affinities navigable, and it does so without using a table of contents, except the tiny one for the article itself. (Actually, there is a “Contents” link in the left sidebar of the article. Click on it if you want to see just how useless a TOC is in a really large information set.)
If you want to explore any of the subject affinities of this brief article, you can do so simply by clicking on a link either in the text itself, or in the structured sidebar, which classifies the Manicouagan crater according to the common characteristics of such things, or in the table at the bottom that locates the crater in the fields of Geology and Astronomy.
- Want to find out more about the area of Manicouagan: follow the links.
- Want to find out more about Quebec: follow the links.
- Want to find out more about impact craters: follow the links.
- Want to find out more about the Triassic period: follow the links.
- Want to learn about the study of impact craters: follow the links.
- Want to learn about the spacecraft that took the picture: follow the links.
Every topic in your content set shares multiple subject affinities with all kinds of other topics in your content set. Readers who navigate through your content do so to get more information on a subject they are reading about: they follow subject affinities.
Neither a big TOC nor several small ones provide a good way for them to follow the subject affinities they are interested in. Using one large TOC buries the specific affinities of interest in the vastness of the full information set. Breaking the content up into several small collections will mean some of those subject affinities will stretch between different collections, meaning they won’t occur at all in the TOC of the current collection.
Here’s the bottom line: there is little value in providing a manifest of the entire information set in the context of every individual topic. Readers who want to navigate from any one topic will do so by following the subject affinities of that topic. To enable their navigation, provide them the means to navigate the subject affinities of the topic. Do this through linking, through linked structure, and through linked categorization.
This is a profound change from how we are used to organizing content. Traditionally, there has been one navigational schema for the entire content set, and each piece of content has been fitted into a pre-ordained place in that schema. Navigation is fixed and external to the content. Content hangs off the hierarchical table of contents like ornaments on a Christmas tree.
But in the Web model, each topic is a navigation hub in its own right. If there is an external navigation, it is secondary, and very often compiled from information in the topics themselves. Topics organize themselves by expressing their subject affinities and linking to other topics along the lines of affinity. The navigational view from every node it unique, and specific to that node.
When an information set grows beyond a certain size, there is no other way to make it properly navigable. Seeing everything at once is too overwhelming or general. Artificially segmenting it is too confining Navigation must be specific to the locale you are in, and changes every time you change you locale. This way, you can have an arbitrarily large information set with manageable navigation at every point, and still have the ability to travel very far across it by following were the subject affinities lead.
This may sound like a big leap to make, but lots of stuff on the Web already works like this. There are no shortage of examples to follow. Wikipedia alone provides a rich vein of navigational ideas to mine. The challenge is not to find new ways; the challenge is to stop thinking in terms of 20th century technology. The navigational relics of books and tri-pane help systems are wholly unsuited to a 21st century hypertext world.