The Future of Content: Context-Aware, Centralized, and Written by Robots

>> SPEAKER:  Perfect.  Lovely.  Okay, well, welcome, everybody, to the future of content.  My name is Todd, I'm from Austin, it can, and I run a small digital agency called Four Kitchens.  We build digital experiences and platforms that scale delight and deliver measurable results.  While we specialize in Drupal for 14 years, we work with a wide range of content management systems, architectures and devices, so to put it simply, we make big websites.  So, I'd like to start with a story.  Once upon a time, there was a fridge, and it had one job, to keep things cold, and it did its job fairly well.  Fridge Co, the company that built that fridge, was doing fine too, but they thought they could do better, so one day, as they so often did, the Fridge Co product team gathered to brainstorm.  How could they differentiate themselves from the competition?  Well, the product manager, who was tired of hearing the same old ideas, like bigger capacity, more energy efficiency, more shelves, there wasn't anything new, there was nothing really exciting, it seemed like they'd had this meeting a hundred times before, and, of course, they had.  Meanwhile, somebody across the table was looking at his phone, bored, and watching him rudely tap at the screen during this meeting, she was suddenly struck with a totally new concept, let's connect it to the Internet.  Silence.  A fridge connected to the Internet?  Asked the guy with the phone.  Yes.  That sounds ridiculous.  No, she said, it's the future.  It'll have a big, bright color screen, it will support apps, just like your phone, and we can partner with recipe websites and integrate Google Calendar, um, Twitter's big, right, let's put Twitter on the fridge, and so it was that Fridge Co ushered the humble fridge into the information age.  

Now, I have no idea if this is how it actually happened, but somebody did put the Internet on a fridge, and this is something you can get right now.  Seems plausible, right?  So, imagine now that it's ten years ago, 12 years ago, the iPhone has basically just been released, and you're a software developer, you get a call from Fridge Co, and they want you to make their vision a reality, putting the Internet on a fridge.  Back then, how would you go about implementing something like this, 10, 12 years ago?  Well, I imagine you'd probably have to build a software development kit, and you'd have to devise your own set of standards for building apps for your fridge, and you would have to document that in some kind of proprietary, um, community space that you create for all of these other, um, providers, like Google and Twitter and the rest and then build apps and, of course, competitors would be sure to follow, and then Fridge Co, because they want to maintain some proprietary edge, they're not going to create an open standard, no way, so they create this proprietary platform, and, of course, so does everybody else.  

So, let's sit on the other side of the table for a moment, let's make it a little more complicated, let's say you're a grocery delivery service, and you want to plaster your app across all of the fridge brands, so building an app from scratch for each individual, um, fridge is a daunting task, right?  So now, you're going to have to manage, what, five different apps, ten different apps, 20 different apps, to all work on these competing fridge brands, and, of course, meanwhile, you're having a hard time just getting your iPhone brand out the door, because that's a brand new thing too.  Looking ahead to today, where we're at right now, this is not that hard, if you have the right technologies and work flows in place.  If you've centralized all of your products, your content, into a single consistent data model, and if you've made that information available using a robust API, you can rapidly develop apps for all kinds of devices that currently exist and those in the future.  So, what seemed like a crazy idea ten, 12 years ago, putting the Internet on a fridge is almost trivially easy today, and that's not because we got really good at making fridges, it's because we've created all of the infrastructure needed to rapidly adopt new technologies, whether they're fridges, streaming devices, home assistance, anything.  

Today, right now, we expect our digital interactions to span a variety of experiences and context.  We are reading, watching, and listening to content.  We're doing this on different devices, different situations, and with different needs, like looking up recipes on a fridge.  So, before we start, I'd like to define a couple of concepts.  Experience.  Experience is what happens inside the content.  It's the medium of the content itself, text, video, sound, whatever, and the message it delivers.  Context is everything outside of the content, it's the device you're using, it's the operating system, it's your web browser, it's the physical environment you're in, it's your history with that brand, it's the needs that you're trying to meet, it's the mental model you're using to compare this content to other content you've experienced, and so on.  Context is everything surrounding and influencing the content experience.  So, to illustrate this, think about watching a movie.  Watching a movie is an experience, just the movie itself.  It is a movie, it's a series of still images played in rapid succession that make it look like there's movement, and there's a plot, and there are characters, and there are dialogues, that's the experience of the movie, but how you watch it is the context.  Watching it in a theater with your kids or watching it on your phone while traveling to a conference, or watching it, as we now are doing, curled up on your sofa with your dog, these are contexts.  

So, today, I'm not going to talk much about experience, I'm not going to talk about the content itself, you know, plots and stories and words and usage and all that, I'm going to be talking about context, everything surrounding the content.  With this in mind, I'm going to make eight predictions about the future of content and where we are headed next.  So, let's start with prediction number one.  CMSs will be content repositories, not website managers.  So, to explain what I mean, we need to go back in time a little bit.  Let's think about the 1990s.  We had flat files, front page, geocities.  In these days, content was directly tied to presentation.  They were fully the same and hard‑coded files.  Desktop publishers, like Front Page and Dream Weaver, helped us to manage those files.  Then in the 2000s, web‑based CMSs came along.  Drupal in the year 2000, Word Press and Dot Net in 2003, YAML in 2005.  These were pieces of software that you installed on a web server that allowed you to manage your content, but also display the content.  And these CMSs were a single piece of software divided between the front end, the display of content, and the back end, the management of content.  

