Should your style guide be built into CMS, or an extra layer in post-production?
The endless capabilities of an open-standard XML vocabulary like DITA means that you can design and automate the creation of content modules with minimal loss of usefulness across different platforms and applications.
However, cleverly implemented content automation does not necessary imply good content marketing. In fact, it's through content marketing that an enterprise, business, organization or brand bridges the gap between data and consumer. In other words, there must be rules to configure data that meets specific brand, linguistic and cultural guidelines so that people want to read what is produced. This is where the style guide comes into play.
"Content management goes hand and hand with content marketing."
Where did authors traditionally encounter style guides?
Style guides have long served as the way we achieve commonality and consistency from a particular institution. Two long-standing guides, the AP Stylebook and the Chicago Manual of Style, have been in heavy use by editors and journalists since the 1950s. Some brands have developed their own variations along the way to distinguish themselves in the market and ensure readability across different audience demographics.
With manual authorship, the interaction with style guides is simple: An author writes a piece of content with the style guide in mind. Editors may verify or adjust style guide usage, but the process still remains relatively contained to authorship.
In this way, style guides are primarily an internal tool, put into action by the person creating the content. Yet in the age of automation – where content can be created, reconfigured and and managed without ever being touched by human hands – where should style guides live?
CMS style guide implementation: Internal versus external
With CMS that enables automated content creation, there are essentially two scenarios where a style guide can be put in place.
The first is the code of the content generation module itself. The data module creates new content automatically and formats it according the style guide, which has been implemented algorithmically within the module. In other words, the style guide is woven into the content creation software, a process that might be termed "internal" implementation. Internal implementations are relatively simple to install and activate at the expense of complexity to the CMS architecture – effectively making it less agile and leaving room for configuration errors.
The second scenario is implementing a style guide outside of the data-creation module. This is a more "external" process and is akin to the traditional copy-editing function. It could involve the work of a human editor/author reading "copy" with the style guide in mind, or it could be an automated, rule-driven package applied in a "secondary" content configuration process. The human approach limits the complexity of the CMS at the expense of low-cost scalability.
Creating your style guide
Choosing which of these two implementation styles is right for your organization and CMS design is something that depends entirely on your resources and needs. However, one way to gauge the best approach is to explore what makes up your style guide.
The three basic elements of a style guide are:
- Content attributes
- Tone and voice
- Rules
Content attributes typically involve the basic building blocks of the content, i.e. what data you will be feeding into the CMS. From there, tone and voice tie closest to the core of hypertext and data tagging. If your voice, for instance, is casual yet authoritative, having data tagged according to these descriptions can help guide the way content is subsequently assembled. Finally, rules dictate the parameters of the content – what phrases or structures must be avoided.
Through exploring the full scope of your style guide, you can more clearly see whether or not it can be integrated into CMS architecture without causing future issues.