In the late 1990s the CMS invaders deployed their systems at large corporations, as managing web pages using HTML editors wasn’t scalable and non-technical folks needed to publish. In many cases after the invader left, the company’s business teams and technical web teams were stuck cleaning, fixing, enhancing, for years to come.
Unplugging web publishing systems (and community platforms) ain’t easy.
Publishing from Word Docs, ouch.
I was a web manager at a very large corporations, as such, I was the business sponsor for the website, and therefore the tools that were used to publish the website. Often, in most cases, I inherited a legacy CMS system, one that I did not choose, the underpinning structure of the site revolved around it, documents, navigation, ability to edit pages, and look and feel.
This was one of the worst implementations of CMS systems I’d ever seen, the idea was for non-technical people to edit the webpages, so the system would have the ability to check out a ‘word doc template’ filled with macros, publishers could edit the word doc, check it back into the system and a new webpage would appear. fail.
The templates were so complicated as users had to be trained on how to use the word docs, understand the styles, and all the nuances associated with the code. The linking structure linked to a primary key for a document, which also caused confusion. That’s just the publishing process, it gets worse.
The Pains of Content and Structure Coupled
The site was unfortunately designed so the structure would for the most part, remain constant. The structure of the site, and the content were coupled together, and that’s a major problem. As the site would grow and more pages were added to the taxonomy, the system became more and more inflexible. The developers had a very complicated way of managing the pages, the changes took a few days to work as the underlying code had to be changed. The simplest of web changes that you would expected to see from a web CMS system required ongoing developer support –not content changes at the business level.
I’m not going to mention the name of the CMS vendor who provided this less than stellar tool, as I believe the deployment of the system was to blame from the in house technical group –all of which happened before I got there. Whew, I feel better, that’s been pent up inside of me for a few years now.
Thinking forward: Community Systems of today, to be legacy systems tomorrow
As we deploy community solutions that have social media features, are we thinking about in a few years how these legacy systems will be inflexible, don’t talk to our other systems, cobbled together application ware that we loosely couple with our other customer facing web systems?
I also know of many business groups that are deploying community software, often by ‘notifying’ IT that they are doing it, sometimes without thinking about the long term implications of these systems not being able to migrate, talk, or share data with other websites. In many cases, the business sponsor will move on to another role, job, or company, leaving the archaic community platform in the hands of the next web strategist.
Two questions for you:
1) I’d love to hear from you about your CMS horror stories, feel free to leave a comment below, go ahead, vent away.
2) Are you deploying a community platform for your web strategy at your company? What are you doing to plan for the long term 5+ years impacts of this system in regards to the rest of the enterprise web strategy?