Responsive Web Design, Part 1 (2015)

Content Choreography In RWD

Documenting And Sharing The Content Model

Content models are only useful when the whole team understands them, so it’s important to get the model out of my head and onto paper or screen in a shareable format. And when I say “the whole team,” I really mean it. We tend to think of the customer as the end user and ignore the fact that the site administrators and authors are on the site more often than most users. Be persistent — annoying, even — about reviewing content models with all levels of the web team. If content entry is mostly handled by Alice, the summer intern, walk through the models with Alice, the summer intern. She’s deep in the content every day and has insights that others do not have.

I often end up creating a few different views (a spreadsheet, diagrams, low-fidelity wireframes, and so on) of the same model in order to give a more complete picture, and to address all my team members’ needs. I’m generally building a model for three different audiences: stakeholders, developers, and authors.

STAKEHOLDERS

Stakeholders want to see the big picture. They want to understand what the overall structure is, and they’re very interested in what that structure allows them to do. They are generally less interested in the minutiae of implementation and don’t care if a field is represented as a boolean in the database. For stakeholders and executives, diagrams and schematics — even a very sketchy wireframe showing a user journey — are helpful.

A graphic representation of the fields in the model can help people understand the overall shape of the content without diving into minutiae.

DEVELOPERS

Developers appreciate the big picture, because who doesn’t like context? But they need details about how to actually build the models in the CMS. They care about whether a field should be a text <input> field or a <textarea>, whether there’s a character limit, if the field is required, and if it will need to accept HTML. The core of most content models, and the information most useful for developers, lives in a spreadsheet.

A spreadsheet is the perfect place to keep track of all the disparate pieces of a content model.

There’s no canonical spreadsheet: every project has different needs. My basic content model spreadsheets contain the following columns:

•Section: groupings of fields, usually by content area like “event information” or “location data”.

•Field: the name of each piece of data in the model.

•Format: the type of content stored in the field, like “image”, “rich text”, or “boolean.”

•Maximum length: this is often used in RWD, where you might have two or three length variations of a single piece of content for use across different screen sizes.

•Number of instances: the upper limit on the number of instances of that field in each entry. For example, an event listing can only have a single location, but may have up to four instructors. This is a good time to learn how to type the ∞ symbol.

•Required: whether or not the field is required for each entry.

•Contents: a brief description of the contents of the field, like “Directions to the location, including information about where to park.”

•Notes: any other information about the field, including thoughts about implementation, issues to discuss with stakeholders, or an explanation of what this field enables from the user experience standpoint. It wouldn’t be a spreadsheet without a catch-all column.

My spreadsheets also include other columns to hold whatever information this particular project needs. Such as:

•Source
If we’re pulling content together across systems, through APIs, or from other media like print publications, I make a note of where the information in each field will come from.

•Example content
Especially helpful if the team is having a hard time wrapping their heads around how the current content will fit into the new model. When the model has variations on a single piece of information (like a short and long image caption that will be used on different screen sizes), having examples of both helps authors better understand the nuance and difference between the variations.

•Do not include
It can be helpful to clarify what doesn’t belong in each field. “Do not include the address in this description”, or “The biography should not repeat the job title (because it lives in its own field).”

AUTHORS

Authors need some of the details of the spreadsheet, like character limits and required fields, but they don’t need the technical implementation data. Authors also need editorial guidelines, which help them use consistent messaging and style across the site. These guidelines are traditionally captured in a content template⁶.

The content template reminds the author who the intended audience is, the primary message that the copy needs to convey, and the purpose of the content. The content template can also include much more detailed information about what belongs in larger rich-text fields, including a paragraph-level outline, reminders of words to include (or avoid), and tips on language and style choices.

Traditionally the content template is a separate PDF, but my experience is that people don’t usually remember to open those kinds of files in their daily workflow. Instead, I like to build those content guidelines directly into the CMS interface. Most CMSs allow you to customize field labels and help text for each content type. By including audience needs, voice and style reminders, and technical content guidelines directly in the CMS editing form, you’re providing information to your authors exactly when and where they need it.

Remember our example from earlier? It’s much easier for an author to create consistent content when all the guidelines are right there in the admin interface.

Good labels and guidelines:

•provide context, explaining what a field is for and how it will be used;

•are specific, encouraging accuracy and uniformity while eliminating guesswork;

•are positive and helpful, rather than hostile and prohibitive.

Field names should be specific and descriptive (think “Artist Name” and “Biography Text” instead of “Title” and “Body”). Help text should instruct the author about what does and doesn’t belong in the field, and include guidance about how the field is being used and where it will be displayed so they understand what information it needs to contain.

If you’re eager to customize your CMS (and who isn’t!), I’ve written a whole article about improving field names and help text⁷ over at A List Apart.