April 2013

Part one delved into the theory and justification for modern Content Management Systems (CMS). Let’s get down to the business of actually selecting a suitable CMS! First, some pitfalls to avoid:

•    Don’t choose one just because your friend likes it. This is about your needs and your company, not theirs.
•    Don’t choose one based on cultural attachment.
•    Don’t choose one just because your IT department says you have to. Consider the entire scope of your content.

A better CMS design process follows this workflow:

1. Consider your INPUTS
   a.    Content Strategy (substance, structure, workflow, governance)
   b.    Editorial Resources (the editorial team’s ongoing time commitment)
   c.    Technical Resources (hardware infrastructure, technical team’s ongoing time commitment)
2. Use them to inform the DESIGN PROCESS
   a.    Content Modeling
   b.    Task Analysis
3. Implement and govern your resulting CMS SELECTION & CUSTOMIZATION PLAN
   a.    Tools
   b.    Customization
   c.    Maintenance

Content Strategy and Editorial Resources

The root of your decisions rests here—the weightiest inputs, as it were. Be prepared to take into consideration:

•    Editorial Strategy (i.e., “product development for content”): editorial calendar, workflows, style guide, etc.
•    Content Analysis: content inventory, gap analysis, taxonomy, migration plan, etc.
•    Copywriting/Information Architecture: content templates (a.k.a. page tables), copy decks, annotated wireframes, etc.

Content Modeling

Your model should be designed to describe the content therein: types, models, and relationships. The content model semantically organizes the content, and thus can be seen as a subset of information architecture, as long as you don’t confuse it with the sitemap—that’s for top-down navigation. Ultimately, the content model is up to you. There’s no one-size-fits all; it’s more dependent on your style and judgment. That said, these guideposts can be of great assistance.

Semantics vs. Granularity

You’re basically pitting what does the content represent? against how much detail is necessary? To borrow Kahn’s example, suppose your company runs conferences and needs a content model. What are you representing? Events, presentations, speakers, and attendees. How much detail? This is usually the harder question. You could model multiple conference tracks and schedules, you could limit yourself to just presentations and speakers…But wait, there’s more! You also need to consider how content types relate to one another. Are presentations tied to tracks or events? Are these one-to-one relationships or one-to-many? How many data fields/elements does each speaker require in your scheme? These questions all boil down to classification and taxonomy. If your content is large or diverse enough to merit a CMS to handle it, it’s very important to agree on these answers before you commit to a design.

The Model Proper

With your deliverables worked out, you can sketch a working content model. The point is to clarify content types by possible associated elements, and also to demonstrate the relationships between content types visually. In the conference company example, you might want to model an event as a discrete number of tracks, each composed of a few presentations, each presented by one speaker. Thanks to semantic richness, you can flexibly choose several display options:

•    Users could navigate from a speaker’s biography to past presentations
•    Presentations could be shown in the context of a daily schedule, with before/after/simultaneous events
•    Intelligent search could return results by speaker, event, topic, etc.
•    Users could assemble a personalized schedule and export it in the form of their choice

It’s more important to have a pragmatic design than a flawless one. As your business evolves, you should be prepared for incremental changes to the model. Any number of constraints influence the design at this stage—know that you’ll probably have to compromise, or defer certain types of functionality until you’re better able to accommodate them. The only wrong choice would be to ignore these eventualities.

Task Analysis

Model in hand, you’re now ready to address the tasks involved: editing, publishing, and renewing the content you’ve specified. Remember, though, you don’t have all the time in the world. Task Analysis is designed to acquaint your model with reality by assessing the true cost of content and features, rectifying assumptions, and allotting the proper time periods for editors and techies.

You can use this four-step guide to evaluate the editorial process:

1.    Brainstorm key tasks based on your content model, editorial calendar, and content inventory
2.    Sketch workflow diagrams by task (sound familiar?)
3.    Sketch wireframes for interfaces
4.    Estimate the editorial time required for each task

With the conference company example, you might lay out the editorial task analysis like this:

Process: find event
Decision: does the track exist? Yes: choose track. No: add track.
Decision: does a speaker exist? Yes: choose speaker. No: add speaker.
Process: add presentation and corresponding fields
Process: publish presentation.

