Rachel and Rahel talk with Scott Abel

However well that has served you in the past, using this structure might be doing your group a disservice when you have a lot of content to manage. This holds true when you move to a content management system, where you have lots of content “chunks” or “objects” that get combined and recombined as an aggregate of topics for the output in a “book” format.

How context affects findability
There are lots of ways to think about your content, and to be sure that you’ll be able to store the content in an appropriate place, find it when you need it, and manage its lifecycle, you need to understand the requirements from a business, content, and technology point of view. When content gets stored in a traditional file structure, you run the risk that content gets forgotten because of its creation context.

Using the example above, let’s imagine a typical department scenario. Imagine your company has a product line of, say, office chairs. The traditional file structure would be:
Office Chairs
> Swivel Magic Chair > Assembly Instructions
> Swivel Magic Task Chair > Assembly Instructions
> Swivel Chair with Lumbar Support > Assembly Instructions
> Swivel Magic Executive Chair > Assembly Instructions

Let’s assume that a new writer is assigned the task of creating assembly instructions for the new type of chair (executive chair with armrests). The writer must look through all the versions of all the chair types to see if any assembly instructions for the armrests exist. If there are many sets of assembly instructions over a number of years, finding existing instructions could be hit or miss.

In a content management system, there is no need to store the content in such a linear way. The content chunks get stored in a way that can be mixed-and-matched, and changed with conditional text processing that gets applied at some point during the system. In the case of a product line such as chairs, where one could assume that lots of the content is common, a more efficient way of structuring the taxonomy could be to group the common elements in a way that requires writers to sort through a known number of content types. An alternative structure could be:

Office Chairs
> Swivel bases
> Swivel bases > Castor type A
> Swivel bases > Castor type B

> Chair frames
> Chair frames > Steel
> Chair frames > Wood

> Armrests

> Upholstery
> Upholstery > Leather
> Upholstery > Wool
> Upholstery > Microfiber

Under this model, any writer beginning to write assembly instructions would look under each Level 1 section, and would choose a topic from each appropriate area. Because any writer can see all the available topics, there is no guesswork about whether content exists elsewhere, and where. In a content management system, there are likely search options to locate content that isn’t categorized appropriately, but for a successful search, the writer has to determine what the search terms will be. If a previous writer used a slightly different term, or a now-defunct term that was in vogue during a certain marketing era within the company, the search may be unsuccessful, and a writer could spend valuable time rewriting content that already exists. On a one-off basis, this may not seem like a big deal, but in an environment with lots of content or many writers, the content repository can get “littered” pretty quickly with duplicate content. And as the collective memory fades, it will become unclear which version is the right version, the official version, or the signed-off version.

The example used here is obviously a simple one, and certainly will not apply to all situations. In cases where complex content relationships exist, you may need a formal taxonomy that allows terms to be referenced in specific ways, that allows content to appear to be filed under multiple categories, or that drives navigation. These strategies are best left to a taxonomist whose training lets them easily see content relationships that the untrained eye struggles to detect. What should not be hard to see, however, is that how you structure your content, right from the beginning, will affect your content “discoverability” for a long time forward, and is a decision that should be based on the business and content requirements within your organization.