Topic size: Finding the narrative minim

By | 2012/09/11

The first question we need to address in seeking a theory of topic-based information design is the perennial “how big is a topic”. Whether we are talking about the reusable blocks that DITA calls topics, or about Every Page is Page One topics that are sized for a reader, the question of size is always the first one that people ask.

In the discussion of Keith Schengili-Roberts’ blog post, What Size Should a DITA Topic Be? (the discussion is on a closed LinkedIn community, DITA Metrics, not the blog itself), Katriel Reichman suggested “one idea, one topic”. Another approach that I have used in the past is to say that a topic supports one task.


Tasks and ideas are both fractal in nature, which makes them a poor guide to topic size. Free image courtesy of

The problem with defining topic size in terms of ideas or tasks, however, is that ideas and task are fractal. That, is an idea is made up of other ideas, a task is made up of other tasks. Fractals have the property of being self-similar at every scale, meaning that if you zoom in part of a fractal, the part has the same structure as the whole. Thus anything that is fractal in nature is not useful as a guide to scale — it looks the same no matter what the scale. What we need is some unit that is not fractal. In  his blog post Misconceptions about Topic-Based Authoring, Tom Johnson talks about how documentation compiled by gluing pieces together often does not work because the result lacks a narrative flow. In the comments that followed, the role of narrative was debated: did narrative matter anymore, if readers skip and skim? This post is an expansion on the notion that came to me in contributing to that thread. What I said there was:

For whatever minim of content that reader needs in order to get back to their task, they will get to their task faster if there is good narrative flow within that minim.

I’ve been thinking since then about this idea of a narrative minim (that is, the smallest unit of narrative). I am beginning to think this is the long-sought answer to the question “how big is a topic”. The answer is, a topic is a narrative minim.

Why do I like this answer? Because a narrative is not a fractal. The chapters of a novel are not short stories. Scenes from a film are not short films. Zoom in on part of a narrative and you will not find perfect miniature narratives. What you will find depends on the genre. In technical communication, zoom in on a narrative and you will find statements.

Out of context, those statements may be meaningless. The statement “Press the Red button.” is meaningless (or, at least, useless), unless you know which red button it is and when, and for what purpose, you should push it. This is what a narrative does in technical communication: it puts statements into context, giving the reader not only the action, but the reason and context for acting.

Big Book

A book-length narrative is not composed of smaller narratives. It can be hard to pick up the narrative flow if you drop into the middle of a book. Free image courtesy of

This is why books are unsatisfactory for readers who skip and skim through content. They arrive in the middle of a narrative, and while they may find correct statements, those statements are insufficient in themselves because the do not establish the reason and context for acting. To establish reason and context, the reader has to work backwards through the text to pick up the narrative thread.

Narratives work by placing certain facts of ideas in evidence, then drawing out a conclusion from the threads of those facts and ideas. Plunge into the middle, and you have missed the submission of some of those pieces of evidence, and the argument from them makes no sense to you.

A narrative, no matter what its size, is designed to be taken whole. Its parts are not functional in themselves. Not every book is a single end-to-end narrative, and it is by no means impossible for a reader to bootstrap themselves into the middle of a narrative without having to go back to the very beginning, but attempting to extract meaning from a long narrative is certainly more taxing than extracting it from a shorter one.

The narrative minim is the shortest narrative that accomplishes the purpose of a narrative.

This is true, of course, only insofar as the short narrative is complete enough to perform the function of a narrative in tech comm: to establish the reason and context for action. The shortest narrative that accomplishes that purpose, in any given case, is the narrative minim.

To be sure, an unsupported statement may well be sufficient for a particular reader. A reader who already possesses the reason and context for action, and lacks only one piece of information, can get by with a mere statement. They do not need the whole narrative.

They do, however, need the statement to be contextualized sufficiently that they can recognize it as the right statement. To this extent, even the reader who skips and skims through a narrative benefits from the narrative structure, for it provides the context that authenticates the one or two statements they actually read.

