Skip to content

What Makes a Good CMS?

April 30, 2014

We at Jazkarta have worked on CMS-powered websites for many years. We’ve built a lot of sites and worked with a lot of customers and we think we know what makes a good CMS for the kinds of projects we do – substantial websites with lots of members and lots of content. Our go-to CMS is Plone  – we’ve been working with it since 2003! – but we’ve also tried out Django CMS, Mezzanine, and have managed our share of WordPress blogs.

As part of our 3 day rural sprint, we decided to pool our experiences and write down our thoughts about what makes a good CMS. What features are valuable and what features can be skipped? Because Plone is so feature-rich and we know it so well, it made sense to frame our ideas in terms of those features.

Our group consisted of Nate Aune, Carlos de la Guardia, Alec Mitchell, Cris Ewing, David Glick, Chris Rossi, and Sally Kleinfeldt. First we brainstormed lists of features in the 3 categories below. Once we had the lists, each person got 12 red sticky dots to place on any item to indicate how important they thought that item was. We could place all 12 dots on one item, 1 dot each on 12 items, or any combination thereof. (If these red dots look familiar, you may remember this process was used extensively at the Plone Strategic Summit in 2008.)

Here are our lists, annotated with asterisks to represent the red dots. We hope this information will be useful to anyone writing a new CMS or extending an existing one.

David contemplates his next red dot placement

David contemplates his next red dot placement

What does Plone do well that our customers use?

  • User Management **
    • Pluggable authentication system, configurable
    • LDAP, SSO integration
    • Easier integration with social is desirable ***
  • Search **
    • Built-in is good
    • Configurable to different back-ends is vital
  • Plugins/Add-ons ***
  • Content Placement/Management **
    • Orderable *
    • Cut/Copy/Paste *
    • Versioning *
    • Staging
  • Workflow ****
    • Usually simple
    • Occasionally internal/external
    • Business process/government can be complex
  • Staging or Working Copies *
    • Especially useful for government or education customers
  • Granting of local (to a portion of the site) roles/permissions to groups/users ****
  • Roles/Permissions and Users/Groups
  • Content Types **
    • Pages *
    • Folders (default page problematic) *
    • Events (but should they be a core feature?)
    • Content Lead Images *
    • Collections **
    • WYSIWYG **
    • Files/Images (thumbnail generation, basic image editing) **
  • Views
    • A few default views *
    • Selectable views
  • Analytics integration
  • In-place editing/creation/management *****
    • Important for users with little training
    • Site admins could be comfortable with separate backend-style configuration/editing
    • Should be cleanly separated for ease of theming ***
    • Categorization/Redirection/Link integrity
  • Portlets
    • Inherited down the tree of content ***
    • Configurable
    • Would be nice to have it merge toward tiles
  • Navigation
    • Usually customized

What does Plone do well that our customers do not use?

  • Related items
  • Complex workflow
  • Internationalization (i18n)/Multi-lingual (because we work primarily in the U.S.)
  • Content Rules **
    • Underutilized
Well-defined API was the clear winner

Well-defined API was the clear winner

What does Plone not do well?

For this category we always have to install an add-on or fix something.

  • Tagging/Categorization especially management of tags
  • Default Pages
  • Previewing changes before save
  • Default folder/collection listings are unattractive and not easily configurable *
  • Form builder ***  (PloneFormGen is reasonable)
  • Faceted search/navigation
  • Videos/embedded media ***
  • Geo-location/Mapping
  • Page layout customization **
  • Mobile-first/Responsive **
  • Well-defined API ************
  • Hosting/Repeatable deployment *****
  • Theming and template overrides ****

What we need

At the end of this exercise, we totaled up all the red dots to see which features we had voted most important. If there were red dots on sub-items, they were rolled up to the parent item. Here’s the list – the number of red dots the item received is indicated in parentheses. We added a few essential things that didn’t get any votes but that a serious CMS can’t do without.

  • (12) Well-defined API
  • (11) Content Types
  • (8) In-place Editing
  • (5) Content Placement/Management
  • (5) Hosting
  • (5) Search
  • (5) User Management
  • (4) Theming/Template Overrides
  • (4) Workflow
  • (4) Local Roles/Permission
  • (3) Form Building
  • (3) Video/Embedding
  • (3) Inheritable Portlets
  • (3) Plugins
  • (2) Content Rules
  • (2) Mobile First/Responsive
  • (2) Page Layout Customization
  • (2) Views – Attractive Defaults
  • (1) Staging/Working Copies
  • Navigation
  • i18n
  • Tagging/Categorization

The clear winner in this exercise was “well-defined API”, which is not a big surprise given that a bunch of developers made the list! Although our customers never ask for this, it is essential for doing the type of highly customized websites that they demand.

  1. May 1, 2014 1:28 am

    Interesting analysis. I think it would help to further break down CMS features by the user role they address. What makes a CMS complex is that it is software trying please different “types” of people. The themer, the admin/site-policy person, the reviewer, the content editor, the viewer and the plugin developer. Almost all these features are aimed to help only one of those groups. If you split the features into lists based on these user groups you avoid the problem of developer bias as clear API is a feature for plugin developers alone.
    What is interesting is that if you look at things this way, the list of things Plone doesn’t do well is almost all “Editor” facing features.
    Would also be interesting to compare with the lists… but written very differently so hard to compare

  2. Sally Kleinfeldt permalink*
    May 1, 2014 8:55 pm

    Organizing feature lists by persona would be very useful, no question about it. We decided against this approach because we were after a more subjective, personal list – what we as a group want in a CMS to be able to do certain kinds of projects – the ones we enjoy the most! Indeed a very biased list, but covering our collective experiences doing discovery, training users, and managing projects, in addition to doing development.

Comments are closed.

%d bloggers like this: