Content monoculture
I’m having some trouble with the idea of “extending DITA” outside the world of technical communication. DITA is obviously important in the right environment, but should we be advocating the use of DITA for more and more content?
I do believe that there is significant room for expansion in the DITA world, and that there are many, many organizations that can benefit from the use of structured authoring, XML, and/or DITA.
But I don’t think that we have been sufficiently clear about what sort of information is suitable for DITA. Consider the situation in my own very small organization. We use a wide variety of tools and technologies for content collaboration, including the following:
- Google Docs: For quick-and-dirty non-deliverable documents, such as writing marketing blurbs for a book covers or listing our priorities for office space.
- Wiki: For office policies and procedures, and other information that changes but is of no particular interest to outsiders.
- Basecamp: For file exchange with clients. Also used for meeting notes and other client-related information.
- DITA: Most of our client-deliverable content, including proposals and reports, is written in DITA. This information is carefully controlled and versioned. (And no, I’m not going to tell you where this content lives. The approach that makes sense for our 50–100 pages per month is not appropriate for our customers, so let’s just not even go there.)
- Source control system: We use source control for code, such as DITA Open Toolkit plugins, custom XSL, and the like.
- Word/OpenOffice/LibreOffice: Yes, really. Some of our customers require us to deliver a statement of work as a Word file.
- InDesign: Marketing stuff.
- WordPress: our web site
Should we have a unified place to put all of this information? Actually, no. We use each type of information for different purposes, and the tool choice reflects this.
What conclusion should we take away about DITA (and structured content)?
First, let’s acknowledge that implementing XML is expensive and difficult. That may change over time, but right now, you need a compelling business case before committing to the pain that is XML implementation.
XML may be appropriate for content that meets the following criteria:
- It is difficult to create and valuable to the organization.
- The content creation process would benefit from formal reuse.
- The content is updated frequently.
- The content must be consistent in formatting and style with related content.
- The organization needs to control the content (because of regulations, policy, or legal issues).
- The content is translated.
If you’re looking at these issues and not sure how to proceed, consider our content strategy analysis services.
About the author
tbo
In a nutshell: structuring contents is more a organizational problem than a technical one.
Michael Müller-Hillebrand
It is a much too common misconception that technology solves problems. Far too often we see the opposite! I find myself spending at least half of time talking with clients about processes before starting to do some technical work. And, I have to admit, sometimes I even try to talk them out of a technical solution. Some don’t like that…
Sandra
Excellent points. I think there is value in extending DITA to marketing material and SME documents that could benefit from reuse with Techcomm content. But for internal or collaborative documentation? hard to see the bennies…
Mark Baker
Sarah,
I think “extending” DITA is probably an inevitable part of its arc. Like other markup systems before it, it will grasp for hegemony and fall short, perhaps killing itself in the process. I’m not sure why this is, but people seem to fundamentally miss the point that structure is specific to a particular task. If you extend and attempt to encompass other tasks, you inevitably become either more general (which compromises the advantages of structure) or more complicated (which compromises ease of use).
You are certainly correct: we create different sorts of content for different purposes, and using one tool or one system for all of it would be counterproductive. Since “content strategy” is the current rage (not without reason, by any means) it is well to remember that not all content is strategic. Some content is tactical. Some content is operational. Some content is incidental and ephemeral. You don’t create all forms of content in one authoring tool any more than you carry all kinds of loads in one kind of truck.
As to XML, it is structuring content that is expensive and difficult. It’s really not XML’s fault. Structured data is hard work, and neither tools nor standards will change that — they may remove some incidental obstacles, but the hard part is structure itself.
Another of the odd things about the history of SGML/XML is that, despite its many advantages, it seems only one advantage at a time can grab any substantial part of public discourse. Originally the one advantage that was talked about was interoperability between systems. Then it was separation of content and formatting. Then single sourcing. Now reuse.
There are a couple of advantages that do not occur in your list of criteria, but which I think are just as important as reuse or formatting independence: linking and auditing. XML can allow us to create incredibly rich linking at much lower cost than non-structured methods. And well structured content can allow us to do many forms of validation and auditing which can greatly increase quality and reduce production time.
However, it is a matter of horses for courses. DITA is not optimized for linking. DITA pays for its reuse potential with a large amount of content management overhead, and adding rich linking just makes that overhead worse. Part of the reason that translation makes your list of criteria is that translation is an ROI multiplier for reuse, and without it, it can be difficult to offset the cost of DITA’s content management overhead.
Not only should DITA restrain the impulse to extend itself into other areas of content, it should not attempt to encompass all of tech pubs either. A tech pubs environment in which rich linking is a higher priority than reuse, for instance, would be ill served by adopting DITA.
Don Day
As one of DITA’s more visible advocates, I tend to look beyond the office for interesting new growth areas for the standard. So my DITA-colored glasses tend to see wikis and blogs as content that, in DITA form, would be much easier to repurpose as eBooks or any of the usual DITA-OT outputs.
Whenever I hear of XML being hard to implement, the XML-based Open Office and Open Document formats come to mind as being sublime examples of XML pushed way beyond the limits of decency, and yet the tools are affordable or even free, and are relatively easy for newbies to understand and use with basic productivity. This is what I envision for the DITA tools that could help the writers of neighborhood association meeting minutes, ultimate frisbee game rules, or tutorials for called change bell ringing. I’m not sure whether any of these are the next big DITA wave, but they represent groups that have content that is managed for consistency and reuse, and for which DITA has more advantages than HTML or the office formats. So I’m thinking beyond the traditional office or product documentation scenario… more like “transgenic DITA for the rest of us.”