Content Strategy, Drupal, Mobile, Presentations

Drupalcon Keynote

I gave a keynote at Drupalcon Portland, and here is the video, my slides, and my speaking notes, which I formatted using the convenient WYSIWYG toolbar at the top of my editing blob. My talk starts around minute 24 of the video.

I owe a lot of my success to Drupal. Let me be clear, I’ve  never installed Drupal, I don’t know my Drupal username, if I find myself on the command line it means something has gone terribly wrong. I’m not a Drupal developer. But understanding Drupal—how it thinks about content, how users interact with it—has deeply informed and inspired a lot of my thinking around the future of content. I wouldn’t be where I am today without this community. I’m not just saying this to flatter you. I’m really humbled and grateful and super excited to talk with you about the future of content today.

It’s impossible to talk about the future of content without talking about where it all got started, which was print. Print was awesome. You put the words on the paper and they stayed there. You didn’t have to worry about it changing and keeping it updated all the time. We know how print works, the techniques and cues that we use to communicate meaning, and everyone understands them at a glance.

But then we had to go and invent the web. Which, I think we’ll all admit has been totally worth it, but man is it a pain in the ass. I’m a huge computer history buff, and the web just turned 20, and reading about what happened at CERN drives home the point that the very foundation of the web: hypertext markup language and the uniform resource locator, were created for the explicit purpose of allowing anyone, anywhere, to publish documents that can be instantly updated and accessible globally. And when you take a step back from the work we do everyday to appreciate  how transformational that is in the history of communication, 20 years just isn’t even close to enough time to adapt to that monumental change. We opened Pandora’s box.

The desktop web was just the start. For the last 20 years we’ve been able to imagine that a web page is just a glorified print document.

But now the explosion of people accessing the web through mobile devices has forced us to come to terms with the ways that the web is different. Our shared hallucination that we have control over layout and presentation, that most users on the desktop had essentially the same screen size, the same input devices—that’s gone.

Now we have to adapt our content for smartphones and tablets. We don’t have the luxury of making assumptions about the user’s device type, screen size, or input device anymore. And that, more than anything, gets to the real transformation that we’re making in content. And it’s not going to stop! I’m not a futurist, I’m not here to predict what will capture the public’s imagination next. But I do know, whatever platform comes next, we’re going to have to get our content onto it.

Maybe it’s smart TV. The thought of publishing your content to a TV screen really drives home the fallacy of assuming we know anything about the user’s screen size or input device. It also starts to suggest some of the limitations of trying to handle this on the front-end. Expecting the exact same content, the exact same page, to serve a smartphone and a smart TV screen might prove limiting. I’m not saying it can’t be done, but I’m also saying this might be the point where we have to consider back-end alternatives.

I guarantee we’re going to have to think differently about content when we finally have speech-based interfaces, like in-car audio systems. It’s easy to mock audio interfaces, to laugh at Siri’s mistakes. You know what else didn’t work quite right for a long time? Touchscreens. Remember how crappy touchscreens used to be? You’d go to the ATM and you’d have to angle your finger just right to try and make it read the button press. And then one day, touchscreens worked. They worked perfectly. And it changed everything about our industry and the way we interact with these machines, in ways we haven’t even comprehended yet. I don’t know when it will happen: 5 years? 15 years? 50 years? But at some point we’re going to make audio interfaces work, and they’re going to transform human society.

And our content has to be ready to go there. Think about something as simple as the difference between the emphasis tag and the italics tag. Developers ask, what’s the point of trying to parse out when to use italics and when to use emphasis, when every major browser since the dawn of time has rendered emphasis as italics? Not in an audio interface, they don’t. One conveys styling, one conveys meaning. So, if we have that problem of separating what something looks like from what it means at the level of the most basic, fundamental tag, think about all the other issues we’re going to have getting content ready for audio interfaces—and how much better off we’ll be if we start making our content future-friendly now. It should also drive home the fact that the problem of future-friendly content and the problem of accessibility are the same problem, and doing the right thing now for accessibility will help make a better experience for everyone in the long run.

Maybe the future is Google Glass! I don’t think so, I think Google Glass will be the Segway of mobile. But it does speak to the problem of getting our content onto incredibly diverse form factors. Google released their UI specs for Google Glass specifying the HTML templates they want you to use—if you designed your content around your presentation, will it be appropriate for their presentation?

Maybe you’ve heard the next big thing is watches. This isn’t a real product, it’s an artist’s rendition, but both Apple and Samsung are rumored to be developing watches. Maybe you don’t want to read a long document on your watch screen, but maybe a combination of an accessible wrist touchscreen and a wireless audio interface would work really well, If you have content that’s structured to support both reading and listening. Watches are tiny, maybe they’re not the next big thing, maybe it’s…