So, first, we can display this content in a web browser.  So, here we are, looking at it on a laptop or a desktop, and then came, um, feeds, RSS, and Adam, and these feeds allowed us to syndicate our content to other sites.  Then, in the mid/late 2000s, smart phones and tablets and, of course, these ushered in the mobile revolution and changed our approach to how we do front‑end design, but it didn't fundamentally change our approach to content management.  Meanwhile, on the back‑end, the CMSs were storing text and media and user‑generated content, like comments and profiles, and as they became more popular, the web admins started demanding more back‑end functionality, because they wanted to be able to better manage things like users, their permission levels and what they're able to edit and not edit or see or not see, and then, of course, these web admins wanted different kinds of layouts, they wanted flexibility in creating articles and posts that look different from one another, and then, of course, integrations, we wanted to start attaching things like CRMs and learning management systems and single sign‑on and all of this, and, of course, everybody wanted it to be configurable from a central UI, and all this gets packed into the CMS, and this made our CMSs heavy and complicated, and CMSs were fundamentally no longer really about content management, they were about website management, so managing your commerce platform, um, fundraising campaigns, communities, and I'm sure many of us in the room remember when Drupal called itself a, quote, community plumbing tool.  It wasn't a content tool, it was a community plumbing tool.  

So, more recently, um, we're seeing a proliferation of more and more devices, apps, channels, and these devices have introduced new technology, like location awareness, they've introduced new interaction patterns, like touch, gesture, voice commands, and the apps built for these devices have created entirely new expectations of user friendliness.  We've created this mindset in which everything is an app or has app‑like capabilities, and we've also seen new channels for publishing content and engaging users.  So, media companies, for example, now have to contend with things like Facebook, Apple news, and all kinds of other off‑site distribution channels of their content.  More and more people are consuming content all these third‑party sites rather than going directly to the source.  So, in our scramble to keep up with all of these new devices and experiences and all of this, we keep spinning up new websites and apps to satisfy our short‑term timely business needs, and all of these new end points often duplicate content, code, and effort.  So, not only does this greatly increase the cost, it leads to inconsistent, bare bones, and just plain bad experiences for our audiences, as I'm sure many of you find yourself in this position now, where you're managing a whole suite of websites, often on completely different platforms.  So, we've heard a lot about decoupled architecture and centralized content, and I'll just do a very brief explanation on this.  

So, we're already seeing a shift to, um, this more agile approach to architecture, decoupling the CMSs and then centralizing the content management.  So, for those who aren't entirely sure what decoupling means, here's a very brief intro.  Here, we have a traditional CMS, it includes both the front‑end, the display of content, and the back‑end, the management and the storage of content.  So, imagine that we separate these two things, and each is a separate piece of software that focuses on a specific task, to display or to manage content.  The resulting architecture is decoupled, or as some people call it, headless.  When we talk about the front end, we most commonly mean your website, so the front end is, um, the thing that you see when you go to that URL, and when we talk about the back end, we usually mean content and all the stuff that's associated with it.  So, let's just go ahead and label those things appropriately, website and content, and these two things are connected by an API that pulls content from the database and turns it into markup, and this is exactly what happens when, um, Drupal gets a page request and pulls something out of the database and pulls it all together and throws it to the theming layer and, boom, now you've got something that people can see on a website, and it's worth noting that you don't need to rebuild your CMS to de‑couple, and here's just an example of that.  In the last year, we, um, we decoupled PRI.org's home page while keeping their underlying site on Drupal 7.  We didn't have to completely re‑architect the site to do this.  Interestingly, a side benefit of decoupling is that the team that's doing this work, um, gets to work with more widely understood code and design patterns, so if you're decoupling and building something in React or whatever, um, you're just working with Javascript, CSS, and markup, and one of the project leads on this PRI project said it was the first time in years that their team had enjoyed working with the code base, so side benefit is there are more people that have the skills to do this, so they don't have to learn things, and, um, it's lighter weight.  

So, back to the decoupling, when this is setup, when your site is decoupled, you can centralize your content, meaning that you store all of the content in a single place, regardless of how many websites it appears on, so then you can start to attach different sites to your content repository, so perhaps you need a micro site for a specific market or campaign, or maybe you want to create a blog for a featured author or an esteemed faculty member at a university.  If all of this content is stored in a single place, you can split up all of these different front ends, attach it to the API, and all the content is in one place and it's shared.  This is content centralization.  Predict number two is that content will become extensible and modular.  A modern CMS does not treat the website as the primary experience.  Modern CMS is multi‑device, but it is not designed for specific devices.  This means that you have to think about content first, not the website, not an iPhone, not a Roku streaming box.  You should let your CMS deliver structured content and then let that device's software or app handle the rest of the work.  So, if your content is properly modeled, if you have reusable fields and robust content types, you can very quickly support new devices and experiences.  One of the things that makes Drupal particularly great is the ability to add new fields and new content types.  

