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: