Data Conversion Laboratory, Revolutionizing Publishing for the Digital Age 
  DCLab.com | About DCL | Tech Info | Press Info | Contact Us | DCLNews | Partners | Wiki | Client Area     
menu
Data Conversion Lab

About DCL
  Why go to DCL?
  Clients
  Company Background
  Management
  DCL in the News
  Events
  Holiday Calendar
  Mission

DCL News
  Current Issue
  Back Issues
  Subscribe

Technology
  Technology Resources
  FAQ's
  Glossary
  Presentations
  DCL Work Tracking

Press Info

Clients' Area

Contact DCL
  Directions
  Request Estimate
  Positions

Books2Bytes
Popular Pages
* Current Issue of DCLnews
* DCL featured in The Columbia Guide to Digital Publishing
* Slash Document Costs
* Ann Rockley on ROI in CM
* PDF Resources
* XML Conversion Resources
* Roundtrip Document Conversion
* DCL Resources Library
*

Converting Legacy Data...

*

Aviation & Aerospace

*

PDF Conversion to XML & MS-Word

*

PDF Conversion

*

Quark to XML

* Getting Content into XML
Fact Sheets
* Public Access for Research Materials
* S1000D Conversion
* Content Reuse Assessment
* Document Conversion
* SPL - Pharmaceutical Industry
* Harmonizer™
* Jeppesen Map Revision Service
Technical Papers
* Why STM Publishers Should Use XML...
* Department of Defense and the Power of XML
* Your Data in XML
* SGML to SGML 1
* SGML to SGML 2
* Quark to XML
* Plan Ahead
* Do it Yourself?
* Encyclopedia
Presentations
* Conversion to XML: Documents versus Data (11/2003)
* Data Migration Considerations  (6/2003)
* Technology for Cost-Containment and Efficiency  (4/2003)
* Converting Textbooks to Meet the National XML Standard for Accessibility  (3/2003)
* More Presentations

How to Rewrite Content for Reuse: Part II

By Pamela Kostur, Partner, Parallax Communications

In Part I Pamela Kostur outlined the benefits of reusing content, the potential pitfalls, and a strategy for getting there safely. She showed us how to determine where content will be reused, how to structure for ease of reuse, how to map an information architecture, and explained why modular writing makes sense.

Part II reviews writing modular content, and continues with a how-to plan to define modules, create structure, create writers' guidelines, and to build a comprehensive reuse plan based on consistent, structured content.

Writing modular content (a review)

Modular writing allows you to more easily reuse content, whether you are working in a content management environment or not. Modular writing makes sense for several reasons:

  • Documents can be constructed from modules. For example, a summary or procedure module can be used in a number of different places, as specified in your information architecture. The entire document can also be a module that is part of a larger set.

  • The modular design makes it easier for users to navigate through content. Well-designed modules have clearly-defined purposes and substantive labels, helping users to find their way to the right content.

  • Modular units of content can be isolated and updated quickly and easily. Modules can be accessed apart from the document as a whole.

  • Modularity allows you to rearrange units as required to accommodate different users' needs or different publications' needs.

Modular writing requires defining what your modules are, describing how they are structured and how to write them. Modules must be consistent to support content reuse so that reuse is transparent to your users.

Defining modules

When you define modules, you specify what they are, what they contain, and how they are structured… All writers would need to follow this structure to ensure programs are structured consistently.

When you define modules, you specify what they are, what they contain, and how they are structured. The following example describes the components of a program researchers can apply for to get funding for their work. All writers would need to follow this structure to ensure programs are structured consistently. M indicates a component is mandatory; O indicates a component is optional.

Component

Usage

Title

M

Announcements

O

Headline

M

Summary

M

Highlights

M

Eligible applicants

M

Eligible costs

O

Ineligible costs

O

Application procedure

M

Deadline

M

Review process

M

Contact info

M

The above example describes the structure for one output (a program description for use on the web), but you can extend the information architecture to include other outputs by adding usage columns to indicate the other places components are used. The table below, for example, extends the use of these modules to a sales letter and to a brochure (blank spaces indicate that the particular module would not be reused for that application):

Component

Letter

Brochure

Web

Title

M

M

M

Announcements

O

 

O

Headline

 

