For the past year or so I’ve been using Textpattern and I’ve got nothing but good things to say about this Content Management System. It’s come on leaps and bounds since I first started using it, and for blogs and small scale sites it’s ideal. Creating blogs is very simple, the templating system is intuitive and it can even be used for more powerful content management purposes.

So why am I ditching it in favour of something else? Read on.

New Challenges

Choosing a CMS is all about horses for courses. You really need to first of all understand the fundamental requirements of the website, its administrators and the CMS. Some questions to ask might be:

• Who will be updating the website? One person? An entire department?
• What is the technical level of the people using the CMS?
• How big is the website and how much of it needs to be updateable?
• What does the CMS have to do? Is it manage an entire website or is it just add news stories?
• What information are we dealing with, and how do the users interact with it?
• How often will the site be updated?

Only be answering these questions, and more, can you get a good idea for what CMS will suit you.

Most blogs run on a small set of popular “blogging engines”: Wordpress, Textpattern and Movable Type being some of the most common. Use of these CMS doesn’t just stop with blogs though, as they lend themselves easily to News Sections, Articles or Tutorials. For smaller sites, or those that only require updates to news stories or blog posts, blogging engines do an admiral job.

With varying degrees of difficulty, it’s also possible to bend these blogging engines to your will, in order to tackle entire site management and many designers do just this. This is where the problems start however. If you’ve done this yourself, you’ll be familar with the feeling that you’ve hacking a CMS into something it strictly isn’t. It gets the job done but it’s not always pretty.

While it might be possible to manage a large website with numerous sections and data types, with a blogging engine, doing so is neither simple nor advisable. But why do we do it?

The Comfort Zone

The energy and time needed to immerse yourself and understand the inner workings of any CMS is such that it breeds inertia. It took me a good few months, working with Textpattern over a number of projects, before I really began to feel comfortable, and started getting quicker with development.

After that, when a new project came along my instant reaction was to reach for Textpattern, because that’s what I knew best. This is fine in some instances but a content management system should fit the project and not the designer.

It’s a situation that leaves us in a bit of a pickle. Does it mean we take the time to learn a new CMS every few months or is there some other option?

The problems with data

It was after reading a great post by Jeff Croft on Personal Content Management , and the subsequent discussion, that I really got thinking about one of the issues with using blogging engines for content management.

Blogging CMS are designed to do one thing: create blog posts. They’re not there to create flexible and meaningful data structures. You write some content and it becomes an article, even if it was actually a course outline or a directory of staff contacts. It all gets flattened in the wash to become a blog post. Most blogging engines allow us to attach categories to our articles but this can’t accurate describe the many possible forms our data might take. Textpattern takes you a bit further and has the ability to create custom fields, but this is icing and definitely not cake.

While this might not seem like an issue most of the time, it does limit us in terms of what we can do with the information on our websites.

Imagine you’ve got the following company site:

• Home page
• News Page
• Multiple Staff pages (with contact info and photo)
• Contact Us

It would be relatively straightforward to create this site with Textpattern. The News section fits the blog model fairly well, and all the other “static” pages could be created as posts too, with every staff member having his or her own page.

This might be fine until we wanted to display a page with only staff members from a certain department, or list only the email addresses for all staff, or create a photo gallery of all staff. If it was created as a blog post there’s not a lot you can do with that data later on. It’s a big limitation.

Like I say, go read the Jeff Croft discussion , it sums it up better than I could here.

Size matters

More problems arise when the site grows. Once you start getting hundreds of “static” pages mixed in with blog posts, organisation and management becomes cumbersome in most blogging engines I’ve used. They’re specifically designed to chronologically display lists of articles, perfect for the blogging format but probably not what’s need when dealing with a list of staff pages or products for example. Again most blogging engines do allow some flexibility here, but it’s not their strong point.

I’m not criticizing Textpattern or Wordpress or any other CMS here. They’re brilliant at what they do. If you’re creating a blog or a news section for a website then by all means, use your favourite blogging engine, but if you’re shoe horning it into a situation where it doesn’t belong then stop for a moment and consider the alternatives.

Framework Vs CMS

Ultimately, it seems like we’ve got 2 choices: either find a CMS specifically catered for the needs of the website, or create one from scratch.

If you’re a developer, then it’s probably a no brainer. No out of the box CMS will afford you the flexibility and scalability as something you create specifically for a particular set of requirements. That’s great, if you’re a developer, but I’m not.

Frameworks like Ruby on Rails, CakePHP or Django allow for the rapid development of custom made content managed sites, but they require a level of technical knowledge that many designers, myself included, don’t have.

On the flipside, I don’t particularly want to have to learn a new CMS every time I start a new project. It takes me long enough to learn one, so to find a CMS specifically designed for a particular set of information management requirements and then learn how to use probably isn’t going to be practical.

There’s got to be some middle ground for us designers.

Enter the Content Management Framework

Luckily, it seems a new breed of CMS/Frameworks are emerging that are user friendly enough for designers to use while extensible and powerful enough to develop into some much more powerful.

Expression Engine seems to be getting a lot of good press but the one I’m currently experimenting with is MODx , which describes itself as:

“ a Content Management Framework (“CMF”): equal parts custom web app builder and Content Management System (“CMS”). “

Which is brilliant. Designers get all the out of the box CMS features needed to build comprehensive content managed sites, while developers have an environment to extend the functionality into a custom CMS.

At Net Resources we’ve built one site so far using MODx, and while it wasn’t entirely pain free, we immediately saw the benefits. As designer and project manager, I was able to get on with templating, organising and building a large fully content managed site, and our developers were able to use the framework to do the heavy duty stuff that wasn’t possible out of the box. Backend code is completely separate from front end templates, which meant developers create functions and designers implement them into the front end templates.

I see this as a huge plus, because too often backend programmers are forced into the world of front end design, because designers aren’t comfortable working with PHP or ASP. Problems then arise becomes developers are forced to make design decisions best left to designers. Separating the two means that both parties can concentrate on what they’re good at without intruding into the other’s domain.

Having said all that

In actual fact, I’m working on two projects side by side, one of them with Rails, and the other using ModX. It’ll be a really interesting comparison to see how quickly they can be developed and how easy it is for me to work within them. Perhaps it’ll turn out that using a fully fledged framewook like Rails will be the right choice after all. Maybe I’ll even end up doing some proper programming, but we’ll just have to wait and see.

I’m sure I’ll come back to this, with more thoughts, but in the meantime, I’ll be posting a review of MODx and what my impressions are so far.