Pretty simple so far. The usual implementation would include about five separate screens, taking up to 20 minutes to complete. When sketching wireframes, consider design elements such as auto-complete or show/hide. By repeating this process for each editorial task, you can then prioritize scope against the actual timeframe—here’s where informed adjustments can be made, where before you could only assume. You can also address the order of tasks, which may surprise you. Still, better to be surprised now than after time or money has been wasted.

The Big Finish: CMS Selection and Customization!

Now that all the planning is done, you can ruthlessly trim down the seemingly infinite list of CMS tools, eliminating any that don’t provide your functional requirements. Similarly, you can fast-track the customization discussion because you already have a concrete idea of what you want. Of course, consultation with your tech team, vendors, or online communities may still be in order. How much customization do you need, can your current resources cover it, how long until the customizations are in place? Don’t let any of these questions go unanswered, and don’t be afraid to scale back on some elements of your model to arrive at a suitable answer. After all, you’re still pre-commitment. Get estimates, and get estimates for possible workarounds!

From here, it’s the usual song and dance with corporate project plans. The system is awesome and you’re satisfied with how it came about, but that doesn’t mean you can just walk away. Good news, though: all that workflow diagramming pays off, because it’s perfectly applicable to applied content strategy for a working business. You’re playing for keeps now, but you’ve certainly practiced enough to get a feel for your capacity. Think of the difference: a well-strategized, custom CMS is a (better) universe away from the sloppy, disorganized content “plan” must companies use. This is how it’s done!

Jonathan Kahn lays out some excellent pointers on how to intelligently approach content management in this article for A List Apart. Read on for a recap of his major points! This is the first in a two-part exploration of Content Management Systems (CMS)

Put simply, you can’t just slap a CMS on your website and call it good. That’s asking for further problems down the line—and inviting compatibility issues, to boot. Editorial teams are no different than the other teams comprising your organization. Strategy matters. Design and user experience are essential in the grand scheme of things.

Why Isn’t There An Easy Fix?

A couple of reasons spring to mind. Probably the largest is the fact that every website has its own custom set of needs which must be addressed before any content management comes into play. Kahn says it best: “any web project more complex than a blog requires custom CMS design work,” period. Sure, faceted navigation on a wireframe looks great in a proposal, but think about the work implied for the editorial team. A multi-tier taxonomy demands a correspondingly robust CMS, not to mention the man-hours to procure, produce, and/or edit the material itself. Know your needs, know your capabilities, then settle on CMS design that marries the two. Don’t cave to popularity with users or time sensitivity; the deciding factors should be the type, frequency, and feasibility of content publication.

For the Layman: What is a CMS?

Content Management Systems package software tools together to enable non-tech users to manage web content. Because the need for such a system is so great, a dizzying array of CMS tools are out there. Common features include:

• Content creation/editing (the big one)
• Delivery
• Taxonomy management
• Curation/page composition
• Editorial workflow

The tactic, of course, is to cram so many features in that you’ll give up and reach for your wallet in a “more is surely better” daze. But, again, that’s band-aid mentality! Bells and whistles are only useful insofar as they contribute to the strategy you’ve worked out. Let’s work out the necessary elements:

Semantic Richness

Paraphrasing Jeff Croft, your CMS should use a rich content model to craft semantic web pages. That means the ability to:

• Intuitively structure, organize, search, filter, and modify your content
• Define new types of content on the fly
• Construct meaningful relationships between disparate content

This should all be part and parcel of the “writing” process: you want to be able to implement and control these parameters at any stage of the content lifecycle, not just after the fact.

Meet the Project

A CMS isn’t magic, though some are advertised otherwise. It doesn’t just fix your problems right away; it has to be customized to deal with your specific problems with a specific protocol. In fact, according to D. Keith Robinson, just about every CMS needs this sort of customization before it can really get to work. Has it always been this way?

Content Strategy Changed Everything

Well, sort of. CMS used to be an IT-centric endeavor, meaning it used to be almost entirely up to the IT Director. Their concerns were practical features, price, and cultural fit, with little to no emphasis placed on ongoing strategy. No more! Now, we conceive of a company’s website as its primary contact vehicle—it drums up sales, it markets, it gets you in touch, etc. This logic drove a sea change that birthed what we call Content Strategy: web content no longer lives in departmentally isolated pages. The new playing field involves the entire internal editorial team, defining success as an interdependent amalgam of meeting business objectives, producing relevant content, and delivering a strong user experience.