Responsive Web Design, Part 1 (2015)

Content Choreography In RWD

Working With The Model In A CMS

All of this content modeling is built on the assumption that you’ll be creating the site inside a CMS. Structured content can only be used to its fullest when the data and information are kept separate from the presentation layer, and that means you need a system to manage the intersection of those layers. If you’ve never used a CMS before, welcome! They are a rich source of joy and frustration.

CHOOSING A CMS

What do I look for in a CMS? (There are of course many other considerations to choosing a CMS — technical, ongoing support needs, cost — but I’m only going to address the content issues.)

•Obviously, the CMS needs to support creating multiple content types and lots of different kinds of fields. These capabilities should be part of its core code, but a popular and well-supported add-on module is alright, too.

•It should allow me to divide and recombine all the fields in my content types for a variety of display uses, and changing the configuration for one type of display shouldn’t break any of the others.

•The system should have a robust set of tools for customizing the authoring experience’s layout and help text because without that I might as well build flat HTML pages again.

•If my models or authoring workflow rely heavily on a particular type of field or functionality, I make sure the CMS has strong support for it. For example, some systems make it very easy to crop a photograph to preset dimensions from within the editing screen, whereas others require the author to upload an already cropped image. I put a high priority on choosing a CMS that makes the author jump through as few hoops as possible.

You may not have the luxury or burden of CMS choice — if you work at an agency that specializes in ExpressionEngine, or you bill yourself as a Drupal developer, or a WordPress guru*, the CMS decision has already been made. That’s fine, too. You can skip right to the middle and start figuring out how to make your CMS work best for you.

Please don’t.

I try to build CMS-agnostic content models, to create a picture of the ideal set of fields and relationships, without any restrictions, that serve the content best. When the time comes to compromise as I map the models to a real system, having a strong sense of the ideal scenario helps me find solutions that preserve the original intent as much as possible.

GETTING CONTENT MODELS INTO THE CMS

The spreadsheet representation of the content model is built to make implementation easy. I work through it row by row, creating and customizing content types and fields until the whole model is represented in the system.

One of the most common snags I run across during implementation is when there are two nearly (or completely) identical content types. For example: “Artist Biography” and “Executive Biography”, or “Training Program” and “Ongoing Education”. Should I combine them, or create two separate instances? My inclination is always to combine into a single content type: perhaps “Biography” with an additional “Type” field (with the choices “Artist” and “Executive”) to distinguish between the two uses. The urge is a good one, based on my desire to reuse code, simplify styling, and make the site as lean as possible. It’s not, however, always the right choice.

“Training Program” and “Ongoing Education” may be identical content types with the exact same set of fields. But if they serve entirely different business purposes — say one is aimed at novice laypeople, the other at existing experts — combining them may not make sense. Are the same people in charge of both kinds of entries? If separate departments handle the two types of information, having them both use the same content type may be confusing, and may hinder my ability to customize and tweak the model and forms for each group’s needs. Even if all the content entry will by handled by a single person, does that person understand these types of content to be completely different? If she says “Oh yes, I could see how those are just two versions of the same thing!”, then I’ll combine the content types. But if she’s stuck on them being entirely unique, I either need to present a compelling reason to combine them or be content with letting the two content types live as parallel structures.

There’s a lot to be said for stakeholder education and CMS training, but it’s also important that the models work with the author’s understanding of the information. A model that a client is constantly fighting against is no good model at all.