The Tyranny of the Terrible Troika: Rethinking Concept, Task, and Reference

Tom Johnson’s blog post Unconscious Meaning Suggested from the Structure and Shape of Help, includes a graphic showing three shapes of content:

Tom Johnson's "Shapes of Help" graphic.
Tom Johnson’s “Shapes of Help” graphic.

These three shapes are meant to represent the DITA topic triad of concept, task, and reference. I didn’t get it. As I said in a comment on Tom’s blog, I was trying to match the shapes to something more specific. It was odd that I didn’t recognize them as concept, task, and reference, I said, because I have be “battling the tyranny of the terrible troika” for the last few years. Tom asked what I meant by “the tyranny of the terrible troika”; this is my answer.

It has become almost an axiom of technical communications in the last few year that all content — ALL content — is of one of three types: concept, task, or reference. This idea is a reductio, if not quite ad absurdum, of Information Mapping’s six information block types:

  • Principle
  • Process
  • Procedure
  • Concept
  • Fact
  • Structure

Others have, over the years, proposed other lists of information types, but, except within Information Mapping’s walled garden, these have all faded away in favor of the troika of concept, task, and reference.

The reason, I am inclined to believe, is that concept, task, and reference have the virtue of being unambiguous. In all other schemes, one could start an argument about the categories. One could ask, for instance, what the difference is between a principle and a concept, or between a process and a procedure. One could ask if facts should be broken up into three types: facts, lies, and assumptions.

It is much harder to make such arguments about concept, task, and reference, in part, at least, because they actually represent three kinds of information seeking behavior: learning, doing, and fact checking.

As such, I think that the troika of concept, task, and reference do have analytical usefulness. Understanding what kind of user information seeking behavior you are currently supporting is useful and can serve to stop you from prattling on about side issues when you should be getting to the point. They are, in this sense, not so much types of information as types of information seeking behavior. As such, I think they are very useful.

The problem is that, in the popular conception influenced by DITA, the words concept, task, and reference do not refer to types of information seeking behavior, or even to types of information, but, as Tom’s diagram shows, to shapes of information: a reference is a table, a task is a procedure, a concept is ordinary text (in other words, everything else).

In Information Mapping, the types are the types of information blocks. Information blocks are not an end in themselves. They are supposed to be combined into maps. The reader of an information-mapped document is not supposed to be presented with individual information blocks, but with complete maps, which, to the reader, simply appear as a well structured document. A map, in information mapping, is an organization of information blocks into an effective whole. Information mappings is as much about how to assemble maps as it is about how to type information blocks.

In DITA, on the other hand, a map is merely a technical device for bundling topics. Beyond the idea that it is useful to put your tables and procedures in separate files, DITA has no information design theory. As the Information Mapping white paper on DITA points out:

No [writing] principles [are] defined except for the concept of a Topic standing on its own.


Information Mapping®’s principles provide guidelines to writers to ensure that their content is organized and presented in a useful and effective way for the reader. There is no equivalent in DITA.

Now, I hold no brief for Information Mapping — as a commercial product it strikes me as the equivalent of bottled water — not bad for you, but not the only beverage, and nothing you could not get out of the tap for free. But on this subject, they have a point. DITA does not have a theory of information design.

This is not, in itself, a bad thing. It is not a bad thing for a technology to be separated from a design philosophy, even if one is intended to support the other. I myself am careful to separate the information design philosophy of Every Page is Page One from the technology of SPFE.

If there is a problem with DITA, then, it is not that it lacks a theory of information design. The problem is that many people actually believe that it does have a theory of information design, and that that theory can be summed up in three words: concept, task, and reference. But a theory for breaking content up into pieces is not a theory of information design unless it also includes a theory of how the pieces should go back together.

There is, of course, nothing preventing DITA users from having or developing a sound theory about how the pieces should go back together. The problem is not that DITA does not provide one. The problem is that writers often do not see that they need one. They believe, or act as if they believed, that the devolution into concept, task, and reference is a complete information design. The result, generally, is Frankenbooks.

The result is that when you talk about information types today, people’s minds go at once to the terrible troika — thus the tyranny. But, I would submit, the troika are not information types at all, (nor topic types). They are the types of information shapes, of information blocks. Information typing (and topic typing) is about something more than this. To be specific:

Each of these deserves a post in its own right.

[Amended slightly based on Larry Kunz’s comment.]


Author: Mark Baker

