Main Area and Open Discussion > General Software Discussion

Idea: A content management system that lives up to the name

(1/10) > >>

tranglos:
Abstract:Available content management systems don't quite deserve the name, I think. They manage the styling of a site. They manage a database of articles. They can adorn a site with cool little widgets like menus, polls, galleries, banners, trackbacks, blogrolls, tabs, sliders and carts... that is, all the stuff that happens around the content, and in addition to it. They manage the layout, too - but again, only of those outer encrustations, not the layout of individual pieces of content. In fact, CMS-es seem to manage all aspects of a site *except* for the content. So what do you do when it is your content that needs some management?

I have changed the title of this post by Mouser's entirely reasonable request. So here's how to...

Write a Better CMS.

Yes, really. Bear with me.

While my previous post in the series is still looking for some love, here's one more installment.

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 seems to be a "blog plus" - start with a blog, then add stuff to it. If you read the support forums, invariably one of the FAQs 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 touch 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.site.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 even 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.

tranglos:
Seriously now, how hard would it be to write a skeleton implementation of this in php/mysql, or php with flat files? Maybe even it could piggyback on an existing CMS - after all, it only deals with what's inside of the articles, while CMS-es only deal with what outside of them.

What about a community project on DonationCoder?

I can always dream :)

superboyac:
Once again, tranglos, you touch upon a subject I have come across without actually bringing it up for discussion.  I went through this thing when I was first setting up my website here at DC.  i am not a programmer, so I wanted a way to do exactly what you have said above:  a pre-packaged template that i can tweak a little for my own needs.  From the start, I absolutely did NOT want the website to be a blog, and if you go through my thread, you will see how I struggled with that for quite a while:
https://www.donationcoder.com/forum/index.php?topic=14095.0

Eventually, I used wordpress and a special theme (the style is called "magazine-style" themes) so that it wouldn't look like a blog.  I didn't want a blog because the chronology of my content was of no concern to me.  So, eventually, I had to use a blog platform (wordpress) and do it in a way where even though it is technically a blog, it doesn't feel like one.  however, the problem of chronology still remains, there is no escaping it without a lot of tricks and workarounds, which inevitably break the wordpress backbone eventually.  So, in the end, I gave in somewhat to the chronological aspect, but tried to mask it as much as possible visually.

I completely agree with everything you said.  you're right, something like this does not exist, at least not when I tried to find it.  My situation is the same as yours, except instead of software, my content is made up of articles.

tranglos:
I completely agree with everything you said.  you're right, something like this does not exist, at least not when I tried to find it.  My situation is the same as yours, except instead of software, my content is made up of articles.
-superboyac (September 22, 2009, 06:52 PM)
--- End quote ---

I'm seriously hoping for some takers for the community project. (Wasn't there an idea like that floated around when Mouser posted the DC questionnaire?) I'd put all my heart into it, I would learn PHP to contribute (takers beware: newbie php-er), and I would certainly use it from day one.

I was happy enough with just plain old html, but now I've had it with updating little bits of data scattered around the site all the time. And with the copy/paste process when I want to add a new page. Forget about a redesign! I no longer have that kind of eager patience :)

CMS-es are great for adding new pages. Problems begin when you want the content of the pages to be structured in some way.

rgdot:
I may have misunderstood completely and if so it is my fault completely as well. But a lot of what I read here can be and is achieved by using smarty and is implemented by some CMSes, may be not as thoroughly as described but not too far off either.
For example reusing and controlling content is one of the strengths of smarty.

Navigation

[0] Message Index

[#] Next page