Design Content for All Platforms, Not Just the Desktop

The web continues to fragment. Most observers estimate that the mobile web will overtake the desktop world sometime in the next 12 months. While visitors to think tanks may not be out on the leading edge of the tide, they’re assuredly out there in the main swell.

At The Century Foundation, our desktop website is still our primary outlet for digital content; about 80% of our traffic comes via the desktop. But a year ago, that number was closer to 95%, and we’ve seen a steady uptick in mobile traffic each month. If we continue to design content for the desktop web, we’re going to get swamped.

We can produce content for the mobile web in a variety of different ways:

  1. Add a whole new team to format content explicitly for our mobile sites. (Impractical, especially since many of us are still trying to convince our organizations to integrate our print and digital teams.)
  2. Truncate desktop content for mobile. (Self-defeating, as it provides a degraded experience for the very platform from which all our growth is coming.)
  3. Create reusable content that readily adapts to all platforms. (We have a winner!)

If we’re to head down that third path, though, we need to spend more time thinking about what our content does and less time thinking about where it “lives.”

Sometimes we assume that the digital world consists of two pieces: the content layer, and the presentation layer. But there’s a third layer. It’s your platform—which for most of us means our CMS. And too many of us don’t treat it as the separate layer it really is.

Three layers of digital content.

Karen McGrane’s three layers of digital content.

Many of us err by linking our CMS—the platform layer—too closely to the information architecture for our desktop website. This path can look particularly alluring during a sitewide redesign. After all, we have some page tables for our content. And we have some wireframes for the various page templates for the site. So why not build our content types to correspond to those templates?

I speak from experience.

The Century Foundation launched a new website in January 2013. Our developer had worked with Century staff to develop some good content models. Below are the fields for our book content type.

books field group

Books field group

It’s a thing of beauty. Authors, subtitles, cover images, descriptions, ISBN numbers…each with its own separate field. It’s a model that allows for different content displays in different places.

In all, there were nine content types:

  1. Blog: for adding content to our Blog of the Century.
  2. Books: for adding Century-published books and/or books by Century’s fellows.
  3. Commentary: for adding longer content to topics sections.
  4. Downloads: for adding file attachments (white paper PDFs, etc.)
  5. Events: for advertising Century-sponsored events
  6. Experts & Staff: for adding fellow and staff bios to the site.
  7. Homepage Feature: for adding content to the homepage “hero box.”
  8. Job Opportunities: for posting details of job openings at The Century Foundation
  9. News: for linking to items written by Century fellows for external publications (e.g., an op-ed in the New York Times.)

Most of these make sense. Events and books (for example) are very different types of content. Creating a book content type means that the editing interface for books has fields for book-type content while the editing interface for events has fields for events-type content.

But when I arrived at Century in February, two things really stood out.

Duplicate Content Types

Here are the fields for the blog content type:

Fields for blog content type on tcf.org

Fields for blog content type on tcf.org

And here are the fields for the commentary content type:

Fields for the commentary content type on tcf.org

Fields for the commentary content type on tcf.org

Notice that they’re basically the same set of fields? That’s because the blog and the commentary section both hold the same type of content. The only difference between the two kinds of content was where they showed up on the desktop website.

annotated homepage for tcf.org

Annotated homepage for tcf.org

Instead of building our content types (our platform layer) around the function of the content itself (the information layer), we had tied the platform to the layout of the site (the presentation layer.)

Merging the platform and the presentation layers means that making changes to the structure of your website is far more difficult. It’s analogous to the old days in which content was hard-coded onto pages.

Our websites contain lots of different types of information. We should have one content type for each different information type. Putting a particular kind of information into a particular location of our website is a job for your CMS’s templating function, not its content types.

Which brings us to the second problem…

Too Few Content Types

Consider the humble blog. We probably all have at least one of these. And the chances are pretty good that we’ve created a content type for it. There’s probably a bit of standard metadata attached to it (title, author, date, some categories, some tags, maybe a subtitle.) But the bulk of your blog content is entered through field called “body.” And there’s probably a WYSIWYG editor involved.

It’s okay to admit it. We’re all friends here.

There’s really nothing to be ashamed of. What I’ve described just is the standard blog model. It’s the one that WordPress brought to the masses. And it worked pretty well when we were all just putting content up for a desktop website. WordPress gave us the equivalent of Microsoft Word for the Web. We all liked it because we all knew how to use Word already.

But think about all the different kinds of content we dump into a blog:

  • Text
  • Video embeds
  • Charts and tables of data
  • Infographics
  • Audio clips or podcasts
  • Interactive visualizations

These are all very different types of content. And accordingly, they need very different types of metadata. Infographics need alt tags and title tags, credits for both designers and authors/data specialists, and data sources. Charts may need some of the same information, but may also need to be accompanied by a fair amount of text. And if those charts are bitmaps, we’ll probably need them in a few different sizes. Audio clips might need sources or descriptions. The list goes on.

The point is that our CMS should reflect the function of our content, not its placement on our website.

At The Century Foundation, we’re taking our own advice. We’ve collapsed our commentary and our blog content types into a single type, one that’s used for content that is mainly text-based.

We’re then adding several more content types:

  • An infographic content type for use with large images that are displayed with little-to-no accompanying explanatory text.
  • An interactive features content type for things like JavaScript-based interactive data visualizations, and control panels for web applications.
  • A graph of the day content type that allows for presenting content that is organized around a chart (or charts) but that also requires a few hundred words of text. This new content type will allow for uploads of multiple charts (each in multiple sizes), and will utilize shortcodes to specify how the text fields and the image fields should interact.

Our team is still in the early stages of implementing these changes. In the coming weeks, we hope to share our successes—and help you avoid any pitfalls we may encounter.

About

Joe Miller is the Director of Digital Media Strategy at Eastern Research Group. He came to ERG from The Century Foundation, where he transitioned the organization to digital-first publishing. Previously he created the digital strategy program while heading the web team at the Congressional Budget Office, worked as a senior staff writer at FactCheck.org, as a writer with the Mack/Crounse Group, and taught as an assistant professor of philosophy at the University of North Carolina—Pembroke and the United States Military Academy. He received his PhD in political philosophy from the University of Virginia, his MA in philosophy from Virginia Tech, and his BA in philosophy from Hampden-Sydney College.

Tagged with: , , ,
Posted in Opinion
5 comments on “Design Content for All Platforms, Not Just the Desktop
  1. Karen McGrane says:

    This is a great analysis—I love seeing real world examples of these concepts.

    Let me give credit where credit is due: the conceptual model that breaks digital services into three layers comes from the US Government Digital Strategy: http://www.whitehouse.gov/sites/default/files/omb/egov/digital-government/digital-government.html

  2. pokpok says:

    If we’re to head down that

  3. […] I should clarify what data means in this context. We’re not talking about vast spreadsheets of ones and zeros. ‘Data’ in a communications context includes content (e.g. blog posts), metadata (e.g. authors) and process (e.g. publication approval processes). Structuring data in this way will become increasingly important as think tanks develop content to be accessed on multiple platforms. […]

  4. […] IT team. And it’s also going to require structured content. After all, if your book content type has a separate field for the ISBN, it’s pretty easy to write some code that will apply right semantic tag […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: