Responsive Web Design, Part 1 (2015)
Content Choreography In RWD
How To Build A Content Model
A content model is an organizational plan for all of the different content in a project. It covers both the high-level content types (like events and products) — and the individual fields and data attributes (like event date, location, and teaser sentence) that make up each type. The first step to building a model is, not surprisingly, understanding my content. I like to start by performing a structural content audit.
If you know the term “content audit4,” you’re probably familiar with an editorial audit. In the editorial audit, each page or piece of content is reviewed and graded against a set of qualitative criteria, like readability, intended audience, or adherence to an existing style guide. A structural audit, in contrast, is more concerned with uncovering the patterns and relationships across all the content. Once I understand the content types and how they relate to one another, I can start to tease out the facets and individual fields for my content model.
STARTING THE STRUCTURAL AUDIT
When I’m faced with a huge existing site or a ton of legacy content, where do I start the audit? My take is: wherever I want. Just dive in.
(Except: don’t start with the homepage. It’s often a mess, and rarely has sensible ties to the rest of the site content or reuse patterns. You know what I’m talking about: the homepage is a political playground, not a structural one.)
I usually start with some of the minor content, like “Executive Bios” or “Company History”. As I read through 10-15 entries or pages, I’ll begin to spot patterns: these executive biographies always have a headshot, name, job title, and biography text. I may notice further nuance in some areas, like that the first paragraphs of biography text are professional background, and the last is about family and personal life.
Finding the patterns in existing content is the first step towards building a model.
More importantly, I’ll find places where a pattern like “first paragraph: work history; second paragraph: personal history” isn’t carried through, and I’ll see how (or if) that inconsistency affects the user experience. I start having discussions with my stakeholders about where the new model should enforce guidelines (through required fields, help text, and so on), and what parts should be left to author discretion.
AN ASIDE ABOUT EDITORIAL CONTENT JUDGMENT
I don’t specialize in editorial strategy; my background isn’t in writing or editing. But even the structural audit includes some editorial judgment because I can’t look at hundreds (or even dozens) of pages without starting to recognize poor formatting, bloated text, and lack of user guidance. As I’m working through the content, I make notes about places on the site that could use editorial attention, especially sections that need design and development help (like “More prominent calls to action!”) to be effective. This won’t be as comprehensive as a full editorial audit, of course, but it’s a place to start. Content strategy is about progress, not perfection.
IDENTIFYING FACETS WITHIN A CONTENT TYPE
How do I know what parts of the content should be separated into their own fields? For each chunk of information, whether it’s something distinct like “Job Title” or a little fuzzier like “second paragraph of the bio, holding personal history”, I ask the following questions:
Is this content likely to have its own style?Audits usually happen long before design, so you won’t know this for certain yet. But I’ll often have a sense: a field like “Job Title” is usually displayed separately from the person’s name; or I may already know that the event location address is going to be displayed in a <div> that’s visually distinct from the main event description. Any content I think will have special display or styling requirements is a good candidate for having its own field in the content model.
Does this content have special editorial requirements? If a piece of information needs to be limited to 250 characters or a chunk of content needs to include very specific references to corporate initiatives or internal programs, it may warrant its own field. In most CMSs, each field can have its own set of contextual help text and authoring guidelines; being able to break out content with complex or specific editorial needs allows me to customize those guidelines to help authors do their jobs well.
Is there filtering or sorting functionality based on this information? Computers are great at rearranging and customizing content, as long as we give them the tools to do it. Users may want to filter the event calendar to show only family-friendly events, or sort a list of documents to see the newest entries at the top. Any piece of data that may be useful for grouping or organizing content should go in its own field.
Will this content be displayed differently in different places on the site, or across varying screen sizes? A product may show a one-sentence description on the homepage and a full description on the product detail page. An artist’s portfolio might show an expansive photograph on a large screen, and a zoomed-in design detail on a small screen. Many responsive sites adjust content and imagery to enhance the user experience across different screen sizes; breaking information into individual fields makes this kind of manipulation possible.
Are there other places (like an RSS feed, API, or native app) that will reuse this content? If my plans involve reusing content across different channels, what content variations do I need to support that work? Entries that will be promoted on Twitter need a sub-140-character description. Content that matches one of the special OpenGraph types5 should include all the fields necessary to take advantage of Google and Facebook’s use of that framework. When I have other plans for the content — as complex as a native app, or as simple as “internal-use-only data that we don’t want to lose track of” — including fields for that information in my content model will make maintaining a consistent record much more feasible.
Once I have the skeleton of a model for a simple, minor content types — which at this point is usually just a scrawled list of content sections on a notepad — I scan another 20–30 entries to see if any of them contain information that falls outside the chunks in my proto-model. I can adjust the model to hold the new information, and also go back to my stakeholders and discuss the outliers. Sometimes outlying content (helloooooo “Photo highlights of the 2011 company golf tournament”) won’t make the move to the new site and so doesn’t need to fit in the model.
BIGGER, MESSIER CONTENT TYPES
Finite content, like biographies and calendar events, is relatively easy to model. Those types tend to hold discrete chunks of information, and more importantly, people understand them. An executive biography is different from an event listing, and even without doing a full audit, many people could make a passable stab at modeling the information they contain. Sadly, not all content is this tidy.
The content that describes an organization’s core products and services can be much more difficult to wrangle because it’s unique to the business and usually contains data and information that falls outside of my early simple models.
The most important part of modeling bigger content types is figuring out ways to group the data. Our product content might be expansive and messy, but a bunch of those fields are product specifications and can be gathered into a single section. As I list all the pieces of data that make up the content type, I start to see smaller patterns emerge that help me make sense of the rest.
FIELD REUSE AND RELATIONSHIPS
I also keep an eye out for fields and content that are shared across content types and relationships between types.
Fields that are reused across types are the simplest to spot: the biographies for authors, artists, and staff all include headshots and URL fields. Most CMSs let me reuse the same field in different content types; I can style the field once and have that style applied everywhere that field is shown.
When the reused information is broader than a single field, that’s a place where a content relationship can be helpful. I have clients with multiple offices, and different services are available at each location — I want site users to be able to look at the detail page for a single service and see all the locations where it’s offered. Rather than include a text field where an author would list the offices, the content model calls for a relationship: the CMS will present a GUI (commonly an autocomplete text field, select list, or checkboxes) that lets the author choose the locations from a list. Content relationships allow the front-end to display anything from a link to the location detail page, to a teaser of the location, to an address that will open in a native maps app on phones that support it. All without the author having to know how (or remember) to create that code, because I’ve set the content models up to take advantage of the power of relationships.