Editors Live in the Holes

Too many times in the past I’ve been guilty of getting too wrapped up in templates. These are the magic things in content management that let you “drop” content into various “holes” on a page. It’s a wonderful concept – “dropping content into holes” even sounds fun – but sometimes we take it too far. You see, what happens in the hole is really important too.

Too many times, we disregard the hole. We know there’s a hole where we “Enter Content Here” (i.e. – the header graphic on Seth’s blog), but as developers, we’re not really too concerned with it. Designers can even be guilty of it too. “What’s this big white area on the design here?” “Oh, that’s where all the content goes.”

When you get too wrapped up in your template, you lose site of the fact that the CMS editor “lives in the hole.” That magic, neatly-defined hole in the middle of the template where they drop their stuff? That’s 90% of what matters for them, and they care very much about what it looks like.

But, no problem, you say, we have CSS rules that make it all pretty! Well, there’s more to it than that, which is where you have to leave your anti-septic little server-side world and think like a user:

• Have you considered typography at all?

• Is their WYSIWYG editor configured?

• Have you shut off all the buttons they’re not going to need?

• Do you have the styles they need? Is there a dropdown box or something full of styles? Do they know where each style goes?

• Can they insert and style images well?

• They’re going to want to caption a photo at some point. How can they do that?

• Does the WYSIWYG editor accurately reflect the styles of the site while the editor is creating content?

• Do they have a style guide? Do they know what headings they should be using?

These things are important because the editor takes a very micro view of their experience. They are concerned with this piece of content right now. Developers, on the other hand, take a very macro view – we look at the entire landscape of the project and the content domain. We can’t be bothered with this little, single piece of content you’re struggling with.

(In fact, let’s be honest – how many times have you turned a CMS over to the client without having actually created much of any content with it? Sure, you stubbed out a few pages, but not enough to even get past the Empty House Syndrome.)

This is, of course, the exact wrong view of it, and here’s why: an editor’s first experience with a CMS will have a huge impact on their overall feeling about the CMS in general. If they can’t make a nice page of content easily right out of the gate, they’re going to be soured on the whole thing.

A few years ago, we did a Web site for a tile and home surfaces company out in California. I remember being all concerned about the templates and the CMS and such, but I never did bother with worrying about what the editors were actually going to do inside the WYSIWYG editor. I spent no time configuring it – just handed it to them raw, at the defaults.

The result was a disaster. The marketing director called me up very upset saying everyone hated the CMS and they couldn’t get it to do anything right. They had been wrestling with it for days trying to migrate their content, and she was beginning to think the whole project was a big mistake. (Wherever you are Wendy, I’m sorry…)

This was all my fault. I hadn’t paid one minute of concern to things are banal and provincial as an editor actually trying to make a decent page of content. After the fateful phone call, I spent an hour configuring CSS and their WYSIWYG editor and it was a revelation. Their entire tone and feeling about the project changed. But it was never as good as it could have been because of their first experience.

The first experience matters. And the editor doesn’t see your magnificent API or database model or the conceptual elegance of your code. They have a WYSIWYG editor and a page they want to create. How’s that gonna go for them?