So, let's say, here, we have this, um, infrastructure that we've been putting together, let's say that you want to add, um, location aware data, because there's big demand for an iPhone app, um, and you know that your content can only be shown or licensed in certain areas, certain geographic regions.  Well, you start with the idea of I want an iPhone app, and I want people to stream video, and we need to know where they are so that they have the right content license to view this video, but rather than thinking about this as adding an iPhone app, you should be thinking about this in terms of I am adding location awareability.  So, when I add this ability to figure out where somebody physically is in the world, don't think of it as I'm making an iPhone app, think of it as I want to know about location, and I need this content to have information about location attached to it, and once you've done that, you are now able to support all location aware devices, not just an iPhone app, so Android and all kinds of other things, things that might be built into cars in the future.  Same thing with video, so, okay, Roku is the most widely used streaming device, um, so, of course, maybe, that's the first thing that you want to build an app for, and that's going to require adding new kinds of meta data fields to your video content and video assets.  

Well, you should think about building those fields and those, um, meta data as not just applying to Roku, but applying to any streaming device or even service, so YouTube or Vimeo even, as well as Apple TV and Samsung smart TVs and things like that.  Let's say you want to do a conversational interface, well, you will add conversational fields, but they don't have to be specific to Alexa or Google Home Assistant or Siri or anything like that.  Um, and then, of course, you're going to want feeds, and feeds can be very similar to, um, accelerated mobile pages, and so you kind of get a lot of this stuff for free, in a way, if you're thinking about your content model robustly, and, of course, in the future, all of these front ends are first‑class citizens, and that means content has to be modular so it can be assembled and delivered to somebody based on their context.  So, for example, you might want shorter titles for social posts, you may want to deliver audio clips for audio devices, but a text transcript for, um, devices or experiences that cannot take advantage of an audio clip, and with this centralized content model, you can add additional fields or content types rather than having to build a separate system or installation for every new device or use case.  A great real‑world example of this is NBC.  We've been working with NBC for many, many years, they have a lot of content, and it has to be delivered across many platforms.  

So, rather than building multiple solutions for multiple devices, NBC just wanted one single content API, and the same infrastructure and content that powers NBC.com also powers Saturday Night Live, the SNL iPhone app, Android app, all kinds of other things.  This decoupled approach allows them to rapidly develop for streaming devices, to see, like, hey, would somebody use an Alexa skill if we built one, so that's what we did.  Here's how we did that.  Um, so, NBC wanted an Alexa skill that would just respond to very simple questions, like, hey, when is The Good Place on?  So, we already have a show time field, and it looks like this, because, um, you know, television commercials, and I guess this is a TV guide, um, formatting system that was developed, 9/8 C, that means 9:00 eastern, 8:00 central.  Well, if that's read aloud as such, Alexa experiences this as 98C.  That doesn't sound right, of course.  So, we created a new field, show time spoken, and we actually spelled out the word central, instead of using the abbreviation, so, of course, it reads 9/8 central aloud.  So, you're probably asking yourself, why didn't you just alter the Alexa skill to know that the letter C in this field is supposed to be read, quote, central.  The problem with that approach is that it shifts the burden to the device in the app, and it's not sustainable, because now, we have logic that has to be carried forward to every audio and conversational device that is built from that point forward.  If we, instead, fix the problem inside the content by making the content model more robust and having a separate field for spoken aloud, where we just spell the word out, we can much more rapidly adopt and more simply support all of these audio devices in the future.  

So, what does this actually look like to a content creator, somebody who's making this content?  Content, on the content creation side, editors in the future and today will routinely work with, um, content in the form of blocks or components, so, of course, in the Drupal world, many of us are using the paragraphs module, and we call it paragraphs because, of course, the term blocks is taken in our name space, and the, um, project page has this very helpful illustration of what a reader or visitor sees versus what an editor sees, so we have these, like, literal paragraphs of content that are text paragraphs, but then we have inline images that have their own meta data associated with them, we have video with our own meta data, and these can be assembled and shuffled and all of that.  We see this in the Word Press world, this is the Guttenberg editor.  It's built on the idea of modular content, so these content blocks are edited separately, they're reordered and they're assembled into a very clean interface.  Now, of course, there is a Drupal Guttenberg.  Prediction number three, content creators will finally get the tools that they deserve.  So, as paragraphs in Guttenberg and other interfaces demonstrate, there is an explosion of interest in creating better editorial experiences.  Coupled with the need for modular content, this has led to very new ways of thinking about and assembling content.  

So, I suspect that we will see a similar interest in stand‑alone CMS agnostic editing interfaces.  By that, I mean a piece of software or an interface that can be attached to any CMS that an editor or content creator simply prefers, so these could theoretically replace the out of the box editing tools provided by CMSs.  While this adds some complexity to your software stack, of course, it's going to be relief for people who are tired of hearing that, oh, we picked Word Press because our editors prefer the user experience, right?  Why not just have a Word Press style editing experience in another CMS?  We can just port that over.  That's what I mean by content creators getting the tools that they deserve.  So, meanwhile, um, we're seeing some hosted content services, like gather content, and we're going to see these compete for the best editorial experiences outside of traditional CMSs.  That will likely be the thing that will make somebody pick one of these services over another.  So, gather content, which is shown here, is really focused on content management at all levels.  It can be content work flows, content governance, campaign management, and they market themselves as a content operations hub, or content ops.  Contentful, meanwhile, has positioned itself very clearly as an API‑first, and they would expect you to provide your own front‑end.  Continuing along the line of thought about, um, content creators having a better experience, a very common complaint that we hear from all content producers is the inability to preview content before it goes live.  So, here, we have tools like Gatsby preview, that allow people to, um, preview content before it's actually published to the site and goes live.  

