And here’s the area everyone always wants to talk about when it comes to content management systems: the technology. There’s a lot, well no, a ton of solutions out there, and here at Blue Flavor we don’t believe there’s one CMS out there for every site, shoot we don’t even think there’s 10 or even 50 that’ll solve this problem. Instead we think content management should be a process.
As a design consultancy we design and develop sites and each one is unique to that clients needs. Trying to shoehorn a blogging service, or a enterprise level CMS for each and every site you build just isn’t the right approach. It’s why I mentioned at the start of this series that CMS‘s are often the holy grail of web software development. And the thing is, nobody is ever going to find that holy grail. Instead us in the industry need to look at the problem in a totally different manner.
We need to stop being so focused on which CMS is the best, or the “right” one and start focusing on what the problem is and the solutions that are right for each particular site. Whether it’s a personal blog, an e-commerce solution or a newspaper site each will need it’s own somewhat unique solution.
Nick Finck, our Directory of User Experience, just showed me the content management solution they use for Digital Web Magazine, and they’re not using Wordpress, or MovableType, or Expression Engine, no they’re using a custom made CMS written by Cal Henderson. Why didn’t they just customize an off the shelf product? None of the solutions out there worked for their particular set of needs, and they had a developer who could write one that did just what they needed. And guess what? They love it. It’s starting to show its age a bit now as Digital Web has grown but for the past 2 years it’s worked like a charm.
Now no, not every site needs a totally custom, written from the ground up CMS by the developer for Flickr, it just isn’t always in the budget or even a good idea if you can’t end up supporting the software. For blogs, Wordpress or Movable Type might be great, but once you start wanting to have more you just end up hacking it. Finding out first what your site needs and working from there is the right way to go. The needs of one site or company aren’t going to be the same needs of the other. I’d also recommend starting small. In my experience, it’s better to start small and grow into a CMS than get an over-engineered piece of software that’s unusable.
I’d go through the value, costs, and risk in more detail but the theme is basically the same: Don’t adhere to some piece of technology just because you think it’s the “bomb diggity” just choose what works for that site or situation.
I am in total agreement here. Clearly, content management is not a problem that has been solved and is probably not a “solvable” problem through technology. The sheer number of companies in this space and the number of implementation horror-stories is evidence enough that no one has gotten it right.
Consulting on process, however, could be an industry unto itself. Putting a content management workflow in place would be easy if there were only a few stakeholders. Unfortunately, the very idea of content management is intrinsically tied to multiple stakeholders. IT doesn’t want to have to deal with updates and marketing doesn’t want to have to deal with maintenance windows, etc. etc. Marketing wants a silver-bullet solution that doesn’t require them to think and IT wants a scalable, repeatable, blah blah blah. We’ve all been there, and quite frankly, nobody can do it all.
Navigating this water can be tricky, and I salute anyone with the patience to work through these issues.
Here at frog, there is a wizened veteran who has been through many CMS implementations and I asked him if he has ever seen a third-party CMS live up to expectations and deliver as promised, and his answer was an immediate and resounding, “No.” His only successful and easy experiences centered around home-grown systems that were catered to that company’s particular needs and fit into that company’s culture. That is, the software was developed to fit into the processes already in place.
Amen, keith. I agree 100% on every count. Well said.
Technology-wise, I think the most important thing is that whatever you go with be infinitely extensible. You need to be sure that when you start small (which I think is a great suggestion), you can grow and maintain a fully integrated system.
For a company like Blur Flavor that does client work, I think a great idea is to start building a suite of common apps that can be plugged into any site. This is more or less how World Online’s Ellington works (Ellington is based on Django, which does this “pluggable” app thing by default — I would assume most frameworks have similar concepts). We’ve got several apps — “news” handles stories and section, “media” handles photos, videos, and audio, there’s “blogs” and “podcasts” and so on — then for each site we build we simply figure out which apps it needs and plug them in. Often times a site will also have some custom developed apps, but having these pre-made pluggable apps lets us focus on the custom stuff and the UI for each site. Sometimes a particular sites needs modifications to one of the pre-made apps, but having built them still gets us 90% of the way there. It’s almost a framework on top of a framework — we’ve pre-made most of the common stuff that nearly every site needs so we can focus on what makes each site unique.
Of course, if you are just planning to manage on site, this sort of thing isn’t necessary.
I also agree completely that the only CMSes I’ve ever used that I was really happy with were ones that were either custom built for the site(s) they manage or very targeted towards a particular type of site (for example, the way Ellington is designed for news and entertainment sites or the way WordPress is designed for blogs).
Ack. Forgive me for assuming Keith wrote this, Tom. :)
Ahh, Jeff I take it as a compliment that you thought my writing was Keith’s. Just know I’m much sexier then he is in person.
I’m in agreement with you on some sort of pluggable type system, but I get a little leary on the abstraction of an abstracted framework (with whatever the technology is). At some point though you have to make choices and give up some flexibility. That and without really knowing what’s going on with the abstracted system, or without some developers on hand to make the 10% tweaks you mentioned, it can get pretty difficult for a small shop to make it all work together.
Then again, it’s 1000 times better then hacking away at blogging software…
I agree with Jeff that flexibility is key…our approach has always been to address as many needs as possible by creating a suite of apps that runs within our CMS (www.synopsis-cms.com) and leverages commonly used components like the user and groups manager and email broadcaster. Because we built it on a framework like fusebox, we can add new apps on the fly for specific needs, whether specifcally for the CMS as a new feature, or for a client. Sometimes it’s both.
We’ve been doing this for five years now, and while the CMS gets the occasional revision in the code base, it’s basically the same app we started with, only with many additional apps we’ve added to it along the way. And most of these were added quickly because we didn’t have to reinvent the wheel each time like you would with each app separated out individually. It’s also allowed to integrate other apps built on the same framework pretty seamlessly, so if we don’t have a specific app, like e-commerce (who wants to reinvent that wheel anyway), we integrate it and move on.
A side benefit to this approach is that when adding new apps you also don’t need to worry about what it’s going to look like or what the UI conventions will be, they’ve already been established by the core CMS, giving you a visual and UI framework as well.
Without this approach, there’s no way we could have added new features in as little time as we have. And for us, it’s been a great advantage from a business perspective. We’re feature-rich and fast — a tremendous boon to our bottom-line.
While no CMS can be everything to everyone, a pluggable architecture and framework gives the you the flexibility to adapt it to whatever need arises. And if you’re giving the client as much freedom as possible to maintain their site and leverage built-in functionality, it frees up developers to do the work they like, refining existing features or creating new ones, instead of making text-changes, as mentioned in Part 2 of this series. It’s a win-win for everyone.
I don’t disagree one bit with the notion that one size does not fit all when it comes to a CMS. Just a comment, though: Offering more than one or two CMS solutions is not the only response to this truth. My firm, for example, targets audiences with similar needs that make the most of the depth of our specific skillsets… to better leverage what we know about a limited range of technologies. It is just so difficult for a small team like ours (5 people) to know more than one or two systems incredibly well, and our business model doesn’t really accommodate a lot of custom development. Therefore, we target the prospect that has a need for what we know best. We miss out on a lot of work, for sure, but in the long run we gain from the goodwill generated by the success we are able to achieve with each project.
Great post, btw… and great blog!