It seems to me that, over time, we’re actually making website management harder, not easier. Sure, we can distribute content authoring to people with no technical skills, but in our efforts to ‘simplify content management’ we’re simultaneously setting code and content against each other for control of the site.
To see what I mean, let’s go back in time to when websites were new and exciting and built in CODE.
First there was code
Back in the day, if you were working on a website, you were working in code. Content, images, font styles, layout and functionality all sat, cheek by jowl, in the HTML.
We content people all worked in Dreamweaver, Front Page or some other WYSIWYG editors (that’s What You See Is What You Get for you young ones) that helped you see what the code was doing.
Developers worked in notepad, Vi, emacs or some other hard core application with mysterious shortcut keys that only propeller heads understood.
As a ‘content chick’ you had to know a bit of HTML, but not that much. A little css code didn’t go amiss either.
This was a really flexible way to manage a website, if a bit laborious. You could make any page do whatever you wanted. Ctrl H (yeah, yeah spot the PC user) would find and replace anything you asked it to and you could guarantee you got every instance.
Our friends the propeller heads got to use /spider to do their universal replaces.
Sure you had to create every page from scratch, so consistency was a bit of an unreachable dream, but copying and pasting existing pages was almost like having templates.
Sites were managed by server administrators or website managers – mysterious creatures with arcane skills.
Code and content lived in harmony, each contributing their bit to the site structure. Neither fighting the other for dominance.
Then came the CMS
In the late 90s we saw the birth of the content management system.
“Separation of code and content” had arrived and it brought with it templates and workflows with user IDs and RWD rights the “content manager” could bestow on worthy souls, according to their status.
Content people could do their content thing, developers could do their codey thing and neither had to talk to the other if they didn’t feel like it. Well, OK we had to talk to the developers to get our templates just right, but other than that… not much interaction.
Back then forms, calculators and dynamic data could be sucked into a page with variables or a placeholder.
Developers coded, testers tested and code moved through a variety of environments until it appeared, as if by magic, on the live site.
We content types published our pages as and when they were signed off and ready.
The CMS controlled the site structure, content and navigation and the developers managed the code.
The internet gods looked down on creation and saw that all was right with the web.
And now…
Now we seem to have taken a step too far.
Every year there’s a bigger and better CMS with more and more bells and whistles.
And every CMS brings us less separation of code and content, not more.
No more developers doing their thing in their environments and we content peeps doing ours, in ours.
Now we’re lumped into the same set of environments, content interwoven with code, and all of us having to release to the same timeline.
Now when you pick your site management tool you have a choice – good content management with handicapped development or a great development framework with really poor content capabilities.
CMS systems are not designed to be development platforms. They are designed to managed content.
Stating the obvious much?
Now days CMSs seem to just get in the developers’ way, making coding harder and releases clunky.
And developers are rebelling – coming up with code frameworks that can serve up the site themselves. Leaving the CMS to host content snippets that get pulled into the code as and when needed.
Eeeek!
See why I think content and code are fighting for dominance?!
How can we stop this madness?
Well, I really like the 90s solution. Content systems managing content, navigation, page structures and nice contenty stuff.
And developers managing code in the framework of their choice, moving it up through peer review, testing, PVT and stuff and then injecting it into the live site when it’s ready for the light of day.
I’d even be happy hosting snippets of content in the CMS to manage error messages and other ‘content’ needed by the code.
Can’t just go back to the days when content was content and developers weren’t nervous?
The Web Content Manger 