By Deane Barker | January 20, 2006 | 2 Comments
Here’s an obvious point: all content is not created equal. When you implement content management, it becomes obvious pretty quickly that content comes in vastly different levels of structure.
Structured content is easy — anything that you can input into an Excel spreadsheet is nicely structured. A list of products, for instance, has a name, description, price, weight, etc. There are dozens of ways to store this: a custom relational database, XML, content management, etc.
A CMS or a database can provide value for structured content. That type of stuff needs to be controlled, it needs to be…well, structured. When you output it, it gets repetitive. If you have 763 class descriptions for your college and you suddenly decide the title needs to be in an H2, not an H1, then content management is your friend.
Programmers love content like this. It’s easy to think about — there are rows and there are fields and everything fits into nice little boxes. When you output it, there are nice little nuggets of information you drop in amongst your HTML. Life is good.
Unstructured content, on the other hand, sucks. These are the ubiquitous “pages” — just big ‘ol hunks of text. Maybe you break out a title or maybe you try to call it an “article,” but the bottom line is that you have a big blob of text with a bunch of embedded formatting.
I hate trying to content manage these things. Where’s the benefit? Sure, sure — workflow, versioning, blah, blah, blah. How many people use that stuff? Not many, which means that — in the end — you’re basically forcing your CMS to do what WYSIWYG editors do and forcing your users to use crappy tools to craft Web pages.
My point is that we need to admit that there’s still a place for static HTML files in content management. After being “enlightened” to content management, we tend to look down on static HTML and think it has no place. This just isn’t true.
Static HTML is never going to go away, and content management systems need to start accounting for this. No CMS will do everything, and it’s not hard to compartmentalize your Web site — have sections that are run from content management and sections that aren’t.
Your phone directory is run from a database. Your class catalog is run from a CMS. But the collection of artistic, presentation-heavy pages that your marketing department uses to try and woo prospective students — those are begging to be hand-crafted in HTML or a competent editor.
There are a few options here to reconcile static HTML pages with a CMS:
- If your CMS is “full stack,” meaning it intercepts all requests “owns” the entire Web site, you need to be able to “reclaim” certain URL namespaces to do traditional HTML development with them. Bonus points if your CMS can catalog those files so they can still be used in menus and such within the CMS.
Refer back to my post on “Middle Ground” between a CMS and static HTML. I believe you can have both — the client-side goodness of HTML editing, and the central control of a CMS — if you do it right.
- If that’s too low-tech for you, you should allow users to upload a HTML file to be used as the body of the “text page.” They can write, proof, review, print, and obssess about the page in an external editor, then upload it to be used as the body when it’s ready.
Images and external files become problems, but they’re nothing that can’t be surmounted. Have the users make the URL references absolute and store the images outside the CMS, or let them zip up all the files then unzip them on the server, put everything in structured locations, and change the references in the source.
- If the idea of actual files repulses you completely, at least let your users write page bodies in external, client-side blog editors like BlogJet or RocketPost.
It looks as though I may be embarking on a good-sized Dreamweaver / Contribute implementation in the next few weeks. I spent about an hour with Contribute tonight, and it’s gorgeous — everything that FrontPage isn’t, which I pointed out so emphatically last week.
There’s got to be a good way to let this work elegantly alongside (and with) a CMS. With any luck, I’m going to find out.
What This Links To
What Links Here
Thanks for the post. This is something we’ve been thinking about how to best handle as we build a niche CMS for churches, called Ekklesia Systems…I’ll forward this on.
About point #2 above: The eZpublish extension http://ez.no/community/contribs/import_export/ezmailimport is one that could help solve the problem. Everyone knows and loves (??) email and the email client. Why not use an email inbox as the source for content building that gets imported into the CMS?
Or another approach (if the CMS supports RSS import) could be the RSS builder http://sourceforge.net/projects/rss-builder/