Reinventing CMS

Question

I have been working with CMS systems since before there was a term for it, and even though there are thousands of different platforms out there - some of which are pretty decent - I just can't shake the feeling that we still haven't cracked the CMS problem.

Back in the mid-90s, there were dozens of search engines competing for users: Lycos, Altavista, HotBot, Yahoo!, Excite, and Webcrawler, to name a few. An arms race was going on between search engine designers and the early black hat SEO hackers, and although the search engines were losing, the users forgave them. The market for web search was saturated; the big players seemed 'untouchable' for a startup or garage project -- until Google came along and changed everything. Overnight, users realized that the whole field of web search had been saturated with suboptimal.

A radically different approach can sometimes change the face of an industry, even when there seems to be no room left for new players. The prerequisite is that the industry is saturated with suboptimal, the way web search was in the years before Pagerank.

Or the way personal social networking was before Facebook.

Or home computing before the Apple & the IBM PC.

My increasing gut feeling is that Content Management is such an industry, that the CMS market is saturated with suboptimal, and that we are on the brink of a new paradigm, or set of paradigms.

My question is this: does anyone else share the feeling that every CMS is suboptimal in some subtle, general sense? And if you do, what does your gut tell you about what's wrong with the modern CMS paradigm? Where do we go from here?

(and before you scream "Not Programming Related", please consider that CMS systems are built by programmers, expanded by programmers, and used by programmers. The question may seem vague to some, but it is directly related to architecture, APIs and platform design)

EDIT: 10 minutes and it was closed?? It seems SO is now censoring any slightly interesting question as 'subjective', while keeping totally pointless ones like favourite cartoon / joke / whatever. How is this not the type of question that belongs in a community of intelligent software developers?

EDIT 2/3: Now with zero colourful language.

Answer 1

I half agree with you, and love '...saturated with suck...' what brilliant alliteration. I think the issue is we're still getting to grips with what the Net is, as a media creation and delivery thing.

Blogs took off because user generated content is a great idea that the world loves, but it's an idea that will take decades to mature. If you think of the Net being 10(ish) years old (yes I know arpanet's much older) then we're at such an early stage we should be thankful that the tools we do have are as good as they are. If you remember what it was like before CMS you'll remember the pain of handcrafting.

At a general level, the tool is less important than the content, writing for the web is different from writing, and being able to write doesn't make you a writer.

Answer 2

With "Content" being such a vague term, what happens to CMS's is that they become feature bloated very quickly.

I have worked on both internal and external CMS systems and they start of very well but in the end are changed to fit the need of a certain client, which sparks the idea of feature Y and Z and X and etc etc.

Though a CMS with a lot of features is possible but that's exactly the issue here, where is the magic CMS that does it all but in a way that changes the whole idea we think about managing content.

Answer 3

I should probably pitch in here, as I have been thinking about this for a while. These are some of my (less than structured) thoughts on the issues with most CMSes today:

1. The major ones (Drupal, Joomla!, Typo3..) are trying to do everything for everyone, and sadly end up being a mediocre choice for almost everything

2. The specialized ones (Wordpress, MediaWiki, etc.) may do one thing really well, but by definition, they don't expand beyond their original purpose very well, and some don't lend themselves well to modification at all. Still, I feel this is the better way to go.

3. The notion of user generated plugins works well in theory, but in practice every major plugin-friendly CMS platform ends up with a library of a dozen or so excellent plugins (that every install uses), and hundreds upon hundreds of poorly coded, outdated, uncustomizable, or too specialized rating-or-tagcloud-or-gallery plugins

4. The poor separation of interfaces for the many different types of users - the core and plugin developers, the client/middleman developer, the client designer, the client executive, the client content editor, and the end user. Most large CMS systems manage to make some distinction, but usually miss a few of the roles entirely, or make the distinction so subtle that it doesn't make a real difference.

Answer 4

I can't help but think that your analogy (between search engines and CMS systems) doesn't quite hold up. A search engine has a specific, defined purpose, and a user who uses one is there to get something very specific done. Either the search engine delivers an appropriate result, or it does not. On the other hand, a CMS system is designed to help people build something (a web site, more or less). The ability to help build something can't be measured with the same metrics as the ability to help find something.