So, here's a quote from the Gatsby preview website; our new preview feature is like a private playground for developers, designers, and content creators.  Gatsby provides a shareable, temporary URL for viewing changes immediately and in context, so you can make sure that new headers play nicely with the rest of the page before hitting publish.  That's the end of the quote.  What they're referring to, um, when they say in context is, like, what device are you on, what browser are you using, what are you trying to accomplish.  So, we now see, and, of course, Gatsby preview can be integrated with Drupal.  We're also seeing, um, some really interesting new ways to make existing CMSs more editor‑friendly without having a developer make changes to a code or template, so an example is, um, DX8 from Cohesion, which is built on Drupal.  Its goal is to reduce the amount, um, of development needed to produce great content and user experiences.  Pardon me for just a moment.  There's a slide error that I need to fix.  Okay, sharing my screen again.  All right, and another example is Emulsify.  This is something we built at Four Kitchens.  It allows developers and editors to quickly assemble content and prototype new layouts.  It was released in spring 2017, and after less than three years, it has almost a hundred thousand installations, and I say that only to illustrate the demand of tools that enable content creators and designers to, um, do things more efficiently, more quickly across teams.  

So, looking ahead, content creators and designers are going to expect much more from their tool sets, that includes their CMSs.  So, for example, a future version of Emulsify will include a living style guide that serves as both a reference for design patterns and the actual code, the markup and the CSS that powers the site.  Prediction number four, um, CMSs will focus on specific verticals and use cases.  So, we've already seen some specialization, we've seen marketing automation platforms arise, newsletter and e‑mail management tools, campaign management platforms, all kinds of stuff, right, and each of these are especially strong in some verticals, like non‑profits or associations or higher education, but what's really interesting, um, related to content is the rise of CMSs specifically targeted to media, entertainment, and publishing.  So, here, we have Thunder, thunder is a distribution of Drupal that was created, maintained, and used by Hubert Media, which is one of Germany's largest publishers.  Here, we have Arc Publishing, this is the CMS that powers The Washington Post, and since the, I don't know the exact order of operations here, but since Jeff Besos acquired The Washington Post, they have moved very rapidly to, um, monetize their CMS and start to license it out to other publications and other news rooms, and it is worth highlighting that they are specifically targeting news rooms.  Their angle is that Arc is not so much a content management system as it is a news room management system, and that's very, very appealing to a lot of publishers.  We, of course, also have Chorus from vox Media, so the Vox Media Group has packaged their CMS, and they're offering it on a license basis as well, and according to their website, they say that Chorus is the only all in one publishing audience and revenue platform built for modern media companies operating at scale, close quote.  So, they are targeting content monetization, that's what they're trying to do with their messaging here.  

So, we've seen things like Arc, news room management, Chorus is a content monetization platform, we're seeing the angles that different CMSs are taking to explain their value.  And another really new interesting trend that, um, is worth talking about is the rise of Brightspot.  So, NPR and other large public media entities have decided to standardize on the Brightspot CMS, and I don't have all of the details about this, because these conversations have largely been happening behind closed doors within the public media world, but, um, from what I've heard, they are creating a custom distribution of Brightspot that they're calling Brove CMS, and it's going to be built to meet public media's specific needs and use cases.  Public media's use of Drupal has been slowing for some time, and the decision to standardize on Brightspot, it will likely further contribute to this trend.  So, there's a sub‑trend, notice here, and that is that all four of these CMSs were created or funded by large media companies and made available to the public through open source or proprietary means.  So, that means that publishing companies are also becoming software companies, and they're trying to reduce or recoup their costs by releasing their internal product.  We'll probably see this continue to expand in the future.  

Let's talk about robots.  So, prediction number five, machine learning will help us manage and create content.  We're already at the point where CMSs can read, see, and hear your content.  This is a paradigm shift, but it's happening in the background without people being aware of it.  So, think for a moment about how Google has, um, this eerily accurate auto‑complete feature as you write emails, that's because it is looking at the many years of data it has about you and how you write and your word usage and all of that and, um, it's learning to sound like you.  That's just one example of hundreds or thousands of ways that machine learning is being, um, implemented in a content creation capacity.  So, in the future, your CMS is going to feel out of touch, if it doesn't have a deep understanding of your content, but, luckily, as machine learning grows in popularity, it will become less expensive, and it will become much easier to install and setup.  So, I do imagine that there will be an out of the box feature or easy addition for machine learning at some point in the relatively near future.  So, before, when you were dealing with media management and content and all of that, you had to tell your CMS where the content belongs, right?  This belongs in the blog, with these tags, or this belongs in this section, and it's a sub‑page of this thing and whatever, but with the help of machine learning, your CMS can add those meta data to the content and perhaps put it or store it more quickly and more accurately than you can, and this is especially true of media management, of images, videos, sound files and so forth, machine learning can elevate basic CMSs to the level of an enterprise digital asset management system.  

