Symphony.

Interesting article in today’s A List Apart on CMSs and content strategy. Thought it might spark some interesting discussion here.

It’s certainly an interesting piece - my gut feeling is that it’s link bait for the articles and blogs scattered throughout the page. It covers most of the salient points around large scale CMS design, but the tone of the article put me off - the buzz words were a bit rich (You’re the ‘Content Strategist’? ‘Deliverables’? Really?! How about a trip to Unsuck It before posting your next piece). It’s par for the course for large implementations of any kind to find this kind of corporate non-speak, but I’m surprised to see it on ALA.

That said, there are some very good points to take away from this if you’re implementing very large CMS sites:

• Always model your data based upon how it will be used. Most of us here have skills with a technical bent, so we’re used to coming up with crisp, pristine development answers to problems. Over-engineering the structure of the data your users need to enter is going to make their lives hell (and hence yours when you continually need to explain the awesome technical reasons that it’s difficult for them to update their site);
• Workflow is king. Seriously, if the process for editing, approving and then deploying changes is too onerous, people just won’t do it. One organisation I worked for had their workflow configured so that all changes to the structure of the site needed to be approved by an under-resourced central web team. This meant if you wanted to change the title of a page, or it’s menu label it had to be approved first - and this was on a site with 45,000 pages and in excess of 400 authors. Obviously authors just stopped changing things, which meant content stagnated;
• CMSes do all require customisation. I’ve worked with a very, very long list of WCMS, document and record management systems over the years, and the number of times I’ve seen a framework pitch itself as the answer to all of an organisation’s problems staggers me. And they never do it well (.*Nuke, I’m looking at you! And you, Oracle UCM). My experience has led me to the belief that you find small tools that do their jobs well, and work toward integrating them in sensible ways rather than trying to make one tool fit all of your organisational needs.

I could go on, but I think the intent of this article sits at a level a little above where Symphony fits in. Would I deploy Symphony at a large organisation? Yes, definitely - for discrete tasks. Would I do so on a site that has 50,000 content-filled (non-dynamic) pages and hundreds of authors… probably not. A site with tens of thousands of non-dynamic pages is (in my opinion) fundamentally broken anyway.

I’m interested in what everyone else thought of this - Nick & the Airlock crew, you guys have done some big sites over the years - anything in here you would highlight/agree/disagree with?

Finally I had time to read Kahn’s article tonight.

First of all:

Trying to fix an organization’s content problems by installing a content management system (CMS) is like trying to save a marriage by booking a holiday.

Best-quote-ever.

Most of the time we select a CMS by popularity, cultural affiliation, or corporate edict—that is, without properly considering the content we’re supposed to be publishing. This is crazy.

Maybe it is, but we should also consider the time spent learning to use a new CMS from scratch. Sometimes you just don’t have it.

It’s just a matter of how much hacking you’ll need to do to get to what works for your people.

I don’t agree. Perhaps the term “hacking” is not really expressive. Customization is a thing, hacking is a totally different one. Every CMS needs some sort of customization, but hacking implies spending time digging into the code and applying changes to it that solve your problems. If you need to hack a CMS then there’s something wrong with either you or the product you chose.

It happens sometimes that you need to get your hands on some PHP while using Symphony to build special datasources or events. Even in this case, however, I don’t consider this as “hacking”.

Shift the discussion about the CMS away from “features” and towards “task flow.”

It seems reasonable to me to stick to a CMS I already know how to use due to some sort of “cultural attachment to it”. Sure, sometimes this is a bad attitude, but again the first enemy is time. Do you have enough time to learn a new CMS? Do you have enough money to engage a team of experts that know how to use it?

Concerning the workflow of a CMS design process: I don’t get these diagrams. But it’s just me.

My first thought after looking at the content model example: “Entity Diagram!”

Web editors are users too […] If we apply task analysis to the whole system, we can derive sensible estimates of the editorial time required to complete each task.

Good points here. It’s something I run into every time I use Symphony and also something I’m forced to think of at an early stage of the design process, while creating fields and sections.

Can this tool handle our content model?

Yes, Symphony can. :)

How much customization will be required to implement this task flow?

As much as I need, as long as it’s not “hacking”.

Some final thoughts: I liked Symphony since the first time because it depends on your website’s IA. That is, without thinking of it you can’t start working on Symphony. This is exactly what I expected from a CMS and this is the reason why I can’t live without Symphony anymore.