Stadium scoreboards! Get your content where everyone can see it! I put this in here as a joke, just to contrast the size of the watch with the size of the scoreboard, and then I turned around and I had a client tell me that one of their biggest problems right now is…

Digital signage. A university I’m working with told me they’d just purchased a bunch of digital screens they want to put up all over campus, and they need a way to manage and publish content to them. I asked “Are you just going to treat them like a separate workflow and manage the publishing process manually?” And they said “No way! We don’t have time for that! We need a way to publish events listings and campus alerts automatically to the website , our mobile app, and the digital signage.” They need a way to manage content in one place and have it publish to three very different platforms automatically, and they need to do this right now, today. This isn’t some crazy futuristic dystopia, this is real.

Maybe you’ll want the same thing some day in your home. Seems like whenever we talk about the future, we talk about the internet refrigerator, as if not being able to check email or Twitter during the 30 seconds it takes to grab a Diet Coke is the biggest problem we face as a civilization. But what about if your entire cooktop was a giant iPad screen? Would your text, video, recipes be ready to go there? What about the problem that I do think is one of the biggest challenges facing us as a society, which is…

What happens when toaster printers become reality? Will your content be adaptable enough to appear on delicious toast? These are the problems we are here to solve together.

Today, our content already has to live on many different devices and form factors and screen sizes. Tomorrow, there will be even more new devices, some we haven’t even dreamed up yet.

This isn’t just a front-end problem. It’s a CMS problem. I want to be careful about how I say this, because people get religious, but responsive design is just one technique in our arsenal for how to survive this zombie apocalypse of new devices and form factors. The future of content means changing the way CMS works. We need both front-end and back-end solutions.

True separation of content from form

Because future-friendly content requires true separation of content from presentation. We have to support too many different outputs for content to assume that we can couple content with presentation. Do you have any idea what a huge shift this is in the way we think about content? For most of human history, it was impossible to produce a document without considering meaning and appearance together. All of our semantic cues as to priority, weight, relationships in content come through visual styling. But now we need new tools, new processes to achieve that.

It’s easy to think when I say “separate content from presentation” I mean “get your HTML out of my content,” like “get your chocolate out of my peanut butter.” That’s a part of it, but it’s really only the tip of the iceberg.

When Dan Jacobson, the API guy from Netflix and formerly NPR says “The future of content management systems is in their ability to capture the content in a clean, presentation-independent way,” it’s really tempting to reduce that to a problem with markup, to think that we can solve the problem just by getting rid of rich text editors.

Personally, I talk all the time about the limitations of what I call blobs, of giving content creators a big bucket into which they can dump whatever they want, style their content with tools that work “just like Microsoft Word,” add tables and custom bullets and make the text purple Comic Sans and float it to the right. Blobs are limiting, because all of this formatting, all of this meaning doesn’t translate when you try to take it to another platform.

I’ve gotten the reputation of being the president of the WYSIWYG Haters Club, which is true, and if you don’t buy into my rationale here today…

I’m going have to continue my graffiti crime spree. People assume I must be some kind of markdown evangelist. The problem isn’t the toolbar. Truth is, I don’t care if users make headings and bulleted lists with a toolbar or markdown codes. The problem with WYSIWYG is that we are allowing content creators to treat the web like it’s print.

Where do you think WYSIWYG came from?

It came from XEROX. Xerox PARC. Because they invented the laser printer. Think about that for a moment. Before the laser printer, Xerox machines could only make copies of an existing document. They invented a way that you could print out anything you wanted. But they needed a way for you to actually create that document. They didn’t invent the laser printer because they figured out WYSIWYG. They invented the graphical user interface and the concept of “what you see is what you get” because they invented the laser printer.

The laser printer was arguably the most important component of the desktop publishing revolution, and a lot of work went into ensuring that the bitmap rendering and printer drivers were in sync. The tools for content creation and the tools for content output were tightly coupled. You can directly peg the adoption of graphical interfaces and thus the personal computing revolution to the demand for laser printers.

Guess what. The web’s not a laser printer. The problem with WYSIWYG isn’t that we have a toolbar on the top of the screen. The problem is that we are using an antiquated metaphor from the desktop publishing era to communicate to content creators what it means to publish on the web. That model was okay — like training wheels — when all we had was the desktop. But now it’s the future.