Having said that, I believe you have a point here. Using Mediawiki is great if you want to publish an encyclopedia, but it may not be the best choice for all other types of content. Many of the CMS systems are really frameworks, that help you get things done in one specific way and make it harder to do things a different way.

Being of the programmer mindset, I've become partial to ikiwiki because it manages your content using a real RCS on the back end (I use it with Git). From there, my wiki is just another set of pages that I can check out and work on anywhere, even offline (most CMSes don't even consider that), and merge back in to the published copy. The benefit is the content management uses exactly the same tools as I do to manage my source code.

Answer 5

Tim Berners Lee's original vision was for a "read-write" web, where the 'browser' was also used to edit pages. If you had the right authorization, you could edit a page from within the browser then just click the save button. I am sure being a programmer community many people will be sick of hearing about Tim Berners Lee's "visions" so I won't go on and on about it.

The part of HTTP designed to allow simple 'PUT'ting of files is almost completely unused. WebDAV sort of does something similar, but isn't usually used for editing a web page 'in-place'.

The simple idea of editing a web page in-place, with all editing controls provided by the browser, didn't really get realized.

Today's content management systems are template-based and database-driven. Because of this, you can't just download the page as HTML, edit it in an editor, and PUT it back to the server, because the site is not just a bunch of flat HTML files.

Therefore, with no standard 'content editing' control built into the browser which can easily be made to fit these requirements, the whole editing interface has to be re-implemented on every different web application. Each one re-invents the same wheel - it has an admin control panel somewhere, and a way of structuring the site, and an interface allowing you to edit pages. Many of them implement "rich text editors" based on the designmode/contenteditable ability of recent browsers, which is very useful, but all the user interface - buttons, a mechanism for 'save' or 'publish', etc still need to be provided by the application.

Interfaces like Wordpress and Blogger show that this model can be improved to be made more intuitive, but such improvements are only incremental. If you are talking about a revolutionary shift in content management systems, I think it has to involve changes in the model. I think we need to see more and more of the components of a CMS built into browsers.

In 25 years' time, will we still be relying on every site we use implementing its own editing interface out of whatever HTML form tools are available, or will browsers by then support a larger amount of the necessary higher level functionality for a content editing interface, allowing content management to be as globally consistent as the search button on the top right of the toolbar is now?

Answer 6

You all need to try Umbraco. Best CMS ever...

Answer 7

I think the analogy is quite good, especially regarding all CMS applications being 'suboptimal'. Here's my take:

• A Content Management System should do just that: manage content. It shouldn't provide a flaky, tag-soup spewing WYSIWYG text editor (for any medium, let alone one that is inherently not WYSIWYG). It shouldn't provide yet-another-templating-system written in its own invented 'language'. It shouldn't be about calendars, forums, or any other bells and whistles the creators threw in to raise the purchase price a dollar or two.

• The CMS products I've used of late have been insanely complicated. Not just for the developer tasked with structuring a site, but for those editing the content, too. The current product I'm forced to use has a very sharp learning curve, and (like many products designed to make things 'easier') hampers the experts too. When combined with the amount of training required, it turns out that the slice of people who actually benefit from using the CMS is really small. I could teach those people HTML far quicker than it takes to teach them how to use the CMS with its built-in 'WYSIWYG' editor.

• For some unfathomable reason, CMSes have a tendency to reinvent the wheel. This isn't just limited to text-editors: custom versioning is a particular cause of personal frustration.

Er, that's all for now; I may add further thoughts later. In short: KISS.

Answer 8

I don't have a ton of experience with CMS products, but the ones I have tried seemed to be jack-of-all-trades but master of none. If you tried to improve them, your hacks were lost with new versions. I'm not a big fan of plugins for the same reason - they might stop working in a later version. I think a truly good CMS should be open source but highly organized such that developers are working on the core product instead of addons for it. That said, the core product should be modular so that people can use only the parts they need. This introduces the problem of interoperability, which might require some intermediate layer where relationships are defined.

I find that it's easier to make content in a CMS than to find it back later. Everything revolves around search, but it seems like search can't find everything either. There needs to be some better method of organizing content. The larger the system gets, the more difficult this becomes. That makes me pessimistic that a holy grail CMS is even possible.