dev/Blog

Here’s how to become a hero of these Internets, in one easy step: write a Better CMS.

Yes, really. Bear with me.

I can’t believe I’m so different from everyone else on the planet that there is no CMS made just for my needs. And yet there isn’t, which makes me think there’s a big, BIG niche to fill, because I cannot possibly be the only one. (One would hope!) Before I say why I think this would fly and why it would sell, here’s what the Better CMS would be like: modular. Modular on the level of text.

Most CMS-es are modular in the sense they let you pick and choose from available modules (the terms vary) that provide some functionality: a calendar, an ad banner, a photo gallery, a poll, etc. You can typically place these modules on sidebars, headers, footers etc., i.e. all around the core content of the site. But the content itself is not modular. And there’s the rub.

I may be wrong, but CMS-es seem to have grown out of blogs. In some cases (WordPress) the demarcation between a blog and a CMS has become quite fuzzy. And at the risk of being totally wrong again, many of the big names in CMS world today (Joomla) may have actually started out as blogs. (Except TextPattern, which claims to be a CMS even before it has become a proper blog.) In any case, almost every CMS I have tried seem to be a “blog plus” – start with a blog, then add stuff to it. If you read the support forums, one of the FAQs invariably is How do I create a static page? Ah, because static pages were usually added as an afterthought, and don’t necessarily fit in the overall scheme of things.(1)

If CMS-es are indeed bloggy by nature, this would explain why their “modularity” happens all around the content – the posts, the articles – but does not enter the content at all. It’s the “blog plus” mentality: you write the blog, and we’ll provide oodles of little gizmos you can put all around it.

That works if what you are publishing is conceptually a blog. It may be a serious and well-designed news site, but it’s still a blog by heart. (Apparently most of my favorites run on Drupal, and there are some great-looking ones based on WordPress.) Recognize them by the URLs like www.example.com/2009/9/23/why-things-suck-the-way-they-are. That’s a blog.

And while I’m sure there are orders of magnitude more bloggers that software authors on the planet, that’s still a huge population. And they need something completely different. Something you cannot quite do with a gizmo-encrusted blog. I’d say they need modularity of content.

If you are selling (or giving away) only one product, you worry little about consistency. Just use a nice theme to make sure all pages have the same background color. But the moment you have two products or more, consistency in layout and design becomes a concern. Each product is going to have roughly the same set of pages: one for description, one for feature list, one for screenshots, another for download links, for support options, and maybe for payment. You want all these pages to have the same look and the same structure.

Try to achieve that by typing, or pasting text in a WYSIWYG editor. Or even in a code editor. Not recommended, especially if your temper runs short. And certainly not recommended if you have other pressing priorities, like adding features to your software, fixing bugs, responding to support email or finding nicer-looking icons for the toolbar. (Or, God forbid, dealing with chargebacks.)

So a Better CMS should be based on templates, understood as forms to fill out with content. That way every page looks the same, and you can change the structure of all your “Download” pages just by editing a single template. That’s one level of modularity, but we’ve barely scratched the surface.

A lot of your product pages will contain the same content. Maybe you want to put a warning, This app requires Windows 13, on every page. Or a link to support, or a Buy one, get one free button. That’s text, or an image, plus some formatting. A block of content that you want to reuse on multiple pages – that is, in multiple templates.

A template, thus, should consist of blocks. Named pieces of text that you could arrange. This is nothing new – every site design allows for things like {header} {body} and {footer}. The problem with today’s CMS-es is that they don’t let you do that inside the {body}. Also, {header} and {footer} are not granular enough. These sections will consist of reusable blocks, too. So that’s another level of modularity.

There is one more level to cover: that of text itself. It’s easy to imagine what happens when you release a new version of your app: you have to update the documentation. All of it. Consistently. Change the version number in the app, in the readme file, in the help file, in the PAD file, in your DonationCoder thread, and everywhere on your website. It’s not all easily automated (there are partial solutions), but it should be completely automatic on the web-side at least.

