How Would You Design a Content Management System?

Rendered Concept of a Digital Content Lifecycle.

By Cathy Hodson

What is a content management system (CMS)? According to Wikipedia, “A Content Management System (CMS) is a computer program that allows publishing, editing and modifying content as well as maintenance from a central interface. Such systems of content management provide procedures to manage workflow in a collaborative environment. These procedures can be manual steps or an automated cascade. CMSs have been available since the late 1990s.”

In other words, a CMS allows multiple content creators (frequently called “authors”), a managed workflow (approval process), and either automated or manual features.

I have experience with two content management systems: Ektron and SharePoint. They both have their advantages and disadvantages. I have also kicked the tires on other CMSs, and they too have the good, the bad and the ugly. Recently I asked the members of the Web Editors group, “If you could design/develop your own content management system, which features would be ‘must haves’?

Must Have Features
The responses were interesting. J.D. desired more project management features, “The CMS should know that nothing goes public until an assignment of copyright agreement has been executed.”

He also recommended staging features, workflow integration (“you should get a view of works in progress”) and annotation, in particular, fact checking and documenting the fact checking.

Barbara wanted “True WYSIWYG. Period.”

Ken wanted to “work on a system that has all the parts that were promised. Twice this week I’ve been told…’Oh, that’s scheduled for the next version.'”

If you were designing your own content management system, which features would you want to include? For me, there are a few, and they have to do with control. Being able to control the style (rules and guidelines used for consistency across a website) within the CMS so authors not well versed in your company’s or your website’s style cannot stray from it. Another feature I’d like would be to have the HTML view of your content be color coded, such as in Dreamweaver. It makes it easier to pick things out when you’re looking for something rather than having everything in black type on a white background. In Dreamweaver, if there’s a problem in the code, the color coding stops where the problem is so you can find where the snarl is a little easier also. (If you’re colorblind, however, that may not be as effective.) It would also be nice to be able to use a global replace in the HTML view.

There are times when it seems that developers of content management systems don’t understand what a content editor or author does. They are not aware of the publishing process that a writer or editor goes through in order to add or maintain content on the website. This disconnect can be a major issue at times. For instance, when my company was going through its most recent redesign, we expressed our desire to the developers that, as all content funneled to me for approval, I needed to be able to see what had changed on each page. I needed a redlined version, in other words. Our company, at the time, had several thousands of web pages. There was no way I could possibly memorize each page and instantly recognized what an author had changed in an existing page when it came to me for approval. Because we have such a high volume of content, I didn’t have time to dig through everything on every page that was submitted to me to try and figure out what the author had changed. Had they deleted any paragraphs? Had they linked to something new? Was there an update to the photos? It would be helpful to see only what had changed so that I could review those changes and then send the page on its way to the website, or back to the author for more work. There was great puzzlement on the developers’ part, not understanding why this was so critical. We finally got across to them why it was so necessary, and were able to implement a customized tool that allowed me to see what an author had done to a page.

Gibberish code
About the time we were discussing this topic, I received an email newsletter, Fierce Content Management, and read the Editor’s Corner: “Content Management Systems drive me nuts!” by Ron Miller. I read with particular interest, “Last week for instance, I tried to drop in some code for the content marketing infographic we published. Typically, it’s like dropping in the code for embedding a YouTube video. You access the source code, paste the embed code, and presto, you have an infographic in your post. But lately our CMS has decided to spontaneously add gibberish to the infographic embed code making it virtually useless and forcing my co-worker, Emily Poe, to have the added work of dropping it in as an image instead.”

That hit home with me, as our CMS also will add gibberish when our authors copy and paste from a Microsoft Word file. Sensing a kindred spirit, I contacted Ron and asked him for his “must have” features. He sent the lists below:

Back End:

  • Make sure it supports multiple writers easily.
  • Make sure it’s easy to update the CMS. (WordPress is drop-dead easy).
  • Make sure you set up a good set of tags ahead of time.
  • Leave a place for the writer to include a one or two sentence excerpt and encourage writers to create this for you.
  • Make sure it’s easy to add alt text to your photos (very important for disabled community).
  • Make sure it’s easy to embed content like video and inforgraphics (easy access to HTML code)
  • Make sure it’s easy to add and edit photos. (visuals are really important in my view).
  • See if you can find a plug in for creating a weekly newsletter and linking it to a mailing list app like MailChimp.

