Responsive Web Design, Part 1 (2015)
Content Choreography In RWD
BY EILEEN WEBB
Let’s start our journey into the world of structured content with a story about one of my clients, an international non-profit organization with a rich history and an enthusiastic staff. One fine day many years ago, their first website launched: it included a page for each of their office locations, a section describing their programs and services, staff biographies, and a brief page describing their history. The first version of the website was spearheaded by their program director, and owned and maintained by people on her team.
Over time, the organization grew: a new office in Geneva, expanded services in Chicago, a summer internship program. Each new program, event or news item meant adding pages to their website — literally creating additional HTML files. Control of the website bounced through a few departments — programs, marketing, outreach — and each group managed the files and the content slightly differently.
Enter mobile devices. This organization’s users lived all over the world, and more and more of them were accessing the site on their phones or tablets. The pinch-and-zoom experience was crappy, and they came to us looking for a redesign that would make the site work across all screen sizes. They’d heard and seen how responsive web design (RWD) worked, and they were convinced that it was the solution to all their problems.
Which: yes! RWD was a great match for their needs. But adjusting the font size and column ratios across screen sizes would not actually make their users happy, because the real problem was not the early-2000’s design aesthetic and inflexible images. The real problem was that the content sucked.
Content created by one department was never updated by the next. Services got renamed in the navigation but were still referenced by the old name in the body text. Important information was buried in the murky depths of flowery prose. Sidebars pointed to “Related Events” that happened in 2011. Important content like program eligibility requirements was duplicated in many places across the site, and the pages had diverged and showed inconsistent and contradictory policies. The site wasn’t helping users get the information they needed, or complete the tasks they needed to get done to do their jobs.
No one was interested in a major overhaul of just the content, but because they wanted a new look-and-feel we were able to use the responsive redesign as a scapegoat for changing their content architecture and processes. One of the major tasks was to figure out how to reduce the number of places errors could be introduced by breaking the content down into a system of reusable parts.
CONTENT IN A RESPONSIVE DESIGN
In this chapter, we’ll talk about why I bother to structure content — about what structured content lets me do on a site — and then we’ll go over how to take current unstructured content and whip it into shape.
We love responsive design as a great way to approach building sites that work across all devices. As a content strategist, I love RWD because it makes it very hard to ignore glaring content problems.
At its smallest sizes, RWD isn’t, generally, a festival of sound and light. When you strip the pomp and circumstance out of a beautiful desktop view, you’re usually left with a very straightforward, single-column, small-screen design that puts the content front and center. If that content is poorly organized, badly written, or just generally crappy, it’s very hard to ignore.
If, like me, your background is in design or development, adding in a whole new phase to your projects to focus on content may seem daunting. But the alternative, which you may have already encountered, is to hope that the content fixes itself, then launch a site that doesn’t help the user — despite its clever use of media queries.
What Is Structured Content?
Structured content is, at its core, pretty simple: instead of storing content in a few all-encompassing content management system (CMS) fields, information is broken down into its component pieces and stored in a set of individual fields. Karen McGrane has enriched all our conversations about structured content by using the terms “blobs” and “chunks”1: a blob is a single gelatinous field containing many different kinds of information; whereas chunks are individual, well-defined snippets of content, with clear edges and a crispy bite.
For example, here’s a type of content that’s common to many websites: the event listing. In most CMSs, the default entry type includes a title field and a body field. The body field is a blob, holding all of the information about your event.
Storing all the content inside a single field is typical, but it makes it hard to reuse information across the site.
There are a few issues that often come along with this kind of setup:
•If the site has a homepage block like “Upcoming Events”, it needs to be manually updated each time a new event is added. It’s an extra step (and hassle) for the site administrator, and the block will quickly get out of date as events pass and need to be removed from the list.
•A main page like an event calendar may want to display teasers (rather than full entries) for the entries. Truncating a full body field is a recipe for confusion and poor user experience.
Teasers created through truncation are often confusing and missing key information.
•If the site has multiple authors creating content, it’s very hard to keep a complex body field consistent. Some people will bold the time, others will use an <h3> because they happen to look identical. Sometimes the event will include a location as the second line, and other times that information won’t be included at all. An inconsistent body field is hard to style, hard to manage, and hard for a user to read.
Rather than keeping all of the information in a single field, structuring the content divides the data — components like event date, location, and teaser description — into individual fields.
Splitting the pieces out into chunks gives me flexibility and control, setting up the site for a more consistent and customizable user experience.