So, image detection can auto‑tag images, and that allows editors to search these image libraries and provide accessibility meta data, for example.  Natural language processing can create transcripts of video and audio files to improve search results and to provide content to those who can't hear.  It's not, um, all good news though, because the main and significant criticism of machine learning is that it is simply a product of its training, so it is a bias‑built system that is constantly re‑entrenching its own biases, and that's just simply how it works.  So, unless you have a very broad dataset and you are constantly teaching it and correcting it, it will, by definition, continue to reinforce biases, and there are some really ugly examples of machine learning biases, um, that you can just Google and prepare to be very disappointed.  Additionally, CMSs are going to create content using AI from whole cloth.  In September 2017, Digite reported that The Washington Post had published 850 AI‑generated articles in its first year of operation.  This included 500 articles about the 2016 U.S. elections, and those articles generated more than half a million clicks.  Now, quote, not a ton in the scheme of things, but most of these were stories the Post wasn't going to dedicate staff to anyway, close quote.  So, at least now, this is not a case of robots replacing reporters, it's robots augmenting a publication's ability to cover more content.  

So, besides publishing articles about the 2016 U.S. election, The Washington Post also put their AI to work by publishing stories about high school football games in the Washington, DC area.  So, here's an example.  This article, um, shown here was written entirely by artificial intelligence, and it begins with the Landon Bears shut out the visiting Whitman Vikings on Friday, so on and so on.  This is written by a robot.  The New York Times, Associated Press, Yahoo Sports, they all use AI to write stories right now, and last March 2019, the Press Association claimed that they can publish, which, by the way, is a UK news agency, they're kind of the equivalent of the AP in the United States, the Press Association claimed that they can publish 30,000 local news stories per month using artificial intelligence.  So, it's already happening, and it's accelerating.  CMSs are also going to interpret the emotional tone of the story and then react accordingly.  So, some publishers, like, okay, who cares, why would you care about the emotional tone of the story and how would you react to it, here's an example.  So, publishers are already using sentiment analysis to, um, to deliver the appropriate ads and to avoid embarrassing advertising placements.  So, for example, if an algorithm determines that an article is critical of Dow chemical or Bayer medical products or whatever, those products will not be advertised on that page.  So, if it's an article that says Dow chemical is polluting the Earth and whatever, whatever, well, you don't want to see an ad for a Dow product, that doesn't make sense, right, so it will be exempted from that page, and that can happen automatically, but if it's an article that's, maybe, um, praises Dow chemical, that might be a reason to pull a Dow chemical ad specifically on to that site.  

Now, we wanted to see just how easy it would be to use machine learning to generate content.  So, for Drupal Con last year, we built this thing called happy gram.  You can check it out at happygram.AI.  This is a Drupal site that turns happy memories into shareable postcards.  So, people would come up to our booth and share a two, three‑sentence happy memory, so here, somebody said I ran into an old friend, I'm about to go visit him in Costa Rica in June, and I'm really excited about that.  So, we start to look at things like what are the entities and the syntax, what are the most important parts of the sentence.  Well, this Google Cloud natural language API that we sent this text to returned friend in Costa Rica, and friend is an entity type person, and Costa Rica is an entity type location.  We then sent these terms, friend, Costa Rica, some others, to a, um, creative commons licensed photo library called Unsplash to then look up images that we could use to help tell this story that somebody wrote.  We also then determined the sentiment of this story, was it positive, was it negative, was it neutral, and, um, the algorithm that we employed said it was mostly a positive story.  So, it got categorized as bonding, as a story that's about, you know, hanging out with a friend, we're bonding, and what we did with that information, um, both the, um, the sentiment, whether it was positive or negative, and then the kind of, um, memory it was, the categorization, we applied an image filter to the images that were chosen.  So, we have the original image on the left, and then we have the resaturated and filtered image on the right, and so that's how you wind up with stories like this.  I had oysters yesterday, they were from different regions, I had a glass of white wine, etc.  The author of this memory was presented with dozens of images, picked these images, and then the, um, the emotional tone of the story, um, had an image filter applied to it.  

Here's an example of a memory that was, um, categorized as affection.  So, snuggling with my dogs in bed on a Sunday morning, all of these images were suggested by an AI, chosen by the editor, by a human editor, and then all of this image post‑production was applied to it to make it fit the overall emotional tone of the story.  This stuff is possible right now using, um, freely accessible, and in some cases, open source libraries and algorithms and data sources.  Prediction number six, reality will be augmented.  If you've seen me speak in the last couple of years, you've probably heard me talk about how big VR is going to be, and I have to admit, I got a little too excited about that.  I still feel VR will have a strong adoption in gaming training and industrializations, but to the average person, it's probably going to just be used occasionally and probably mostly in gaming, but it is still important, so VR is being used in combination with cognitive behavior therapy, for example, to treat combat PTSD and phobias.  So, it has very, very, very important uses.  AR, augmented reality, on the other hand, is already quietly infiltrating our every‑day lives, and its potential is huge, precisely because it's so useful, yet subtle.  Here is an example of AR in use.  This is Google Lens.  It's like a pair of smart glasses without the glasses.  This camera‑enabled app, um, can be used for object recognition, translation, shopping, recognizing things in the world, and in this example, Google Lens is highlighting a menu's most popular choices based on reviews within Google Maps, and then it links those popular choices to photos of those items that people have uploaded to Google Maps, and it's doing this all on device.  Google has also been working on ways to integrate 3D content into different learning experiences, so here's an example of a Wikipedia‑like online encyclopedia, here's an entry about the space suit.  