Mark Baker is a content strategist and content engineer who helps organizations produce content that matches the way people seek and consume information on the Web today. He is the author of Every Page is Page One: Topic-based Writing for Technical Communication and the Web. He blogs at His website is

28 thoughts on “The Tyranny of the Terrible Troika: Rethinking Concept, Task, and Reference”

  1. Thanks for the article (and love the alliteration). Though we don’t use it currently, I was just introducing the concept of DITA to a colleague this morning. I think it is attractive as a way to “chunk” content — especially where there was little structure before. Also, it is relatively simple to conceptualize (three types are easier than six). However, I agree that it requires a writer or editor to think carefully about what content is important and how to map it. I look forward following this exchange between you and Tom in the future 🙂

    1. Hi Michael,

      Yes, the fewer the types of chunks, the easier is it to conceptualize and make chunks. The problem is, the design does not lie in the bricks, but in the building. If forced to build with only three types of brick, the architect is limited in what they can design.

      To Tom’s point, it is hard to make something with elegance and flow out of a limited selection of small pieces.

  2. Mark, you totally highlighted a problem I experienced last week. In fact, I have a draft in process about it. I was reading, cover-to-cover, a PDF how-to guide that I singled sourced from the online help. It’s a small help file — about 75 pages. But it read poorly as linear content. Information was redundant in places, didn’t flow well from one topic to the next, seemed choppy and unhelpful, etc. In short, the book version sucked.

    My approach was to write content in topics, and then assemble those topics in what seemed like a logical order. But that approach just doesn’t work. No one I know has ever written a book or lengthy article using that approach. Almost no one starts writing in little chunks, discrete paragraphs, and then tries to mix them all around on a large board and then simply click print.

    One has to read and re-read the content as a whole unit, identifying gaps, smoothing out information here and there. I’m sure that you read your blog posts numerous times from top to bottom to make sure the content flows well as a whole essay rather than simply reading paragraphs in random orders.

    I definitely have the frankenbook syndrome with my help authoring, and I agree that information design differs from topic-based authoring, that topic-based authoring doesn’t lead to a well-organized body of information.

    What I didn’t get from your post was more clear strategies and answers for avoiding the frankenbook syndrome. If every page is page one, what does that really mean? Do you include a ton of cross references to other topics readers need to understand? Do you read your print manuals cover to cover and adjust them continually until they flow as a whole? Do you make sure that topics aren’t separated from their related tasks?

    Great post.

    1. Hi Tom,

      I think that in renaming IM’s information blocks to “topics”, DITA fundamentally distorted what topic-based authoring is about. It’s something I wrote about a while back in

      No one would expect information blocks would flow together if written independently and then assembled afterwards. Everyone would expect a topic to flow. There is thus a kind of slight of hand involved in renaming blocks “topics” and calling the result “topic-based authoring”.

      To me, a topic is what IM would call a map, rather than a block. It is a complete piece of information that fulfills some definable purpose for a reader. This is also what tech comm has traditionally meant by topic — as in help topic.

      As a design philosophy, Every Page is Page One is focused on the web (on hypertext, specifically) as the primary media. If you were to produce a book from Every Page is Page One topics, it would read more like a collection of articles than a single narrative (which is actually quite a common thing for books). The topics would flow; the book would not flow as a single narrative. But that, I think, is quite appropriate for most technical manuals.

  3. Hi Mark,

    Thanks for this post. I think that you eloquently state one of the biggest issues with DITA implementation. That is that people adopt DITA expecting it to be a one-stop shopping experience. Adopting DITA is far more akin to buying a pound of ground beef than it is to buying a meatloaf. The expectation should be, with a DITA adoption, that you are simply getting a framework for creating content; you are not getting a finished product. DITA self-advertises as a *standard*. It’s up to others to develop specific implementations for that standard. A group who is unprepared to develop its own full implementation–specializations, information architecture, publishing methodology, etc.–is not ready for DITA adoption. I really don’t see DITA’s failure to inherently include these aspects as a failure at all. DITA does exactly what it set out to do.

    The real problem is that far too many groups are not able to shift away from a tool-based way of thinking to understand that DITA is not a tool. You can’t just install it and get going, like you can with FrameMaker or InDesign or even Word. Anyone who implements DITA thinking it is a tool in the sense of those applications will be disappointed and frustrated. All of the hype about DITA as the salvation of tech writing is somewhat to blame. It’s up to individual groups and those of us who evangelize DITA to make sure the parameters are clear. When groups come to me interested in implementing DITA, I absolutely play Devil’s Advocate. I make sure they understand how much work it will be, how long it will take, and what a paradigm shift it will be for the writers. I discourage some groups. Good!

    As for the tyranny of topic types, again–that’s conventional wisdom (which is usually neither) masquerading as gospel. Though the topic types are defined in the standard and have a structure that somewhat determines what content they include, DITA comes with built-in mechanisms for breaking free of that “tyranny” and creating content types that reflect a group’s actual usage? Need a “principle” information type? Define it on paper and then specialize it. Need a task that’s not a procedure? Define it on paper and then specialize it. Don’t want to specialize? Decide on a “principle template” for a generic concept that simply uses certain elements in a certain order. Make that template available to all the writers and have sufficient oversight to ensure everyone follows that pattern. DITA content doesn’t write itself; it doesn’t architect itself; it’s not a substitute for writer judgement, discretion, or use of internally-developed best practices.

    DITA is simply not for everyone. Don’t buy the pound of ground beef if you don’t know how to make a meatloaf, aren’t willing to get a recipe and learn, or don’t have a cook in the house 🙂

    Thanks again, Mark, for opening this discussion.

    1. Leigh, thanks for the comment. You are right, of course, that DITA is a framework, not a finished product, and that it does not, itself, claim to be anything else. The irony, of course, is that if people realized that, far fewer would adopt DITA.

  4. Hi, Mark. You got one out of three right.

    In DITA, a task is a procedure. But a reference isn’t necessarily a table, and a concept isn’t a bunch of plain text. While writers often choose to compose reference topics and concept topics that way, they’re not required to do so. I think that fact weakens your argument that DITA is tyrannical (although I, too, loved the alliteration).

    You make a good point about the fact that while DITA doesn’t have a theory of information design. DITA gives writers the freedom, and also the obligation, to develop their own designs. If writers are trained to believe otherwise, then a disservice is being done.

    1. Hi Larry,

      I didn’t accuse DITA of being tyrannical. I accused the idea that information typing amounts to concept, task, and reference of being tyrannical. And while DITA certainly bears some of the blame for promoting this idea, that does not make DITA the tyrant itself. In the vocabulary of tyrants, it plays more the role of the useful idiot. 🙂

      You are correct the actual DITA reference type definition does not require a literal table in the page layout sense of the word — it is much looser than that, and allows some other common reference shapes, or even no shape at all. Actually, it doesn’t even make a distinction between being a entire reference and being just one entry in a reference — a table and one entry in a table.

      But in the popular image of the concept, task, and reference types, as Tom’s picture illustrates, that is the image that “reference” invokes.

      I can’t for the life of me, though, find anything in the DITA concept type that is any more specific than a bunch of text. Perhaps I misspoke slightly with the use of “plain”, which could be construed to exclude lists, etc. That was not my intent.

      But again, my complaint here is against the popular model of information typing as concept, type, and reference, not against DITA itself. One could hardly discuss the rise of concept, type, and reference, though, without discussing the role the DITA has played in their ascendancy.

  5. Tom (and Mark), when I have a topic-based deliverable that has problems with flow or general helpfulness, I ask myself, what is it about these topics that prevents them from working well in the structure and order that I want? Why did this topic work in some other context but not here? Or is there something wrong with the structure or order I’m imposing?
    Very often a topic doesn’t become genuinely reusable-at-will until you’ve tried to use it in several different outputs and found that you needed to tweak its scope, or its voice, or its title, or something. Looking at whole deliverables is a great way to expose these things. (Although with experience you can often guess what’s going to fly and what’s not before you even put it all together.) The top-down perspective is as much a part of topic-based authoring as the bottom-up view.

    1. Thanks for the comment, Ted. I’m sure what you describe is true, but I think it points to a significant problem with the way “topic” types are being defined and written. If the only way to tell if a “topic” is going to actually be reusable is to try it in a bunch of different places, adjusting it time and again until it finally works, then I wonder how much of the supposed efficiency of reuse remains after you have done that much fitting and a shaping. And how does that work when the potential reusers are on different teams or working on different schedules?

      It seems to me that one of the basic things you should expect of anything called an “information type” is that you should be able to create instances of it based on the type definition alone, and not have to hand fit every instance into multiple contexts to ensure that it really worked.

      An information type, in other words, should be sufficiently well defined as to produce reliable instances. That, generally, is what it means to define a “type” of something. That, however, is difficult to do when you are dealing with very small units, something Tom and I talked about a while ago:

  6. Great article as usual, Mark. And, of course, I love reading Tom Johnson’s comments, too.

    My two cents…I seldom want to read a book to find the answer to my problem (cook dinner, update the firmware on my laptop, discover new ways of searching Google). As such, I love topic-based writing as it isolates the core components into chunks that can be (when done correctly) served up to me as if I ordered them (and chances are, on the web, I did just that). I wonder how much of the resistance to topic-based authoring is legacy memories of what it was like in the good old days when we wrote books nobody read? As someone who spends a fair amount of time with folks much younger than I in our field, I can tell you that the young writers I am around don’t care about flowing content, smooth segues, and such. They care about efficiently finding the answers to their problems so they can move on to more important things (like drinking beer).

    I realize there are different approaches to creating content (and respect that there are good reasons — sometimes — for doing so). But, far too often, the “reasons” people give (in my opinion, at least) aren’t “reasons” just “excuses”.

    Thanks for always making me think about what we do and why we do it. Your wisdom is something I am glad you choose to share as often as you do.


  7. Hi Scott.

    Thanks for the comment. I agree that most people don’t want to read the whole manual, and so don’t care much that it doesn’t flow, though Tom’s speculation that this may in part be learned behavior because of how badly many manuals flow is certainly an interesting one.

    I do think, though, that whatever unit of content you do end up reading, you want that unit to flow well. That, to me, is what topic based writing should be about, and what Every Page is Page One is certainly about.

    But the kind of fragmentation many are now practicing in creating task, concept, and reference topics/blocks is clearly far below the level of what a reader will usually need to complete their task. (It it was not so, you would not need to go to such elaborate lengths to stitch the blocks back together into maps, after all.)

    Certainly, making one block be the unit that meets the readers every need is not what IM had in mind. It is the map, not the block, that creates the unit the meets the reader’s need in IM (which is why it is called Information Mapping, not Information Blocking).

    This is where I think the concept of topic-based authoring has been distorted. An Every Page is Page One topic is the unit that meets the reader’s need in the present moment. This is something much more sophisticated than a simple task/concept/reference division would produce.

    I’ll have more to say about that in my follow-up posts.

      1. Hi Scott

        I haven’t studied OManual in depth, but a quick look shows that it is not what we would consider a structured format. Much of the actual content is not marked up in OManual at all, but in encapsulated HTML. The OManual markup itself seems to be more about publishing and connecting the parts and tools mentioned in the text to the place you can buy them in the iFixit store. This is done, according to the samples, using hard coded URLs, so there is no kind of abstraction going on here.

        I would regard it, therefore, as the input format to a particular publishing engine, rather than as a structured content format. In a SPFE implementation, if a client wanted to have oManual output, I would generate oManual as an output of the Format stage of the SPFE process.

        This is not a criticism at all. We need domain specific publishing engines, and they need to have input formats. But the usefulness of the input format is incidental to the usefulness of the publishing engine. If you want to do things by hand (and sometimes that is the right choice) you could write directly in oManual (using an oManual editor, if such a thing exists). But again, you would do so for the sake of the publishing engine, not for the sake of the format (just as one might write HTML directly for the sake of the browser, not because of its usefulness as a data format in itself.)

  8. As usual, a provoking post, Mark. Scott’s point about unwillingness to read a long, linear exposition being more pervasive among young and web-centric readers and writers is true *generally* but not universally. Lesson one in writing is to understand your audience, and lesson two is understand your own content… sometimes that combination requires more depth than a cookbook or a new Google trick. When documenting for developers, the ability to break down everything to a task-based topic that lets users “solve a problem and return to their work” is not always possible. Mark, your “every page” approach is good for considering big concepts exhaustively, but does not enable reuse of content, which is more imperative when you are documenting multiple products that reuse modules of code in different contexts. I agree that the Troika is limiting, but it is a model that enables reuse at a modular level. Executing an effective reuse strategy, using the Troika or any other information model, is a huge challenge.

    1. Hi Frank,

      Thanks for the comment. I agree that there are still, and always will be, times when the reader just needs a book. Movies did not kill the theater, nor did TV kill the movies, and the Web won’t kill books. But the movies did reduce the sphere of the theater, TV did reduce the sphere of the movies, and, in tech comm, the Web has reduced, and will continue to reduce, the sphere of books. So, for most tech comm projects today, the Web should be the principal sphere of concern, but there will still be times what the user wants and needs a book.

      As Tom points out (and experience confirms) books cobbled together out of reused concept/task/reference fragments don’t tend to work very well as books. Books formed by collecting Every Page is Page One topics will generally work better. But neither will work as well as writing the book as a book.

      The choice between these approaches will, in part, be dictated by the time and resources available, but if the book you build out of fragments is a Frankenbook that would, in Tom’s words, test the patience of a dead owl, it probably won’t get read, in which case the most economical course would have been not to bother creating it at all.

      EPPO, by itself, it an information design philosophy, so it is neutral on the issue of reuse, which is an authoring side issue. SPFE ( is an content processing architecture that supports reuse in a number of different ways, both structured and unstructured. I think that DITA’s conflation of information design with reuse techniques actually limits the reuse methods available in DITA and make reuse much more expensive and troublesome than it should be.

  9. Great discussion. Of course, we may be assuming the best way to communicate some things is in a book, in more of a narrative manner. That said, I just left a client gig. During the meeting I told them the answers to almost all of their questions are documented in the book (manual) they display proudly on their bookshelve.

    “Oh, we don’t have time to read that. Can’t
    you just tell us the answers?”

    Yes. Yes, I can. Invoice to follow.

    1. Tech comm as performance art?

      Seriously, though, while not every customer will have the money to hire people to read the book for them, this does illustrate once again that asking the expert, not reading the manual, is the natural way people seek technical help, and thus why we have to start thinking more colloquium and less publishing house.

      The written word still plays a part in a colloquium, but its role is more correspondence and anthology and less magnum opus.

  10. A fascinating article and responses and responses to responses. That’s a colloquium!

    The last letter in DITA stands for “Architecture” and that suggests that the DITA designers did have the attention of providing more than a useful chunking mechanism. That was the intention but I find that information architects prodded about this take recourse in minimalism.

    1. Hi Patrick. Thanks for the comment.

      It does seem that few people actually use DITA for information typing, preferring to stick with the information types defined by others. I don’t think DITA’s appeal has ever actually been based on its capacity for information typing. Information chunking, and the resulting capacity for the reuse of chunks, seems to be its main attraction.

      One of my chief complaints about DITA is that the chunks that people frequently produce with it are not strongly typed, and therefore can only be reused by inspection. You can’t attach reliable enough metadata to them to reuse them automatically. (See:

      The thing that gets me about DITA as an information typing architecture — that is, as an architecture for defining information types — is that we already have a more sophisticated and versatile architecture for defining information types: it’s called XML. More specifically, we have a family of XML-based standards for defining information types: DTDs, XML Schema, RelaxNG, and Schematron.

      DITA, of course, adds a new trick to information typing that none of those other standards support: defining types by specialization. But the problem is that the actual specialization mechanism in DITA is so limited — as it has to be to make the fallback publishing mechanism work — that it actually amounts to little more than an element renaming scheme. It really only creates more specialized names, not more specialized structures.

      Recently, DITA has added a little more sophistication to it information typing with the addition of constraints, adding back, in a much more convoluted fashion, a capability — constraining an information model — that was already present in DTDs, XML Schema, RelaxNG, and Schematron — all of which are essentially mechanisms for expressing constraints. In short, we are already well supplied with powerful standards for information typing.

      Really, then, it is not particularly surprising that DITA seems chiefly valued not as a information typing architecture, but as an information chunking and assembly mechanism.

  11. Mark, although you hold no brief for Information Mapping, I and others within our “walled garden” were impressed by your insights re the widespread misconception that DITA has a theory of information design.

    We’ve long seen our methodology as synergistic with DITA rather than in competition with it, and urged users of DITA to look beyond Concept, Task and Reference for purposes of information design.

    I disagree with your perception of the ambiguity of information type schemes beyond Concept, Task and Reference. For example, the difference between our Principle and Concept information types seems quite clear and unambiguous to me. But that’s a topic for another post.

    Thank you for an insightful and interesting article.

    1. Hi David,

      Thanks for the comment. I wasn’t meaning to imply that the distinction between Principle and Concept was inherently ambiguous, only that there would always be people who could argue that it was not necessary, on the one hand, or not sufficient, on the other. All classifications schemes, not matter how clearly defined, are susceptible to such debates. Concept, task, and reference, on the other hand, seem to have a achieved an kind of irreducibility which was able to win broad-based (if possibly misguided) consent.

Leave a Reply

Your email address will not be published. Required fields are marked *