Chunks of content get remixed on the fly. Different content chunks appear on different pages, on different platforms. Which chunks appear where is subject to a complex set of metadata-driven business rules. The job of the content creator in this environment is changing, needs to change. Our job is to build new tools, new interfaces, new metaphors that help them understand that. This is tough fight. It’s a battle. It’s a war.

It’s a war of blobs versus chunks: sloppy blobs of where there’s no distinction between content and form versus clean, flexible, presentation-independent chunks. But this war isn’t about markup. It’s about mental models. It’s a fight between the old, outdated processes and metaphors of content publishing derived from print versus the new approaches we have to start inventing now if we’re going to survive the future. This is why I’m so excited to talk to you all. You guys are Chunk Army. It is time to go to war against the blobs.

Here’s our battle plan, Team Chunk:

  • Content has to be structured. No more relying on a giant field that says “content goes here.” We have to work with content owners to model their content types and define the structures needed to deliver content, especially if it’s going to different platforms.
  • Find ways to communicate meaning that’s encoded in visual styles. Presentation and formatting has to be replaced with semantic metadata.
  • Authors need to be able to maintain all the content objects and metadata associated with a content type in one package, not attached to individual pages. Then, those objects must be able to be targeted by platform.
  • All of this means we have to create a different kind of author experience, a new user experience for content creators.

Structured content

You guys know how structured content works. I know Drupal isn’t a blob CMS. The challenge is breaking out of the page-based mindset to figure out the right level of granularity so different content structures can adapt to different platforms.

Here’s an example from Amazon. Now, Amazon already has a pretty well-structured content model for their products, that’s not their problem. The problem is figuring out whether the existing content structures will support new platforms, and what to do if they won’t work. Even just looking between the desktop and the smartphone form factor you see the questions that arise:

  • Not every object from the desktop should be used on every platform. How do we decide what to keep and what to exclude? If we exclude it on one platform, does that mean it should be excluded from others? If not, how do we target content by platform?
  • If you handle this transformation on the front-end, there must be a one-to-one mapping between a page on the desktop and a page on mobile. Sometimes that works, sometimes that doesn’t. The page is a container, and how much you should put in that container might vary by platform. Amazon decided to break a long product page into a series of shorter pages on smartphones.
  • That means that text that was previously used as headings on the desktop are now used as navigation links. The headings Product Features, From The Manufacturer, and Product Description aren’t sufficiently differentiated. If I have a question about the product, I can’t tell from those three options which one to tap on to get the answer.
  • Same thing with the body text that gets truncated for the teaser. Each summary just repeats the product name and the zoom and megapixel features listed in the title over and over. They don’t convey any new information and they don’t tell me what I’m going to get when I tap. Pretty much every word on this screen is wasted.
  • Cross-platform images is a whole nightmare unto itself I’m not even going to talk about.
  • What happens with giant tables, giant infographics, Flash videos, content in hover states?

I gave a talk recently where I outlined these challenges and a woman raised her hand and said “We’re going to use responsive design.”

Responsive design is not gonna fix your content problem! Responsive design doesn’t answer these questions for you. Another way to put that is, whether your solution is client side, server side, or a combination, you still have to make the underlying choices about how content is structured.

Semantic metadata

The second problem we have to solve is figuring out how to replace presentation and styling information that describe what something should look like with semantic metadata that describes what something means. LIke everything else I’m telling you, this isn’t a technology problem, it’s a human problem. We’re going against centuries of history where people relied on visual cues to communicate meaning. We have to replace styling choices with something more adaptive so that the author’s intent can make the leap to different platforms.

Back in the 1980s TV Guide was the most popular magazine in America. Don’t ever let anyone tell you Americans don’t read. If TV Guide had thought of themselves as a just a magazine , they might have been okay with just publishing program descriptions on paper. In print, data like the program name, genre, length, network, even the actors was encoded solely through visual styling, making text bold or all caps. But if all that data were locked up in Quark files with only visual cues to tell you what it meant, it doesn’t have any value. TV Guide realized they weren’t in the magazine publishing business, they were in the content publishing business. So way back in the 1980s they built a green screen mainframe application to capture all of this content with appropriate semantic metadata, which means that their content has stood the test of time. If you see a program description on your cable box or your TIVO or your iPhone for a show that originally aired the 1980s, it’s the exact same content that was published in the magazine decades ago.

The Guardian faced a similar challenge when they launched these things called Topic Pages. All the content that matches a particular taxonomy term or proper noun, like Tony Blair, gets automatically aggregated. They’re great for SEO. When they first launched these pages, they had a prominent box for Top Story. Problem was, they realized they had no way of knowing whether one story was more important than another. When the content from the print edition hit the CMS, there was no priority metadata attached to it. For this output, they decided to handle it by asking their editors to do more work. The editorial team had to manually assign a priority rating to to each story, 1 to 5.

