Content Management Systems – a Bad Idea?
CMS – Content Management Systems are meant to…manage content. So if we need a generally static content, which should be editable by non-technical persons, it is probably a good idea to use them. Probably.
I’ve had some experience with a number of CMS (Joomla, DotNetNuke for example), and read/tried some more. What do all of them claim to offer – faster development, easier reusing of repeated tasks (registration, news feeds, etc). But let’s review some of the claims, and compare the use of CMS to making a site from scratch:
- editing by non-technical persons made easy: Without a step-by-step guide a non-technical person would never make it through the complicated menus, buttons. And what most CMSs offer is some ugly javascript editor-enabled textarea, which generates bulky and incorrect (X)HTML. On the other hand, with a similar step-by-step guide, a non-technical person can easily use Dreamweaver to make his pages and link them to menu items.
- easily reusing repeated tasks: let’s call the pieces of reusable code “modules” (they are often called that way). They should integrate well with both the CMS, and with existing modules. In practicse this is never the case. If at all any integration between modules is to be achieved, a bunch of inconvenient configurations are to be done. And when at some point you find out that the existing module is not actually working as you want, it becomes a fight with the constraints of the cms. On the other hand, if you have already developed a number of sites, and have developed them well enough, you can reuse your own code (or even someone else’s independent code) knowing perfectly well what the outcomes will be.
- creating new functionality: as mentioned in the previous point, lot’s of constraint and cms-specific rules are to be observed. They cannot be forced programatically, so you will be lucky if you have a whole list of these constraints and dependencies. Otherwise you should guess each time something doesn’t work. And these constraints and dependencies are not few at all in big CMSs. On the other hand, writing a custom functionality as just plain code, with no configurations, implicit and explicit dependencies seems easier. Of course, it should integrate with the existing system, but this integration is done transparently.
In all the above point “learning curve” should’ve been included. It takes too much time to master a concrete CMS. And why, when, if you structure you work well, you can achieve even better speed and quality?
So let’s introduce the term “prepared scratch” – that is, all general stuff like db connections, main configurations, etc, is already prepared, and you start writing your custom dynamic/static pages from that point. Believe me it will turn out to be a lot easier, and will save neurons.
CMS – Content Management Systems are meant to…manage content. So if we need a generally static content, which should be editable by non-technical persons, it is probably a good idea to use them. Probably.
I’ve had some experience with a number of CMS (Joomla, DotNetNuke for example), and read/tried some more. What do all of them claim to offer – faster development, easier reusing of repeated tasks (registration, news feeds, etc). But let’s review some of the claims, and compare the use of CMS to making a site from scratch:
- editing by non-technical persons made easy: Without a step-by-step guide a non-technical person would never make it through the complicated menus, buttons. And what most CMSs offer is some ugly javascript editor-enabled textarea, which generates bulky and incorrect (X)HTML. On the other hand, with a similar step-by-step guide, a non-technical person can easily use Dreamweaver to make his pages and link them to menu items.
- easily reusing repeated tasks: let’s call the pieces of reusable code “modules” (they are often called that way). They should integrate well with both the CMS, and with existing modules. In practicse this is never the case. If at all any integration between modules is to be achieved, a bunch of inconvenient configurations are to be done. And when at some point you find out that the existing module is not actually working as you want, it becomes a fight with the constraints of the cms. On the other hand, if you have already developed a number of sites, and have developed them well enough, you can reuse your own code (or even someone else’s independent code) knowing perfectly well what the outcomes will be.
- creating new functionality: as mentioned in the previous point, lot’s of constraint and cms-specific rules are to be observed. They cannot be forced programatically, so you will be lucky if you have a whole list of these constraints and dependencies. Otherwise you should guess each time something doesn’t work. And these constraints and dependencies are not few at all in big CMSs. On the other hand, writing a custom functionality as just plain code, with no configurations, implicit and explicit dependencies seems easier. Of course, it should integrate with the existing system, but this integration is done transparently.
In all the above point “learning curve” should’ve been included. It takes too much time to master a concrete CMS. And why, when, if you structure you work well, you can achieve even better speed and quality?
So let’s introduce the term “prepared scratch” – that is, all general stuff like db connections, main configurations, etc, is already prepared, and you start writing your custom dynamic/static pages from that point. Believe me it will turn out to be a lot easier, and will save neurons.
CMS is complicated and overhyped area, but still you need to make a difference between “private-use” and “corporate-use” content management systems.
Claims that you are mentioning are valid for “private-use” CMSs where most of the things can be done manually. Systems like Joomla, Mambo, DootNuke etc. are quite simple and feature poor CMSs.
As soon as you step into corporate world websites (intranet, internet) you will see the true power of CMS s like FileNet, Oracle UCM, Vignette, Communique etc. Some of the features that they offer are workflows, scheduled posts, personalization, high-volume document management, integration with legacy content repositories and really easy to use WYSIWYG editors for non-technical pulishers.
You need army of people to do these things manually.
Nemanja
P.S. no, I don’t work for any of those vendors. 🙂
I think your using the wrong CMS, I found CMS Made Simple the user could work out how to use it easily.
So, why are you using wordpress for this website?
Andrej, for my needs, WordPress is ready-to-use software. I’m not customizing it – only write articles. I could do it manually, but then I wouldn’t have the fancy .wordpress.com
Nemanja – I guess you are right to make that clarification – I am talking about general-purpose CMSs, those of the kind I mentioned.
Of course it is better to have a ready issue tracker, calendar, etc, etc, instead of writing those. But these are big systems themselves, here’s why I wouldn’t label them “cms modules”
Good developers are used to have full control on the code and modeling onto a bunch of generated resources is not efficient as the CMS providers claim to reduce time-to-market. So these CMS systems might be useful for a small sized less complexity and less business logic web sites. The benefit would be for web designers, content providers or other CMS users with no HTML/Javascript/CSS and related background.
I found your blog by chance . but i have to say that it’s great blog very useful information and very interesting subjects just greetings and good luck
i’m not going i will be always checking for updates.I’m very interested in CMS and all its related subjects.
It’s a very interesting subject I was looking around about more information but you got really what i was looking for in your article so thanks and keep it up you have a great blog .
I’m very interested in CMS and all its related subjects.
Research loads on content management system at