Managing your content management system
Rory Douglas writes about the perils of working within a content management system, on A List Apart. Essentially, he advocates for more editor-side decision making, to define fields and content structures so that it is a stricter publishing environment — basically so that the content is harder to screw up.
When implementing a CMS, try to give your users exactly the level of freedom they need—but, when in doubt, err on the side of giving them slightly too much.
That’s the broad view of things, but it’s trickier once you get into the details—the fields and WYSIWYGs and permissions. What makes it even trickier is that, if you’re thinking about CMS implementation, you’re probably in one of two very different situations:
- You’re creating a new site and the world is your content-management-system-implementation oyster.
- You’re managing or refurbishing an existing site and the content management system setup brings you great sadness.
Although these situations each have their own individual troubles—which we’ll get to—they’re both governed not just by the first rule of CMSes but also by the second rule: no two CMS implementations should be exactly alike. Each site will have its own needs, and the CMS should be customized to match those needs.
He poses questions to ask yourself as you’re designing the CMS. A couple particularly stood out to me:
Does the user need this permission? He suggests creating a user account with minimum permissions, and gradually go through and try to do everything this user will need to do, and add back permissions one by one. In WordPress this would be possible with a plugin like Members, and I love the idea for situations where a site may have various editors and content creators.
Does the WYSIWYG need that button? If not, remove them. He advocates that most WYSIWYG have buttons that just aren’t necessary (I know that’s true for my own use), and we should cater the editor to the specific client/content type/field needs.
In the end, he offers tips for getting a budget to do this style of work:
In my experience, not only is it possible to get approval to spend time on this, but you can get outright gratitude. I recommend making a financial case: spending x number of hours on the CMS now will save five times as many hours later. The more specific, the more compelling. For example, if you estimate 16 hours of work to implement an image-uploading system that takes care of all the image sizes behind the scenes, you can then estimate how long it would take for the content editor to save three different image sizes and optimize and upload them every time an image needs to be changed.
If that doesn’t work, here are a few sound bites you can use:
- “This is a special, one-of-a-kind organization, so we need to spend a little more time making sure the CMS meets its unique needs.”
- “You have talented staff doing important work, and we don’t want them to have to spend their valuable time troubleshooting errors on the website.”
- “We want to make sure there’s no way you can do anything to mess up the site. That way you’ll never have to pay us again.”
- “See this page where someone uploaded a dog GIF and typed some flashing red text? I can prevent that from ever happening again.”
Just don’t quote Dostoyevsky and expect it to go over well.
Check it out on A List Apart. This is highly useful for someone building the backend to be highly catered to a particular client.