Reference vs. Learning in a Bottom-up Information Architecture

Do reference and learning require different organization in a bottom-up information architecture? This is another in the series of posts addressing questions from my TC Dojo webinar on Bottom-up Information Architecture.

Q: Is there a difference in looking for a specific information fact (such as the depth of the Manicouagan crater) versus a search for understanding a larger information set, such as the development and formation of craters in general? Would the latter type of search merit a more hierarchical mini-TOC to navigate through the content?

A: There is definitely a difference between looking up a single fact and seeking to understand a subject. The interesting question is, do people use different resources to do these two things, or do they use the same resource in different ways.

If we could rely on them always using distinct resources for learning and for reference, we could design each resource solely for its intended purpose, in which case, addressing the desire to understand with a fairly lengthy essay would make a lot of sense, and  a mini TOC would be a good way to introduce this essay.

A TOC is this role is not a navigation tool. If your intent is that the reader will read a piece all the way through, they don’t need a TOC as a navigation aid — the only direction they need is onward. The TOC, in this case, is actually a piece of advertising. Its role is to establish the information scent of the piece, to assure the reader that this piece addresses the subject they are interested in.

For pure reference, on the other hand, where the reader is trying to locate a simple fact, a long piece with a mini-TOC does not make a lot of sense. A pure reference is a database and the appropriate interface is one of the many forms of database lookup tools available for various media.

In neither of these pure cases, therefore, is the TOC useful as a navigational tool.

The problem is, the pure cases are not the cases we find very often in the real world.

In principle, at least, we used to do learning in the classic waterfall approach. That is, you chose a profession, or at least a project, and then you read all the books, passed all the tests, graduated, and then commenced work based on the knowledge you had acquired.

It never worked that way in practice, of course. Even in the learning phase of our lives, we had to do a lot of work in order to learn, and in the working phase of our lives, we had to be continually learning because our formal learning never covered all the situations we encountered in the real world.

But in the paper age it did make a certain amount of sense to devote some time to study before commencing a project. Looking stuff up was relatively expensive, so caching basic knowledge and techniques in your brain before starting work was an efficient strategy.

Today it is so much easier to look stuff up as you work that it is often more efficient to start sooner and to look stuff up as you go. (Usual caveats about working with dangerous equipment and sensitive data, etc.)

This does not only mean looking up facts. It also means looking up design principles and concepts. It means learning in the course of doing. More precisely, it means proportionally doing more of the learning in the course of doing than previously.

A typical pattern of conversation on StackOverflow goes like this:

How do I mangel right-handed widgets.

Why do you want to mangle right-handed widgets?

I need widgets that work left-handed.

You should use widget inversion, not widget mangling to get widgets to work left handed because…

In other words, our quest for a single specific piece of information often leads us into discovering a concept we were not aware of, which changes both how we do our task and how we understand our tools and approach future tasks. Reference and learning, in other words, are all mixed up with each other.

Separating out reference material and learning material (task/concept/reference) makes sense if we think of our job as putting information in buckets. But real human information seeking does not break down into such neat and distinct categories. In the real world, reference and learning are deeply intertwingled.

Nowhere is this intertwingling of reference and learning more evident than in API reference documentation. The typical API reference page is, in fact, both a database table and an essay. Examples of the reference essay pattern abound. Here are a couple of examples from the Python documentation:

https://docs.python.org/3.4/library/xml.etree.elementtree.html

https://docs.python.org/3.4/library/re.html

At the beginning I asked whether readers use different resources for learning and reference. The answer is pretty clearly no, for a number of reasons:

1. Reference and learning are deeply intertwingled. We rarely do one without the possibility of the other occurring.
2. While we do still sometimes set time aside for reading and learning, we are more than ever likely to dive into a project and learn as we work.
3. We tend to turn to the same resource each time: the same book if we have books; Google if we are on the web.

So while there is certainly a case for pure references and pure textbooks in certain cases, there is also a very large space in the middle where learning and reference are intertwingled, both in the actions of the reader and the design of the content.

In these situations, a mini-TOC on a longer topic does play an important navigational role. It helps to establish context for the learning reader, but also directs the looking-stuff-up reader to the individual piece of information they need. More than this, it also places that information in a context which may prompt the reader to realize that they actually have something to learn.

Topic TOC vs TOC of a subset

To this point in my answer, I have assumed that mini-TOC means the TOC present within a single topic, such as the mini-TOCs found in many Wikipedia articles. But there is another possible interpretation of “Would the latter type of search merit a more hierarchical mini-TOC to navigate through the content?” which is that you have several separate pages chained together by a prescriptive table of contents.

I would strongly discourage this approach, for several reasons:

• Who is to say, in a bottom-up information architecture, that the reader will arrive at this TOC or at the first topic it lists?
• Unless you are writing a book (for a reader who actually wants to sit down for a good read) then you probably don’t want to make your essay longer than will fit on one web page.
• What happens to the pages in the middle of the sequence described by this TOC? Are they still Every Page is Page One topics in their own right? And if they are, what is it about the overall order described by the TOC that compels these stand-alone topics to be read in a specific order?

In many cases, I suspect, the desire to create a mini-TOC of a subset of pages arises from the fear of making a single longer page covering the same material, because some readers may not need all the material that a single longer page would cover.

The truth of the matter is that you cannot perfectly size any topic for a single information need. The intertwingling of reference and learning activities not only permits, but demands an intertwingling of learning and reference content.

This is not license to go back to writing book length material for everything. The intertwingling of learning and reference arises from a learning-as-you-work style that has no time for long reading. But it also means that infinitely segmented content does not work either. Every Page is Page One and Bottom-up Information Architecture are about finding the happy medium and supporting the reader in navigating the content set in the unique way that supports their present task and knowledge.

Series Navigation

<< The role of the TOC in a bottom-up information architectureSearch ranking and bottom-up architecture >>