or

Nocturne Note - Implementing process-based content management

A content management process

Content management is the process of controlling the creation, revision, versioning, distribution and inter-relationship of content. For the purposes of this discussion, we'll focus on documentation 'chunks.' Content management of an information set that is made up of a number of discrete information chunks may not require an expensive CMS implementation. Instead, you may be able to use a content management process. For small information spaces or document sets, Nocturne recommends instituting processes and providing templates and training to allow individual content owners to manage, author and publish their own content.

An important note about content management processes is the need for full involvement by everyone involved in the creation and maintenance of content. Content management starts on the authors' desktops and extends right to the implementation of navigation and access control on the portal.

This page outlines some of the steps and issues involved in the implementation of a process-based content management solution. Unlike purely tools or technology based content management systems (CMS), a process approach allows small groups to implement effective content management over medium-sized information sets without the massive expensive of customized CMS.

Understanding what you have

Parsing your content

In order to migrate to a new documentation solution in a cost-effective and manageable way, you need to map out, categorize and label your existing content. Every guide, every chapter, every section, and every paragraph should have a clear status and ownership. (Most 'chunks' of ownership will probably break out as chapters within documents, or high-level topics.)

Once ownership is established, you should cost-justify every piece of content. How much does it cost to maintain, and what is its value? Is it needed? Is it accurate? Is it dynamic? What are its dependencies?

This information is used in several ways:

• To identify who can sign off on (approve) content
• To identify appropriate content owners and authors
• To determine what content can be discarded, or does not need to be migrated into modular documentation
• To attach a dollar value to chunks of content that may require ongoing revision (letting a stakeholder decide whether to keep that content)
• To structure modular documentation so that larger modules are not being updated regularly due to small portions of dynamic content. (For example, regular updates to a small pricing table should not require the regular update and republishing of a 25-page chapter in a Sales Guide.)
• To ensure that all information dependencies are met. (For example, if the documentation includes a section describing the ABC process, it must also include a section that describes what the term ABC means.)

Unique identification of content and documents

The first key to content management is putting a system in place to uniquely identify each document and each chunk of content. Sometimes this takes the form of an ad-hoc tagging system, sometimes it involves a version management system such as SourceSafe, and sometimes a relational database.

Nocturne recommends a simple SQL or Access database, maintained by the documentation controller but accessible to individual authors. The database stores information about the document filename, title, contents, author and owner, and about revisions, changes, signoffs, dependencies, and inter-document relationships. It can also act as a repository for authors' notes and document-specific instructions.

Content and document ownership

As mentioned earlier, all chunks of content need to have clearly identified owners (who may or may not be the authors). Ownership has two aspects: subject matter expertise, and authorization of change.

All documents need to have clearly identified authors. A document author should be the only one able to update the document. A document may also have an owner designated to authorize any changes (for example, for a customer-facing service agreement).

Identifying new content

If there is significant content that is going to be added during the transition to the new documentation system, identify it and plan accordingly.

Modularizing your content into small, autonomous documents

Chopping up the content in the current information set is very important if you are going to distribute the authoring across a team. Multiple authors working in a single document space always creates chaos, regardless of the controls that are in place.

The solution is to create a small cloud of individual documents that are autonomous (able to be distributed and used on their own), but interlinked using hypertext. Individual documents may contain the contents of what is currently a chapter, a section, a procedure, or even a single table.

Each document must have an author who is responsible for its management and update. Ideally, the document author should be the person who owns the content of that document. In addition, each document has a defined audience and task environment (a definition of how, where and when it is used).

The overall documentation space can be represented as a matrix of individual documents, owners, audiences, and task environments.

Many if not most documents will have broadly defined audiences and task environments. Some documents will have specific audiences and, more importantly, customized content for specific audiences.

There are several ways of managing customized content. One is to maintain several branched versions of the same document, one for each customization. (For example, you may have a New Customer procedure for ACME Corp stored in one document, and a nearly identical but slightly customized New Customer procedure for WIDGET Ltd. stored in a second document.)

Another way of managing customized content is to tag content within the source document and include a step in the publishing process to temporarily delete undesired content.

The ideal, however, is to modularize the documentation so that customized content is contained in wholly separate documents.

In general, documents are broken down as little as possible, since larger chunks are more easily managed. The rules that determine when a document is broken down into smaller documents are simple. Break a document down into smaller modules ...

• If the document is going to be authored by more than one person
• If the document has audiences with markedly different needs, or if the document has audiences who are mutually exclusive (for example, a document that contains procedures for both ACME and for WIDGET)
• If usability is being affected because the document does not 'work well' in one of its task environments.

Gatekeepers

