A number of participants at the recent STC Spectrum event here in Rochester were moving into XML-based content systems for the first time. I wrote to one of them recently on LinkedIn and described some of the common pitfalls I've run into in past projects. I thought it would be good to share this with a larger audience.

I finally managed to get Search Engine Friendly (SEF) URLs working on the site. I did some research and found one of the Joomla developers recommending OpenSEF, so I downloaded the component as a ZIP file and uploaded / installed using the Installers-->Components administrator UI. That was straightforward. I'd never been able to get the built-in SEF to work using the Global Configuration UI and discovered that my .htaccess file was empty. I poked around for awhile and finally found where to download the htacces.txt file (which I renamed to .htaccess to get it to function under Apache). This file needs to be in the root directory of my installation.

Someone asked me a fabulous question the other day. “Define change. Why is it so hard to change?” I responded, tongue-in-cheek, that “change is the only constant.” Upon reflection I think there needs to be some expansion of the question. As always, I am drawn back to Bateson’s learning model, which offers some clues.

I was doing some research on Link Management this morning and came across CMS Matrix , which lists no less than 761 CMS entries. And the list doesn’t include high end commercial offerings like IBM FileNet, Day Communique or Hummingbird RedDot. This means there’s a good chance that your neighbor Joe Nextdoor is cooking up a CMS in his garage for commercialization in the next few months.

In re-reading parts of the CMS Watch Report this morning, I was looking at the Pitfalls section. Care to guess what Pitfall #1 is? It has two parts. Part A is: no requirements. Part B is: requirements not tied to a business case or strategy. Go figure.

I saw yet another horrible requirements document a couple of days ago. Actually it was called a functional spec. From the perspective of the user, the spec talked about what they’d see on a web page in a site, how the controls would behave and where they’d be laid out in several page types. This is fine and you need this when developing a re-design or migration project, or both. The problem with this approach is it doesn’t dig deep enough.