M

M

Summary

M

M

M

Highlights

 

M

M

Eligible applicants

O

O

M

Eligible costs

 

 

O

Ineligible costs

 

 

O

Application procedure

 

 

M

Deadline

M

M

M

Review process

 

 

M

Contact info

M

M

M

By adding additional usage information, you're forming a reuse strategy. You're deciding in which other outputs (information products) you will reuse content. You can also extend the information architecture to include other program descriptions as well as other outputs. For example, the application procedure may be identical for several different programs, in which case, you would want to reuse it across programs. Once you know where you plan to reuse content, you can plan how to write it.

Describing modules

Describing the modules takes the information architecture one step further. The description not only tells you how to write a program as a whole, but also how to write the components contained within it. So, if the application procedure is going to be reused across different programs, it needs to be written so it will be reusable across the different programs. The following example includes the description of each component:

Component

Letter

Brochure

Web

Description

Title

M

M

M

This is the name of the program

Announcements

O

 

O

Includes updates about the program, such as the pending deadline, or a new deadline.

Headline

 

M

M

Describes the main feature/benefit of the program, in one phrase.

Summary

M

M

M

Describes the program briefly, in 5 to 10 sentences. Should cover what the program is, who it is for, and how much funding is available (if applicable).

Highlights

 

M

M

Highlights the main components of the program, in point form (about 5 to 7 bullets). Highlights may include the different types of awards, the different levels of funding.

Eligible applicants

O

O

M

Describes who is eligible to receive an award or who (if applicable) is eligible to submit an application.

Eligible costs

 

 

O

Describes any stipulations on how you can spend the funding.

Ineligible costs

 

 

O

States what funding cannot be used for.

Application procedure

 

 

M

Includes specific instructions, including downloading the form, filling it out, and where to send it.

Deadline

M

M

M

States the deadline. If the deadline has passed, state this.

Review process

 

 

M

Describes what happens after applications are submitted, how they are evaluated.

Contact info

M

M

M

Lists who to contact/where to go for further information.

Structure and usability

Unstructured content, or inconsistently structured content, causes problems for its users. Not only is unstructured content difficult for users to follow; it's difficult for writers to create because they tend to make decisions as they write.

Unstructured content, or inconsistently structured content, causes problems for its users. Not only is unstructured content difficult for users to follow; it's difficult for writers to create because they tend to make decisions as they write. For example, without the program structure above, some writers may include a deadline while others may not, making programs inconsistent. Inconsistencies compromise usability and could also compromise reuse.

If content is to be reusable, it must be structured and written the same so reuse is transparent to both writers and to users. Note that consistent structure is important even when you are not reusing content. Consistent structure provides a consistent way for users to navigate through content and eliminates guesswork for writers.

Writing to the structure

When you write to a structure, you find that the content practically writes itself. You base the structure on a thorough analysis of your content, its uses, and its users, so when you sit down to write, you already know what you need to include. Writing to a structure simply means that you have the "categories" already defined for you. Think of your structure as your outline.

But, writing structured, reusable content goes beyond following an outline. The outline is the beginning; you also need to create writing guidelines that tell writers specifically how to write to that structure. Regardless of what structure you are following (e.g., DITA), you still need writing guidelines so writers know how to write content consistently within that structure.

Creating writing guidelines

Once you've described the structure, you need to create writing guidelines to support that structure. You already started doing this in the descriptions of the components. However, depending on how consistent you need to make the content, you may need to take the descriptions a step further.

When you create writing guidelines, you provide further assistance to writers. Writing guidelines tell writers specifically how a piece of content should be written, and like the structure itself, are based on usability and on where you want to reuse content. For example, the structure for an application procedure might look something like this:

Component

Usage

Description

Application procedure

M

Includes specific instructions, including downloading the form, filling it out, and where to send it.

Deadline

M

States the deadline. If the deadline has passed, state this.

This may be sufficient, but you may need to take it further to ensure consistency and to help writers understand what to include. In this case, the structure for the application procedure could include specific writing guidelines, such as:

Component

Mandatory or Optional

Description

Application procedure

M

Includes specific instructions, including downloading the form, filling it out, and where to send it. Make sure you include the following sections:

·        Downloading the application

·        Filling out your application