 Hi everybody. Thanks for joining us. So we're kicking off the new design workflow and we're all with Phase 2 and there's been some significant improvements to the way that we've been doing our workflow when it comes to designing of sites and the design implementation and the front-end development of them as well. So that's some of the stuff that we'd like to share with you. Go ahead and pick and choose from what we share and hopefully you guys can implement it and can help out and make kind of what you are able to do a little more enjoyable and quicker hopefully. So my name's Evan and I'm going to be going over the kind of the process overview and the tooling selection that we use and then both of these gentlemen are going to dive into more of the specifics. So we've got Joey who's going to be talking a lot about the design process and we've got Micah who's going to be talking a lot about the front-end development process. So I'm going to give a little overview and then they'll dive into some details and we hope it helps you out. So one of the biggest things that has helped us out has been implementation of a prototyping tool, Pattern Lab. So we love Pattern Lab, it's been helping out tons. Who here has heard of Pattern Lab? Who here uses Pattern Lab? Anybody using Pattern Lab on a project right now? Oh, so this is perfect. So we had a lot of hands go up for heard but not as many go up for amusing. So you're at the right spot. So Pattern Lab looks a little bit like this and there's a lot that it can do and so it's definitely a style guide and it is definitely... So it also is a prototyping tool and style guide together basically and by prototyping I mean high fidelity HTML pages to be specific. So we're not talking about grey boxes or wire frames. This thing looks like the end product. So if you... Right here we're kind of on the style guide portion but you can go to full pages. So we've even been able to have this as a design deliverable that satisfies the client on the end whether we're talking about design or front-end development. So that's been a big win for us and it's a big component inventory. Major props to Brad Frost and Dave Olson. Oops, I killed some slides. Awesome. One second. My apologies. Trying to get the speaker notes all full screen. Anyway, so major props to Brad Frost and Dave Olson to be able to put this together. So it's an open source project that's out there and that's all of them. Yeah, it's great. So it's just the tool that we like and I would say that most static site generators would do the trick. So whatever works for you, go with it. If you don't have one you're using, this is a great one. So it's built on this idea of modular components and kind of these things that stand alone that can be put together to build bigger systems. The vocabulary that is used here is based off of atomic design which is you don't need to follow atomic design to use Pattern Lab and you don't need to have Pattern Lab to use atomic design. The two do go very much hand in hand though. So this vocabulary that's kind of biologically based and it is using atoms, molecules and organisms and kind of the idea is that each go into the next. So we've got atoms which are like our simple labels and just our individual text fields, all the kind of form elements really. Buttons, just a button by itself. And then those atoms get combined together to make molecules. So a great example there would be a search field. So we can style against these things and just style just a search field as opposed to search fields in the header. So later you're able to basically put the molecule in the organism of the header. So basically logo plus menu plus search bar is your header really and each of those are styled individually. So the individual components, atoms, molecules, organisms they really don't have a set container with. They're really put into other things that set its width for it. And this really helps out with modular design and responsive and mobile and it's a big benefit. So kind of the way that things had been done before really is this linear process, very much waterfall development. I think that this is something that you're all pretty familiar with and I think everybody here is trying to get away from this. And the reason I bring it up is really that the issue here is that each step is a blocker and we don't like blockers, right? So we want to be able to make sure that we're not holding up other steps of the process that could be done. You know I have prototyping in here, not everybody gets around to that. Some do and that's awesome but it's great that it's even there. But the problem with prototyping here is what usually ends up happening is it doesn't really get kept around at all. So a lot of work gets thrown into figuring out a lot of this responsive behavior and how things look and the medium things are destined for and then it's tossed away because it's off to the CMS to actually build the thing that the client paid us to do. So if you're going to throw it away, why keep it around? It has a ton of benefits though and so the way that we figured out to keep this benefit around is by just putting it in the Drupal. So we basically just set up our theme like this. So we've just got a folder right next to CSS and JS, pattern lab. And it's just a static site generator and we get ignore its output and we basically just link the CSS and the JS to both Drupal and pattern labs. So really just in pattern labs header it's just like the link tag is like dot dot slash dot dot slash up and over and grabs the style sheet. So the thing that why this is super helpful is that you can go to your style guide and you can see a list of every form field, a select field, all that weird HTML5 text fields like the buttons, the secondary buttons and you just see all those and you just style those. And then you just go over to the Drupal side and all your forms look good. So you don't have to really like hunt through Drupal and find a page that has the form type that you're looking for. So this is really nice and you can bounce between the two since it's shared. One thing to highlight really is the generation of the HTML is left to the two entities themselves but CSS and JS is shared. And then also the pattern lab gets deployed to each environment as well and this is super helpful because then we kind of have a style guide that represents what it looks like on staging and production and local. So that's incredibly helpful. So this kind of leads us to just a parallel iterative process basically. We can kind of get out of the way of each other and stop blocking each other. So we've had projects before where instead of having to wait for the entire backend environment to get set up so we have some HTML to even style we were able to start months ahead and get going. And likewise on another track basically backend is being able to work on a lot of functionality. Also we just kind of want to be able to have design in on this process and you see design up there and that's okay for it to be static comps and assets. Like nothing wrong with Photoshop. There's nothing wrong with a comp. The problem is getting 30 comps like thrown on you. So the idea is that as new comps are coming out you can just iterate and pull them right into the medium that they're ultimately destined for. And this turns around and helps design out as well because design has an asset library basically. They don't have to go hunt into previous PSDs that they made or whatever they're using to be able to find what the header was. This is how we get those small deviations in margin and padding that are just a time suck for all of us and not what we really want to be doing. So this can help out the designers by providing an asset library and additionally backend developers get a huge benefit to this as well because they're able to... It's a great reference. It's a living reference. So say they need to implement a tab panel. They're able to go to the tab panel component page in Pattern Lab and they just have to really be matching the markup in the classes and it just clicks afterwards because the CSS and JS is shared. So it helps out a lot of people. Project managers and stakeholders are also on this list. They kind of have an overview of basically all the front-end components that where they're at, how far they're along, what everything's looking like without having to worry about say the navigation isn't done in the Drupal site and you can't get to a certain page. If you'll remember that first slide had a nice drop-down menu of all the components so it's really easy to be able to get around. Definitely we've seen people from a lot of different roles really appreciate this process and this approach. It's not just front-end developers being like, yeah, we're going to work in a static site generator. Although that is really fun. And lastly as well, there's an objective share vocabulary. So who has ever been in a meeting where everybody's kind of caught, is it the primary button? Is it the main button? What really is a media block? So the thing that's nice here is that all of those components have a text label. And once you start to have some vocabulary and almost a glossary that you can lean on, it helps out to be able to know that people aren't making assumptions of something that is just in people's heads. So we'd like to also share how we do things. So phase two is put out our pattern lab starter out on GitHub and run these two lines and you'll have a whole set up going just right away. Check out the link as well to kind of take a look at our code approach. So our pattern lab starter is a lot more than just pattern lab itself. So we definitely have like grunt, watching and compiling pattern lab and SCSS as well. But you have the options to be able to use Libsass, which is 10 times faster or Ruby Compass if you'd like to. And then we have auto error linting of just the last file saved for JavaScript, SCSS and JSON. The entire icon system is in there as well. So you can just plop an SVG into a folder and it turns it into font icons and then it adds the mix-in based on the file name to your SCSS. It creates an HTML class to be used again based on the file name. And then it adds it to the pattern lab page to all the icons. So by dropping an SVG in there, you've updated your style guide. Super helpful. We've kind of taken that approach with a few other things as well because style guides are only as good as they are up to date and current. So the idea is like, so a great example is like the color palette that's up there. So what we do here is we just take a look at the SCSS variables you've declared because that's probably the most likely chance you're going to change the color palette and then just create a style guide page from your colors. We do the same thing, font families, typography sizes, break points. It's actually pretty easy to be able to add some more for your specific project. And then lastly, we've got Bower in there as well. So if there's any kind of external libraries you need, just Bower install the thing and then it gets the link tags or script tags get added to pattern lab automatically. And of course it's available to your own generator. So there you go. I hope that it can help some of you guys out. If anybody has a few questions feel free to open up an issue on the GitHub page or talk to us right afterwards or ping us on Twitter. We'll have our names at the end there. We've really seen a big, big benefit come from having our prototype live inside our Drupal theme so it doesn't get discarded. People can kind of pick the best job or the best tool for the job, or work in a Drupal or pattern lab because a lot of the assets are shared there. So if you're using some pattern lab just plop it in there and link towards the same CSS, big benefits. And if you already have a Drupal theme and you actually just run this human generator in the Drupal theme, you'll pretty much be good to go. Maybe a few padding issues. You got get anyway so you can undo it, right? So we hope this helps you out. So now that's kind of the big overview of this, I hope that was helpful. And next up we got Joey, our incredible designer, talking about that process. Thank you. Alright, so now we start the design phase. We sort of take a step over and go backwards a little bit in time here. We're starting off with a blank slate, but I do want to say that in the old days of doing things, I would rush into into making comps. And so we'd go out, we'd probably do like three comps. But the problem here is it ended being like this, like a frankincomp and some abomination of a design would emerge from this where the client was like, I really, I like the header here. I like the sidebar. Let's take this and put it all together. So fortunately we're not doing that anymore because we're building systems. We're not building pages anymore. We're not designing the layouts with the components in them. We have sites that are being built by content editors that have hundreds of pages and sub-sites. And this has to be a robust system that has a consistent design language that kind of ties it all together. So instead of doing these comps, we're going to replace it with more of an immersive design discovery. So starting off, we really want to look to pull everything we can to help us with design. Brand guidelines, stakeholder interviews, user interviews, notes documentation, like wireframes scrolled on a napkin. Really anything that's going to be able to give us something valuable to be able to move forward as I view and just really be as informed as we can. Our goal is to make our clients successful and so it's really important that we do our due diligence during this stage. With everything that we're doing, we're starting off on the shoulders of giants. We're standing on the shoulders of giants. So many problems have been solved. So instead of trying to solve these design goals in the first round of comps, which always ends up leading to these discussions anyways, why not take a sampling of these problems already solved and explore options to apply them to the given goals for the project. So one way to do that is with a visual inventory, which is something invented by Dan Maul. It's a quick way to get some feedback on design ideas without actually creating anything from scratch. The format that you see here, there's a few different screenshots, is to take screenshots of different applications, sites. It could be even like a poster or anything that conveys what you're looking to relate the goals back and forth. So in turn, we're going to ask maybe a meaningful question that we can derive from that and approach how that can be related back to them in terms of their goals. We can look to address things like concept, tone, color usage, typography, how the narrative reaches. There's so much that can be done here. So many problems have been solved. So in this stage of research, we're really spurting these great conversations to gather that powerful feedback and break it down and let that move us on to the next stage. So with all of that, we're really essentially playing this design-discovery battleship where we're knocking out these sections so we can really narrow the visual range in which we want to explore. And this is really a fundamental aspect of design is to work within constraint because we can't really design all of the things. We have to focus and we have to perfect. So this is an underlying narrative that you're going to hear throughout our entire talk is that designing within constraint. So people always say that design is pretty subjective. But the goal of everything that we're doing here is to take those things that are kind of murky and subjective and really surface these objective goals and set constraints. So we have something to sink our teeth into. But as we keep going on with design, we really want to start strong with multidisciplinary teams working together in parallel. We want to tear down the silos of a typical design process. And we want to be iterative. We want to be collaborative. We want to work in parallel. Iterative, collaborative, working in parallel. You can hear that a lot. This is really important. These are the foundations of what we're doing for a design process. Good ideas don't care who they happen to. Right? So I've put some sites off design work that you've had zero input on. But you know that your views could have helped improve the final product. Could you raise your hand? All right. Awesome. How about designers? Any designers that had a vision but that vision falls short of the implementation because you weren't around during the build or you weren't there for that final design QA. I mean, I'm kind of the both years. So both of these situations are super frustrating. And I've been in both of them. I've had a lot of development in the background. So I have absolute empathy for both sides. As a front-end developer, I've cut design work that's been thrown over the silo wall and have to address responsive problems and responsive behavior during the build process. So it's like how the hell is responsive design considered like not considered part of a typical design process? Like why are... It baffles me that agencies are still like outputting comps and comps of pages. This is...what is going on here? We need to move forward with this. Designers should not be completely limited to just designers. We need to bring in these different perspectives because the success really of that final product really hinges on all these different varied perspectives. So I think we all agree with that but we also need to have some kind of an avenue to move forward with that. And that is design thinking. I mean, it's essentially bringing together this desired human perspective with what is both economically viable and technologically feasible. Who aren't trained as designers use creative approaches to solve design problems or improve inexperience. We're also striving to fit within the budget. I know the PMs love that and consider the technical approach. Gotta give some love to the devs there. To drill down a bit more we can accomplish this through a collaborative design process. There's so much to talk about. We can't even possibly begin to cover all this in the 10 minutes that I have here. So really look into some of this afterwards. But this is not designed by committee. These are sessions that are that are mutually facilitated with these clear exercises in mind that are structured to reach a specific outcome. It's managed discord in a controlled environment because a lot of times you're on a project and this has happened so many times where you're working on it, you go on three or four months and so many comes in, some stakeholder that you've never even heard of and they're like, stop this process. Stop it and go back in every factor. So if we can take that and structure it in a way where we bring in these different perspectives early on and we control it, it's a very controlled process for an outcome that we're looking for and I think we're closer to something that's more workable. It's not perfect, there's going to be disagreements we want that as Dries was saying in the keynote but it's better than the alternative which is kind of finding out four months down the road they have to completely redo everything. It's something simple, just like wire framing out the hierarchy of homepage components and there's a lot with co-design but really working in an environment where we're doing divergent to convergent thinking we're going to hold off on really giving our feedback until everybody's had a chance to speak and we take this, we distill it down probably UX designer can take that and compile it to the final form of what we're going for. In parallel with this we're working on some of the visual design starting to kick off and really start at ground level as far down as you possibly can go we want to start and get that foundation for our visual language. So we need to have a common thread throughout the entire brand experience. Typography is that vehicle because it's going to help keep us on brand. This is an example of a website called Typecast, it's tools for exploring some of the typeface pairings there's a bunch of cool templates and lets you go in there you don't have to buy them from here and you can see what they look like and things like Typekit and fonts.com are in here and once you find something that works you can take that and maybe screenshot it and drop it into a comp or show the client do a bit more research here but we do want to set the foundations because typography has been around for a long time and it's the basis for content and getting that out there. So at this point we've also got from the great conversation that we had during our design discovery and one of the core pieces of our process is iteration, we're starting off with baby steps working in the visual range that was defined. So here's where our art direction happens where we establish not only what the design is going to look like but how it's going to feel. On the left is an example of a style tile anybody heard of style tiles invented by Samantha Warren she's a phase two alum I can't even like she says style tiles are a design deliverable consistent of fonts, colors and interface elements that communicate the essence of a visual brand for the web. It's beautiful. It's a great way to kind of kick out that trajectory of iteration it's a small artifact it's lightweight you can bust it one out if you had to do one I think I heard a story about somebody who did one every day for like 30 days or maybe even more than that to try to find where they needed the right is another example of a lightweight kind of like a comp of a header and more of like a hero area so this is the maybe like the next step after you have what your style tile is for your direction and as we move forward with this we're really looking to build up our visual language. This is an element collage and these are all tools like it's a toolbox you can just kind of use them as you wish. An element collage and it's like a style tile on steroids it's very much like a mood board it's also created by Dan Maul who came up with the visual inventory so what I love about these is you look at it and it looks like a poster it's kind of like widescreen it's completely outside the context of what a website would feel like so when you look at this you're not like this is a website it's sideways you know it's scroll sideways and it really hints at this cohesiveness of what the art direction what the visual language are and there's some UI elements on there the typography, the color usage maybe a hinting of what a header and a button could look like that is butter colored and it sort of shows but it's the next step in the process it's iterative it's a throwaway artifact we're gonna throw it away I like it I had a fun time making it but it's there to kind of move the process forward and anytime during the process you can stop and say let's change out the photos the art direction doesn't feel right maybe like black and white more contrasty, more drama, more emotion and you can stop that here and you can kind of work with that also don't be afraid to change up your process if it isn't working you're in an iterative process you can really just turn very quickly there's not much risk in that and that's really the beauty of that of this process so at that point you could choose to go into the browser I have at certain points or you could continue to keep going this is just a screenshot that I have of some elements that I worked on in Sketch and at this point we're really working with the outcome of the UX work which has been focusing on component-driven design and we're taking some of that work marrying some of the visual language with that and sort of massaging it and looking at things so as I'm designing this I can add pieces to it I can look at one thing and sort of this atomic design methodology is starting to kind of emerge from this work and say alright I got a button here I'm gonna grab that let's put that over there and maybe go back and revisit it and kind of work with that and this is really where we see a hint of what a design system what it's looking like it's starting to come to life and this is really just another step we're moving forward and moving forward at any point we can stop there's no big reveal it's just kind of iterative so process recap parallel work we want to be starting in parallel with multidisciplinary teams like user testing like so much there art direction visual language we could be setting up like back end architectures like so much stuff we want to start strong we want to start in parallel we want to iterate we want to continue to refine that we get feedback design feedback we loop through this over and over again we also want to collaborate because we really have like good ideas we have perspectives it's valuable we're there for a reason for what we're doing on our projects we have all of those in the design process should not be locked out we want to get those perspectives it's very important designer takeaways you have to learn enough CSS in HTML to prototype your design work this is totally key you don't have the right production quality you can we try to strive for that but that's not really what you're going for the really important thing is you want to control the design process as much as you can which includes responsive behavior you want to make all these comps like desktop and and medium screen and and tablet and mobile because there's so much that happens inside it's so organic without like actually designing all of that together you just like completely missing the mark and you're like dropping like essentially your job in somebody else's lap and the front developer ends up doing your design work during the build of the process and it's just so insanely frustrating to me and I vowed that I would never do and it's still okay to use Photoshop still okay to use InDesign or whatever else you know Microsoft Paint these are artifacts that are meant to inform their prototype they're meant to inform the design system be available throughout the entire project and I know that as a designer it's not always up to us it's up to maybe the engagement designer up to project managers but this is something that is really important we can start off strong on the project we need to be there especially at the end to ensure this excellence through design QA like getting in there and this is where getting your hands dirty with some HTML and CSS is good because you know launches are tight and things are moving very quickly so as a designer if we can get in there pull down to get repo just do some quick like CSS adjustments and move things to where they need to be so we can sleep at night then you know that's like back to the iterative design process we've been building visual language and kind of establishing it and building it up and starting to see what a design system looks like so the next step at this point is to get to the browser and with that I'll pass some mic to Makka Godbolt who's going to talk about design systems and front-end architecture thank you Joey and he read that slide completely wrong get to the browser that's how you're supposed to read the slide awesome so thanks Joey so what he's done is he's talked to us about how we get to this point of developing developing our visual language about the visual appearance of the site the colors, the buttons, the fonts how we're basically going to be speaking what we need to speak to the users of our website and for us this visual language it really is a language and the point of this language is to speak these things to people so what we need to be able to do is turn that language into a design system and that's what we need to talk to you about the idea of breaking this thing down into a design system is a design system is a programmatic representation of our visual language inside of code now just like a spoken language can be broken down into nouns verbs, adjectives our job is to deconstruct this visual language so we can reconstruct it put it back together again and create the rules that define how that language is put together it's by breaking down the visual language into its smallest pieces that we learn how to put it back together put it back together into various sentences, paragraphs chapters novels, our entire website now the goal of this conversion don't right click, there we go the goal of this conversion is to create a scalable and maintainable codebase that faithfully reproduces anything that this language is capable of expressing this conversion of visual language to design system is a collaborative job between the designer and the front-end developers and anyone else with a stake in this and it's also one of the outcomes of what I like to call front-end architecture front-end architecture next slide front-end architecture is a collection of tools and processes early in the development life cycle meant to improve the quality of our front-end code while creating a more sustainable and I totally missed that one sustainable and efficient workflow, thank you so many of these tools inside a front-end architecture are things that we already use they're not new many of the processes are already tried and trued processes but the point is we're putting them to get together in a very intentional way in a manner under which we create this design system so let me walk you through the four pillars and talk to you about how these four pillars affect this design system and this project as we move forward with it pillar one is our code the actual code that we write the assets that we create for our project now, who here follows the Drupal code standards when you write your PHP yes, awesome cool, I was hoping for some hands that makes it a lot easier for people, maybe the front-end developers that don't write as much PHP have your merge request rejected because you had an extra space after your code block or something like that yes, only me, a couple this happens because there's these great tools that can go through and lint all the PHP are writing and tell you you're not writing your documentation properly, wow that's extremely granular control over the PHP code that's acceptable into the system now, how many people are doing the exact same thing for your HTML and your CSS I see a hand and I love some of you, awesome there are some great tools out there but not only just like are your properties in the right order but are your properties applied to the right things now we're not designing pages anymore we've kind of talked about that several times so we need to establish a process and approach for breaking all these things into smaller pieces we need to create small modular pieces and we need to figure out the best way to do that it might be atomic design which is the way we've been talking about it might be O O C S S it might be snacks it might be whatever process, whatever approach works best for the content that you have and the project I'm at right now with redhat.com we have a very different approach because our content is laid out very differently so we have an approach that works specifically for our content it might not work in other contexts but it works perfectly so then once we have an approach for breaking things up into pieces we need to figure out what's the best way to apply that visual language to all of those pieces this is our design system and this is going to dictate what is acceptable and what is not acceptable C S S now for us on redhat.com we've got a list of rules that we'd like to call the Roadrunner Rules now you might have seen this around recently this is a list of nine rules put up by Chuck Jones about the universe of the Roadrunner Cartoons there are things that state the Roadrunner cannot harm the Coyote except by going beep beep there's no dialogue ever except you guessed it, beep beep the Roadrunner must stay on the road otherwise he wouldn't be called a Roadrunner he'd just be called a Runner so these are the rules in which the authors, the writers the Roadrunner cartoon and the animators of the cartoon have to abide under anything outside of these rules will be rejected and not published this is the same type of approach that we take and then we have a set of rules that govern what can and cannot happen with the code that we introduce into our system for example we break things up into layouts versus components and they each have very specific roles a layout for example is specifically built to provide a background to provide theme context as well as layout for the child elements inside of it now the components they don't care about their background they don't care about margins they don't care about padding around them the only thing they care about is styling the elements that are inside of the component and it's this separation and this knowledge the fact that everyone knows these rules and knows that the code will be judged upon these rules when they emerge requests that allow us to create a predictable a testable and a scalable design system pillar two is testing so we do Drupal Drupal loves behavioral testing because we have lots of processes who here does behavioral testing like B hat those kind of things cool alright unit testing we use some unit testing our PHP we got some cool unit testing is great you can do that with javascript and other things as well without visual regression testing yes got a couple awesome what's that oh I swear back one thank you guys cool alright that makes a lot more sense testing now how many people are testing their site performance some great tools out there some grunt tools and web based tools it's amazing if you have a process set up where your site performance is tested on every single merge request so that you can catch those problems when they happen and that is the point of the testing pillar see testing shouldn't be an afterthought it's not a nice to have testing is checking the foundation of our building before we build another story on top of it and that's not something that's optional testing allows us to know that that foundation is set and is settled and that nothing we do up here is going to invalidate it so the mission of testing is to mitigate the negative impacts of any introduced code so whether those regressions are functionality user experience visual appearance browser performance the mission of testing is catch that infectious code before it's ever merged in from our feature branches so even before it gets in the master those things are caught and it's by setting the expectations of how the system should work so we can make sure that any developer by any developer at any time we ensure that no developer is surprised by the code that introduced I run a little script and PHP yells at me because I did something wrong I know that there's something wrong before I ever introduced that code back in as a merge request and we make sure that any code introduced actually has a positive impact on the system versus a negative all right cool we move forward this is grunt gulp some kind of processor task render awesome it's very cool now that's not the only thing a really good question obviously I don't want you to blurt all this out because it will get really loud think about how long does it take for you to set up a new developer on a new laptop is it half hour that'd be nice is it two hours is it a day is it two weeks how long somebody walks into our new employee laptop does it take before they are writing validated code to enter into the system that is the process that is the value of creating the process so that I drop my laptop in the water it's going to take me two weeks to get back up and running it's a lot of lost time so the process pillar describes the steps required and the tools used to add new functionality to the design system now it's not just about tools but also how and when you use these tools it's about putting the UX in the proper place in the development life cycle it's not putting UX after Drupal development where you're stuck with whatever markup the Drupal developers decided you should have it's putting that in front it's doing that UX work before any PHP is even written so that you can get client feedback so you can do cross browser testing so you can actually get a sign off before a single line of PHP and a single developer hour is spent so at that point the developer knows what their target goal is and that target goal has been vetted by everyone that has a chance to look at it and QA knows when it's done they can verify that what's been built is exactly what was signed off on that is process and that is putting a process in place for your project to win the Paylist Ink is better than the best memory and it's very true as we try to write this talk and I've got these great ideas while I'm in the shower like yes this is perfect it's perfect and you sit down to write and you forget what you were thinking so even if it's the Paylist Ink it's so much better than what sticks in our brain so documentation is obviously incredibly important as we build our system and we pour our individual expertise and knowledge in every atom, every molecule every organism we are the experts of the system we are proud of the incredible work that we have done but it's not just about us and what we know about the system there's others that will be using this system we're not building a system just for us we're building a system for our team so our team can succeed and we're not always going to be on this project we might be finishing up with a contract handing it over, we might be promoted if it goes really well it's not always going to be us working on this project those are just a few of the many reasons why documentation is so important documentation at its root is really a content strategy problem we've got so many things that we need to say about the process and the tools and the things that we do and we have so many audiences that need to read and learn about what these things are we document our onboarding process the way we write our HTML the naming conventions of our classes documentations of accessibility and progressive enhancement eventually we need to get to a point where we document how we document a fully documented system is a web property all of its own it's got its own navigation its own taxonomy, its own search and typographical style as soon as you're creating a style guide to mock up how your style guide is going to be looking you know you've reached the zen level mastery of style guide documentation so documentation is all about capturing all that knowledge that eventually ends up in these personal silos so create a plan for documentation this isn't something you do at the end of a project you need to work in time for every single feature that you build to write that documentation so if you've got a story and it's got task, task, task, task and when those tasks is not writing the documentation something is wrong because you need to have hours for that time for that so they can be properly documented fixed Leonardo da Vinci once said a website is never finished it is only abandoned now it's true that our work is really never done there's always going to be something else that we need to do but there's one magical get mythical point where our design system is capable of expressing or capable of creating everything that our visual language is capable of expressing now think about this utopia for a little bit you walk into work on Monday and you're handed this task to go and create a new node type new content type so instead of going and creating a whole bunch of new CSS a whole bunch more JavaScript to build this big huge page out instead you crack open pattern lab you build up a new page you pull together all of your existing atoms, molecules organisms, templates pull all these together and create everything required for this node page to be able to be represented we have a design system capable of representing everything this visual language can do so in the end your work is already done your design system can already do everything that language needs you can build out that entire page without writing a single line of code without adding a single line of bloat to your site that is a mythical point that we all strive for and of course it never lasts because eventually someone needs a new feature someone needs that carousel that everyone loves someone needs something and it's fine we add new vocabulary to the language all the time English is a great language it's got lots of ways to express the things that you want to say but eventually someone has to say twerking and as horrible as it is it's a very similar dictionary so we do it I've debated on saying that word is that even offensive moving on when it comes time to introduce that new vocabulary the thing is we already have a system in place we already know our code standards about how we're going to write that into our design system we already have regression testing to know that the changes that we make to introduce this new language we've got documentation set up already so that we can just add new documentation for how this new language should work and we have a workflow that makes this process efficient and defect free in the end we have a new design workflow thank you and does anyone have any questions what time is it there's a mic in the middle here so please go ahead and if you have a question there first come first serve you're leaving you can't leave until you have a question just kidding everyone who leaves has a question although I just thought dancing I think he's worked up a jig some sort Mr. Potter no dancing for me so that's like the pinnacle of workflow right there you build everything statically and magically port everything to Drupal is there ever a point where you need to get something from Drupal back into pattern lab let's say copy and paste so it depends on how much time you've got so if you basically just need to hurry up there's no problem with just going over to Drupal inspect element right click on it copy and start working on it obviously if you have a little bit more time and it's a more complicated thing you can see that there's already some sub components in there those can be broken out pretty easily so that works out pretty good for us so don't ever hesitate to do that always take the simplest path so thanks for sharing in all this process in the design and bringing back bringing those things together is there a moment where maybe I can understand in larger sites it becomes really daunting but involving the content strategy team and kind of figuring out things like lengths and is there something in the documentation that incorporates that or is there some thinking you've done about this problem because we've had that at times where we're developing a thing we've got the style guide, we've got the prototype we're working but involving the content management the sort of more content strategy side of things figuring out voice and being able to show the client some of the work ongoing, have an idea of how the content fits into all of this it sort of like seems like the next big step in all of this and I was wondering if you guys have any thoughts about it one thing great about documentation is it is what you make it just like Drupal is a platform you build a website on top of there's no one way to do documentation we use a system called Hologram that allows us to write write our documentation right inside of all the rest of our files mark down inside of some comments really what that allows us to do is create anything that we need to create so we have documentation on our fonts and on the different colors and how you create new git tags and how you push up releases we can document all of our process but we can also document other parts of it you can document what's an acceptable photo what is good copy what are copy lengths what are medium and short copy lengths we can get all that into documentation because we have this whole idea of we've got navigation we have taxonomies for our different pages we have search so you can go in and search for the different topics that someone needs to hear about and the point of this documentation style guys is it's always accessible to anyone that needs to get to it so your audience we find that our audience is there's not just developers it's not just front end not just back end but it's also product owners and the content creation team but they can all go in there and have one place to find that information so whether you need to mock something up with some fake content show what our vocal style is whatever that word is tone vocal tone anyway you can actually put examples in your style guide that demonstrates those so make the documentation what you need to be to demonstrate everything about your website can you talk a little bit about you had mentioned in the beginning it sounded like you pulled some CSS down from Pattern Lab and dropped that directly into the Drupal theme can you talk a little bit about that and what Pattern Lab outputs and how you pull that in and how you use that sure thing so just like in your theme you declare CSS slash style.css and Pattern Lab is just a static site generator so right in the theme folder we have Pattern Lab and then there's two subfolders in there source and public so what happens when you compile Pattern Lab is it throws them all in public and that's just straight static HTML and then in the source there's a partial for the header and basically in there there's just a link tag and it's dot dot slash times four specifically and then it's dot dot css slash style dot css so it's just a relative link that goes up there and just points towards the exact same CSS that Drupal is looking at any other questions? the question was how do we communicate responsive design complex responsive design to our developers I think the answer to that is kind of in part of designers needing to be able to actually prototype out some of the responsive behavior themselves so kind of meeting halfway working very closely with the front-end developer just a lot of communication a lot of working together sort of like working as one brain to design that and I think it can be conveyed through artifacts that they need to do some of that I think really also thinking about this in terms of component based design where we're looking at those individual pieces of how they respond sort of not caring about the context of what they're sitting in then you can look at that tackle those problems individually so just the answer to that really is that you need to have the designer and the front-end developer just really working closely together and just having constant communication and I think a lot of the process like I can't prescribe something it's really going to come down to how they work together and really just having that communication is going to kind of a process will emerge from that does that answer the question? well pattern lab is for what we're looking at is really the tool that we're using for that and just having like that shared vocabulary with the atomic design methodology with the atoms and the organisms and molecules and things like that we're able to look at that so designers work inside pattern lab to maybe rough something out a front-end developer can come in and really start to make that to make that more production quality and work together on that so working inside that and it doesn't have to be I mean pattern lab is a tool we really prefer to talk more about like the methodology but we're really using that for so many projects and it's a common vehicle we're even starting to do more of the workflows for our UX and we can do like working there with content design and get work through IA so it's a great tool to be able to have multi-disciplinary teams working in there in kind of different pieces and one other thing to note is pattern lab isn't just the small pieces you also have the ability to create templates and also pages so you can mock up entire pages in pattern lab it's not just the tiny pieces so it gives you the opportunity to say like what is this complex responsive layout actually going to look like in the browser using all the pieces that are built in pattern lab so it gives you that flexibility to pretty much build out your entire site within pattern lab if you want to so whenever you're building in pattern lab you build these components have you ever played with adding element queries to these components and do you have any libraries that you use? yeah so we'd love eagerly love some native support on that but on a previous project we've just used some JS libraries that hook on to data attributes and I mean you nailed it right there because it's pretty tough to be able to write modular code not just this block but you have to write a media query based on the width of the page so therefore we've kind of contradicted ourselves like now suddenly this little component is aware of its context and that's against the rules but so element queries would just be like totally nail it so that'd be really nice so it's kind of a combination of both it's like yeah sometimes some just classic media queries just kind of get written in there because we kind of know where it's going to be and there's going to be some tweaking but there's also some JS libraries for pulling in some element queries so that would be a good tool to be able to use yes we're using it in production yeah there's there's big sites that I cannot name I'm sorry but I've seen large news organization I know it was like it's enterprise the one by Sam Richard I know he's done it to like you had 10,000 instances on a page of it it'd be like this tiny minor performance hit and typically you do maybe a couple dozen at the most so you know as long as you're smart about it and really like we started introducing them and we found out we really didn't use a ton because we don't we didn't have a lot of needs to like change layout of stuff because stuff was usually pretty much a stack but anyway it's a great tool to have in your basket when you need it and it changes a lot I would definitely say use standard media query first if that is the trick yeah well if you know the things going to always be 100% wet any other questions song requests awesome well I think it went off we'll be at the Facebook booth we'll be hanging out there if you guys do want to combine just talk or ask any questions or whatever thank you