Your CMS Isn’t Too Good for Static HTML
Content management system often deride static HTML. However, static files are necessary in some cases, and we discuss some patterns for integrating them into an otherwise content-managed site.
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…
The article discusses the role of content management systems (CMS) in managing different levels of content structure. It highlights that while structured content can be managed effectively by a CMS, static HTML, which is large, unstructured text, should still be handled by a CMS. The author suggests several solutions to reconcile static HTML with a CMS, including reclaiming certain URL namespaces for traditional HTML development, allowing users to upload HTML files for page bodies, or using external blog editors.
Generated by Azure AI on June 24, 2024Here’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 among your HTML. Life is good.
Unstructured content, on the other hand, sucks. These are the ubiquitous “pages” – just big 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 obsess 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.
No matter how much we sell our souls to content management, there’s still a place for “hand crafted” HTML. Trying to pretend that absolutely everything simply must be stuffed into the CMS is doing your users a disservice.
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.