Warning: Tech Content

CMS the Promise and the Peril.
That is the title of an essay I have been meaning to write for a long time. Back in '00 I was developing websites with a friend of mine and we found ourselves on the cutting edge of Content Management Systems development. At the time there were no good programs out there that would allow an admin with no code skills to update a web page. The premise is quite simple, extract programming from design, separate content from everything else. Thus, my pretty designs would not trip over a 1000 lines of code, the PHP wouldn't run into my markup, and the user could insert content independent of all the behind the curtain stuff.

What the user saw was a nice attractive interface, like the one I am typing in right now, just a box with some buttons that will affect minor markup changes, things like emboldening a line of text, or making something italicized, much like any word processor. When the user clicked save, what would publish on the public internet would be a page with the updated content. This is really quite a powerful capability. Think about a small business that has a staff of office workers, all perfectly capable of using MS Word or Word Perfect but not having a clue about HTML or FTP or servers. Instead of having to call the webmaster, wait for him/her to get around to making the changes, write said webmaster a check, they could login to a web interface and update the content themselves. This idea was a radical paradigm shift, and I was once in the fore front of making it happen.

Our CMS didn't get very far, we ran into the same road blocks everyone else did but we lacked the time, the finances and the will to keep pounding on the problems till we solved them. Over the years my team and I have produced three or four small systems and published them on live sites but by '02 there were many well developed and documented systems out there and most were, and remain, free.

I eventually decided that CMS was too powerful for the masses. My customers would call me to make changes, and I would login to the CMS console I built for them, and make the same changes they could have made without the need to send me money. I came to the conclusion that a good CMS would need to be brain dead simple in order for the average small business person to use it effectively. The problem was, the closer you got to the lowest common denominator, the less flexible the system becomes. There is probably a law of physics in that statement.

What I mean by that is this, I give Sally the receptionist the ability to login to a web interface and update the text on her home page. This works fine if all she can do is type some verbiage and maybe insert a photo in one small segment of the page. Maybe she wants to add a page, no problem, choose a template and build a new page. If one template is good enough, then once again we are not in trouble, but what if the home page template is not the same as the secondary pages? Now what happens when the navigation needs to be updated? do I give Sally the ability to add that too? So we make it dynamic, meaning we code some programming to allow the navigation to update automatically when a new page is created. What if the page does not warrant a place in the real estate set aside for it? So we create a way to choose if and when new content is placed in the navigation area. What happens when there are multiple navigation areas say across the top or beneath the header?

The complexity starts to boggle the mind, the possibilities are endless, and poor Sally now has to remember dozens of buttons and procedures to simply create a new page. We find ourselves in a position to limit what the user can do. Honestly, there is only so much power we can give to our receptionist, she doesn't know how the Wizard behind the curtain makes the pages, or the content change, all she knows is the boss wants the page updated by closing time.

Once we start limiting what the content editor can do, we also start to limit the flexibility of the program over all. The boss will want a calendar, or to change a color, or to add some nifty widget he saw on the competitions website and suddenly our CMS is diminished in it's practicality.

The promise of CMS was and to a certain extent still is, to allow the people that know the content actually publish the content without needing to know HTML. The peril is that less flexible websites will always fall behind in the market place. Where is the balance, the holy grail where the underlying API contains enough bells and whistles to make a CMS website both easy to use and able to meet the business logic needs of a company?

I could write for a very long time on this subject. I work with a large CMS at my job. It is starting to fulfill the purpose of it's intent in that we finally have department heads trained on the system well enough for them to do routine tasks each day. However; I am still called upon regularly to do something that the system just cant handle.

I think these systems get oversold. What company wouldn't jump at the chance to cut back or eliminate the Web staff, and let their current staff do the work instead. That is a basic business principle, get more work out of your staff for less money. It is similar to the siren song of MLM where the customers become your sales force etc. Why invest in trained sales people when you have given the customers the power to sell your product for you (AMWAY).

I have come to the conclusion that even with a good CMS there is still the need for a webmaster to do all the myriad tasks that the system was not designed to do. I guess that means I will have a job for awhile.