So, let's assume that we're on a desktop right now, here's the desktop experience.  Well, we can scroll down, and, well, okay, here's this space suit, and we can turn it around and look at it and all of that.  That's okay, that's the desktop experience, but now, let's go to a device that has real AR capabilities, so a phone, for example, you scroll down and there's a different icon there on the bottom right, looks like a little cube with, like, a square around it.  If you tap on that, um, you get this kind of interface, and now you can drop that space suit in the room, you see it to scale, you can rotate it, walk around it, do all kinds of stuff, and as recently as May of last year, Google has started introducing 3D models and AR experiences directly in line in search results, but we'll get there in a moment.  So, these AR and VR experiences are three‑dimensional, so therefore it's no surprise that we're seeing an explosion of 3D assets, which is really just another form of content.  Here is a website called Sketch Fab.  It's a massive marketplace for 3D assets.  This is sort of like Shutter Stock, but for 3D models.  So, the users can upload everything from scans of real‑world objects to hand‑built models to powered animations.  Some of these are free, some of them, you can pay a licensing fee for, but there's all kinds of stuff, and if you just search for tractor, look at all the stuff that you get.  This also extends to 3D printing and fabrication.  

So, here's a site called Pinshape, which is like Shutter Stock, but for downloadable, um, fabrication files, so you can print these things on your 3D printer at home.  Here's a great example.  When I was polling our team for some ideas on this talk, one of our developers, Chris Martin, described how he felt that this new space race is going to result in an explosion of 3D printing technology, because if you're on a long‑term space voyage to, say, Mars, um, then you can't bring, like, every possible tool that you need along with you, it just becomes cumbersome, so why not have the 3D printer that allows you to make the adjustable wrench that you need, when you need it, and when it breaks, you just melt it down again and put it back into the 3D printer, do it all over again.  This is all content that has to be managed, and it is part of the future of content.  Prediction number seven, content delivery will be context‑specific, meaning it will be delivered to you based on where you are, what you're doing, and what you're trying to achieve.  A great example of this shift is iTunes.  So, when iTunes was launched in January 2001, it was a game‑changer.  It became the go‑to music store and MP3 library, and then it started adding other media, movies, TV shows, podcasts, and, of course, podcasts were invented for and named after the iPod, but 18 years later, iTunes is, it's a relic.  They refer to it as a relic of a different era in which people bought all their movies and music in one place.  Now, that seems, like, quaint.  So, Apple Music, which they've split off as a separate app, is singularly focused on music, and now we have separate apps for podcasts, TV, movies.  So, Apple has realized that the context of content no longer makes sense within iTunes, so they have to split it into all of these separate applications.  This was rolled out to, um, Mac OS devices in the last year, and it had been available on iOS for much longer.  So, Apple's announcement, um, came shortly after Google added playable podcast episodes inside search results.  So, if you search for a popular podcast on Google, you will be able to play episodes directly within search results, and, of course, you know, this is because Google wants you to use their podcasting platform, which brings us to another interesting form of inline search results.  

So, we are seeing AR, augmented reality, and 3D assets appearing natively in search results.  So, please try to resist the temptation to do this now, maybe wait 15 minutes until we're done, but, here, we have a search, Google search for dog on a desktop device.  Nothing strange here, right?  We got some news articles, we have the Wikipedia entry on dogs, we got images of dogs on the right.  Pretty standard.  Well, if you open up a mobile device and you search for dogs, oh, you'll see this little 3D animated dog.  You can tap on view in 3D, and now you can, you know, look at it in 3D and kind of spin it around.  You know, that's neat.  Well, then, you can tap that button at the top that says AR, and you can drop it in your room, and here is this animated dog, life size, you get to walk around it and, you know, it's kind of barking at you.  This is all inline search results within Google, and it's a great example of context awareness to experience this kind of stuff.  All right, last prediction, distribution channels will be restricted and monetized.  So, we're seeing, this is, you know, not news at this point, but, man, is it accelerating, streaming services are being built around exclusive content that you can't get anywhere else.  So, um, many content producers, you know, have been doing this for awhile, Netflix and Hulu, for example.  CBS launched all access in about 2016, and it provided streaming only context, and by August 2018, it had 2.5 million subscribers paying money every month to access it, and in January 2019, they announced they intended toenter the streaming wars by releasing Peacock.  This also means they're going to end their deals with Netflix and Hulu, so three of the most popular shows on Netflix are, of course, Sienfeld, The Office and, um, Friends.  Well, all three of those are probably going to be moving to Peacock, and that'll be the only place where you can get them, because they want you to, um, join their exclusive service.  The podcast market is really heating up, so don't let the DIY nature or, um, roots of podcasts fool you, it is serious business.  So, not that long ago, the interactive advertising bureau, the IAB, reported that podcast ad revenue in the U.S. had increased 53 percent within the year and was expected to go up another 42 percent the following year, and so these podcasts, now that there's so much money in sponsoring them, they all used to be platform agnostic, now they're starting to consolidate on paid platforms with exclusive content deals.  So, you have groups like I Heart Media coming up with, um, exclusive content, you also have Spotify acquiring Gimlet Media and all kinds of other things moving very quickly in this space.  So, um, podcasts are becoming increasingly popular and profitable.  

