Q&A: Karen McGrane on the Importance of Adaptive Content


  • By Juliet Stott
  • May 04, 2015
Q&A: Karen McGrane on the Importance of Adaptive Content

Digital can no longer be a “carbuncle on the side of a company” says Content Strategist and Information Architect Karen McGrane. In the past 20 years she has been instrumental in transitioning major U.S. publishers’ content from print to digital. She has worked with Hearst, The Atlantic, Fast Company and Time Inc., referring to publishers as canaries in the content coal mine. MSP-C Content King Juliet Stott interviewed McGrane about the importance of adaptive content and what big business can learn from the publishers who’ve been forced to go digital.

Juliet Stott (JS): What is adaptive content?
Karen McGrane (KM): I think it’s helpful to look back toward the history of earlier Web publishing technologies. If you remember the WordPress or Wiki craze—where it was easy to put whatever you wanted in a box and publish it on the internet—content was locked to a particular page or an output format, meaning that content and styling were tied up together. In one sense those technologies moved Web publishing forward by a decade, because they made it so simple for authors to put something on the Web. But in another sense those technologies set Web publishing back by a decade, because rather than having information that was truly digital, flexible, independent, semantically rich and able to be transformed for different platforms, what you had was essentially a Web page that was just like a piece of paper. It was square, it had formatting in it and all of the same principles and values that we brought over from print. Now with the rise of all these different devices and platforms, we need to publish content that can adapt. Content needs to be more flexible, more fluid so that when you want to take it from where it was originally in print or on the Web, and publish it to a smartphone or a watch, you can do it more easily.

JS: Why do publishers need adaptive content?
KM: The concept that underlies adaptive content is not just about multichannel publishing; it goes well beyond just getting your content to work on, say, a smartphone. For me the end game is if you have truly adaptive content, it opens up a lot of other, more strategic opportunities. It makes translation and localization more possible or feasible. It makes true personalization—being able to personalize by user context, by any known business rules that you may be able to understand about that user—become possible. I think there is a huge amount of long-term strategic value that comes out of that. And having adaptive content means that organizations are going to be a lot better positioned in the future to do more interesting things with their content.

JS: Can you give examples of companies that are adapting content particularly well?
KM: National Public Radio has an approach that it calls “COPE” (create once publish everywhere). NPR needs to publish a core piece of content that must appear in different ways on different platforms. The same content is rendered one way on the website, when it’s an article, but appears in a completely different way on their player with an audio file. For both of those things, the content needs to be able to adapt to the platform.

Another example is the Lark Cookbook. It was a Kickstarter-funded campaign with the aim of publishing a multiplatform cookbook. So it was a website, a native app and also a print cookbook. Interestingly all three of those platforms were sourced from the same Drupal content management system (CMS).

Both examples show how, even though you may have the exact same content type and you may presumably have similar goals for it (such as multiplatform publishing), the way you implement a content model and use the semantic information is very different for each platform.

JS: From what I’ve read, CMS’s rely heavily on application programming interfaces (APIs). What does that mean?
KM: The reason APIs come up when talking about CMS and adaptive content is that a lot of organizations have a large amount of legacy content management infrastructure. Whether it’s a WordPress site with 50,000 pages or a large-scale site with hundreds of thousands of pages, there’s a limited ability to go in and change what’s in there. The content is not terribly malleable. To re-platform a CMS can easily be a 12-18 month project and cost hundreds of thousands, if not millions, of dollars. So often the solution, especially in times when you have a new wave of technology like mobile, is APIs. It’s middleware. These APIs can go in and talk to existing content and pull out what’s needed for the native app, the mobile website or whatever platform that you need to publish on. Many organizations are moving toward an API-first model for content management. An API model is inherently more maintainable, flexible and seen as a future friendly way of thinking about content management.

JS: Do APIs have to be built from scratch or can they be bought as an off-the-shelf solution?
KM: There’s a variety of different approaches. I am an adviser to a product called Contentful (a small scale content management start up based out of Berlin). It is an API-first product that enables content modeling and multiplatform publishing. But I also hear of organizations hacking together their own decoupled content management systems. A lot of people are talking about “headless Drupal”—essentially manipulating Drupal into a decoupled content management system—one install at the back end to manage authoring and storage with APIs coming out of it, and one install on the front end to manage display and publishing. Or having Drupal on the back end with APIs coming out of it and using Typo3 on the front end. I think there’s a lot of experimentation. In my mind this will probably be one of the more interesting things to see people experiment with in the next three to five years.

JS: Should marketing and IT teams be restructured to reflect the new skills in the industry?
KM: This is probably one of the biggest transitions we’re going to go through. I don’t think it takes a lot of foresight to see that in 10, 15 or 20 years from now the definition of what marketing is and the definition of what IT is are going to be really different. We used to treat digital as if it was this completely separate thing—like we better keep it off in the corner, somewhere in the backyard, so that it doesn’t infect our “real business.” And over the last 10 years I have worked with lots of organizations where their digital properties were essentially a completely separate business, like a carbuncle on the side of the company. Now, in the last few years, we’ve moved to a tighter but more uneasy integration of digital with traditional businesses. At a certain point there isn’t going to be a distinction between “digital” or “the website” because that’s what everything is going to be. But organizations move slowly. You’re dealing with people’s careers, with human beings. You can’t just go in and sweep everybody out and go “oh we’re done with you, now we need Web people.” I think yes, at some point in the near future the line between what’s marketing and what’s digital is going to be drawn in a very different place. I don’t think you’ll be able to have content people/marketing people who don’t have at least some grounding in the technology—an understanding of how these things get done.

JS: Have you already started to see organizations restructure in this way?
KM: I’m seeing organizations that are restructuring—they’re separating IT out. They still have IT people who are responsible for keeping the machines and the networks up and running as IT. But they are moving the other IT teams, the ones that are responsible for the business-facing, consumer- facing technology, the content management system, the publishing system and the website, into marketing. There’s this sense that this isn’t really an IT function anymore, this is a communications function. Organizations shouldn’t be pitting marketing and IT against each other—as if they are different organizations that have different goals. They have shared goals. And the shared goal is to deliver working products that meet customer expectations. That’s a huge shift in the way organizations are structured.

JS: What lessons can publishers teach traditional business about the way to output content on multiplatform channels?
KM:
That’s a great question. A simple baseline is a lot of organizations really need to get their content operations under control. There’s a lot of wasted effort, a lot of duplicated work, legacy thinking like “well this is the way we’ve always done it” and that needs to change. I think publishers are like “the canary in the coal mine.” They’ve had to adapt more quickly, needed to be more forward looking with new ways of working. They’ve have to give up on old legacy business models and old ways of doing things because the work’s being yanked out from under them. I think if there is any lesson to be learnt it’s that your business model, your way of working will not exist until the end of time. Changes will happen to your industry.

JS: What advice can you give businesses about creating content?
KM:
Do not create content for any particular platform. That is the most compelling thing I can say. You just don’t have the resources. You cannot afford to be thinking: here’s what we create for the magazine, the brochure, this whitepaper, this handout or whatever. That is antiquated thinking. You need to think holistically about what you are creating and what gets created so you can have the ability to publish it to different platforms. You can have a workflow that says here’s what needs creating and this is how it is going to work on the Web, in print, on mobile, in kiosks in the lobby or wherever else you need it to go. The only way you’ll get there, and the organization will see the value in doing that, is to stop privileging one platform over another. Think of all the platforms as equal—a content publishing process, not a print, Web and mobile publishing process. I believe that the organizations that go through that mindset shift are the ones that will survive.