Core CMS platforms

Everyone has a basic understanding of what a CMS is.  Here, we’re going to cover some of the core elements that make up the platform.

First, I think an important distinction needs to be made between the CMS provider, and the “core” that they use.  Generally speaking, CMS providers don’t build their CMS from the ground up, they use an existing foundation over-which to build on.  And this makes since; why spend resources on something that is already available?  Also, all of the major “core” platforms offer a multitude of widgets and ad-ons provided my the community.  The three most popular are WordPress, Drupal, and Joomla.  Each of these platforms come with some distinctive advantages and disadvantages, and many providers will use more than one depending on the specific needs of their client.  Let’s go over what each various platform offers:

WordPress: Wordpress is easily the most popular among bloggers.  While WordPress offers a more limited scope than some other CMS platforms, it can be the perfect fit if the goal of your site is to quickly publish blogs or periodicals.

Joomla: Joomla may rank last in popularity, but that doesn’t mean it has no place.  It offers slightly more advanced theming options, and is generally a good fit for young startups who want some room to experiment themselves with some light coding.  It’s fairly easy to switch out themes, and they offer a ton of pre-made themes available for purchase.  Going this rout may not give you the most unique or advanced site, but it still provides a good option to get creative on a smaller budget.

Drupal: Drupal is somewhat the gold-standard for most developers.  It’s the most bare-bones out of the box as far as theme and design goes, but it has numerous powerful features under the hood, and that’s even before you look into installing any additional modules.  What Drupal does best, however, is flex.  Developers can use its core to build just about anything they can imagine.  It’s complex, but also has options to give the end user (that would be you) easy to navigate menus to add your content after the site is built.  while you can purchase a pre-built theme, most prefer to have one custom made so that no other site has their exact design.  While Drupal is a CMS at its core, it can be used for so much more.

Having a good understanding of what each of the “core” CMS platforms offers can help you decide which provider might be right for you.  Especially if you’re working around a tight budget, you don’t want to spend money on features that you don’t need.  With that being said, this is probably one of the biggest pitfalls providers fall into.

Providers want to offer their clients the best available tools possible, and work hard on using their “core” CMS of choice to offer a unique out-of-the-box experience.  But this can be a precarious proposition.  With so many CMS providers out there, it can feel difficult to have your voice heard.  The easiest solution to this problem is feature-creep.  It can be appealing to say you offer the latest and greatest new widget, have the most complex out of the box design schemes, or have the most tools that come built into the standard package.  But when it comes to the planning phase, how necessary will all of those extra little perks be?  And worse, will those things get in the way of the simpler functionality your site really needs?  Unfortunately, I’ve seen it happen more times than I can count.

So why do providers do this?  Usually it’s because their marketing department demands them to.  Market research has become a dangerous science.  It has reduced content down to it’s most fundamental key-words, and insists that in order to be heard, everything has to be geared toward that.  And the worst part is, there’s some truth to it.  I’ve heard numerous clients ask for things like agile design without really knowing what it is.  When we explain that we don’t offer such-and-such feature, the phone hangs up before we can explain why we don’t recommend that in the first place.  There certainly are some basic features that should be expected as a part of the most basic of packages, but most bells and whistles should wait to be added until after a through consultation.

This might require a bit of a paradigm shift, for both developer and consumer, but trust me, building this way will make for a much better experience for everyone involved.

Comments

comments