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:
- 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.)
- Truncate desktop content for mobile. (Self-defeating, as it provides a degraded experience for the very platform from which all our growth is coming.)
- 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.
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.
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:
- Blog: for adding content to our Blog of the Century.
- Books: for adding Century-published books and/or books by Century’s fellows.
- Commentary: for adding longer content to topics sections.
- Downloads: for adding file attachments (white paper PDFs, etc.)
- Events: for advertising Century-sponsored events
- Experts & Staff: for adding fellow and staff bios to the site.
- Homepage Feature: for adding content to the homepage “hero box.”
- Job Opportunities: for posting details of job openings at The Century Foundation
- 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:
And here are the fields for the commentary content type:
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.
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:
- Video embeds
- Charts and tables of data
- 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.
- 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.