Web Content Management Done Better

Why Not "Done Right?"

In a previous post I only hinted at all the different "touch points" a Web content management (WCM) system such as SDL Tridion can have. And it was only for HTML tags! To balance out the seemingly bad news, I'd like to share the positives that come from a well-implemented system. I don't assume to have all the answers to managing content, but know there are some things that make it better.

A WCMS works better when:

1. You follow standards and best practices by separating code from design from layout while using good naming conventions, include comments, etc
• Developers and other technical people excel at spotting the differences between code so the framework or method doesn't matter so much as the consistency between elements
• It helps to follow the technical community, but to also borrow from other disciplines to find the best (good) practices for your given environment.   
2. You follow a life cycle (almost any method works, as long as you have a way to maintain changes and synchronize functional and code changes across environments--Joel's test definitely applies)
• Believe me, it's tempting to just make a quick fix on the production WCM system or WCMS and forget your other environments. If at all possible, don't!
• (Un)fortunately the 7 places an SDL Tridion setup can add markup are not always controlled by the same people. It's even worse when you multiply the 7 places by the four locations in a typical DTAP setup. "But the environments are exactly the same!" Are you sure?
3. You empower end users to own their content
• The project team and organization needs to set the right expectations and hold content owners responsible for their content.
• However, this works better when you provide training, support, and documentation like any other internal or external system*

*The WCMS lets you manage content with versioning, history, re-use, metadata, publishing, authorization, workflow, and a separation from presentation. However, it does not control all aspects of the content such as target audience, appropriate tone, your writing style guide, or describing how templates affect each field and how to choose appropriate options in components and for metadata.

The Pay-Off?

Like other "enterprise" systems, SDL Tridion requires training, an implementation, and support costs (don't assume "free" or open source solutions are cost-free). So why go through all the trouble?

• You only have to "migrate" for the occasional update, or when getting large sets of new content.
• New website? Update templates, change publication targets, and your new site is up in literally moments. The likely bottleneck will be how fast you can build the presentation server websites.
• With end users empowered to manage their own content, your development and business teams will spend less time managing the nitty gritty details of HTML markup and more time focusing on your website's functionality and delivering value to your customers.

The idea behind purchasing or building a content management system isn't to replace your development team, but to offer it easier ways to manage growing libraries of content.

In a World where creativity, content, and connections are driving changes across industries, a platform to help manage, re-use, and distribute your intellectual property can make the difference between leading or following in your market. If the management of that content is one of your core competencies, by all means create the solution internally; otherwise, at least consider what a third-party system could offer. Again, it's not about the best or even cheapest solution, but rather the right fit for your environment.

Speaking of which, I'll have to post next about why Tridion developers or consultants don't use Tridion to manage their own content.