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: