Content classification and findability no image

Published on January 6th, 2009 | by Rahel Bailie


Taxonomy considerations in component content management

Organizing your files within a component content management sounds like a no-brainer, but it’s not that simple. The temptation is to recreate your existing file structure, with the high-level structure consisting of something like:
Level 1: Product Line
Level 1: Product Line > Level 2: Product Name
Level 1: Product Line > Level 2: Product Name> Level 3: Document Type

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.

Share this post:
These icons link to social bookmarking sites where readers can share and discover new web pages.

  • StumbleUpon
  • email
  • Facebook
  • LinkedIn
  • TwitThis

Tags: , ,

About the Author

Rahel Anne Bailie is a synthesizer of content strategy, requirements analysis, information architecture, and content management to increase the ROI of content. She has consulted for clients in a range of industries, and on several continents, whose aim is to better leverage their content as business assets. Founder of Intentional Design, she is now the Chief Knowledge Officer of London-based Scroll. She is a Fellow of the Society for Technical Communication, she has worked in the content business for over two decades. She is co-author of Content Strategy: Connecting the dots between business, brand, and benefits, and co-editor of The Language of Content Strategy, and is working on her third content strategy book,

3 Responses to Taxonomy considerations in component content management

  1. Rahel,

    Very good post. Just wondering if when the file structure begins to get quite complicated whether some sort of mapping of the structure might be of use.

  2. Rahel Bailie says:

    You are exactly right. That “mapping” is part of a taxonomy. In web projects, this is very common – for example, if you have a product that needs to appear in several categories (think of clothing, where a belt might show in Accessories, and Menswear, and other departments where a belt would be a natural purchase with, say, a suit). An organization might even use a taxonomy management tool to manage the relationships, if they get complex.

  3. Ivan Lee says:

    Odd this submit is totaly unrelated to what I was looking google for, however it was listed around the first web page. I guess your doing something proper if Google likes you enough to put you around the first page of a non related search.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Back to Top ↑