Two Types of Content

With the advent of responsive design and later discussions adaptive content has come a split in the world of content strategy. In one corner is NPR's COPE, the idea that content should be flexible and flow through many different formats with the standard web page being just one possible outlet. Over in the other corner is an older view, the world of WYSIWIG's and inline editing, the one where SEO-centric people tinker with specific colors and layouts to squeeze every last drop of potential from a piece of content. Caught in this debate is the future of new CMS platforms - especially Drupal 8 - and the overall direction of tomorrow's content strategy.

As a programmer I naturally lean towards the ideas of fluid data. Separating out the layers just feels right, whether it's view/business logic or presentation/content. The thought of having a full-featured API to call and fill mobile apps, mobile website, desktop sites, or any feed-centric platform is frankly cool. However, I can also see the need for fine-tuned tweaking. Making sure that the text flows nicely on a specific landing pages, that the words line up just right and catch the user's eye, is something that you can't do from an agnostic CMS. There's a place for specialized, optimized content and a place for data-driven, distributed content.

One solution to this is to divide up a website's content into two types. This is already done with images - there are specialized background images that enhance a web design and content images that block up with the text. An online photo album might have some fantastic background images, a cool header logo, and then rows and rows of photos. The web developer spends a lot of time with the background images, making sure everything lines up and any repeating patterns flow before uploading dozens, if not hundreds, of standardized photos cropped and resized to defined sizes. The end user is able to enjoy both types of images in different ways: they consume the photos while the background images provide context and support.

So too does the different types of content work together to fill out a web page. A car dealership website may have dozens and dozens of different vehicles, each with images and descriptions and specifications, and this raw feed of data gets plopped onto template pages that appear identical. It does not make sense to have inline editing for these product pages. Vehicles come and go, the information changes, and the user expects similarities in each page.

Where inline, specialized editing can come in handy is with the service page, or the about page, or even model landing pages. These pages have content that don't change often, that shouldn't change too often. The content on these static pages provide a good base for the website, a solid context that a user can depend on. They should be optimized, with the occasional tweak over time, but there's no need for these pages to be part of a generic API.

Dealership websites are not the only type of website that should have split content like this. Any sort of product-based site, news and media, even blogs have a clean break of content types. Some chunks are dynamic templates and can be filled with a NPR COPE-like data structure while others are more static and context-based.

Is there a split in the world of content strategy? Yes, and I think there is enough room for both. Not all content is the same. There is some content that should flow through different devices, served up by a powerful feed and powered by an agnostic data source and CMS, and there is some content that should be focused on specific devices and platforms. Inline editing has its place, especially when the content generator is not terribly technical, and should not be discarded in this world of adaptive content.