In a Content Strategist's Shoes
Yesterday I finished reading Content Strategy for Mobile. It wasn’t a long book, and it’s 3 years old now, but it did provide a lot more insight into how to approach my presentation for Twin Cities Drupalcamp this year.
When you think about Drupal content types, it’s easy to only think of them in terms of what you can do on Drupal itself. It’s a bit like making a template for documents. It allows you to type the content, specify what kinds of fields you can have and which are required. That does outline the basic idea of content modeling, but it doesn’t effectively communicate why this is important.
What I needed to do take off my developer boots, and step into the shoes of a content strategist.
Why structure content?
Before an organization started to require the use of templates, they might have accepted just doing everything in an unstructured Word document. These documents don’t have any enforced structure. Even the title of the document is a guess -- just look for the biggest text at the top of the document. Sure, we humans can pattern match a title, but machines have only a limited ability to do so. After that, we hope that we structure the document with headings and subheadings. None of this is enforced by the editor, though. It’s a big blob of content.
“Just make it work like Word,” is easy to say. It’s also an express ticket to the land of blobs.
Structuring content starts to make more sense when you think in terms of channels. Just like it used to be a safe assumption you’d only be targeting print, it was a safe assumption to only target the desktop web. We know today, of course, you can’t make such an assumption any longer. Today there are multiple devices, multiple platforms, multiple aspect ratios, modalities, and resolutions. Not just desktops and smartphones, but tablets, Smart TVs, smartwatches, and even appliances. If your content is just a big blob of text, no matter how much inline formatting you have, it’s going to remain stubborn and reluctant to adapt.
You could say, “Okay, we’ll just create a separate content channel for mobile.” While this is easy to do, it doesn’t solve or split the problem. Instead, it doubles it. Now, instead of writing content once, you have to write it twice. Often this will be more than twice since mobile isn’t monolithic -- there is no single smartphone target (think of recent IDC marketshare reports) or tablet (declining iPad sales, anyone?). Smartwatches open up an yet another channel. Each recreation needs to live in a separate place, be reviewed in different contexts, yet still somehow connected together. You don’t want someone sharing a mobile-only link.
You need smarter content
Obviously, re-creating content to tailor it for each channel is hopeless. What we want is to publish it once, and then have the content be adaptable. We want each front-end to choose how and what to present. You might think, “let’s just truncate the content to fit”. Truncating content misses the point and is bad UX. A game developer blog might create a post titled, “Real AI based on the human brain.” A poor truncation algorithm might chop off just those last two letters, leading the reader to imagine dystopian future of omnipotent underwear. Even if you truncate at a word boundary, you might annoy your readership with incomplete sentences. Often they may just skip over content that would otherwise be interesting.
Neither re-creating content nor truncation is a solution. They both miss the point; content needs to be adaptable to the front end. You want to publish your content once, and have it available everywhere for everyone. Accomplishing that task requires not more people or separate channels, but smarter content. You need take that blob of content and chunk it up to more useful bits. Then, combine each chunk with metadata and business rules.
Drupal and adaptable content
Drupal provides a lot of ways of doing this. It has one of the best content modeling systems of any open source CMS. We can take our blobs of content, and chunk them up into typed templates with defined fields. Much of my session for Twin Cities Drupalcamp this year will involve this practical aspect: creating content types and defining fields.
Drupal also has a healthy ecosystem of modules that allow us to do more than what is provided out of the box. Many modules provide important field types -- links, addresses, phone numbers, geolocation, files, and media. Others allow us to display and aggregate content more effectively. Views allows us to build pages, widgets, and feeds of content. Not just chunks, but down to the field level.
Images also can be a problem when creating adaptive content. Devices has different resolutions -- and DPIs -- that make use of a single image inappropriate. This is becomes more critical when you also account for different hardware capabilities (speed and memory) and the expense of data connections. We can attach business logic to images to crop them intelligently, even replacing them with alternatives when certain criteria are met.
Content Packages
Some content types aren’t really types at all. They are content packages. They bundle up many pieces of content into a whole. For a feature article, you may actually link to several content types such as the author’s bio, a type for the images, types for callouts and others. Each of these is a kind of content in their own right, and should be considered as such to your team even if when presented to readers as a single blob of content.
Good chunking means users only see blobs, but you only work with chunks. That is, users see the illusion of a single, continuous content package on any device or modality in which they consume it. You, on the other hand, will see the chunks, the pieces, the parts that make up that package. This allows you to update each chunk, reuse those chunks in different packages, even switch out chunks as needed. You can’t do that with blobs. You have to go in, and edit each piece of content, one by one. Blobby content requires a lot of manual effort to chunk up. If it’s not done when created.
When creating content types in Drupal, there is no rule of thumb as to the number and kinds of content types you will create. Each site is different. Typically, though, you’ll have more content types than you expect, but less than you fear. If you have a lot of existing content, you’ll want to perform an audit to identify common chunk types. You don’t need to go over every piece of content, only a representative sample.
It’s often not enough to just think of content types. In many organizations beating the drum of content strategy will not be enough. The problem you have is cultural. Content creators often expect and demand to have control over their formatting. Wrestling that away from creators will involve a modicum of yelling, screaming, and gnashing of teeth. As time goes on, however, you’ll begin to see the benefits of chunking up content and delivering content packages. Enforcing that change will take time and dedication to a singular vision of adaptive content.
Summary
Creating content types is actually the easiest part of this entire discussion. It’s knowing what to create and how to leverage it that takes considerable thought and experimentation.