Loading...
 
Search icon Looking for something?


Key Content: Too Many Pieces
Published
2006, Q1 (October 21, 2008)
By Bill Albing, Past Chapter President

Bill Albing
Bill Albing

Image

Do you ever think about how much time you spend tackling process issues and tools issues? As Greg Rakauskas said at a local STC meeting about wikis, and I’m paraphrasing him, “Even with new online collaborative tools, it is still difficult to get information out of subject matter experts.” Even further, there are still too few resources to develop all the content you know is needed for a product, and too little time to meet the deadline with a great quality piece of writing. There are still process issues that are perennial, regardless of the tools we use. As long as we are working with people, there will be clogs in the flow of information. As long as we are working for corporations, the bottom line will be money. With the dependence on computers and information in accessible and digital form, there is still a challenge in getting meaningful information. The tools, as advanced and automated as they are, will not fix all our problems. But we have to work with what we have, and automate as much of the production and maintenance of our content as possible. We must, as the British say, muddle through.

Too Much About DITA

There is so much buzz about DITA (the IBM-started open standard for topic-based information architecture), that I have to say a word about this new set of tools. Let me start by saying the term is a little inflated in its self importance, but that’s part of the branding. DITA simply stands for Darwin Information Typing Architecture. The Darwinian part has nothing to do with the current debate about teaching evolution in school but rather about the ability to customize (specialize) the topic types for your work and still base them on an ancestor topic type from which to inherit all those base settings. It’s really about object-oriented inheritance (to borrow the language of the software development industry), but the creators of DITA prefer their own descriptive vocabulary.

The information typing part means that you look at the types of topics, the metatags in XML, the information about your content. And it also implies modularization in as much as the information is categorized into those types. Where IBM used the word “information,” many of us use “content,” which is more than “data” and not finalized in a “document.” Instead of “pages” or “chapters,” we use the generic content container “topic” which may or may not get delivered in a printable form. With information typing, there is a place for everything, and everything in its place; a type for each piece of information, and every piece of information in its type. And IBM uses the word “architecture” to describe this grandiose set of procedures because it’s not just a DTD, a document type definition; it is a way of looking at the information. It is a weltanschauung, if you will.

With all this information architecture mindset, there is so much more to making an authoring environment DITA-ready. That’s why FrameMaker and Flare and other tools won’t be DITA-compatible overnight. FrameMaker is still just an authoring environment (albeit with a great print engine for making PDFs); it will not manage the modularized content in the way a content management tool will. DITA does not have a corner on the market of modularized and reusable content.

Many of us have been working with our own topic-based DTD and our own set of tools before DITA came along. Having a tool that can output DITA-ready XML alone won’t transform the technical writers on your team into content developers or information architects. The approach to working with modularized content and keeping the metacontent as well requires a different working environment.

The move toward content management systems is a move in the right direction, but is not the complete solution. There are no out-of-the-box solutions that work for everyone. Content management alone will not suffice; now we need translation and localization tools and tools that will publish to any number of output devices and media. Will it output to a wiki or a blog or a podcast? Some of us have moved to content management systems and authoring environments that promise to be all in one. But even these, I suspect, have a fair amount of customization involved (or consultant expense) and will not offer as much freedom as the content development team might require. As our projects include ever more requirements for accessibility and localization as content development becomes more collaborative, our work in tailoring the tools never ends.

Having a local conference on DITA may be a start for some people who can afford it, but for most of us, the chance to talk with others about how we are facing our own issues and dealing with processes and picking tools is an ongoing endeavor that involves going to local STC meetings, keeping up with online lists and chats and generally keeping up. DITA is only part of the picture and not the only way of describing the effort of modularizing technical content.

Grand Solution

Our work is becoming more fragmented. Not only is the content becoming more modularized—the very processes we use are becoming more modularized and the very tools we are using are more numerous and more task specific. To accomplish the software product documentation where I work, we develop some of the content in FrameMaker and some is automatically generated in a tool by Innovasys. Then we use Saxon to parse the XML out of FrameMaker and we use another tool to compile the HTML to make a help system. We also use a Web site management tool for fine tuning the HTML if needed, and another tool for checking the validity of the generated XML and another to generate the PDF files.

Some of these tools are free and open source, and some of these tools are expensive. Some of the customizations and the template development are necessary and labor intensive.

Certainly getting it all to work together is an effort. Nothing works right out of the box anymore. But getting the right tools is worth the effort. There is no single environment that does everything immediately, but much more can be automated these days and the capabilities of tools are improving all the time.

As a profession, we have never offered enough financial gain for sophisticated tool vendors to focus only on our needs. We borrow tools from the XML world, where most of the effort is tagging data, not human readable content. We borrow tools for content management, where most of the focus is on external web sites, not large pools of product documentation. We borrow page layout tools, but these are mostly for marketing or graphics teams. Maybe this hints at what will be the grand solution to technical documentation tools. By being more specialized and modularized and all working together, the tools we pick can be assembled to meet our unique requirements. By picking the authoring components we need, the module management tools we need, the publishing and delivery tools specific to our customers, we can tailor a system that will allow us to develop, deliver and maintain our enterprise’s content.

I would challenge the folks behind DITA and the vendors from Adobe and Microsoft to Vasont and AuthorIt to Idiom and Rascal, that until individual components can plug and play together, just as our modularized content is moving toward that goal, we will not be satisfied. Those tools have a better chance of surviving in the market if they interoperate. Until then, we will have to deal with too many pieces.


Bill can be reached at bill dot albing at keycontent dot org End of article.


More articles like this...
Comments powered by Disqus.
RSS