In any system that attempts to classify the whole of something, there is usually a category that essentially constitutes “everything else”. In the terrible troika of task, concept, and reference, that role belongs to “concept”. In Tom Johnson’s shapes of help graphic, which have quoted before, and repeat here, task has the shape of a procedure, reference the shape of a table, and concept the shape of plain text.
Concept, then, stands for the plain, the generic, the featureless and structure-less.
But is that all there is to structured writing: tasks, references, and everything else? To be sure, every structured writing system needs some kind of generic topic structure, for a few reasons:
- There will genuinely be some topics that are merely discursive narratives and have no particular internal structure at all.
- You will sometimes have topics that could certainly have a structure applied to them, but you don’t have enough of them to justify creating a separate type for them.
- You will sometimes have topics for which you know you will want to develop and enforce a structure, but for which you don’t yet have enough information to develop that structure, and you need a place to capture them in the meanwhile.
Okay, but what does it matter what you call that class of topics? What difference does it make if you call such topics “generic” or “concept”?
It makes a difference in a number of ways.
First, saying “generic” reminds you that you are not giving a topic a real type at all, but recognizing that it has no type. Calling it a “concept” makes it sound like you are actually giving it a type (one of the three canonical types: task, concept, and reference), and that can lead you to think your information typing job is done. Generic makes you ask if the topic is really generic, or if you should be doing more to define its type; concept raises no such questions.
Second, “concept” is one of the slipperiest words in the English language. In some general sense, it means a thought or an idea, but, as the Wikipedia article on Concept succinctly begins: “The word concept is defined variously by different sources.” Its full meaning has vexed philosophers for centuries. Its multiplicity of meanings is perhaps what made it a candidate for the third member of the troika, since there is probably some meaning of the word “concept” that can be applied to any text. But you do not want a category name to work because it is ambiguous. You do not one some members of the category qualifying under one meaning of the term and some under another. Categorization only tells you something useful about the things it categorizes if the categories are clear and unambiguous.
Third, one of the many meanings of “concept” is actually relevant to a great many technology products. Many products are designed around certain fundamental ideas, which the user needs to understand in order to get full use of the product. If the user is switching from one technology to another (such as switching from an unstructured desktop publishing process to a structured writing process), it will be particularly important for them to grasp the fundamental concepts of the new technology, and how they differ from those of the old. In this sense, a concept is not “everything else” but something quite specific. But if the user is presented with hundreds of hundreds of topics labeled “Concept”, these essential foundational concepts can be lost in the noise.
Fourth, there are plenty of topic types that are not, by any reasonable definition of the words, either tasks or references, and which are not concepts in the sense described above. Nor are they generic. An example from my own background writing about programming languages and operating systems, is the annotated code sample topic.
Programmers basically want two things in a documentation set: an API reference and code samples. Programming task topics may be useful, and in some cases programmers would really benefit from paying some attention to the fundamental concepts of the language or OS, which may be quite different from those they are used to (markup processing languages like XSLT can be very confusing to regularly trained programmers, who often use them wrong because they don’t understand them) — but what programmers want, universally, is an API reference and code samples.
The documentation’s best chance of educating a programmer of the fundamentals of how a language or and OS works is through well-documented code samples. That merits a topic type in its own right. And code sample topics do have a definite structure to them. There are a number of things that every code sample topic should include, starting, of course, with the sample code itself and its annotations, and including such information as the versions of the API supported, the language of the sample, the resources it requires, and, in the case of specialty applications, such as embedded or real-time systems, its security and performance characteristics, and other product or craft-specific information. I’m sure similar examples will spring easily to mind for those in other fields.
Another example is something I regard as particularly important in any topic-based information set: pathfinder topics. Pathfinder topics are not task topics (in particular, they are not the same thing as workflow topics, which are a kind of task topic). Nor are they big-C concept topics. Rather, they are topics that help the user find their way around the technology, giving them a sense of where everything is and how it works together to achieve the user’s ends. If big-C concept topics are aimed at understanding, pathfinder topics are aimed at orientation and planning. Pathfinder topics are a topic type in their own right.
There are, then, besides the truly generic, many kinds of specific topic types, one of which, in a very specific sense, is concept. Concept is not the right word to describe “everything else”, nor is it useful to single out tasks and references as particular types and then assign everything else to a single category, however named. To do so is akin to dividing the animal kingdom into cats, dogs, and everything else.
We need to free ourselves from the tyranny of the terrible troika and develop an appreciation for the many different types of topics that are needed in a structured writing environment. It we want to apply real and useful structure to the topics we create, we need something more than the simplistic trio of concept, task, and reference.