In an era of impatient readers, where few are willing to take the time to read a whole book before starting work, the topic provides the shortest effective piece of communication. The topic is the narrative minim: the smallest narrative that can be written and still be a narrative.

In her blog post, A Steep Price for Bad Documentation, Rahel Bailie observes:

Skimping on documentation quality is often rationalized away by claiming that users don’t read it. The reality is that while customers don’t read a document from front to back, they do refer to the document when they’re in trouble. And when they can’t find that single, critical piece of information, their perceptions and expectations change. They stop using the documentation and revert to calling the vendor’s support line – a far more costly alternative to looking up an answer – because they assume that none of the needed answers will be found in the documentation.

But unless the user is fully contextualized and is genuinely in need of only a single data point, what the user needs when they are in trouble is the narrative minim that will get them out of trouble. In many cases, even when the user does dive into the book, they can’t find the narrative minim, either because the books narrative is at too large a scale, or because it has no narrative shape at all, at any scale.

This is why we need topic-based content: because the book-scale narrative is too big for the modern impatient reader. They want quick answers — but they also want answers that work. They want the narrative minim.

How long should a topic be: for whatever subject it treats, it should be the narrative minim.

A chunk of text sized to optimize for reuse is not necessarily (and, indeed, not likely to be) the narrative minim. Can you create a narrative minim by stringing together pre-existing chunks of content?

Perhaps, but it will certainly require deliberation and care to do so. What is clear is that without that care to construct the narrative minim when reusing chunks, the result will not be an effective narrative, but a collection of statements without narrative flow between and through them. As such, they will not establish the reason and context for action. This is not to say that the reader, with a certain amount of diligence, won’t be able to figure out the reason and context for action. but is to say that it will make the reader work harder for it, and modern readers are not known for either patience or dilligence.

Our first care, therefore, must be to design and write topics that are the narrative minim.

