There are effectively three things that matter when you’re evaluating the overall quality of your content creation process and system:
Everything else is details.
These three factors are fairly easy to assess.
- Efficiency = how easy is it to reuse content and how quickly does the system produce your required outputs
- Flexibility = how many output formats are required or how easy is it to collaborate
- Scalability = how many collaborators can the system support and how much output (or throughput) can it easily produce
Efficiency and consistency are simple to manage in small teams. When there are three or fewer people contributing to your content creation, you can control consistency with interpersonal communication and peer review, even though the process is manual. It’s when you start to scale that these factors need to be approached more strategically. These factors are also achieved through reuses which, in most authoring systems may be difficult to achieve and manage.
Flexibility is size and scale agnostic. If you need PDF, eLearning, knowledge-base, and chatbot from your content, it doesn’t matter if your team is one person or one hundred people.
Scalability is critical when you are dealing with more than a few documents or a team of more than a few people. Once your requirements include having to support a large number of documents, you wind up having to look at: How do you support multiple contributors? How much output can the system produce at a given time? How easy would it be to reuse information in various documents without having to determine whether the reused pieces stay in synch?
So, let’s look at some options for content creation systems and see how they stack up to these pillars.
It’s going to be no surprise that Word largely fails on all factors.
While Word is fairly good at producing single unstructured documents, writers end up spending 30-50% of their time on formatting. You have to deploy templates and train teams to use them religiously. The content developers can also spend time trying to tweak the presentation, over concentrating on the content itself, which results in less meaningful information. Reusing any amount of content is achieved through copy and paste, which often results in content creation that becomes out of synch if changes occur. To keep the reused content consistent requires outside management methods which are error-prone and time intensive.
While Word is easy to use for a casual writer, the output capabilities are limited and you cannot change the look and feel of a document to meet different needs. While the PDF and printed page may look the same, if you need to create web output or online help, you’ll need an entirely external process to support this, and oftentimes, that system will be based on people copying and pasting content into it.
Because Word is so prevalent in the marketplace, it is useful in terms of content portability should an organization be acquired or divested. However, rebranding the content, should the need arise, becomes challenging.
Because Word is designed for a single user, scaling to produce documentation for enterprise doc sets can be challenging. You need to develop external, elaborate processes and procedures if you want to have multiple collaborators and the application is deployed using a standard license. Using the cloud version could result in contributor collision that you’ll have to resolve.
If you need to create a large documentation set, updating the resulting document is onerous. On the other hand, combining smaller documents into something bigger is challenging.
Help Authoring Tools (HATs)
Some examples of HATs are MadCap Flare, Adobe FrameMaker, DocToHelp, and RoboHelp. These systems are designed to support the needs of small teams with low complexity requirements. Under the right conditions, each of these tools can do this job well, but as your team grows or your requirements expand, HATs aren’t going to keep up.
Similar to Word, most HATs use a paradigm that intertwines content creation and formatting. While this is familiar to most casual contributors, it results in the same problems in terms of the processes surrounding the implementation of templates and enforcement of styles and time lost tweaking the presentation rather than developing content. The advantage of HATs is the ability to build a larger document from individual components which can be a stepping stone to getting a team of contributors working in a structured, topic-based, paradigm. Most HATs provide the capability to apply metadata to improve searchability but may not be able to provide that information or capability effectively to the resulting output. Some HATs provide mechanisms for reusing content which improves consistency of content.
HATs do provide some flexibility to produce outputs. While their main purpose is to produce HTML-based output, most modern HATs also produce other formats, such as PDF as a side-benefit.
Should an organization be acquired or divested, HATs will require one of the organizations to change their processes and acquire licenses for software so that all authors are using the same processes, which could become expensive. This could result in duplicate processes for a significant time during transition or, worse yet, continuation of dual processes. Rebranding the content, should the need arise, becomes challenging.
Scalability is where HATs tend to struggle. HATs use a desktop publishing paradigm for content creation. This becomes problematic as you increase the number of contributors because the software has to be installed on each machine driving up the costs of scaling your publishing infrastructure. This model also tends to force your content creation processes to take a partitioned view of your corpus which inhibits cross-collaboration – your writers tend to concentrate only on their assigned portions of the corpus, rarely contributing to other areas. This lends to unfamiliarity in other areas of the content stifling your capability to cover that content development should any of your team be unavailable for extended periods, and increasing risk associated with a team member leaving the organization.
Because access to the content requires the application to be installed on each machine that requires access to the content, content reviews become cumbersome. Most organizations develop a separate, disconnected, process for SMEs to review the content. With the comments divorced from the source, transcription errors incorporating the changes into the source files can occur.
Markdown is currently the cool kid on the block, it’s a part of a cycle that mirrors the boom-bust of wikis during the 00s. Markdown can be very efficient from the writer’s perspective and if your only output target is a relatively small, static documentation site, it can be a wholly functional solution.
From a writing perspective, markdown appears to be extremely efficient. However, the markup language itself is not intuitive for unacquainted contributors, which may actually slow down an otherwise fast process. This problem could be overcome by editing tools, but using WYSIWYG authoring tools that provide the markup capability makes the use of markdown questionable from a benefit standpoint.
Reusing content is the copy and paste method which, as described previously, runs the risk of inconsistent content should there be changes. As with other systems already mentioned, acquisitions a