 All right, mic check. I love this high tech stuff. I've been joking, I've said it three times now, this is not my first rodeo. So since this is the last session on the last day, we're not going to wait, we're going to get started, and then we're going to finish early. Woo. My name is Ken Rickard. I'm a semi-famous, I'm known as Agent Rickard, because Blackman, you had to get an AOL username to use Instant Messenger. The matrix had just come out, but I was the boss. So I didn't want to be Agent Smith 72, right? I work for a company called Palantir.net, or a full service digital agency. Fun stuff, I'm the director of development and professional services, which basically means if you interact with any of our folks who write code, you're going to end up talking to people who report to me. I've actually been around the community since Drupal 4.5, most famous for a couple of weird modules and for launching the first newspaper websites on Drupal. There's also a co-author of a book called Drupal 7 Module Development, you may or may not have read. That's kind of fun. And this is my 17th DrupalCon. So I was going to give a quick brief on how we're going to do this talk. This is a little different than some of the ones that I do because we're in the business track. It's not going to be very code related, but I have a couple of code slides. I'm going to talk a little bit about what I mean by the modern web. It means 2015. What does that actually mean? I'm going to talk about what Drupal 8 means for the project and then sort of how do we prepare for a redesign or a design project. And in particular, you'll see when we get to it. There's going to be a shift in the talk. We're going to go from talking about technical stuff to talking about project stuff. And I think that's OK. So really what I want to do is define the topics that we're talking about. I do want to explore why those things matter to you. And then I want to talk about how Drupal 8 addresses it. So that's going to be the sort of introductory format. So I do love this concept. Drupal 8 on the modern web. Modern is fun. So this means you get to play buzzword bingo. I don't know if anyone made one, but we're going to use all the buzzwords. It's going to be fun. I broke it down in, excuse me. I went too far. Instead of trying to elucidate all the little facets that go into what we consider a modern website, I decided to split it into five basic concepts that I think are the most crucial. And we'll talk about those in turn. You can read, so I don't have to list these off for you. So we will start with mobile. Yeah, people, I thought, never mind. I thought I was being heckled for a minute. It's just latecomers. Sorry. So yeah, mobile. This side, again, I did some research. I had fun putting this presentation together. Mobile usage did surpass desktop usage last year. That is official. And there are some statistics that will say that in America, something like 17% of all users only use mobile devices to access the internet. And when you get into other parts of the world, in particularly what we call the developing world, the numbers are even more substantial. In places like sub-Saharan Africa, you're talking about 70% to 90% of all traffic comes through mobile devices. It's a totally different ecosystem. So if you're not thinking mobile, you're thinking wrong. It is just flat out the case. The best interaction we had in a client case, we were up pitching design services. And we're just doing the discovery and getting ready to do the first iteration of the design. And the designer is making his pitch for how he wanted to do things. And the CEO was sitting in the room, and she said, mobile first, nothing else matters. And everyone smiled, and we went away very, very happy. In Drupal 8, they've worked very, very hard to make it mobile first. This is actually mobile first responsive on the back end and on the front end natively. So when you go to edit things, you can actually now practically, I want to say practically, in a practical usable way, edit Drupal sites from your phone. You can create content from your phone because it scales properly, which is really, really nice. This is the article editing interface from an iPhone. It's really, really slick. It's kind of hard for me to show what the front end stuff looks like. But I will, again, move ahead a little bit. Responsive images, how many of you are familiar with the concept of responsive images, right? Baked into Drupal 8, what you can do is you can say, I have these different image styles and these image styles apply at these different breakpoints. And so you go through the interface and you say, hey, this is a responsive image. And when you're defining an image field and you're uploading something, the system is smart enough to know how to respond to that. So when you finish editing something, it's like, this is what the photo looks like on desktop, where it's using the large format. And this is what it looks like on mobile. And these are actual size photos. So you can actually see, hey, this does change size. It's really, really nice. And it's just baked into the software. And it brings up something we'll talk about as we go on. One of the nice things about Drupal 8 as opposed to Drupal 7 is you'll notice when you start building things with it, you're not as dependent on contrib modules anymore. Because a lot of the things that we had to go back and retrofit into Drupal 7 or Drupal 6 or earlier versions are there natively in Drupal 8 because they're so fundamentally important. So the first piece is you want to make sure that your site is responsive and usable and consistent across all the different platforms and devices that you're gonna get into or that your users are gonna be interacting with your site on. And Drupal 8 is aware of this and it's baked into every single part of the system. So mobile, boom, first big thing you have to be thinking of. And Drupal 8's got you covered, so that's great. Number two is, well, mobile's not enough. You have to be extremely flexible because new stuff is coming up all the time. Damn you, Apple, the Apple Watch. I have no idea what I wanna do with this thing, right? I don't know how to program for it, I don't know. Drupal knows what to do with it, right? Because we've been, again, seeing such this proliferation of devices and ways that people interact with things. You ever seen like the billboards you can tweet to? Those are fun. I'm just gonna put a tweet up on this billboard. They're gonna do fun stuff like that. For those of you who don't know, there's a basketball game here tonight at 730 at the Staples Center. So at about five, just about the time we wrap up, like 25,000 people are gonna start coming to downtown looking to have a good time. Yeah, who knows what they'll be interacting with things on. But Drupal has, again, always had these ways to adapt. So you know you can create new content types. You can create new view modes and view modes to have to do with how you display your data. So you can tie a view mode to a specific screen size using the breakpoint module, which is really, really nice. The views module is baked into core now. You don't have to download views and C tools anymore, which is really nice. And one of the things that they've done when we talk about flexibility, which is kind of hard to talk about in an abstract way. With views, you can do things like say, I need to create a rest endpoint to deliver content to these Apple Watch devices because Drupal probably is not the best way to serve directly to an Apple Watch. There's no web browser built into the Apple Watch, right? So they can't go to your website. But what you can do is build an Apple Watch app or an iOS app that requests JSON data from your Drupal installation, right? And you can do that now in Drupal 8 core without adding any modules. I created a rest endpoint and it looks like this. In a minute and a half, right? That's kind of exciting. And that kind of flexibility is really, really critical because even for the smartest of you in the room, you don't know what the web is gonna look like in 2018. We have some ideas, we have a little bit of influence over it, but we don't actually know, right? It could be that some kid somewhere in Nicaragua is inventing a shoe thing that will be the biggest thing in the world, right? You're gonna be like reading stock quotes on your shoelaces for all I know, right? Drupal 8 can actually handle that use case because it knows how to talk to your shoelaces. There, I love ad hoc, I love ad living, it's fun. So again, this is as technical as the presentation gets, the other thing to note, and this is for those of you who are new to, how many of you are new to Drupal in a room, by the way, or never used it? Don't know if you wanna use it. In particular, we find people who are hesitant to use Drupal because it can be hard to hire Drupal developers, it can be hard to find folks, or perhaps you have an existing organization with existing skills and PHP's not one of them. Drupal 8 has been rewritten from the ground up to be much more of a framework application. It's finally, after 12 years, adopted an object-oriented programming interface, which is really, really exciting. From a technical perspective, it's got really cool stuff like PSR4 auto-loading, which is so nerdy I'm not even going to explain it, but it's cool. It's composer-powered, which means a composer is the way modern PHP apps are built by combining components from different projects, and I'll show you that in a second. And that allows for what we call library sharing, or what you'll hear people at other sessions, although, you know, the week's over, but what people call proudly-invented elsewhere, right? Which means that in Drupal 8, we actually pull in code that was written for other things. These are the 20 embedded libraries of PHP applications that exist inside of Drupal 8. And I'll give you one example, one simple example. Guzzle HTTP is in here. Guzzle is a very, very good, very, very robust protocol for creating HTTP requests so you can retrieve information and share information with other services. We used to have our own homegrown functions for this that were weird and buggy and complicated. Now we have Guzzle, which is a very, very powerful, well-documented and stable API, and we just borrow it, right? So literally, when you're starting to develop Drupal 8 applications, you can be pulling in code from other systems and writing just a little bit to tell Drupal how to talk to it, right? So this, from a flexibility standpoint, is really, really exciting. What it means is, and I have a slide for this, means there's more resources available to us. This has always been one of the strengths of the Drupal community and of the Drupal project. I was talking to Damien, to a node, Damien works for Commerce Guys, he's really smart. He's been architecting PlatformSH, and he said, you know, what the actual strength of Drupal is the shared knowledge that people bring to the problem space. It's not the code, it's not the platform, it's the fact that everyone's working on similar problems and they're willing to talk about it openly, right? The shared architecture, the new approach to how we built the Drupal 8 core makes that even greater, because now we can pull in people who know nothing about Drupal, right? If you didn't notice the symphony folks who are hanging around here, it's fun because, you know, Dries gets mobbed everywhere he goes, he can't sort of walk through anonymously. There's a Dries-level famous person here named Fabien Potentier, and no one knows who he is. Fabien loves it, he just sort of walks around, but he's one of these guys who's big into code reuse, right? He's the symphony project lead, but this gives us a lot more power and a lot more flexibility moving forward. So the next piece I wanna talk about, again, we'll get away from the sort of code-level stuff, is accessibility, and this is huge, and I'm gonna take a slightly different spin on it. Accessibility is one of these things that's sort of hard for me to show. There are guidelines. I think I spent a lot of time with the higher ed folks this week and the higher ed folks all have to follow WCAG 2.0 standard, they have to follow Section 508 standards because the Department of Justice is actually suing state institutions, people who take federal money if they're not accessible compliant, if they're not, you know, putting alt tags on images, if they're not properly supporting screen readers by using properly nested H1 tags. Now it's not very exciting to look at properly nested H1 tags, I wanted to try to talk about accessibility in a slightly different way. There are, again, typically four major things that people think about when they talk about accessibility, you know, site problem, hearing problem, mobility problem, cognitive problem, and I'm gonna add language and I will explain why I'm gonna add language here in a second. And I will note, by the way, that we had sign language interpreters here at the conference, it was great. And I've seen at least one blind person walking around. So this is a problem, but people do tend to think of accessibility as a sort of minority issue that there aren't that many people affected by it. And I'm gonna argue that that is just plain wrong and here's why. Oh, and this is great because my director of operations is in the second row. We just launched some new software as a service platform for CRM that I'm supposed to use at work and I can't read this on my machine. I have a 25 inch monitor that's high depth and this is freaking gray text on a white background at nine point. And I have to get four inches away from my monitor, read it. I am 46 years old. I'm wearing progressive trifocals. This is a map of population demography in the United States. That orange line is the percent of the population under the age of 60 right now. Excuse me, over the age of 60 right now, right? You see that the millennials are actually kind of at the top, that blue line, right? The 19 and unders and the 20 to 39s, right? They don't change that much. And by the time we hit 2045, the over 60s will be dominant, right? And that is gonna have a huge impact on what the web looks like, right? And I doubt those people will be using their shoelaces to read stock quotes. They will probably have wall size screens that they can just gesture at and anything they want pops up on it, right? But they'll have to be wall size because I cannot read nine point gray text. And by the way, that application, which is great, doesn't let me change the font size or color in any way. Fork it. Fork it. It's a paid software as a service platform. I can't fork it. Anyway, so again, this is why it's not really exciting to talk about accessibility in Drupal because this is how you know it's accessible. You look at the code, right? We have good, clean, semantic markup. The front-end team in particular on Drupal has been working very, very hard to make sure we have accessibility standards baked into everything because, as I said about mobile, it's so critically important. And then I did wanna talk about why I included language in here. And I love this. This was another fun part of my research. This is a map of LA County census data from two years ago where you'll notice that English as a first language isn't even a majority. It's a plurality, but it's not a majority, right? And if you do the demographic shifts over the next 40 years, this gets much more extreme, right? So if you're in LA and your website's not in Spanish, you're throwing 30 to 40% of your audience out the window, right? So that's why I wanna talk about language just a little bit in the concept of accessibility. Drupal has always been multilingual and it's multilingual in a much better way. And it's funny because a couple of years ago, I said I've been in the community a long time, I asked Dries why Drupal is multilingual because I told it, my argument would be if an American had created it, it wouldn't be. You have to remember the Dries is Belgian, right? In Belgium they speak three languages, right? Dutch, French, German. And those are all official languages and all government websites have to support all three, right? And only after you support those three can you add English. So as a Belgian student, when he created a content management system, he baked multilingual into it. Now, multilingual has been a thorn in many people's sides in Drupal 7. You take something like 56 modules to do a properly translated site in Drupal 7. In Drupal 8, you can add, I added Spanish language in two minutes. This is actually, you basically say I wanna add Spanish, you hit a button and it starts downloading stuff. And when the download ends, it's like, oh, hey, look, it's Spanish. So this is like the admin interface. There's something like 8,000 strings in the admin interface and 7,980 of them have been translated into Spanish, right? Automatically, it just happens. And then the editorial interfaces can become in Spanish. So when you go to a piece of content, you can say, it'll tell you in fact, oh, this is only in English. Does it need to have a Spanish translation? Go ahead and add one. And so I go in and I add one. And then it says, hey, here's my new thing, which is great. The other piece I wanted to say about accessibility does go to editors. The editorial experience in Drupal 8 is much improved. We moved a lot of the seldom used tools off to the right hand side, which is great. They get out of your way during mobile. There's a WYSIWYG editor baked in, which is really, really nice. And then there's one thing that we don't make a big deal out of, but is going to become huge. And that's the tour module. The tour module lets you map different semantic components of your page, little components of your code, to tooltips, to interactive tooltips. So you can guide people through use. So this is an example of the tour module being used for views. And I consider this to be an accessibility issue, because it's about making it easier for people to do things. OK, we're moving right along. Security is, again, the next to last big topic I want to talk about for modern web applications. It's also very hard to visualize. It's not very exciting. It's really exciting when things go horribly wrong and you get hacked. I did that this morning. Yeah. No one says lead anymore, do they? I am very 2004. I love it. I mean, most of the web is actually going to be moving to HTTPS very, very soon. It's already started. Just like Google is promoting mobile higher-in-search results, they're going to start promoting HTTPS higher-in-search results. Drupal 8, of course, supports HTTPS out of the box. They're not doing any more session mixing like we did in Drupal 7, which is a security problem. I know. No more mixed sessions. You have to pick one. Sorry. The other thing that I love, we talked a little bit about some of the semantic markup and other good things. They use Twig now. Twig is actually a symphony component. It's a templating layer. And it's very exciting for developers and for designers, because it looks like most modern templating systems. And that's great, because we don't have to use PHP template anymore. And we're not using custom Drupalisms anymore. We're using a markup syntax that looks familiar. Well, why is this in my security piece? Because what Twig does is takes your markdown code, or your markup code, and then compiles it into runtime templates. And it doesn't let you put insecure code in your markdown. So this is for the developers in the room. That means no more SQL queries in template files. And for those of you who don't know, putting SQL queries in template files is bad. And generally the number one way to get your site hacked, because it can very easily open exploits into the system. We saw a case of this recently where someone had written a module that had a template file with it that was running exec in the template off a post, which basically means that anyone from anywhere can take over your entire server. Twig does not, huh? That, yeah. That was a sandbox module, fortunately. Twig doesn't allow for that. And so it's a big step forward for security. This is, again, code. I apologize. I noticed this this morning, because I was brushing up on my slides, the Drupal 8 has a new configuration system, configuration management system. You can put your configuration in the database or in the file system. And you can put your configuration in the file system outside of the web route. And that's what this code does. And that's great. Like, hey, I don't want people looking at my config code. I don't want people even trying to look at my config code. And that's great. So yeah, the security stuff is, again, hard to visualize, because it's like attacks against machines. But I did want to say, the other part to security is that ability to sleep at night, to say, hey, everything's going to be fine. And part of that is also about workflow. And configuration management, which allows for the export of all your configuration into code, is very, very powerful. Features is not quite dead in Drupal 8, but it's a very different thing that gets to go back to doing what it's good at, rather than what we use it for. So configuration management supports continuous integration workflows. It supports all those things that modern web deployment, the DevOps community, really, really needs. So that's very, very exciting. So I'm going to switch and take off my technical hat again. I love this picture. I've been waiting for two years to have an excuse to use it, because I think it's a memorable photo. So this is that last component. It's that sort of effervescent thing that you can't really describe, which is the modern web, your application, your website, your interactions must be memorable in some way. There must be some reason for folks to be recommending that you get used. It's a very viral, excuse me, very viral environment now. Pardon me. Lunch, everyone. Typically, people think that means jumping into design. Oh, I can wireframe it out. I can get what I want to have on the page. And a lot of people do this wireframing without doing user testing, without letting people interact with prototypes and see what it's about. People want to jump in and talk about color schemes and photography and all the really fun stuff. And what I'm here to tell you is you can't concentrate on the fun stuff until you concentrate on writing down what matters. The biggest thing to make your site memorable is to know what you want people to accomplish and to make that possible. I'm going to speak kind of, I come from a development background. I like easy, please, pick one thing. At the outside, maybe pick three. But one thing that you want people to do and make that the best you can. But that means actually studying your business or hiring people to study your business and knowing what are my competitors doing, what will make me stand out. Where does my money come from? And you can only do that by writing out your use cases. The other thing you should do in that case is write out your personas. This is a persona map. Persona is simply a representation of the type of person you expect to interact with your site. If you don't know who your personas are, you cannot properly build the application because you don't know what Mary is a fictional person. She's a nice fictional person. We don't know what Mary, if you don't know what Mary wants, you can't build something that's gonna work for her, right? So, I promised to talk some about, again, it's redesign and I would make the statement that I'm gonna assume it is 2015, no one is starting from scratch, right? Everyone has existing websites. It's not a case where you just get to make up new stuff. You have to either repurpose or reassess what you have been doing in many cases for the last 20 years, which is very, very exciting. There are, for those of you who don't know, three ways to upgrade to Drupal 8. Number one, there's update in place, which basically means Drupal 8 ships with basically an update process that will say, install the new code on my Drupal 7 site, run some functions and boom, it will work. That part is still being finished. That part is kind of dangerous, but it does work and it will work when Drupal 8 is released. Typically, what I find is people do the second option more frequently, this rebuild and migrate. That's the more popular strategy for Drupal 7 and I think will be very popular for Drupal 8. And that is where you take advantage of the new features and functionality and the new way that Drupal 8 works. You rebuild the site properly and then you migrate across the content that matters, the information that matters. And then the third part, the third way you can do it is just to start over, right? Just throw everything away and reimagine, which can be time consuming and expensive, but if you already have a site in place, you might be able to afford to do this. I actually recommend number three very highly, but no one ever takes me up on it. The thing I wanted to say about any of those three things is none of them are magic and machines are not gonna do it for you. Whenever we do a migration or an upgrade, we then build editorial tools so that you can review things, right? You're going to need editors, you're going to need to plan for it, right? And that sort of leads me to, I promised a shift in the talk and this is the big shift. I spent a lot of time again with the higher ed people, the higher ed people are great. How many people in this room were at the higher ed summit, because I was? Yeah. And they were all talking about horror stories and the problems they're facing and guess what? None of their problems are unique. All the universities have the same basic problems. And guess what? None of their problems are technology problems. They're all training problems or staffing problems or governance, what we call governance problems. The big thing, and it's funny because again, I am a director of development, right? I am a technology service provider and I'm gonna stand here and tell you none of you have technology problems. Drupal 8 is actually part of a whole ecosystem of CMSs. They're commodities, right? You can get the same functionality from almost anywhere else and sort of the rest of this talk to tell you what does that mean for you and why would you wanna pick Drupal over something else? But the technology itself is not going to be, it's not gonna make or break your project. It is not going to be so clear cut that you pick one over the other because it has feature A or feature B. All the stuff I just talked about with mobile and flexibility and all that, that's not secret. Everyone knows it, right? Everyone in the technology space knows it and they're all targeting the same thing. So my big warning is that you don't wanna have a technology fetish. I use this slide all the time. I used to work in the newspaper industry and we used to have to do paystups and all this stuff. This woman looks so happy because she got a new machine and it makes her life perfect and it's baloney. Excuse me. Pardon me. This is Mark Bolton. Mark Bolton did the Drupal.org redesign. He was the lead on that project. He also helped write the seven theme that we use for administrating Drupal sites and this is a great quote from him that we spend all this time on technology. We spend all this time on code and things like that. And we forget the personnel stuff. We forget who's involved. So again, when I say, okay, you're doing a redesign project, who are the people involved? Who's on your team? Who do you need to add from a supplemental capacity? We've been talking to people all week. Again, we have a booth. I'm here, I am selling things and we keep saying to people, what can we do to help you be successful? Because we are gap fillers for your organizations. All the service providers in the show hall, that's all they are. They're gap fillers because you're the folks whose name is on the line. You're the folks who have to live with this for the next five, 10 years, however long, right? You're the folks who, heaven forbid, get fired if the project goes badly, right? So people and what you have to do for the people is you have to set boundaries and milestones. So I like this little track slide here, right? Boundaries and milestones. How are we gonna get where we're going? So we're good on time. I'm watching the clock. I'm gonna recap a little bit and then we'll talk about strategies for getting where we're trying to go. So number one, remember the web is everywhere. It is ubiquitous. It's so ubiquitous that I haven't logged into Wi-Fi all week because I have a good LTE signal and I've just been using my phone everywhere I go. So anytime I have a spare five minutes, I check my email. Great. The audience is tremendously fragmented, right? This is just devices. The devices are, the variety of devices are just indicative, they're sort of a manifestation of the variety of interactions that you might have, the varieties of customers you might have, right? Massive fragmentation in the audience. I love this one too. The audience is very, very distracted. They're always doing something else. Your website, your application is almost never the most important thing in their life, even if they're interacting with it right now, right? How many of you people, by the way, are multitasking while I talk? Thank you for being honest. So our job, and again, I'm a technology consultant. Our job, everyone in this room, our entire job is to focus people's attention properly. So they can, and I'll be honest, so they can do what you want them to do, right? Okay. So we have strategic components to that. Five big ones, right? And these are the kind of things you might hire people to do on your behalf, especially if you don't know what they are. Content strategy, right? What's my governance model? What is my sales funnel? What is gonna get people to respond? How am I going to test my messaging? Technical architecture, that's pretty straightforward. Data migration, this is a huge one. I talk to a lot of folks who are very, very comfortable building Drupal sites, and when you get to data migration, they don't know, they're afraid. So that's a big deal, because again, you're not starting from a blank slate. All right, the first big project I did in Drupal 4.6, we had to pull across a quarter million news articles, spanning 15 years, and it took us three months. It was fun. It took us three months and a high-level C engineer. Now you can do it in much shorter. Systems integration, this is the other big place where Drupal 8 actually is going to really shine in the systems integration realm. One of the big problems for folks, especially we're gonna be talking to university folks, but a lot of people still are stuck with proprietary systems that have bad API management. You can't just go to your vendor and say, hey, can I have a REST API endpoint so that I can talk to my circulation management system to make it easier for customers to put a stop on the newspaper delivery. The circulation management people look at you like you're cross-eyed because their business model is stuck in 1986, all right? And this is true across many, many industries and many, many services. So systems integration is a big deal. And then security. Security review is gonna be a huge, huge problem. So things we always ask people to consider when getting into a design project or a redesign project or a web launch project. And I'll touch on each of these points in turn. You want to develop in an iterative process, which simply means don't try to do everything at once, right? We'll talk about that here in a second. What is your staffing and training model? The first, I said I've been to 17 Drupal cons. The first one I went to was 2006 in Vancouver. It was because we were building this giant newspaper platform in Drupal 4.6. And I went to do my due diligence because my name was on the project and I came back with a report to my superiors that said, yes, Drupal 4.6 is stable enough and will support what we need to do. However, we need to hire three full-time people to support Drupal and one of those people will spend half of their time interacting with the Drupal development community to make sure that our interests are protected. And this is still relatively true for large organizations, right? Now, if that number scares you, those three people, we're talking about supporting 15 newspapers, right? 15 websites. Yeah, and that's about right. What's your long-term support strategy? Right? How are you gonna maintain things? How are you gonna perform strategic updates? How are you gonna know you need to perform updates to functionality? Are you doing A-B testing? Are you doing more content strategy as an iterative process? And then this is another big thing, this is the last thing I'll hit on, is sort of this, what's your risk tolerance? Particularly as we're talking about Drupal 8, which is I think everyone knows by now is still beta software, right? So, iterative development. How many of you use agile development techniques? Hooray. Agile development techniques are very, very good and very, very important. And for a different reason, I think they're often sold as. They're really good because they let you focus on what's the highest value, what's the most important thing? You know, if I say you can only pick one business goal, right? You're a university, great. What do you want? Alumni donations or admissions or retention? And I've talked to different people and I've gotten all three of those as different answers. Right? Iterative development processes let you hit that. They let you set small milestones and say, I'm gonna release when we do this. When we talk about DevOps being really, really critical to success, this idea of being able to do continuous improvement, Amazon does things like 20 updates to their code every day. They're always rolling out new code and if Amazon's down for a minute, they lose something like $10 million in sales. And so they have this smooth process by which they're continuously making improvements. Right? You can do that too. It's not that hard. You just have to plan for it. Right? And this also goes again from an agile perspective. And I'm gonna be selfish. I'm gonna be speaking as someone who manages the development team. Please, don't tell us what you want us to do. Tell us what you want the software to do because we can figure it out. Right? Focus on what you know best. Focus on the business goals, the business outcomes. Right? It's really, really tough. I'm in management now and I have this problem talking to my own people. I always wanna solve their technical problems and that's not my job. My job is to tell them what the technical problems are. Right? I need something that will do this. I need to solve the DevOps problem. Right? Not my job to tell them how to do it. Right? Because they're smarter than I am. That's why we hired them. So staffing and training. This is a good one too. This is Hampshire College. This is a project we actually did. I love this project because three people built this website in six months. I talked to them for an hour and a half a week the entire time just to see what are they working on? What do they have trouble with? Instead of trying to do like two weeks of training and teach them everything about Drupal, instead we built a project plan that let them incrementally learn so they could take ownership of the entire project. Right? It was really, really effective. Really, really happy about this one. But staffing and training, they're actually in trouble now. They came back to us to help them with a redesign because one of their two developers got a better job. So they're a person short. But that's a huge piece, right? This again goes back to my first report. Hey, you need to have three people working on this stuff. You need to be able to support it. So yeah, what is your staffing model look like? Right? Please don't assume that your existing staff can just handle it. You have to do an honest assessment. This one's got text on it. You probably can't see it. Again, long-term support. How do you plan it? Right? How do you put milestones around it? Ideally, you keep that same iterative process going. You'd be able to work with a support model that says, you know what, every two weeks we're gonna really release new upgrades. Right? We're gonna be able to do this. And you have to know things like in Drupal, security updates come out on Wednesday afternoon. They tend to come out of around one o'clock Pacific time. Right? And that has to go into your long-term support strategy. You have to know how to handle that. Who's gonna do it for you? Who's monitoring that? And then again, these strategic updates. The, one of the more painful things is that, you know, wireframes and ideas that sound great on paper, you know, two years ago might not work. Or they may no longer meet the needs. Or you may be in a new line of business. You may be trying to accomplish something else. So you have to have some kind of planning around. How do I make those updates? Right? So these are the conversations I want you to be having with your internal teams, with your vendors, with people here at the trade shows. Like how am I gonna solve these problems? Right? Now, I'll wrap up by talking about Drupal 8 a little bit and some of its risks. I love that this is a piece of art in our office. So we have a risk of giant robot attack. Not true. Whoops. Based on current projections, Drupal 8 will come out in September 21st, which is kickoff of DrupalCon Barcelona. This is from a week ago. There's actually a website that tracks the critical issues. And I actually have a really smart person who works at Palantir, Larry Garfield, you know, Ms. Krell. And I said to him two weeks ago, I said, give me a hit list of what are the big risks of Drupal 8 from a technical perspective? And he came back and he gave me a nice little list. Not all the APIs are done. There might be some minor API changes still. There's some things that are being worked out because they're being tested still. There's still some changes in the theme layer that may or may not happen. It's not fully settled. It's pretty good, right? It's stable, but it doesn't mean it won't change. This third one is actually the biggest one. It's the biggest thing that scares me at the moment. Drupal 6, Drupal 7 are both covered by the security team. Any stable module release is covered by the security team, which means we don't discuss security holes in public. I'm actually working on one right now. There's a known security hole in a module that I'm familiar with. I've written a patch. But we don't talk about that publicly because if we did, people could exploit it before we released the fix, right? Drupal 8 is not under that because it's still beta software. So if there's a security issue uncovered in Drupal 8, it's going to get talked about publicly immediately, which means if you launched on Drupal 8 last week, you could be vulnerable to something that someone discovered this morning. What does that mean? And let me say, the likelihood of that happening is pretty low. What it means is you just need to have someone monitoring these things, right? It's part of your staffing issue, really. Contributed modules aren't all ported. I'm working on a couple. A lot of people are staying for sprints and working on some. But what we found actually is you don't necessarily need them. And I'll show you in a second. And then hosting support is a bit of a challenge. I did talk to AQUI this morning. They're ready for it, right? Pantheon folks are ready for it, PlatformSH. Blackmesh, all the folks on the floor are ready for it, but some of the smaller hosts might not be. Our PHP version requirement went up. You can't run Drupal 8 on PHP 5.3. Then you might need to find a new host. You might need to reconfigure some internal servers. These are issues. We have not taken the plunge and built a Drupal 8 site. This is Memorial Sloan Kettering Cancer Center. It was built by our friends at phase two. Since I've known the guy who was the technical lead on this project for 15 years, I had a beer with him on Sunday and he told me all the dirt. And the report was that they loved it. The development team in particular loved it. And the client loved it. As I understand it, they went from 150 contributed modules in Drupal 7 to seven contributed modules in Drupal 8. And they did not lose functionality. Because as we talked about the stuff that's baked into Drupal core, you can just do stuff. Schnitzel, whose real name I don't know, who works for, yeah, go ahead. How many of those modules are related to translation? I don't think any, because I don't think they do multi-lingual. Right. Right, but there's someone in a phase two short. He'd be happy to talk to you about it. See, look, I'm, huh? Mikkel Schmidt. Mikkel Schmidt's a great guy. He lives in Zurich. That's why I can't pronounce his name. But he did a presentation on Tuesday where he was talking about their lessons from Drupal 8. And I forgot where I was going with that. But he said the exact same thing. And he did have to do multi-lingual. And he went, I mean, they just threw out most of the modules. I think they're using like two contrib modules on one of their sites. It's really quite stunning. Oh, that's what I was gonna say. He figured out that the first module that I ever was thrilled to find in my Drupal experience is called NodeQ. Everyone use NodeQ? The first module I was going to write, and then I found that it existed. And it had been released like a week before I needed it. NodeQ's not ready for Drupal 8, but you don't necessarily need it because you can do everything that you might do with NodeQ using the block system. Because blocks are now fieldable. And you just add entity references to the block and then you sort them how you want. Which is just fascinating. As I understand it, however, this is again one of those risks. In the process of this, as I understand there were 53 core patches approved for Drupal 8, which does get me to two things I wanna end on here, really. One is what do you do about these risks? Well, proper risk management is the actual solution. How many of you at your organizations practice formal risk management? Okay, there's a session we're gonna do next time. Risk management is not actually very hard. Everything I know, I'm gonna plug phase two again. Everything I know about risk management, I learned from Nicole Lind, who's like director of VP of strategy at phase two. You just chart it, right? What's the risk? What's the likelihood it's going to happen? How bad is it if it happens? How are we going to prevent it? Right, and the classic risk is at the bottom. Yeah, oh, we're building a new server and it's not ready. You cannot launch without a server, right? That's a fatal risk. You put someone in charge of that. And every time you have a status meeting, you report on risks, right? Your project actually will not succeed if you can't talk openly about risks, which is why we're talking openly about risk and droop late. So why would you jump into droop late now? Why would you jump into open source at all? And this sort of goes to where I want to lead the question and answer, because I have two slides left at 15 minutes. Told you we're getting out early. Why would you take these risks? Why is it important? Drupal 8 is actually in the exact same position that Drupal 7 was. Drupal 7 got out the door because two or three very large organizations wanted it. The examiner was one, US House of Representatives was another. And it is not a coincidence that Drupal 7 was released on the same day that a new house was sworn in. Not a coincidence at all. Because the house isn't gonna use beta software, right? It's just not gonna happen. So Drupal 8 is actually ready. I actually came, I was skeptical when I got here this week and now it's like I want to build a project. I want to build several projects. And in fact we have to, right? Because that's the only way it's gonna get finished because literally if you look at the bug countdowns and things that are here, there's like 25 critical bugs left. There may be others, but we're not gonna find them until we actually try to use the stuff, right? So the question then becomes, well why the heck would you do that? And I like to end on this slide for that very reason. Red Hat, as everyone knows I think, is the biggest open source company in the world. And they still run into what we call FUD, fear, uncertainty, and doubt about why people would use open source. I heard a horror story about this yesterday that someone had a project that was in the risk of getting canceled because some VP in some other division found out they were using open source software. Oh, it's insecure. No, actually it's more secure. And it's more secure because we publicly talk about our insecurities, right? It's a paradox, but it's true. The reason why people band together at events like this, why they're what, 4,000 of us here is that we're all stronger together than we are apart, right? So why would we waste money solving a problem once, right? It was a great moment of my day before this talk actually, this talk's a highlight of my day. But the great moment of my day over my entire week, a woman came up to me and said thank you for something I did four years ago. She said, I've been looking for you all week. I'm glad I caught you. Wow, actually what I did four years ago is I was nice to her. She had a problem. I answered it patiently and thoughtfully and it solved her problem and she was thrilled. And guess what? She's been doing that for other people ever since, right? So there is, when you get into the open source community and hopefully you've gotten that spirit this week. I mean, yes, we've just talked very honestly about problems that we face, about challenges, about risks. But all these other folks are in the same boat, right? That's why I'm talking, the phase two guys like, yep, you should be building sites. He's like, I need you. He needs me to build sites. He wants me to build sites, I can tell. Yeah, that's what Toby told me. Toby said my developers are not going back. Yeah, they know, they will mutinate. So again, let's not waste time. Let's not waste resources, right? Collaboration, I sort of last story and then I will open for questions or we can just leave early and get good seats for the closing. I was at lunch with a bunch of folks who all work at different universities in California and they were talking about collaborating on a Drupal 8 distribution to make all of their lives easier, right? And that's why when you're thinking, again, redesign, you've got to think, I spent a lot of time talking about what are your business goals? But there are also sort of community goals and broader goals, right? What are you trying to accomplish? Do you want to be a software company? Right? You probably don't, right? So collaboration helps you get away from that. So again, that's the end of my formal talk. You are encouraged to go and fill out a survey online and say nice things or bad things about me so that they can improve the program for next time. We do have a microphone if you have questions and if you don't, I'll be happy to stay and answer them privately. Thank you. And if you don't want to stand up, I will repeat the question for you. So it wasn't long ago that Drupal 7 was the new thing and we're telling our clients you got to get on Drupal 7 and they're all excited. You'll never need to upgrade again. I mean, obviously, Drupal 8 seems like it's a better answer but how do we answer that question when the client says how do I know we're not going to do this again in a couple of years? Right, so there are a couple of ways that I could answer that. I'll give you the honest answer of what we tell our clients and what we tell our clients is to skip versions. So we don't usually take people from six to seven. We don't usually take people from seven to eight. We're more than happy to do so. But the first projects we're looking at are six to eight conversions. And probably the meat of our stuff in Drupal 8 will be people new to Drupal. And we do have very honest conversations in the sales cycle with folks about what's the ROI on the project. What's driving your deadlines? What's gonna drive the end of life for the software? I mean, Drupal 7 is gonna be viable for the next four or five years. Drupal 8 will be viable for the next six or seven. Jam, you're gonna tell me I'm wrong? Go ahead. Yeah, my point was actually to completely agree with you. I've done several sessions since January about it's basically a decision matrix. Who should be using Drupal 7 right now? And who should be using Drupal 8 right now? And there's a whole series of decision points, but the fundamental question about, oh my God, now I have to upgrade again. Drupal 6 has been supported since 2008 and Drupal 7 has been supported since 2011 and the incremental release cycle in Drupal 8 will mean Drupal 7 supported longer than any previous release in the history of the project. So it's money very, very well spent to stay with Drupal 7 right now. It's not bad all of a sudden. We're building Drupal 7 projects still and we will continue to do so through the end of the year. I know we will and it is that risk reward and we again, put it right in front of the client. Say, hey, it's your money, it's your time, where do you wanna go? Right, so. Yeah, Michael Schmidt made that point too. He's like, we just don't tell them. We just say, hey, we're gonna do a new site for you, we're gonna redesign your site and then you just do it in Drupal 8 and don't tell the client and the client doesn't care. He literally did this in his session. He said, yeah, they used to be using Drupal 6 and they're like, wow, the editorial interface is much nicer than it used to be. Can we have this on our other sites? Anybody who wants to watch this later is not gonna hear a word you just said. So the point that he made is that the actual experience of being in the Drupal site isn't that much different. And so any, so it's not actually gonna change the user experience, it's more about what can you do with which version right now and what are your needs in this moment and what are your projected needs over the life cycle of the project. Right, so if Drupal 7 fills your needs and everything you can do and you don't have to write a ton of custom code then do it. Yeah, and like I said, I spent all week with the higher ed folks and I said, you know, the only two things that worry me about Drupal 8 is what to do with LDAP and Shibboleth which are the two big authentication systems that universities use. And I don't wanna rewrite those and I don't know if they're ready yet. Everything else I'm not worried about. So I have a question about the migration stuff. Okay. It all seems very relevant to what we're talking about. And this probably exists somewhere, I could probably go read it but one thing I've learned in my UX sessions is that people don't read and that includes me, I guess. So the question is, I'm thinking of the options, the three options that you gave and we have a very robust seven site and so I'm thinking that. But I also don't like, it was developed by outside developers and I don't like the way they did a lot of things. We use a lot of templates, a lot of PHP templates and you're already explaining the dangers and hazards there. You probably have 50 of them. So I'm thinking I'm not going to do an upgrade. That path is not a good path. I'm probably going to rebuild so that I can do it in a much more efficient, safer method. But I have 3,000 pages of content. Does the migrate module, because I'm not very familiar with the migrate module, but is there a way to just say, okay, look, I want everything, it's in my body content areas to migrate to my new basic page template or whatever it is that I've used develop in Drupal A and just migrate that. Like don't try to bring everything else over because I don't want any of that stuff. I just want that one-to-one migration. Yeah, it's very, very possible. There are two things, two answers really. One is that parts of the migrate module are now in core and used for the direct upgrade path. And so you can leverage those to write your own custom upgrade path. Or, and again, this was something Toby told me when we were talking about Memorial Sloan Kettering, you can just write the API, the entity API is mature now. So it's very easy to just reach out to your old site, grab the data you want and run entity save and be done with it. So writing a very, I mean, you have 3,000 pages, that's nothing, really, it's nothing. We do migrations and they're like 300,000 pages. So you can write that in a pretty simple module of your own devising and be done with it in a week. If I know how to write the code, that is. If you know how to, well, you could probably pay me or this nice man in the orange shirt. Yeah, I hear you. We can write in about three days, it'll be fine. The question is, why would you want to, yeah. Oh, I'm not gonna upgrade immediately. I just figured this is something we're going to do at some point, I want to take advantage of Twig and all the other benefits that are gonna come with 8. Yeah, but this is where I want to. For the people that might watch this later, the question was why am I even considering upgrading to 8? And the answer is to take advantage of what's going to be an 8 that's not in 7. But this is where I'd go and back up to something that I said that you don't actually have a technology problem and it's not sure that you need to do it because, yeah, there are things that are gonna be much easier to do an 8 and much more efficient to do an 8 and there are advantages to it. But that doesn't, you have time. You don't have to rush into it if you're stable and satisfied with where you are. That kind of went without saying it. I mean, we're gonna definitely let it hit the road and see, you know, fix some bugs and then we'll. Yeah, yeah. But thanks for the answer. Right, so the question is kind of complicated. I will, for the video folks, try to summarize. It's a big site. It's on Drupal 6 now. They can't move to Drupal 8 until Drupal 8 is stable and released and the concern, the primary concern is that Drupal 6 will then be end of life and there'll be a three month window that, and I'm not sure where that three, well, that there will be a three month window in which they need to get off 6 and onto 8, right? So number one, I'm not quite sure where that three month number came from. I do know there are working groups around providing long-term Drupal 6 support, so I don't think it's gonna be that critical that you move that quickly. I would say that you can start planning for that upgrade now. We're in fact, hopefully gonna go back next. We can kick off a Drupal 8 project that's not gonna launch until, you know, November, December, because we can start doing all the content strategy work. We can start doing all the design work and all that business work of saying what's really, really critically important. So again, I think the community, there are gonna be solutions for how do I support Drupal 6, particularly in Drupal 6, what you need is security. You just need people doing security audits of things. And I think there is a solution for that, but I do not have the details off the top of my head. Was that a helpful answer at all? Anyone else we have officially a minute and a half, but I think we have big excitement, yeah. So it's the question of backward compatibility and the basic answer is no. Drupal is historically and famously not backward compatible. That's what the upgrade path is for. When Drupal 8 is released, there should be a direct upgrade path that lets you say, okay, I'm gonna convert what I have into the new formats basically. But what's gonna be really, really interesting why I think that most people are gonna rebuild and migrate is I think that you'll find, let's say that just for the sake of argument, you have 25 modules on your site now. We may find that 10 of those are not even needed anymore and therefore won't be upgradable. And so you may be forced to re-architect some of that functionality. So that's an interesting challenge. I will say that one of the reasons why Drupal 8 is such a, from the code side, such a radical reinvention, such radically different from Drupal 7 is to make backwards compatibility more possible moving forward. But we haven't decided as a project whether or not that's a goal for Drupal 9. But it's much more possible than it used to be. All right, we are out of time. Thank you very much. And whose cable is this? Whose dongle is this? You had the guts to. I really do want to know how you sold that to me. Thank you. Oh, really? Yeah, because, oh, thank you so much. They came to you and asked me. That's what I understand. I mean, I wasn't on the project myself, but that was the story that happened. That is fascinating. Yeah. We've had people ask about it. We have one.