CIDM Information Management News February 2012: Learning to Manage Your Content

Learning to Manage Your Content

Mark Lewis, Quark Inc.

Managing content is like riding a bike. It's really hard…at first.
Both managing content and learning to ride a bike are complex. Nobody does a better job of breaking down the complexity of learning to ride a bike than the autistic boy Lou in the book "The Speed of Dark."

Lou rejects the traditional approach offered by his parents and instead breaks the problem into its components:

Learning to steer
Learning to pedal
Learning to balance

To Lou's autistic mind it is clear that the first skill that you need to learn is steering. So, he walks beside his bicycle pushing it around the yard turning and straightening until he gets the feel for steering the bike. Lou succeeds. He then adds pedaling and balancing and soon rides.

Now it's time for my son Logan to learn. Ironically, a friend told me that they had removed the pedals from their child's bike to eliminate the complexity of pedaling from the equation. Hmmm. Problem: learning three new skills at the same time. Answer: Break the problem down into its components. Learn one new skill at a time.

First I remove the pedals and I place Logan near the bottom of a hill. All he has to do is lift his feet and roll to the bottom of the hill. He does it. Then he starts further up the hill for more power, adding pedals but only using them as footrests. He learns to balance. As he masters one component, I add another. We add silly turning games. He learns to steer. Logan, pedal. He pedals away and out of sight. My vision blurs ... a little.

Break Down Content Management into Components

Managing your content is a huge task. You can break it down into components like you do to learn riding a bike. The first concept to learn in content management is the content lifecycle. Content lifecycle tasks are broken down into the following categories: requirements, design, implementation, test, and maintenance.

Know Your Requirements

It's common at a conference or workshop to have someone say "Can you recommend a CMS?", or "Should I use schema X?"

The answer is it depends. It depends on your content requirements and your process. How do you know what to buy until you've determined what you need? And when I ask if they've documented their current processes and performed a content audit and the answer is no, then they start to get overwhelmed, but they don't have to.

This is all part of the requirements task. This big task can be broken down into much smaller tasks. In fact, breaking down the requirements tasks is called a "work breakdown structure" (WBS).

Now you have smaller components that are quite manageable and do-able. The following Gant chart shows these component tasks in a timeline.

It's a proven methodology. For software engineers, the lifecycle is similar: requirements, design, implementation, test, and maintenance. Why? Because engineers need to know what is needed (the requirements) and need an architecture that supports those needs (the design) before they can write code (the implementation). Otherwise, it's hacking. And we all know the results of hacking, garbage software. Have you ever read garbage documentation? I suspect that you have. We've all seen far too many new CMS, new tools projects fail because the requirements gathering and content design steps are skipped.

For more information on requirements, see "Doing Requirements Gathering" and "the wheel of content management" in Bob Boiko's book the Content Management Bible http://www.amazon.com/Content-Management-Bible-second-Text/dp/B004UPNOJ0/ref=sr_1_6?ie=UTF8&qid=1325906488&sr=8-6.

Perform a Content Audit

Part of the requirements task is performing a content audit—identifying the content you have and the information products you have that contain that content. The Work Breakdown Structure (WBS) shown above contains two content audit tasks: top-level analysis and an in-depth analysis. They sound big and scary. But aren't.

Here's part of a top-level analysis I did for an accounting system. Even without understanding the details of my content, the analysis is easy to understand. I have content about accounting features that is being repurposed in a collection of information products. This is straightforward. You can do this for your own content.

The design task of the WBS is not so scary either. Let's take a look at one of its sub-tasks, information modeling.

You've been working with information models (and structured authoring) for a long time, but you probably didn't realize it. Take a resume for example. The information model for a resume is designed to satisfy a set of content requirements. A person wants a job. An employer wants information about a potential employee to help decide if that person is a good candidate for the job. A typical resume contains the following components:

Contact Information
Objective
Skills
Experience
Education
References

Let's look at another information model that you're probably familiar with, the model for a business letter:

Letterhead or sender's address
Date
Recipient's address
Subject
Salutation or Greeting
Message (body of the letter)
Closing
Signature

For my accounting project, I created an information model for content about the various features and entities in the system. The model is simple:

Title
Navigation Path
Definition
Usage
Special Considerations
Image
Example
Prerequisites
Description (Marketing)

If you have completed the requirements task and your content requirements are clear and accurate, the design task becomes much easier. You can see from these examples that information models are nothing to be afraid of.

Create a Reuse Map

With an information model in place, the next step is to create a reuse map. Creating a reuse map is one of the first steps toward designing a reuse strategy. The following reuse map shows my information model and how the content components are reused in my information products.

Again, you can do this for your own content. Use your model to determine if you can use a standard schema such as DocBook or DITA. If you can easily map the elements in your semantic model to the elements or customize the standard schema, then use the standard. If not, then you may need to roll your own schema. For more information on information modeling, see Bob Glushko's discussions on "harvest tables" in his book "Document Engineering" with Tim McGrath http://www.amazon.com/Document-Engineering-Analyzing-Designing-Informatics/dp/B005Q8COGE/ref=sr_1_1?ie=UTF8&qid=1326027305&sr=8-1.

In conclusion, by breaking down the tasks of managing content using a proven methodology like the one outlined above, you make it easier. By using due diligence to gather requirements, you'll be able to design your information model and a reuse strategy. You'll succeed and be in a better position to tackle your next content project. You'll find it becomes easier and automatic, like riding a bike.

About the Author
Mark Lewis is the DITA Product Manager for Usability and a product evangelist for Quark. He is a contributing author of DITA 101 Second Edition and has authored several white papers on DITA Metrics that prove the savings and high content reuse percentages possible with DITA's structured, topic-based architecture.

Return to main newsletter page