Thing is, they have a ton of information about editorial priority. It’s all conveyed through the layout of the print edition. You can discern editorial judgement at a glance by looking at this page, picking up on cues like the size and styling of the headlines, the number of columns and column inches dedicated to the story, the size of the image, the layout and placement on the page. When it came time for them to publish an iPad app, they did something different. They wrote an algorithm to read the layout of the print edition, derive editorial priority metadata, and then use that data to determine hierarchy and placement of stories in the iPad app.

I want to be clear— I do not think the future is artificial intelligence backed Dreamweaver, where content authors can apply whatever styling they want and then robots will figure out semantic metadata on the backend. Newspapers have a clearly defined visual language and hierarchy, so it’s possible to make inferences about meaning from styling; small business owners or government employees sometimes make random styling choices for their websites that can’t be accurately parsed. I tell this story to just to illustrate what it means to make the leap across platforms, and how we can’t rely on styling decisions made for one platform to communicate meaning on a different platform.

I love these two quotes: “Metadata is the new art direction” and “Metadata is a love note to the future.” The first reminds us that the approach we used in print, where an art director made layout choices for every page, has to be replaced by a new, dynamic approach that works for the web. The second tells us that the effort we put into adding metadata to our content today is what will give us a head start when we need to get it onto a new platform in the future.

Content packages

Third problem we need to figure out is how to support content authors who will need to create and manage content chunks that will be dynamically published to different platforms. Authors must stop thinking about making web pages and start thinking about managing content packages. They need interfaces that allow them to create and maintain the content elements associated with a particular content type in one place.

NPR “COPE: Create Once Publish Everywhere” gets talked about in regards to their API strategy, but I like to use it as an example of a content package.

Each “article” content type has all these different elements associated with it. It has a headline and body text, but it also has an audio file, it has two different sizes of teasers, it’s got multiple images.

The content producer gets a single interface to create and manage all those content objects in one place. Each individual platform can make its own choices about which content elements to display. Too often, we have content that is attached to particular pages, like a marketing headline and product tout that “lives” only on a landing page. Content can’t live on pages anymore. Instead, we need to manage content packages.

Author experience

This is the kind of author experience we need to create: one that encourages content creators to add the appropriate structure, use semantic metadata rather than visual styling, and manage packages of content elements that can be dynamically published to multiple different places.

I know what you’re thinking: content creators hate all this! They beg for a blob with a WYSIWYG on it, they want it to work just like Microsoft Word. You’re trying to do right by your users by giving them what they say they want. Thing is, UX doesn’t work that way.

All these people are driving buggies, and we’re building cars. When you ask them what they want, they say they want it to work they way they’re familiar with, they want faster horses. This is a quote popularly attributed to Henry Ford, he didn’t actually say it, and I don’t care. It gets quoted frequently because it captures the challenge  we face getting people to adapt to new technology. We have to give them what they need, not what they say they want. We have to give them new tools, a new mental model, of how publishing works on the web.

You know who else had to change their mental model based on how the web works? Graphic designers.  Classically trained print designers had to radically change their tools, their process, and most important, their underlying values system to adapt to the web. I have watched them succeed. They gave up pixel-perfect layouts in favor of embracing the fluid, flexible nature of the web. If graphic designers can do it, content creators can too. But we have to help them. We have to stop building them faster horses, and instead embrace the multi-device future.

And this brings me to the subject of: In-place editing. You guys didn’t think you were going to get through the entire talk without me mentioning this, right? I want to preface this by saying I’m not categorically opposed to this as an editing interface. There are specific albeit limited scenarios where this can benefit content creators. But it’s not a usability panacea.

The problem is, at the very moment when we need a new metaphor, a new mental model to convey to users that their content will appear in a variety of different contexts, you’re encouraging them — forcing them — to imagine that the “real” version of their content is the desktop website. I’m delighted that you’ve made the Drupal admin interface responsive, but allowing users to do in-place editing from a mobile phone is not the solution to this problem.

I can tell just by looking at it that in-place editing was an idea ginned up by someone in marketing as a way to make Drupal seem easy to use. Which isn’t the same as actually being easy to use. I’m sure it looks great in sales demos, but when your shiny new feature has its collision with the real world, you’re going to discover it doesn’t necessarily solve usability problems. In some cases it’s going to make them worse. It will make the author experience even more confusing, particularly for users who need to understand the underlying content structure and metadata.