Personalized advertising, which powers a lot of this stuff, so an interesting thing to note, in case you're not aware, when you download podcasts from most major podcasting platforms, the ads, the, you know, this podcast is brought to you by, those are injected into the MP3 file at the moment of download based on whatever information they know about you.  It could be your location, it could be other podcasts that you subscribe to, whatever it is.  They might not know a lot, but they are trying to personalize advertising to you at the moment you download the file.  So, that may be why it seems oddly specific, or if you travel a lot, for a weird two‑week period, you might be hearing all these ads for stores in LA and New York, and then you get back home and wonder why.  That could be why.  Also worth noting, when you visit a site, the ad space, the banner ad, whatever, that's being auctioned off at the moment of page load based on everything the site and that ad knows about you, and whoever bids the highest to show you their ad wins, and this happens in milliseconds in the background.  So, advertising is content, and it's being personalized based on everything they know about you, and it's being injected into how that content is being delivered.  So, that's a lot.  Let's summarize.  CMSs will be content repositories, not website managers.  Content will be extensible and modular.  Content creators will finally get the tools they deserve.  CMSs are going to focus on specific verticals and use cases, the examples that we showed were in media, entertainment, and publishing.  Machine learning is going to help us manage and create content.  Reality will be augmented.  We will see a lot more, um, AR.  Content delivery will be context‑specific based on what you're doing and where and why.  And distribution channels are going to be restricted and monetized, um, being exclusive content for specific streaming services.  So, oh, pardon me.  There we go.  

What now?  Hey, if you found this interesting, speaking of podcasts, I run a podcast called the future of content, and in every episode, we talk somebody in a specific industry about the kinds of content they produce.  So, it might be somebody who's really into role‑playing games, what is the content of role‑playing games, how do you manage it, what does it look like.  Somebody who is a restaurateur, how do you do menu design, what makes an effective menu, how do you use Instagram to collaborate with your team.  These are all topics that we explore.  You can review this session at the URL shown there, and please, please, please feel free to reach out anytime.  The best way to reach me is e‑mail, [email protected].  I am happy to take questions.

>> SPEAKER:  We have Carson asking is Drupal uniquely positioned in any way architecturally to take advantage of this changing landscape?  I'm guessing a no.

>> SPEAKER:  Um, well, I think it's better positioned than most because it is built around, um, it's built around the ideas of, um, fields and content types at its core.  You know, previously, it was a node, and then it became an entity, and that's really, to me, from a business value perspective, what Drupal really does super well and really boils down to is its content modeling capability.  So, I think it's uniquely positioned from that perspective.  I think it's also uniquely positioned in that the shift from monolithic front‑end and back‑end tied together to decoupled, um, the front end being a display layer for the content that's sent to it by an API, that transition was a lot easier for Drupal than other CMSs, as I, um, believe the case to be.  Mostly, I'm comparing it mentally to Word Press, that packs so much of its functionality into the theming layer.  So, for anybody who's familiar with the Word Press architecture, there's this thing called the loop, and the loop is a database query that says give me the content.  They put that in the theming layer, and in Drupal, you do not do database calls in the theming layer, right?  So, um, architecturally, I think that Drupal has been ahead of the game, um, but I have to admit that, like, basically, any modern CMS can be decoupled at this point.  If it can't, it's way behind.  So, um, I think that Drupal has had an advantage for quite awhile, and I think that because of those roots, it probably has a slight edge, but, um, there's less and less differentiating it in that way as time goes on.

>> SPEAKER:  Excellent.  I have a question that dovetails on that one.  You mentioned, I don't know if you used the phrase CMS agnostic editor, but is that simply just an RTE, a rich text editor, or is there more data modeling and meta data included in that?

>> SPEAKER:  Um, I think I'd open that up really broadly.  I think it's more than the editor.  It's about, you know, how do you, um, score the content, how do you collaborate on the content, what is the governance and the work flow around it.  When it comes to, like, a CMS agnostic, um, editing experience, I guess I should open that up more broadly to, like, content operations and how those things are handled.  Um, I think it can be as simple as a rich text editor and somebody just prefers that to something else, but I think that the real value is in something much broader than that.

>> SPEAKER:  Mm‑hmm.  So, are we talking specifically UX?  Because you're talking about the editor that, um, are you saying publishers deserve, I want to get that quote right.

>> SPEAKER:  Um, it's the, um, editing experience that content creators deserve.

