If a topic in your documentation gives you trouble, seems homeless or doesn’t quite “work”, it’s probably because it is mixing topic types.
The company I work for has started to roll out topic-based authoring over a year ago. We’ve seen several benefits already: Topics are easier to find and follow for users and more efficient to maintain for writers. But the transition has not been without problems…
The curse of the ornery topic
One of the biggest headaches for us is the “ornery topic”. Here’s how you can tell an ornery topic:
- It seems homeless. Regardless where you put it, it seems out of place somehow.
- It doesn’t quite work. It doesn’t really do what the heading says, but somehow does more or less or differently.
- It seems essential. You really need the information. You can’t just cut it out.
The #1 cause for ornery topics is mixing topic types. What often happens is this:
- We need to explain how to do something, so we write a procedure.
- Then we need to provide some context about the task, so we include some concept information.
- Then we need to tell the customer about all the available settings and options, so we include some reference information.
Voilà, our topic’s become ornery! – If you’re into project management, think of this as the molecular tech comm version of scope creep.
The cure for the ornery topic
We’ve by now found several ways you can bring an ornery topic back in line:
- Extract concept information, put it into a concept topic and link to it.
- Omit reference information in the topic, if it is sufficiently explained elsewhere, for example in online help entries.
- Make the procedure rule the topic structure, so you have intro/context, prerequisites, procedural steps, result.
- Limit context information to what fits into an introductory paragraph (and link to other concept topics)
- Limit reference information to what fits into individual steps (and link to other related reference topics)
Your turn
Have you met any ornery topics in your documentation? How have you addressed them? Feel free to leave a comment…
Filed under: structured writing, technical writing, topic-based authoring, writing |
Well put. This is a major problem when converting legacy content to DITA. Unstructured content like this requires considerable upfront work to rearchitect as it goes into DITA.
Thank you, Sandra! So moving to unenforced DITA-like structured authoring as we are (see https://kaiweber.wordpress.com/2011/06/09/all-aboard-onwards-to-semi-structured-authoring/ ) will be risk and opportunity, both at once: Risk because we’ll find several topics that won’t comply with our information model. And opportunity because we can clean them up as long as we don’t strictly enforce our content structure.
[…] go a long way, but they shouldn’t replace entire concept topics. Also see my previous post When topics don’t quite work from two years […]