A 'gatekeeper' (a designated documentation controller) is responsible for auditing and reviewing the documentation space on a regular basis to ensure quality, for responding to user comments and change requests, and for maintaining any overall CMS infrastructure (such as adding or changing navigational links in portal pages). The documentation controller receives new or updated documents from authors and applies quality and consistency checks prior to making the documents available on the portal.

Delivering content in HTML format via a customer service portal

HTML is the natural choice for delivery of content to customers. PDF files, while useful for delivering printable material, are not as easy to navigate online due to their 'paper on glass' nature. HTML allows very flexible hyperlinking between documents, and even into other documentation or online help spaces. HTML can also be printed (ideally, by providing printer-friendly versions of pages).

User navigation

User navigation is a component of content management. Navigation is determined by the inter-document relationships (the hyperlinks), and by top-down links (for example, a navigation pane giving access to all ACME documentation).

Users logging into the portal should be able to jump to a navigation tree that will let them drill down to the information they need. The tree should allow access to all documents, regardless of size. In addition, users should be able to drill down or navigate between documents using hyperlinks.

Ideally, the user should be able to jump to any location in the document space using no more than seven clicks, starting with the jump to the documentation space from elsewhere in the portal.

Access control

Access control is a serious issue. Be sure to think about access control at all stages in your implementation process. Access control applies to all groups that touch the content, from owners to authors to end users.

In the portal environment, where content intended for different customers is stored together and confidentiality is an issue, access control becomes extremely important. The first tier of access control is provided by the portal front end: identification and authentication of a login.

The second tier is provided through content management. Specific directories can be locked to prevent access to users not belonging to a specific customer. All customer-specific documentation then goes into that directory.

While that prevents access to documentation across customers, another strategy must be used to guide navigation appropriately when users hit the navigation front end. Depending on how much customer-specific information the content will contain, and how it is structured, the best solution may be customer-specific navigation trees.

Another issue is navigation using hyperlinks from generic to customer-specific documents. There are a range of solutions available, beyond the scope of this outline.

Search function

An unstructured form of navigation is the Search option. Content management includes the search function in two ways:

• Preventing user access to unauthorized documents via Search
• Focusing searches based on meta-data (information that does not appear in a document, but flags the document so that it can be found during searches)

You can implement a search function on the portal server, allowing documentation users to search for keywords within the documentation space. Nocturne has been testing several open-source Perl/CGI-based search tools and is currently recommending jasearch.

Alternately, you can purchase and implement a proprietary search tool. There are now a wide range of search tools available from a number of vendors.

A final, less attractive alternative is index-based searching. You can implement this on the client-side with no server overheads or administration, but it will require a person to act as a documentation controller, updating keyword indexes whenever content is added or changed. You can implement index-based searching cheaply using a tool such as MSS (Matt Simple Search), or in a more elegant way using e-Help's RoboHTML.

Revision control

Revision control becomes more and more important as activity increases in the documentation and as the documentation space ages. The simplest form of revision control involves the documentation controller as a policeman to ensure that versioning is being used properly, a relational database to track version updates and content changes, change bars to mark delta content, and a library system to store older versions of document files.

Graphic libraries

Graphic libraries are stores of commonly used or recurring graphic elements (including icons, branding objects, screen captures, and callout shapes). Authors can imbed or link graphics into their source documents. If they choose to link, then the source file should be stored in the graphic library on an accessible network drive, and not on their local hard drive.

Certain graphic elements, such as branding objects, are the exception as they may be applied to only a subset of documents at any given time. Branding objects should be linked, but should be stored locally with the document files on the author's desktop.

Branding

Branding is the re-labelling of documentation to customize it for specific customers. Content management must include tagging to identify how documentation is labelled, and to control how the HTML output appears to be branded when it is presented to a user. Branding in the proposed documentation space will involve dynamic customer logos that appear somewhere on the document (for example, in the headers of printer-friendly versions and in the navigation frame of standard pages).

Standards and templates

Over time, the need may arise for customized templates for specific documentation types. The content management process must accommodate this, primarily by including a template tag in the relational database.

Access tracking

It may be possible to implement access tracking on the portal so that user hits on specific documents can be recorded. This is a server-side function beyond the scope of this discussion.

Portability

The content management process must accommodate situations where the author is not connected to the LAN when authoring or updating documentation.

User feedback channels and change requests

Change request management is a subset of content management. When users make comments, identify errors or request changes to content, that information must be managed so that ...

• It is recorded centrally for later reference
• It is communicated to the author and owner of the content
• The completion of any change is tracked
• The disposition of the request is communicated back to the originator

Summary

This outline is not intended to be a comprehensive overview of the topic of content management processes. For more information about content management, please contact us.