What is a topic?
A “topic” can be defined in several different ways— a fact which often leads to inefficiencies in content management. Even if we can agree on the general function of a “topic,” the concept often remains confusing for many technical communicators. This is especially true in the context of a global content management team, with each individual technical communicator holding their own definition.
As technical communicators, our definition of a topic really depends on the form in which we make content available to our users. What follows is a presentation of what a topic means within the context of three different content delivery scenarios.
The purpose of this guide is to help you find clarity the next time you are discussing or communicating about topics. Hopefully this will help solve the problem that comes from having an unclear definition, and ultimately lead to greater team effectiveness.
First a Little Background
Rather than managing each user manual as one file, many technical communicator teams chunk existing content into many hundreds, or even thousands, of smaller files— also known as topics. User manuals are thus built by referencing many topics in a given order—similar to building a Lego car with many different bricks. This is done for many purposes, like enabling the reuse of content when designing user manuals. DITA (Darwin Information Typing Architecture) is often used as an underlying architecture for managing topics and topic authoring.
Scenario 1: A Topic as an Answer to a User Question
In this scenario, your focus is topic-based delivery. You acknowledge that the users are asking the questions and you are providing the answers. Thus, a topic is an answer to a user question.
This means that your users do not want books to flip through, but rather the answer to a question and nothing else. In this case, topics are made available as a search result list much like the ones generated on Google. Reuse is not a big issue here in the sense that the same content is included in many user manuals (obviously, since there are no books). Instead, the user finds a topic (an answer) within a knowledge base by searching or filtering (For more information, see ISTC Communicator article,How do you Design for Findability?).
Scenario 2: A Topic as a Knowledge Article
In this scenario you deliver individual standalone topics to the user, not books. Each topic is not an answer to an individual question, but instead contributes to larger knowledge articles that answer several questions. An example is an Every Page is Page One topic, like a Wikipedia article, which often has a flat structure that doesn’t constitute more than a maximum of a couple pages.
These topics are not building blocks that build something bigger. Rather, each topic is meant to work independently of the others, but to remain interlinked. Certain sections of a topic may be the same in two or more topics. In such case, the content is conditionalized or chunked, and reused according to scenario 3.
Scenario 3: A Topic as a Unit of Reuse between Books
This scenario works off the assumption that the user holds a preference for book manuals. The user does not want topics, thus you deliver books to the user in the form of user manuals. Topics are only visible in the CMS.
You create a topic when content needs to be reused between two or more manuals. The chunk that needs to be reused is extracted and placed in a topic which is then referenced from each manual.
The benefit is that you only need to change content in one place—hence single sourcing. Here, it’s only the chunks that must be reused between manuals, and nothing else. This is because you want to keep the number of files managed in the CMS to a minimum, since every file has an overhead cost in terms of version management, linking, etc. The size of a topic totally depends on what must be reused. When you need to reuse, you chunk, thus there will never be a topic in the system which is not reused in two or more manuals.
Chunking can be done for other reasons than the reuse of content. Many technical communication teams chunk the contents of a book into topics within the CMS to allow multiple authors to work on the same manual independently of each other.
Publishing book content as an HTML delivery— where users can only see one topic at a time by clicking on the table of contents— can be said to still constitute delivering content according to the book paradigm. The user is forced to figure out the logic behind the static structure in order to get to a topic.
When Trouble Arises
I often wonder why companies invest a lot of money chunking existing content into thousands of topics (as if each topic were an answer to a user question, as in scenario 1), only to deliver content in the form of a static PDF-book (as in scenario 3), where only a small fraction of the topics are reused.
To chunk content into thousands of topics in the CMS, without reusing or delivering topics to users, often creates headaches since the overhead management cost for each topic fails to create any value.
On the other hand, having content chunked into thousands of topics provides the flexibility to reuse content when building additional deliverables without impacting the existing set of user manuals. But my experience is that companies seldom create additional deliverables, which means that chunking content into thousands of topics “just in case” is nothing more than expensive insurance.
Furthermore, if technical communicators in a team hold different opinions—for instance, some implicitly assume that the content strategy follows scenario 1, while others believe the strategy follows scenario 3—you end up with a lot of confusion, which in turn leads to inefficiencies.
Keeping Both the Technical Communicator and End User Happy
My experience is that technical communicators and end users have different needs. Technical communicators want to keep the number of files within a CMS to a minimum, since the number of files to manage is proportional to the cost of maintenance. Keeping content within larger book files in the CMS allows one to easily search and replace easily, etc. Besides, some users prefer books, which justifies the management of content in book files within the CMS.
However, the majority of users want to find answers quickly in a web knowledge base by searching and filtering, without being forced to skim through a number of books.
So, whose need will win the struggle?
A solution is to manage content in book files within the CMS, where the chunk level is defined by metadata. Then turn each book into topics when publishing to a web knowledge base, allowing users to search and filter answers. The book file is published in parallel to traditional PDFs to satisfy those who prefer books. This is possible with Skribenta Finder, an add-on to the Excosoft CCMS, Skribenta.
Using the unique concept of “wrappers,” Skribenta Finder allows you to define which content in the book file should be treated as a topic. This enables you to get started faster, delivering topics to the user, without being forced to first invest heavily in chunking each existing book into topics within the CMS.