What makes a good CMS

opensource-cms

Photo: http://blog.xtremeloaded.com/

I’m giving you a list. I guess it’s not extensive, I am not doing a research. I’m just writing down everything with which I had problems in various Content Management Systems. So, if you’re making your own, bear these points in mind. Although, my programming teacher used to say: why are you trying to reinvent the wheel?

Intuitive structure

Don’t try to make it too intuitive. It is much better to have a clear tree structure with sections and pages (like OCP), rather than an attempt to put edit buttons in-page. Drag and drop in this structure is very helpful, it saves several steps of copying or moving a page into another section.

Also, many CMS-s have a problem with second level menus: does a page need to be inside a section/folder in order to have a sub-level? Or are pages “chainable”? The solution I encountered most often were completely separated menus from the content. So, content is added in one part, then chosen from a drop-down list in the “menu creation section” in a different part of the CMS. The solution I liked most is:

  • pages, representing menu item if the option is thicked
  • sub-pages, can bi chained directly to first level pages

Good HTML editor

I can’t stress this enough. Look at it from the point of view of the person who will be updating the site. Every day. Or every hour. Or once in two weeks. Doesn’t make much difference. The point is: what he/she will mostly be using will be the HTML editor.

I am aware of the fact that no editor can deal well with Word’s formatting, and that additional cleaning will always be required. However, there are good and bad editors. There are editors that work in only some browsers, or in many, but have lots of bugs. There are also some that pretend that all you type is being accepted, but after saving the changes all your <br/>-s disappear. (Yes, WordPress, I am talking to you.)

What I, and everyone else on this planet who is at least a little bit into website administration, need is a good HTML editor.

This means:

  • no bugs with breaks or losing code/text after saving
  • equal behaviour in all browsers
  • simple table editing with predefined styles choice for cells with multi-select (quite buggy in all editors)
  • simple linking (WP did it well)
  • non-buggy list editing
  • easy to implement pictures, uploading, auto-cropping (custom cropping too), and their positioning (WP did it well, apart form one thing missing: possibility to position two pictures next to each other)
  • possibility to change to pure HTML (for things it can’t deal with)
  • possibly clear word formatting

And now, from the point of view of someone who actually works in the industry, and teaches clients how to update their own site: please, don’t allow them to choose fonts, sizes and colors! Only allow pre-defined styles.

It would be useful, although not crucial, to have the editor display the text in exactly the same way it will look on the site. Same style of h2, h3, same fonts and font sizes, same colors. It’s easy to get used to editors that don’t do this, but it would be extremely helpful if they did.

Administration levels

A good CMS must allow the administrator to do almost anything to the site. CSS alterations, changes in php files, deleting sections of the site, file rearranging and so on. Not everything should be drag and drop, and the distinction between different level of access to different CMS users should be clear. If someone is there to change the website copy, that’s exactly what he will be allowed to do. But if someone is logging in with the username “admin” (I know, it doesn’t have to be that), he should be allowed to delete or rewrite a crucial php file. Of course, he should be asked for confirmation several times, with the list of all the consequences of his actions, including being fired from his job and dumped by his wife.

So, yes, some might say that a CMS should manage only content and leave the files to be managed via FTP, but I think that having it all in one place makes things a lot easier.

Administrators’ activities should be logged, so that people know who to blame when something goes wrong. (If you take a closer look, you’ll see that the human mind will more often than not search for the ones responsible for a problem, rather than for the solution.)

Ease of customisation

This is where open source and proprietary differ. If you are developing a proprietary CMS, all additions to it will also will be developed and implemented by you. This means, making the plugin implementation easier is just for your own future use, and is your choice.

However, if you are building an open source CMS that will be freely available and many other expert programmers will join in the development, you have to bear in mind that “mortals” will want to use your CMS too.

WP didn’t become so big because everyone knows how to code; it became big because it gives laymen the option of using it, customising it, and making it into something that looks almost professional. This is mainly achieved by having the plugin search and installer inside the system, and every customisation is just a click away.

Also, related to this point: know when to stop.  The basic version of CMS should be developed just enough to make most users happy, but not too developed, so that for basic use customisation would be required.

Search Engine Optimisation

This should go without saying, really. Don’t make a site if you’re not going to optimise it (you’re just taking up precious web space from us others).

The initial (design and development related) optimisation should, of course, be done by the designer and developer. But if the site is regularly updated by non-techy users, they don’t need to know too much about SEO to be able to update their own site. They are maybe into literature, or painting, or bicycle renting. What the Content Management System needs to do is to optimise every new content that appears on the site.

For this purpose, having meta fields to fill in is necessary, and if left blank, they should be filled in automatically from the content supplied. The same goes for URLs. An algorithm to calculate keywords by assessing their in-page appearance would be nice, with the possibility to change the auto-offered words that it suggested.

Don’t forget the sitemap re-generation every time new content is added.

Language versions

Sometimes, the language versions of two sites differ in the number and content of pages, but in most cases the content is just translated. Very few CMSs deal with this problem in a satisfying way.

I would consider this to be a good solution:

  • Creating a new language version is done trough a separate button in “tools” control panel. You crate it by choosing a version to make a copy of. The visibility of the version is set up here, so that the version can be made visible only after the content is filled in.
  • Language versions are not displayed in the hierarchy tree of pages, but as links somewhere inside each page’s editor. A drop-down list or toggle button would work well.
  • Possibility to choose different titles, URLs, descriptions and such for different language versions, on that one “page” inside the CMS that holds all the info. Contents for different language versions is done within the HTML editor (thanks to the “toggle button” again).
  • In the “tools” control panel, where the “create new version” option is found, there should be a “check for empty pages” button, which would show all the pages that are left untranslated. This means, empty pages of a version are not displayed on the front end, but only the ones that contain translated content.

I accept the possibility that there might be problems in creating this solution, but I found that the representation of language versions in a tree makes bigger sites difficult to modify and manipulate (too many pages in the tree structure). Other solutions that I saw were even worse.

Other useful features that I came across

…or didn’t but would like to have done.

Shared content
I want the same content to appear on different pages. If I have changes to it, I want to change it only in one page, and the changes should reflect to all other versions too.

Simple forms creation
Maybe I want to add a field to my contact form. Do I really need to send a request to the developer and wait for him to have time? Or can there be a built-in solution that my CMS offers?

Scheduling
Don’t underestimate the usefulness of scheduling. Bear in mind that by “scheduling” I don’t mean only “my post will appear on date/time”, but also “my post will disappear on date/time”. It might seem like a trivial thing, but if you do more than one project at a time, you can relieve yourself from lots of planning and reminding.

Recycle bin
Oh, yes. Even if you hate that something deleted is not really deleted (I am from the “shift-delete” group of computer users), recycle bin can be a life saver.

Auto-save and status of changes
For forms, HTML editors and other content, auto-saved content shouldn’t be sent to the web instantly, but should still be found and published if needed. Also, statuses are welly well done in WP – public, pending and draft (with the preview possibility of the latter two) are enough to cover every situation.

Dynamic content
You should be able to add small predefined dynamic pieces of content to a page of your choice. Maybe, again, through “tools” you can choose a form, or a video, or articles list, and add it to a page from a given list. Managing  this content, however, is a more complex question and should be assessed from case to case. Maybe the best option is a “dynamic content” section of the CMS, where administration of these functions is defined and edited. Again, WordPress has a decent solution: pages are static, everything else is “post”.

————————————

Here’s a list. Use it. Make the best wheel in the world. I will be happy to test it and point out the faults. Although, the faults will be my own, if I have missed or omitted something important.

;)