by Jim Korth, PR Committee member

Ask ten technical writers for their definition of structured authoring and you will get ten different answers.

Although structured authoring has been with us for several years, it is still regarded as one of the next big things on the technology frontier. While it remains difficult to define, its potential is exciting when seen in action. Yet, industry veteran Neil Perlin feels structured authoring goes far beyond just installing FrameMaker or DITA (Darwin Information Typing Architecture).

The STC Lone Star Community was privileged to have Mr. Perlin as its featured speaker at its September 6th meeting. Perlin is the owner of Hyper/Word Services of Tewksbury, Massachusetts, and has 28 years in technical communication. He has worked with XML, single-sourcing and structured authoring since 1998. As the STC’s lead representative to the World Wide Web Consortium from 2002 to 2005, Perlin is known industry-wide.

Perlin enlightened the meeting attendees with anecdotes and amusing stories about the trouble organizations get into when they go blindly down the road of document creation. He summarized the early approach of many organizations as, “There’s never enough time to do it right, yet there’s always enough time to go back and fix it.” He condensed this to “Ready, fire, aim, …damn!”

Document creation has evolved since those days. Structured authoring now occupies center stage because it allows authors to write documents that are more consistent, easier for readers to use, easier and more predictable to single-source, and easier to localize.

Structured authoring isn’t perfect. Some authors view structure as a constraint that limits their creativity. Structured authoring requires more detailed up-front planning and increased technical skill and rigor. Content ownership can also be very political. Some authors simply rebel. Perlin pointed out that it is just as challenging to stay inside the box. On balance, the drawbacks of structured authoring are largely process related and should easily be offset by its benefits.

Current definitions of structured authoring are flawed because people are often told that documents must be valid based on a DTD (Document Type Definition) or XSD (XML Schema Definition) to be considered truly structured. While that answer is technically correct, it is difficult for most people and it is unrealistic for companies unfamiliar with the underlying technologies. Dropping Microsoft Word and switching to FrameMaker or DITA is usually not feasible. A compelling business case often can’t be made due to budget limitations, corporate culture, and politics. Perlin also astutely pointed out that switching to FrameMaker can further isolate the documentation group from the mainstream organization.

So what to do? First, seek to understand or learn the company’s strategic direction, finances, culture, and politics. Consult with people from groups outside of documentation such as IT, engineering, marketing, and sales. What is their take? Talk to people who have lived through similar “re-thinkings.” Then choose the appropriate definition from the four that Perlin suggests.

• Definition 1: Most simply defined, structured authoring in Microsoft Word is visually structured with all text in Normal style and locally formatted using the text formatting toolbar.
• Definition 2: Structured authoring is programmatically structured using styles, perhaps a CSS (Cascading Style Sheet).
• Definition 3: Structured authoring is programmatically and visually structured using templates with an attached CSS.
• Definition 4: The final, most refined definition of structured authoring is that which is programmatically structured by being valid according to a DTD or XSD, like DITA, which is the best choice because it supports a structure programmatically.

The cultural, political, and strategic issues involved in choosing the right definition can be daunting. If we are creating finished products, then code, structural cleanliness, and consistency are irrelevant as long as our material displays correctly. We can use a simple definition. However, if raw material, the building blocks of content management systems, is our goal, then code, structural cleanliness, and consistency are crucial for controlled, predictable, and automated processing.

For Perlin, this latter area is where the future lies. He suggested the process for moving to structured authoring calls for strategizing both big and small. Thinking big, we should understand the company’s plans and envision how documentation can support the company’s strategy. If documentation was instead called content, would receptivity differ?

Thinking small, define a content strategy that supports the company’s larger strategy and define what you’ll need by way of content types (user guides, quick references, and others) and output formats (WebHelp, HTML Help, and so on). Identify your intent for the content. Finished product or raw material? Is the company’s culture controlling, or loose and mission-oriented?

You’ll get an idea what you want to do and be able to select the right definition of structured authoring and the correct tools to use. Start with Perlin’s most refined definition and find the one that’s most future-proof with the minimum cost and disruption. You can at least begin shifting the underlying culture, which is a huge step forward.