 Okay, I think I'll get started. I'm gonna jump the gun 20 seconds. Hopefully no one gets too angry. Hi, I am Chris Wright. I am one of the two Chris's you'll be seeing in this presentation and this is Wireframes to Widgets. Basically the idea of this is that we're gonna be rethinking our design workflows and bringing in the idea of prototyping and generally thinking about how we approach design as a more holistic process. Amongst the, we also have... Hello, I'm Chris Bloom. I'm front and lead at phase two and I really want you guys to know that we're gonna try to approach this presentation as a way to connect pictures to what we end up having to build on the web and that big kind of dark area in the middle that's a lot of unknowable. So we're gonna make some suggestions. Just our suggestions might be helpful for you. Hi, I'm Ashley Feginoli. Product Manager at Weight Watchers and some of the work that you'll be seeing is the work that we did with the help of phase two late last year. Great, so I want to let Bloom do a little activity here just so we can get a little energy. I know it's 2.15, you're probably feeling maybe those parties last night. Thank you so much for making it out here really quick. So just to get a little bit of energy, I'd like you to turn to someone next to you and tell them about the most memorable build you might have had where you were given a design without a lot of input and you had to put it on the internet. So just turn to someone and tell them it can be memorable good or memorable bad. Let me tell you about something. Yeah. We tell you about everything we ever lost with something. Yeah. Oh God. We'll give it like for the designer I got that didn't ever use the triple website and produced like 60 pages across. Just like with everything different. All right, it's every difference. Like here's 60 individual pages for a super complicated like data heavy site. Have fun. Yeah. This is good. I've watched that video. There's like angry hands. Yeah. So it's funny just like, I know some folks like I know some folks that are probably have been through something like that. Yeah. Anyone that's built a website. Yeah, like maybe two, like 30, 35. Yeah. This is supposed to be probably, yeah. Three plenty of time, I built him like five or two. I just don't want it to go good. That gives him like enough for like one story each. That's amazing. It's like watching how animated it was one time. Okay, let's. I know we can probably go on and on about this. I could tell you about the 60 pages of comps I once got from someone who'd never used a Drupal site. So, you know, I'll spare you that story. But I think what you've probably learned here is that everyone has a story to tell and everyone has dealt with on one side or the other. He'd be either being the designer who's like, I just want this, why can't you give me this? Or the developer of like, wait, why did you design this in Photoshop? Why is this an icon over here? You already have 10 other icons. I don't understand. So if we're thinking about design, being the analyst that I am, I first have to do a problem statement. So what is our problem with our design systems? Our design process is not agile. Development works agilely. We've gotten very good as an industry of working agile and adapting. Design works on iteration. It should be good at this, but somehow like going from design to development is always difficult. So the old way, the way that I'm sure all of you have dealt with is pixel perfection. Someone, you get a static Photoshop file, you're given this and it's like make it look like this. And that's like the worst thing to have. Like what does that mean? What does it look like this mean when you have to actually make something that functions on the web? So doing it this way, we all know why this is bad. I think this is a really good quote that illustrates this really well. So we know this, but like let's just go over it a bit. Why is this bad? It's slow. This is something that's really, really hits home to me. When you build a Drupal site traditionally, you have a backend developer, you get requirements, you build out a Drupal site, then you hand it off to your themeer. And then they do a theme, they're usually crunched for time. And then you give it to a client, they're like, I didn't want that. That doesn't look like I expected. And then you get pixel perfection is such a weird idea in an era of a dozen different screen sizes, being a responsive web. Like how do you make something pixel perfect across so many different devices, across such variants? And then this one is big for me being a UX person. Design shouldn't necessarily infer data. Like design is for telling a story. It's not for designing how the data is gonna lay out on a system. That's something that Dev and UX should be working out, IA. And then collaboration. This is also being the hippie-dippy analysts that I am. I want everyone to sit around a campfire and sing kumbaya and hopefully build out something. So we know this. We know this is bad. This is what we've been working to move away from as an industry. So how do we fix this? This is kind of one of the things that we've been moving towards is maybe the Dev Ziner. Designing code, doing it. Hey, we've got code. Now we can build towards something new. This is great. And I do think this is really good, especially if you're one person working on a team. It's really good if you can translate this. And this does solve a lot of those problems about it. But. I want to interject here. We're not saying this is bad, though the slide actually says why this is bad. But there are a lot of people who work solo or work in very, very small teams where this is very, very appropriate. The point of this presentation is about how do we get large teams with large builds to be able to unify and share skill sets across people? So why is this bad then? So it's a unicorn problem really. It's the way what I've dubbed this is that designers have a skill set. What designers are there is to solve certain problems. Or to tell stories and figure out how to most effectively get this point across on a website. But having to do that in code is not ideal. Code is not built for that. It's built for doing a thing and making it functional. And then the converse of that is that when you're limited by that code, maybe the designs you're making are not as interesting. Then from the developer's perspective, sometimes yeah, oh God, how do I build that in this design? That's not how the web works, but maybe you have to solve a new problem and push yourself a little bit. And that's how we innovate. So whenever you focus on one of these things too much, I think we get a little static as an industry. It's one thing when you have someone that is doing it all at once. But as a team, it's sometimes really hard to translate that. And generally, I don't know if it's necessarily best for these big groups that we're moving towards. So really quick to highlight the unicorn problem. I think as an industry, we do face a lot of pressure to be able to do all things all of the time and be able to work miracles and magic. And what we're trying to find a way is to be able to share that load, find some system that can help, like not everyone be a unicorn. Yeah, so with that in mind, we took a second to think about what we really wanted from our design processes. Agile, like I said in the beginning, we move quickly. The web is always changing. You build a site for six months. That's way different than when you, and from when you started. And design should work the same way. That should be moving. There you go. You might recognize some of this. I was so glad to see Dries talking about the idea of atomic design. What we wanted, the web is moving towards a component-based approach. This is something we've been thinking about for a very long time, and it's something we really wanted to make sure we incorporated into it. We'll go over a very high level of atomic design when we get into some of our tools, but hopefully by now you've heard a dozen different people rattle on about why this is great. Editive, this is also a big thing. Like design is iterative and agile iterative. We want to make sure that we're learning from what we're doing, and collaborative, like I said. I want everyone talking together, and reusability. So this is something we're gonna focus heavily on. So one of the things when you have such a big team is that often you get one artifact, it's delivered to someone, they make something entirely new out of that. The same it goes on, and that's really inefficient, especially when you're trying to move quickly. We wanted to be able to sort of recycle and make sure what we're doing upstream is able to actually produce something of value downstream. And inclusive, like I said, my hippie nature, I want to make sure everyone's included and has a voice while everyone can still focus on what they're good at. And this is, I think, all summed up in the idea of failing fast, trying new things, and adapting to what we learn. And as the developer representative up here on the stage, I feel we don't build in enough opportunity to not get it perfect the first time. We really wanted to be able to help cultivate a process where we could try stuff. I mean, the whole point of Agile to begin with was that you do a little bit, you learn something, and that would help inform the next little bit that you're doing. But if you look closely at a lot of processes designed to build process, you only get one chance to get it right. So another quote I think is really good. I've read basically every book on lean ever written. And I think this is a really good way of summing it up is that we should be able to work together. Design teams, dev teams, they're doing the same thing. They're just approaching at it from different lenses. So we've talked about why this is good. I've set up my problem statement. Let's actually take a look at how this works in practice. And to do that, I have Ashley here because Ashley worked with us on Weight Watchers, which was a perfect project to do this with because they really understood the idea of components and how we need to work together to sort of have an integrated team. All right, so at Weight Watchers, we were having this conversation in September of last year. We rolled out our first Drupal instance in our US market in the end of May of 2015. So you're only talking a few months of maturity there. And I was asked to roll out 12 markets. Okay, I could do that. Multi-site instance, no problem. 16 languages, Drupal has me covered. Oh, but my designers want to redesign the existing website because they don't like it. And it's not working for us. And I also need to design subscriber site content, which is a somewhat different use case. They need different information. You need to fill it out a little bit differently. And when we were explaining this to Phase 2, our partners, they came up with something that would allow us to give UX and design what they needed and allow us to meet our delivery timeline. The thing that I love about what we instituted is that UX and design are integrated into the prototyping that we do. So they actually are the approvers of the prototype. So before a backend developer develops anything on our site, UX and design have looked at the prototype and said, this is good, or you know what actually I need to change this, is that another story? Ashley, can we wait on the build until this is done in the prototype? It makes everyone's life a little bit easier. I'm not gonna say that it's 100% perfect, but it is much better than what I have dealt with in the past. So a little bit more about our site. Along all of this, we also were working on workflow, which is very interesting to deal with. And we wanted built-in documentation and training guides so that as we were designing these new slices, especially as we were iterating on them, there was training right in the CMS for our editor's reference. Okay, so with this, I want to make sure what we're doing here is actually useful. What you can take something away from this that you can integrate today and do what you're already doing and maybe start to change the way you think. So we've got four steps that make up our design process. It's not gonna be encompassing of every team everywhere, but I think at a very high level, this hopefully captures what we think is critical to going from an idea in someone's head to a finished product on the web. Really quick before you change the slide, I love how Oprah is just kinda peeking out of the bottom here, watching all of you. She's watching us, so we better not mess this up. So first up, we have UX and definition. This is traditional. This is what we've done for a long time. This is the idea of figuring out what the business aid is, figuring out who needs what, figuring out how that's gonna lay out, what's the build. We don't need it to necessarily look pretty. We just wanna get some structure and get some sort of uniformity to everything. And I have sort of a who, what, why here. I think it's my journalism background poking its head out. And what I wanted to really stress with this, this is all about process. You can use whatever tools your team is comfortable in. Are you working with Omnigraftal? I'm sorry, but if you wanna keep using it, you can keep using it. And then the why, like why we do this. I think this is critical for everything. If you're doing something, you shouldn't do process for process's sake. You should do it to a means to an end. So with UX, we're really trying to ensure whatever we're building at the end matches what everyone tells us we want in the beginning. So after that, we move to design. You'll notice in the screenshots, we're both using sketch here and it's sort of similar files. That is very deliberate. We're gonna get into our actual tool set later. But the idea of this, this is to make sure that it's that reusability component that we're going from one thing to another that's similar. You'll notice the slide is short. And I have one why here to tell a story. I could give you probably a two hour long talk about why design is critical and why we tell stories. But that's another talk. For now, we just need to know is that design is very important and we should not undermine it. Third up, we have prototyping. So this is the thing I really wanna focus on here and what a lot of this talk is gonna actually highlight. And Bloom I'm sure will have many things to say in here in a second. All I will say is from my design perspective, is that prototyping is a way that we can start to get actual finished designs and actual implemented code in front of the design and UX teams long before we have any kind of backend CMS to actually create it. So this is one of the reasons really did this when we're talking, Ashley's talking about sort of the tight timetables we have here. If we were to wait till a week before the site was ready to launch to get approval from design and stakeholders, that's not gonna work. If someone doesn't like something or if we figure out we didn't think how this was gonna work on a Windows tablet that also as a touchscreen there's gonna be a problem and something is gonna get dropped. So this is a way for us to start to solve these problems early. And just as a quick show of hands, who mainly does most of their front end CSS and JavaScript at the Drupal site level? Like your clearing caches, your refreshing pages when you're making it pretty. All right, all right, all right. It's pretty good, pretty. Hi, so we're gonna get into this when we start to get our tools. But what I really wanna stress at this point is that prototyping doesn't have to be extensive. It's a way of starting the conversation. As much information as we can get upstream, that's what we really care about. So last in our process is building. This is what we've always done in Drupal. This is a theme, this is twig, this is whatever systems you're using. And what you use here doesn't necessarily matter. You can have a headless Drupal site with React and whatever, it doesn't matter. Though what we're gonna get into is some paragraphs and stuff that I did promise you in the session title because we think they're pretty cool. But the idea with this is that the process that we're gonna outline here is meant to take that prototype code and have as much of it as possible be reusable at the Drupal level. So that way, I know if there's any PMs in the room, you're gonna look at something like, why am I having my front-end developers prototype this when they could be building my site instead? There's a lot of good reasons for that. And maybe to help you sell it a little bit more is a lot of the code that they're gonna be doing at the prototype level is going to end up at the Drupal level as well. I wanna reiterate that. We're not throwing away a bunch of assets here. We are prototyping and integrating them directly into Drupal. So if anyone's tweeting like, oh, our prototype's the throwaway, we're not throwing them away, we're using them. Yeah. And another side benefit we get with all the systems we're outlining here is you get things like style guides and pattern libraries that are good ways to start thinking about design from a component-based level. So Weight Watchers was such a good project for us because when I got the first set of wireframes from their UX team, it already laid out as like we have this component. So it worked really naturally. Not all design teams work that way. A lot of people still think at the sort of page level and that takes some adjustment. But as you start to prototype and figure out, oh, hey, you have this header here and this header here and this image and a caption, that's like a card. So maybe we could standardize those across the design. So it's a way to start to influence that kind of like code atomic level of design, maybe upstream to the design team. And I think it's a really good way to start to get everyone to speak the same language, which is kind of hard when we're in Drupal and we have all of these weird particular nomenclature that we use. So what we're gonna talk about now, I've talked about the steps, all of this. Let's actually get into the tools that we use and what we're doing and why we think it's good. So these tools, like I said in those other slides, you can use what your team's comfortable with. I think that's actually really good. But we've built a certain set of tools that work really well for us and we're gonna kind of go through why we think those are good for the job. And this is not just at the Drupal level. The first thing we're talking about here is Sketch. I love Sketch. I come from a Photoshop background to Omnigraphal to Sketch. And one of the things I like about this so much is that it uses that like design language is that we, like there's certain conventions and design software that you're used to. Sketch follows those, but it's built from the kind of ground up to support the web and speak in what we have is like the mantle of the web. Under the understanding that you're not just building one static file, you're building some assets that are gonna display at all these breakpoints and across these various systems. So there's a lot of, I'm not gonna read every point that we have on this slide, but like at a high level, why we like Sketch particularly for the UX is that it's very easy to get sort of a vector scalable design system at the start. And to start from the beginning of this. Also, the level of integrations that Sketch has with a lot of online tools is really, really nice. Sketch is already in the language of the web. Even at this early functional stage where we're trying to figure out our gray boxes, Sketch is really nice. Plus it only costs about 99 bucks. Yeah. Anyone that's paying for an Adobe Creative Cloud knows the pain of this. So for design, unless we also have Sketch here. So if we go back to our goals of what we wanted from our design process, it was all about reusability. This idea doesn't just extend to code. This also extends to our designs. When I had those screenshots before, they were from the same files. We start with the UX and then we build the design on top of that. And it's the whole idea is that, well maybe a designer doesn't have to re-lay out this comp. The UX designer already did that and did that really well. That's their job. They can worry about how do we actually highlight some of the elements that we need. So that's why we're doing it. And then as a more practical matter of what we're gonna get into in the code, Sketch has a lot of really cool tools built in to make it easier for us to get some of those designs to the code level. In Sketch, you can basically export anything as an SVG, which is huge. It's so much easier to get an asset out of Sketch than it is opening up a Photoshop file, like maybe finding whatever layer this thing is on, like copying that over to a new Photoshop file. Slices. Slices. Saving that new one as a PNG. I've never had to do this, clearly. So that's one of the reasons that we like it from the design perspective too. And the symbols pattern thing, I think Bloom is really. Who here uses Sketch as their main design tool? Interesting. Okay, that's not a lot. How about Omnigraphil from UX? Oh, Sean's gonna hate this. And then Photoshop. Okay. So I'd like to point out that in Photoshop, there's a lot of conventions that we're probably used to. Hotkeys, key placements, hand placements. I still have Photoshop claw to this day, which is when you Alt, Shift, Command, S to save for web, okay? All of that transfers over wonderfully to Sketch. So Sketch does a really good job of making a transition from Photoshop to Sketch. However, things that are built into Sketch that Photoshop and the Creative Cloud don't have is this concept of, say, symbols, right? It's a very web-driven process when you're designing the way you define something once and you reuse it with maybe small deviations from one pattern to the next. So next up is the prototyping. So this is something that you may have already seen a couple of talks on is Pattern Lab. This is a pretty cool system we've been using for over a year. The idea, if you haven't heard about it already, about Pattern Lab is that at its core, Drupal is doing one thing. It's generating HTML. All of the code we do, there's whatever you're doing in the backend, at the end of the day, you're gonna produce some HTML that you're then gonna theme. That's basically a Drupal site. And that backend code is hard. It takes a long time, especially the more custom you get. What Pattern Lab is doing is it's basically serving as a framework for us to generate what we think that HTML is gonna look like and we can theme against that. And this also lets us do a interactive version of the designs and start to put this in front of the design team a lot earlier than if we were doing it at the Drupal level. One thing I'd also like to point out about Pattern Lab is that it almost forces the atomic design paradigm. You have to build your atoms and code. You have to build your molecules that compose into organisms, that compose into templates, that compose into pages. I call these the benevolent fence posts of atomic design. And when you stick to a process like that and you have a tool that helps you enforce a design process like that, you get much more consistent results. The analogy that a client once used with me is I'd rather have guideposts at the top of the cliff than a hospital at the bottom, which is one I've shamelessly stolen because I really like it. It's the same way. If we start to put in the frameworks in the beginning, it kind of encourages us to follow our own best practices. I'd also like to point out that most of our assets are generated at this stage in the process. All of our CSS, most of our CSS, a lot of our JavaScript icons, fonts, anything that we need to do, Drupal doesn't care. It's not Drupal's job to generate CSS. It's Drupal's job to maybe serve it. But like CK said earlier, Drupal really only cares about giving you HTML if you're building a website. We'll talk about headless later. If all we're dealing with HTML at the end out of Drupal, then all we need to do is build our CSS and build all of our assets very early on in the process. And it really helps guide the rest of this because we have all of them. That's that reusability we talked about earlier. Do it here, do it fast, figure out your problems, solve them and then sweep those assets into Drupal. And we actually don't do any copying at all. We actually just use the exact same folder on this process, but very, very efficient. So last up on our tools at the Drupal level, paragraphs. So anyone that's been doing Drupal theming before has probably used panels, mini panels, fieldable panel panes, all these different systems. Yeah, we know all too well what this is. I'm partly to blame for that. Paragraphs has been around for a while, but over the last like two years it's really matured and now it's by far my favorite way of thinking about the same component base level at a Drupal level. At a very high level paragraphs idea is that you're embedding entities within one another. Do you wanna give a much better explanation than I ever could? So with the move to Drupal 8 and a lot of the focus on entities as first class citizens inside of Drupal 8, and Drupal 7 did this too as well, if you're able to take a build and break it down into small components, when it comes timed to build say a node or a page or whatever your paradigm is in Drupal, if you can pull those components off a shelf and just use them and have their own data model represented per component, paragraphs lets you do this. If you've got a widget and it's got a couple of fields that it needs, it's very, very easy to build a paragraph, define those fields, add a template for the paragraph and then inject that paragraph wherever you need it. Paragraphs are just fields. They attach beautifully to nodes and yeah, they work well inside of the Drupal build process. So next up we have a little video specifically on Weight Watchers, how we did this and Bloom's gonna narrate this. Anyone who's tried to embed a keynote video in has probably dealt with the problem of actually getting navigation. So Bloom. Okay, we just have to go over there. Yeah, I just need to. It wouldn't be a real presentation if we didn't have at least one thing that took us a second to do. Or maybe 10 seconds. One of the things, do you ever travel a lot like I do? My screen lives on a different side of my desk every day so my brain does not get that left side, right side thing. All right, so let's make this bigger. Okay, here's what we got going on here. We're gonna go from the design to the prototype to the editing experience of making a paragraph. And we're looking at our designs and we're just kinda showing off everything's kind of atomic design-y, right? We see we've already got a design process that works well within the component space. Now, we're gonna focus on this component, all right? There's a lot going on here, but let's break it down. Let's call this an organism. In the atomic design process, you look at these bigger, more complex pieces as organisms because they contain smaller pieces like atoms and molecules. Molecules generally contain smaller pieces. So here's a molecule wrapping what we're gonna see as three atoms, okay? Now, we've got to share vocabulary on the team. We're talking atoms, we're talking molecules, we're talking organisms. Let's go and take a look at what this looks like to prototype. So we're firing up the tooling just to kinda show how fast these tools are when it's time to go build this, right? Compile all your work and let's see it in a browser. And let's walk through the chain of where we have full audit of where this design comes from and why is it doing what it's doing, okay? So we're gonna take a look at this fully prototyped organism. We can see that we've got it in browser. This is responsive, this is on the web. But even better in tools like Pattern Lab, we can see, hey, looks pretty close, we can verify, maybe the spacing's not right, maybe the font size isn't quite tall enough. And this is where we solve these things. In Pattern Lab, we can actually get a lineage of all of the pieces that make up the other pieces in our designs. This helps us really easily figure out that, hey, you know what, there's this molecule, this little tiny text there, sorry about that, that we can go find and make it stand alone. Now, we had some design restrictions of having to reuse this molecule and these atoms in multiple places. We didn't want them to look and be fully styled on their own. Let me take a look at it. You can see, all right, this is what it looks like when it's not set inside of an organism context. And in this molecule, we can even go back even further and see the standalone atom that makes it up. This is stuff that I love because I've been on so many builds in the past where someone said, how did this get here? And everyone went, I don't know, right? And now we know, we figure out where it comes from. So what I'm doing here is we're gonna throw on a little bit of indication of where an organism is, where a molecule is, and where each individual atom is, so we can see exactly where they compile into the process. Let's take a look here. And this is gonna be an individual atom, and you should see organism molecules, and you should see three atom words showing up. So there we go. That's the prototyping process. Yes, there's tons of CSS. Yes, there's tons of templating tools involved there, but let's bring this over to Drupal. So in Drupal, now we know that we need to define a paragraph, okay? This is a full suite of all design components that are available to us at this time. How many of you have been on a build where a client has asked you, I just kinda wanna build the page on the fly. I don't want stuff in there already, right? Okay, a couple. My first response used to be we're not Squarespace, we don't do that. Well, now with this kind of process, I can grab an icon list horizontal display, naming is hard, and choose to throw one in. We get a little bit of documentation about what fields line up with what, throw in some default values for headlines, and we're gonna add sub-components that allow us to embed paragraphs within paragraphs, within paragraphs. I don't need to go into a whole lot of detail other than we've got an atom, we're throwing in, we've got an organism in the back, the background image, and we're gonna start adding in these individual atoms and just fill in their data models individually. It's that simple. We just handle this at the template level with a little bit of embedded logic. Here we go. So let's see what one of these atom columns looks like when it's fully filled out. We're gonna add a second one just for demo purposes. Throw in an icon from a pre-selected list. You can see that our prototype helped us indicate that we needed to pull in a set of data and a set of text fields. It was really easy to emulate that or pull that over and do that in Drupal. All right, here we go, big reveal. And so I picked a background that was a little too light for the demo, but as you can see, we've got two columns with the image on the top, a title and a call to action with the background image there. And this is in Drupal and this is just a node showing a rendered field of fields of fields. All right, I think that's just about. Here we go. Okay, so I know we're going through some of this quite quickly, but if we do have, we have plenty of time at the end for questions and when we wanna drill down into some of this. Since I can find my cursor. So I wanna go back to when we talked about our goals. In the beginning, I had those lists of things we wanted from our design process. And let's talk about how well we've done with what we got fast. So basically, hopefully what we've done from this is we're prototyping much sooner. So we're putting our finished front end in front of the design team to confirm, to talk about, to tweak before we've done basically any backend code. And with this, something that I think Ashley will speak to where our front end team is working about a sprint ahead of our backend team. So that way if we go to the designs like, I didn't want it to look like that. I want this over here. We do that before we actually start to build it in the backend, which is really big instead of like, oh, but we're deploying next week. I can't change that, but we have to go change the back. No, we don't have to do that. Collaboration, so hopefully with these tools, what we're doing is we're getting files that we hand off from UX to design. And on the way, they might be like, oh, why'd you put this field over here? Well, you see, we have to have like it highlighted here. Oh, that makes sense. So what we're doing is trying to get teams in the room together talking, especially the front end people talking with the design people is huge. I know a lot of conversations we have end up being like, oh, why is this displaying this way? And you get on a call and the design team and the front end team can work together of, oh, I wanted it like this. And then, oh, let me change this one code. Oh, it looks so much better now. And that's not something that we could have done easily in Drupal. There's a lot more overhead in having those changes come from the Drupal back end. Well, in Pattern Lab, the text and such that's being displayed is kind of trivial. All we're doing is changing how it lays out. So specialization, this is when I was talking about the why I don't always love designing and code. Designers are really good at solving design problems and coders are really good at coding. I want to let them do these things well. And I want them focused on these things so they don't have to split focus. And then reusability, this is huge. This is the thing that I really want to stress with these tools. It may not come across entirely in that video, but the code that you're seeing in that Pattern Lab, the styles for that front end is the same code. It's being reused from one place to the other. This is another quote I love. And anyone that spends half their day in meetings like me will appreciate this, is that if a picture is worth a thousand words, a prototype is worth a thousand meetings. God, if you could save two meetings a week, I would do something for that alone. So, we've talked about wanting to adapt and learn. So this is what we've been doing for over a year. This is what we did to launch the Weight Watcher site and this is how we've been thinking about the way we build websites. In Drupal 7. In Drupal 7. You'll notice a lot of talk here about Drupal 8. Drupal 8 is really good, especially from the front end perspective, and it allows us to do a lot more. So what are we doing next? When I talked about learning from our mistakes and learning and adapting, this is what we're doing next. So some of you might have already seen a couple talks around this. This is something I'm really excited about and Bloom is gonna give you a good overview. Hopefully it won't get too technical. If anyone has any issues, just raise your hand and I'll smack him in the head. But basically what we're gonna present here is a project we've been working on and we pushed live a couple weeks ago called Drupal Lab. The idea is to have a very basic Drupal site and a very basic pattern lab site that are integrated and share the same code base. Before, we kinda glossed over some of the fact where you do have to redo some of that front end code. All the styles are the same, about 90% of the assets are the same, but the layouts are not. The way Drupal does layouts is very specific and it has a certain nomenclature. We've worked to try and eliminate those barriers so we're trying to make everything just a little bit more reusable and a little bit better. All right, so while he's gonna try to drag this over to the correct screen, so the video actually works, in Drupal 8, we've got twig and a pattern lab used to run on the mustache templating language, which meant we didn't get a lot of reusability out of it. Drupal doesn't understand mustache. So what we've been able to do now is take the pattern lab twig files of pattern lab 2.0, embed them in a simple Drupal theme and Drupal just understands them. There's actually not a single line of custom Drupal code to get this to work. It's just new it, it understood it right away. So what you can see here is we're kicking off, we are kicking off a build of this tool and all we're doing, running a couple of commands, it's actually gonna install a Drupal 8 site for us. It's also gonna fire off a pattern lab site for us. So one site, two systems running in it, very easy to go to PL and see what's going on, very easy to go to Drupal 8 and see the results of your PL work in Drupal 8. Bear with me here. I know this is the UX track and we're getting kind of Cody here so thank you for your patience and staying awake. I really, really appreciate it. All right, so this made a Drupal site for us. I wanna point that out. The things we get in DA and Drupal console run a command and I've got a Drupal site, that was amazing. And you can see here over on this side we also have a full pattern lab URL available to us. Let's take a look. There's our entire style guide for our website and most of our Drupal components. Take a look here. That is the site header. That is the branding block. It lives in pattern lab. It does not live in Drupal anymore. So we're able to pull out every single individual piece for Drupal design and move it to another system that gives us an audit of all of our possibilities. All right, here we've got a card pattern. Cards have images and they have titles and we wanna make a view row that looks like a bunch of cards, okay? What I'm gonna show in the code here is that we've got the Drupal view row on the left sitting at that path. You'll notice it's just a view template. We've got the pattern lab card design template on the right and all we're doing is Drupal's coming over here and it's just going rah. And it's grabbing that card pattern, handing it its own data and rendering it. That's it. So we simply get to pull these pieces off the stack and use them in anywhere we want. Nodes, non-content UI patterns. So what I did here is I just changed the value. I said, hey, make the image go away. And I just passed it a new value and it went to pattern lab, pulled it in, hid the image and rendered it out for us. And we can see we've got all of our cards over on the right hand side in pattern lab. Now, something to point out, I know it's probably blurry in the back and this might be a little too washed out here. That just simply says embed at molecules. Drupal knows what that means and then width. And that width is the key. Twig is so amazing. There's a reason Morton is absolutely insane about this is because I get to choose a pattern and then hand it the data on the fly and that pattern sits in some other system. All right, last but not least, and we can kind of cut this off. You can tell me just to hold off here. We're gonna make a paragraph. I wanna show you that we're doing all of this in the UI. Just completely here. Let's go make a paragraph. Call the card and let's add some fields to the card. Simply a title and an image for right now. And I wanna show how we can make a card and then just use it somewhere arbitrarily, right? This idea of we've defined how it's gonna look and we're just gonna go use it. And stressing that too. So stressing this here too. So what we're gonna see here, I wanna make sure it's clear. When we talked about that idea of atomic design, it's thinking about everything in these smaller chunks. So say for example, you have this page and you know this page is gonna have a header at the top, you're gonna have a slideshow in the middle, God knows why. Then you're gonna have some text in that and then you have like a jobs page where you also need to embed just this little widget. It's the same as every other page but oh, it's unique, it's custom. You'd have to redesign that, you'd have to do it all completely. This idea of breaking up these little components into it is that you now have a way to take what is normally a completely custom page even though it's 98% the same as every other page and embed just a piece of that custom bit just so we don't have to redo all of that work that we've done everywhere else. Thank you for staying awake. We are almost through the demo. You can see here that we've got a title that we're throwing into this card because we have a data model for this. We're gonna throw an image field on next where we simply are gonna make a, we are going to provide these values to our card pattern when we get to some code in just a little bit and then we are gonna tell our article, we're gonna let people add cards to you because this is a completely contrived example. So we're gonna say simply grab a paragraph, add it as a new field. This is a paragraph reference and you'll notice that card is our preexisting type and we select it. This lets you do things like have different content types that have different types of cards, I'm sorry, different types of paragraphs available to them on the fly. And you can see we're gonna go make an article, fill in some values and you'll notice there's this add card sitting right down there at the bottom. We're gonna fill in some values and it should look right, right away, right? Should look perfect on first try. Let's see. Oh, okay. So it doesn't look right. Well, we haven't lined the two things up. We haven't told Drupal to go to Pattern Lab and use our card pattern yet. It's just simply data being spit out to a node. Now, we're gonna rearrange some things in the node so it looks pretty here really quick. We're gonna move some fields up. I wanna point out we're using all of the default Drupal things given to us. It's all out of the box. Hide some labels, move some fields around and then say, okay, there's my card. Let's make it look correct. We have the data. We have the function first before we go to the design. All you need to do is name a template, paragraph, dash, dash, paragraph name and you have a paragraph. And look what's going on here. Same card twig file sitting over on the right-hand side. Nothing's changed. This should look familiar over here on the left-hand side because this is just the paragraph grabbing that card and passing it some custom values from the paragraph. Our Drupal implementation acts as a presenter layer to just simply go designs and patterns from some other system. Let's take a look. Let's clear our cache. And here we go. Refresh. And you can't see it but there's actually a little gray border all the way around. The image is up top. The title is blue. We have a card in Drupal. That's simple. I think of that's it. We can stop them. Here's my mouse over here. So I want to take a quick second to thank a lot of people that have been involved in helping make this possible. A lot of the people behind PatternLamb and the original systems that we've used with this, the Form 1 team gave presentation on a similar subject yesterday and we could have sort of compared notes. It's always good to see that we're all moving towards the same direction. I think that's good for us as an industry that we're learning the right lessons. And then Evan Lovely, Anne, and Kelly are three of our internal team members that have been working really hard on getting this system particularly up to speed. So now questions. I just want to open it up. We have 10 minutes here for questions specifically. Oh, there's a mic there. Yes, so that way anyone recording this knows what you're actually doing. Oh, I think you got to turn it on. He's the tech one. I send him to do it. Just shout it out. It's fine. Technology has a career. Yeah. We're trying to do this as well. The prototype right now, it's not using this. I was wondering as you guys, when we're using Drupal, you're using any of Drupal's JavaScript in the prototype. So let's talk about that. Okay, the question was, are we using any of Drupal's JavaScript over in Pattern Lab? We actually include the Drupal core Drupal.js JavaScript in our PL implementation. That way we can use Drupal Attach and Drupal behaviors, and they just work great in PL and they fire on doc ready, just like we would expect them to in Drupal. So that does mean just write your JavaScript the way you'd write it in Drupal and it works in Pattern Lab. As a matter of fact, all of the D7 Weight Watchers work that we did, everything's just a Drupal.attach behavior and working great. Any other questions? All right. Hello. That's good. So you would use Pattern Lab and a whole bunch of work for our Drupal developer either using fences or just translating to... Right, because they're like, that HTML is not gonna work for us, right? Yes, okay. Okay, yes, so the question is, what do you do in the prototype to ensure that going over to Drupal land is smooth, right, instead of doing something completely custom because there is hard ways of doing HTML in Drupal. We've all been there. Now, this is not the be all end all gonna fix everybody's problems. It still takes a team that understands the limitations or the advancements of the end system when they're building it. As a matter of fact, for the menu system at Weight Watchers, anybody themed Drupal menus before? How much sanity did you have left when it was done, right? We simply built the menu in Drupal, copied the HTML and threw it over to PL and then worked 10 times faster because we didn't have to wait for Drupal to refresh every single time. We actually built the menu much, much faster by simply just grabbing it and moving it over. So yeah, it does, the short answer is, it takes a team knowing the strengths and limitations of both sides of it. It does, because Drupal 8 is able to use those things directly, you no longer are limited to like, ooh, how are we gonna do that in the header, right? Or how are we gonna do that in menus? Because the menu that you style in Pattern Lab and the Drupal Lab Drupal 8 version is the Drupal one. That's the only one that Drupal's using, which is kinda cool. Just shout, yeah. So, I'll speak to this actually as the non-dev in the room. I know I may play one in TV, but I'm not actually dev. This is all we had to do that spin that up. I come from a, I was a poly-sign major when I come from a design background. I'm not a developer. I understand the language, but I don't actually build sites. However, I ran these commands over the weekend, the double check that we're actually giving you the right information here, and it works. Basically, when you built a DA7 site before, you probably used MAMP, you probably used a lot of terrible things, you probably had some PHP version that didn't work. If you're not a developer, some devs are like, I'll just clone that thing and get it to work. And like, but what's this bash thing, what's that thing, all that. What this is in D8, it kind of blew my mind actually, because D8 is so much easier to set up. All I had to do was basically download this and run one command, go into a folder, and run one other command. And that was it. And a lot of that has to do with the Drupal console, which is built into Drupal 8, and generally just making it a lot cleaner of a package. It's not built into Drupal 8. It's built into our implementation of Dupro. Sorry, I misspoke there. It's just like we have, if you want me to have technical, we have Gulp and we have Browser Sync, we have a lot of things built into this. I was trying to keep it simple. Basically, the system we've built here is a little more than just Drupal and Pattern Lab. It's Drupal, Pattern Lab, and a bunch of other tools that make it so you only have to run two commands instead of 20. So a lot of the output that you were seeing there is, we actually just have a little local grunt running. So it watches you work, and it actually refreshes PL on the fly and uses Browser Sync to refresh the browser where you work. We can go to town on SAS as fast as we can work, and that browser is just refreshing like crazy. The velocity is nuts when you get to this level with it, and it does all of the configuration for you. So you install it, you run it, start coding, and it's gonna watch you work. And a little plug there, this is online already. It's been up since last week or so, and you can run this and do it on your own, especially in the dev types, you can play around with this. The whole idea of this is that it's a way to start to think about how to do prototyping and have sort of all these tools we've talked about. Here's a version you can go use on your own projects, even if you're still using Photoshop, whatever you use in upstream, maybe here's a way you can translate it to what you're already doing in Drupal. And as of about 11 o'clock this morning, you should be able to Drush DL and Drush EN, this project. There might be more involved, but make sure you check out the readme at that GitHub URL right there. Any other questions? Border. I might have left my bag, might have taken a vacation around New Orleans without me when I first showed up here with our presentation materials. All right. Thank you very much. Who wants a shirt? Yeah, we have some shirts. Medium. Oh. Yeah. Small for questions. Thank you. We probably have a couple more at the phase two booth if you want to come by as well. Extra small. Kendall, yours. Hello. I don't know if I gave him a card this time. Medium. I didn't, I don't have my card right now. Yeah, we definitely want to like... Yeah, we want to collaborate. Yeah. We're sort of a collaboration group. Yeah. Thank you for coming too. I checked your session out like right away. Yeah, he, I was prepping this, so...