Front End:

  • Accessible contact info.
  • Some sort of comment security like Disquus. Doesn’t prevent morons, but helps.
  • Prominent search box.
  • Resources like white papers and ebooks.
  • Include all your site’s social media info
  • Make it easy to subscribe
  • Make it drop-dead easy to share across all major social networks.
  • Easy to copy and paste text from outside sources and maintain style

None of the CMSs will be perfect. They all have their quirks, and web editors must find work-arounds and solutions we can live with. But it sure would be nice if we could design our own, or at least catch the ear of the developers and have them truly understand what our needs are. Anyone?

Next time: Editor vs. Programmer


Usability in Redesign

By Alan Eggleston

How do you get a site redesign right? How do you make sure it fits the needs of your users and will be useful when they come to the site? Two words: Usability Testing.

Certainly, a needs assessment is important. You would want to pool the opinions of your various stakeholders to make sure their voices are heard. You would want to take advantage of the experience of your designer and developer, no doubt about it. But when the preliminary input is received and you begin piecing together the site, theory and input fall to the wayside and the practical takes over. That’s when usability testing is invaluable.

There is always the pressure from within to think we know our users. Yet, until we ask them, until we query them with design-in-hand, until we give the user a chance to interact with our handiwork, we never really know whether our site works for the most important person for whom the site is made – the user.

Usability testing occurs at different milestones in the redesign and tests your assumptions about site navigation and function by having actual users play around with it. They may also test other aspects of the redesign, like color, font, the use and location of various elements, but key to the testing is navigation – it asks the user, does the way we’ve laid out the site make sense to you and is it functional for you? You would be surprised how often our assumptions on behalf of users are wrong.

Stage I – Test Your Thumbnail

At an early stage, it is useful to test a thumbnail or wireframe of the redesign with users. Let them see the home page and ask them to look at it where they think they might go to find different things. It might be as rudimentary as pointing to navigation bars or page elements. If you have named your navigation, this is a good time to test whether it works for the user and which named ones don’t. Even if it is just a rough layout, you can also test where their attention is drawn and where they would like to find different kinds of information.

Stage II – Test Your Navigation

At an intermediary stage, it is useful to test out your articulate site map – your hierarchy of links. If you have a technical structure built, let users test out your navigation. If not, create an interactive graphic that lets you expose navigation levels as they try to drill down. Ask them to use navigation terms to tell you where they would go to find information or items buried beneath the top levels. Be sure to ask them to locate links on the home page that are not in the main navigation bar, such as “Contact” or “About,” which might be at top right or in footer navigation. How long it takes them to respond can tell you how easy it is for people to use your home page. It may be inconvenient, but there should never be a time when you can’t rename something or move something to aid the user when it’s apparent its current name or location isn’t working.

Stage III – Test Your Site

Near the end, when you want to tweak the site before launch, you should bring in the users one more time. This is when the site is built, the links work, the pages are mostly finished even if there are a few stragglers still under development. Now ask your user testers to use the site for a set of defined tasks but also to play around. I would ask: What works well and what doesn’t? What excites you and what disappoints you? What’s a positive surprise and what’s a negative surprise? What worked well and what didn’t work (recognizing that a site still in development may not allow some operations to proceed)? When did you get lost and did you ever feel frustrated? Now consider what it would take to fix any of the issues brought forward by those questions. That close to launch, you may have to save them for site updates, but if they are easy fixes or problems that are critical to site success, you might have to hold the launch until fixes are found.

Testing with Science

One more usability test I didn’t mention till the end: A full-bore market research science-based usability test using computers and cameras and metrics to see how users physiologically react to and use a site – either an existing site for future planning or a new one in development. I waited because these can be costly and not everyone can afford one. But if you can, I highly recommend it. What you learn about how your users actually see and read and react to and use your site is invaluable insight. Assume what you will about your site and users, this is the real thing.

Next Up – Inside Testing

Once you’ve redesigned a site and tested it with users for usability, you need to quality test it to catch the bugs before you release it to the world. Let’s talk quality testing in my next Web Editors article.