 So I've got a four-year-old daughter. I just kind of put her on her leash, let her run in the backyard and lay down, go to sleep. So the session before mine, they were talking about usability research with children. And they're talking about how kids may not know how to use a track pad. They may be more familiar with a mouse. Well, my daughter loves touch screens. And I can tell because the television in my living room has peanut butter spread all across it until I trained her and told her that no, it is not a touch screen. I'm controlling it with my phone. So now she fights me for my phone. So that's not good. That's not good. So how far has everyone traveled? Is anyone not from North America in the room? Travel from further than that? No? Okay. Anybody from Mexico or Canada? Oh, very nice. Very nice. Glad to have you guys here. I hope the border wasn't too bad. Let's see. I'm just trying to kill time here, letting people filter in. So if anybody has any questions that's not related to my talk, that would be great. Yeah, so I myself, I'm coming from Pennsylvania, middle of nowhere, Pennsylvania. Every mode of transportation that I took to get to Drupal Con was late. It was fantastic. I take the train from my hometown to Pittsburgh to catch the airport. And it was an hour and a half late. So then got on my plane and it was three hours late. I had plenty of time to write my talk in train stations and plane stations. So it was nice. It was a good time. So we've got about another two minutes. We're gonna let people continue to filter in. Once again, there's a lot of people in the back. There are some empty seats up here. There's some empty seats over there. Get to know your neighbor, scoot over. So for those of us just joining us in the back, there are some empty seats over here and up here if you don't mind getting cozy with some people. All right, we just got a few more seconds before we start. So I'm a big fan and not punishing the punctuals. So we will begin on time now. So hello everyone and thank you very much for attending this talk, Maintaining Design Consistency Across Every Channel. This is a topic that I'm very excited to talk to you about today. I'd like to start by introducing myself. My name is Randy Oost and you can find me online as Amazing Rando, at least everywhere that I can manage to snag the handle. My personal work history includes a decade of working in higher education at the University of Pittsburgh as a design manager working on university-wide branding. After that I spent about a half a decade working at a 40-person plus marketing agency where I oversaw the digital team that created websites and digital experiences for all of our clients. Now I'm proud to be a web chef at Four Kitchens where I help our clients create rich experiences and meet their goals. So everyone is talking about how the future is decoupled. Drupal and WordPress are both pushing hard for this and with good reason. Separating data management from presentation allows for amazing things to happen. So your content goes everywhere that you want it to go. Websites, apps, devices, special content going to AMP, RSS feeds, Alexa, Roku, iPhone apps, blogs, microsites, websites, it goes everywhere you need it to be. And there have been a lot of talks about the technical progress of decoupling. I'm sure that some of you maybe have attended some today or yesterday or planned to for the rest of DrupalCon. But what about the design and marketing side of things? When do we get our decoupling? So how do designers and marketers keep everything aligned? So, and that's what I'm gonna talk to you about today. How do you handle large-scale design consistency or as I like to put it, decoupling for designers? The first, the, hmm, pardon me. The very first thing that you have to do is you have to get everyone invested in the process. This may seem like an obvious first step, and it is, but that's because it's vital. Maintaining consistency is a task that requires discipline and pays dividends when you do it right. There needs to be a central authority to oversee this, to maintain this consistency that happens. This can be a person, this could be an office. Sometimes it's just chief design officer, maybe you got one, or it's like a CMO, chief marketing officer, someone who's in charge of identity and design and visuals and interactions and this whole kit and caboodle and process. By making someone responsible for this, you empower them to maintain this network, which is a very important word, and also to grow this framework so that it can serve your needs. So, the big value is consistency and the design experience for centralizing design. Sorry, I was moving, this has really got a small range. So, let's talk about the value of design consistency so that we can get everyone on board. The first value is usability and learnability are improved when patterns are used. So, what this means is that the learned knowledge can be transferred to new contexts quickly. This is how you build rapport with your audiences as you expand to new devices. By having this consistency, users know what to expect. They know what the signup process is like. They can start on their phones and end things on their tablets or vice versa. Having an inconsistent interface, allowing the M.shop to do the mobile site and to allow the IOS shop to do your iPhone app and so on and so forth leads to inconsistent interface considerations. And it's like talking to users in several different languages. Only advanced users will be able to finish tasks in a scenario like that. So, keep it consistent and build a relationship to last with your users. The next value is the freedom to focus on the important things. We are all very busy individuals. We have a lot of things to do. So, we need to stop spending time solving the same things over and over again. By having a framework in place, designers and marketers can focus on the important goals. Work on that killer promotional art or a motivating call to action instead of fretting over what to do about the footer and reinventing the wheel. Get to your solutions faster by having this design framework. Bringing new people up to speed takes less time when you have documentation and tools for them to learn the ins and outs of your identity, your branding and your interface. This also applies to adding new teams or working with outside vendors. There's always this reticence to add vendors or outside contractors to help with the team because that onboarding process is so expensive in time and knowledge sharing is difficult. So, by having a framework to work from, you're able to spin those people up faster. If they have a question, you can send them a link to a URL where you've already written out how to explain that as opposed to having to actually take the time to explain it to each individual person that you're onboarding. So, this design consistency helps to reduce this friction involved with getting new people on board and with getting results. So, you can spin up people faster. It also, lastly, means that you have faster entry into new markets. You've done a lot of heavy design thinking to provide this framework, these interactions. You know your users. You know how they use your product or service and you've built this framework to serve them. And so, you can actually, whenever new markets emerge, you can enter those markets quickly. So, for instance, like talking cylinders and virtual reality or some of the newest areas in which we can start generating, creating and moving content. And when you have your design framework set up, you can address those needs faster. So, what goes into this style guide? So, now that we have everyone on board for consistency, let's define what this looks like. To me, I use the term style guide. I know that there are a lot of people who like brand standards, industry standards. There's a lot of different terms for these sorts of things. And I generally call it a style guide. So, let's talk about what this style guide is. So, for starters, a style guide is your North Star. This is when you're designing new interfaces or solving interaction patterns, your style guide is where you start. You reference what has come before. You reference what you have asset-wise and by asset that can mean everything from components that you've defined, guidance on how to write editorial copy, whatever the case might be, and you're able to reference that and making sure that everything is consistent and that you're solving for new problems and bringing those into the fold. So, this has to be your North Star whenever it comes to creating this design consistency. So, a style guide is a toolbox for creation. In addition to being this North Star, it's also a toolbox. So, it has to be a living thing that feeds into the things that you make. And we're gonna talk about some of the ways in which style guides can kind of feed into that, into what you make. But it has to be a living thing. It can't be a binder that sits on the shelf. So, inside that box, I divide it up into four separate things. You need branding information. You need to have a design language that shows visuals and interaction design choices. Editorial guidance on voice and tone, telling your writers when to be friendly and when to use formal language. And a code library for developers to implement. Now, you'll start to notice that there's a Venn diagram with the rest of the team. So, as designers and marketers, we dip our toes into code and we dip our toes into writing. And so, a style guide, a design framework like this really solves all of these needs cohesively. So, you're part of a team. So, a lot of my talking about style guide stuff, there is overlap and that's on purpose because that overlap helps you think holistically on what is going on. So, let's talk a little bit about this. Let's talk about branding. So, branding information is used to set guidelines for how your company or institutions core assets are used. This can include colors, fonts, logos, topography and more. It's the core of your essence. It's the green track jacket that you wear because you're a web chef at Four Kitchens. So, I mentioned that I worked at the University of Pittsburgh. So, I'm gonna pull from my past life at Pitt. Some examples here. You can see here that the University of Pittsburgh is using their style guide to help tell the story of the university itself. I know that that's too small for you guys to read, but basically it's starting to talk about the history of the logo itself. And the next several pages actually talk about how this mark is the latest incarnation from the original identity that was done in 1787. I don't know about you, but doing logo revisions on a logo that long, that was pretty awesome. So, another thing that the University of Pittsburgh does is that it makes sure that its language about what it's talking about is consistent. So, here we've got the University of Pittsburgh seal broken into a variety of parts. The labels are small, and I apologize for that, but the breakdown shows the name circle, the leaf sprigs, the Latin banner, and the shield and crest. This breakdown helps ensure that everyone working on Pitt projects is talking about the same thing by defining a shared language. So, they've actually broken up this complicated logo and made sure that whenever people talk about it, you know, like, oh, can I use the sprigs as a design element? Everybody knows, well, everyone who's seen this knows what I'm talking about. So, in addition to that, there's the universal, like, logo with a dotted border around it and arrows that goes into every branding style guide just to show how much space to go around the logo. Here, this particular page also sneaks in, and it's not going to be legible. It's the text that's in the blue. It actually defines its fonts here as well. So, it says use Janssen for the University of Pittsburgh text, and then it says use Helvetica for everything else. Let's see. The University of Pittsburgh also breaks down their color identity. Unfortunately, they are very print-centric in their particular branding guideline, and so they literally scanned the Pantone chips to put into the style guide. So, I thought that was charming, and so I thought that would share that with all of you guys. So, yeah, so they've clearly defined what their colors are, and I had to do a little bit of digging in the document, and I actually managed to find that they actually do have hexadecimal colors in the text, which they've omitted the hash before them, so I'm going to be writing a sternly written letter to my friends who work there. So, yeah. So, that's branding. Let's talk a little bit about design language, okay? So, your design language says a lot about who you are. It conveys a message of importance or friendliness to the people who interact with you. It helps build a rapport that keeps them engaged with you. So, defining design language includes things like your design principles, your aesthetics, your UX principles, and how to use motion, and so on and so forth. Anything that's relevant to helping a designer do their job is something that should go into the style guide. And so, I'm gonna be showing you guys a series of style guides that are out there. If you go to styleguides.io, there are a wealth of them out there. Many of them do a lot of things right. Some of them, not so right, but it's worth seeing all of them. So, the Lightning Design System, this is by Salesforce, and this is, I think, a really nice one. Their style guide is explicitly built to empower a large number of people to build on their system. So, whereas maybe some of the projects that you're going to be working on are working on your own style guide for your own team. So, maybe you're talking like 20 people or fewer might touch it. This Lightning Design System is built for thousands of people, potentially tens of thousands of people, because they, Salesforce offers up a large code base so that people can build apps. And so, they have done their due diligence to define stuff. So, it's really worth going through because everything is very clear. They have articulated a set of design principles. So, they prioritize clarity, efficiency, consistency, and beauty, and you can expect that everything in the style guide is based on this bedrock. So, these values, I mean, these are great values, who doesn't like efficiency. Efficiency through laziness is one of my personal mottos. But you have to determine what are your guiding design principles, and when you list them, then it really helps to orient for whenever you're creating new things. And they leave no stone unturned. They have animation style guidelines. So, they tell you how the recommendations on timing and effects and dimension to make sure that the entirety of the suite feels consistent. So, ease in, not ease out, or whatever the case might be, so that things are animated consistently. The Warner Brothers would be very proud. They even go so far as to provide you with a loading widget. Okay, this is a lovingly crafted loading spinner. Think about that for a moment. A lovingly crafted loading spinner. I don't think I would, I'd never thought I'd say that out loud. And not only do they define this for you, but they actually show you an example of this loading spinner in all the different places where your application will fail. Cards and lists and full screens. And so, you're not gonna be caught unaware of what is going to show up when. So, pardon me. So, in addition to this, Salesforce realizes that the people that they're working with, the people who are using this particular design system have a variety of skill sets. I'm sure that a lot of you are very familiar with code-oriented design systems. And every design system that I'm sharing with you today has code snippets that go along with it. But as a designer, maybe you don't, maybe like HTML, CSS, you really don't want to deal with the code quite as much. You wanna kind of let someone more skilled deal with that and you deal with the interaction design and you deal with the color selection and the visual effects and the UX of it. Salesforce offers sketch files. Everything that's built in their library, they've got a sketch file for, which means that if you need to build a Salesforce application, you can hire a designer, send them these sketch files. They can put together a UI for you using those components and then you can use the components that are in the, or a developer can use the components that are in the component library to build that out. And so what you have is every time a component is added to this library, it is added everywhere where it will be useful for the rest of the team. And then there's also, just to show that other design systems offer it, IBM's carbon design system actually offers sketch files as well. So everything that gets created has a code version and a comp version for everyone on the team to work with. So the next thing that I'd like to talk about is to talk about voice and tone. This is a part of a style guide that has a tendency to get overlooked. It's kind of, it's one of those nice to haves. And I mentioned it so that we can all collectively do a better job making sure that it's included. Voice is the core of your personality and tone is knowing what you're saying and how best to say it. So this is something that your editors and writers are going to need to know and even the people who are developing interfaces. Like, you know, do you say, do you use the term apply or save on a dialogue button whenever you're done? Like these are things that should be consistent and should be codified. So the gold standard for voice and tone comes from MailChimp. The personality of their app is a vital part of their branding. So they've codified it in a document that they call voice and tone. So let's go through some examples. Here you can see an example of a success message. At the top they give the author a context for how a person is feeling. This user is feeling relief and pride and joy. And so the suggestion to the author is to pat them on the back, use casual language and tell them to feel free to be funny. It's all good. But then here we've got a different story. As you can tell from the angry red color, something has gone dreadfully wrong. The person who the author needs to speak to is feeling confused and stressed and maybe even angry. So the suggestion here is to offer a solution or a next step while being straightforward. Remain calm and be serious. So they give you guidance on how to handle when things go wrong as well as when things go right. So the carbon design system, another design system by IBM is pretty awesome. And it handles voice and tone a little bit differently but no less clearly than what MailChimp did. So inside of the carbon style guide, when you visit the content section, you can read all about voice and tone and what they mean to the company. So they tell you why it's important. And then where MailChimp provided guidance and way of situations, carbon lists out writing principles as a backbone for communication. So do use active voice. Do use second person. And they tell the reader why they should use that and when. So they even go as far as to provide a glossary of commonly used terms. This ensures that everyone means the same thing when they talk about things and it reduces confusion. So let's move on and let's talk about code a little bit. I know that I've been talking about designers and developers but a good style guide includes a code section. And so style guides are wonderful things as long as you can implement them. So most of what we're gonna have here are gonna be code snippets for using components but this section also can contain development principles, how to architecture new components and define a review process. So we're gonna go back to the carbon design system for a moment and we're gonna look at a single date picker. This is a prime example of a component in a code library. It has the component displayed on the page to interact with and it has the code that you need to implement it right on the page. We're gonna see the same thing in the Yelp style guide. So in the Yelp style guide, they also have their components listed on a page. You can interact with them and they include code snippets. Here's the thing, we're facing a decoupled future and there are devices out there that require different code to run. Okay, so all of the examples that you've seen so far, HTML, CSS, some JavaScript, the holy trinity, it's all great, but there are devices that don't actually run that. So you've got Android devices and iOS devices and like Roku's and we all know we've got a long laundry list of things. And so your style guide, whenever you have these new arenas that you go into should be expanded to go into these arenas. So for instance, the Salesforce Lightning style guide, it includes Android code snippets, everything that they've built for their website. They've also built for Android. So you need to build an Android app for them. Boom, you've got it right here. They add a new component, it's added to this. It's fantastic, it's great. And they even make sure that iOS people aren't left out in the dust. Because you know we get everything last, right? No, but I tell you what, I was really surprised by this next thing. Salesforce serves window phone. All right, does anyone hear of a window phone? All right, good. But yes, they have people who apparently it's enough to justify them maintaining it for it and they know their user base and so like they provide code snippets for window phone. It's wonderful. So let's talk about how to keep a style guide updated a little bit. So because progress stops for no one, you need to have a plan for adding new features or removing old features. This is a living document. Things grow and change and shift and molt as time goes on. And so you need to have that baked into your style guide. I swear I'm not trying to push Salesforce on you guys but they just have a really nice style guide that has a lot of the features that I like. And so like here you can see circled is, it says prototype in progress for this app launcher feature. What this means is that you can use it now. It's available to you but you can actually, you know that it's going to shift on you or you know that feedback you provide to them would be incredibly valuable. I prefer to look at it that way as somebody who makes components. If it's broken, tell me please, please. And so you're able to see these sorts of things. So you can have a status marker like in addition to in progress, you can have soon to be deprecated or going away or unused and just track your various components. So now I want to take a moment and ask everyone to stop making style guide, a four letter word, okay. This is something, perhaps it's the fact that like I've got 20 years under my belt in the industry or something like that but most of my experience with the term style guide except for like the last two or three it has been synonymous kind of with failure. And the reason for that is that a style guide was a binder that sat on a shelf with a layer of dust on it. That was only brought out to resolve arguments and meetings. Okay, judging from the laughter I think everybody has some similar experiences but there are two problems with style guides that we have to overcome to make the use of them or to make the best use of them. Okay, and the very first one is going stale. You don't want to get dust on your style guide because it's sitting around going unused. So for a design to be consistent we have to consciously push all changes and new additions through the style guide. So what this means is that when you create a new component it goes into the style guide, it goes through the process and gets fed back out. And so that way it's maintained, it's consistent and it gets routed through that central authority that I mentioned earlier to make sure that everything is as it should be. Lost my spot. So a style guide has to be a living document. As best you can you'll want to integrate it directly into the sites and apps that you're building. So for instance, at Four Kitchens we've built a tool called emulsify for Drupal. It's a front end theme that is both a living style guide and a template system for Drupal that we use to style a site. So what that means is that if we change something in our style guide it will immediately change on the site. Like so if our card component we decide that we want to put a big rainbow border around it as soon as I merge that without Evan approving it it immediately goes live on the site and we've got to revert it. But so it's really nice that with your style guide as a dependency you can prevent your style guide from going stale. So the second problem with style guides the second of two is that a style that sometimes you get a strong pushback from designers due to an imagined sense of being restrained on what they can do. I'm a designer, I've been a designer for 20 plus years. I don't like style guides. I want to do that cool thing I want to do. So a lot of designers think that way. The reality is that a style guide should never be a restriction on what's needed. Using a style guide should be like using Legos. You can build whatever you want to out of Legos. If you don't have enough Legos, go get more Legos. Just bring it together. So for instance we recently built a project where a client was concerned about creating custom areas on key pages like a big hero at the top they would do like a lot of custom images and interactions and things. And we were talking to them about emulsify and like okay so we've got all of these consistent stuff and they're like well we've got these bespoke one off things that we make. Like we don't want to be restrained by the style guide. So we told them that the style guide was there to serve them. So we actually explicitly added a custom call to action widget in the style guide that was intentionally left blank. It was just called like, I don't even remember, like custom widget. And it was literally just a blank slate that we added documentation that's like put your bespoke snowflake here. And so they were very satisfied by that. And it's just an example of how a style guide is supposed to work for you, not against you. If it's working against you, you have a bad style guide. It should work with you. So we're getting closer to the end. So how do you make a style guide? How do you create and maintain a system like this? Not everybody is starting a project fresh from the ground up. Everybody has history and legacy. I mentioned the University of Pittsburgh. I worked there, I started in 2000 and at that point they had like 200 years of history. I wasn't starting from scratch. The first thing that you have to do is you have to audit your assets. So you've gotta go through your properties, all the websites, apps, whatever, what have you and list all of the widgets and components that you have. Now it is not uncommon to find dozens or more of button styles, a rainbow of color choices and more fonts than you can shake a stick at whenever you go through this process. What you wanna do is you wanna log it all and then you go through them and you categorize them. When you're done, you'll have a sense of what kind of widgets and components you'll actually need. The next thing that you need to do is find your voice. You wanna define how you speak with the people who you engage with. So are you formal? Are you informal? Are you a little bit of both? I want my bank to be formal. They handle my money. I don't want them cracking jokes. But what about a university? So at the University of Pittsburgh, our voice was mostly formal. In fact, our voice was Chicago Manual of Style, 14th edition with a smattering of AP. And but yeah, but for some of our touch points, we kind of softened it a little bit because for stuff like admissions, we wanted to get the best students in. I'm sure they still do, I don't work there. They wanna get the best students in, so we adopted a more informal conversational tone because we wanted to better adopt language that would be attractive to them. And that's something that should go into a style guide so that again, it's consistent and it's not unexpected whenever your flyer or your email campaign that's going to admissions students cracks jokes, whereas maybe like, you know, your university like bylaws page, you don't wanna have jokes on it. So you also have to define your brand standards. You're probably already going to have this already. That's something that a lot of companies whenever they get identity work done, they have brand standards. So this is stuff like corporate colors, topography, et cetera. But one of the things that you have to consider is, are your corporate colors the only colors that can be used on a project? Do you have accent colors? Or is it okay to use any color as long as your logo is in the appropriate colors? How does your logo work on a variety of different types of backgrounds? Some branding guidelines that you'll get will solve these, some of them won't. I was looking through the University of Pittsburgh one in preparation for this talk and they have like six pages of what not to do with the logo, like just like big red X's over all sorts of crazy stuff. I don't know who did the fisheye tie-dye version of it, but that was pretty crazy. So then lastly, you're gonna need to build and document your toolkit. So all of the examples that I show you live publicly on the web. Yours does not have to live publicly on the web, but it does have to live somewhere that's accessible to the people who are working on it. And so you need to create these assets. Each team has different needs, like marketing needs to know how to use and implement widgets, and editors need to know the tone of how to talk with users whenever they write an email campaign, and developers need code snippets to ensure that interactive elements are working appropriately. And so like you need to actually bring all of this together and document it and make it work. And when questions arise, when someone says, you know, that accordion widget was a little bit confusing, you have to revise it. So let's talk about how to communicate this. So this information has to be communicated back to the rest of the team. And there are a lot of apps and services that facilitate this. In fact, we're entering a golden age of design tools that bridge the gap between team members, between developers and editors and marketers and designers, and my four-year-old daughter is making PowerPoint presentations. Who knew? It's crazy. You know, there's a growing number of apps and services to help you. I'm going to go through an admittedly incomplete list of tools that can help you on your journey, but I just wanted to leave you with some ideas with some of the tools that are out there that can kind of help you as part of this process. So the first, I dare say that whenever it comes to doing interactive and visual design, that Sketch is the go-to tool. You know, it has a robust plug-in ecosystem, which is not unlike Drupal modules that give designers superpowers. Like you can make flexible layouts. You can publish websites with Sketch if you get the right plug-in. It's pretty crazy. Some are free, some are paid, but it is an awesome and extensible tool. The next one that I want to tell you about is Zeppelin. So Zeppelin is a wonderful complement to Sketch. You can create style guides and resources for the whole team to use in Zeppelin. So a designer will upload their Sketch files. They'll go in and select various colors. They will give those colors names that turn into variables that then can be used by your iOS team, your Android team, your web development team. They can pull those specific RGB color values, or rather those variables that are defined in the style guide. And if you as a designer decide that you know what, that shade of blue wasn't right, I need to change it. You upload a new file. You change the definition for that blue variable that you have, and when the developers pull it, it will change, and it will be updated. Okay. Zeppelin also allows you to, like you can export various code things, like you can get sizes and font sizes and things like that. And you can export for iOS and Android, mention that. And in addition to working with Sketch, it also works with Photoshop and Adobe XD. So if you're still using Photoshop and Adobe products, you're not left in the dust. Zeppelin has full support for that too. Which leads me into Photoshop and Adobe XD. These are both very good tools. I've used Photoshop the most for web design in my career. I use Sketch now, but if I looked at hours logged, Photoshop is my baby. And Adobe XD is new on the market. It is basically a Sketch clone, but it is a very good Sketch clone. So if you're kind of on the fence about trying it, I do recommend that you try it. It has a lot of good things. It also mimics Sketch's one downfall, which is moderately bad typography support. So you can't win using either of those, but it's not a perfect world. There's also a tool coming out soon, Envision Studio. So you may have heard of Envision, primarily used for like reviewing comps, so on and so forth. You can actually, this will be a free tool that you can visually build out responsive designs and share the code. I literally just got my beta access to this yesterday as I was traveling here, so I haven't cracked it open yet, but I can't wait. Then just a couple more, and then I'm gonna, I think I've got time for questions. Avacode, if you're invested in the Adobe ecosystem and you don't wanna buy an Adobe license for all of your developers just so that they can extract assets, Avacode is the way to go. It's an application that can open up Photoshop files. What is it? Photoshop, Sketch, Adobe XD, and Figma. It can open up all of these and you can pull assets just like all the things that I mentioned with Zeppelin you can also do with Avacode. So you have options out there based on what works for you and your team. And the last thing that I wanna mention because this is so weird and so cool is so Airbnb so much, they love their style guides so much that they actually have coupled it. They've coupled their visual assets with the code base. They're generating sketch files from their React components. So Airbnb is actually coding it up and then creating sketch files from that. So I can only imagine that like their loop is like designer designs a thing. Coder makes it. Coder creates a sketch file that designers use. That's a pretty awesome feedback loop. It blows my mind, I haven't played with it yet, but so ultimately everything's moving so fast and every team has different preferences on what works for them. So the best thing that you can do is evaluate the options that appeal to you and choose the one that works best for your team. Talk to a lot of people, find out what they're using, what they're doing and see what works for you. So I think I've got time for questions. I'm not sure when my talk ends but I will take questions if anyone would like to come up to the microphone and ask a question. I'd prefer it to be about the talk but you can ask me anything. No, all right, great. Thank you all very much. As a reminder, there is a survey on the Drupalcon site so you can go and give me all whatever the thumbs down is. That would be great. All right, thank you all so much. Have a great Drupalcon.