 Welcome everyone to StyleGuide Driven Development for Project Managers. We're really excited to share this with you. I think there are a lot of people talking about StyleGuide or Component Driven Development over the past couple of camps and conferences. Yeah, there was definitely some pretty good buffs about it this week, a bit more technical presentations. This is gonna hopefully be a bit of a later overview more on the why you would wanna do this and how, but there's definitely some other sessions you could check out if you wanna get deeper into the specific tools and whatnot. So if you're looking for the specifics and the highly technical, this is not the session for you. If you are a non-technical person, this has been made specifically for you with just enough to share and bring back to your technical teams. So, about us, my name is Adam Weingarten. I'm a technical architect at Aquia in our professional services group. I help estimate, design, and implement large-scale web builds, and ultimately I want them to go smoothly. I don't wanna have to work late nights and late weekends and burn out developers. I want things to go easy. And I'm Sarah Thrasher. I'm a front-end architect also at Aquia, and I also like things to go smoothly and don't like to be burnt out working nights and weekends, so here we go. What is the problem that we have? I think that anybody who's been doing Drupal theming for any amount of time, I personally have been doing it since Drupal 6, although I have even touched Drupal 5 sites, and I think it's a pretty common thing that you hear from people who do front-end that getting Drupal to look the way that the designers you're working with want it to is kinda difficult. It takes time. It's hard to find good front-end developers who are interested in and or knowledgeable about Drupal to be on your team, and a lot of the workflow habits that we've picked up can make the front-end phase longer and riskier, and given that it tends to come at the end of the project, that can be pretty bad for trying to get your site launched. So the usual process for styling that we follow back in the old days was your client asks you for something, usually a pretty cool thing, in a page, and your UX and design team do some comps and wireframes, there's some requirements gathering, your back-end developer builds a bunch of widgets, the comps are thrown over the page to the front-end developers, and then the front-end developer starts hacking away at that, working those nights and weekends that we referenced earlier. So what the hell is style guide during development? We've thrown around a word, and we need to qualify what it is. So the idea here at a very, very high level is that you're going to start with visual designs. Nothing new here. But what we do is we break those designs apart into visually modular elements. We're aiming for Lego blocks here. And we want to build a small, ideal model. We do not want to build a page. So here's the problem. In the old model, we would hand a front-end developer a page and say, go build me this. They would create their own universe for that page. You'd give them another page and they would build an entirely new universe for that page. And these pages would be extremely brittle. They'd be problematic. If you've got multiple developers on your team possibly coming from several different contractors and you're trying to split up this work, stuff can get very close, but then there's actually subtle little differences between the implementations of things that are supposed to look the same that you might not catch when you're doing UAT on them. And then that does sort of degrade the overall experience of your site as people are going through it because these little inconsistencies really build up. And then eventually when your client decides they want to change the font across the site, that's really painful. Why didn't these three pages change? So here's that design kind of exploded into modular elements. So what we're doing here, this is more of an art than a science and this can get into some pretty nitty gritty technical areas or at least CSS architecture of how you actually go about and implement this. But this isn't specifically just style guide oriented. This gets also into component driven design. So what I mean by components here are design patterns as in visual design, not something like a JavaScript for Java design program of patterns. So somebody on your team, hopefully several somebodies will spend some time breaking up your bits into little interconnected and related chunks that can be worked on separately and developed discreetly from one another. And you might look at this and wonder, do I have to get this perfect the first time? The answer is no. Sarah said it's an art. It's not exactly a science, which actually is the way that we normally do things. I think a lot of you guys, if you're project managers, use something called story points to estimate. It's an estimation. You don't want to spend lots and lots of time estimating. You use a Fibonacci sequence. You try to nail it down as best you can and then you move on. So for an example of something that could be worked out as a separate design pattern, this is a Masthead element. It's got a logo. There's a header text on here and there's a large background image. It's a small piece. It can be surrounded by tons of other pieces on actual pages. In this particular instance, this may not actually be reused anywhere, but we're still picking it as a simple starting point to show you how this breakdown works. So your developer needs to think about how to take this individual piece and build it so that we can create this full page. So how do you do this? The first part is you forget Drupal. When you start, there is no Drupal. Put it out of your mind. All the horrible traumatic markup that you experienced in Drupal 6 and Drupal 7, it's gone. So like getting to your safe, happy place, you know, this is a bit of an optimistic methodology. So do not start from, you know, all the crappy things start from your good place, you know. Don't dig out any of you's templates at this point. Don't do views templates. Don't do any crazy Drupalisms. It doesn't exist, you know. Go to your happy place. So what does that look like? This is a small chunk of markup that we've put together to implement this piece. On the technical side here, we're using BEM to create the classes. One of the reasons for that here, you don't have to use BEM, but it's a pretty good starting point for a Drupal project because Drupal Core actually does this. If you look at the Classy theme, this is actually why it's called the Classy theme. It's full of BEM classes, which the breakdown is block element modifier. So in this case, the block here we've chosen is hero, which is just the name of this thing. And then every individual piece of it has its own class. So wrapper, logo, and title, and they're just appended on there with underscores. And then the following piece that we don't have here is you can also have a modifier, which is if you have several of these things that have a visual difference, but not a structural difference, you use hyphens and put that at the end. So it could be hero, pink, or something. And because you don't have to use any different elements for that, you just have that variation on here. So it's not required to use this methodology, but it complements building out these separate chunks in the style guide very well, and it's already something that you're gonna be dealing with in Core. I don't wanna scare any of the non-technical people in the room, so we're throwing some of these examples in, mostly to give you guys something to take back to your developers. If you don't understand what is here exactly, don't freak out, that's okay. Yeah, and as you can see, none of these are like those kind of classes you get out of Drupal, like .block, .view, .png, or any of that, because we'll show you how to get the classes that you have done your dying against into place. So, what content is this thing gonna have? So any little piece of markup that you wanna put onto a page is gonna have some text in it, and possibly images. And those bits can be broken out into simple variables. So an example in here is the title, or body, and these don't have to be anything that has to do with where Drupal is getting them. They're just the parts that can be used by this pattern. So this example is specifically what KSS node, which is a particular builder would use. It's a very, very simple example of a JSON file. So in this example, we have URL because this mass head is linked, logo because there's a logo smack in the middle of it, and some alt text for that, and then the title text. And these variables don't have anything whatsoever to do with Drupal. If you were building the style guide for a WordPress site or some other system, you could use this exact setup, and you don't need to worry about what ones you might be using for some other piece of this style guide. They're completely for this one little piece. And then this is an example, again, KSS node, just because that's the one that I'm the most familiar with. We use the most of our projects. The comment at the top is actually for the style guide. And most of these systems have something similar to this, but there's a title, the name of the thing, that's important because how are you gonna talk about it if it doesn't have a name? It matches the name of the classes we've been using. The next line is a short description. It points to a twig file, which is the templating language that Drupal uses. That's important that the style guide system actually does use the same system as we'll talk about a bit later. And the line that says style guide is a style guide section. So these in KSS node are top level sections. For something like this that's important, it can have its own section. Some smaller bits you might have a bunch of things all together in a subsection. So you take all these different things that we just showed you and we probably overwhelmed you with and you mix it up and you get a style guide. KSS in this case is a static HTML style guide that a normal person can go and click through. You can go and look at any of the elements that you have built out and you can see them in isolation. So you can go look at the little Lego blocks that you have now created and you can evaluate them. Powerful and you have a little HTML example right below all of them to show people, how is this working? What are my classes? What are the things? You have a great interface here. It's kind of like a Rosetta stone for developers, for designers, for UX people, and also for your stakeholders. And this is something that does not need Drupal. It is just pure static HTML. How do we do this? We'll get back to that. Don't worry about that for now. Once you've done all that though, at a certain point, I told you to forget about Drupal. At a certain point you want to get back into it. Yeah, it's not useful if you don't know how to get your Drupal stuff in there. So because the style guide is using twig files and Drupal 8 themes also use twig files, let's say that we have a block and this is either a custom block that we've added fields to or maybe we wrote a small module. Possibly that also has fields. Maybe we just static, you know, hard-coded this because we're lazy, whatever. It doesn't matter. Drupal has block templates and no templates automatically right out of the box. And all we have to do to use this template, there's one other little piece where we're using a module to add namespaces, but we can use twigs embed functionality or include to point to where this lives in our theme, the style guide is inside of the theme. And then the width here is another bit of JSON, which we're talking about, to pass data from the Drupal template to the style guide template. So the stuff on the left matches those simple little variables we came up with for the style guide and the stuff on the right is actually coming from Drupal. So the style guide doesn't care what the source of this is, you do, but your developers are used to breaking out these variables. Anyway, this could be simply passing fields or these could have been built through pre-processing, it doesn't matter. Yeah, and you can think of this as an abstraction layer. It's a total mapping layer to bridge the gap between Drupal and the outside world. So you have a style guide now and it's been mapped into Drupal and everything is awesome. Cheers, have a drink, you're awesome. Cool. You know, it's not that useful if we just have this one component. We had a whole page that we were looking at. So we're gonna continue along with all those little design patterns that we picked out and we're gonna build all of them. And there's probably several other pages that also have more components and you're gonna be working with your design and UX team to map out what all those are, come up with names for all of them and make sure that the little chunks of data are working, you could do browser testing. Some of these things may show more than once on the page so you're gonna have to work out things like wrappers. But this is just the same styling you're used to doing. Any sort of CSS that goes with those classes, you need to work out how two or three of these things work together, responsive behavior and all of that. And you keep repeating until your style guide is full of every single component that you could possibly need. And we're done. So everything's great, we're done. We have the perfect style guide, we've got all of our Legos. We have everything graded into the theme. Like everything is great. And then that happened. That never happens, right? Who here hasn't had a change request from a client? Anyone? No hands, okay. Yeah, so then that happened. So what do you do? Do you freak out? If I was using the old page model, yeah, I might freak out. That was really, really difficult to make changes because I had all these monoliths, I had different universes of monoliths that they wanted to make a change to all of the universes. Sometimes if the pages look okay, you have no idea what kind of spaghetti is lurking under there. Yeah, they're redragons. So what do you do? Yeah, keep calm, it's okay. We'll get through this together. So you go and you make your changes to your style guide. No big deal. You recompile, you do some of that magic that we told you to not think about. And then you enjoy it, that's it. You're able to make these changes without sweating too much in a much, much more reliable way. You can enjoy until the next time around. And there will be a next time. And a next time after that, cool. So I'm gonna talk a little bit more in detail on the technical side of this. Not incredibly deep, but at least enough to do some more research to see if you need to pick out some particular tools or there's a few things I heard about this week that I'm gonna definitely look into when I get home. The style guide itself is a simple static site. So there's a lot of different tools out there. Sometimes people even hand code these. You could write your own if you wanted to, but there's a lot of different tools out there that use templates that are similar looking to what you might be using for your Drupal site anyway and can interoperate with it like we were showing you in the integration example. And then sample data. And there's a few other cool things that are out there in contrib that I'm gonna touch on. So why are we calling it a living style guide? There's a few different types of style guides that you might come across as you're working on this type of development. I've been handed a lot of PDF style guides. So that's obviously not gonna drive your site. And there's also sort of a separation of keeping that updated, updating the theme, them getting totally out of sync, and then people stop looking at it. There's also style guides that have been built out that are still separate. I think you've seen a lot of examples of this, such as like Bootstrap style guide. That's another style guide. And even if you're using Bootstrap, your site might not look exactly like the examples on the Bootstrap site because you've customized things. You've changed colors, you've recombined things. So that's not really what's showing up on your site anymore. And then the living style guide is similar to that in structure, but it's actually using your styling, the same CSS that your theme is using, and ideally the same templates as well. So there's a lot less duplication. And then anything that we're changing in the style guide, as long as we've kept to this component driven design and development methodology, if you have changed something and it looks correct in your style guide, you're using the same markup on the drip side. If you make it look good in the style guide, it's gonna look good everywhere else on your site. We have all of the same markup. We have all of the same CSS. So you can trust that this one example, which you always know to go and look for, is matching what the site's gonna be showing. One of the fun frustrations in trying to fix things sometimes is not being able to find a published, created example of something in the Drupal site. All right, I need to make a note. I need to fill out what fields again, or having to pull down the database. And if you can do something that's like a CSS or HTML kind of fix on something like this without having to create a bunch of different examples that can speed up those fixes quite a bit. Cool. And so this is another little technical bit. One of the things that can really help with having this style guide that might already be easy to integrate into your workflow is having a build tool to run the generation of this. So this is just a small snippet of a gulp file where we're passing options such as the style sheet that's being loaded for the site that gets loaded into the style guide, the location we want the style guide to live in. In this case, we're specifying that we wanna use twig. That namespace bit allows the KSS stuff and the Drupal namespacing to use the same stuff. So if you're using embeds within that stuff, both in the style guide and in the Drupal site, they're using the same namespace and don't collide with each other when you try to integrate them. That's a little bit more on the technical side. But all this stuff is configurable. You can make this work with your existing theme. You could pull this in and if you're doing some kind of refactor, it's a great time to make sure that everything that you're using is sort of clean and modular and works well together. There are also tons of tools out there. Like I was saying, there was an excellent couple of buffs about this. Some of them are more widely used in Drupal specifically than others and there's new ones coming out all the time. So you're probably gonna wanna do a bit of research for what works for your particular instance. Like I mentioned, KSS node is a pretty popular one in Drupal. The main reason is, aside from KSS having been around for quite a long time, it's one of the earlier tools, the maintainer is John Albin. He's one of the Drupal core theme maintainers. He maintains the Zen theme, which is a very popular base theme and this has been integrated in the Zen theme since Drupal 7. So there's people who use this for reasons. Pattern Lab, you might have heard several times. The reason why this one's popular is because it's Brad Frost, who's kind of the guy who has been popularizing Atomic Design. He's written the book on Atomic Design and he also wrote Pattern Lab and it's a pretty cool option as well. SC5 is based on KSS node but it's actually got some angular integrations so it's UI is a bit fancier. And I've also, there's tons of roundups in compare and contrast because everybody is looking to do something like this nowadays. It's definitely something that you hear talked about at this Drupal Con last year. So there's plenty of information out there if you find this interesting and want to look into whether it'll work for your project. And then, like I was showing you with the Gulf integration, if you can get this integrated into your build so that you're not giving your front-end devs all kinds of complicated command line instructions and there's something simpler that they can run or possibly they can be run. That's something they don't have to touch. It's much easier for them to cope with and you probably have something integrated like this as well if you're using SAS or LAS for something along those lines. So, you guys are cynical, right? Why should I care about this? Developers get all excited about brand new technologies and cool new toys. I mean, that's what's gonna happen at a Drupal Con. Developers get all sorts of cool stuff and then it screws up your delivery. So, why is this a good thing? So give me a reason. I've got eight. We've got lots of good business reasons why you should do this. So, I'm not gonna go through all of them right now but this is everything. There's a lot of good justifications for why. So you can validate your client's business requirements, you can increase the accuracy of your estimations, you can speed up your development, you can increase the quality of your deliverables, you can build confidence with change requests. We talked about that a little bit, we'll talk about it more. You can accelerate your delivery velocity. You have more people who can help you get this stuff done. Right now, there aren't a lot and integration becomes a whole lot easier and less risky. So, validating client's business requirements. So, by having these static models, you can preview styling without Drupal. So, before the backend people have done anything, you can start to get stuff in front of your clients. That's huge. You can get feedback, they can tell you what they like, they can tell you what sucks and you can go fix it. You can also use this to do cross-browser testing, load it up on mobile, different devices. So all this CSS type stuff is sorted out where you're starting on the Drupal bits. So, what you're gonna probably wonder is aren't we just talking about Agile? We build a model, we refine it, we keep going, we make it better and better and better. Well, yes. That is exactly what this is. You just figured it out. But what that implies is that the way that we've been doing this hasn't been Agile traditionally. It hasn't been all that Agile. Tell me how long it will take to finish the theme. I mean, basically we have turned theming without realizing it into a waterfall task. That's really horrible and incredibly dangerous. So, I mean, what that means is we have this huge monolith. We have no idea what's going on and there's always a crisis at the end of a project, always. So, the other cool thing. You can start working on this, like Adam said, without having any Drupal installed whatsoever. Since it's a static site, you can create your little models, you can style them out, you can touch them against each other, you can even build up these small bits into pages that match your comps. So, this allows you to work without Drupal. You're not held up by people building a module or even doing site building to work on the styling. This separation is very useful to, you don't have to bring in back end people, people who know PHP, Drupal specialists. You can have the front end people actually focus on the front end, build the back end people, work on the back end. You have fewer blockers, you have fewer dependencies that are happening. Those are always delightful to juggle in JIRA. And inevitably you will forget them and you will screw them up or you will just hit them. There's no way around them sometimes. Like I mentioned earlier, splitting up tasks by components reduces inconsistencies in the pages. I have absolutely seen this on projects where if you have a very large team and somebody's like, all right, you work on the homepage, you work on the news section, you work on this, but they're all using basically the same titles. People can have very slight differences between those things when they're working independently from each other. And those things aren't always that easy to catch. Smaller tasks allow you to move things across the board more quickly and QA those things separately and then work on QA and integrating the big thing as you've got the pieces together. And you can have multiple people, again, doing things. So if you have lots of small tickets and you're keeping your QA people busy, you're keeping your UAT people busy, you're keeping people saturated. Whereas if you have this like sputter of large tickets, all of a sudden people are gonna be paused doing nothing and then all of a sudden there's a crisis. So smooth that out. Like I said, we don't wanna work late nights and weekends. So one of the things that also helps a lot on is increasing the accuracy of our estimation. So how does it do that? It does it by letting us decompose these monoliths, these huge pages into smaller chunks. So how does that kind of look? So think of it this way. The square on this side, we'll totally get the word individual. Hang on, it's me or you. So that one, you guys look at it. Okay, you know, it's nine units of work. The other one, does anyone have any idea how big that is? Any guesses? Can you give me a number for how many squares there are? 400. 400? Who the heck knows? Do you know? We'll see if it's on each side. I don't remember how much it's on each side. 125? Could be. But the fact is that if I'm looking at this, it's really, really hard to figure out what's going on. Smaller things were able to approximate, and not even approximate, were able to determine really quickly. Big things were really bad at. So, you know, what's my answer? Who knows, but we got three different ones in this audience. That's the point. You could. What is the answer? If you get a driver, everybody does. You're gonna have to answer this question. So, the answer is, let's see. I'll tell you at the end. But this is gonna be a grooming session. Okay. Yeah, but the key is, you know, estimation's important. That's our bread and butter. That's how we get stuff done. And if we can estimate these things better, we can resource better. We can keep things moving. We can keep people saturated. We can increase concurrency. All of those things are really, really important to get right. And then ultimately, it increases the quality of what's actually being delivered. This really struck me the first couple of times that I worked using this process. In the past, what would happen is you would hack away at the styling and the theming at the same time, and you would do a really horrible job at both. You would start trying to get the markup from Drupal. You start with the markup from Drupal, which was horrible in Drupal 7 especially. You would then try to write CSS to target it. Then you would start making more changes to the markup and the CSS. And you would have horrible classes. And at the end of the day, the final result was ugly. It was brittle. It wasn't scoped well. I wouldn't say ugly. You don't think it was ugly back in the day? Depends on your developer. I don't know. It was pretty rough. But ultimately, by separating these tasks out a little bit, you do each one much, much better. So we showed you there was a little bit of markup. So that twig. It's beautiful. It's simple. It's clean. There are classes that you can read and understand. We're using that smacksbem syntax that Sarah mentioned. We then have a really, really nice small sass file. And by using smacksbem, we also are making, we're creating a concept of visual scope. So if we have styling or effects that are happening, they affect our component and they don't affect everything. So if I make a change to one component, I have some confidence that I'm not going to then nuke other parts of my site. That's really, really a big deal. And kind of slightly on the performance side, if you're doing this component-based CSS architecture, your CSS file is smaller. So that's better for performance. Bonus. And once we have this, change requests become a whole lot easier. We kind of talked about that a little bit earlier. But you change the model, you change your Drupal. And you can very, very quickly QA both the model and you can even QA Drupal. You have a lot of confidence and that scope means that you're not gonna break it. And finally, you have a much larger pool of developers now that can start to do stuff. Because if you don't need Drupal to start your theming, that means you don't need to necessarily know Drupal to start this process. You can have someone who is more of a just a straight up JavaScript or CSS person to start to put these pieces together and to decompose your models and to create the components. And then you can delegate it to someone else who can then bang into Drupal. It's kind of like a Henry Ford modern assembly line approach to development. Smaller chunks, going through the factory and discrete tasks. I've definitely worked on teams in the past where we got UX people who are relatively familiar with HTML to just be able to take these little chunks. Sometimes we would work on it with Bootstrap for a foundation to do this, but they could build prototypes really quickly just because they can copy and paste those little static bits into a page and then show it to people. Yeah, and then, so the style guide can be created before the main dev team, the back end people or the people who are actually integrating into Drupal come on board. Twig is really similar to things that people would use in other systems. So you might have somebody who's not a Drupal specialist but because they've used Mustache before, they can totally work with us. And if they haven't, it's actually not that simple, that difficult compared to looking at HTML. The locations where the variables go are bracketed and you put the variable in there and there goes your text. And Sarah and I have this dream that one day we will actually be delivered our style guide, not in PDF, but as a visual style guide like this. It is the dream. It has not happened yet, but one day we hope that designers will start to even think this way. Cool. And ultimately the integration becomes a whole lot simpler. You can make these aggressive front end changes without being too afraid. You can avoid visual regressions because we have that scope and you can style in small testable chunks. So we can send the style guide to UAT. We can maybe theme a certain part of a page and send that chunk over to someone to start to get feedback much, much more rapidly than we ever could before. And, you know, a completed style guide that's actually living in HTML that's in sync with your actual site can be an excellent reference for content people, for those UX people that I was talking about later, or for future business decisions such as new sections of your site, completely new sites and stuff like that. You've already done the styling. You have the style guide as a reference for all the things you've built already. And also, one of the big points in that is it can help you start to be more consistent about what's on your site. Often what happens is maybe when you first built the site people knew where the style guide was located, like the PDF, and then afterwards designers go off and they want to reinvent the wheel. They create pages that have nothing to do with the overall design and vision of the site. They just go rogue and do something crazy. Whereas now you have a style guide that can be linked from your website. It's always being updated. So you can enforce some consistency across all the new development as well. It's in the drive folder, didn't you get permission to that? Yeah. It also, for people who are working in it, it documents things that you've already built. So if you have something that's slightly similar, you know you can make one of those modification or variants. It documents how the thing is meant to be used and options that might not be showing created content. And it's a useful reference for onboarding new people because here is all of our existing styling. Here's what it looks like, and this section has all the pieces you're gonna be working on. And you know, if you do it really well, you can end up with a pretty amazing style guide. This is one from actually a D7 site that I did last year. And every single piece of that site was built using components. So it made it really, really simple for us to blow through all of these. This was one that Sarah pushed me on, I remember. Yeah, and this one isn't using the templates since in D7 that's a little bit more technically difficult, but it's still really valuable having this as a reference, even if you're forced to sort of copy and paste stuff into D7 templates instead of using the embed technique. So this is the goal, is you know, you're curious, what does the stock quote look like? What does the event reference look like? You can go and click through any of these and get more information. So we're getting, actually close to the end. So getting triple to look the way you want is hard. Can't be hard. Yeah, it used to be. Cool, yeah, you've got some tools to help. And then component-based approaches to both your design and your theming can make all of this a lot less stressful. And a living style guide is a great way to work with Drupal. I feel like it's the future, it's the thing that everybody has been talking about for the last two Drupal cons I've been to. And there's even talk of putting some of this into Drupal core. So even if you don't start doing this on your next project, it's definitely worth learning the ins and outs and doing some research and maybe some little proofs of concept. And you know, while it's a great technology, ultimately it's really about delivery. It's a great agile methodology that can help improve your ability to make your clients happy, to keep your developers happy, and to get things done on time and on budget. At the end of the day, what speaks? Time and money. So hopefully this will help you with both. So with that, we're actually at the end. Do you guys have any questions? Oh yeah, and if you do, please use the microphone and we'll try to repeat your question if we can't hear it. So as a project manager, I think this is all great. My developers kind of on board. We have a small agency, so we work with freelance designers. So how do you get them on board with this process? Or maybe you kind of answered and said that you get PDFs from them, but I would love to not have, hey, here's your static PDFs. On a lot of those types of projects, it's been the front end developers who actually build the style guide out, but definitely there's some education and communication that goes on there between your front end team and your designers, which ideally you'd be doing anyway, even if you weren't working on this technique, but definitely sometimes that's just not possible. Like the design is done even before you get on a project and then the designers leave, and I've been on that kind of thing as well. I mean, these are all values for us, not necessarily for them, right? So what is it for them that they would like to say, yeah, we want to get on board with like we're going to build you the style guide in, you know, a living style guide and we're going to get on board with this whole component design thing? I think if you're working with people who are coding designer types that may not want to work anywhere near Drupal or have anything to do with it but can do the HTML and CSS themselves, I've worked with tons of designers who write their own CSS or will tinker around in Chrome, do a screenshot for me, and I'm like, why didn't you just send me the CSS you did in Chrome? Because now I have to figure it out again. So that's definitely something that could be done on your team. And something like this that's a little bit simpler and doesn't touch Drupal is like the ideal place for that type of designer and developer collaboration. But I think that's a lot easier if you're all in-house or have like a longer working relationship with each other. And it's probably the future of where designers are going to go. You know, I think, you know, we all know that PDFs just don't cut it. You know, PSDs, they are inadequate. They often don't work, especially now that we're dealing with a lot of responsive stuff. You always, you know, when you get one of those, there's always a gotcha or something didn't fit the way that they thought it was going to fit, even though you used all the right things. So, you know, there's going to be a newer generation of designer that's ultimately going to be expected to do some CSS. I don't know. But then, I mean, this is still a good thing to have. Like that might be the blueprint, whereas this is a mock-up that you can actually play with and see changes as you change the browser size. Yeah. Oh, is it, is there such a thing as, like, somehow using this mock-up that you start with to help with visual regression testing? Is that a thing? Like, is that, oh, cool. Yeah. What's that about? Yeah, one of the, so visual regression testing is when you actually use a testing software to automatically go through and check for differences in CSS and markup. So, something like Wraith or Phantom CSS, you point it at a particular URL and you have a baseline image, which is the way I want it to look. And these might be in your repo. And then, as you put in a pull request, that goes to that URL, takes another shot and then diffs them. So you get, like, a little pink lines, you know, for the padding changed or the height changed or colors or something like that. And if there are differences, it fails. So you could run through an entire suite for each one of these components. And if you've changed something on this thing that inadvertently changed this one because somebody was sharing a class or something like that, or you added padding to all the divs for some reason, a bunch of stuff would fail. You'd be like, oh, wait, I should check that out. And you would know to look at that specific component. The reason why a style guide is really useful for that is each individual component does have a specific URL and some specific markup around it. And this gets around one of the key drawbacks of doing visual regression testing on live content, which is people edit it. You would have a CMS behind it. The title might be totally different words. And then even though nothing's broken, you know, the images are totally different just because the line links are different. So the style guide isn't gonna have that because you've provided it with sample text from those JSON files we were talking about. So if you start here first, you know that this one will always look the same, you know, assuming that you haven't purposely made some changes to it. You didn't have to go and mark suite of BeHat tests to regenerate the content in order to get a baseline that then you could test. But you should still write your BeHat tests. You definitely should still write BeHat tests. This kind of follows up on it and I apologize because you are really at the edge of my knowledge and understanding here. So what happens if you embed these nodes and now you are in Drupal and you're really using the content? How does that change how designers react to it, clients react to it because content can change everything. I know in our projects, we put all our content in before they even start theming because my developers want the content. So I'm just wondering how you kind of navigate that territory because you said you put dummy text in and then when you get into Drupal you got the real stuff. On the style guide side, that's actually one of the things that's better about it than having to create nodes to test because if you use something like develop generate to fill out a bunch of sample content, you can do things like vary the amount of titles but in the case of creating the style guide you can make more than one little sample. Not all of your template stuff that you're using in there has to be specifically for embedding in Drupal templates. You can have like here's the widget with really short title text. Here it is with huge title text. Here it is in French, Spanish, Russian. And then once you generate that, you have that example for all the different variations and you can look at them together without anybody having to go through and make nodes. And you don't have to worry about deleting that later from like your test site because you're keeping this for reference. Yeah, can you, you mentioned using Behat. I use Behat for behavioral testing but it seemed like you're implying that you're using Behat for validating your style. No, just go, how do you find Behat most useful for you? Maybe that's a useful question. Yeah, yeah, totally. So Behat is a great way to test behavior. So I click here, then I see this or this happens, I do this, then that and just going through various steps. It's not really a tool that's designed for major visual tests. It's great for content, it's great for words, it's great for maybe some classes or states but not visual, there are better tools for that. So the one use of Behat that you might do is if you didn't have a style guide, you could use Behat to at least maybe generate the content so that you would have a predictable set of content that you could visually diff. That's the only reason I might use it. So maybe I would run Behat before I ran my visual regression test so I had a baseline. That's it. Yeah, I think on the style guide, the Behat test would be kind of useless because you know that the content's gonna get there and it isn't gonna change and nobody has to do anything to get there. So it's kind of outside of the realm of stuff Behat's meant for. So I'm a developer, so I understand that having a living style sheet is excellent for you to gather requirements. But as a developer, I'm chasing a moving target, basically, trying to implement your things as you're changing your style guide. Can you sort of address that? So first off, you had that problem no matter what. Yeah. The client was doing, you've just called out the issue now and made it a little bit more clear. So nothing has changed there. But also the key is if the visuals change, it doesn't really matter. What matters is what goes through into those JSON files from your point of view. So as long as you're passing parameters like that, then things are fairly consistent. If those are changing, yeah, you're gonna have some changes that you're gonna have to make. And you've talked to your client about what are the limits of what changes and what's the cost of making some of those changes? Well, you would have to go back to your Drupal templates in the case that you added or removed some piece of data that the template's using. If there's new fields that you're adding, that widget might need them, or if you've taken off a chunk, then you would probably have to go back and edit the Drupal template to match up. But if you're just changing the surrounding markup, then you're good to just go on the style guide side. Is there like a way of checking in your live style guide? So are we gonna have to determine that there's a change? In most cases, we include this inside the theme. So it's get committed with everything else that goes with the site. It is also possible if you're sharing this between several different projects, like I know for a fact that some people use these between several different Drupal sites, possibly WordPress sites or other systems. And in that case, you would need to use your build tool to pull that in, but it would still probably live somewhere within there and be version controlled. So it's not just something that we loosey-goosey get to edit any time. You sort of partially answered my question, but for one of our larger D7 sites, our developers had pros and cons for having the style guide inside versus outside the theme. What are your thoughts on that? I don't think it matters that much on D7, frankly, I mean, you could put it wherever you want as long as the CSS that it's using is accessible to the theme. I think that's the key point. And that could even come in from a CDN or something, honestly. For the technique where we're doing the embeds, it does need to live somewhere that twig can find it. And in the default case, Drupal namespaces, the templates folder, so it looks for everything in there, there's a module in contrib called component libraries. Literally all it does is give you the ability to find additional namespaces. So for pattern lab, those might be the atoms, molecules, and patterns folders. And then you can do, you know, I'm loading this from patterns, you know, and here's the file path relative to that. And that's just sort of a technical thing on the twig side. So in that case, it's good to have it inside the theme just because it's easier to reference things relative to each other. Yeah, in D7, like Adam was saying, you're definitely using it more of a reference since PHP template can't do this type of thing with the twig files. Although there are actually D7 twig themes. That's gutsy. Yeah. I would not recommend that. One wants to guess no play. D7 used to let you change the templating engine. So there are definitely things out there that I've never touched on a Drupal 7 project. Just because there doesn't mean you should. I like shiny things. We covered that. Anything else? Well, thank you so much for attending. Thank you. Well, thank you so much for attending. This is for a slide. Oh, that's resources.