- Bottom-Up Information Architecture Q and A – Part 1
- Bottom-Up Information Architecture Behind the Firewall
- Bottom-Up Architecture Q and A: Organizing the Site
- The role of the TOC in a bottom-up information architecture
- Reference vs. Learning in a Bottom-up Information Architecture
- Search ranking and bottom-up architecture
- PDF in a Bottom-up Information Architecture
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.
What does it take to write an Every Page is Page One topic? That is the subject of the next TC Dojo session, and if you want more detail, see the book, but the basics come down to seven principles:
- 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.
Good post. While I agree that content and the information it is intended to communicate must be built from the granular (bottom) toward the aggregated (up), I would suggest that the process must actually be bi-directional. The development of topics and their architecture must be based on a coherent strategy from the top down. Only with a clear strategic direction can the detailed decisions about topic and content granularity, linking, minimum retrievable unit definition and a host of other factors be made properly.
In a sense, the strategic goals establish the desired target environment and process support, then the content architecture executes that target within the constraints that exist from data sources, authoring resources, content complexity, timing, funding, revision patterns and other limiting factors. In the middle of these two, assuming that we don’t live in a perfect world where anything at any level is possible, an implied negotiation must take place to bring the architecture in line with the constraints so that what is tried is indeed possible and supportable.
I have seen many projects that didn’t heed this constraint, ending up with a mess that neither accomplished its goals nor was supportable within the resources available.
Thanks Mark for putting this important subject front and center.
Thanks for the comment, Barry.
However, I think we are at cross purposes. You seem to be talking about the process for creating content, whereas I am talking about the information architecture of the content itself. This is not about whether the content is created from the bottom up, but whether it is read and navigated from the bottom up.
The process for building the content is also important, of course. And while a top-down information architecture pretty much demand a top-down development process, that is not the case for a bottom-up information architecture. You can create a bottom-up architecture using either a top-down or bottom up process.
A good example of a bottom up development process is Wikipedia. Wikipedia does have overall goals and principles to guide contributors, of course, and a team of editors to enforce them. But you don’t need permission from central authority to create a new topic. If the topic you create violates the principles of Wikipedia it will get flagged by members of the community and may eventually get removed, but there will also be lots of opportunity for you or others to bring it into line.
One of the byproducts of the Wikipedia process is that it tends to be updated with new information virtually as soon as it happens. No central authority has to approve the update, so it can happen very very quickly across a huge range of subject matter.
Typical top-down processes tend to lead to a “wedding day” style of publishing in which a team works very hard to bring everything to a point of perfection (or at least, approval) and then published it all as a block. Updates after that point are costly and difficult, because of the cumbersome approval process, so the published content rapidly goes out of date.
A bottom-up process, on the other hand, does not make publishing a grand event, but constantly publishes content as it becomes available and constantly update it as it goes out of date. This is not an ungoverned process. Oversight occurs, but it takes the form or monitoring the content and people’s reaction to it over time. The result is a content set that is always slightly imperfect, but is constantly being monitored and fixed to keep it at a more or less constant level or reliability and currency.
A top-down, wedding day process, on the other hand, can get badly out of date and significantly far behind current knowledge and practice. It is rather like the stopped clock that tells the right time only twice a day.
A bottom up process is therefore an excellent way to maintain a high level of accuracy and currency in an organization’s content set, providing a real and disciplined bottom-up process is put in place. Whether this will sit well with the top-down culture of many organizations, not to mention regulatory environments created in the paper age, is another matter.
What is important to emphasize here is that you don’t create a bottom-up information architecture simply by throwing away your top down architecture, and you don’t create a bottom-up process just by throwing away your top-down process. Top down and bottom up both require goals, processes, and discipline. The mistake it to regard having goals, process, and discipline as synonymous with top down.
Ultimately, you are in control of whether your company and its content contributors use a bottom-up or top-down process. What you can’t control is that your readers seek information using a bottom-up approach. If you want to meet their needs, you need to start creating a bottom-up information architecture. Whether you do that using a top-down or bottom-up development process is a separate question.
Thanks for the response. Actually, I think we are more or less on the same page. My point is not based on the content creation process so much as it is on the architecture within which content will ultimately be created. For example, the goals of an information architecture may be general, technical, process-driven or any number of others, each one dictating a certain way content must be designed and in which it must be created for use.
You mentioned Wikipedia. I have some familiarity with the encyclopedia world having been involved in developing the content management architecture and system for one of the big three several years ago. Because the systems environment was aimed at the online version of the publication, we used XML in an architecture that made it possible for association and reuse of virtually every component of every article and for highly flexible navigation path development. Because the articles are mainly written by outside experts, the strategic architecture also supported authoring with remote, unconnected workstations using the XML editing software chosen.
The automated print version of the same publication, having been in existence since the early-70s, had used layout formats and software, neither of which lent themselves to logical navigation beyond the specifics of index, footnote, see and see-also references. Because of the layout software in use, authors also had to submit their articles in both WP format to be re-authored and tagged in the required format for the print edition and in XML for the online edition.
This, I think, illustrates the point that had the initial automation strategy, coming as it did from the top down, taken into account the need for both print and, at that time a future need for an online version, the architectural goals could have called for and supported a single, integrated architecture, using SGML, that would have obviated the need for duplicate content and processes to support print and online editions. That it didn’t (even though it could have even back then) saddled the organization with a very complex and expensive need to harmonize the two.
So I think we agree. I am merely calling attention to the importance of thinking through the functional and strategic goals before the detailed decisions are begun. While there are some architectures that can be predicted from the bottom up, aircraft maintenance in S-1000-d for example, many are not so predetermined, making strategic decision making up front an important part of the mix.
I enjoy the exchange and definitely see your points.
Thanks for the reply, Barry. However, we are still talking about different things. Whether the content is created in XML, SGML, HTML, or RTF has nothing to do with the information architecture.
Information architecture is the set of relationships existing between and within elements of content as they are presented to the user. In a top-down architecture, pages tend to be presented as leaves on a tree. The path from one leaf to another is through the tree. In a bottom-up architecture, pages tend to be nodes in a network. The path from one page to another is a direct link, or a series of links through intermediate pages, or a long jump using search.
None of this has anything to do with the file formats or structures used for authoring.
I do agree, of course, that taking a structured approach to authoring is enormously beneficial, whether your information architecture is bottom up or top down. In fact, it is hard to do the rich systematic linking the a bottom-up architecture should have without using structured techniques (though not the structured techniques in common use today). But these are still two separate issues.
Boy, a conversation by post is really tough. Wish we could sit down over a beer and talk out the issues involved. Think I see what you are positing, and I believe my position is valid as well.
The only thing I would suggest is your suggestion that information and content architectures are different things. I agree but must suggest that information architecture can only be made concrete through content architecture, given that information, in the normal definition, is a process that occurs in the user when he or she interacts with appropriate content. Thus I believe that while one can describe an information architecture in general terms, its realization is only possible through a content architecture designed to support the processes inherent in the information objective.
(-:
If by content architecture you mean the architecture of the tools used to create content, then yes, information architecture can only be made concrete through content architecture, which is why part three of this webinar series is about tools.
Indeed, I think that many writers, information architects, and content strategists gravely underestimate how much the content architecture they choose is prejudiced towards a particular information architecture. People tend to dismiss tools as if tools had no influence on the quality or design of the work. That is not true.
Every tool is build around a set of presumptions about information design. As long as your chosen information architecture fits with those presumptions, you probably won’t notice. But as soon as you have a tool whose presumptions do not fit what you are trying to do, you will feel it badly. A good case in point is people who buy wikis for the collaboration features and then struggle to get them to produce manuals.
This does not mean that you can’t produce one information architecture with a tool designed for another, but it will require extra work and extra awareness.
I do hope we get a chance to have that beer some time!
I am happy you two could not sit down over a beer. This conversation offers many insights for people like me – without you two noticing. Thanks for conversing through comments!
Thanks for the comment, Mugdha.
Indeed, one of the great benefits of the Web is that we can have public conversations that anyone who is interested can listen to — at any time they want. That is a really important benefit of the Web, and it represents a profound change in the technical communication landscape as well. Virtual eavesdropping on other people’s requests for help is not one of the major ways that people find answers to their technical questions.