The future of Drupal UX

So, if that’s not the solution, then what is? If there’s one thing I am thoroughly convinced of, from all the work I have done in this space, it’s that there is no one-size-fits-all approach to content management. There is no perfect author experience that will work for every content model, every company’s workflow. And that means that the future of Drupal UX…

Is you. You were hoping I was going to say robots, right? No, you are the ones making decisions about how your content creators interact with the admin interface you create. You are the ones making choices about the content model and metadata. And you are the ones who will invent the future.

This isn’t a problem that gets solved in Drupal Core. There’s a lot of great work being done to make the framework better, but the real magic is in the decisions that you make about how to customize the interface and workflow for content creators. Drupal gives you unparalleled flexibility. It’s your job to use your power wisely.

The theme of this conference is “building bridges, connecting communities” which is why you invite someone like me from an outside community like content strategy and user experience to give a keynote. There’s maybe some fear that I’m going to use my time like an hour-long informercial for my discipline, and lecture you about how you need to hire UX people.

I’m going to do just the opposite. Don’t get me wrong, many of you would benefit from partnering with UX and content strategy people, they’re great, but I’m here to help you help yourselves. I’m here because I want to show you the bridge TO my communities, if you want to take advantage of what we can offer you.

You are a content strategist. I guarantee you are doing content modeling, even if you don’t call it that. Maybe you should. Maybe you could charge more money for it. The content strategy community has lots of people from the content management space participating. They have all kinds of resources that can help you get better at structuring content and planning the content lifecycle. If you want advice on getting better at doing this work, they will welcome you.

Sara Wachter-Boettcher’s book Content Everywhere and Ann Rockley’s book Managing Enterprise Content are two indispensable resources for people trying to solve the problems I’m talking about. If you wanted to buy my book Content Strategy for Mobile that would be very nice of you but I promised no informercial

You are an information architect. You are making decisions about categories, taxonomy, navigation, and labeling on your projects. There are lots of resources out there to help you do a better job at that.

Lou Rosenfeld and Peter Morville’s book Information Architecture is a classic in the field. Donna Maurer’s book on Card Sorting is a short, straightforward book that will teach you a simple research technique to figure out the right categories and labeling for your interfaces. You can do this. It is not time consuming or expensive, and it will make a better author experience.

The information architecture community wants to reach out to people like you. Lou Rosenfeld, the author of the seminal book on the subject and the publisher of most of the other books I’m sharing here — his stature in the IA community, he’s like our Dries — threw down a challenge to the IA community recently that we need to focus on the 95% of people who don’t call themselves information architects. That’s you.

You are a UX designer. You are, right now, designing the interfaces that people have to use to do their jobs. I don’t necessarily mean that you’re an amazing visual designer or interaction designer for the front-end. (Or maybe you are. I don’t know your life.) But I do know that the choices that you make in how the Drupal admin interface works means you design user experiences. You design the experience for the most important user, the content author.

You actually have two things that make you incredibly powerful as a UX designer. My user experience peers all wish they had what you have. First, you have access to real users. They’re your clients and co-workers! They’re the people you work with! That may not always be the case, but I would assume the average Drupal developer gets way more time with the  people who will be using the system you create than the average UX designer does. Which leads me to number two, Drupal is a powerful prototyping tool. I have seen it in action. You can create real, functional interfaces, possibly even working with real content, in less time than I can make a wireframe.

So start teaching yourself how to be a better UX designer. Learn the techniques that make interfaces easy to use. Learn how to prototype and test and iterate. The world needs you to have these skills. They’re not just for my community to have. I’m going to tell you a little secret. I’m convinced that some really innovative ideas for how to model and manage future-friendly content are going to come from the Drupal community. You have a fantastic platform to build on, you just need to frame the right problems.

Let me leave you with this.

The web isn’t print. We’ve got millennia of history creating print documents where there’s no distinction between content and form, and only about 20 years of web publishing experience. This is a Gutenberg level transition we’re going through here.

The tools, interfaces, and processes we use to create content must evolve. We can’t rely on print-based metaphors that tie our content to pages anymore, whether those are sheets in our laser printer or web pages on our desktop. Our content can and will live on lots of different platforms, and it’s our job to help content creators understand how that works.

This community is so well positioned to tackle this problem. You have a powerful, flexible framework. You have an innovative community of people. And you have access to real users so you can prototype and test new interfaces. You are designing the user experience for the content creators. Start thinking like a UX designer, start thinking like a content strategist, and invent the future.