5 Top CMS Features That Will Ruin Your CMS

January 25, 2009

Posted in Technology.

Content Management Systems are always a hot topic in higher education, especially those of us who manage web. CMSes (ideally) let us create and update content on websites without a lot of technical know-how or staff expense. But we’re a greedy kind of folk, and we want to get the most of our CMS. Along the way, we’re going to have 5 very hard battles to fight or we’ll risk hating our choice for the next few years.

1. Permissions

Photo by jsmjr http://flickr.com/photos/jsmjr/264257694/

What: One of the great things about a CMS is that you can usually let non-technical users update their content. Delegating such responsibility is hard for many, though – they want assurances that only the content that should be changed can be changed. In other words, people want to make sure their employees can’t deface their website.

Why This is Dumb: If you don’t trust your employee, why would you hire them? Why would you keep them on staff? Why would you give them this assignment at all? This isn’t to say that you should go all wild west with your CMS: some permissions are OK. But page level? Directory-level? These details end up creating more work for the CMS administrators and more headaches for the people who need to update content. So avoid a spaghetti mess of such granular permissions.

2. Centralized workflow

What: When someone wants a change to their site, they submit a request to your central web team (often just one overworked, stuffed-in-a-closet web designer-developer). Your web team reviews it, adds it to the queue, and schedules the work. After all, the web team is qualified to make these changes and preserve the integrity of the website and adhere to your communications strategy, right?

Why This is Dumb: The web is growing explosively, even in small organizations. It’s much faster and more cost-effective (heck, often more effective in general!) than the print pieces you’ve been doing for the last two decades. Even the smallest department or academic center wants a website. And from what I’ve seen, no university or college has the staff to handle the demand. So forcing all of your content updates through a centralized web office is a suicide move – it ensures you won’t have time to do any of the real work you ought to be doing. A good CMS lets the web team do the heavy lifting – design, development, and the fancy stuff – while content owners do what they do best: own and manage their content.

3. Stock templates or themes

What: Most CMS packages come with a default theme. It’s usually quite plain, but it’s also quite clean and attractive. It shows off the feature set. It looks good because the CMS vendor wants to show how well this works, right out of the box. Maybe your staff is too busy or doesn’t know how to create a custom theme. Or maybe it costs extra to customize. Or it looks good enough that you’re willing to adopt it as your own site design.

Why This is Dumb: Everyone can tell. It’s like you rolled out of bed and drove into work wearing your pajamas: even though you’ve met the minimum public standard of being clothed, you wouldn’t be proud to show up wearing that to a sales meeting. Well, everyone can tell when your design is the default theme for the system. Because we’ve seen it before. And because it doesn’t quite do the job. Oh, and it doesn’t seem to match the personality of your organization – whatever that might be. Don’t skimp: design and build your own custom theme for the content management system.


WYSIWYG on Flickr - Photo Sharing!-1.jpg

What: What You See Is What You Get. It’s usually pronounced whiz-e-wig. When you want to add bold text in the CMS, does the text show up as bold right away? If so, that’s a WYSIWYG. It’s marked by a convenient toolbar that looks and works like it’s right out of Microsoft Word. Which is great, because it makes it easy to see what you’re doing and how it’s going to look.

Why This is Dumb: The usual WYSIWYG looks one way and acts another. The foundation of web standards is based on proper, semantic markup that describes the content appropriately. WYSIWYG tools aren’t smart – they just do what the user tells them to do. Which means they apply the wrong markup to content just to get it to look a certain way. Not only that, but many tools produce different code based on the web browser that the administrator is using! This can be addressed in two ways: 1) educate content administrators about proper markup and how to enter content, and 2) use a WYSIWYG tool that is browser-independent and more consistent. The path we chose for our CMS was to NOT use a WYSIWYG at all – we use a text markup language called Textile. I describe it as a Fisher-Price version of HTML.

5. Desktop software

Photo by Thomas Claveirole http://flickr.com/photos/thomasclaveirole/538819881/

What: There are two ways you might update a website: one is to log into a web interface, but another way is to install software on your computer that will access the website to make changes. There are some things that desktop software can do that web-based software cannot, often due browser limitations and connection speeds.

Why This is Dumb: This is getting less and less common, thank goodness, but some schools still choose desktop software. We made this choice around 2002, and are still dealing with the consequences. Desktop software means licensing, installation, platform issues, upgrades, etc. Web-based software can be accessed from home or, as is increasingly common, by traveling faculty and administrators. And browsers and connection speeds continue to improve, blurring the lines between web applications and desktop applications. As it stands, our former implementation has dozens of websites being managed by a piece of software that’s two versions old and almost nobody knows how to support.

Finding a Good CMS is Hard to Do

Not all of these features are inherently bad. It’s how you use them. After all, a CMS is a tool, and most CMS problems are actually offline problems. If you look at the list of five items above, they fall into the following offline problems: social, resources, branding, and editorial; only the desktop vs. web-based software issue has to do with the software. The rest can be addressed in the real world.

One of my favorite articles on the topic is from Jeffrey Veen of Adaptive Path on why content managment fails:

Content management is not a technology problem. If you’re having trouble managing the content on your Web site, it’s because you have an editorial process problem. Your public-facing Web site is a publication. Treat it like one.

If you’re not in the business of producing publications, you won’t be able to do better by plugging in a technology and crossing your fingers. Rather, solve the problem with people.