>> SPEAKER:  Beautiful.

>> SPEAKER:  That includes anything from if you're a one‑person content production shop and you have to handle all of the images and videos and the transcripts and all of these things that go into a piece of content.  It also includes all of, you know, how do you make that happen, like, how do you quickly find the right images to feature that help tell the story, how do you do post‑production on the images that it fits your branding guidelines and also the tone of the story, um, how do you get a, um, a high‑quality transcript for an audio file or a video, so that your content can be accessible to people.  I think it's all of those things wrapped into one, and having a content creation tool that can help you with as many of those things as possible is really powerful.

>> SPEAKER:  Excellent.  In the room for some more questions, what do we have here?  Well, I will take advantage of the opportunity then.  So, I'm still stuck on this, Todd, this RT experience.  I love our data modeling, and I love it compared to custom type, um, post‑types, and I way love it over the other content model, which they struggle to understand.  So, in that respect, we are somewhat unique with positions, but then I bring in this thing that you have, which I'm not going to misquote again.  I'm trying to put that together, and you, I did not realize that Four Kitchens had branched out to, you know, whatever the client wants, which is a fantastic business model, no one's going to argue it, but I have to ask, and maybe this is not the time, what is the future of Drupal for you as a go‑to, is it a go‑to solution, to satisfy these requirements you just explained to us?

>> SPEAKER:  It's still the content management system that we use the most by a huge margin, but we are, um, we have Word Press capability, we are also looking at any number of other solutions.  We have, in the past, recommended things like Arc to some clients strategically, because it seemed to check all of the boxes that they needed checked, um, because their use case or their need was really, really unique.  Um, you know, we don't actually build things in Arc, we don't really have the internal capability, but also, um, Arc is a pretty locked‑down model, and our attempts to reach out to them, to understand their partner model for, like, can they bring agencies or other developers onboard to implement stuff, um, maybe it was just early on in the life cycle of the product or whatever, but that didn't exist at the time.  So, and if you, at the time, and things may have changed since then, um, if you were an Arc customer, you relied on Arc to do the implementation, installation, and all of that for you.  So, it's, what we're really trying to do is just find the best solution for our clients.  That might be, you know, gather content, then we'll build the front end, or it might be content, and then we'll build the front end.  Our focus is on creating, um, really good digital experiences for organizations that educate and inform, and that's why we focus so much on higher education and media, entertainment, publishing, and some other related industries, like professional associations.  So, we want to use the best tool for the job.

>> SPEAKER:  Yeah.  Well, you're doing well, so no one's going to challenge that.  I guess I guest the last word here.  I don't suppose D9 has you much excited about improving its use in your tool set.

>> SPEAKER:  I'll be honest with you, I don't have, um, a lot of insight into the big changes in Drupal 9 at this point.  My focus, professionally and within my role at Four Kitchens, um, over time has become more and more distanced from the, um, the actual mechanics of Drupal and other platforms, so I'm not really well‑equipped to answer that question, and I'm sorry to say.  I would like to learn more, and I look forward to seeing more, but I wouldn't say that there's anything that disappoints me.  I think that, um, there's a bright future for Drupal in a lot of industries, and we can see that through all kinds of, you know, trends and data, it's rapidly being adopted in government and higher ed and tourism and a bunch of other industries.  It's just that media, entertainment, and publishing is going in a different direction for a lot of reasons.  You know, they're struggling.  They're dealing with their content being, um, sucked into things like Facebook and the rest, and they're not able to really monetize it well, and it's the same story we've been hearing for, like, 15 years, 20 years, it's just getting harder and harder and harder every year for them.  So, they're looking for solutions that, um, that really focus on content monetization, and that's what a lot of these proprietary platforms are promising.  Whether they do them or not, I can't say, but they promise to do that.

>> SPEAKER:  And, fortunately, Carson had one more here.  I want to give Carson the last word.  He said are there good or great open source options for that decoupled editor experience you were showing us?

>> SPEAKER:  I'd have to follow‑up on that, look into that a little bit more.  The kinds of editing interfaces that, um, that I'm more familiar with are the hosted content solutions, like gather content and contentful, things like that, and they focus very heavily on editor experience, because that's clearly where they feel their marketing and their adoption will be driven, is by simple use and happiness with the platform by the people who make the content.  They're the ones that will yell the loudest, if, um, if that experience is bad, you know.  So, I'd have to look into the question about open source third‑party editors.

>> SPEAKER:  Excellent.  Well, thank you very much.  Do you have a feedback slide, by chance?

>> SPEAKER:  Um, yes.  Let me pop that back up.

>> SPEAKER:  We'll extend a minute or two to get that feedback slide up here.  I know that, um, you got 40 people in here, Todd, this was exciting.

>> SPEAKER:  Wonderful.  There you go.  Can you see it?

>> SPEAKER:  Yes.  So, please offer your feedback on Todd's amazing content.  Don't be biased, but it was amazing.

>> SPEAKER:  Thank you.

>> SPEAKER:  I did not know you're doing a podcast, but I've got that bookmarked now.  Thank you so much, Todd.

>> SPEAKER:  Yeah.  Thank you, everybody.