I got a number of really good questions following my TC Dojo session on Bottom-up Information Architecture (below).
I want to address the questions in a little more depth than was possible in the webinar.
Q: I’ve attended multiple Every Page is Page One webinars. They get bogged down in theory but never explain what tasks working technical communicators should perform. “Books may be bad” but at least people know what steps to take to make one. What tasks and steps shall one perform to implement this wondrous new content architecture?
A: This question astutely identifies the problem of moving to an Every Page is Page One / Bottom-Up Information architecture: people know the steps to make a book. The steps to create a bottom-up information architecture are not necessarily so obvious or well known.
Part of this is simply because bottom up architectures are the child of the digital age, of search and of hypertext. These things have not been around nearly as long as paper, and the top-down architecture of books and libraries. The first stage of adopting to a new technology is usually to mimic the old. Thus some early locomotives had legs.
“Bruntons Traveller” by Unknown – http://www.catskillarchive.com/rrextra/odcuri.Html. Licensed under Public Domain via Wikimedia Commons.
It takes a while to adapt our thinking, our processes, and our tools to fully embrace the possibilities of a new technology.
So how do you go about implementing a bottom-up information architecture?
The first part is straightforward, and you can do it in whatever tools you are using today. Start to write Every Page is Page One topics. If you are writing manuals, start writing them as collections of Every Page is Page One topics. If you are writing help systems, start writing each help topic as an Every Page is Page One topic.
Remember that in a bottom-up information architecture, the pages themselves are structural parts of the architecture. A bottom-up architecture starts and ends with good pages. This also means that you do not have to throw away your current top-down architecture in order to start building your bottom-up architecture.
- Make each topic self-contained and so that it functions independently of other topics. Eliminate any kind of linear dependencies. No previous. No next. A topic may be related in all sorts of ways to other topics, but it should make no assumptions about what the reader has read before and it should not tell them what to read next.
- Give each topic a specific and limited purpose. This does not mean answer only one question or relay only one fact. Such a topic probably would not be self-contained. It means to play a clearly defined role in preparing the reader to act.
- Make each topic follow a clear topic pattern. Self contained topics that have a specific and limited purpose tend to have a definite and well defined shape. They say the same things in the same way in the same order. A clear topic pattern helps ensure the topic is complete and correct, gives it a strong clear information scent, and helps the reader move around quickly within the topic.
- Establish the context of each topic clearly (and succinctly). The reader may have arrived from anywhere, and they are evaluating your content to see if it is worth their time. The context of your page has not been established by any part of the navigational path that led the reader to it, so the page itself must tell the reader where they have landed and what to expect.
- Keep each individual topic on one level. Readers may need content at many different levels of abstraction in order to fully equip themselves with the information and the confidence to act. This can include very detailed procedural information and very high-level concepts or workflows. But every reader needs different pieces and in different orders. Keep each topic on one level and let the reader decide when they want the details or the big picture.
- Assume the reader is qualified. A topic with a specific and limited purpose is written for the person who normally performs the task it describes. Recipes are written for cooks. API references are written for programmers who know the language of the API. Readers who are not qualified can use other content to fill in the gaps in their presentation, but if you try to answer all their potential questions in a single topic, that topic will become a book and will not work well for any reader. The overall topic set should serve the full range of your intended readership, but each individual topic should serve an appropriately qualified reader.
- Link richly along lines of subject affinity. Remember that a topic or page in a bottom-up architecture is a structural piece of that architecture. The connections between topics are formed by the links within the topics themselves. Links allow imperfectly qualified readers to get the background they need. They allow readers who have landed in the wrong place to get where they need to go. Readers whose interest has been caught by something in one topic need a way to get to topics on the subject of interest. Links keep readers in your content set rather than sending them back to Google. Links are fundamental to a bottom-up information architecture.
Okay, but these are principles. How do you take those principles and apply them to your own content? The best way is often by studying examples, which is why I have started a series on topic patterns. That series will examine many important topic patterns and will hopefully help you to see how to apply these patterns to your work, or help you develop topic patterns of your own. If you need assistance, Analecta Communications can help you with your topic type designs. We also offer a training course on writing Every Page is Page One topics.
But while you can write Every Page is Page One topics in any editor, when it comes to managing the content, and managing the process of creating and maintaining it, things are not quite so simple. I will outline some of the options in part three of the series.