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.

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):

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:

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:

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:

Content reuse alone doesn't ensure usability

If you reuse unusable content, the result is consistently unusable content!

Reused content is consistent simply because it is reused and this consistency enhances usability. However, reusing content doesn't necessarily make it usable. If you reuse unusable content, the result is consistently unusable content! It's critical that you base your structure and writing decisions on usability to ensure content reuse is effective.

Accommodating differences

Even though you are writing to a structure, you can still accommodate differences in content. Components can contain as much or as little information as required and can be broken down into subsections, as required. In your information architecture you can specify components as mandatory or optional to indicate where the sections and subsections are used.

For example, in the program structure, you can break down the application procedure depending on the complexity of the procedure, like this:

• Application process

  • Filling out your application

  • Submitting your application

  • Getting help with your application

  • What happens next?

To accommodate differences, you indicate in your reuse chart in which programs/uses each component is required.

You can also accommodate differences by tagging content (metadata) as you are authoring. You must know what the allowable differences are and have a metadata strategy to support them.

Summary - 7 Steps to Successful Reuse

• Effective reuse doesn't just happen. You need to plan for it. You need to create a reuse strategy that describes what content you plan to reuse, where, and how.

• Reusable content is modular so it can be accessed and changed easily. Modular content also helps users navigate through content.

• Modules must be consistent. Decide what constitutes a module and create reusable structures for all writers to follow. Determine which modules/components have reusable content.

• Reusable content is based on standards that all writers follow. Create structures for your content that all writers can follow. Support structures with writing guidelines.

• Reusable content must be usable content. Always consider usability and principles of clear communication. Base structures and writing guidelines on how the intended audience will use the information.

• Guidelines are useful only if everyone follows them. Ensure that all writers contributing content have a shared understanding of the writing guidelines.

• Reusable content and structures can still accommodate necessary differences. You can identify some components are mandatory or optional and you can tag content with metadata.

DCLnews Editorial
April 2008