Roles and responsibilities in XML publishing
The roles and responsibilities in an XML (and/or DITA) environment are a little different than in a traditional page layout environment. Figuring out where to move people is a key part of your implementation strategy.
In an unstructured (desktop publishing) workflow, content creators need a variety of skills. The three most important are:
- Domain knowledge (expertise about the product being documented)
- Writing ability (duh)
- Knowledge of the template and formatting expertise in the tool being used
For a structured workflow, the first two stay the same, but paragraph and character styles are replaced by elements. Formatting expertise is less critical—the formatting is embedded in a stylesheet, which is applied to content when it is time to create output. Knowledge of copyfitting and production tricks is no longer relevant and can even be detrimental if the content creator insists on trying to control the output by overriding default settings.
The content creator needs less template and formatting expertise, especially if the content is highly structured and provides guidance on what goes where. Generally, content creators need to focus more on how to organize their information and less on how to format it.
The role of the technical editor (assuming you are lucky enough to have one) also changes. Document structure is enforced by the software, so technical editors can focus on overall organization, word choice, and grammar. Technical editors are often responsible for reviewing large amounts of content. This perspective can be helpful in establishing an information architecture.
Speaking of information, we have the information architect, who is responsible for determining how information should be organized and tagged. Typical tasks for the information architect are:
- Developing guidelines for topic-based authoring (for example, how big should a topic be?).
- Establishing rules for tagging. For example, when should an author use the <cite> tag and when the <i> tag?
- Organizing shared content and establishing guidelines for reuse.
The equivalent responsibilities were typically handled by the technical editor and the production editor in an unstructured workflow.
In an unstructured workflow, production editors are responsible for finalizing the layout/composition of unstructured content. They typically have deep expertise in the publishing tool and know all of the tricks to make output look good. Very often, production editors are permitted to override templates to copyfit pages and make the final result look better.
The role of the stylesheet programmer is new in an XML workflow and replaces the production editor. The stylesheet programmer creates a script that transforms XML directly into output (such as PDF or HTML). In effect, the handiwork of the production editor is replaced by a script. Stylesheet programmers need a thorough understanding of XML and especially of publishing scripts, such as XSLT, but they need almost no domain knowledge.
Here are the typical roles in a structured workflow:
Did we miss any? What do you think?
Portions excerpted from our Structured authoring and XML white paper.
What puts me off using XML-based tools is the level of XML expertise needed. As a technical author in a small firm with no XML expertise to hand, and as someone who hates programming, the learning curve looks daunting and has so far put me off. The bulk of my output is printed paper manuals, where page layout matters very much and I often have to tweak things to getting it look right, using multiple columns and text boxes. I’ve just about learned how to beat Word into creating the effect I want. Learning how to do the same with XML would be a real pain. Unfortunately, being XML-phobic rules out a good few content management and single sourcing tools and I could really use such a tool to manage content that is common between printed manuals for related products in the same family as well as managing that content in multiple languages.
How much common content do you have? At some point, the cost of content duplication (especially if you have localization) may exceed the cost/pain of moving to XML.
A well-designed template (whether XML or not) should eliminate the vast majority of “tweaking.”
Our proof-of-concept DITA publishing system uses FrameMaker and a couple of plug-ins from Leximation. The plug-ins take the role of the stylesheet programmer in this workflow. However, when things break, you have to have a “DITA mechanic” (yours truly) on hand who is willing to dive under the hood into the XML and fix whatever needs fixing.
To Bruce’s point, there’s definitely a steep learning curve,. But once you’ve seen a couple of typical errors, you learn what to look for, and the time to fix anything drops quite a bit. Most of our problems are related to topics or graphics not being where they’re supposed to be on the DITA server. No, we’re not yet using a CMS. We don’t even have check-in/check-out rules yet! Hence the need for a mechanic.