Published on July 29th, 2013 | by Rahel Bailie0
To DITA or not to DITA: That’s a Good Question – Part 2
In the first part of this article, published last week, I made the contrast between authoring environments and publishing environments. What was not made explicit was the difference between creating content in a Web CMS environment and authoring in an authoring environment that exists outside of the Web CMS. This is a point worth making explicit because it seems to be at the crux of some of the misunderstandings that occur. Let me use an analogy.
An XML editor is to Photoshop…
When a photographer takes a photo, or a videographer takes a video, they will want to edit their work before publishing it. They will go into a photo editing environment, such as PhotoShop, or a video editing environment, such as Final Cut Pro, to do the fine-grain manipulation of their work. They will then upload the final version to the Web CMS or other publishing platform. At that point, they may do some basic tweaking, such as cropping or resizing or adding alt text. But all of the real work has been done in a back-end, powerful, specialized environment.
DITA (Darwin Information Typing Architecture) is the standard behind the XML editor and the underlying CCMS (component content management system) that provides a back-end, powerful, specialized environment for creators of text-based content. Authors can do all of the fine-grain manipulation of content that needs to be done. They can then have a transformation script run, which compiles the content into its final form, and uploads the content to the Web CMS, or other publishing platform, for consumption and presentation.
There have been other powerful authoring environments before DITA. Adobe FrameMaker created structured content in SGML (the precursor to XML), and then in XML, though it seems that the majority of authors used the non-structured version. There are numerous HATs, from Adobe RoboHelp to MadCap Flare to Author it to the cross-over product, Eclipse. There is even a DITA plug-in for MS Word. DITA has become the gold standard for being able to manipulate content in powerful ways, in a dedicated authoring environment.
Re-use vs repurposing
I think it’s important to recognize that there are two very distinct ways to recycle content.
The first way, as mentioned in the example in last week’s post, is associating articles about the Paleo diet, and perhaps repackaging them into an ebook. That is one type of re-use, which I would label repurposing. In that case, the whole article (a content “blob”) is associated with other whole articles (other “blobs”) and curated into a new context. In other words, an article has had its use as a feature story, and now becomes a chapter in an ebook. This is more accurately described as repurposing content. The content is, in effect, used in a single article. Then, the article, as a whole, is repurposed. It may go from feature article to a related article to an ebook chapter, but it is used in its entirety.
The second way, also mentioned last week, involves re-use within the topic itself. It involves creating a bank of building blocks – much like the way that the UX community talks about design patterns that they isolate and then re-use for consistency – and re-using those in within a topic. I’ve taken two descriptions from the Web and shown how they could benefit from re-use (not repurposing).
So do I need DITA or not?
Here are some questions to ask when deciding whether or not a DITA authoring environment could be of benefit in your situation.
- Do you have a large body of content to deal with – have you found yourself doing a Google search to find content that you should be able to locate through a content repository search?
- Are there standard words, phrases, or paragraphs that you repeatedly use – do you often search and copy phrases from elsewhere in your body of content?
- Do you have ongoing issues with consistent use of language between topics – for example, certain sentences or paragraphs that should be identical in a large number of instances?
- Is the content subject to change volatility – that is, the organization changes the names of features or products on an ongoing basis?
- Is your organization in an industry where compliance is an issue – accuracy is important?
- Does your company have multiple product lines where descriptions could be quite similar but with key differences?
- Is your content highly structured – that is, do you create many of the same type of content, where formalizing the schema could be beneficial?
- Can your content benefit from being created in a modular way that has mix-and-match qualities to the topics?
- Is your organization a target of lawsuits – so you need to be able to find all of your content and update immediately when products, services, or market or legal conditions change?
- Does your organization need to respond to market conditions quickly by gathering and modifying existing content – for example, if your organization has a rapid adoption rate for new products with similar features?
- Does your organization translate into multiple languages, making a key consideration content consistency in the source language?
- Do the writers in your organization have the skill and discipline to learn an XML editor and work in a structured authoring environment?
- Does your organization have the technical infrastructure and to support the effort, especially to create the transformation scripts that turn DITA content from the component-based content repository into HTML (or other standard) content that can be used by the Web CMS?
If you have little content and little or no re-use, then DITA is likely not the solution for you. However, if you have answered yes to at least two of these questions, and you are looking for ways to manage the content lifecycle more efficiently, then you should add DITA to the list of standards and systems to be considered.