Finding the Best-Fit CMS for Your Project

firebus's picture

CMS are often categorized by the use-cases they cover, usually grouped by "complexity". So we see a lot of CMS taxonomies that bucket products into "Enterprise/Small Business" or "Simple/Medium/Complex".

Here's a typical taxonomy takes both complexity and the Product vs Platform axis into account.

Getting back into Drupal work after a long hiatus, I had an epiphany about how developers choose CMS (or maybe more generally, how makers choose tools).

You know that wonderful moment when you're trying to learn how to do something new with Drupal, and you learn that the feature in question has been implemented in a particulary beautiful way? With enough complexity to handle 99% of the edge cases and provide maximal extensibility? And that happens again and again, and that's why you end up falling in love and refusing to work with other tools?

Many other people have the opposite reaction, retreating in disgust because things are too complicated, and too much work is required just to do something simple that you could roll out in Wordpress with your eyes closed.

I'm trying very hard to avoid making a value judgement here. Simple is good too. Good complexity can also come from combining multiple simple systems, sometimes with more freedom than you can get from a single complex system.

But I wonder if we choose the tools that fit our brains more often than we choose the tools that fit our use cases. I wonder if the decision to make Drupal a relatively-complex, but elegantly crafted CMS is the reason why Drupal has a community of outstanding and thoughtful developers and not the other way around as is commonly supposed?


Complexity with strong usability

I don't necessarily think that having a complex system that reaches edge cases can't be simple. From my experiences it has been the usability of drupal that has steered folks to other CMSes.

What's missing is the default configuration, modules, wizards, etc. that make it easy for the user to get up and running quick. The more advanced users can tweak / code away to reach those edge cases.

As an example, take the organic groups module from D6. When you enabled it the user was often confused how to get groups working.

Now take a look at the Date + Calendar modules. A sub-module was included that basically was a wizard to create your Event content type, date CCK fields, and calendar views.

That same concept could be applied to groups to automatically create a group content type, etc. Advanced users may have a few more steps to set it up the way they'd like, but they'll have an understanding of how to do that anyway.

firebus's picture


Aha...I'm talking about complexity vs. simplicity of the code in Drupal core, not complexity vs. simplicity of the UI.

As a developer, working with a CMS that has beautiful code and architecture is compelling, even if there are aspects of the CMS (like the admin UI, or any other external flaw) that make Drupal a bad fit for some use-cases (like the ones you describe above).

I certainly agree that difficult admin UI has been a disadvantage of Drupal historically (I haven't played with D7 enough to know how much progress we've made in this release).

Powered by Drupal - Design by Artinet - Amazon Affiliate