Ideally, things like the version number and release date should be placed on every page for your product, so that they’re easy to find. In Joomla or WordPress, that pretty much means revisiting all those pages and changing the number and date in each article, making sure you don’t screw up the surrounding content. And what happens if you decide to change your copyright string, or the name of a product? Isn’t this one reason computers were invented in the first place?

What we need then is text substitution. The site is built from templates to ensure all pages look the same, but all pages do not have the same content. They differ: one page says “Download SuperFreeEditor 2.0“, another says “Download SuperFreeEditor Pro 3.5“. We have to have a dictionary, one for each product, that basically says “app-name=SuperFreeEditor“, “app-ver=2.0” for one product, and for another product a dictionary that says “app-name=SuperFreeEditor Pro“, “app-ver=3.5“. Then your template for the download page contains simply “Download {app-name} {app-version}“.

There would be a “product” manager, where you would add the information specific to each product. That information would then be used to fill out the templates and generate pages. And presto, a CMS based on the time-tested DRY principle. You only enter the app name once, in one place. Likewise the version number. And if you have a specific important note that you want to plaster on every page for that app you simply add {BIG-HONKING-WARNING} to a section of a template. It’s not complex or strange or anything. It should be the fundamental concept of a CMS, as long as you really want to manage content, rather than just manage the links on the page.

Oh, and let’s not forget links. Take Joomla. Every article lives in a database and has a unique ID. But if, in the editor, you want to put a link to another article on the same site, you can either manually look up the article’s URL, or use the awkward selector (where it’s always easy to pick the wrong article by mistake). And if you ever move pages around, all your existing links will be dead. If you are using “clean” URLs, and one day change the title of an article, all your existing links to the article will be dead. Or, and this is particularly amusing, if you have two articles named “Screenshots” on your site (for two different apps, right?), links in the menu will all point to only one of the two. Unless you manually fix it, giving each article a unique slug.

So there should be two ways of linking. One, by the database ID of an article. It will never change. The link can only go dead if you delete the page. But a better solution is to borrow from wikis and add some smarts. Say you are on the main description page, and want to link to a “Features” page. With all the information the CMS already has, it should be enough to type {link:Features}. Not even {link:SuperFreeEditor:Features}, no. Because the CMS already knows the current page is part of the “SuperFreeEditor” section of the site. And as long as you have a page with the internal name “Features” (this might be the name of the template on which the page is based), the CMS has enough information to construct the right link. OMG, it’s so simple! Where can I get it?

Nowhere. Nowhere I’ve looked, at least.(2)

Now, if you still want all the gizmos, knock yourself out. And there should certainly be a blog. And in the blog, I should still be able to say “Hey, I’ve just released a fantastic new version of {app-name}! {link:Download}Go get it!{/link}” See my point?

A nagging feeling is telling me all I’ve written above is trite. Captain Obvious stuff. The more puzzling to me is that this thing doesn’t seem to exist.

Now, why would this thing sell? Two reasons: because programmers already have their hands full doing all the stuff I mentioned above and more. And if they can spend thousands of dollars on the latest compilers and libraries, they will happily buy a $99 CMS if it saves them weeks and months of grief. A shareware vendor building their own website from scratch is like a shopkeeper doing their own masonry. Some do, but it’s not for everyone.

Reason number two, this could work for almost anyone distributing almost any kind of product, not just software. Just make sure the fields in the database are user-defined, not hard-coded to be “app-name” and “app-version” only. Sure, Amazon won’t buy it from you, but plenty of one-man, one-woman shops will. I will!

To be continued, I’m afraid.

(1) To put in a good word for Joomla, they got the static page part right.

(2) TextPattern has “forms”, which are a little like my “blocks”, but that’s far from enough.

(I posted an earlier version of this article at DonationCoder.)