Content management?

Subject: Content management?
From: "Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Wed, 3 Jul 2002 09:03:53 -0400

Mubeena Mutabanna reports: <<I've joined a company as an intern and will be
working for about two months... Besides preparing documentation, the company
is interested in having a model devised for content management so that any
person looking for information in the future has access to information
easily and readily.>>

This part of your query seems to contain information that several
respondents missed in their response. First, you only have two months, and
much of that time will be taken up writing marketing materials and other
documentation. Second, the company wants you to develop a _model_ for
information management rather than actually implementing the system. As
others have noted, 2 months is far too little time to research a solution
and begin implementing it, even if that's your only task during the

An ideal solution would involve dedicated software specifically designed for
this task, and several of these systems have already been mentioned by
others; at some point, if your employer's needs grow large enough, migrating
to such a system could prove very cost-effective. I'd also propose adding
software such as Extensis Portfolio or Canto Cumulus for cataloging images
and creating browsable image databases; this software works wonderfully well
if you understand how to take advantage of it. But it seems to me that what
you really need as a starting point is a simple system for identifying
categories of content and making it easy for users to find information in
those categories. A good way to start developing such a model might be as

1. Itemize all the types of content that exist: For example, you might make
a complete features list for the software and indicate where information on
each feature is found. Simplistically, you might have the following places
where such information is found: the design specifications, any
documentation built into the code (i.e., comments), the print documentation,
the online help, and marketing material. That's a good starting point, but
don't forget to talk to those who want you to develop the system and those
who will use it to make sure you haven't missed any categories (e.g., the
bug reports database, tech support database, etc.).

2. Figure out how to provide access to that information. One obvious way
would be to create an intranet, with each piece of information available as
a separate file. In parallel with this, you could create an index to the
intranet that lists all the keywords that point to each file. (Add a search
tool and you increase the power of this approach.) A typical index section
based on what I listed in the previous point might be:
"Save as" menu choice
Comments in code
Design specs
Marketing material
Online help
Print docs
Instead of page numbers, you'd include file names or locations or even

3. Figure out how to implement such an approach. It seems on the surface
that you could simply break up the existing information into chunks that
match these index entries, and indeed, that's an initial step towards
single-sourcing. But managing such a collection of information is tricky,
and it'd be a real pain to have to reassemble documents manually from
hundreds of scattered pieces. This is where single-sourcing solutions start
to make a lot of sense: you maintain each chunk of information in only one
place, and when it comes time to assemble any product (e.g., online help),
simply import that chunk in the right place. Check our archives for
discussions of single-sourcing.

4. Don't forget the human aspect (see below).

<<To start with, I might use Access or Excel to prepare a table with
columns: path, filename, date content created, revision date, version,
content owner, images used etc. Is this a right approach to begin with?>>

This is a simple and efficient way to organize the information if you're
already proficient with the software. I'd avoid Excel (a glorified
calculator) because it's not really a database, despite simplistic data
management features. Access or any other database would be a more powerful
tool, but developing an efficient relational database requires knowledge of
database design, not just learning to use the software.

<<how should I approach content management?>>

Carefully. Most people forget that even if you come up with the perfect
software system, you still have to persuade people to use it consistently;
dedicated content management systems make it difficult to avoid using the
system, thereby minimizing the risk of users getting lazy and ceasing to
follow the system. Before you get too busy following all the advice you'll
receive (including mine), perform a very careful needs analysis; you can't
build a model until you know what it is you're trying to model.

Who will use this system? What information will they need to retrieve? How
would they prefer to retrieve it? If you can produce something people want
to use (i.e., it's easy to use and makes their lives easier), they'll use
it. Produce a model that is complex and that nobody wants to use or keep up
to date, and you're asking for trouble; people will agressively seek ways to
circumvent the system, and over time, it'll collapse under its own weight.

<<Are there any formal methodologies in use for content management?>>

Certainly. Librarians and archivists spend years learning them and end up
with postgraduate degrees in the subject. <g> While I'm confident in the
advice I've provided, I'd also note that I'm not an expert, and that talking
to a few experts at your local public or university library could reveal
valuable tips that I can't even begin to imagine. Take your librarian to
lunch and ask their advice!

--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada
"User's advocate" online monthly at
Hofstadter's Law--"The time and effort required to complete a project are
always more than you expect, even when you take into account Hofstadter's

Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.
Save $600: Create great-looking Help files and software demos with
RoboHelp Deluxe. Get RoboHelp and RoboDemo - our new demo software - for one
low price. OR Save $100 on RoboHelp Office in June with our mail-in rebate.
Go to
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit for more resources and info.

Previous by Author: An editor's role... to punish the writer?
Next by Author: FTP as a verb?
Previous by Thread: Re: ISO Doc Management
Next by Thread: FTP as a verb?

What this post helpful? Share it with friends and colleagues:

Sponsored Ads