One of the principles of Every Page is Page One information design is that an EPPO topic conforms to a type. But I have come to think that that formulation is not quite right. It should really be, an Every Page is Page One topic conforms to a topic pattern.
The difference between type and pattern
What is the difference between a topic type and a topic pattern? In structured writing terms, a topic type, or, more generally, a document type, is a formal set of rules about the structure of a topic which is capable of being expressed by a schema. In most cases, that means an XML schema or something similar. This usage is consistent with the use of the word “type” in other computing applications. A type is a data definition.
Of course, a topic can conform to a type without actually conforming to a schema, or being written in any form that support schema validation. You can write a topic in plain text that follows the prescriptions of an XML schema definition exactly, though you won’t be able to validate it, or use automated publishing tools to format and present it.
To say that such a topic conforms to a type, therefore, is a little confusing. It may conform to the rules of the type, but it is not an instance of the type because it does not have the markup that can be used to identify it and process it as that type.
What it does do, though, is conform to a pattern. Thus we can say that the topic conforms to the pattern, even though it does not conform to the formal type definition.
How types relate to patterns
If that was all there was to the distinction, it would just be a bit of semantic quibbling. But I think there is more, and that it is important.
In the Every Page is Page One book, I use a recipe as an example of a topic type. But in fact a recipe is a more general pattern that different publications may interpret in different ways. The fundamental parts of the recipe topic pattern are universal, but there are variations in how the are arranged and all sorts of optional extra elements, like nutrition information, preparation and cooking time, and wine pairing.
Of course, you can have optional elements in a topic type as well, but formal types are generally more useful — provide more guidance, more error detection capability, and more reliability in different applications — if they have as few variation and optional elements as possible.
Types support business requirements
Any one recipe publisher, for instance, may want to mandate that wine parings be stated for all recipes. That requirement may be an essential part of their identity, their marketing strategy, their revenue stream (through affiliate agreements with wine producers), and their navigation schema.
For such a publisher, the wine pairing information is an essential part of their recipe topic type. Given how important it is to their business, it is probably a complex structure containing several fields whose values are validated against a formal taxonomy of wine terms.
The requirement for that extremely detailed wine pairing section does not hide the fact that the recipes follow the recipe topic pattern. And following that pattern is an important part of the usability and findability of the recipes, since readers who are looking for a recipe, and deciding which dishes to cook, look for content that follows the recipe topic pattern that they know.
It is important, therefore, that this publication’s recipe topic type conform to the general recipe topic pattern, and also that it be an extremely specific type definition that captures the information that is essential to running this publisher’s business.
Elements of a pattern not expressed in the type
But a topic pattern may also be specific in ways in which a particular type that follows that pattern is not. For example, the procedural part of a recipe may look like any other numbered list of steps, and may be modeled that way in most recipe topic types, but there is actually an interesting and important pattern to recipe procedures that is not found in all procedures. We could call it the “meanwhile and let” pattern, as exemplified in a this recipe for Curried Pumpkin and Wild Rice Soup.
Bring a small saucepan of water to a boil. Add the rice, and simmer until tender, 30 to 40 minutes. Strain and let cool.
Meanwhile, combine 2 tablespoons of the raisins and 1 tablespoon of the vinegar in a small bowl. Let sit at room temperature until ready to serve.
“Meanwhile” and “let” introduce an interesting pattern into a recipe procedure. The standard form of a procedure is that each step is completed in turn. The first step is performed to completion, then the next, then the next, like this:
But in cooking, part of the art of a meal it to make sure that each dish, and each of the parts of a dish, are ready at the same time. Rather than each step ending before the next begins, in many cases the whole point is to make sure that all the steps end at the same time.
This actually creates a complex pattern in which some steps are sequential and some run in parallel. In some cases the parallel steps run all the way to the end of the recipe. In other cases, the thing they produce is used as an ingredient for some later step. Thus the model of a recipe procedure looks something like this:
Creating a formal content model to represent these relationships could be quite complex, and it is not clear it it would make recipes any easier to write or to follow.
Rather than try to express this elaborate pattern, what recipes actually do is quite simple. When a step is supposed to run in parallel — which almost always means that some part of the dish is cooking while the cook does something else — the following step begins with the word “Meanwhile”, indicating that this step is to be performed while the ingredients of the previous step are cooking.
In the case where the output of one step is going to be required as the input of a later step (not necessarily the next one) this is indicated with words like “let stand,” “let cool,” or “set aside.”
The elements of a finished dish come together like the converging branches of a tree, and getting that convergence pattern, and its timing, right is vital to the success of a recipe. That tree could be modeled as a formal data structure. In future posts, we will look at examples where it makes very good sense to model a set of inputs as a formal data structure and derive a procedure from them automatically. But that is seldom going to be applicable to the writing of recipes.
Though the “meanwhile” and “let” pattern is part of the rhetorical structure of the recipe topic pattern, and important to how you teach people to write recipes, it is unlikely to be part of any recipe data type.
Data structure vs. rhetorical structure
A topic pattern, then, is a rhetorical structure. A topic type is a data structure. The data structure and the rhetorical structure intersect but the data structure does not usually encompass everything that is in the rhetorical structure, while the data structure may make data requirements that are far more explicit and formal than the rhetorical structure demands.
As we shall see later, the data structure may also depart substantially from the order and form of the rhetorical structure, and abstract out many of the rhetorical elements, so as to automatically construct the desired rhetorical structure from the data in a more efficient and reliable manner than can be done by hand.
This is why I think that the distinction between a topic pattern and a topic type is worth making, and why I should have said not that an EPPO topic conforms to a well defined topic type, but that it conforms to a well defined topic pattern.
Of course, if you are using structured writing techniques to create EPPO topics, you will probably want to create topic types that help ensure that your topics consistently conform to the appropriate topic pattern. But these two ideas are separate, and it is important to keep them separate.
In following posts, I will be looking at a number of different topic patterns, and why they matter for effective communication.