 I think we're gonna start right on time. This is only a half an hour. So, hi, welcome. I'm Kevin Walsh. I lead the UX team and I'm a Drupal developer at Civic Actions. And this is Iris Abecque, who leads our front-end team. And we're really excited to share with you some of our experiences and what we learned working on the Doctors Without Borders.org project last year. And it's ongoing, but mostly what we'll be talking about is first half of 2018. Hi, everyone. So, going straight into the site, the name of the site is MSF, Medicine Sun Frontiers, and it's also Doctors Without Borders in English. Their mission is to provide life-saving medical care and medical assistance to people who are affected by conflict, epidemics, disasters, or any form of exclusion from healthcare. And the site has three main goals, fundraising, recruiting, and bearing witness. There is a big emphasis on storytelling, and they have this incredible photography team and incredible journalists writing. So, they get both hard-hitting press releases and also first-person narratives from people serving on the front line. A lot of MSF international groups, they have chapters in many countries, and a lot of them have been using Drupal for many years, including a D7 distro. In 2016, the design team at the UK chapter of MSF created a new design system and implemented it in their D7 sites. So, this is where civic actions came in. We were engaged to lead the development of a Drupal 8 site using this new design system. The project started, and all we had was about 15 high-five designs in PDF, like long pages of what their vision for what the new site should look like. And we had a schedule of about 10 sprints, roughly 20 to 22 weeks. And to a date, it's releasable. After that, we continued our engagement with them. And up to this month, we're still working on the site and adding new features. So, first, we're going to talk about our approach to building the site. And we built it. Our vision was to have a competent, driven project. And there are a lot of benefits of building your project in that way. For example, it makes the development really agile. You can build things one slice at a time because you're not building out this full feature thing. You have these small components that you can build and ship. And then also, it makes you have really lean, really flexible code because it reduces the complexity of the site. And because you're using components, it encourages reuse. You can plug it into different frameworks which are typically modular in design. So, it really fits that model. And then another advantage is having consistent branding because when you have one source for all your components, regardless of where you use them, you will just have this consistent branding experience for everyone that uses any branch or any part of the MSF ecosystem. And then there's also a separation of consent because the platform you end up using for your project is viewed as purely a content source. The components actually determine how the markup of whatever you're plugging into the site will look, what the markup will be. So there's this separation between the presentation layer and the content you're getting from any other platform where you're reusing these components. And another good one is best practices. One thing we noticed was that they, for example, if you want to optimize for accessibility, if you have a component and you wanted to have the correct area of roles and all of that, it's good to have everything happening in one library. So if you decide to use it somewhere else, you still maintain those best practices. And velocity. This was actually a happy accident for us because when we built the site, we found that it was a lot easier to add new features because we had these components that we could reuse. And if the clients wanted that thing on a different content type or using a different form, it was just easy to take these components that we had already used and just reuse it. It actually made the last month or three, no, two or three months of the project go much faster than we expected. So I'm going to talk a little bit about the content strategy part of it. This is not about the holistic content strategy at MSF. It would be better to hear someone from MSF talk about how they approach content. I'm going to be focused more on the content model part of the content strategy. This is a Drupal conference after all, and content modeling is a big thing. And I mean, it's an essential artifact off of which a lot of the content strategy hinges. So as Iris mentioned, one of the main goals was to empower the content creators at MSF to create amazing, to do their storytelling. So we wanted to make sure we were on the right track with that business school really early. The two other business schools that we mentioned, fundraising and recruiting, that was a fairly well... We already kind of knew how that was going to work based on the designs, but this is the one that we knew that we could have the most impact on and make the biggest difference. We wanted to solve it sooner than later. So this is where we started with a lean, mean content model. I'm going to talk a little bit about some of the principles with that. First of all, small is beautiful. It's mean, but it's elegant. You kind of boil down the content model to its most elegant forms. And it's smaller in two different ways. The model itself is smaller. There's less junk in it. It's got rid of anything that you don't need. But also the individual parts of the model are small. So I'm going to talk about each of those two axes here for... I don't know how many of you have been involved in building a Drupal site that looks a little bit like this. I certainly have. I've also inherited a few that looked like that. So yeah, this is a picture of scope creep. And content strategists have a major role to play in making sure that scope creep doesn't happen. If you go across an entire organization and ask them what the features they need, and you build a content model to suit all those features, you're going to end up with something like this. And I think it's got about like 20 knives in it. And they all probably do pretty much the same thing. So it's our job as content strategists not to contribute to that. And I think one of the dangers is that in Drupal in five minutes you can add a huge chunk of content modeling. You can add bundles and fields and you've got a new feature and a lot of technical debt. So that's keeping it small and targeted. And also just not repeating yourself. Like I said, there's 20 knives in that Swiss Army knife. So using the techniques of... or ideas of dry, like database normalization, trying to abstract out your patterns into their smaller bits. And yeah, so if you see, you know, you're looking at a set of designs or in just your conversations about requirements, and you start to see multiple patterns involved that are overlapping, that overlap is a sign that you probably want to do maybe one of two things. So if that's the Venn diagram of an overlap, you've got these two ideas of content types and they share attributes. Try to move in one of these two directions. Either get those three parts of the Venn diagram, the top one into their own separate chunks that are smaller, or collapse them together and then use some of the tools that are available in Drupal, like form modes and view modes, as ways of creating that distinction after the fact. So a couple examples of those. On the right, one I've seen a lot is people in Drupal and how they get represented in Drupal. I've seen a site that has one person in two different parts of the content model. So like they're an author of a content and they show up with like an image and their byline and stuff, but then they're also in the leadership page or something and they have a different bundle. So in those cases, maybe the fields are different, but in reality the meaning, there's only one of those people. Try to find, try to create your content model so that they only live in one place. And we'll talk about some other examples of the ones on the left, but I think like Drupal in general has been moving towards the left over the years, like media bundles for example. They're typically used within another piece of content and they are smaller chunks of content paragraphs that I'm sure most people in the room are familiar with, lots of different ways of doing it. So one very broad way of thinking about this and it gets a little bit complicated once you start to push on this, but I think of like the higher level standalone content across the top and then these like lower level content entities that are smaller as kind of verticals. So things like no types, taxonomy vocabularies or custom entity types like a product or whatever, usually they have their own URL. The other things don't usually have their own URL. There's some gray areas between those, but yeah, just to try to push as much as possible lower in the content model will make your lives easier later on. We'll see some examples of that. This is Eaton's taxonomy of these things. I don't really understand it, but he was talking about it yesterday. Now he's got actually different names than small boys, units, puppers and snowflakes. But yeah, I think that there's, we still have some work to do and he's done a lot more work on this to try to figure out what we're talking about and we're talking about these, what are the different types of chunks that we're looking for. Okay, so the second big principle is you're going to get the content model wrong and I don't think I've ever gotten it right the first time on a project. So assume that from the beginning and make sure that your process is prepared to refactor, that you're building in those feedback loops that will help you refactor quickly in not an expensive way and not at the last second. I think a lot of content strategists think of themselves as architects in like a studio and they're coming up with this beautiful model that they're going to unveil at some fancy party and but in reality we're just, it's a little bit more dry than that I think. So yeah, like maybe in our Discovery Sprint we're coming up with our first pass of content model and that's a deliverable that I just expected to change. And yeah, like I said, build a process that you're going to learn from quickly, fail fast. And the best way to do that is get in front of your users. They're probably really smart people. They wanted a Drupal site after all. I mean, if you're talking about your users are the editors in kind of a publishing situation like this one. Even if you've done your research all the right ways in like a Discovery and you've talked to them and you've found out what they wanted, it's going to look different once they actually see the forms and once they see what you've called things, the labels that you've come up with. And they're going to have really good ideas about, no, that's not called that. I want to call it something else. In the case of Dr. Philip Orders, they're really, as Iris mentioned, they're experienced journalists. They know their craft. They're very demanding about getting their content displayed in the right way and structured in the right way. So they were... So yeah, what we did is we defined a hypothesis kind of around this problem. It wasn't maybe the only part of an MVP, but after three sprints we got an editorial and authoring experience in front of people and we wanted to test it to see if it would work. And we asked them to break it. We wanted to find all of the edge cases that wouldn't fit in and learn from their actual use of it. In order to get to that, we knew that we wouldn't be able to get in all of the features that they wanted. So we went for the 80-20% rule. And with 20% of the effort that we were going to spend creating components and getting them built, we picked the ones that we knew we'd be able to do quickly just to validate the overall approach and then made it really clear what was not included yet so that they would know how to give their feedback. So yeah, this is the same diagram, but we kind of picked one or two content types to test this experience with. So we knew after two or three sprints we weren't going to have all of these content types developed and with the front end. So we picked an article or story or one of those ones that they were going to be using a lot of to achieve the storytelling goals that they have. And I'm not sure if this is going to work. I was going to click over to this. This is a visual of a content model. I find content models are like, there's so many different ways to represent them for different audiences. This was one. And I don't think I'm going to zoom in. Oh, look at that. So this was a visual one that their editors could use to understand what kind of ingredients, what Lego blocks were available to them, largely with paragraphs in Drupal. So on the right, these are node types and they're sort of like groupings of node types as well that we created. They're total of only 11. So it looks like there's sort of more than 11 branches at the end, but they're 11 node types. And then these are different groupings of paragraph types. So this whole bottom stuff is called to action. There's media somewhere in here. It's been a while since I've looked at it, but anyway, it's kind of like a taxonomy of the content model in a way. And one of the things that it shows is that we really tried to push stuff over to the left into the smaller things in Drupal. And that is evidenced in, if I can get my mouse back onto this screen. Actually, there we go. Oops, let's skip the slide. And these numbers represent sort of how the content model changed from their Drupal 7 site to Drupal 8 that we built. So those kind of higher level entity bundle types, node types and taxonomy vocabularies, they went from 31 to 11 in Drupal 8. We actually turned off taxonomy, which as someone who really likes taxonomy usually felt really weird but also kind of cool. And then, yeah, the one thing that did go up is small groups of fields. So they had been using field collections in Drupal 7. We didn't reuse any of those really, but we did end up with 28 paragraphs and custom block types. Paragraphs for non-reusable stuff and block types for reusable things, which were sometimes in paragraphs, if you know what I mean. And then, yeah, I think the fields is maybe even more meaningful in a way. Reducing the number of fields as much as possible. That reduces technical debt when it comes to refactoring and simplifies the authoring experience. It helps you guarantee that your authoring experience is good across the board. The number of fields on nodes went especially down and then, you know, a few more fields within paragraphs. But not a ton of fields within paragraphs. Yeah. All right, I'll pass it back to Iris. The first mention is that we, while we were planning out this content model, it also worked hand in hand with development, the planning, because we all had to huddle together to figure out which of the content types we can break out and what are these pieces that we can pull into components while just that makes sense with the content model. And that was an interesting change also for us, because usually we have the VX and the UX happen before it's handed over to the developers. But this, everything worked together with planning how we would build the site. So in a typical project, the requirements are like a pile of Legos and the feature set is just to take this pile of Legos and build a truck out of it. So if at some point the client decides, okay, I also need a race car that gets carried on the truck or something, you would have to get another set of requirements and like another set of building things to build a race car or a different content type with a unique set of fields to fulfill that purpose. But when you're working with components, being able to sort your pile of things into discrete components helps so that you now have a view of the ability actually to create different things with these same components. And you also see more clearly the overlap between these two things that the client wants a truck and a race car that seem completely different from each other. But when you sort out the components and structure them, you realize you can actually reuse some of the things for the truck to build a race car. And to structure components, we use the atomic design approach, which has been around for a very long time. I started with Brad Frost and it just means that you have little atoms, discrete elements of things and they get used to build bigger and larger things until you get to a page. And if you look at the page, you can pick out all the atoms that went into it and then you can create different types of pages with the same atoms. So we use pattern lab to do this, which is a design system, but there are also other options. For example, KSS node and there's also fractal.js and fractal.js has different templating languages you can use with it, like handlebars or even Twig or React. So what this does is really brings you to a point where your component library is this standalone thing and depending on the front end you're going to display this component on, you can use the templating language that would fit your front-end framework. This site was not decoupled, by the way. It was a pure triple-eighth site, but it could have been and we could have had different ways to build it. So this is an example of a component. The hero component had just one... Actually, I think I might... just one component in pattern lab here. This is an instance of pattern lab. Across the top here, it's not so clear. We have a large set of molecules which are built from the atoms here and then it goes up to fewer organisms and hardly any templates because the templating system happened within Drupal. So we had this one hero component and it ended up being used in different variations. For example, this is a page about measles. The hero is different from the page about special locations but it's still using that same component. This is different too, but these minor variations are built into the component library so you can choose depending on the context where you're using it, how you want it to get displayed in Drupal. That's the slide. And the address component was another example of just looking at how little things make up a larger piece. It shows... I'm sorry. In pattern lab, it tells you that this block contains the following atoms and the iFrame map, the address atom and the iFrame map atom, which is this and this section. And then it is included in a larger organism, which is events. This probably won't work. Let me see. Okay. And then we had other components too that we use across the site, like teasers and statistics. The statistics one was actually really interesting because it kind of displayed how components can be platform agnostic. Any tool used in Drupal to render them is really viewed as a content source. So if you're using the core block layouts or paragraphs or layout builder, all it's interested in, all this component is interested in, is getting the content from Drupal. It's going to display the exact same way, regardless of what tool you use to display it. So interestingly, we had the statistics block here, which is a paragraph type embedded in the node. And then there was also another instance where it was in the footer as block. So we created a custom block type for it because that had to be displayed sites-wide and not on a perinode basis. But it still used the same components from Paranlam. And let's just say that really made that development a lot more fun and easier because we had to do less work. But better than that, I think the clients just saw the possibility. They had this explosion of ideas, really, where at first they just wanted a subset. They had requirements that had been stipulated and things had to be this way. But when they saw this large toolset, the possibilities of what they could do were just like endless in their eyes. And the love, the fact that they had that flexibility to create more things. And one good example of it was the FAQ page. So the initial design, they just wanted to have one page and that page will just be for every form of question users could ever have about MSF. They wanted that to just be restricted to something about their work and something about donations. But when we built this block down here, the one with the topics on top and the drop-downs, the accordion, the drop-downs there, they realized they could use that in many other places. And so they started using it in the Mizzou's page, for example. They used it to create this path. So they started adding facts and questions to different things just to expand the type of information that people get. So this is still ongoing. Features are still being added. The sky is the limit and the client is having fun. We are really happy to still be working on it with them. So the premise of all of this is... This is yours, right? I'm sorry. I was going to just quickly rehash some of the main points. So yeah, using this component-driven approach to content strategy, content modeling, getting in front of our users early, especially the editors to make sure that this approach would work, letting those users invent new ways of combining components to come up with new types of meaning and high-quality content. And then also, I don't think we spoke to this too much, but coupling the content strategy with development so that we could be agile and in tight feedback loops. You know, research, content modeling, development, front-end design, back-to-users. Having those tight loops really helped us learn quickly and exceed a lot of expectations, I think. Yeah, that's it. I think we've got four minutes for questions. Thanks very much. And there's a little bit of information about how to get in touch with us. Or just at civicactions.com. Go to the team page and you'll find us. And I also just want to mention the contribution of opportunities on Friday. I think this is going into a lot of talks, so you've probably all seen this, but lots of stuff you can do on Friday. And then we very much appreciate evaluations There's the very long URL. Or just go to the website, find the session, and leave an evaluation and we'd appreciate it. Yeah, thanks and three minutes for questions. Hi. At the beginning of your presentation, you talked about you had a collection of sites that you were working with to begin with. I expect they had existing content types. Can you talk a little bit about the process of I expect there had to be some changes to those types and maybe challenges that you encountered and how you address those? Yeah, you know, I totally forgot about migration, which was a part of this. So that was part of that analysis as well. So we did do an audit quantitative and to some extent qualitative audit of that content. We learned pretty quickly that we would only be migrating the stories that are such a value added part. They were rewriting all of the static content on the site pretty much from scratch. So a lot of our attention to auditing was on just that one vertical of stories. And it was illustrative. We didn't go like MSF-wide. We focused mainly on the Doctors Without Borders USA website for that. If you're interested in the broader network and how we did some really cool stuff, MSF has done some really cool stuff with media libraries and that we were able to plug into from Drupal. So if anyone's interested in how a media library in Drupal can plug into a third party, that was... Yeah, we didn't mention that at all, but that was some of the research that we had to do to figure out how to get the new site built. I was particularly interested. I work at a university. We have to deal with a lot of legacy content types that there's a lot of inconsistencies. Was there any thought put into maybe trying to introduce more consistency across those content types in terms of how you were naming your fields? Yeah. That was a big emphasis, is to try to keep the fields uniform and everywhere. And that's one of the reasons why you want to keep your model small, if you can. And have the stuff that's reusable reusable as much as possible. So we had very few... The content types themselves, the node types, for example, really didn't have very many fields in them. So it was a lot less to maintain and a lot easier to provide that consistency in multiple places. Thanks. Sorry, since there's no one else here. Did that add a lot of complexity into your process? The process of trying to introduce that consistency, did it make it way more difficult? Or... No. I think this was a relative... Maybe this use case was a bit easy for that, too. Yeah. I think it's... Yeah, we did have to rename some stuff. And so that's why I think it's really important to refactor early and learn those stuff. But certainly it's complex. But yeah, I think that getting those changes... Getting in front of people so that you can find out where you made of solve complexity the wrong way, for example. We probably had two or three passes total to sort of get to it. You can't do it all in one shot, maybe? We're thinking of doing something like that. It's helpful. It kind of gives me an idea of what we're looking at. The biggest problem for that, from my perspective, is a technical debt one where your machine names are totally out of line with your field labels. So I don't know if I'm talking about it, but yeah, that happens... Another project I'm on now where we've renamed things as we've gone along and to try to standardize. And so we've ended up with some technical debt there. Yeah. Well, thanks. Hi there. So, Mike, I work at our college and we have a large amount of editors up to the hundreds at some points. Is there any efforts you had to go through to help enforce best practices around adding multiple components to pages? So preventing editors from potentially adding 10 buttons in a row or something like that. Is it training you had to go through or is it just kind of a trust thing? I've seen that on a different project at the moment where I've really big concerns about that. They've got really well-trained, small staff of people who are doing this, so we were really lucky that we didn't have to worry as much about that. They're the content designers in a sense and I think that that's maybe one of the principles here is I think that content creators are content designers. They may not be good ones and so maybe that's the case that you're concerned about is that I think they're bad content designers. In this case, for MSF, we had great content designers on the editorial team. So we had some guardrails for sure but for example, there was no form validation to say no, you can't add 10 of those statistics bars in a row because we knew they wouldn't do that. Another project I'm working on right now which has thousands of editors potentially, I'm much more concerned about that and how to apply some of these principles to when you do have paragraphs or that approach, Layout Builder, things can go pretty badly pretty quickly in the hands of the wrong people. So do you have any early thoughts on how you're going to approach that issue or is that just going to come down the road? In the projects I'm on now, we have the workflow permission so I think a lot of it is also in the hands of the clients enforcing that workflow where not everyone can publish something so if someone puts something, it gets into a draft state and then someone else can review it before it actually gets published. That would be a permissions and roles solution. Okay, thank you. I'm curious about the outcome of what you guys have done both in what type of user has benefited the most from these changes just because you have such a diverse site and then if there has been any impact in your fundraising efforts from this. Did I stump you? So I think one of the things that a lot of Drupal projects are faced with is that we've got two sets of users and sometimes they overlap but in this case there's the end users of this website who are people who might get apply for a job at MSF, people who might donate and then people who are interested in the new stories and sometimes those three business goals overlap. Their team is so sophisticated that we couldn't contribute too much to studying that part of it. We just wanted to give the tools for them to build the content they needed and then they could test it. So their metrics teams are amazing so I can't answer like, can we measure that? But I think the qualitative research that we did around authoring experience with users of the product which was fairly informal like it was not rigorous user research by any means but I think the kinds of work that we were getting from various iterations that we put in front of people was that they were able to do what they needed to do and then we were saying we were able to invent new ways of doing things that they hadn't thought of before so those were the metrics that we were kind of interested in the scope. So it was like the authoring experience for all of those end users all around. And now there was one big road block we'll say. You said there wasn't one big road block but there was. Thank you. Thank you. Could you elaborate a little more on how you went from all the taxonomies to zero? I'm just trying to wrap my head around that. I clicked uninstall on the taxonomy module. The other next speaker needs to set up so do you want to type just quickly and anyone else who wants to talk with that?