 Good morning everybody. Good morning. Welcome to Future of the CMS. We're gonna talk about making content work across all devices and experiences. My name is Todd Nienkirk. I'm CEO and co-founder of Four Kitchens. This year we celebrated our 11th anniversary of not just being in business but working in Drupal. We've been working with Drupal since 4.7.2. Anybody remember that? Yeah. So if you want to get a hold of me later, that's my email address. It's easy to remember. That's me on Twitter. I don't really use Twitter much anymore. I got kind of sick of social media in the last few months. But occasionally I will post silly jokes and word play along the lines of, you may not know who I am, but I'm big in Baltimore. So today I want you to rethink how we manage, publish, and consume content. I'm gonna cover four things. I'm gonna talk about what a CMS used to do. I'm going to talk about what a CMS will do tomorrow. I'm gonna give you some examples, both theoretical and real world. And we're gonna talk a bit about what's next for content and content management and content experiences. So to understand the future, we must understand the past. So let's talk very briefly about what CMSs used to do. So way back in the 1990s, we first dealt with flat files, HTML files, there was no CSS. There really wasn't any JavaScript. There was briefly a thing called DHTML. Anybody remember that? Dynamic HTML? Then there was like VRML and all kinds of stuff. Then those flat files became kind of difficult to manage. So we needed to create desktop publishing applications like front page and dream weaver to help us manage our websites and assets. And those were really the first mass market content management systems. They existed on our desktop computers. They created FTP connections. They uploaded and synced files to a web server. And then along came GeoCities. And GeoCities was kind of interesting. Not only because it's a part of internet lore at this point, you can download all of GeoCities. It's like a terabyte. You can find it on various like torrent websites. GeoCities was kind of the first web-based CMS. It was a website that let you manage your website. You logged into a website, you loaded up a form, you threw a bunch of HTML in there, and it stored the HTML and served it to other people. GeoCities was really the first web-based content management system. There's also tripod and angel fires and others, but GeoCities is the one that kind of latches on to public memory. And just for fun, let's take a quick, very quick trip back in time to the 1990s to remind ourselves of what things were like back then. Space Jam is still up. It's not going anywhere. It's a classic. And of course, Apple's first website. How many people here have either said or have a boss say or have a client say, I want a website to look like Apple.com. There you go. So in the 2000s, along came web-based CMSs in scale. This is when Drupal and WordPress and PHPBB and all kinds of, you know, dozens and dozens of platforms, .NET Nuke and all kinds of other CMSs were created. And they followed a pretty familiar pattern. CMSs contained both the back end and the front end of your site. They would store your assets, your images and other things, text, maybe some files to download. It would manage all of that stuff, store all of that stuff, and then it would also display all of that stuff. So CMSs were all in one, right? And at first there was desktop and laptop, and that's how you looked at websites. And then eventually along came RSS feeds and everybody at some point here had to somehow shoehorn in an RSS feed onto a standard website in the early 2000s. Then along came mobile devices, responsive web design. For a while we were doing separate mobile pages and experiences, especially for not-so-smart phones like Blackberries and others. But this was like the landscape in the 2000s for the most part, on the front end. These were the only devices we were dealing with for the most part. On the back end, there was a lot of text. There were multimedia assets, files, images. And then along came things like comments. So we had some user-generated content that we had to store. People could leave comments either by creating accounts or anonymously. So we were storing all of this stuff on the back end. But as people started to use CMSs, particularly open-source CMSs like WordPress and Drupal and Joomla, people started demanding more functionality. They said, hey, it totally makes sense to give accounts to people who are managing content. Other editors, other writers, site administrators, right? So we started to build in this account functionality. Users had accounts. Well, then the next logical step was people should be able to register on my site because then I can track their information, they become members of our community or then they have a shopping cart or all of the different things that you can do when you have a user profile and a login system. So we started creating user profiles and logins. Well, the next step there was we had to have permission systems to allow some users access and deny other users access because not every user can have admin access to the site, right? That's foolish. So now we have this big permission system built into our CMS. Well, then these users, these administrators of the site, they don't know HTML, but they're in charge of the site. They don't know CSS or JavaScript or anything. So what do they want now? They want layouts. They want to be able to create their own layouts. So now we're creating layout engines. Some of them are drag and drop. There's all kinds of stuff for WordPress on the theme layer where you drag and drop things into the columns or the content areas. Of course in Drupal we have regions and we have panels and panelizer and panopoli and all kinds of stuff that we use to create layouts. And then there were integrations. So you want your shopping cart and your analytics and your CRM and your ERP and your HRIS and all of your acronyms. They all need to glue onto your website. You want your LDAP address book stuff to feed into the user profiles and you want to export data, CSVs to other things and the business world took over and just littered it with alphabet soup and now we have integrations everywhere. So CMSs have gotten really bloated in the 2000s and early 20s. They do a lot. They're not really content management systems anymore. They're website management systems. We're managing users and permissions and integrations and layouts. They weren't really intended to do that. Who here remembers when Drupal called itself a community plumbing tool? Not a content management system, a community plumbing tool. So this is what wound up happening. Some company would create a website, organization, they create a website. They built it on whatever was the flavor of the month or whatever skills they had in house. Maybe somebody new WordPress or somebody new Jumla or vignette or whatever. So they built it on this. But then some other department would come along or device and in this case, oh now we need a mobile website. Well, it's going to cost too much. It's going to be too complicated. The technology is not really there yet. Let's create a separate mobile site. So now we have these m.sites and mobile.sites. So we have a separate, a totally separate website for mobile devices. It exists in a silo. Well, then, you know, marketing needs microsites. So now you've got these microsites and they're built on totally different things and they exist in silos. Well, we need to add a blog. It's too complicated to add it to the main site. Just fire up a WordPress instance, right? That's easy. Now we've got blog.yourwebsite.com or yourwebsite.com slash blog. And that's a separate CMS. Oh, and then the iPhone comes along and we need to, everybody needs an app. So let's build an app and we have to feed content to that. Can't get it out of our main website because it includes some of the blog stuff and some of the mobile stuff and some of the microsite stuff. So let's just create a new website that is just like a content management thing and that feeds into the iPhone app. And this is where we are. How many people are in this situation right now or have been there very recently, right? It's terrible. It's terrible. So let's talk about what a CMS should do tomorrow. But the thing about the future is the future eventually becomes the present. And this is especially true in technology. I have completely rewritten this talk every year for the past three years and I just rewrote it yesterday. So each time the what's next section at the end of the talk just gets moved up to the front and it's what's now. So every six months or so it gets a complete rewrite. That's how quickly this changes. So what we used to consider the CMS of tomorrow is now the CMS of today. So let's talk about what a modern CMS should do right now. Let's talk about philosophy briefly. We need to put the content back into content management. Content should be first. Let's go back to our roots. Let's deprioritize user management, layout, functionality that's locked into the site. I don't mean eliminate. I mean, I mean, deprioritize. We need to elevate the importance of content so that the site can better serve its purpose, which is in fact content management, not website management. We need to stop confusing CMSs with development platforms. How many people here have called Drupal a development platform? I know I have, to a lot of clients, because it kind of is. It's kind of a development platform and it's kind of a content management system. And I think we need to pick one and make that thing really great. So let's think about that while we go over what Drupal can do and not do. So it's a bit confused in this sense. But that's because we confuse it. Drupal and all the other content management systems out there are just reflections of our needs and demands, right? We want there to be user permissions. We want there to be layout creation tools so the community builds them or an enterprise company builds them. So here's an example of confusing content management with content display. Think about Drupal views. Think about the module views, now core functionality views. Think about what it does for you. Like when you go into the interface and you create a view, what are you doing? You're building a database query that pulls content, filters it, sorts it, select specific fields, maybe does things to those fields, right? So far so good. And now we start adding stuff to it, divs and spans and markup and all kinds of stuff. And then what do we see when we create a view? We see a list of posts or a list of content. Maybe teasers, maybe full-length blog posts, maybe user profiles, whatever it is that we're pulling out of the view, we then see it. But views real power is in building the query, not in displaying the content. That's what views is actually a query builder, not a way just to display content. And this is what I mean about our constant conflation of content management versus content display. And we need to really think about those as entirely separate. Here's a way to do that. So the modern CMS needs to decouple the front end from the back end in some way. Back to our example, we have a CMS that controls both the front end and the back end of a site. When we talk about decoupling, this is what we mean. We mean we pull the front end away from, not necessarily out of, but away from the storage layer of the CMS. The front end might be called the head, and the back end might be called the body, and therefore it is headless, also known as decoupled if you prefer something a little less evocative. So here's where we are. Modern CMSs should be able to separate the front end from the back end, and they are of course connected, don't worry, through some kind of API. And when we say front end, we're mostly talking about our website, and when we say back end, we're mostly talking about the content that's stored on the site. So here we're separating the display layer that is the website that you see when you go to a URL from the systems in place that allow you to manage that content. And there's a connection between them called an API. Drupal actually is pretty close to this, out of the box, because its theming layer is implemented using an API, right? You're working with the theme API to build your websites, to build layouts and to use twig and stuff like that. So we're already doing this. When you're building a theme, you're working with Drupal's theme API, and you're effectively working within the structure. A modern CMS needs to support robust content modeling and structured data. So here's what I mean. I'm going to give you a super, super simple example. Let's take a look at our model once again. So here's our decoupled website. We're going to zoom in on content. So inside content, we will have all kinds of content types, right? We all know about content types. We're going to have articles, and we're going to have authors, and images, and videos, and all kinds of stuff. And these content types contain fields, right? The articles have titles, maybe also short titles, author information, a summary of the article, body, images, videos, other assets attached to it. This list could go on and on and on. These are the fields. This is a very simple content model. We have thought very carefully about the kinds of information that might be needed in the future by some device or use case, and we create systems that allow site administrators and content editors to put that content in place from the very beginning. So we have a title and a short title, because we might need to publish this on Twitter or some other length constricted medium. So we have a short version of that. We don't always want to show the full body of the article, so we might show just the summary, right? These are simple examples, but we could think of how articles could easily, if you're publishing to a lot of different sites or services or devices, you could have dozens and dozens of fields. And that's okay so long as they're reusable and robust and intelligent. So here within the article, we also have to make sure that these things interrelate. So your author is going to be pulled from the author content type name field, right? These all need to kind of link up and they could be reusable. And the headshot for the author might be the medium sized image for the image content type. The images and videos from your article are pulled from the maybe small image and hyra's version of the video. This is what we mean by content modeling. We're thinking about how each of these fields interrelate, how the content types interrelate and how we can reuse this stuff and not repopulate this content again and again. That's content modeling and it's very important for supporting new devices in the future which we'll get to in a moment. Okay, so let's zoom back out and think about how we centralize our content. A modern CMS needs to centralize all of your content into one place so you're not scattered across your blog and microsite and other things. So here's what that would look like. If you consider your website just one of many sites or front ends that you work with, you might then add a marketing microsite, you might add a blog like we did earlier, but rather than treat them as entirely separate sites, we just connect them to the same content store. And now these are different front ends for the same pool of content that you're drawing from. Because typically a microsite is just going to be a subset of the content you already have on your main website, right? It'll have a specific audience or purpose or agenda, but mostly it's going to be stored along with all the other content. And the blog as well. So that's centralizing content. A modern CMS needs to quickly support new devices and experiences. So a modern CMS does not treat your website, especially your desktop website, as the primary experience. A modern CMS is multi-device but not designed for specific devices. Multi-device but not designed for specific devices. This means you have to think about content first because the content drives all of these experiences. Think about content, not devices. You should let the CMS deliver structured content and let the devices, software or application, interpret that content appropriate to that device. I'll say that one more time. Let your CMS deliver structured content in some format, a feed or an API or a data model, and then let the devices, software, the app that somebody else built or the other point of integration, third-party service, let it do the heavy lifting of interpreting the content that you send it. Because that same piece of content, that content model is going to be reused across all of your apps and sites. Some things will be selectively pulled out and displayed on that device or app. And some may appear on the website, but no single source, no single end point is going to use all of the content in a specific piece of content. So here's what this would look like. So here we've got these three sites that we built. These are like traditional style websites. You can load up a browser on your phone or on a desktop or whatever. You can look at these sites in a browser. But now we're going to start adding applications and services. So the first app, let's say you want to build an iPhone app. Well, what's cool about this content model is you've already structured everything. You've got your articles and your author and your images and videos and all that. Let's say that there's, there is something unique about the iPhone. It does lots of things. It has support for accelerometers and sensors and all kinds of things. But the most common use case is usually location. You now have a location aware device. So when it's time to add an iPhone application, just add a location field to your content model. And now you not only support iPhone, but all other location aware devices. We're thinking about content first, not device first. Reusable fields and data. Let's add Roku. So now we built a Roku app. Well, you're going to need to add certain metadata to that content, like, you know, Roku is a visual medium, mostly video, almost entirely video. So you've got all the streaming video. What do people like to do with streaming video? Rate it. Now you've got a ratings field. You add a ratings field to your content model and now you support ratings everywhere, not just on Roku, but particularly on streaming devices like Roku and Apple TV and Samsung Smart TV and Chromecast, all the rest. So by adding just one or two fields to your content model, you've now opened the door to all of these other devices. We're not building a specific website for Roku or a specific service for the iPhone. We're just adding stuff to the content model that already exists. Let's add Alexa. Alexa is an audio conversational interface. You talk to it, it talks to you. There's some content that can't readily be read aloud by a computer because it has abbreviations and other interesting things that trip it up. So maybe you need to add a conversational field or a read aloud field to the title or timestamp or anything that Alexa might trip over. So just add another version of that. Have your editors start to populate that for new content moving forward. You now not only support Alexa, but you support all auditory conversational devices. So then we'll add a couple services, feeds, could be RSS feeds, it could be whatever, AMP, accelerated mobile pages, Google's answer to Facebook Instant Article and Apple News and all of that. Well, once you have feeds up and running, it's a relatively easy step to support AMP because AMP can just simply be structured data. You can send it a JSON-LD feed and you're done. You don't have to create unique AMP pages. And these are so similar to Facebook Instant Articles and Apple News that after adding a couple more fields, you can pretty much support it as well. The idea is making this stuff really robust. Add a couple of fields and now you not only support the device you're going after, but you support all the other devices in its class. And they're all connected through an API. So this is really fundamentally the future of the CMS. All front-ends are first-class citizens. Everything starts with content. Content is created from multiple devices and experiences, but not specifically for those devices and experiences. And the website is just one of many front-ends. It's one of many ways that people experience content. Which brings us to the very last thing that a modern CMS should do. It needs to integrate with content-focused analytics. I'm sure everybody here has had the experience of, well, how many page views did we get in our website? Okay. How many times did people open up our app? Great. How many downloads of our Roku streaming app did we have? Right? And these are treated as like these separate analytics that you have to look at kind of side-by-side. And then you start judging which platform is more popular. Right? Like, well, not a lot of people download a Roku, but a lot of people go to our website. Should we just get rid of Roku? What you should actually be thinking about is how did a single piece of content perform in total? How popular is this piece of content on the website and on Alexa and in Roku and on AMP? You want to focus on the piece of content and not all of the device downloads and experiences. So you need analytics that are intelligent enough to understand when the same piece of content is being sent across a dozen different devices and experiences, how that content is performing. So all of that can be stored perhaps as metadata within the content management system, but unless your content is centralized you can't easily do this. If your content is spread across multiple devices and applications and separate sites that you create for that, you're going to have to, you know, run spreadsheets all the time and add up all the numbers and it slows all that stuff down. You should have analytics that really focus on content and not experience specific metrics. Those are valuable too, but the content is really at the core of all of this. So to quickly review, the CMS of today should put content management first. It should decouple front-end from back-end. It should support robust content modeling. It should centralize all of your content into one place so you can easily manage it. Quickly support new devices and experiences by just adding a few new fields every time a new device comes along and integrate with content-focused analytics. Alright, let's talk about some examples. So the first couple are theoretical. I see them all the time. I don't have exact, I don't have first-hand client case studies to share, but they're super common. So let's say you want to share content across multiple sites, the same content multiple sites. How many people here work in education or like a large corporate environment or a large bureaucratic environment, right? So we've all dealt with multiple departments and stakeholders and every department has its own site, every office has its own site. Okay, so here we have an example where there's like my website. I'm the webmaster for the law school at a university and my colleague Sarah, she works at the medical school and then we have the English department and the you know the dean and student affairs, right? We all have these separate websites and they all exist in these silos. They're probably not all in the same content management system because there were certain people in place when the site needed to do a redesign and they had skills in a certain area or they hire different vendors or whatever. So it's all kind of all over the place. So if I wanted to share content more effectively across the entire organization, across the entire university, then we would create a central content store in a content management system that is really good at this kind of thing and I feel that Drupal is. So we think about this in terms of content in my site and then we start to spin up these different front ends. So Frank has his site, Laura has her, Bob and Sarah, right? And they're all connected through an API. So this is very similar to multiple devices but we're just talking about multiple websites because they're all endpoints. They're all different front ends for the content. So let's say Sarah over at the medical school, she publishes a really interesting article about Supreme Court decision regarding patenting genes, right? That's a serious issue affecting medicine but also law and here I am at the law school and I think this is a really interesting bit of content that we should put on our law school website too. So what would happen before we had this situation set up is that first of all I might not ever be aware that Sarah published this really cool article. I might never find out about it because I'm busy doing my thing, she's busy doing her thing, it might not occur to either of us to sync up and talk about this or best case scenario, she tells me or I see that she's done this and I publish some kind of a summary on our law school page and I'm kind of duplicating content or I just duplicate it outright. So now we're being penalized by Google because we have duplicate content or I'm kind of doing a fluff, you know, introduction like all our colleagues over the medical school did this cool thing, check it out, it also relates to law. See you later and now you're sending them to that site, right? So in this case if Sarah's publishing content on her site it can automatically be sent to this content store where, I don't know, maybe it appears on a dashboard that everybody at the university can review, everybody who runs websites at the universities and maybe that content is tagged for different subjects or areas of interest. So there might be a medical tag, a law tag, a genomics tag, right? And I've got a dashboard that shows me all the stuff that's related to law that's been published at the university in the past month. So I see this article and I think that's really neat. I click a button, I syndicate it to my site, because all of this is happening automatically we can set the canonical reference in the metadata for the page so that Google does not penalize us for having duplicate content because we're saying yes, we know it's duplicate, the canonical source is over on Sarah's site, not mine. I'm just syndicating it because it's also relevant to me. But it's stored in one place and I get access to it. What if Sarah makes a change to the content? Well, without this system in place, I either have to be actively reviewing her content on a regular basis word for word to see if any changes or corrections were made. I'm not going to do that. Or Sarah might have to remember, oh, anytime I change this article I will need to email Todd and let him know that I made a change. Well, how many hundreds of pieces of content, hundreds of people will she have to contact on a monthly basis because she made a little change. It's not sustainable. So she makes a change. Well, that can simply be sent to this content store. And then maybe I'm alerted that there's been a change to a piece of content that was syndicated or even better, it just automatically sends it to my site and I don't have to worry about it at all. That's pretty cool, right? At a university, imagine this center hub here being strategic communications. This could work really well. This is what a modern CMS should do. Let's say you want to publish the same content to different experiences, totally different experiences, same content, same story, same idea, same narrative, but totally different experiences. So here we are with all of our devices and services and microsites and all of this, right? Let's say I write an article. That's a heavily text-based article. So where is it appropriate to send a heavily text-based piece of content? Not to every source. Certainly our website, microsite. It's not a blog post, so we're not going to send it to the blog. It's not really appropriate there, because it's already going on our main website, so it's good. We send it on the feeds, we send it out on AMP. We're not going to send heavily text-based content to Roku. Nobody actually reads text on a Roku device. It's not smart. Well, let's talk about videos then, because that's what Roku does, right? So let's say we produce a video, a really slick video. It's a single piece of content and it gets sent out to all the video-appropriate devices. It's not really appropriate to send video to Alexa, because you're probably going to miss out on the diagram. Like, yeah, if it's a talking heads kind of video and, you know, their interviews and people, that'll work, because you can think of it like a podcast. But if there are diagrams and infographics and animations and things that clarify ideas, that's going to be totally lost on an Alexa audience, because they can't hear the diagrams being animated, right? So we send that stuff to the iPhone app, Roku, microsite, website. And we create a text version of this same story. Maybe it's a transcript. Maybe it's a description of all of the data and animations and ideas in the infographics that are presented. Maybe it's just a rewritten text version of the article. NPR does this all the time. Pretty much every audio piece that NPR puts together has an accompanying article that is not simply a transcript of that radio story. It has embedded links and images and other media, and it's actually written for a reading audience. They have changed the actual content. This is exactly what they're doing. Exactly. So people who can't or don't want to listen to the audio version of the story can read a very well-written, written version of that same story. So we create a written version and we send it to the appropriate places. So it can be read aloud by Alexa and it goes out on AMP and feeds. Maybe we don't want to put video in AMP because it's a little too heavy for lightweight pages or whatever the reason, right? So we just send the text version out there. This is what we mean by the same content, the same idea, the same narrative being sent to completely different experiences. But it's all stored in one place. There's one in the Drupal World node that contains the video and the article version. Let's say you want to add new devices while tracking content performance across experiences. So this gets to the analytics side of things. We've been working with NBC for the past four years to do all kinds of things. Build APIs, build websites, build applications for various devices. They have a ton of content. There's the Jimmy Fallon viral videos and the two, three, four-minute bits that he does with his celebrity guests. There are episodes of the Blind Spot. There are entire, the entire 41-year history of Saturday Night Live is accessible through a website and iPhone app and Android app all using the same API and content management system. So this is a decoupled approach, obviously, because we're supporting all of these devices. And the content API that we help build allows for rapid device deployment. And I'll talk about that in just a moment. This also opened the door for really smart content-focused analytics. So analytics are collected across devices and related back to specific pieces of content. So this means that they can track how popular a piece of content is rather than how many page views the website got or which specific Jimmy Fallon video clip got the most YouTube hits, right? It's all across platform. They know how popular that piece of content is across the entirety of the internet and all devices. This also allows us to create a really cool customized experience across multiple devices. So there are websites and there are mobile versions of the websites, but in the case of SNL there are also apps. So you can download the app and get a richer experience with the content or you can just go to the website. This kind of thing, like this is OmniChannel, right? Omni Channel is one of those buzzwords that gets thrown around, but despite it being kind of buzzy and the kind of thing that you hear marketing people talk about a lot and no offense to marketing, but like there are a lot of buzzwords in marketing and so sometimes people get a little tired of hearing about them. But this is really cool and it's really important and OmniChannel really is a thing and we should be paying attention to it. It's about creating really cool experiences across devices and contexts that are relevant to that person at that time and that carry through to other channels. So you could think of retailers, right? If you're in sales and you're at a Best Buy and you're looking at audio equipment and you're reading their reviews and you're looking at the price there and you want to shop Amazon and see what's going on at Amazon, right? You might buy that in store or you might go home and then when you get home and you load up your laptop, well, guess what? Amazon is like retargeting to you that same audio equipment that you looked at before and then you might go to the Amazon site on your desktop PC or laptop and it's that single stream, right? It's a constant experience. It's also good for educators. It's not necessarily about sales. It could be, let's say you're in the admissions department at a university and you want to know if a particular applicant has read the emails that you've sent, the text messages that you've sent them, that they've used the chat tool that you created, that they are 50% of the way through the application process or there's some kind of pending flag on their application for whatever reason because they haven't turned in their essay or whatever and you need to get a hold of them across multiple devices and channels. That's OmniChannel. There's a university, I forget which, I think it was in Missouri, State University, that found that applicants, you know, keep, I hate to use the M word, millennial, but you have people who are now between 16 and 19 applying for school, for the most part. They don't really use email as much as maybe we do, I don't know who we are, but I use email a lot so they don't use email as much as I use email. Open rates on emails for them are like just abysmally low. So they thought, how do we ensure that we don't lose people in the application process? So they created a chat bot that interacts with students through text messaging and open rates on text messages are like 97% or something crazy, right? And they're like quick and they're easy and anytime a student expresses confusion or anger or they've hit a roadblock that the chat bot can't help them with on text messaging, they get flagged, they get by an admissions counselor, they get sent a message like, hey, give us a call. Like right now, just give us a call, we'll sort it out, it's cool. If they don't call, the admissions counselor will look them up and call them because they know that they've hit some kind of roadblock in the admissions process. So again, we're moving from website application to SMS to phone call, Omni Channel. It's pretty cool. So part of what we had to do with NBC was create a really flexible content model because they've got a ton of content and they want to support like every device, they want to be on every device. So when they came to us and said we want to do Alexa, you know, hey Alexa, what's on NBC tonight? Who's on Jimmy Fallon tonight? Who's hosting SNL? All we had to do was add one field and Alexa worked. And here's how we did it. So think about Alexa for a moment and think about what it looks like on the back end of your website in your content management system and the exact characters and letters and numbers that you use in fields. You probably have a showtime field that looks something like this. Now when we see this displayed as text in front of our face, we know that this means 9-8 central. Or I hope, I don't know. I know it means 9-8 central. What does Alexa say when Alexa sees this? 9-8-C. Hey Alexa, when is the blind spot on tonight? The blind spot is on at 9-8-C. That's not super helpful, right? So we create a new field. Showtime spoken. 9-8-C. Hey Alexa, when is the blind spot on? 9-8-C. You add one field and support it. Now you might ask, it sounds trivially easy to just put a parser in the Alexa skill that says anytime you see a C in the showtime field, read it as central. You could totally do that and you wouldn't have to add any fields to Drupal. But what have you done now? You have written specific behaviors for a specific device. And that work that you just did, though trivial, will not carry forward to any other auditory conversational interface that you build ever. Okay Google, you didn't do it for okay Google. But if you do it in one place with your content, okay Google will read this as 9-8-C. Also. Make sense? This is the whole content first thing. Awesome. All right. What if you need to make your content publicly accessible? Who here works at some organization or in some industry where you are required to do reporting like SEC, governments, public data, anything, right? I know they're more of you. Right, yeah, there we go. Thank you. So you have to make your data publicly accessible. I'm sure that's a huge pain. What if you could just make it accessible because, oh, guess what? You already have. You've already built this. This is already in place. There's already a central content store with this API that wraps around it that makes all of that content accessible in specific contexts. So you just take one of these little spokes and you make it a public API. Publicly document it, give people access to it. If people wanna build, and this is gonna sound weird but I'm about to show you an example of this, if they wanna build fan sites based on your content, they can do it, they've got your API. If you have to share with government entities or reporting organizations or government transparency groups or whatever, you've got your public data, it's accessible and it's the same API that's powering all of the other stuff you've already built. It comes along for the ride. Let's talk about fan sites. This exists. This is a thing. So we built Twit TV a few years back. This is a decoupled Drupal site using a node-based front end that we designed specifically for Drupal called Sausier. When Twit first came to us, it was a site migration. It was an upgrade in Drupal, which means migration. And I feel like I'm dumped on Drupal. I love Drupal. It's great. That problem's hopefully fixed in Drupal 8 moving forward, the migration upgrade thing. But this was a migration. And in the process of doing this, they wanted to do a brand refresh and a bunch of other things. In the process of doing it, we were thinking pretty creatively about like, how do people wanna experience their content? How do they share that content? How do they want to expand into other experiences and devices in the future? Because their audience is very technical. These are developers. They have video casts and podcasts about Android development, religion and technology, Apple development, all kinds of stuff. Like you name it, they have a podcast or video cast about it. So they have a highly technical audience who would want to do stuff like this. So they decoupled for a handful of reasons. And I wanna read those actually. So from the client, this is Leo LeBort. Reason one, it's faster and easier to create new sites when it's decoupled, when the front end is separated from the back end. Web design styles change faster than high fashion. So it's nice to be able to update the site without redoing all the hard work on the back end. You've created one content model with an API. It's handing that content off to whatever front end layer you've created. And now for the front end, all you're dealing with is markup, JavaScript, CSS. People don't need to know about twig or PHP template or any kind of front end theming thing that you've done. Just regular old front end skills, meat and potatoes stuff. You can hire anybody to do that. It's cheap, it's faster. So they can iterate through designs more quickly now. Having a complete API makes it easier to do apps. The app just like the website would have access to everything there is to know about twit in a simple and accessible fashion. So anytime they wanna add an app, they can do it very quickly. But by making it public, this is the cool part, we encourage members of our audience to create new things, things we might never have thought of. You could even design a website you like better. True. Abstracting the content from the presentation seems like a big win. So this actually happened. If anybody here has an Apple TV or Roku device, just search for twit and you will see a whole host of fan created applications for twit. Sometimes they're competing, like they both do the same thing and the developers wanna see which one will do better. Mostly though, it's an opportunity for their fan base who again is highly technical to just noodle around on a new technology and then publicly release it to the world. So they've basically had their fans build all their stuff for them for free. That's pretty cool. And finally, by keeping Drupal simple and avoiding additional third party modules, we can make a more secure and reliable backend that will be much easier to upgrade when future versions of Drupal arrive. So what makes these organizations in particular successful? Internet on a fridge. Internet on a fridge, remember that? Oh wow, I'm gonna have internet on my fridge. Yay, internet on my fridge, that's what I need. I'm actually not thoroughly joking here because the same things that make this possible, I know it's absurd, but the same things that make this possible allowed Netflix to develop a world-class VR daydream experience within weeks of the platform being released. Netflix, weeks, VR, the same things that make this possible made that possible. Here's what I mean. Agile project management and development practices, decoupled architecture, robust future thinking content modeling, and a focus on content, not specific devices, and finally a strong API design. If you have these things in place, yeah, sure, you can do a fridge thing quickly, relatively cheaply. It doesn't have to be a whole project that takes months and months and months. If for whatever reason you want to experiment with a fridge thing, let's actually think about the fridge thing for real, for a moment. It's very easy to laugh at it, because it's totally silly. But there are sites out there that could do really well with an application on a fridge. Allrecipes.com, Epicurious, Yelp, Instacart, right? I'm out of milk, tap, tap, tap, milk. I don't wanna cook, I don't have any food. Where can I go eat, Yelp? Recipes, Epicurious, allrecipes.com. It does make sense for some people. If they could rapidly adopt that platform, rapidly and cheaply, of course they're gonna do it. The barrier is always effort and cost. So if they have a big lumbering system in place that makes it really difficult for them to whip up a new app, then of course they're not gonna do it. I'm not saying that the fridge thing would have been successful ever. I mean, maybe it's still coming, right? It took VR like 25 years. So this is what makes our clients successful. This is what makes us successful as consultants, all of us. This is what opens up contents and new and future experiences. And what's funny is a lot of this stuff, Agile PM and iterative development practices, this is stuff that we've all been talking about for years and years and years, right? Continuous integration and scrum and DevOps stuff and deployments and there are all these tools that we've put in place that when you add them to all of this other stuff, decoupled architecture, content modeling, backend content strategy, API design, when you add all of these things together, you get a really lean machine. You can do really cool stuff quickly. Okay, let's talk about what is next. And in six months, this will be the what's now thing. All right, I made this up. I don't know if this is the thing. WMSs, website management systems. This is huge. Squarespace is like destroying parts of the market. Just shutting it down because it's super, super easy and people don't wanna deal with managing a big content management system or updating software or applying patches or doing whatever. They want a $20, $50, $100 a month solution for their portfolio site done, right? So what used to be the WordPress.com market or like I'll just install WordPress on this thing or I'll create a Tumblr account or whatever, it's moving towards stuff like Squarespace, Wix, Weebly, the others. So this is only going to continue to gain traction. Front-end technologies are constantly accelerating. They move way faster than CMSs, which are largely back-end focused. So as a result, CMSs need to double down on content, the back-end side of things. Put the content, put the C, back-end content management system, CMS, and allow front-end technologies to move at the pace that they should. And we can do that by decoupling CMSs. We let the front-end technologies just take off and we attach them any time we need them. So pick a moment in time, build your front-end system, using the best-in-class tools at that time, and rely on the back-end to be stable and last for years and years and years, but not the front-end. We have to design for experiences, not just devices. I'm gonna come back to that in a moment. Conversational interfaces, this is definitely, I'm surprised at how much of a thing this is. People actually really like conversational interfaces, and what's important to clarify about CUIs, conversational user interfaces, is that they're not just about audio. They are anything human text-based. SMS, search boxes, things that you just kind of wonder aloud, things that you interact, things, questions you ask Google, and Alexa, and Siri, and all the rest. They are those help desk systems that you see. A lot of those are automated. You're not, guess what, you're not really dealing with people sometimes, and you're on an airline website, and you're asking questions. But people generally really like them. They're passive. People hate getting on the phone. I hate getting on the phone, right? I'd much rather just text or Slack or something. The bot infrastructure in Slack is just, there's all kinds of crazy stuff happening. People are managing their entire lives in personal Slack teams. You can do financial management. There's like a Mint.com, but for Slack called Abe, and it checks your accounts, and it sends you alerts, and you ask it questions, and you tell it to transfer money, and it's all through Slack. It's pretty incredible. But here's where it's like really headed. So there's conversational interfaces like typing a question into Google. People tend to type questions, not keywords now into Google. So Google has to be good at conversation. It's not just about that. It's also about interacting with computers thoroughly through voice. So think like Star Trek Next Generation. Computer, what's the status of Deck 7? Or I'm sure that's something that was said at some point. But think about though how you pull that off. What infrastructure, what physical infrastructure is required to be able to walk into any room and just say computer, microphones in every room of your house connected to the internet? That's a good idea, right? That's good. So think about that for a moment. But before you get too scared, let's talk about sub vocalization. So various intelligence and military and paramilitary organizations have some pretty cool microphone technology where they will like you can kind of glue or touch a microphone to your jaw. Who here ever put on a pair of Google Glass glasses? So you know there was that thing, that pad that touched the bone right behind your ear? It wasn't a speaker. It was like a little vibrating piece of metal and it turned your skull into the speaker and only you could hear it. That's pretty cool, huh? The reverse is true with microphones. So you can sub vocalize, speak very quietly, maybe even under a whisper. But here's the really creepy thing. Increasingly, scientists are learning that if we just think a phrase, like a short phrase, like yes, no, do this, do that, short phrase, if we think it, there are actually subtle muscle movements as we're thinking that phrase in our throat and tongue and mouth that can be translated without us even speaking. Next up is simply thinking the stuff and not having anything attached to your neck that's feeling muscle movements, but having like some kind of, I don't know, a thing that giant weird hat you wear in your head like in Ghostbusters and you control the house that way, that actually already exists. It's just a matter of connecting it to your decoupled website. Virtual and augmented reality, this is so totally a thing and it's about to get really, really cool. So virtual, just quick definition. Virtual reality is a fully immersive experience where you are shut out from the real world and you're in this new world, right? You shift to a totally new thing. Augmented reality is when you blend the real world with other things that are added to it. So Google Glass was augmented reality. Pokemon Go is augmented reality. Instagram and Snapchat and all the filters that you use with that, that's augmented reality. You're taking the real world and you're flavoring it or coloring it or putting a filter on it or adding a heads up display to it. So Microsoft is working on some cool augmented reality stuff. There are a couple of solutions out there right now. There's this called the HoloLens. Virtual reality stuff is really neat and it's interesting to think about how Drupal fits into it. So I'm gonna plug real quick. Come by our booth where the games area will show you. Not how Drupal connects to it, but a very simple story told in VR using photospheres which are 360 degree photos and hotspots where you can interact with them and do things and bring up information and move from one room to another. And it's all in the browser. There's no app you download, nothing. You just go to a website, you hold up your phone and it becomes like a portal into that world or you put it in a headset and it becomes everything that you see. What's cool about thinking about how a content management system fits into that, when you're dealing with photospheres you're just dealing with a giant image and when you want to interact with that giant image you're just talking about coordinates on the image. So if you look within these coordinates here for two seconds, click, that's gonna do something. You can store all that information in a Drupal node. Here's your giant image that is your photosphere. Here are all the coordinates and here's what they all do. That's a node, relatively easy. But here's the really cool part. So once A-frame has support for the little remote thingy for Daydream, little Google remote, imagine entering the back end of a Drupal site and rather than having to map out coordinates mathematically and write them down on a piece of paper in like a little text file and then put them into a node, you just load up the node in your headset and you say, okay, that's a hotspot, that's a hotspot, that's a hotspot, done. Drupal as a virtual reality editing interface. Totally doable. Maybe we'll have it done in a couple months, we'll see. Augmented reality. It's gonna be really good for things like shopping. Here's a scene from Fight Club that, if you've seen it, you probably remember. He's walking through his apartment and all of the stuff that he's bought from this fake Ikea appears all of the metadata and all of that. This is totally doable now. This, like HoloLens could do this. Your iPhone and Android device through the pass-through camera can do all this easily. This might be the future of how we shop for things. Imagine being able to go into a store and you see a product and you just hold up your phone and it recognizes the product using image recognition and it says, oh, that costs whatever on Amazon. You don't even have to search for it. Here it is used on eBay. That's pretty slick. So we have to think about how we manage that content and what that experience is like and how we deliver it to specific devices. And finally, I want to talk about context to work content. This is kind of like, who here knows about progressive enhancement? Right, progressive enhancement is the idea that as you graduate to more capable devices, the experience becomes richer. So often this was used to describe the mobile web to desktop web transition. We're on, say, an older smartphone, a not-smart phone, a feature phone, like BlackBerry or whatever. You would have a really stripped-down version of your site, just text and a couple of images and it can handle low bandwidth connections and all of that, so a really simple version. But then if you load it up on an iPhone or an Android, there's a richer experience. If you open it up and it has a certain content is usually in one big column that you scroll through. And then if you open it up on a desktop application on a big screen, you have a different experience there, but it's all the same code. It's the same markup, the same JavaScript, the same CSS, same URL, it's the same code that does all of those things. And the experience progressively enhances as the capabilities of the device expand. What's cool about VR is that it almost goes the opposite way, where web VR, you can load into a browser on your desktop, but now you're just looking at a funky image that's stretched around the edges and you have to click and drag and kind of fling the image around to see what's happening in this photosphere. Or you load it up on your phone and you look at it and it becomes a little window into this virtual world and you can kind of do this thing or you can scroll through it. Or you pop it in a headset and now suddenly you're in it. And it's all around you and you're looking everywhere. In that case, as the device gets smaller and smaller and smaller, the experience gets richer and richer and richer. So it's not necessarily about the size of the device or the size of the display. It's about the context of the content that's being used. So in this case, context where content in VR would mean that we're not gonna display a website in VR ever. That doesn't make sense. Who wants to read a whole bunch of text in VR, scroll through an article in VR? That's not what VR is made for. I mean, how many people, like I can do VR for maybe 10, 15 minutes before I start to feel a little weird. I'm not gonna be reading long form Atlantic monthly articles in VR anytime soon, but I am going to do 306 degree photography and video and all the other cool stuff that they're producing. So the content needs to be aware of where you are and what you're doing and what devices you're on and send you the appropriate information and experience for that device. We have 40 seconds for questions. Any quick questions or thoughts? Come on up and we'll talk. Thank you everybody. I appreciate it.