 Good afternoon. Making sure everyone is in the right session. I know it's the end of the day. It's been a long day. It's been a fun day. I promise we'll get out a little bit early. That's my pledge to you today. So, oops, if I could learn to operate my own computer. I'm Ken Rickard. You might know me as Agent Rickard. My name is actually down on the floor in the exhibit hall. I'm really tiny right under Chex. He's a really big CHX. I'm right underneath him. This big letter. I've been around for a very, very long time in the Drupal community. I'm right now the director of professional services at Palantir.net, which means I'm in charge of account management and sales and training and some other things. I've been a Drupal contributor since Drupal 4.5, which is semi-impressive. I was one of the co-authors of Drupal 7 Module Development. One of my co-authors is speaking about this same topic to the developers in the core conversations track right now, which is kind of amusing. I was a top 50 contributor in Drupal 7, and I got promoted to management and I'm a top 150 contributor to Drupal 8, because I haven't written code as my day job in about three years. Before that, and we'll talk about this because I had fun putting this together, I spent, before I got into Drupal, or when I first got into Drupal, I should say, I was working for a newspaper company, and we'll talk a little bit about that when I get into some history. So we're going to talk today about four basic things. Again, I'm going to set some terms so that we all can agree on what we're talking about. I'm going to talk a little bit about history of content management very briefly. We're going to talk about some needs going forward, and we're going to set some goals. In particular, again, how many people in this room would consider themselves to be developers? That's about what I expected. I will tell you this, like I said, I've been doing this a long time. The first talk I ever gave was at the Florida Press Association, it was a newspaper conference. I had a room like this, and half the room were managers or editors. The other half were developers, and no one considered themselves to be both. Bridging that gap between the tools that editors need and the ways that developers think about them is critically important. That's really what we're going to be getting into here today. So these concepts should be familiar to your development teams, and if they're not, if they are familiar, they will think of them in this language that we're talking about. So I think it's very important. So we'll start with the terms. Very simple. What is a CMS? Content management system. Two words there I want to focus on, of course, management and a system. The biggest thing about a content management system is that it requires structure, it requires consistency. That's a big deal. I want to contrast that to what most people are familiar with, which is actually a web publishing tool. The web publishing tool is actually just a thing designed to get things onto the Internet. Web publishing tools do not like structure. Web publishing tools don't care about governance or the rules that one applies for editing and publishing. I'll give you a very simple example. How many of you use WYSIWYG editors, like CK editor, those things that look like Microsoft Word? Yeah, those are web publishing tools. They're not content management tools. Those are tools designed to help things look the way you think they should look. But that's not necessarily the same thing as having a content management system or content management strategy or, lo and behold, a design strategy to inform the way your pages are rendered. I want to get into that. The difference between these two things. A web publishing tool generally was created by people who grew up in the print world. How many of you had experience like this? I used to build websites a long time ago. A lovely design come in from a print designer. She had designed it vertically, so it was longer than it was tall. I had to have a very polite conversation that she really had 600 pixels this way and 300 pixels this way. She converted it, took her two days. It was great. It was beautiful. But the print model infiltrates our thinking in a lot of ways. Print tools are layout focused. They're all about proportion. Where does this fit compared to that? And again, from a web publishing model, editors and designers really value uniqueness in their layout. They want to be able to do something that's different. They want to be able to do something that's stunning. It's one of the things that keeps magazines in business, is that magazines can give you that good visual. And web publishing tools tend to be these page-centric visually-oriented things. We'll talk a little bit about that as we go. Whereas a CMS is very, very different. It's driven by the online models of how we produce and consume information. And in particular, it's focused on content and on distribution. I should say I've been doing this professionally since 1998, and I first learned how to do web pages in 1995. The original web pages, remember all that gray background and blue links and black text? There were no design considerations. That's not what the web was invented for. The web was invented to be a very, very convenient and efficient way to share data. So the two models are very, very different. They come at the same basic problem space from a very different approach. So this is going to sort of ground what we're talking about as we go. So I'll talk a little history. I said I've been doing this since 1995. Does anyone remember this? This is how I learned to write web pages. Netscape Navigator Gold came out in 95, I believe. It came with a page editor. You could build web pages with this. And I actually learned to code because it wrote really, really bad web pages. I mean, the actual output it produced was it was bad. You couldn't quite make it do what you wanted it to do. So I learned to edit these pages. But I say page-centric, layout-centric, that's what it was designed to do. I mean, it looks like Microsoft Word. And it did that on purpose. And for those of you who don't know this tool, by the way, imagine if you could open your browser and there was another tab in your browser to let you edit the page. Netscape Navigator Gold did. You would just pop open, I want to edit this. And this is how we all learned how to build web pages. And you got to build things like this with it. This is from an archive of GeoCities. Yeah, that inverted L, we're very familiar with that pattern. And this is also famous because the Space Jam website is still live on the internet. You can still go look at it. But these are, again, design-centric. Most of the things we were building in 95 and 96, they were either generally plain text or image-heavy with no real information on them. This is sort of a classic example of peak web design from 1997. It's great. At the time, I was working for a newspaper company I mentioned called Morris Digital Works. And I was used to this page model. And so I've been constructing things using these visual editors and looking at them. And at the newspaper, what we were trying to do was churn out the bigger properties about 100 stories a day. You can't handcraft 100 stories a day as an editor. No, you can't. You just can't. You need some kind of automation. You need some kind of tool for it. And it made me very sad. I couldn't find a good picture. But this was our editing tool. It was actually a FileMaker Pro database. I'll get wistful about FileMaker Pro. Beautiful piece of software. And what it would do is it would take our newspaper content. We would rip it into the system and it would then use semantics to show us what the different parts are. There's a headline. There's a subhead. There's the body copy. And at this point, there's no markup in here. This is all pure data. It's great. It actually then had its own templating engine and on output, it would literally spit out all your HTML. But at its core, it was a database for proofreading the content you were getting from print. And what was really funny about this for us on the digital side is that our print editors, because they wanted pages to look nice, would often break the conventions for how to build a page. So when we pulled the content over, there'd be no headline, because they weren't using the right font styles to map to headlines, because they wanted to do something unique. So we had a lot of fun with that. But this is fascinating to me, because this, I mean, they did this in 1996, is when it first came out. And the HTML, it spit out, had embedded semantic tagging in it. Right? Does anyone want to ask a question about why I think that's a big deal? Why? Sorry? Yeah, people talk about semantic tagging is now huge. It's right. It's the thing. But this is almost 20 years ago. Right? And the software engineers who built the system were like, you know, we might want to scrape this data off this web page later and republish it in a different form. We should probably make it so that we can do that. It's the really, really funny piece here. It's actually not semantic markup. What they were doing was embedding their hidden stuff in HTML comments. And then we were actually using like font tags for layout. So it was sort of a mash of the two. It was really kind of fascinating. Around the same time. So I'm working for this company. I'm using this tool from 1999 through 2007. Drop.org, Drupal comes out 2001. Right? So while I'm working in this space where, again, we're using FileMaker, which is a database application to generate web pages so that we can harvest our data and do useful things with it. Drupal.org comes out. Drupal comes out. This is a screenshot from Drupal 3. I have a whole other presentation about that. It's a lot of fun. Very, very different way of thinking about your content. Right? Oh, that's interesting. I didn't know I had a transition in my slide. There's a boom, actually, in the early 2000s, websites like Corrosion, which is now gone, and, oh, Slash.dot was the other one. Drupal, for those of you who don't know, started as a Slash.dot clone. I want to be able to spit out news quickly. So we have a bunch of tools that come out around the same time. It's interesting because the shift there is to thinking away from pages and towards these bite-sized chunks of data. What's your title? What's your headline? What's your body copy? And trying to keep separate the structure of your content from the display of your content. So we'll go to the semantic markup issue. Have we made any actual progress in the last 15 years? Certainly we have. We have much better tools. I'm one of those people who started web development before there was CSS. Yeah. We have HTML5, which has some really, really great components to it. We have semantic markup. Semantic markup, again, instead of having to separate the tags that tell me what my data is, HTML now supports that. So we can very clearly say this is the article. This is the headline. This is headline one, headline two, et cetera. We have data-driven layouts, which are really, really important. We have micro-formats. We have frameworks. We have lots of different ways to distribute information and to think about information. And yet I think we still have this open question. Are you using a CMS or are you using a web publishing tool? And I love these examples here. I don't know how big Medium is in Europe. Folks, read Medium over here. I'll show you a screenshot. It's like Medium is essentially a blogging platform and then it aggregates content. It's really nice. Authors love it. It's very easy to use and their pages are beautiful, but their code is not. So we're talking about like a web publishing tool, Dreamweaver, front page. These are web publishing tools. Wordpress started its life as a web publishing tool, right? One of the great, you folks seen all the Drupal 8 new stuff? One of the great features of Drupal 8 is it finally has a WYSIWYG editor in core because the people who build Drupal have been fighting against it forever because the people who build Drupal want to build a CMS and they think WYSIWYG editors are web publishing tools, right? So this idea, once you introduce that, once you let people put markup into their body copy using a WYSIWYG, you've broken that the data model, right? So whether WordPress or Medium or things like that are CMSs or WPTs, and again, this is what Medium looks like. Really, really nice. Their HTML is absolutely horrible and not semantic at all, right? They don't care about that. That's not their business model, right? Their business model is how do I make it easier for people to build pretty web pages? Now, the reason I think this is interesting is the web has also changed pretty drastically. I mean, this is a screenshot of my Twitter feed, right? Twitter cares quite a great deal about semantic data. And Twitter doesn't care at all about markup. I mean, you don't put markup into Twitter feeds. Twitter has things like standards for web publishers to put semantic data in the header of a web page so that Twitter can generate those images, right? You're supposed to tell Twitter how to read your stuff. And I think that's kind of fascinating. And you could actually look at the HTML it spits out is a little bit better in terms of the semantic structure to it. At least their div classes have actual meaning to them, right? Is it a preview? Is it not? But I mean, there's some interesting things happening in the web space. One of Google's new missions in life is to make sure you never have to visit another web page other than Google, right? Oh, I want to know about the Sagrada Familia. Okay. Oh, here's everything I need to know. By the way, the other thing you need to know about the Sagrada Familia is you should book online. You should book in advance. It was a five-hour wait yesterday, so we didn't go. We're going Thursday. So I'm going to make the argument that the web page is a dead thing. It is not something that we should be thinking about. And if you are talking to people in your organization who are thinking about the design of a page or the layout of a page that they are thinking in terms that are outdated and inappropriate, in particular, if you're dealing with people who are trying to sell you software, right? The great example I have for this is at Palantir, we don't design in Photoshop anymore. We design in HTML chunks and show those chunks to people. We do design systems, not here's a pretty page. Here's a pretty picture of what your website looks like. Now, your website is a cluster of components that interact with one another. It's a very different model for looking at things. So we have these things. I do a talk frequently where I joke that the next big thing is going to be the internet on the tops of your shoes, right? So you don't have to look people in the face when you're walking. Oh, news on my shoe. The only way to get news on your shoe is through structured data, right? You can't get a web page onto the Apple Watch. You can send data to it, and it can have a data reader, right? And then the device will then display that data appropriately. Things that can do that, things that can power that, are content management systems, because again, they're thinking about data in a structured and reusable way, right? So since we have this sort of proliferation of devices, we have watches and things, and we have to design for those different viewpoints. We have to design so that our data always matters, right? And you get a consistent experience across devices. So this is the big change. And just to drive it home, I love this in 2014. Yeah, mobile, finally outstripped desktop. And particularly if you get out of the United States or Europe, this is true. If you go to Africa, it's all mobile. All mobile Internet. There just aren't people sitting around using computers the way that we're used to. This is the future. And in order to power that, you have to think about what you're trying to transmit. So that's where we get into these needs. Pardon me, one second. So I'm going to steal an acronym, and I'll show you a chart. This is actually from National Public Radio. National Public Radio in the United States is government and community supported news and information. It's actually some of the best radio we have. And they coined this acronym, COPE, right? Create Once, Publish Everywhere. This idea that as a content producer, you should be able to write your story. You should be able to control your data in such a way that once it's there, it can go wherever it needs to, and that can be distributed. I was showing you SiteWeaver, the tool we use when I was at the newspaper. And at one point, we wrote a plug-in for SiteWeaver that would send some of our data to MSNBC so they could publish our headlines and link back to us. And we sent them like this little sliver of metadata. It was a very, very cutting edge. And a total failure. But this is like the original graph of the COPE model from 2009 of what they're actually trying to do, right, where you have sort of data entry. Those editors are on the far left. And actually, Lord knows what on the far right, right? Larry Garfield is one of our engineers gave a talk this morning where he was talking about Symphony and some of the things that it can do. We did a project two years ago for an Australian telecom firm. We essentially built them a video-on-demand platform, but we only built the middle part, right? We have no idea what they actually built for users. We just built an editorial tool and an API layer, right? We built the create once part and then they dealt with the publish stuff, right? I'm pretty sure they built a set top box application. I'm pretty sure they built a mobile application. I know they built a website, right? But that didn't affect any of the data entry stuff, right? Because the data entry can't be tied to the presentation layer, right? Again, if your data is tied to your presentation, you're dealing with a web publishing tool. So some needs and definitions. Again, these are the things you should be talking about with your developers and or your vendors, right? CMS means separate concerns always. Your content is not the display of that content, right? Your management is not the same thing as your publication. And I will give you an example. There's a great talk that was given today about putting crap in Drupal core. Crap, meaning create, read, archive and publish. It was a metaphor for the workflow. Are they going with purge instead of crap now? I thought they were still calling it crap. In the program, it was called... Oh, purge, not publish, purge. I'm sorry. Create, read, archive, purge. I'm terribly sorry. I have my acronyms backwards. The idea being that the act of archiving old information is in fact a management act. It's not a publication act. Those things that we talked about earlier as web publishing tools, front page has no concept of archiving, right? Photoshop certainly has no concept of an archive or of purging old data from your database. So I'm giving you a helpful hint, by the way, because this is the quiz portion, right? What do you need for content in 2015? Five things. Guess which one is most important? It's the yellow one. You need architecture, right? You need a content architecture. Drupal is really good at that. We'll talk a little bit about that. WordPress is getting much better at this. Medium is actually pretty good at this. Let's be clear. I mean, even Twitter has an architecture. It's a very simple architecture. You put in 140 characters. Boom. Governance. How many of you know what governance is? Talk about... I talked to someone today who was in sales and he said, if they understand governance, then we're in. Governance are the rules and procedures around who can publish what and when and how they're reviewed and et cetera, et cetera. So I'll give you a simple example. Here in Catalonia, it is important that everything be available in both Catalan and Spanish. So you might have an editor whose sole job is to make sure that both versions are ready for publication. In countries like Switzerland where they have three and four national languages, this is crucially important. So you might have a governance rule that says this content cannot go live until all of the translation editors have signed off on it. So governance... I will say this later in the talk probably because I say it all the time. Almost everyone in this room does not actually have a technology problem. You have a governance problem. Technology is actually a commodity. Wordpress, Drupal, you could probably solve most of your business needs using something like medium. It's perfectly fine. Heck, there are businesses who do all of their stuff on Facebook. It's fine. Until you start having complex governance needs, then it's not so good. You need storage. Storage is absolutely critical, especially in the digital medium. Again, I came out of a newsroom. Whenever we start a new project, I always like to ask two questions that get to the fundamental sort of heart of everything. Question one is, where does first write-through happen? Which simply means when you're creating new content for your sites, where do you write it? Do you first scroll it on a napkin? Do you write it in Microsoft Word and then paste it over into your content management system? Or do you actually use your content management system as your editorial system? Which is preferable, obviously. So that's question one. Question two is, where is your database of record? Where are you actually storing your historical value? SiteWeaver was great, but it was considered a temporary solution. And literally, I used to work with a bunch of people who worked at they worked at a nuclear bomb facility, believe it or not, very near our offices. And so they had very, very strict ideas about data security. And the reason we had those tags in our output is so that they could go through later, scrape the output and stuff it into an Oracle database where it would be indestructible and save forever. Because they were concerned about, you know, the sort of ephemeral data. They wanted to make sure that things were stored correctly. You have to worry about distribution, obviously, the huge deal that create ones publish everywhere. There's a lot of pressure to that. Okay, I want to be able to write this once. And it needs to go to my Facebook page. It needs to go to my website. It needs to go to Twitter. And those things need to be those versions of the content need to be customized for those platforms. And yeah, outside of distribution, you do need intelligence. You need information that helps you do your job better. We'll talk about that here in a little bit. And I'm doing well on time, by the way, we're at 28 after I'm on slide 38 of 61. I promise to get us out on time. Your architecture is your structure. This is again the sort of crucial point when people talk about content management systems. One of the things that's made Drupal successful, in particular, is this concept of fielded data, right? It's the one thing that for years Drupal had that WordPress didn't have WordPress is getting into this does now fielded data simply means I don't have to just have one big glob of text that is my entire web page, the way Netscape Navigator used to do it, I can divide it up into different pieces, right? I just rewrote my blog software. And for my blog, I have like six different pieces of data that I can tell, right? Titles, I have things like that. Drupal makes that again very, very easy. So fielded data is important. Your editing workflow is important. What are your approval processes? What are your editing restrictions? Those are important. And the reason I put this in place, this work around, I should have a better picture for it. But it's the it's the classic, you know, if you tell people not to do something, or if you force them into a workflow, they will find ways to break it. This is the biggest governance issue you have actually. Even though you've put a structure in place for people, they are going to find ways to make their jobs easier. Right? In my newsroom, we always used to blame the sport reporters. The sport reporters hated to follow the rules for their layouts. They always break them because it was faster. So again, governance, we talk about that a little bit. Governance is your standards. Yeah. What to edit? One of the big governance rules we work with a lot of universities, and a lot of them need to review their content every year, or every six months, or they need to have historical revisions of policies. They need to be able to say, well, this was our policy two years ago. This is our policy now. And there are federal regulations that force that. So yeah, what do I edit? Who can do that editing? When do I do those edits? How do I control who can make those edits? One of the contributions I do in Drupal is actually about this very issue of who can edit what based on permission. But the more important governance question I would ask you, of course, is why? Why are you making this edit? Why is this change important? Right? And why are the restrictions around those edits important? Literally, if you're going into a content management project now and not thinking about these questions, you're going to have a bad time. It's going to be painful. You need to sit down with your editors and say, okay, what's our workflow going to look like? What's the structure to things? How do we want that to go? We very much like to go to people's offices and watch them work when we start a project, right? And sit there and take notes. Okay. And sometimes we'll watch them use their old systems and be like, why did you skip that part? Although that part's not important. And it was like the most important thing for us. Well, why aren't you doing that? Oh, it's hard. Okay. So governance, your governance rules will give you your standards for things. That's really, really critical. Storage is just about data, right? How are you going to create it? How are you going to retrieve it? How are you going to archive it? And it's really also about the data model, right? We don't have to get into that too much. But there's a whole industry around this now, right? Content strategy, this whole idea of how do we model data so that we can be successful, right? The distribution part, again, that's your audience, right? Now consider what are your channels for distribution? What are your methods to getting to those channels, right? We talk about, I mean, people want Twitter straight out of the CMS. It's easy to do. It's actually very easy to do. What are the costs associated with that? Again, important things. Do you have to go through, you know, elaborate partnerships to do certain things? I know people in the United States are upset that, you know, Google started to put some restrictions on who can do certain things. And if you are certain, if you have a certain partnership level with them, you can do things that other people can't, this sort of thing. And then this is the really important thing, I guess, as we get into the next bit, which is about goals, which is the real success is going to be based on actual business intelligence, right? What are people reading? What are you doing with the information you're able to gather? The biggest disappointment that I can remember in our newspaper careers, we had a really nice piece of analytics software, and then no one knew what to do with it. So we had all this data, right? Actually, anyone in the room familiar with Aquia Lift? So the folks who wrote that software used to work for a company called Omniture. We used to use Omniture in the newsroom. Omniture was awesome, and it captured all kinds of data, and no one ever knew what to do with it. So the folks at Lift basically said, well, what if we took this data and told you what to do with it? We'll do personalization based on the data. Boom, success, right? It's just kind of fascinating. So start thinking now, again, how are we going to do this? What information do we need? How are we going to gather it? How are we going to report it? How are we going to understand it? And then, again, this most important piece is what action are we going to take based on that, right? So we can get to the goal. So hopefully, I put forward some clear arguments for what you need. It's like, okay, what are we going to do with it? So number one, direct quote, hey, I'm quoting myself. You do not have a technology problem, right? With the possible exception of Inigo, because Inigo is one of our clients, and he has to pass around gigabytes worth of climate data. That's a little bit of a technology problem, a little bit. But it's great. Inigo has a great project. You should talk to him later. The technology for most of these things is actually a commodity, right? The open source software community is caught up to these things. I mean, these are solved problems, right? A lot of folks can get by. There's a software as a service in the United States called HubSpot. And it does a lot of this for you. You don't even need to buy a server if you don't want to. It can be expensive, not to, but you generally don't have a technology problem. Those problems have been solved. I also like to pull out this Mark Bolton quote, because he's a little more famous than I am. Just because people worry about the technology so much, and they don't actually describe the business problem, or this is the worst case, they vastly underestimate the human problem, right? We sometimes talk to clients, and they very clearly state their business case, and then we tell them, that's great. You need to hire six people. And they look at us like we have, you know, six eyes, or horns, or like it's chlorophyll. Can we have the little torches? Did anyone else go to chlorophyll, by the way? You missed out. It was absolutely dangerous. So yeah, Mark Bolton's the guy who, by the way, helped design the administrative theme for Drupal 7, the 70, that's Mark Bolton. So I'll show you a few Drupal things we're tinkering with. Like how do you give people actionable information? This is just the basic, you know, hey, here's Drupal stuff. Wait, did I put in the wrong? No, I didn't. No, excuse me. I apologize. We're doing different tech stuff. I jumped ahead of myself. So, ooh, Drupal stuff, how does Drupal make this happen? Okay, let's say you want to distribute content, as I said, to my shoe, or my Apple watch, right? What you need to be able to do is spit out a service that has the data, in a structured format that other people can read. You can do this in Drupal 8 in about five minutes through the user interface, because you can go in and create this bottom one here, this rest export. Rest export is simply a protocol for sending data to requests, basically. So someone says, hey, give me the last three things you published, and it will send them this, which doesn't look like anything, but that's the whole point, because it's the receiver, it's the Apple watch on the other end, or the BlackBerry, or my shoe, that's going to then turn this into something that you can act on, right, as a reader. So that's really, really important. The question that I asked here is, how many tools do you need to do these five things that I've outlined? Drupal will tell you that it does four of them, by the way. Drupal will tell you that it covers architecture, governance, storage, and distribution. It can do all those things. Distribution was the last piece we just looked at. What it doesn't do, of course, is that intelligent piece, right? I like this too. How many points of failure are there in your toolchain? There are five points of failure in your toolchain. Any one of these things, if done incorrectly, can really hamper you from achieving your goals, right? So how do we combine those right tools? And again, this is what we're kicking around from a, when you think content management system, when you think content strategy, this is sort of the meat of it. What are your analytics? How are you auditing your content, right? And a content audit is a very, very simple process. It's just time consuming. It says, hey, let's look at what we've produced. How are people using it? What value does it have? Is it written appropriately? I don't, I'm going to assume that things are similar in Europe, but we are given the advice when working on government websites that they should be written for people with a primary school education, not primary school, secondary school education. So 13 to 14 years old. That's like a government standard. Gov.uk is writing for nine-year-olds. Yep. That's about, in the U.S., it's 13, I think, is the standard, but 10 or 11 is probably really good. The point being, you want to make sure that people understand things. I mean, content audits will tell you things like, and most people know this, like people like to read bullet lists, they're much easier to read. So it's very, very good practice in many cases to start your article with, here's the bullet points of the three things you're going to learn today, or the three reasons you should read this article. It's the same reason I put out an agenda on slide three. This is how we're going to go through it. And then people can scan it very quickly and decide if they're going to read the whole thing or not. So yeah, content audits, governance and workflow. So what might that look like? This is a slightly modified version of Drupal's editorial interface. Again, just a list of content, and all we've added is a status to it at the moment. Like, hey, we've gone through and done an audit. What action needs to be taken next? Someone needs to add an image to it. Someone needs to review it. Oh, this has been approved. This idea of going through and setting the next action to take, and then assigning that action to someone on your staff, I think, is really, really important. The other piece that I think is going to be really interesting, and I promise to talk some about analytics, and then I probably didn't fulfill it. I apologize. Is integrating analytics directly into the editing experience, right? How many people are looking at this page? We have unique visits here at the bottom. This percentage of direct and indirect traffic. One of our project managers and strategist used to work at one of the three biggest newspapers in the country, and he loves those two numbers, the percentage of indirect and direct traffic. Direct traffic are people who literally type in your URL and go to it, and nobody ever does that. Indirect traffic is, you know, they get you through search. Do they follow a Facebook link? Those sorts of things. Yeah, what's your bounce rate? Bounce rate, of course, means people who look at that page for less than the amount of time you need to actually read it, which means they hit it and then they left immediately. And then the exit rate, which means for how many people was this the only page or the last page they looked at on your site, right? Now, it's possible to have a good, that a high exit rate is good if the page is actually solving the problem that the person has. But these are generally flags that you have bad content. So thinking about, yeah, how do we integrate this in, in a way that editors can actually respond to it? Because the great thing about Google Analytics, and that's what this is, is that all that data is present, but it's sort of siloed away from editor doing their normal jobs. And it's very, very difficult to do this kind of work. I mean, if you ever do a content audit, the basic strategy for doing a content audit is to use a giant Excel spreadsheet. Yeah, I see at least one person weeping silently in the front. Yeah, we have tools that will let us do that. Why don't we just do it natively in the CMS? All right, we can prepare our content right here. And then again, you know, where it really gets fascinating is this doesn't even need to be my presentation engine. I can do all my content preparation right here and then syndicate it out using that REST API that I showed you, right? As you're going around the rest of this week for the non-technical, when you see sessions where they say headless, headless Drupal, that means Drupal doesn't actually render your web page, it just provides data and other things render your web page, right? It's also known as decoupled. It's like really, really exciting stuff. But what I like to say, this is the important thing. Yeah, Larry will probably use this in his talk too. I actually looked up what this actually means. This is called the law of the instrument they call it. The law of the instrument, meaning the paradigm you're used to, the way of thinking that you're used to, tends to color everything that you do, right? So if you're again come from a print background, you're used to thinking in terms of layout and space and juxtaposition, that's not relevant when you're designing a content management system. There is a tweet, one of the people who's speaking right now, Morton, Morton's one of the leaders of the front end group, the folks who do all the output and the HTML for Drupal. And I forgot where I was going with that Morton story. He had a tweet earlier today. Oh, he had a tweet earlier today where he said, no, we're not putting an HTML editor into the user interface. That's not appropriate. We don't even want you thinking about that. That's not what the tool is for. The tool is for the structure. So this law of the instrument, the piece that I would ask is, yeah, where's the most critical failure in the organization? And again, it's probably in this intelligence part. I would really, really urge you, I do this in all of my talks, that it's the people who are actually going to make the most difference here. You want to invest in those resources, not the technology resources. Technology changes. Strategy will adapt to those changes. But people are the thing that will keep coming back. There's that great, the great story of what happens when you hire the wrong person. How long does it take you to recover from that bad hire? So it is much, much better to invest in the right tools and the right people as you're getting started. So I did promise a little bit about analytics. The big question is, how are people finding you? Are they coming to you directly? Are they coming to you through search? Are they coming to you through social networks? And then what's happening when they get there? What are your top pages? What are your top bounces? What are people doing when they get to the site? Tracking those things and then feeding them back into the editorial workflow are really, really important. Put another way, the big business questions here, again, from a content strategy perspective have to do with what do you value as an organism? What's important? And in particular, it's not, this is really challenging. We're doing a project right now with a firm. We did their redesign. They're a hospital. Their redesign is all about doctors and it's all about making the doctors feel important. And the problem for that is that I don't know the difference between lymphoma and leukemia, right? So when I go in and search the site or try to find information, I'm confused because it's written for people with medical degrees. It's not written for, it's three o'clock in the morning and my child won't stop vomiting, which is the more important question because it's a children's hospital, right? So we're doing another piece with them to re-examine how people interact with their content, what kind of questions they're trying to solve, right? So, yeah, how do you make that easy and how do you track that people are doing what is important, right? So then those last two questions, yeah, do you have a CMS or a web publishing tool? Yeah, are you building pages or are you actually driving interactions that matter? So that is the end of my formal presentation. We do have time for questions. I believe we're going till six, is that right? We've got 14 whole minutes for questions or you get bonus free time. Thank you. And they have asked me to use the microphone if you do have a question. I'll give you a fun story that isn't mine and then I'll ask the question. You asked, you mentioned the comment to do with people always trying to gain the system of particular sports journalists. Martin Benham, who used to be in the Guardian, he had a great story that, I hope it's him, unless it's the BBC, that they were trying to get sports people to use the system for the reporting results and everything. Everyone hated it, apart from the people that were in the littles villages in England, because they realized that if they put all the data in properly, they would come up top on the sports pages. So if there's an incentive, there isn't a way. My question, which is, I guess what you were starting to touch on at the end, I do content strategy and a lot of persona stuff and we're really getting excited at trying to get people to think about personas and then write the content based on the personas and then even start using personalization to not only be able to say, well, we know that page is for this person, like the person who's got a child three o'clock in the morning, as opposed to a doctor, and then also being able to figure out that later on, based on them going to that page and that page and that page, they must be a parent. We can give them more information and I know that Lyft does that, but we haven't played with it yet. So have you sort of had, I guess the question is, have you had a chance to look at any of this stuff relating to personas and content and sort of personalization? I have, but I don't have a simple or fast answer to that question. I can say specifically, sort of, is there, so is there, there are other systems, I don't know, people know Sitecore, which does personalization, so you can sort of tag pages and then say, I think this page is going to be related to, you know, this, if someone looks at this page, they'll be a parent and then you can sort of track things similarly. Is that sort of a similar thing that Lyft is going to end up doing? Yeah, Lyft will do something like, you can do that in Drupal natively now just because, I mean, Drupal has a taxonomy system, it has for a long time, and so you can, if you're just going to structure along, these things are related. That's very, very simple to do. You can even do, you know, you can have structured taxonomies and you can have, you know, free form taxonomies, where editors could just make random collections of things. So what Lyft tries to do is say, given that we can infer this about this person, either by reading their browser history or however they gather that analytics data, you then sort of program in content suggestions to say, okay, given that we've identified that you're from the UK as opposed to from Belgium, we're going to present this to you instead of this. So you can do that without Lyft, you can do that. It's funny, I just had this conversation with a team who's doing a project and they're like, oh, so we're going to do personalization, what's that going to look like? Like, well, you're going to talk to the client and find out what they want to do. In many cases, geolocation is the big deal. And the simple version of that is just like language switching. You can do automated, geolocated language switching in many systems. So I hope that sort of gets to what you're asking. Yeah, no, I guess I'm curious, but just because I think it's a hard call, people don't always understand personas. They don't always understand content strategy, but it's bringing that part again, you're talking about the action. It's going to bring it all together. So I guess it's just a general thing, which I'm sort of think hope that people know about because it suddenly makes it relevant. I would reinforce the concept of the persona. How many of you understand what personas are? So I don't have to hit it too hard. Personas, yes, do persona mapping and do persona ranking. Persona ranking is very, very important. We did this, this children's hospital. It was fascinating because we had, we had about this many people in the room and they all represented different parts of the organization. And who is one woman who was quiet the entire time because it was her third week on the job and she worked in major gifts, which means she was responsible for getting people to give them lots of money. And she said, well, what about the persona of these people? How important are they? Where do they fit into this? So, yeah, persona mapping, of course, lets you understand, yeah, who are you targeting and why are you targeting them? Yeah, right. So the point I'm repeating for posterity was that you might not, if with proper analytics and proper automated actions on those analytics, you don't need personas anymore because they will auto-generate. Right. And okay, I'll plug because we're an Aquia partner. If you go downstairs to the Aquia booth, they'd love to explain Lyft. They would love to tell you about it. And it does work with non-Drupal things too. Going back to the analytics point there, so the in-page analytics for journalism, I've done a couple of sites, not just in Drupal way, we've had that so they can go back and see the number of page views that bounce right and all the rest of it. And all it's led to is an absolute lack of understanding of why those things go up and down. Yeah, they see a bigger number. That's great, but that doesn't help them be better content strategists. It doesn't help them understand when they're writing well or when they're writing badly because of the sheer number of variables that that could be about, you know, whether the story is any good, well-written, uninteresting story is still uninteresting. So and going back again to the Gov UK example, one of the first things that GDS did was strip the rights for individual departments to even have access to their analytics because they were so often used as policy-based evidence making. So at what point is six small measures of analytics that actually take each page out of the flow of what a user journey looks like? How do we prevent bad use of analytics with that feature and how do we promote good use of an understanding of a user journey through numbers? Right, and I think the answer to that is that we're thinking about things more crudely. So here we have hammer the hammer and the nail problem, right? That, okay, so we're not even conceptualizing of this correctly. The real the real thing is, are they actually taking it a worthwhile action? Right, when we talk about, again, a guy in my team, Joe Allen Black, used to work for Boston.com, huge website, and he used to be in charge of the analytics and all these things. He likes to talk about key performance indicators. His KPIs, he loves his KPIs. And when we talk to clients about KPIs, we actually don't talk about analytics, we talk about conversions, right? And so the, you know, the best analytics software is actually about conversion tracking, right? We just did a project that was actually kind of painful because they wanted us to tag every single link specifically for Google and for Omnitrax, so that they could track exactly how people were getting places so that they could use that to make some information. So yeah, a better question might be, can we use the analytics to present to an editor or to an auditor? This is where this page exists in the standard flow for people. This is, you know, people, that might be interesting to know, right? This is typically the third page that someone loads and then they tend to leave, right? But I suppose the question here is, again, that every nail looks like a Drupal nail at that point. Like, you have Google Analytics, is it, is it sensible per client to just train them to use analytics for at least a certain number of content editors or, you know, Pyrrhic or whatever they choose to use? Or is it, how can the CMS take on that role? Or is it sensible to follow the sort of chunking of things into the appropriate tool for the appropriate job? Right. And I don't have an answer to that. I just say, when you're thinking about your CMS, you need to be thinking about these things because I think they're relevant. So it's a conversation we can have all week, right? Yeah, I do not claim to have all the answers. I just claim to have valuable questions. Yeah. For the record, I have like 2050 vision because my eyesight is really bad. So I bought new glasses just last week. They don't fit my face. So I couldn't even wear them. 2020. What's really, like I said, one of the guys I work with is down the hall talking about 2020 Drupal. Like, what's that going to look like? Hopefully, we're saying the same thing. But so, yeah, I mean, analytics, in a way, are that blunt, they're hammer two, they're the same problem of, well, we think this is the way to get the actionable intelligence we need. But maybe it's not. This is again, why those folks went off left omniture to build what's now lived because they're like, there's an easier way. Why show the analytics to people? Let's just act on them. Right? Yeah. Right. So the question, as I understand it is, excuse me, what kind of tools have we seen for helping people write better content or making better choices about what content is related? Essentially, right? Right. There are a number of ways to do that. We used to use back in my newspaper days, we used to use a system called DTI and DTI had a search box baked into the editorial interface. So you could actually go in and look for things. And I've seen people implement pieces like that in Drupal. It's actually really easy to do with taxonomy. For editorial teams, what I like to do actually is you have one taxonomy, it's sort of the fixed taxonomy that your public sees. And then you have some private taxonomies for your teams. Well, I'm going to tag this as Barcelona 2015 because that might be important three years from now. And I want to be able to come back and find it. I used to do this when I used to run in my site weaver. We used to have discussions every once in a while. I was like, hey, have we seen like two or three articles on that same topic? Let's spin up a tag for that. And we would actually start building historical archives off of that. I have seen systems that try to run automated searches off titles. Like, oh, you're entering this title, and it'll pull up related things. That would be kind of fascinating to do in some respects. I mean, I could see, I have this vision now, it would be fun to write from a programming standpoint. Like, okay, you've entered your title for your story, let's run a Google search and see what it pulls back. And display that over here. I don't know if that would be useful or not. No, I mean, I'm also going back to, so DTI was this system we used for print newspapers, right? And it was interesting because the page layout tool and the copy editing tool were different. And they actually didn't want most of the writers to be in the page layout tool. They wanted them just to be looking at that blank white, just write the story. Don't worry about how it lays out, just write the story. And I think that's kind of interesting. And we do, I think we see sometimes that, you know, as technology folks, and especially as developers, we really, really like structured data. But structured data can be very cumbersome to the creative process. Like, oh, I got to stop and think about how I'm going to fill out these eight pieces of the form, rather than actually write the story. That does come up to that question, again, that I brought up of, you know, where does your first write-through happen? Right? And what tools do you need to make that successful? You know, if I actually still wanted to write a long form piece, I wouldn't use Drupal. I would probably use Word or a text editor. Right? Just because I'm more comfortable there. It's less distraction. So, all right, we are over time. Again, we can have this conversation all week. I appreciate everyone coming. I appreciate your time. Thank you.