My own private Emocide

Now, I think that in a discussion with Mike I finally got the the root of the question what’s wrong about current CMS systems. On the one hand, you have the big players, such as Red Dot and even bigger ones. They charge an arm and a leg for licencing and claim to be just about doing everything. Now, as a developer they still suck. If you know what you want and how easily you can often times achieve just that, without having to squeeze your idea into the corset of such a system, it can be frustrating to be forced to work with such. On the other hand there are open source systems such as Joomla or Typo3. I think the verdict is out on Typo3, that the usability just sucks. Both systems have the problem that they still are rather limited when trying to implement very custom features and/or applications. But even the pricey systems have that problem. And why? Because they all claim that they are able to handle any problem and be this 100% alround tool.

Well, I disagree, as well as do at least 2 of my former co-CMS-developers, that this really isn’t what I need as a developer. Especially not in every day agency work. A CMS is what it’s name says: A Content Management System. And that’s that. It doesn’t need to be supporting all kinds of extras and especially not any front end display issues. It shouldn’t even dictate the technology that should be used for that.
I want a system, that clearly seperates the layers. I want to define the data structure and it should be able to generate some basic environment from those settings. A little like Rails’ scaffolding feature. Then it needs the most important part, a smart business logic layer. Support plugins, etc. Keep the features limited and make things like publishing schedules optional plugins. Build a Content Management System. Keep it open and clean, which requires a great concept and specification to begin with. This business logic layer allows the editor to fill his system with the information necessary, in a — very importantly — clean environment. In interfaces less is more. Don’t dump every option possible on that usually just half IT-savvy guy.

Finally, we don’t want to have to deal with front end programming here. I want an clean, well defined and smart interface to query retrieve my objects from- Then I want to be able to use any sort of technology to display the objects I just derived: Be it PHP, .NET, Java, ColdFusion, Flash, … hell, even Desktop or remote applications can be supported.
From what I have seen, there are some sort of “Database modelling” tools already out there — like Strg.at’s “spunQ” — and they work! But what I would like to have is something, that is more tailored to the needs of an editor, who just wants a clean and pretty much “self explanatory” interface. The second focus is on the developer: All they have left to do is

• set up the data structure
• retrieve the objects and build a front end on top of them
• write applications to weave in (optional)

That’s it!