 So, welcome to Content Is Drupal's Business, so make it yours. Hello, everyone. My name is Pamela Barone. You can find me on Twitter at Pamela, which is also my Drupal.org username. I am a client service manager at Previous Next, which is a Drupal shop based in Sydney, Australia. I'm also an experienced site builder. I've got a number of core patches. I'm a module maintainer, and I've been working with Drupal for about four years now. And if you're wondering why I traveled 28 hours to Spain to talk to you guys about content, there's a little bit of a backstory as to kind of what drives my extreme passion. Around all matters, content-related. Before my sort of Drupal career, I spent four years as a content producer for a large media company in the United States. We used exclusively proprietary CMSs, and I say five plus because I don't know whether SharePoint counts because we did use it, but it wasn't really a CMS then, but now they say it is. Maybe five, maybe six, depends on how you count. Most importantly, they spent millions of dollars on these websites. There were high visibility websites, billions of page views, and so much rage. I call it CMS rage. If you've never experienced CMS rage, I think you're probably lacking a really important insight into the lives of the people who use these things. And I spent a lot of my time sort of in this position with my eyes bulging out over those four years. There was absolutely no consideration of content in the design or the development of these sites. The workflows were like it was almost as if they had built it to be as inefficient as possible. We were constantly coming up with workarounds and compromising on what we were actually doing just to get the job done. So instead of enabling us to do our jobs, the technology was actually getting in the way, which resulted in a terrible user experience for the editors, obviously, but also the end users. I mean, the product we were creating was not very good because the design wasn't very good. The tool wasn't very good, and we weren't able to produce very good content. It was a pretty toxic environment as a result of this. We were a big team. There were maybe 20, 25 of us depending on the season, and we were really unhappy. We were really stressed. We felt kind of wronged. We felt like victims, CMS victims, and I left that job, and one of the main reasons that I left the job was that I was just constantly frustrated with the technology that we were being given, and I knew how much money was being spent, and I knew how much time was being spent, and I was so frustrated by the sort of basically the failure to produce something that would have been useful. So after I left that job, I spent a little bit of time exploring the CMS world. I built a WordPress site, and it was hacked within a few weeks, which was totally new experience for me. I was really confused. I downloaded Joomla, and I was just baffled, and that's nothing against Joomla. It just didn't make sense to me. I just really didn't get it. But I discovered Drupal, and I was completely blown away by the potential. So it was really a light bulb moment when I found Drupal because it was totally free from the restrictions of those CMSs that I used that I hated. There were all these assumptions built in. There were all these restrictions built in, and Drupal had none of those. Every problem that I previously had, I could see how I could actually solve it. So where are the old CMSs? We'd say, do you think you could actually check this box by default, rather than having to have us check it every time? And they'd say, oh, no, that's going to be a week of development. And you're like, this is possible. And then Drupal, I could see. If you need to check the box, you just check the box, and it's done. And in a way, you can think of it as you can build the perfect CMS for the use case because you can do anything with it. I didn't necessarily know how I would go about doing it, but I could sort of see that the tools were there, and I found it really exciting. So I started working with a Drupal shop, and I assumed that Drupal projects were smooth sailing with happy people and the content editors were happy. And I mean, that's not to say that, obviously, Drupal's not perfect out of the box, but it's so flexible that it's like, okay, well, we can make it perfect, right? And just throw in a unicorn rainbow, which actually, unicorns farting rainbow is a meme, which I didn't know until I looked that up. So I was completely wrong about that assumption, right? My first Drupal project was a complete disaster for editors and end users, which was sort of a sad story that I had already been a part of. And I was sad to be contributing yet again. The IA was incomprehensible. The content just didn't fit. It didn't fit the CMS. It didn't fit the design. And we spent a lot of time on workarounds and reduced. And we learned a lot of lessons, some of which I'll talk about later. And at that point, what I already knew before I started was that Drupal provides the tools to build great content management systems and great websites. But what I hadn't learned, what I learned after that project was that without the right inputs, those tools are completely useless, right? It doesn't matter what CMS you're using. If you don't have the right information, it's not going to be a good result. So the proprietary systems essentially didn't have the right inputs because they were products that had been built before and you couldn't customize them. And Drupal can be made to do anything, but if you're not making it do the right things, then it's not useful. So I had found this amazing tool that could solve all these problems, but I really hadn't quite yet learned how to use them. And that's what this session is about. It's about why you should care about the content side of things because it will result in better outcomes. And the second part is a little bit about how you can get started implementing these content-focused processes at your organization. So these are actual things that you can start doing now. And then I'll give you a little bit more information about that disaster project and I'll also talk about a quick example of sort of getting it right. So if you're here and you're wondering why is content important, why should I care about this? This is the section for you. So why should I care about content? Well, you're building a content management system. And I think that a lot of times we forget that, you know, we think we're building websites, so we obsess about the design and not just we as vendors, but clients as well. You know, you're building a website, you're worried about the design, you're worried about what it's going to look like, you're worried about the integrations, you're worried about end-to-end testing. You're not really worried about the content, right? But of course we all already know this. So this isn't new information for anybody and I find it a little bit strange that we're still talking about this sort of like, should I care about content? It's like, yes, you definitely should. So I'll talk a little bit about this now, but just a little bit because I really think it's fairly self-evident. So if you think about it as a graph, the value of a CMS is directly correlated to the sort of efficiency and the content consideration. So, you know, you're building them a CMS to publish content and if the value of that then is related to how it performs that action. So if it's beautiful, but no one likes using it, or if it's beautiful but they don't actually have content that will fit into that beautiful design, it's completely meaningless. And if it's hard to use, people won't use it. So if you build a CMS and people aren't making content, obviously that's a huge failure. The value of that project for that business is extremely low. And there's like a kind of maybe a weird analogy, but if you had a business that made custom containers, you'd probably want to know what was going in the container before you built it, right? I mean, I think if you had this business, you wouldn't let your client say, don't worry about what's going into it. We'll figure that out later. Just build it and hand it off and then we'll worry about that. But that makes no sense, but a CMS really is a content container. That's what it's for. It's a place to put content and then publish it wherever you're gonna publish it. So the risks of taking that approach of, we'll worry about that later, are you're probably gonna get it wrong and you may find out that you got it wrong before the budget's gone and then you're gonna spend that money refactoring it, but you might not find out until the budget is gone and then what, there's no more money. So you end up with an expensive system that probably has a lot of workarounds. It's very inefficient. Pretty much everyone involved is unhappy. But the rewards of getting it right are, it's cheaper because you got it right the first time. It's easier, easier to use. The clients are happy, the users are happy. And of course the developers are happy too because developers hate refactoring. And this is just a quick example of a really bad container. So this is a page with sort of like a news feed and I'm sure that this seemed fine in the design, right? You've got a thumbnail, you've got a date, you've got a title, but it's like a telecom authority government agency, right? They don't have really great images for all of their news items. So what they ended up doing a few years down the track is some of them have images, some of them don't. Some of them have a date, some of them don't. It's a really, really awkward page and it's not, this is not a complicated problem. A news listing page is not, it's not a complicated thing to build. All you have to know is what is the information and how should it display? And in this case, probably what they did was they created a display and then just expected the information to exist and it didn't. So in order to get the best result, we need to know the right information. Simply knowing some information is not enough. So in that last example, as I said, I'm sure the client signed off on that design and said, yeah, that's great, but did anybody ever ask, do you guys have images for all of your news articles? I don't know if you can see that well, but the images are like, it's like a book, it's like a stock image of a book and a word up there. So just like, this was not a good idea. It's not a good design and it's not a good result either. So yeah, how do we get the right information? So the best way to get it is to offer it to help them get it, right? We provide services aimed at uncovering those important details and we charge money for those services because it's actually adding value. And the best way to think about it is, in some cases it might be a complete rethink of how you approach these projects, but content comes first and that's the assumption that you start every project with. We don't go anywhere until we know about the content. What is it? What does it look like? Once you know what it is, you can think about how you might structure it, you can talk about designing it and you can talk about developing it, but you have to reverse the conversation from, okay, here's the design, now put the words in later. Find out what the words are and then tell the designer, hey, here's the content that we have, this is the most important stuff. Now you can create a home page. I mean, how many of you have ever just told a designer, no, they need a home page, just, we don't know, just go do it? I mean, if you actually logically think about that, it makes no sense. So if you do think this is worth doing and I strongly recommend it and you wanna get started doing it, the first thing that you need to do is think about how this fits into your team structure. So do you already have someone on your team that has experience with content and can speak to some of these issues? Or do you have someone that's interested in learning about it? It doesn't have to be someone that's a content expert, whatever that means. And sometimes it's enough when you're starting out just to have someone be this sort of designated advocate, meaning this is the person that's putting their hand up and going, wait a minute, we haven't actually answered the content question yet, we should hold off, we shouldn't go any further because we don't actually know enough information to get this started. So like I said, it doesn't have to be a content strategy expert. If you wanna hire a content strategy expert, that's great, you should, but you don't have to be intimidated by that sort of bar. It can be anyone, really. And if you don't have someone, then just hire someone. Depending on the size of your organization, the size of your projects, it could be a part-time contractor. It totally depends on what level of services that you wanna provide. And this person sort of becomes your designated content lead. And then every project you do, you run a content assessment, or you can call it whatever you want, but content assessment is sort of, I think, a little bit non-intimidating and also very vague because the content assessment could be a very wide range of things. But incorporate this into your project definition or your requirements gathering and make sure that your clients understand this is not an optional extra. It's not an activity that you can sort of cross off the list and say, no, we don't actually need that. As a business, we require this assessment in order to proceed with the project. So again, it's not a bonus thing that they can get us to look at their content. We require it. So it's part of the process, part of the project's success. And the amount of effort that you'll need for this will vary greatly. Sometimes you may think it's gonna be small and then you start and you realize that it's actually a big mess and they're gonna need to engage a content strategist to help them or they're gonna need to engage a copywriter to help them. But part of the content advocate's job will be sort of helping you assess this and figuring out how much time you might need to spend. And I even recommend it for really small projects because if this project is really small, the effort to do this is gonna be really small as well, but it could be a huge payoff because sometimes small projects actually sort of get ignored even more because you figure, well, it's only small, it's not gonna be complicated, it'll be fine. I think no matter how small the project, you should at least do like a very initial assessment of, okay, you guys are fine, we can proceed or let's think a little bit more about this. And the content assessment, what the outcomes that you want are, initially it just sets the tone for the project that content is gonna be really important. It's important to us and it's important to the client. And I think in my experience anyway, a lot of clients really don't actually know this. They've maybe never done a web development project before. They don't work very closely with the team that's producing the content so they don't really understand what goes into it. And certainly at my old job, the person who was doing the projects had absolutely no sort of insight or visibility into what we were doing on a daily basis. And so he might have actually been surprised to hear this. So I think it's, again, it seems like it should be obvious but a lot of people don't necessarily know that it's really important. And when I say ensure there's a validated content model, I'll talk a little bit more about content models but ensure means you don't actually have to be the ones to produce it. So like I said, if you come to a project and the content is a mess and you're worried about it and you think they need help, refer them to someone who can help them if you don't wanna help them. But it's just about making sure it's like a gatekeeper thing. If they don't have a content plan, they need to get one. However they're gonna do that. The other thing this really helps to do is just match expectations. A lot of times, especially if it's a person that hasn't done a web development project before, their expectations might be sort of off in the clouds somewhere. And that's not generally the way it goes. So you can use this to match the expectations of, right, this is the content structure and CMS we're actually building for you. And this is the amount of content that you're gonna need to produce to support it. And then once you have that model, you can use that to inform, as I said, get, inform your design and development and sort of take the next steps. So again, the key thing here is that you don't actually have to know everything that you're sort of challenging them with. It's really just about asking them the questions. And again, you can be the ones to provide the answers if that's the service you choose to provide. Or you can just be the one to sort of say, actually, you need more help with that. We can't provide it, but you should seek professional help. So before you start, here are a couple of very simple questions, right? Hey, what's the plan for this content, right? Why are we building this site? What content are you trying to promote? Who's gonna be using it? Who's gonna be updating the content? And what are the workflows? Like how is this gonna go from, probably a Word document to a published item on the homepage? We need to know about that. And oftentimes these are things that the client has absolutely not considered because people say, what do you mean? You're building a website. That's, you know, you're building a website, not us. And I think that kind of disconnect between the website and the CMS is often really, there's a really big disconnect at the start of a project. And so the sooner you can kind of get them on side to understanding that this is a production tool, it's not a sort of a magical content producer. It's a tool, and they need to understand how to use it. If they don't have a plan, stop everything. And talk about it. Discuss it with them. Why don't you have a plan? Did you not know you needed a plan? You do need a plan, so let's sort of explain that we can't design a site for you and we can't build a site for you with no plan. The design, so creating a design is not a content plan. Annotated wireframes are not a content plan. And you have to be really firm about this because I think a lot of times it's sort of like, well, we'll wait till later to do that. That's gonna be later. But this is the slogan for a New South Wales rural fire service, bushfire readiness plan, right? Planning to make a plan is not a plan. So waiting until the site is ready and there's a working CMS and then we'll do the content, that's not a plan and it's not gonna end well, definitely. So you sort of have to, in some cases, protect them from themselves. So you can suggest some tips for coming up with a plan. Here are four, come up with a content plan and four easy steps. Start with evaluate, just ask what is the goal of this project and what is the content that we're gonna need to support that goal? Does some of it already exist? If it does exist, is it still relevant? Is it still accurate? Can we repurpose it? If nothing exists, just make a list. It can be like actually just a list of pages or a list of articles or a list of categories, a list of types of content. It totally depends on the size of the project, but it's actually a really simple exercise in it. Obviously, the sooner that you do this, the better. And then once you have the list, it's really important to prioritize it. So of the content that they're planning to create, what's the most important, what's the most effective at communicating the vision for this project and achieving the project goals? And that's a really, really important step because what that tells you is to focus your design and development effort on the most important content. And the less important content can kind of sink to the bottom and you can worry about that later or you can sort of spend a lot less time on it. And I mean, it's just so important that I can't stress it enough that you have to find the most important content and focus on that. And once you know what it is and once you know what it's gonna look like, you can talk about how to surface it. So once you know what the important stuff is, okay, that's the stuff that we're gonna wanna put on the homepage. Probably you don't need a carousel. You know, once you have that information, you can say you have a list of 10 things that aren't gonna change very much. Why would you want a carousel? You know, it's sort of like you have the information now to argue against the maybe the bad decisions because if you're making them in a vacuum, you have nothing to, okay, carousel, what are you gonna put in there? No, let's start from the beginning. Let's start from the content. What is the content? And then we can talk about where it might fit. Do you see how, like, if you say, here's the homepage, now what are you gonna put in it? It already looks like it's completed. They're not thinking of what do I need to do here? They're thinking of something that's already done. They're not thinking of the work that it's gonna take. After you've evaluated and prioritized it, you can do a bit of mapping and you can talk about the structure with them. The detail doesn't need to be too much if they're not very technical. But just, you know, if they already have content, start with the existing fields, what's the structure look like, does it make sense? Are there some improvements we can make? And don't invent fields just for the sake of it. Keep the content map really simple at first and just make sure they understand that the less you build, the more time you'll have to build stuff later. So the best way to be efficient is minimum viable products, which is something I'll talk a little bit about later, but do the bare minimum, get them using it, get them testing it, and then talk about how you might be able to improve that. And this is probably from a planning perspective for them the most important step. Because once you have a list of the content that you're gonna need, you can actually estimate, say, how long does it take to write one article? And we're gonna have 50 articles for lunch. Okay, that's how much time, that's how much actual time we need for the staff to come up with this. Do they have that time? Do you need to hire someone? Do you need to simplify your plan? You can actually do the math, right? And how often do you hear people say, we want our home page to be dynamic, a lot of content, it's gonna be changing all the time. And then you say, who's your content team that's gonna be producing this? It's like, oh, well, there's a guy in the marketing department and he might wanna help. It's like, no, if they're envisioning lots of interactive and dynamic content, they need to understand that it's something they will need to be providing. So again, this is more about protecting them from themselves. And I think, as much as you might say, well, the content entry is their problem. If you've ever been part of a project where the content entry was supposed to take two weeks and ended up taking six months, it puts a real damper on things. For us as the vendor, as well as for the client. And if you do have a plan, that's great. Let's talk about it. Let's just go over it. Let's see what the assumptions are that you've made. Are there anything, is there anything in here that implies something functionally that you don't understand? Make sure you clarify that first. Identify any gaps and say, well, you've got this sort of bit of text here, but I don't actually know what that is. Do you know what that is? Is that something you're gonna be updating? Is it something, is it part of another piece of content? And also, ensure that there are examples. So if they say to you, we need a publication content type, okay, well, what's an example of that? And oftentimes we have, you know, we'll say, okay, what's an example of that? And they say, well, we don't have any yet, but it's something we wanna do later. That's totally fine. It's something we'll build later too, though, because there's no point building a sort of a, call it a hypothetical content type. If they don't have an example of it, it doesn't need to be built yet. And then document the workflows that they're envisioning in their heads and talk about this both for Go Live as well as ongoing maintenance. And I'll talk a little bit more about workflows later too. So once you have a content plan, you can come up with a content model. And this detailed content model is not necessarily that important for the client, but it's really important for the designers and the developers. So if you don't know what a content model is, it's really, really simple. It's just sort of a documented site structure. So it can be a list of content types, and then under that, there's a list of fields, and you can sort of identify similarities in places where you can use the same field, places where you can use a shared taxonomy. And it basically takes the guesswork out of site building and design. It tells the developer exactly what they need to build. What's the content type? What are the fields? And the designer as well can say, what information do I have to work with? And that way, you don't end up with these sort of inventions and little bells and whistles that the client doesn't need, and it's a waste of time to build. So it's really like a big picture overview. And honestly, like you said, it doesn't have to be that complicated. A spreadsheet is totally fine. It doesn't need to be this grand diagram with lots of colors, and the simpler the better, really. And I was reading an article in the lead-up to this about content modeling, and one of the headlines was, why is a content model important? And it's just one of those things that you think, because it is, because it's so important. I mean, how do you know what you're building if you don't have a content model? It's the most important thing you can have at the start of a project. And then a little bit of plug for my former self. Content editors are people, and you should talk to them, because it's really important that they get what they need to do their jobs, and the only way you can give them what they need is by actually talking to them. So see if you can set up a workshop. Ask them how the CMS works now. Ask them how they'd like it to work. Are there things in the CMS that they absolutely hate? Are there things in the CMS they absolutely love? And empower them to kind of engage in the process and ask for things. And so you explain that what you're gonna be doing is delivering a version of the CMS, and they can continue to ask for refinements and improvements, and it becomes more of a discussion rather than kind of a throw something over the fence and then throw it back over the fence when it's done. So it's not about saying tell us anything you might want in your wildest dreams. What would your CMS look like? It's not about gold plating. It's not about giving them whatever they want. It's just about including them in the conversation and giving them a voice in the process and making sure that they know where you're coming from and you know where they're coming from, and that engagement really does go a long way. And if you find that your client or whoever you're dealing with on the client side is resisting this communication, it's a major red flag, because there's probably an underlying organizational dysfunction that is going to surface at some point, and if you don't surface it early, it's gonna be too late. So if they say, why do you wanna talk to them? Just say, because we have to, that's how it works. You know, we need their feedback, and we need their feedback often. And finally, workflows matter. So CMS processes should support real workflows, not block them. Find out what the steps are from getting to A to Z. You know, where does the content start? Who's creating the content? Is it a Google doc? Is it a Word doc? Who's actually copying and pasting it? Is somebody actually typing it into the CMS? Is there an approval process? Does that approval process happen offline or online? And real actual workflows, so how they're doing it now, is much, much better than the hypothetical, well, we'd like to implement a process whereby our director publishes the content. You know, does the director really wanna do that? Does he understand what the implications are of that? It's gonna take up a lot of time, I can't even tell you how much money we've, or well, time, how much client money we've used building workflows that two weeks later are thrown out the window because it was just too complicated. And focus the efficiencies on things they're doing often to find out what the tasks are that they do 10 times a day. Focus your effort on making those quicker and maybe less important are the things that they do once a month. It might be okay that that process isn't perfect. Again, back to the sort of workflow thing. A lot of times organizations will use their CMS as sort of like a policeman or a guard against bad behavior. And adding rules and restrictions to the CMS to prevent people from doing something that they shouldn't be doing is kind of a weird idea and probably won't work out that well. I mean, people are really good at finding workarounds for one thing. But for another thing, I think if you treat these people like they can't be trusted and that there needs to be all these fences in place, I think that comes through and I think it's just not the best result. I think educating people and training people in how the CMS works and what to do and what not to do is so much more effective than adding rules and workflows and regulations. It comes down to really trust. I think when we come across an organization that's sort of insistent that the comms person can't publish content, it's like kind of like why is there so much mistrust? That really sounds like a people problem rather than a technology problem. So if they're expecting the CMS to solve their organizational dysfunction, they're gonna be really disappointed. Just a few sort of final thoughts on this. Iterate, iterate, iterate. Minimum viable product is such an important concept in web development but it applies to your content model too. So start really simple. If you have a content type, don't create 20 fields that they might use because someone might be adding something someday. Make it with five, send it over to them, get them using it and find out what they might wanna add. Maybe they find it works fine to their surprise. They didn't need all 20, all they needed was five. But if they do need changes, that's okay. That's the point. You're expecting that there will be changes. You're not necessarily trying to get it right on the first try. But if you don't get it right on the first try and you haven't spent a lot of time on it, then nothing is really lost. So you find out early that there need to be changes when the impact is really low. The second point here is start entering your content as soon as possible. During development of projects, we have a dev site and a staging site and the dev site is where we push things without too much testing. But staging we treat as pre-production from very early on in the process. So we have daily backups running. We send it over to them. We create all the accounts and we actually tell them enter your content now. Like this is the site. So start creating your content. There's no reason to wait until the end. That's just gonna delay things and you're just gonna be delaying that important feedback. And not just add content, but add real content because testing with test content is a complete waste of time. All you're really proving by testing with test blog title is that the text goes where you think it should go. But that's not really what we're trying to test. We're trying to test whether this actually supports their content model. So does it have all the fields you need? Do the fields work correctly? Minor things like should it be a multi-select or a single-select field? You can't get those answers unless they're actually creating real content. So for simple sort of, it's okay to use warmups in my guess, but they need to be testing with real content as soon as is humanly possible. And that means as soon as the content type exists on staging. And that's kind of, I think there's a bit of a mental hurdle there with clients to say, well, the site's not done yet so I can't enter content. But the content type is done, you can enter content. So the whole point of this is to make the project smoother, better, more valuable, more efficient. It's not a money-making scheme or you can make money doing it if you offer it as a service. But more importantly, you can stop yourself losing money if you mess it up. So we really don't treat content services as sort of like a money generator. It's just a really important part of the process that will save time in the end. And I often hear people say, well, my client says they can't afford content assessment. It's not about can I afford it or can I not afford it. It's sort of a cliche, but it's something that they can't afford not to do. So it's not something that's going to make the project blow out. It's something that's gonna keep the project from blowing out. And I'm gonna go back to the example I gave in the beginning, which we got it really, really wrong. This is the setup of the project. And we did have a fair few things working against us. It was a really, really big project. There's a lot of content. They had spent many, many years planning it on various committees. They had gone out and gotten a design. And that was before they even chose the CMS. And so they had this really big RFQ that again had been decided on by a committee. And as is true in most big organizations, there was a minefield of internal politics. But we were excited still at the beginning. We were optimistic and we were excited for this big challenge because it was a big meaty project and we were really excited to dive in and help these people move from an ancient CMS into the future with Drupal. But one year later, this is really what it looked like. That's me in the corner praying. I ran training at the end, which it wasn't the end, but at the end of the project, I ran training for over a hundred content editors and admins so that they could start the content migration. And it did not go well. I had thought that there probably would be issues. Like I thought that there would be things that they said, oh, you know, we need to just tweak that. That's not quite right, but I had no idea how bad it was gonna be. People were furious. They were frustrated. They were angry. They were obviously taking it out on me because I was the idiot standing in front of them, showing them how the new CMS was just not gonna let them do their jobs. And I had sat through so many of those sessions myself. I had been on the other end and I was really quite sort of upset to be the person that was then sort of doing it back to them. Like I said, I knew how they felt and I understood their anger and I understood their frustration and I knew that they weren't, it wasn't personal, but I had come to them after probably three or four years in this organization, they'd been talking about this great, we're gonna build this awesome new CMS and it's gonna be this huge thing for our organization and here it was, it was sort of like the worst of their, it met their worst expectations. Well, what went wrong? A lot of things went wrong, but tracing it back to the content in particular, they had a content plan, but we didn't know anything about it. And I think that we didn't ask because we didn't really wanna know because we thought it was probably pretty messy and I think we just thought that it was like, well, that's too complicated, they'll sort it out. They gave us these designs that had been done before, we didn't get a chance to talk to the designer, we didn't necessarily know what was implied, they kept sending back annotated wireframes with all these crazy ideas and we took everything at face value, we accepted this sort of piecemeal information, you know like here's the content type and then three weeks later, here's another content type, we didn't really know how they fit together and again, we didn't understand the big picture. Basically, the CMS was just totally unfit for what they needed. And the only good news, there was some good news, was that because we were using Drupal, we did have the opportunity to refactor things and some of it was really hard to refactor, but some of it was quite easy and there were some really small things that we were able to do that, hopefully made it go down a little bit easier. And that training again, like I said, was pretty eye-opening for me, I was pretty taken aback by it, it was really clear that we had failed and it took me kind of a lot of soul searching to figure out what we should do differently and I think the key thing, I talked about before, just don't start if you don't have a plan and the position we were in was, we had a team that was booked and it was ready to go and I think we knew we weren't ready, they knew they weren't ready, but we had this team booked, so I guess we should start, right? And that's just never gonna, it's maybe not never, but it's probably not gonna end well. We should have just said, look, this isn't ready, we don't know enough information in order to proceed. And as a result, I think we took this attitude of, well, it's their fault, we blamed them, it was their requirements, it was their IA, it was their content and they just didn't understand it, obviously. But I mean, we were the ones that were selling it to them, so it really was our responsibility to recognize that they didn't understand and recognize that they were making decisions that were going to come back and haunt them. And certainly I've completely failed to recognize that this was something they didn't really know what they were doing. And that's not to say that in a condescending way, but they were trying their best and they really didn't know what to do. And they just needed guidance. We made some recommendations, but we gave up pretty quickly because we had some sort of early failures where we said maybe you should do this, and they just sort of told us to shut up and do it anyway. But that led to a working relationship that was really tense and we just started doing what they said even though we knew that it was a bad decision. So eventually we just sort of shut down. We stopped providing advice even when it could have been really useful. And we avoided the conversations because they were tough conversations. And I think we ended up adopting just like a sort of a doomsday view of it, like, well, this is gonna be bad. Where if we had just started the beginning from the approach of this is a collaboration, this is a partnership, and we need to know more about it in order for you to succeed. So we should have challenged them a little bit more. We should have kind of identified their mistakes for them and avoided them making them, at least avoided making the same mistakes over again, which we did that too. So there was a lot working against us on that project, but we definitely could have done better. And I'm not a content strategy expert, I'm not a content strategist, but it's hard to be an expert in something, but it's really easy just to try it. And we really didn't try, we didn't try to take the kind of content advocate point of view, we just didn't try it. And so it was a real learning experience for me where I said, right, I'm not gonna let this happen anymore, no matter how big or small the project is, I'm not gonna let this happen anymore. So this is a very quick example of where we did do it, right? We had a large, very large website moving from really old CMS to Drupal. I think it was about 5,000 pages, about 10 content types, and the mapping was pretty straightforward. The old CMS wasn't super structured, but it wasn't a complete mess. And after a long, they had done a long lead up to this to get approvals and they really wanted to move to Drupal ASAP. So there was one problem, which was there was this giant structured content blob of HTML, which was sort of like a landing page, but it wasn't structured. There was no way we could automate this migration. There was no way we could map that title and that teaser to that piece of content somewhere else. And so what we did here was we did a simple measurement, right? The obvious best practice here would have been create a landing page, make it automatically generated, add the teaser and add the image field to the child node and build it dynamically. But we measured and we realized, right, well, there are 600 of these pages. They simply don't have time to do it themselves. It's not gonna happen. It's gonna take months. We don't have time to do this. So even though it was a very, very clear violation of the structured content best practice, we just migrated this into a body field. We just migrated this markup as it was. And it's not a very elegant solution. It's pretty ugly, but it got us, we ended up launching that site within six weeks. We did the automated migration. This way this kind of got thrown into the body field. And we also, at the same time, we created a content type for them and we added a teaser field and we added an image field to the child pages as well so that they could sort of one by one migrate the pages in their own time. And that site went live about a year ago. They still haven't finished, but the site went live a year ago and they might still be working on it now if we hadn't just decided to sort of accept that as a compromise and move forward. So yeah, don't focus on getting it perfect. Find a good place to start and just keep improving from there. If we had insisted that, you know, no, we can't migrate that into the body field because that's a droopble, no, no. It could have taken, like I said, months, maybe even a year to get that site over the line. We just needed to get them started. And once they got started, they took it, they ran with it, they're super happy. We were super happy. It was a sort of the, in many ways, the complete opposite of that first project I talked about. So just a few final points here. There is no single solution. So as I said, we violated a definite best practice, but it was the right decision for that situation. Every project is different, but for me, anyway, that's one of the things I love about this is there's sort of a new challenge every so often. And once you start doing it, you'll start to see similarities. You'll start to see things that looked like something you did where it went well or it didn't go well, and then you can use that previous experience to inform your next round of decisions. You'll start to see patterns. You'll start to kind of approach things in a different way. And most importantly, it'll get easier. The more you do this, the more familiar you get, the more comfortable it will get easier. And the sort of final point is getting it mostly right is way better than getting it mostly wrong. And you just can't get anywhere near the mostly right side of things without talking, without talking about the content, without caring about the content, and without taking some ownership as a vendor of the content side of things. Forget about perfection, you're not gonna get it right. You're not gonna have all the answers, but you have to start somewhere. You have to ask the questions. And that's the only way to get to the mostly right side of the spectrum. That's all. Thank you. Any questions? Yes. So just for the recording, the question was about educating content writers in SEO best practices and kind of enabling them to do it where they don't might not necessarily know how. I think, yeah, content strategists can really help. If nothing else, an SEO expert, which I'm definitely not, can maybe help you come up with ways to improve your CMS. So if you're using Drupal, there might be some obvious things you can do, like make certain fields required, or put some help text in or whatever tweaks you can make to the CMS to make it actually easier for the people that might not be experts in it to do it more often and do it better. And maybe, I mean, I don't know that much about it, but definitely I think a content strategist could help you come up with sort of like an organizational set of guidelines that would be easy to follow. Because SEO is a really complicated thing, and it changes a lot, and I mean, I can understand why people might struggle with. With getting it right. Working is relative, right? Yeah, no, you're absolutely right. The question was about how you can sort of encourage developers to think a little bit more about the content and the experience when they're building content, because it's true. I mean, their job is very technical, and they're not necessarily concerned with the end result from the content at its perspective. But I mean, I think for one thing, getting them both in a meeting at some point, so that they each know that each other is human, I think a lot of times devs sort of, and even a lot of people, can sort of brush aside the content editors as sort of winters or minions or lemmings that just will do what they're told. And I think that meeting the people and talking to them and having at least like a form of communication can help humanize it and can help them understand. And a lot of times what I find is the developers go, well, why do they want that? Why do they want to do that? I was like, it doesn't matter, you don't need to know why they want to do it. I mean, you can explain it, but it's sort of like, it's not an argument, right? It's their CMS, and you might not think it's the best way, but it might be the best way for them. And one of the other things that we do is we have a peer-review process. So every time a developer builds something, they put a pull request on GitHub, they post the steps to test it, and then another developer actually has to manually test it. And I think that has actually helped a lot with, like you said, some of them have never actually tried it. And I think at the beginning, if you say, right, I can make this work in 10 steps, and then they actually go to try it, and they go, oh, actually, that's really crap. I should have done it differently. And I actually have seen in our team, I have seen developers send things back to other developers by saying, like, this is crazy. You've done it in a crazy way. We need to fix it. We need to make it a little bit more usable. So, I mean, the best way to get them to understand what it's like to use the CMS is to make them use the CMS. Using the mic, I think. I have a question as well. I'm sort of a front-end developer for Drupal at my job. So I'm between the real developers and the people who write the content. And then developers are real developers, but I know what you mean. Yeah, yeah, I don't write scripts. I just use the views and views and all the other modules, but anyway. My question is about existing websites. We've just gone from a really big website from about 9,000 pages to a new version also in Drupal, 5,000 pages. We were killed off nearly half of the website. So most people said this is going to be disastrous, but we've got 30% more visitors. But how do you get content writers to keep to certain norms? Because we said at one point, you want to have one thing per node that was a totally new insight. One thing per node. Yeah, you stick to a subject. You don't write about something on four different pages because you gotta get a bloated website. But with Drupal, because you can do almost everything, writers will say, oh, you can fix that for me. So how do you manage that? You can fix content bloat, is that what you're saying? Yeah, if you want to do really strange things on your page. Do you work for an internal team, or do you work for an agency? I work at a national library, so we do most of the development. Because for us, the way we educate them is we say, you can pay us our hourly rate to do that for you. Or you can do it yourself, and that's a really easy argument because it doesn't make any sense for them to pay us. But yeah, what's your relationship like with that team? I mean, I would say that it's really about communication and education more than, one of the things I said was just about not sort of, you could implement a character limit on the body field, but I don't know if that's really what you want to go for. That approach, then it ends up just feeling like a prison where you're just putting all these fences around them and then they'll come up with another crazy way to do what they're gonna do. So yeah, I would say it's really just about kind of interaction and maybe show them one day, show them if you want me to do this for you. This is how long it takes and this is what I have to do and kind of propose alternatives. And I really think that's a communication and a person-to-person problem rather than a problem that Drupal can solve for you, I would say. Excellent. Yes. Oh, sorry. Do I ever work with clients that just write properly formatted and grammatically correct content, but content that's just not very good? And the answer is yes, we do it a lot because we work with a lot of government clients and they are really good at that. They're very prolific, but they kind of miss the, they kind of miss the mark a little bit. And it's a tough one because you don't wanna tell someone that the work they're doing is maybe not the best work, but I think you can always sort of suggest that they maybe bring someone in to teach them about content marketing or a content strategy and, you know, that's not something we provide, but we heard about this, our partner agency is offering this workshop that you can go to and learn about. I think it's just about sort of approaching it from a constructive, hey, we found this thing that might help you, not that you need help, but it might help you. You know, versus yikes, that content is crappy. Because yeah, I say that a lot to myself. Sure. Do we ever encourage our content creators to do A.V. testing? Some of them do, it's not, user testing isn't something that we really have gotten into much. We're planning to sort of build up our user experience service side of things, and definitely that would be part of it, but it's not something I'm very familiar with, so I know you can do a bit of it using Google Analytics, and one of our front-end devs is here, and he has some crazy thing that you can add to a block, and it shows one block or another block. And there are certainly a lot of tools now in Drupal that can enable you to do A.V. testing. AcquiaLift is obviously a subscription, but the open source modules that they've released are essentially A.V. testing tools, so you don't get the analytics on the machine learning, but you can build a simple kind of ABC, promote a campaign thing with that, but unfortunately, not something I do a lot of. No more questions? Please evaluate the session, even if it's bad feedback. I do want it, and, oh, that's the credits, and also there's a session tomorrow at 10, 1045, that's about the kind of return on investment, the reward that you get back from investing in content strategy, and that's a replacement session, so it's not in the program, but it's replacing the session, oh, okay, okay, yeah. So it's replacing the content strategy session tomorrow at 1045, and you should all go. Okay, thank you. Thank you.