 Okay, so today, title of my slide or title of my session is Managing Complex Projects with Design Components. I'm John Albin, John Albin Wilkins, better known as John Albin, basically everywhere, jubil.org, Twitter, that sort of places. I'm a senior front-end developer for Previous Next, and I'm really excited about giving this talk. I've actually been iterating on this talk for more than a year. The very sort of the prototype version of this talk was given at SASConf last year, and I've given it three or four or five times now, something like that, and it keeps getting better and better, and if you saw the video in Austin, it's way better than that. I have been doing drupal for 10 years now. My 10-year anniversary was like last month, and more importantly, though, I've been doing front-end development for the past 21 years. And because I've been around so long, I've done a lot of stuff, but it's just because I've been around for so long. ZenGrid, Normalize, Syncs, all this stuff. I'll post these slides, you'll be able to get the URLs later. But I'm one of the reasons why I'm so excited to talk about this topic today is because of what I've learned just in the past month. And I'm going to have to give a little trigger alert here. This session will mention the word agile. I'm not knocking trigger alerts here. This was my trigger word for a while. People kept talking about agile and not explaining it very well, and then they're like, oh, you'll figure it out as you do it, and I kept doing it. The agile or agile-like process and doing it does not make it any more clear. I got way more confused when I was actually doing it than before, because, yeah, just bad. But I have... My goal for today is basically to explain agile in a way that I would have understood it two years ago. That's my goal for today. How many people here went to David and Brian's state of the front-end session yesterday? A fair few of you. So their question was basically, look at all these different technologies, what's going on, can we know all this stuff? And I saw the first version of their session at DrupalCon Austin, and I've been thinking about this question in front-end development very strongly for the past several months now, where are we headed? And there's a great quote here by Nicholas Gallagher that says, are you new to front-end development? Here's the secret. No one else really knows what they're doing either. And I was totally true. It's very overwhelming, especially when you're new, but even when you've been around for a long time. This quote is from January of 2013, so it's been a little bit... Hopefully he's a smart person. I'm sure that he's figured out basically what he's doing. And so rephrasing the question, what the hell is going on, the problem that most people, including myself, have been having is we have all these new technologies. So many new technologies. This is a technology conference, so we're talking about technologies all the time. But of course, process is another very important part of the picture. And one of the interesting things about responsive design was that it was a process, a way of building websites that came with associated technologies. And that process, together with the technologies, made much more sense of media queries and scalable images. All of those things made more and more sense to brought them into the process of responsive design. So when I gave this talk previously, I talked about web components. Because again, I was thinking about technology. Web components are a new HTML spec that you can do some of this using JavaScript right now, some JavaScript polyfills right now. But this is future technology that we can't quite use on real websites yet. And that's just... I was too focused on that one thing in Austin to really get the bigger picture. And there's all these other things going on, right? There's Twig, Jenkins, CSS, CSS, Linting, Yeoman, Bauer, just crazy, crazy, crazy. And this is only like 5% of the stuff, right? There's so much more. There's like 20 times more of different technologies, right? This is bad. Let me skip to the next slide. Okay. But what I've started to notice is a lot of those technologies have to do with component libraries and continuous integration. Those of you who don't know what continues their integration or don't quite get it, it's basically it's automation plus regression testing. So you're trying to be able to, you know, bold your site using automation and also do regression testing so that basically when you add new things to it, you can ensure that you're not making your site explode in some other area that you're not focused on at that point. And continuous integration is basically... the reason why people talk about it is because agile development requires continuous integration. If you are supposedly doing agile development and you're not doing continuous integration, you're doing it wrong basically. I mean, it's impossible to actually do agile without continuous integration. As much as you try, you will fail until you start doing continuous integration. And then sort of some of the other key technologies that I've seen, they're talking about component libraries, right? And a great way to document a component library is with style guides, right? So... these are the two topics that I'm going to be talking about, mostly, the rest of the session. And I want to explain agile development so that we can all sort of understand it because I never figured out what was going on. And, of course, I need to actually show you, of course, what's wrong with waterfall development, right? So this is a typical waterfall plan here. You plan it first, and then you do the design phase, then you do some development, and then you do the thinning, right? This is the way that you plan it from start to deadline. But what often happens, and I say usually, yeah, usually happens, is basically you get to a certain spot, like, say you're here, say it's today, and you realize that you don't have enough time to actually finish the thinning. So the way that you solve your problem is that you basically, you stop, you don't do half the thinning, right? You throw that away. And oftentimes that means that you're also throwing away development time because you're not theming those features, you're throwing away all these designs, and you're throwing away all these planning. Now, if you look at the actual time where you've done useful work, it's about half of the actual start to deadline time is usable, and the rest of it you've thrown away. This is horrible. I mean, basically, you could have done the same thing in half the time, in half the budget, right? But because waterfall does all this upfront planning, it's just really bad. So Agile Development looks at that, and it's, what is the core concept? What is it trying to do to make things better? And the other one thing here is reducing your risk, right? In the waterfall, we had the risk of like, well, what if we don't finish everything that we planned? Right? You have a huge risk because you end up with a lot of wasted time if you don't get to the end of the plan. And so Agile Development, reducing your risk by controlling and minimizing the risk at every stage of the process. So let's look at a natural project. Again, you have start deadline. This is the same timeframe as before, but now you've broken up your project from start to finish in two weeks' sprints. And then you've taken your feature list, and you've broken it basically into a whole bunch of features, and you go through the client and say, what are your top priorities? Make sure that this list is in the priority order of what you feel is the most important stuff because we're going to start at the top and grab the first couple of features and implement it during the first sprint, okay? And then when the second sprint comes along, what do you think happens? If we just sort of start going and keep going, and then finally at the end, we're like, hey, here, client, what are you, we're done, right? No. Actually, when we get to the second sprint, we have to talk to the client again and say, okay, maybe something's changed. Actually, almost guaranteed that something has changed in their priorities because they've now seen the results of your first sprint. So you want them to look at the priority list again, reprioritize it again. Make sure they understand the stuff that they're de-prioritizing and understand the stuff they get that they're prioritizing. And just grab the next set of features, do it in the next sprint, and do that continuously over and over again, and when you get to the end there, the client is well aware of the stuff that you haven't finished because they specifically de-prioritized it, and by definition, the stuff that you've finished by the deadline is the most important stuff that the client wanted. Every two weeks, prioritize private goals, complete a set of features, and you're creating a releaseable product. And so what does that mean for the web? How do we actually do, like, people have a really hard time understanding, like, okay, when I get to that first sprint, what do I have after two weeks on a website, realistic, what does that mean? I did some scrum training recently, and the best advice that my trainer gave me is basically, it's going to take you over three years of doing this before you figure out sort of the mechanics of how to do it the best way. And the answer is I don't quite... I'm having some vague ideas of what that first feature is going to look like. That first set, I should say, what that first deliverable at the end of the sprint looks like. It's going to be really minimal, right? A single one-page website is deliverable. It's complete. All of its features have been designed. That's what sort of the minimal viable product looked like at the end of that first sprint, and it's going to be hard for us to figure that out. But the mechanics of Agile and the web basically mean that we can do this... Oh, actually, I should take... So, Kim Pepper, my boss, he asked me, how do we get designers and front-end developers integrated into our Agile workflow? He asked me that right when I started working there in May, and I said... I don't know. I have really no idea. But then he sent me to a scrum training last month, and it just blew my mind, and it was two days' intensive course, and I came out of there and I said, okay, I know exactly what we need to do. And it's not even that hard. That's why it was so hard to figure out, was because it's really, really simple. All we need is component-based design and automated style guides. And if I had known this when I submitted this session, I would have called this session style guide-driven development. The known web development. I honestly believe that... I know probably a lot of your bosses are like, well, we're going to try to do Agile. You will all be doing Agile ten years from now. Guarantee it. I feel like style guide-driven development, that's the way we're going to be implementing websites. It's not just a front-end developer thing. This is how web development is going to work. So style guide-driven development, the only requirements are component-based design, automated style guides. I'm going to give a live demo of the automated style guides, and then I'm also going to be talking about what I mean by component-based design. So we'll go through both of those topics, and let's get started with the component-based design. What are we doing now that we're doing wrong? So CSS specificity wars. This is something that we're definitely doing wrong. Yeah, I have to get the cat vid a gif in there. Oops, I missed one slide that wasn't converted from Austin's theme. Anyway, so you've probably seen some little sets just like this inside your Drupal theme menu item a link. And then you've styled your nav bar. And then you're like, oh, the sidebar has a different styling. Oh, it's got all the same classes. I'll add a new rule set that's sidebar menu, and this is your side navigation as you drill down. And then for whatever reason, the client says, oh, I need it on this one page. I need to have this style look different. So you just start getting these crazy and crazy more higher and higher specificity on all these rule sets. And when I first started using SAS, it was like, oh, I can fix this problem. I'll just rewrite it in SAS. Whoo! Of course, the problem here is that all I've done is I'm now auto-generating the same crappy CSS I had before. I love SAS, but it doesn't fix this problem. Another problem we have is overly generic class names. This is especially true in Drupal. You have title. There's also titles inside blocks, inside nodes, inside views. Basically, this means that you can't actually style anything with just the title because it bleeds across all these other different things that have completely different styles. And I'm pretty sure that this is in D7 because of me. Sorry about that. Content, same thing, black node views. This one wasn't me, thank God. This is bad, but learn from your mistakes and move on. It seemed like a good idea at the time. So given the mistakes that we're doing now, how do we fix that? And that's what design components. So when I say design components, basically what I'm talking about is the object in object-oriented CSS. The module in SMACS, which is scalable, modular, whatever it stands for. Black in bounds, black element modifier, UI pattern. These are all the same concepts. Bootstrap and foundation, those are also component libraries. This is the same idea, it's just a library of components. And even the upcoming web component spec, that's components built using HTML markup. I think that President Seh was giving a presentation where he was talking about some new CSS and HTML stuff he should probably talk about web components there as well. It's the next session after this, yeah. Go see that, he'll go over the more specifics of web components. So these are all the same concepts. And basically our goals of CSS components is we're applying to a loose set of HTML elements. They're repeatable, so if you apply a design component to a particular set of HTML elements and apply it to a different one, you'll get the exact same design. They're specific, meaning that the same name isn't going to bleed over to other designs. It's just going to be that one design using that one class. They're self-contained, the styles don't bleed over the thing. And nestable, so you can have one component sort of nested inside another one. I'll go over this list again because I want to give you a bit more concrete examples. Here's the PRI website. This is one of the first websites that I helped build using this idea of design components. And I took this sort of lead article here and made a single design component out of it. It had an image to the left, certain styling for the title, the taxonomy date, additional taxonomy in the top left there, and that also that red share count there. So that was one of the first ones that I implemented. I tried to make that repeatable, and then I went on to the next feature and found something else to identify as a single design that can be repeated. And sort of scroll down here, and then down here at the very bottom, you can see here's another list of news articles very similar, but the order of the stuff is different. The share count is on the left instead of the right. So what I ended up doing is I made the share count, I refactored, made the share count its own design component and then sort of nested it inside them. So as I looked at the designs, I would discover the reusability as I went. Now, there's a lot of different things going on here inside this design, right? Just inside that one component. How do you actually, like, identify all those parts? How do you write it? How do you organize that component? And the way that I start out is by looking at SMACs. SMACs is a way of categorizing CSS. We have base, layout, modules, date, theme. It's like Jonathan Snook's hates Drupal developers. He has to use the exact same terminology that Drupal does. So I usually, actually instead of that, I will use base, layout, components, date, and skin. So I've replaced module with components and theme with skin. This makes it much easier to talk to other Drupal developers. So the rest of the slides, I won't be using the official SMAC names, but these other ones here. So when I started looking at this and started figuring out how am I going to use this categorization to build design components, I realized that state and skin, they're not actually equal levels of components, layouts, and base. The state and skin are actually parts of the component. If you're building a component, state and skin are pieces of them. And in fact, there was something missing, too, which was BEM. The additional things that you need to understand a component is the base component, different elements, with modifiers, states, and skins. I can go back to the PRI example and start to point at things like, this is an element, and this is a skin, and this is a state. It would be very difficult to understand, so instead I'm going to use an analogy. And one of my favorite quotes about explaining technology through analogy is this one. You see, radio is a kind of very, very long cat. You pull his tail in New York, and his head is meowing in Los Angeles. Do you understand? You send signals, they receive them there. The only difference is there is no cat. I have a ride sign. Another claim to my analogy is as awesome as this one is simple, but we're going to talk about design components using the analogy of a flower. A very poorly drawn flower, because I've done it myself, but this is going to be the visual analogy for understanding the parts of a design component. So this is our base class, CSS class, just dot flower. This is going to go on one of the HTML elements. And then when we start looking at elements, we're basically talking about different pieces of that design component. In this case, flower petals, and we're using BEM syntax here for building our classes. The important thing is to understand that petals is an element of the flower component, and you do that by having very specific naming. So instead of having high CSS specificity, we're converting that CSS specificity into very specific naming conventions. So it's low CSS specificity, but a very specific name so that it doesn't bleed across to other things. In addition to the petals one, we also have the face, we have the stem, and we have the leaves. And just so you understand that when I said this is a loose collection of HTML elements, I really meant that because you can also have a flower bed, right? And obviously the flower bed is a wrapper around the flower itself, so it's going to be a wrapping HTML element. So it's totally fine to have an element of your component be outside the DOM of the base component. That's totally fine. Let's go on to modifier here. So we can have a modifier called tulip, and this converts our normal flower into a tulip-looking one just by using a slightly different CSS class. So flower dash dash tulip. The double dash here designates that you're using a modifier to make a variant of our normal design component. And now, just given this naming convention, I see a lot of people take that and sort of start running with it, and you really don't want to make this complicated. I was actually shown this example today. Channel dash tab underscore underscore guide underscore underscore upcoming dash video underscore underscore info underscore underscore time. So there's actually only two problems with this. You shouldn't be inferring HTML structure with your class names. It's really no need, right? Because it also makes it impossible to refactor and simplify. You totally need to simplify your HTML if I'm guessing correctly here. You simplify the HTML. You don't have to rename your class names just because you've simplified the HTML. So this is just completely unnecessary. Component, and you have an element. Just make your element sort of descriptor longer rather than start nesting it crazy like this. And the second problem with this is semantics. Semantic namings. Content semantics, they're handled by HTML5. So whether you have an article, your menu, that's already handled by HTML5 elements. There's no need to try and describe your content using CSS classes. Drupal uses basically build semantics for all of its CSS class names. It's like, oh, the views module makes this, so I'll name all my classes views. So it uses build semantics. That's not the best, but that's what we have right now. But there's really no need. Let's make our class names based on design semantics. You're trying to describe the design in a way that you understand it's meaningful to developers and designers so that they understand what that class name means and what design is trying to describe so that it can be repeatable. But don't make it too specific like green box, and then later you need to rename. You need to refactor it and make it purple. But just try and come up with a relatively good name that's based on design semantics. And also do not just kill yourself trying to come up with a naming. Don't worry about it. It's really not that important. Name it something that seems to make sense to spend a little more than 30 seconds thinking about this name. Really, just do it. There's no need to get crazy. If you come back the next day and you're like, oh, God, why did I name it that? Just refactor it. Or admit your shame to the rest of the team and move on. It's all right. So getting back to our design component, if you're going to state, this is a hover state, right? So in this case, your mouse is hovering over it. The state is actually, there's a couple of different ways that you can have state. This is a mouse state. You can also have a JavaScript state. So like some JavaScript sort of applies this extra is-pollinating class to your component. And of course, in media queries, there are also a state of your design component. So this is the desktop version of our flower. You can see it's just wrapped in a media query, right? And then of course, print styles. Print styles are also you know, they're just media queries, right? So here's our print style. And then if you move on to skin, skin is kind of a weird one. And for a long time, I didn't have a good example of what this actually was because it basically skins got started with like Yahoo in the 90s. I don't know if you remember this. You would go to the Yahoo website and then it would be like all yellow and stuff. And then you would go to like Yahoo Finance and it would be the exact same layout in all the same boxes, but now they're being green. It was a, what skin is basically it's a global it's a global modifier, right? So it's, you're modifying this design component, but you're sort of applying one class at like maybe the body tag and it just affects all of your design components across the board on your entire site, right? So skin is basically a special case modifier that's applied globally. And in our example we're going to have an is night flower here. This is what it looks like when it's night. Yeah, global modifier. And that's basically it. I mean, that's, those are the it's relatively simple rules. You can learn this stuff and memorize it and just use those rules as you're building your design components identifying the repeatable bits. Use these rules to do your naming conventions. Here's an, you know, all the selectors here again, so the dash component we use a single dash if we need to have multiple words to describe our components because sometimes you just can't come up with a single word. Double dash specifies that it is a, you know, a modifier you're very making a variation of the design. So you're like tweaking it just a little bit so that when you apply that class you're getting the slightly altered one. All of your elements are with double underscores. Sometimes a variant will have a slightly different styling on that same element. And then all of your different states javascript state, hover states, midi queries and then lastly the global modifier as a skin. Now I'm fine if you hate double underscores and double dashes and dashes and stuff like that and use some other way to identify which bits of the component and which bits of the modifier. That's totally cool. But these same ideas apply even if you use completely different syntaxy bits in between them. So let's go over this list again one more time. So CSS design components. They're applied to a loose collection of HTML elements. Again, we're not trying to infer any specific HTML DOM structure. They're completely repeatable. They're very specific self-contained and nestable. And this naming structure has been adopted by Drupal 8. Drupal 8's official class naming convention is dang it, not that real is described here. Drupal.org.node 1886770 and it follows these exact same naming conventions. So when I start actually building a website using design components my file organization is basically the first three levels of smacks. So we'll have a base folder, a low out folder, components folder and then everything just sort of goes into one of those three folders here. And the SAS setup, because I love SAS is basically this. So my styles.scss file is going to import the init partial and the initialization partial is basically loading any third party libraries that I need. It's in charge of loading the variables as well and that's where I store all of my SAS variables. And that way if I have multiple.scss files that I need to generate like a wissywig.scss file it could also import the init and get the exact same access to the same variables and the same SAS libraries. And then yeah. So here's my styles.scss So we import the init import the base, import all the layouts and then all the components. And this it's set up with a really simple folder structure but it also means that because every single one of my design components are in a separate file you end up with a ridiculously long list of files inside your components folder. But it turns out that this is really easy. It freaks people out when they see it for the first time like 50 files how am I going to find anything but it turns out it's really easy to find your design components. If you're a new person on the project all they have to do is inspect the actual thing that they're trying to alter, inspect the DOM look there's a class right there on that component and look there's a file name with the exact same name of the CSS class right so it turns out to be really easy to organize this really easy to find things for new people so I highly recommend not trying to build some folders inside your components because it actually makes it harder to find things. Now, I know a bunch of you were like wait a second so you mean I need to alter my HTML to add in all of these new CSS class names. You do realize that we're all using Drupal right? Sometimes it's going to be completely crazy you cannot like alter some you're trying to get down into some template you don't even know what it's named and you just cannot figure out how to alter that bit of markup and you know I've been doing Drupal for 10 years and I can't find all this stuff but the good news is that with SAS we're everywhere around that with the fugly selector hack the fugly selector hack I didn't actually name it after Morton but I like to show Morton's face when I talk about it. What I do is I will in my SAS I will write a selector that's based on the DOM that I was not able to change because Drupal sucks Drupal sucks I couldn't change this DOM and then inside there I will extend into the class name I wish I could have used in the DOM so you know inside the SAS file I will define the component as I wish I could have using this silent selector here feature underscore title-link I wanted to put that as the class name but I couldn't get into the DOM A-link because Drupal so I'll write it this way and it turns out this it does make your actual CSS selector have more specificity but it turns out it's never actually a problem I've never encountered a problem from doing it this way because you're still thinking about your design components in this repeatable way and also completely independent way each of your design components are independent so you end up without any bleeding anyway so the selector in the DOM it doesn't turn out to be that big of a problem usually I obviously don't use dot views space A that would be bad but uses a little bit more specific than that but this is a great way to actually get Drupal to spit out all of our components in CSS that's basically it as far as design components go so let's start looking at automated style guides I looked at a bunch of different automated style guides and the first one that I actually got to work was KSS node so this is one that I prefer it had a couple of bugs but because I really liked it I actually became a maintainer of this as of July so now if there are bugs in this you can yell at me and everybody knows me, hi say hi John now you officially know me you can yell at me about this and this is where the slide I didn't finish so let's jump over to the last slide which is time to grapple right it's in front of me here if I can just figure out how to hide the stencils there we go so this is our basic workflow of any automated style guide system so down here we have our application, in this case Drupal we have our SAS files HTML templates twig, whatever mustache, doesn't matter and what we would like to do is we have SAS we're parsing the SCSS files and generating CSS files and we would also like our application to take our real templates and dump each design component into a separate file just like a code snippet of HTML that our design component is going to apply to and then we're going to have KSS in this case our automated style guide generator suck in the source code of our SAS in this case and these HTML snippets so it's using the real the real code and the real markup and it's important that the style guide generator use the real code when it's building the style guide because that's the only way you can ensure that this style guide will stay up to date I've been using style guides for like 10 years and for 9 years and for 10 months they've completely sucked because what happens in reality of course is that it's a waterfall thing so while the designer does all the work he does a beautiful style guide but of course there was last minute changes in like last two weeks of his part of the process and then he had to change a whole bunch of stuff and he forgot to or he didn't have a chance he didn't have time to update the style guide so I get a brand new style guide it is already out of date and then I start implementing stuff and it fails immediately so style guides become more and more useful if you're actually automatically generating it from the real code because the style guide is guaranteed to be up to date so in this case here so KSS is looking at our source code the SAS and these HTML snippets and builds an entire static set of HTML files that is our style guide so it's got the real markup inside it it has the documentation that it parsed out of the SAS file and then it's going to hot link in the real CSS that Drupal is using in this case so our theme is spitting out a CSS file and it's going to use that CSS file in a theme you should also add a link tag into your style guide that points at that very same CSS now KSS right now it doesn't do this little bit where it sucks in HTML snippets and the quick hack that we did that the previous maintainer did which is brilliant hack for temporary work around is that basically you take a little HTML snippet and you stick it into the SAS file so inside your sort of code comments about your SAS you have a little HTML snippet it works as a hack basically there's going to be some sort of Drupal module that you can configure and say these are my design components that I've configured in Drupal and they're using one of our theme hooks and it's going to spit out each of those files and then KSS will be able to read all of those individual files pull in parse the SAS files the SAS files will say hey this design component is that HTML snippet so it'll point at it inside the docs it'll just do it that way that'll be that's what it's going to do it's not quite there but it's close enough that you can use it now we're iterating this is agile development this is good enough to release so we released it so let's do a demo first I should show you what the actual if you go to the KSS node website you'll have instructions for how to set it up it's a regular node.js so there's like a package.json file for there that's what that looks like but the instructions are on the website and if they suck, yell at me and let's look at oh wait I'm on the wrong screen there we go let's look at no not that one this is a ridiculously long HTML snippet which is why I want it to be in a separate file but basically so here oh I should make this bigger shouldn't I can you see in the back no that's too big 18 so here is down here is our regular SAS rule set we've just documented this footer menu in this case here's our base class footer and then of course we have a wrapper so it's footer menu wrapper and then this is the documentation basically we define what the name is we can also have a brief description the menu that is in the footer this is a horrible documentation you'll never write anything like that that's why it's not in there right now but you can write in several paragraphs whatever you want about this design component right here and then we have the markup snippet which is in this case really long but this is then going to be spit out on the style guide and the last thing here is we were in the style guide we want this to be stuck into and all we need to do to generate the style guide is come on mouse there we go in this case I have a gulp task which runs the kss node command line utility so I'll type gulp style guide because that's way easier than the kss node really long thing with all the different flags on it and it's gone through and read all of these it's parsed all of these sass files and generated all of these html files and it took it 499 milliseconds right let's look in the gulp file real fast just so you can see just so you can see the actual kss node command which is right here so this is some javascript in order to run the kss node thing but it's basically just kss node you point at the directory where your sass is you point at the destination where you want the style guide to be spit out to and then this dash dash template here this is basically saying I would like to use a custom theme for my style guide because to be honest the default theme that comes with kss node sucks I don't even use it that's another open issue but you just point out your custom theme and it uses that theme to generate all your styles and let's go and look at one of them this is the very first one that I ever did for MSNBC it's an internal style guide so you can't get to it from any website and you can see here that just parsing sass files it's generated all of these html files including a list of all of our sass variables what our font faces look like what those font variables look like font sizes this was a team effort so some of this is awful but not necessarily my fault or even their faults anyway one of the nice things about a style guide like this is it's because we implemented this style guide right at the very very end of the project and then exposed a lot of things that we had done wrong and hadn't realized until it was sort of right in our face here we had a variable that was like you know green links except that it was red so style guide is really really nice because it allows you to visualize the actual component as you build it because as you write the css you also write the style guide snippet and if we're using gulp or grunt you're going to have a watch command so you're in gulp watch and it generates the kss and then any time you modify any of your sass files it's going to automatically regenerate the css using sass and it's going to automatically regenerate this style guide so you just run that command using grunt or gulp or whatever test runner you want it starts auto-generating all this stuff what are some other good ones in here so all of these this entire website you know has all of these different design components that are completely documented here and the way this works in an agile development is you know when you start your style guide is going to be completely blank you won't have anything so you have the first feature and you're like okay so I'm going to get a designer front end developer, back end developer we're all on the team here we're going to figure out what that feature looks like how it should work, the UX of all that stuff implement that and then you know the front end developer is going to code that into css and it's going to automatically generate into our style guide so now our style guide has one thing on it and then we go to the next feature from the next feature we look at it like can we reuse anything from the style guide so we look at the style guide try to find out if there's anything that we can reuse if there is great you just reapply that all design to the new feature and you just keep going iterating that way over it and this also works on projects that have started out in a waterfall way you can apply this at any time and just work from the new day one and do it this way and you'll still get a huge benefit out of this I would like to leave a bunch of time for questions so we should go back to the slides and here we go so on Friday we're going to have a Drupal 8 sprint as I told you these naming conventions are part of Drupal 8 and we're trying to get these design component ideas into our css we have it in a couple places we need to apply it a lot more places and the 7 style guide is amazing if you haven't seen it Lewis and a bunch of people worked on it it is not auto-generated right now right not yet and they went to work on it on Friday so you can actually get involved in Drupal 8 core helping to make the 7 style guide auto-generated from the source files so thank you and please I'm sure you have lots of questions go ahead and line up but if you're over in the corner I'll take your question you can just say your question right there so the style guide module was written by Ken Rickard when I worked at Palantir he was a co-worker of mine it doesn't do the stuff that I need right now yet I would like to talk to him or possibly implement a feature request about having a way to configure what my design components are because right now it just sort of spits out some sort of standard components inside this style guide and it would be really nice if I could configure like this is the thing that I need so please build the HTML markup for that and then spit it out into a separate file right and I see it as and certainly it could also be the place where it builds like this entire list of all these different components right so yes I have considered it it doesn't do what I want right now so I grab something that works right now and I'm working on it but I have a feeling it might be part of the future of my process sure yeah we can chat afterwards I would love to chat to you about the style guide module I haven't used style guides before and it seems like a good idea which role does this play in the daily development work which role does the style guides play in the daily work the role there are two things so from a front-end developer standpoint I find it much easier to write the actual class names come up with the actual class names if I can see immediately what that component looks like inside the style guide as I build it so like I have my local copy of the style guide and it's auto-generating and building up the component as I actually write lines inside my CSS it becomes way easier to write my component if I see it being built immediately that's really really helpful and of course the other part of the daily role is basically when we come to no features we should immediately when we first look at the feature and sort of understand that feature then we look at the style guide and decide are there things that we could reuse sometimes there's like oh this thing is like 90% of the way there I've heard that if we tweak it a little bit that can be a new variation of it we can add a modifier to it and make it slightly better for this new feature so that's how it's used in daily use so this also allows to write the CSS or the SES before you actually build a website that's true this is another great thing that we found out because we have front-end developers and back-end developers working on this single feature that builds the requirement that the back-end developer does his stuff first and then the front-end developer does her stuff next so you've coupled that so that the front-end developer can build the style guide first at the same time as the back-end developer is working and then you integrate it at the end that's really handy too often you get from the client you get some kind of material where you don't know is this just for this page and probably the style guide will help with that you send the style guide back to the client and ask, look at this, should this be reused or should it not be reused? that's another thing that especially the style guide is a great focusing tool for the designer as well is because by looking at the style guide as it exists right now they can go, I don't need to completely re-solve this problem I can reuse one of my solutions that are already in the style guide and sometimes if you have you have a client who's providing you the design sort of in waterfall fashion you can do the same thing hey, there's this thing that we already implemented that's like 95% the same way do you really want to pay me X dollars or euros to build this whole new thing because it's slightly different in the design can I just save you some money and reuse this style? another question what role does Drupal Modules and Drupal Themes play? what part of the components go in the theme and what part go in the module? I like to do stuff in the module but then if you decide I want a different alternative theme where everything looks different then maybe it's better to put it in the theme I'm a fun and developer so I'm a themeer so I put stuff in the themes I feel that most of the design components they're design solutions so they but they have markup with them really too so it's a combination of the markup and the CSS together and they seem to fit more naturally in themes to me then you make these things, it's a views plugin or it's a formator and that's module code so the module will depend on the availability of some CSS components then then the CSS components might be in the theme so then the module depends on the theme but tricky I'm not too worried about that I've read some views plugins or some panels plugins a lot of times and those will be inside modules so the templates over there and the CSSes over here that's a real problem as far as Drupal's architecture because it has this artificial separation between modules and themes what we really need for the next Drupal core is basically an idea of a component library where it bundles every component has markup and CSS with it that's what I would like to see and then it gets rid of this artificial where do I put it, the module or theme that question goes away question here the question is if you have a layout system that you're just using does that go one of the things about smacks that you could definitely argue about is do you really need to put layouts in a separate categorization from components because you could think about layouts as being a very very specific component that just does major shifts of your pieces on the page and no other styling that could be a type of component so if you want to think about it in that way go for it, I'm cool with that Pixelwip, did you give your session on the layouts already? so there's going to be an excellent session the video for it is going to show up where he talks about CSS layouts and stuff, so look for that too another question go for it so the question is often your components will be using variables and of course the variables are going to be like your variables partial and stuff so then there's a dependency between the components and those variable names that's sort of a common problem in SAS as well and I would love to see some better solutions and then basically the components can define, I mean the best way right now that I know of is basically have the component define the default version of the variables, so it specifies the variable name colon and then the actual value and then space exclamation point default semicolon that says if you haven't already defined it use this value for this variable that would be the way that you could package up those components and then reason that way but that still requires you, maybe there's some like build thing so some part of your build system goes oh I'm downloading, I'm grabbing this other component that I'm reusing and it's going to like yank the variables out of there strip the word default and then stick it inside your variables folder maybe WA would automate and remove the sort of hard dependency on variable names inside components the other questions is it's actually it's been in one hour so thank you so much for spending your time with me can you go back no, no, I know what to do I have to upload these slides I will also have them what time do you start? start at 5 oh absolutely it's it's it's only a month I mean it's looking for a certain syntax so it can't set it's left and it's not similar to our common so it doesn't actually spare the fact that it's partial it's not and I I I I I I I I I I I I I I