Cms Trench Warfare An Introduction

I have, in recent years, fallen into a weird niche in the tech industry. I don't think there is a widely-used title for my job. I have been working with large organizations to create or move web and intranet sites from static HTML pages to the company's chosen CMS. I have never worked with enterprise-level CMS software — my experience has been helping folks port content into custom-built or open source CMSs.

In this line of work my role is that of liaison between the IT department (or whoever manages the project) and end user. By default, my clients tend to be in clerical roles: the folks in the trenches. My job is to evangelize the product, explain the process, present, instruct, coach, and guide clients in web architecture basics and design best-practices, and in use of the chosen software. Sometimes, I am expected to sell the project to management as well. Frequently, I have to physically help with the initial data transfer. In fact, I believe it's essential to take a hands-on role in at least one site transition, in order to get a better idea of how the CMS is performing and what your clients are experiencing.

As a liaison, I also channel information from clients to whoever maintains the software. I document client wants and needs, software bugs, usability problems, and push for needed changes.

How do I love my CMS? Let me count the ways...

In my experience, CMSs are generally chosen by those who will be supporting the software (often the IT department), and the process and/or criteria used to make that choice, vary. Understandably, IT is often as concerned with their own needs as with their clients' (the true end-users). And to me, how the CMS was chosen matters not, since I've always come on board after the choice has been made, and it is my job to make the client love the chosen CMS. Or at least, to use it.

But CMS-wrangling is not a job for the timid, especially if IT has not quite managed to wrestle their software into submission and/or if you are facing mountains of badly organized and/or outdated content on someone's shared drive — times a few hundred. That you will be porting sites built in some ancient form of HomePage, FrontPage, or MS Word is pretty much a given.

CMS administrative interfaces are usually somewhat complex, often not particularly intuitive, frequently employ an esoteric vocabulary, and always entail some kind learning curve.

Carrot? Stick?

Motivation for clients comes in the form of carrots and sticks. Carrots work better than sticks, and use of carrots makes you heroic. Use of sticks makes you villainous.

Carrots can include providing usable software that works as advertised (and/or fixing bugs as quickly as possible), being freely available to clients when they need help, giving clients a choice in how to customize the look and feel of their sites, finding a way for them to keep their favorite JavaScript hoohas, and generally helping them create a site they can feel proud of. A little empathy can go a long way. As can some bagels at a morning meeting.

Sticks are simpler and generally consist of you have to do this because (insert powerful person here) says so. Less creative, and depending on the culture of your organization, frequently less effective.

Focus on the content.

As you work in the organization you will find that the technically-savvy may be fascinated with your nifty CMS technology, but hate the fact that they have less freedom to customize their sites. The technically averse will find all kinds of reasons why they cannot work with the CMS. The creative/art/design department will hate the front-end design; or, if they helped create the design, they will hate the implementation. The IT department will give you a byzantine list of workarounds for admin interface bugs. The opinionated will ask for a blog. Someone will want to use Flash. Everyone will want an embedded weather report. You will have to run reconnaissance missions between departments with long standing feuds. You'll be forced to use an HTML editor so frustrating, it makes you want to use Clippy to commit seppuku. And in the face of it all, your open source people, washed in the blood and bathed in the kool-aid, repeat in unison that their product is powerful, standards-compliant, and user-friendly, as they march forward like brain-devouring zombie army incapable of comprehending any of the real-world problems you are experiencing. And you? You will be repeating this mantra:

Just focus on the content. Just focus on the content.

And that's the truth to hold on to, the light at the end of the tunnel. Your open-source CMS product will only get better — maybe much better — assuming your IT department keeps the software up-to-date. We can debug, we can fix looks and feels, we can add or remove functionality. It can only get better... right?

So, should you also find yourself in the CMS trenches, blinded by sweat, grime, and your own blood... focus on the content.