10 thoughts on “Topic size: Finding the narrative minim

  1. Alex Knappe

    I think if you are trying to structure a document into topics, you should first of all ask yourself: What am I trying to accomplish? What is your goal?
    If you’re structuring your document into topics just for the sake of it or because DITA suggests you to, then you’ll be ending up cluttering an endless amount of topics for no reason.
    So, generally speaking, topics have to be use- and meaningful for the reader. You’re absolutely right, when you say most readers skim and skip through a manual. But the central question is – what are they up to? They usually search for the answer of a certain question.

    “How do I get that damn VCR to record what I want?”
    “How do I change the ringtone of my phone?”
    or less specific
    “What is that shiny (and expensive) thing I bought (because everybody else has one already) all about?”

    This is my understanding of topics: A topic is an answer to a question of the user, which covers a mayor function of a product. It is for the most part self-sufficient, uses a narrative form as far as possible and is highly reusable with minor changes.
    Let me use one of the example questions above: How do I change the ringtone of my phone?
    There’s an exact answer for the phone you describe. And a general answer for every phone.
    The topic would then be the general answer.

    To change the ringtone of your phone:
    Call up the main menu (refer to topic “The main menu”).
    Select x, then y, then z (refer to topic “Using the phone controls”).
    Select the desired ringtone.
    The phone plays the ringtone.
    Select OK.

    As you can see, this is a really small chunk of instruction, but answers one of the most common questions on the user side, when buying a new phone. It also cross-references two other very common topics that usually appear in a manual for a phone (not counting the old analog ones).
    The reuse value is very high, as this generally can be used for each and every phone.
    There’s only a single part, which needs to be changed according to the menu structure used on that particular phone.
    You could add some more general information as an introducing text, savety instructions or any other helpful piece of information on this topic.

    So, when asking about the size of a topic, it may be this small, or for more complicated topics it can get quite large (to a point where you might want to break it down into smaller topics).

    To my understanding, a topic always should be the answer to a question the user definitely will ask, or might ask.

    1. Mark Baker Post author

      Alex, thanks for the comment. Answering a question the user will ask is definitely a good guideline. I would make this distinction, though. Sometimes the only thing the user need is a fact, a single data point. That isn’t a narrative, it is just a fact. The factual minim is much smaller than the narrative minim.

      Narratives are about taking the user from one point to another, from some point of confusion or uncertainty to a point of clarity. While there will always be cases in which readers will pluck facts out of narrative, I would submit that the serving up of facts is generally the role of the reference, not the topic. The role of the topic is to contain a narrative.

      When I talk about topics in this context, though, I do mean Every Page is Page One topics. You don’t structure a document out of Every Page is Page One topics — an Every Page is Page One topic is a document in its own right.

      1. Alex Knappe

        Looking at the other comments, it seems we all pretty much agree, we are trying to predict questions and give the answer within a structural context. But it seems there are some fundamentally different views on that structure. You’re supposing the narrative minim as content for a topic. Others go with DITA and produce Frankenbooks (I honestly love that expression).

        Personally, I think we should take a step back and look WHY we are even structuring our documentation. It is not primarily the possibility of reuse. We could do that already with unstructured documents (we live in the era of Copy&Paste anyways). In my opinion, we are structuring documents, because we want to make it easier for the reader to search and find information in an awful mess of information overload.

        While it is nearly impossible to find a piece of specific information within a novel in a few minutes, it should be quite easy to find a chunk of information in a technical documentation in this amount of time.

        So let’s take a look, if the proposed narrative minim serves that general requirement. To find specific information within a document you usually use titles, a table of content, an index, and some graphical elements. If you break down information below the title level, it becomes hard to find by the ‘traditional’ search elements. Only the index could help there. But what good is a title, if it hides on the 4th layer of titles and doesn’t show up in the table of contents for that reason.
        It may well be, that below that title you’ll find a narrative minim. But is it beneficial to create a topic out of it? I don’t think so. Taken out of the surrounding context it may also become an unreadable piece of information.

        I’ve been tempted to throw around the expression of ‘informative minim’, but that doesn’t fit the case too. After rethinking this, I would propose this rule of thumb:

        A topic should contain: At least a narrative minim, the full answer to at least one question, an informative minim and at least one or more references to it in the navigation part of the document.

        The narrative minim is key to the readability of the document.
        The answer to a question is the reason to read the topic.
        The informative minim is the part to put the topic into context.
        The references are the way to find this structural part.

        1. Mark Baker Post author

          Alex, I agree entirely on the reason for structuring data. Reuse is a good thing, but it should not trump usability as the focus of information design.

          When I talk about topics, though, I mean Every Page is Page One topics. Every Page is Page One topics are not intended to be the building blocks of larger narratives, so they should never end up under a forth level heading in some manual.

          Every Page is Page One topics could well be collected into a book, but if so, the structure of the book would be a collection of Every Page is Page One topics, like a collection of essays. The natural home of Every Page is Page One topics, however, is the Web. They are not designed to be found within something else, but to be found in their own right.

  2. Kai

    Interesting post, Mark.

    While the question for topic size did come up as our team of (then) 12 writers went to topic-based authoring, it was neither the first, nor the most important. Our answer was deliberately vague and indeterminate: Most topics are about one screen long, so users don’t have to scroll too much, but use your own judgement.

    I’m not sure I agree about the narrative minim for several reasons.

    First, many narratives DO include self-contained narratives which work perfectly well on their own. For example, the first long chapter of Don DeLillo’s novel Underworld stands alone as the story “Pafko at the Wall” as which it was published in Harper’s Magazine years before the novel came out. This is not an exception, as many novels have individual section published earlier as stories in magazines.

    It is not new either: Since the 16th century, two of the defining features of picaresque novels are that there is little if any character development in the main character and that there is no plot, but only episodes.

    Second, the narrative minim puts too much emphasis and trust on narrative as a crafted entity that affords meaning and contexts as constants.

    That is actually not how narratives work when they create meaning upon being read. Whatever meaning and context a text transports contributes only half of the understanding. The other half depends on the reader’s current context, their previous experiences and the meaning they create.

    To illustrate this, consider whether the following six words would still pass as a narrative minim: “For sale: Baby shoes, never worn.”

    You could pass this off as an irrelevant ad, because you’re currently not shopping for baby shoes.

    Or you could understand the incredibly tragic story that almost certainly lurks behind the sparse words. Someone posted the ad, someone who was preparing to have a baby in such concrete and specific terms that they already bought the shoes. And now they no longer need them – why? What happened to the baby?

    The reason behind this, I believe, is that humans are addicted to meaning in both aspects: Meaning as applicable understanding of text and meaning as a satisfying purpose in life. They will go to enormous lengths to create meaning, even from incomplete narratives. And from seemingly complete tech comm narratives, they will construe meanings which we as technical communicators would never have thought possible.

    1. Mark Baker Post author

      Hi Kai, thanks for commenting.

      You raise a good point about novels that are constructed out of stories that are capable of standing alone. Another example of the same thing would be episodic TV. Many shows have both the episodes story arc, and a season arc working together (Buffy the Vampire Slayer is the clearest example I can think of — it always has a yearly “big bad” as well as whatever the story was for the individual episode.)

      I actually think this is the kind of model that tech comm should be adopting — a documentation set as a collection of coordinated Every Page is Page One topics. But these things are not fractal. The mosaic and the tile are not self similar. The whole and the pieces are not alike. There is no repetition of the pattern at smaller or larger scales, just the container and the contained pieces, each distinct from the other, and each on its own single scale. So I think this actually reinforces the point that the narrative minim is a good model for a topic.

      I certainly agree with you that a narrative has to work in conjunction with the user’s context and experience. A narrative has to assume that the reader has reached the point of departure. A narrative is like a plane ticket from Ottawa to Washington. If your live in Arnprior, it is not the airline’s fault if you don’t have a ride to the airport.

      “For sale: Baby shoes, never worn,” clearly is not the narrative minim, as your discussion of it demonstrates. It states a fact and gives no context. Therefore it is not a narrative and does not qualify as the narrative minim.

      This is very much the point I am trying to get across. A narrative is more than a fact or a collection of facts. A narrative has a job to do, and the narrative minim is the smallest narrative that will do that job. Anything smaller than that may be a fact, but it is not a narrative, and as such it should not be a topic.

  3. Jonatan Lundin

    A narrative minim can be really small. On a big stone wall in Czechoslovakia, someone painted the numbers “4-3” around 1968. To me that does not mean anything as a think about it, but it meant a huge thing for the people of Czechoslovakia. During 1968 “Prague Spring”, the Russian invaded Czechoslovakia, but during the same year I think, there was also the ice hockey championship where Czechoslovakia beat Russia with 4 to 3. The numbers “4-3” was a signal to the Czechoslovakia people and the people interpreted it as “we can still beat them – do not give up”.

    So what perceives to be a meaningless string of words may have a huge meaning for people in a social context. We need both the social context in which and utterance is placed and our semantic knowledge (knowledge about the world, prior experiences, linguistic skills) to interpret something as meaningful, understandable and worth reading.

    Another point of departure to determine the size of a topic is to start from the information behavior of humans as users of technology. An army of researchers in the information science research field as studied this phenomena for decades know and we know a great deal of what is going on. In short, users perceive an information need due to a perceived uncertainty of not being able to make sense of how the process of using the product turns out. Users are active and goal oriented, trying to find an answer to the need to reduce uncertainty.

    So users ask (mental) questions, they are active “answer finders”, not passive readers whom we can fill with narratives. The task for technical communicators is to predict the probability of a question and then provide the answer (since we often work in a pre-release mode). The answer is then a single topic that can be seen as a narrative minim. But we must assume that the user has a certain knowledge level, which means that questions at a certain low level will not be asked. So the assumed knowledge level determines the “question and answer resolution” – thus the size of a topic.

    Then a question must be findable. A search user interface provides the mechanisms to allow the user find the answer. A search user interface can be dialoging, meaning that it asks questions and provides options to choose from. As the user makes selections, the user picks up the context which makes the final answer possible to interpret. So the search user interface provides meta textual information – contextualize it – to understand what a (topic) answer is all about which gives the user motivation to actually read it.

    1. Mark Baker Post author

      Thanks for the comment, Jonatan. Just as ““For sale: Baby shoes, never worn.” is not the narrative minim, neither is “4-3”. As you illustrate, “4-3” in that context is really just a symbol. The narrative minim would be the shortest narrative that explained the significance of the symbol in its context.

      I’m not sure what you mean when say “… they are active “answer finders”, not passive readers whom we can fill with narratives” Yes, people try to answer questions for themselves. When they fail, they turn to other for answers. Depending on the question, the answer they need may be a simple fact or it may be a narrative. We don’t fill passive readers with narratives. We respond with narratives when active readers ask us questions.

  4. Ruth

    Hi Mark,

    Very interesting post and a vital topic. I have been thinking about what you wrote for a couple of days.

    The question in this form is a bit strange for me as my mind goes to pragmatic solutions rather than academic ones – not that there’s anything wrong with the latter; it’s just that I’m more likely to think of things like, When should content NOT be split; What are ideal and non-ideal lengths of topics for particular readers and content; what should be included with a task; etc.

    You make an excellent point that topics are not fractal (and I really like the examples of narratives). I think you have exploded an assumption that a lot of people are making unconsciously. That idea should be widely disseminated. I imagine there’s a lot more that could be said about it as well.

    Re the name “narrative minim”, I have some concerns although I’m not sure they’re show stoppers.

    Is “narrative” too restrictive? Not all docs are narratives, arguably. For example, reference docs.

    Minim means a drop, and does that imply that a topic is a non-dividable part? That could be misleading. Sometimes a minim will be several drops; for example, if a minim in a developer doc included concept and code content, that wouldn’t seem to be one drop.

    (And one tiny quibble with minim. I just happen to be reading Harold Bloom’s The Book of J, which is literary criticsm of the Old Testament, and noticed that “minim” in Judaism means “heretic”. But that definition doesn’t even appear in the dictionary.)

    So to get back to my pragmatic bent. I’d ask, “What should be included in each type of topic?” with two answers that must be considered: ideal/non-ideal length; and breadth of content. The answers would depend on the type of reader, type of content, and particular user set (and possibly other things), so instead of a single answer there would have to be a set of criteria or something like that. I’ll go away and think more on that and try to write a post.

    1. Mark Baker Post author

      Thanks for the comment, Ruth.

      Agreed, not all docs are narratives. Some (references) are collections of facts, not narratives. But I have argued elsewhere that references are not topics ( So, in my world view, a topic is a container for narratives and a reference is a container for facts.

      By minim, I certainly mean non-dividable, but I mean non-dividable as a narrative. A narrative may well be made up of a series of connected facts, which could be divided from one another. The point of defining a narrative minim is not that the text cannot be divided, but that if it is divided, the pieces cease to be narrative. You can divide a tea set into individual cups and plates, but then it ceases to be a tea set, though the cups and plates continue to be cups and plates.

      Division of content below the narrative minim is exactly what happens in many DITA systems: you end up with many disconnected pieces (which DITA calls topics) which don’t tell a whole story and thus frustrate the reader.

      But I definitely agree that the answer to the question of how to define the narrative minim in practical cases will involve multiple criteria. This is precisely why I believe that we have to focus on creating specific topic-based information designs. Those designs, essentially, define what is required to achieve the narrative minim for a particular audience and a particular set of information.


Leave a Reply