Writers often express the concern that topic-based writing cannot handle the big picture. Topics, they complain, don’t provide a way to tie everything together. Thus users get lost in a sea of topics, can’t understand the system as a whole, and can’t figure out where to start.
If you formed your topic set by slicing up a book, then the above is probably an accurate picture of the result. Scattered fragments of a book generally don’t do as good a job as the intact book. No wonder that so many writers, having split their books into topics, hurry so quickly to stitch their topics back together into books, leaving themselves, in terms of information delivery, right back where they started from.
But good topics as not bits of books, and in any case, most books — most product manuals, at least — actually do a lousy job of giving the user the big picture.
Consider how most manuals handle the big picture. You will rarely find a chapter devoted to the big picture. Academic practice (which we all learned, and most find difficult to shake) would have us lead with the theoretical overview. But then minimalism rebukes us and insists that we must get right to the action. What to do with the overview then? It would seem silly to put it at the end, or squeeze it into the middle somewhere, so out it goes.
How then to deal with the big picture? What generally seems to happen is that it gets woven into the chapter structure of the book. As the reader progresses through their sequential reading of the book (as/if), they should gradually pick up the big picture, while constantly being kept busy and entertained by all the practical hands-on stuff they are reading/doing along the way. The big picture is not expressed explicitly; it is to be inferred from the sequence of the book.
No wonder then that writers feel that they need to string topics together in a prescribed sequence in order to give users the big picture. That is how they are used to doing it in books. But that is not how topics work In a nutshell, if the reader needs a way to discover the big picture, write a topic on the big picture. It really is that simple. Write a topic to describe the big picture. Make sure all the detailed-picture topics link to it. Make sure it links to all the detailed picture topics. Now when the reader needs the big picture, they have access to a big picture topic to explain it.
The problem with the big picture topic in the book world is figuring out where to put it. In the book world, authors feel themselves to be responsible for the order in which readers receive information. Ignore for a moment the fact that readers read what they please when they please — the point is that authors still feels that they have to get the book design right. But there is just no right place to put the big picture topic, because there is just no way to know when the reader is going to want the big picture topic.
The great thing about Ever Page is Page One topics is that the reader can read them whenever they like. The author no longer has to worry about when the big picture should be introduced. They only have to make it available.
Finding the end of the string
There is one other issue to consider, however. Getting the big picture of a complex product is not something that happens in a few minutes of reading. We don’t learn that way. We build up a big picture over time, through experience and exposure. No matter how good your big picture topic is, no reader is going to read it through and immediately have the big picture fixed in their heads. As much as anything, the role of the big picture topic, in a properly linked topic set, is navigational. It helps the user find the area of the product they need to focus on, and provides rapid access to the topics that describe that area.
The reader who is looking for the big picture, therefore, is not usually looking for the grand overview. What they are really after is the end of the string. They are looking for a starting point.
This, of course, is the need that the venerable Getting Started Guide is designed to fill. But getting started guides tend to be tutorial in nature. They tend to be built on the assumption that the user wants to be taught, and that all users are looking for the end of the same piece of string. Neither of these assumptions is warranted in the light of what we know about users actual behavior.
What most users want is a way to get going. They don’t want the whole big picture. They just want to find the door marked Enter. But not every user wants to get going on the same issues or in the same order. The way to accommodate different users who are looking for different ways to get going on different projects is with a set of pathfinder topics.
Pathfinder topics
What is a pathfinder topic? It is a topic that shows the reader the overall path for accomplishing some real goal with your product. It is not a “beginner” topic because it does not assume that the user wants to do something very simple for practice, rather than doing a real piece of work. A pathfinder covers the full range of tasks and features in a way that helps the user get a grip on how to attack a problem. But it gives none of the details. The details are left to the many task-oriented topics that make up the bulk of the information set.
The role of the pathfinder is to set the users feet upon the right course. That, in most cases, is why the user wanted a view of the big picture in the first place: because they wanted to work out a plan of attack for a certain kind of problem. A straight-up big picture topic is certainly worth having, but the real work guiding the user down the right path belongs to the pathfinder topic.
Hi Mark,
I agree with what you’re saying about the big picture topics. In a minimalist world we are taught to “slash the verbiage”, but to slash is probably one of many minimalist misconceptions.
From my point of view (you know; SeSAM point of view) user are sometimes searching for the big picture (search situation 1). What can the product do? Can it do X? Or can it do Y?
The answer is a content type that elaborates and explains that “the product can do X” and furthermore many sub types explains for example where the result is visible in product interface, who the receiver of the result is, what the purpose of the result is, how the result is generated, how/where/for what the result can be used and other types of sub types.
Users needs this kind of conceptual information to understand and correct the mental model. And from the big picture about what the product can do be directed to info about how to get the product in delivering the result, evaluate the result and troubleshoot etc.
Hi Jonathan,
Thanks for the comment. My take on minimalism is that it is about minimizing the amount of time that the user spends in the documentation. That goal is not necessarily achieved by reducing the amount of documentation.
The trouble arises when minimalism is applied to the book model with an assumptions that users read linearly. The classic minimalist exercise is to read a book up to the first point at which the reader gets to do something, and cut everything before that. The problem is, classic book design starts with the big picture, even thought that is not the material that most readers want first. Result: the big picture gets cut and is not there when needed.
This is not a problem with minimalism. It is a problem with applying it to a linear reading of a book, despite the basic insight of minimalism that people don’t read linearly, but search for help when they get stuck.
Readers need many types of information, and they need them when they need them. It is our job to provide the information they need, not to tell them when they need it.