• Blog Home
•   |  
• Rockley Web page
•   |  
• About

Structure, DITA, and content other than technical documentation …

Posted on October 16, 2007
Category Best Practices | Leave a Comment

In an earlier blog entry, I commented on the value of structuring your content, even if you aren’t going to DITA or CM systems. I received a couple of comments that I was going to respond to in the comments section, but then again, it makes a certain sense to give them a greater response here. Because it brings up a subject near and dear to our hearts: the expansion of DITA (and component content management) beyond technical documentation.

The first comment came from danortega :

Structure is always better than no structure. If you’re going to go to the effort of structuring your content, you might as well follow an industry standard such as DITA, assuming your content is going to be integrated at some point into something else. All the mainstream authoring tools support DITA at this point, so it’s not like this type of capability is hard to find.

I would agree fully with Dan’s point if the sole perspective was the care and feeding of technical documentation. After all, if you take a quick look at DITA, it looks like something you would use to create a Help system. Topics, concepts, tasks, and reference. They were the topic types delivered in BlueSky’s RoboHelp, back before Adobe bought in. For a technical document Help developer, DITA is an easy transition to get your head around. It’s not much more of a stretch for developers of user, reference or systems guides to see the applicability of DITA to their tasks.

But, if you are creating other types of content — policies and procedures, marketing materials, training materials, legislative information, magazines, web sites, legislative information — well DITA isn’t exactly an “industry standard” anymore, not from the perspective of structure. If you can’t make use of concepts, tasks, and reference, then you must make do with topic. And quite frankly, base topic is not really that much more structured than HTML, which isn’t really structural at all. Now there are other benefits to moving to XML and component content management than structural control alone, so maybe simple topic is good enough. And, of course, you could specialize.

The concept of specialization, is very important as more and more people are looking at DITA as a mechanism for creating non-tech docs content. At the DITA 2007 conference several people lamented the lack of presentations on applying DITA to something other than technical documentation. (Although Eliot Kimber’s presentation on DITA for the publishing industry was excellent.)

In fact, we’ve heard rumors that the DITA TC is considering a subgroup to look specifically at enterprise content needs and fitting to DITA.

The other comment came from Mollye Barrett :

… The benefits of well-planned structure definitely offer high returns in the areas you detailed.
I focus on the XML, analyze the content, determine the document type and then decide if a DITA is appropriate. There are other industry standards that also work. Allowing authoring software support to drive structure is a shortcut prescription that may, or may not, work for the user and the content.

And now Molly has an excellent point. When people ask “Can we use DITA?”, I suggest that the question should be rephrased as “Should we use DITA.” The first question is easy to answer. I don’t even need to know what kind of content you create. The answer is an unequivocal “Yes!!” You could use DITA for any kind of content. Ignore Concept, Task, and Reference, and implement all of your content in generic Topic. You could do it. But would it be effective? If you take that perspective, the second question should be rewritten as “What do I need to do to DITA to make it an effective content creation mechanism for my content?”

That’s the important question. What do you need to do to DITA (i.e., specialize) to make sure that you get the content you need in the authoring process and to make sure you can manipulate that content (render, etc.) to get the outputs you need.

There is more to structure than just a set of tags to markup your data. When you analyze the structure of your content, you must approach it from the perspective of usability. In other words, what is the content that my user needs to see to answer the question that brings them to my content in the first place? What types of content do they need? What level of detail?

Then, as you move towards implementation and have to determine the effective tag set you need, you have to ask “how must I define the tag set to ensure (as much as possible) that I get the content that I need from my writers.

If you have many writers, generic won’t do, you need consistency from the tag set. It you have occassional writers, generic won’t do, you need guidance in the tag set.

If you have professional writers who author in the tag set every day, you can maybe get away with a more generic tag set. It depends on how professional they are and how much you want to rely on editorial process to maintain structural consistency.

So for any content you are creating, the approach that Mollye uses (which is what we also do and recommend) is the right approach.

Comments