 everybody. Thanks for making it. Really appreciate it. I know that there's a challenge coming here because we're competing with beer, so I really appreciate that. Thank you very much. So let's see here. So we're trends of the new here. We've got keynote live going, which basically means that if you type in that little URL at the bottom, that means that you can see where our slide is at the time. And so that could help if you're in the back and there's some code samples. But also, you can click on links. So I'm going to leave that up for just a second. It's like a bitly 2Q8U capital RJA. That's your only chance to get it. So grab it if you want it. So the title of our talk here is a Pinterest component based design and breaking it. Well, you guys can read. So we're really excited to share this with you. So we got a joint partnership from Phase 2 in Pinterest. And my name is Evan, and I'm a software architect at Phase 2. I'm also on the pattern lab GitHub org and the maintainer of the Phase 2 pattern lab starter theme and pattern lab Drupal edition and a couple other cool things. So if you have any questions afterwards and you don't get to chat with me, Evan is lovely and Lovedo is kind of chat. So and then here as well. Thanks, Evan. My name is Grant Gaudet. I work at Pinterest. I'm a software engineer. At Pinterest, I am the tech lead for most of our public facing not to Pinterest.com sites. So if you think of all our blogs, our help center, our careers in engineering sites as well as like our business to business marketing site, which is what we're going to kind of talk about today in a case study. I've been using Drupal for a long time before we're going to Pinterest. Drupal Architect, I've worked on enterprise integrations since round Drupal 6. So I've seen a lot of good ways to do sites, a lot of not so good ways to do sites and some experience there that kind of led us to look at using kind of a component based approach to rebuilding a few of our sites in Drupal 8. Let's see. Sorry, I found a cursor here. Also, Drupal.org, bonus username, maintain a few modules. One relevant to this talk is the Pinterest media entity integration. So if you have a site and you want to embed pins, users, boards, there's a module recently released for that. A little bit about Pinterest. I'm sure most people have heard of Pinterest or are familiar with it, but just kind of want to get a couple high level points that'll sort of inform some of the reasons why we built the business site in the first place. Pinterest is really a visual discovery tool. So if you think about using something like Google or a tool that's used to parsing words, it's a bit of a different experience than using Pinterest. We do more object detection, visual search, and have a really unique platform built around that. Pinterest is also really large as far as data. We have over 100 billion pins and data points. Those are all again like visual objects and provide this really excellent web of discovery for our users. We have a cool product called Lens. You should check out which you can search Pinterest with your camera phone. The other interesting thing about Pinterest is it's a mostly global product. 60% of our 175 million users are based outside the U.S. And all this combined kind of builds a nice ecosystem for businesses and others that want to use our platform to promote their interest in their pins. So what we're looking at in this talk specifically is the Pinterest for business site. Originally the site was built on D7, pretty early adopter of D7. That informed some interesting architecture decisions, but we went ahead and decided to do a complete D8 rebuild. It's definitely an enterprise site available in 30 languages, full integrations with CRMs, single sign-on, CDN. So not just a typical blog or marketing site from that perspective. And again, components will play a pretty big role in what we're able to do that is normally challenging for kind of Drupal sites or larger sites. When you go multi-lingual, are you trying to think about personalization or other kind of complex topics? This site's been live for quite a while, so the D7 version, before we recently rolled out the D8 version, ended up having a lot of content debt. And just kind of we all were grappling with that decision of like, do people actually like the CMS? Do they like Drupal? Is rebuilding in Drupal the right decision? And a lot of that was kind of fed into this project. So we kind of took a step back and really made sure we were addressing the core concerns that we were seeing as failures in our D7 build. And again, this site is touched by a lot of internal teams at Pinterest, so it was a big effort between our brand teams, design, marketing, engineering, internationalization, and just business stakeholders. Ended up being a pretty big project with a lot of people involved. The new site right now, if you go to business.pinterest.com, is the D8 version. I'm going to step back and look at the D7 version a little bit and just kind of show you some of the pain points that led us to make some decisions differently this time around. So this is the old home screen. Like, if you look at the new home screen, you probably will see there's some pretty similar design treatments and kind of the requirements of the site. So I think that the new site didn't really change drastically. It's still a marketing site. It's still a marketing site for business, but the way we approached building the site changed pretty drastically. And I think that mostly changed between Drupal 7 and Drupal 8 and some of the capabilities there. I think Evan will touch on specifically the front capabilities. The Drupal 7 site at the time was built on kind of what you needed to build an enterprise site, which meant a mix of panels, views, blocks, entity queues, node references, field collections, just everything under the sun, right? Which, for better or worse, makes it really difficult to kind of scale a site, translate a site, and just kind of keep a site running in like a really efficient operational way over its course of its, I guess, lifespan. Even back then, we wanted to start thinking in components and designing in component systems. So one of the old screens from our business site would look something like this, right? You can still see kind of the idea that there's like these, we'll just call them components for lack of a better term right now, just, you know, image, text, some subtext, and then a call to action or link. This all sounded good in nature, and like when we built the site originally, we came up with some solutions that the editors really liked, things were working well, but by the time the site got to the point where we really needed to step back and reevaluate just kind of its lifespan, it ended up being a case that you can probably see from the buttons on this page that people felt more comfortable creating and uploading PDFs than creating pages in Drupal, which is kind of a canary in the coal mine for that you might have a problem. And it just wasn't really effective in serving its goals. So we kind of stepped back again, a lot of decision around whether we keep going, but this is one thing I wanted to share too. Looking at some of the things we did wrong, or that were done wrong, the original implementation I should say, just kind of this general treatment of the body field or any other field in Drupal is like, it's okay to shove data that has presentation layer data, structural data, business logic all in a single field. So on the surface, it looks nice. It's like, oh, the WYSIWYG can do a lot of things. You know, it's, you've got this clean layout, you've got columns, it's doing like multi-column and WYSIWYG, that looks great. But then you take a closer look at what's happening if you click on the source button. It's full of CSS classes, it's full of presentation logic. You run into a situation on a lot of sites where you're dealing with not just technical debt, but content debt. And content debt can be almost even worse in a lot of cases when you're talking about an upgrade. You can't migrate it, or if you do, you have to, you know, parse everything through some awful regex. We ended up with a situation where we kind of said, no, we're going to rewrite everything, we're going to redesign everything. And what we have here is kind of unusable. And again, components are a good way to sort of avoid this in the future. Another kind of pulled back example is like, you look at the body field further out, it's not just one component, the whole thing is just stacked with code you can't reuse. I mentioned another big challenge for us was internationalization. Because the way if you build pages like this, it's very, very difficult to localize or translate the pages. For instance, if you need to translate a single link within this block of text, that can be extraordinarily difficult. So what we ended up doing was putting in place hacks like this. And I definitely want to call attention to the second block of code where it's, the first block is hiding this particular element for every single language. The second block is showing it for English and UK English only. Wrong way to do localization. I definitely don't recommend doing this. But again, like components allowed us to solve problems like this that normally would be kind of tricky in a Drupal implementation to solve. Kind of moving forward a little bit. We've all kind of looked at the way CMS and Drupal seriously thought about pages kind of page TPL rolled everything and then you kind of stepped down and no TPL rolled everything and you kind of is very top down and Drupal tried to really enforce its kind of page building paradigm. I think this is not a Drupal problem. This is a CMS problem. But Drupal is definitely at least in the kind of pre-component thinking was guilty of this as well. Every time you need a different variation of a node, you create a new node TPL. Or you know when your original designs break down. Not in every case but over the course of the site you ended up with just kind of this, where is this template? What's it controlling? What am I doing? I don't really understand what's happening with my site. The top down approach was just really not scalable. I mean pages are kind of not web scale. Especially we turned into everything being service oriented and data coming from different sources. It's something we needed to move away from for a variety of reasons. The end end process again was kind of a collaboration of a lot of teams at Pinterest as we started moving through the redesign. The nice thing about Pinterest is they're pretty designed forward as a whole. And that means a lot of our teams already think in components. We use components to power a web app. We use components to power iOS and Android apps. Luckily from my side, being the internal stakeholder for this project, I didn't have to convince anyone that this was the right way. Because everyone kind of got it already. That's a different challenge that I think some people might have to wrestle with in their own projects in their own organizations. But we sort of had that luxury of not having to prove value in building something out in a component-based system. That being said, I kind of want to just give a little bit of context on why components are valuable and why Pinterest thinks components are valuable. Our co-founder Evan Sharp was the original designer of the Pinterest grid that you see today. I've used Pinterest and kind of guided its direction throughout its evolution. He was a huge fan of LEGOs growing up. And I'll drop a link into the notes after this talk that he gave a talk kind of on the history of LEGO, how it informed his thinking. And there were some kind of pieces that I wanted to pull out of that and just share really quick. I think everyone who's kind of had to explain what components are to someone who's like, oh, they're like LEGOs. You know, you build your pages with LEGOs. You can mix and match pieces. That metaphor works really well, I think, here. The idea being that what we're trying to build and what a good design system is, it's a system of interlocking pieces. And it's a universal system, right? So every piece will interlock with every other piece. There's not so many rules on which piece you can use here and which piece you can use there. I mean, you could probably make some bad decisions and mix your LEGO sets. But at the end of the day, they all interconnect, right? That kind of system is really nice, but it also kind of brings a constraint with it that really empowers content editors. The way they don't have to learn how to use different LEGO sets before building. They can just pick them up and they know how they glue together. They don't have to like, does this one connect with this one? How do these work? And that kind of mindset of building a system that will allow everything to interlock was really kind of pivotal for us. Again, like looking at something like the WYSIWYG is a dangerous thing. We're not giving people blank canvas where they want to know or where they, you know, they feel they're going to break the site. They don't know what they're doing. They don't know design. We want to take all of that kind of fear of, is this going to work like I want it to work away from the editorial experience and just give them a system that people can start creating and not be limited by what they can do based on kind of the perception of it. Again, we like extensibility, so we want to start kind of small, get the basics right and make sure that we can extend the system over time. As I mentioned, the Pinterest for Business site was the first site in what would be a platform of sites. So we're using this foundation to kind of power the look and feel of several Drupal 8 sites going forward. And again, kind of like I think the underlying principle is like we're looking for a minimum set of components that we can grow on and kind of achieve a maximum output. And again, just keep it understandable and fun to use for people so they can kind of experiment on their own and not have to involve engineering or design whenever they want to, you know, spend up a new marketing page kind of at the end of the day. Looking at our process a little bit, I think this is kind of an interesting piece. I'll talk about our process a little bit and I think Evan will get into a little bit of history on phase two. But kind of the way we look at designing components, I'm assuming most people in here are familiar with atomic design to some degree. This is an advanced front-end talk. So I'm going to kind of skip over like the differences between what, you know, all the different pieces are. But if you think about what atomic design calls atoms, which are like the very basic pieces which would kind of boil down to not much more than like an HTML element, something that could stand on its own but couldn't be decomposed any further. We wanted to start and make sure we got like those pieces down really well and kind of go through the process of really vetting what our basics are and just come up with a library that makes the basics really good. What this kind of requires is consensus, which is really important. So the way we kind of work together is our design team is definitely leading the charge on look and feel, what they see as our visual style, our visual language, you know, what colors we use, what our grid feels like, what the typography feels like, and just kind of the overall aesthetic of the site. You can kind of see one of our sketchboards in the background of early prototypes that the brand team was working through, you know, their sticky notes, there's lines drawn through things and this is kind of how we got to the point where we wanted to start iterating on patterns. Brands role is really important in this and like as a developer, our role would not be to tell them, you know, you can't do this, you can't have this component. It's more to provide guidance and really consider edge cases around how components will be used and not kind of dictate that direction, but make sure that things are well thought out, that we present alternatives, and that at the end of the day, you know, there's consensus around whatever we end up delivering. And that process is really crucial. I'm working hand in hand from the beginning with the design team and the engineering team and as well as our production team to make sure that we kind of take our time and get the basics right is really important. In the simple fact, like our component libraries at the core really thrive off that atomic level where, you know, if you're an engineering, you need to implement a button later. You don't have to worry about that button not working in a certain case or if you're implementing a basic image include, you know, all the pre-optimizations are going to be there, all the kind of imaging performance benefits, all the accessibility. Like the things you as an engineer, you don't want to have to think about, you just want your components to work right. That's kind of what we really wanted to get right in the process. And I think we'll go through now and kind of look at some of the examples of like what that looked like internally as we were building out our design prototypes. Again, kind of starting with the basics, brand colors. So, you know, we have a color palette today that consists of, you know, maybe at the beginning half a dozen colors. And it'll kind of expand and grow over time. So we wanted to make sure that as we add and remove new colors from this palette, we're really considering those educations. You know, what is the contrast between the text and the background? When does that need to invert? How do we deal with that? And that can be codified in a system. So every time we add a new color, we don't have to rethink the logic. And you can see on the far right, we have a like an infographic stats component. Same idea. If we want to add a new color or a new type, we already know what those contrast levels are. We know kind of how things fit together and kind of best practices. And so we wanted to start at that very basic level. Again, kind of moving from there into, you know, what does a link look like? What does a button look like? What's a primary call to action action? You might have the button below. It's like a secondary call to action. The bottom one may be a faded out version, which is like a Drupal cancel button on a form. And make sure we consider all the use cases. So if someone's going to use a button somewhere, they have the options they need. Same thing with like links, if you're looking at the right hand side, again, context. How are they going to work? You know, links standing on their own, links in content, links bolded. And just get those fundamentals right. And as I mentioned, I think the probably the most important part of the process is considering edge cases and how we make these components work. International is a huge contact. So we go through the same exercises every component. What does it look like when it's translated? What does it look like with a different font? What does it look like different situations with different line links? So just kind of really battle testing the stuff before we include in our base library. And from that, we sort of start building and composing larger components. And these are more at an implementation level. And right now, kind of just at a prototyping level, but we'd get into something like this where we have, you know, a little bit more of a complex component. It's kind of like the one we looked at on the previous slide where there's a headline on the left and then text and a button on the right. Then, you know, we kind of want to test variations on that. So we get into like, oh, we still have a headline on the left. But now what if we have an image with a caption or an image with a subtitle on the caption? How does that work? And then, you know, there's other variations like if we want to reuse those image and captions that you see at the bottom, but they don't have that headline approach. Like each piece can be kind of swapped in and out of different components. They're not locked into only being used in one scenario. And that's where we provide the flexibility of the system. It's like everything should be reusable, recomposable, and kind of be able to build larger systems. So the idea of starting with like the small components like just an image, just a subtitle and just text and then how we build from there is key. Again, like if you only start at the micro level, you're probably not going to see everything. So design explorations moved into, you know, what do our different blog posts look like? Do we have a header image? Do we have media in line? How does that play out? And making sure we're testing all the scenarios there. Go through a few more of these. Again, we'll take a same example, same idea. This would be like a page where we might be guiding through a user through various steps where they're numbered. You know, we'll go through a responsive grid. Does this hold up? Does that numbering treatment work? And do these, you can start to see where the components kind of will reposition themselves on the page and like what the components are naturally. And this was like really helpful for us to kind of understand the longevity of a component. Like where it would fail, where we might want to rethink it. Where something too, I'd say like not abstract enough. Are we making too many decisions? Are these components too opinionated? And this really helps us get there. And then kind of the super high level where this is our grid showing an entire page with our typography breakpoints as well as our layout breakpoints because those happen at different places. And kind of put everything together. But that kind of high level is the way we start to like build our component library. Again, that was the kind of condensed version of the process. But I think it's super important to work with design as early in the process as possible and anyone who will be in charge of like the implementation spec. And that's kind of what we went through. And let's see just a quick high level on project goals. Again, I think the biggest thing is we just wanted to build a system that empowered content editors, especially in the context of our international business being able to create pages on demand without engineering involvement for as many markets as they need. We also wanted the component library where the basics are really good. They only included the necessary pre optimizations. We're not over engineering. But something we can still extend for the future. And also again, providing a starter kit for new projects, something that's actually going to be a living system. It's not going to be used now and forgotten about later. It's something we're going to continue to maintain throughout the course of the projects. So I've been thinking a lot about this kind of since I started at Pinterest and it had been following closely the pattern lab Drupal integrations and specifically Evan's work and the team. And once we got to the point where Morgan our design lead and AJR production designer, we all felt we were in a pretty good place with our project goals and our design system that we wanted to start actually turning this into a Drupal site. We were in a place we needed a partner with someone. So that's where the conversations phase two started. So let's go ahead and take a step back. And we need to figure out what had been kind of going on at phase two. So before we talk about what our process is, you know, to be able to understand where you're at, you have to understand where you came from. And so this is kind of a little recap of our front end process and the origins. So once upon a time in a code dungeon far, far away in Portland, Oregon, two developers sat. And I know what you're thinking that doesn't look like a code dungeon, but that's the new office. The old office, it definitely looked like a code dungeon. So we were part of stock augmentation. So we had gone to work with a client that shall not be named. And we were helping them out in their process and their environments. And so we we go to start the project up. And they have things kind of so locked down that you have to work up on the servers. There's no local development whatsoever. And it's a very big platform. And so we start the project and we're like, all right, let's go. And they're like, OK, well, not yet. The servers aren't working right now. And we're like, what do you mean they're not working? And they they're like, well, we're we're upgrading the platform and you have to start from that. You know, but you guys have to still like be productive. And we're like, well, how? And so so, you know, born from this pain is this opportunity. And, you know, Chris Bloom and myself, who's sitting right there. And we were working with Susie Arnold. Hi, Susie. And we we had been eyeing Pattern Labs. This is like three years ago. We've been eyeing Pattern Lab. I'm like, oh, yeah, that that makes sense. And so, you know, what real quick, if anyone doesn't know what Pattern Lab is, you know, it's just a static site generator. And it serves really well as a style guide, a component library and prototyping tool. And so what we did was we basically started, we got static site generator going and we started basically like converting like comps into there and then breaking it apart using atomic design principles because being able to make things reusable really, really helped out. There's there's a feature in there that lets you take a component and then just slap different data against it several times. And so you get variations of a component. And so you can be able to kind of see what happens if, you know, they check different boxes or fill things out in different ways, what happens in different state. And so, you know, that really helps out because, you know, imagine being able to like style like every form and even when it's been like required and like required but not filled out, not required but not filled out correctly and seeing all those states in one spot, what happens is a reduction of churn because you have those edge cases covered all the time there and it just saves a lot of time because that's a lot of clicking through Drupal to be able to like do all that, you know. And so after a little while, the client actually really loved the new approach. I mean, so we had a quicker dev workflow which led to earlier feedback and which helped out with iteration, you know, especially because we're able to style out the components without having to build, you know, what can sometimes potentially be a very complicated back end. And so, you know, if you have to build out the back end, you know, to be able to style the front end because you can't style anything, you don't have HTML, right? So, you have to do that and then they say, no, wait, not that way. You have to refactor the back end and the front end. So being able to just, you know, decouple those helps to be able to iterate on it much quicker because comps aren't a website. You want to get this into the browser because that's the medium that it's destined for. And you can quickly find some surprises. I think everyone has, I personally think actually that browser compatibility used to be like the hardest part but I would actually say that like responsive behavior and layout is actually probably even harder now. You know, you're like, here's a comp at 320 pixels and here's a comp at 1600 pixels. That covers everything, right? No. So being able to do that is really great. Additionally, you're able to get all of the things together. So, you know, they send you 57 PSDs and, you know, you basically start to put, you put all the buttons in one spot and then you say to the client, now are you sure you want 17 button sizes? And they kind of look at the page and they're like, no, no, no we don't. And that conversation is so much harder when it's in the page, you know? Basically being able to pull them all together in one spot gives you a really high level look at small things. So this promotes consistency as well. I mean, because honestly, if I feel sorry for designers who have 57 PSDs and then someone's like, can you bump the font size one pixel? And then they're like, okay, we're back in two weeks. So being able to, the consistency just really, really helps out. And then of course, if you update the button everywhere the button is used, cascades through. You know, additionally we found out that this creates a shared vocabulary and, you know, with web design and development, we are talking about an abstract thing. Like you can't touch it. And when you're talking about an abstract component, if you apply a label to it, and it's a green upon label that the whole team uses, conversations get more efficient, they get more intelligible, less assumptions, which leads to less surprises down the road, less churn, faster project. So, you know, the developer, the designer, the project manager, they all call it the media block and they all actually mean the same thing. So, you know, it worked out really well for us. And then they got our servers ready. And we were sad because we didn't want to let it go because it was so great. And, you know, so usually what will happen if, you know, if prototyping is involved is you're basically, you know, you get comps and then prototyping and then off to the actual CMS and then the prototype is left to die. And so what we did instead is we basically just put it in the theme. It's just a static site generator. And we pointed it at the same assets as the Drupal site. So pulling in the same CSS and the same JavaScript. So this is Drupal 7, pattern lab one, just based on mustache. And so, you know, we basically just, you know, got the same assets in there. And then, you know, really, you know, you basically style stuff in pattern lab and then you would just align the markup in Drupal. And so, yeah, and we, you know, you want to reference the same CSS, do not copy this, it, do not copy. Basically, you do not, like, have, like, some task that, like, duplicates it over there because this, on a slight level, is getting away from the single source of truth that you want to go for. So to this process, yeah, so what we did after this project was basically extracted our work out, generalized it, anonymized it, and then put it up on GitHub as pattern lab starter. So pattern lab starter got kicked off in August 2014, two and a half years ago, and it's been iterated on refined and improved ever since. We're on version 9.6 right now. And it also includes a lot of tooling that you need for front-end development as well. I mean, like, why for every project where you've even setting up, like, gulp task to compile CSS. And it's not just that, but some of the subtle, really refined parts as well. So, you know, we truly believe that pattern lab is the best way to organize and work with components. So, we got the CSS, we got the JavaScript, just one thing missing, it's the other part of it. And so, obviously, it's like what creates the HTML. And in our case, by the time it came around to Drupal 8 and, you know, we got twigged. So, if we could just get twig in there, we would get it. We would be able to attain the Holy Grail. This is what everyone wants. And so, you know, not only is it just kind of like, oh yeah, the Holy Grail, like, we're really seeking after it, but like, what does that even mean? Well, it means it's a pattern library and a website whose are perfectly in sync. And so, the pattern library expresses and demonstrates the state of your application and site and vice versa. You get a lot of benefits this way. So, basically like doing updates on your site is basically updating the style guide. And if someone works on the site and breaks it, you see it, you know, in the style guide. And so, you know, there's, this is kind of another demonstration of that same thing. It's, you know, again, Holy Grail. So, basically just making a change in one spot and having it go to all the places. So, this is from Brad Frost. And this is in his book, Atomic Design. And he's talking about the maintaining the design system. So, why do we want this besides how cool it is? Well, we want it because if you have something and you stop updating it and you were to update it in the site and you would not go back and update your pattern library, you lose trust. You know, this is akin to almost documentation as well. So, you know, I mean, if you basically have docs and then you change the process but then you don't update the docs, then you don't trust the docs. So, trust is important. And the thing is, is you can have 100 components in there and a few of them can fall out of sync and not to be up to date, which would cause the rest of them to not be trusted. And so, that's really important there. And so, you know, we get to this point. We've been doing this for a little while. It's about a year ago or so. And we're starting to do a lot of projects in Drupal 8. And, you know, we're like, okay, I mean, pattern lab, where's pattern lab 2? Where is it? And basically, development on it had kind of like stopped. And the thing that actually even worse is there was basically a bunch of like betas that didn't work. So, it was like a tease, you know. And so, we, at phase 2, we did some internal investment on our process. And we set out to basically see if we could get this working. And we looked close at it. We looked at close at writing our own thing. You know, we firmly believe in open source. And so, if we can, we'd rather contribute back to a project that other people can use and, you know, also help us build, too. And so, we wanted to be able to do that. And so, we kind of set out like, you know, evaluating everything that we could for it. And, you know, it turned out that somebody out there had kind of actually got some stuff working. And so, Alexey Peebles, who's in Helsinki, Finland. So, he had put out a blog post. This is January 2016. So, I'd love for someone to show me someone who had this done before him. So, I think Alexey is definitely the first one to get some stuff integrated. But we looked close at it. And, I mean, he had forked Pattern Lab and then had thrown his own modifications on there. And he had actually tried to pull Requestim into the Pattern Lab project, but there was just like unanswered PRs, which like scared us further. Because it's like, if we're going to contribute back, they're just going to sit there, too? Or are you going to basically maintain another fork where we just merge all their PRs? Like this sounded like a nightmare. And so, you know, you can also see he's mentioning the Holy Grail, too. Many people are seeking after this. So, and also, yeah, check out his other theme. He's got a theme, the Sheila theme. It's named after his dog, P.S. And so, yeah, he's great. And so, what we did then is basically like, well, if he's got these unmerged PRs and they're just going to sit there, then we can't take that approach. So, I was just, I just asked, is it Brad, Dave, is it done? Is Pattern Lab abandoned? And, you know, I actually kind of didn't even have any, like a little hope for the response there. You know, but they kind of got back to me and then, you know, they responded about what had been going on and then they're like, okay, I'll take a look at it and then we're like, hey, what's wrong with this? And then he gave some feedback to that. And then Alexi chimed in and then we got some of the PRs merged and we got really excited and we were really stoked. We love Pattern Lab. And then, you know, we find out that maybe we can work with Alexi. And so, like, I'm like, hey, let's do a video chat. And Dave's like, I'll join the hangout. I'm like, oh my god, yes. So then we kicked off a meeting and kind of like, I think we lit a fire under his butt a little bit. And we were like, all right. So he's like, all right, I'll kind of, you guys, okay, tell you guys are passionate about this and we'll get some of these final pieces in. We're missing this and this. And so, you know, Alexi, myself, and a few other people, and sort of at phase two as well, was helping out getting this going. And, you know, because we, of course, wanted to like get Twig going instead of Mustache, but there's also certain things that we needed for Drupal to be able to work with this. And so we gave him some feedback on that. And, you know, we got it in and then he launched it. And so, pattern lab two got out and it was using Twig. And so the first challenge of a successful compile happened, but, and I had been fearing this is, well then, how do you use it? So like, be careful what you wish for. I mean, do you want to recreate Drupal's rendering pipeline in a static site generator? That sounds horrible. So, you know, we thought about these challenges. I mean, we tried all sorts of different approaches. We like put all of the Drupal templates in pattern lab. Don't do that. And, you know, we took a lot of different ways. And, you know, there's, you got to keep in mind that basically there's, I mean, there's different data that gets handed to the templates. And there's extra add-ons that Drupal has, you know, like the T filter for translations, link, attributes. But what I'd like to kind of focus on that's really important to be able to understand this, file paths. So, how do you, how does the system know to find that? You know, so, well, the first one, I mean, Drupal's going to start at the doc root. Pattern lab's going to start at source slash patterns. That doesn't work. The second one is if you take a look at pattern lab docs, that's how it recommends pulling it in. So, this is actually, it's a super convenient, like pattern lab shorthand syntax. And it basically is like, all right, give me the first part and the last part and the middle will be fuzzy. You know, pattern, path dash template, you know. And then this last part is the at path is using what's called twig namespaces. It's just a variable for a base path. And that's in twig, you know, just twig core. So, we looked closer at that. And we got some changes done to pattern lab core. And we got some default twig namespaces. So, pattern lab will register a twig namespace for each folder under source slash patterns, stripping out the number of course. And so, we have at molecules. And so, and this, by the way, that can be anything. If you're like not that big into atomic design, you're like smacks or whatever, go ahead and rename one of those layouts. It'll totally work. At layouts will be there. So, you can call them whatever you want. You can add to it as well. You can see we actually add base. So, we put that right even there before there because we put our sass in there too. We kind of, you know, need color variables and things. So, and then Drupal, the theme name slash templates is the twig namespace. So, they'll, same thing happens with modules as well. You can see the machine name slash templates. So, but they're still not aligned. You know, they don't know of each other. So, enter the component libraries module, allowing you to register extra twig namespaces in Drupal. So, this, the code screenshot right there is in the themename.info.yaml. And so, you know, we're like, hey, Drupal, this is what we mean when we say at molecules. So, but funny, so, did anybody here see the periodic table of Drupal modules? Yeah? Yeah? Component libraries, number 79 right now. Like, most downloaded Drupal modules. So, I mean, there's a lot of people wanting this and you could be able to register, like, at components and not even be using pattern lab and still just be like, hey, go there for this. So, this is one important concept to be able to understand. The other one is how do you pass data around? So, you know, we have our include, you know, and so we got b.twig on the top and we're going to include with title. And then title becomes hello. And then there we go. So, what's crucial is c.twig. So, we have a variable set label and we include and we set title to label. So, we just remapped our variable names. You'll see how this is really helpful here in a minute, but this is a crucial part. The only, that prevents variables from leaking into the global namespace and one thing you're going to want to be doing if you're doing reusable components is encapsulation and making sure that it is basically kind of in its own little world and other things do not leak in and, you know, you could set variables above and then include it, but then that's very magic and you want it to make sense to other developers. Very explicit. So, this also works with not just include, but extends and embed. So, you know, what this causes to think about is, well, what if we have these two types of components? You know, there's definitely a lot of this is borrowed from the React.js world so we got these presentational and container components and there is no technical difference but it's a difference in their purpose. So, presentational is concerned with how things look. It has the vast majority of the HTML. It's styled using CSS and only has minimal logic like if and for which allow flexible variations and it does not care where the data came from or how it got it. It can contain other presentational components so you can be able to kind of nest and embed. So, then we've got our container components and these are concerned with how things work. They have little to no HTML. They're not styled using CSS and they provide the data to the presentational components and it does not know or care how that data is presented. So, you can see with the examples that we have this very general card and then in the container we have its implementation of the node card view mode or the views row card. Also, we've got the paragraph pull quote or the field pull quote. So, if you basically extract this apart and you decouple this, you can change a part of it. You get a lot of cool things if you start doing things like this. I realize the code might be a little tough to read in the back. I'm going to have, I'm going to zoom in on it in just a second. So, what we have here, the only presentational component on the screen is in the middle and so we've got underscore card dot twig and you can see where I've got a little, these are the things in pattern lab, I've got the gray background and then drew pull of the blue and so, you know, you'll note that the name of the file is underscore card dot twig. If you name a file like that in pattern lab, it just hides it in the user interface and it is a convention to state that this is a presentational component. So, what we have here, let's go ahead and take a look at when that presentational component gets used in Drupal. So, we've got a node template, a paragraph template and a block template and they're all including it and they all set the title to something different. We've got the node dot title, we're hitting the value off of that for the node teaser. Paragraph is including it but it's setting it to the content field title and then the block is including it and then it's got label and so, you know, if we had made basically just, if we had just put paragraph dash dash card in pattern lab, then we would have been stuck with that variable name being field dot title the whole time and we wouldn't be able to use this in the node view or as a block at all and so, this is where that flexibility really pays off. So, fun fact, on the paragraph title, you can see that I'm piping it through render. So, if it's empty and then it hits the if, it will still pass because it's a render array and so that still passes if even though it is empty content. So, fun little twig fact there for you. You can find that out the hard way but I figured I'd help out. And then also another fun fact on the node teaser, you'll see that we're hitting the title but we're going to dot value. So, a lot of this does map right over to some of the PHP functions and in a nutshell, you basically just have access to the public and getter functions and there's a lot of stuff that you actually can do here and there definitely comes a point when maybe this should be pre-processed, you know. So, figure out what makes sense there but if you're just grabbing simple field values, this works great. So, let's go ahead and take a look at how pattern lab consumes its own templates. So, we've got the presentational component on the right and the container component on the left and what these are is the implementation and the demonstration of the variations. We've got a card with an image. We've got a card without an image. We've got a card that's dark and so you get this all in one pattern lab page and it's awesome because you can be like as you're setting like your margins and your title, you can see how it affects if there's an image there or not and you don't have to go through the clicking of pulling an image out or adding it. It's just all right there and by the way, that really sets you up very nicely for visual regression testing which is awesome. So, there's the whole diagram again and so you can see again that basically this works really well for us and you have these abstracted away front end approach of just focusing on the presentational components. These are your reusable components and so, you know, like I said the pattern lab style guide component library prototyping tool typically the presentational components would live under molecules and organisms. It's just a personal opinion. There's a lot of ways to do things. The atoms tend to be like a style guide and prototyping for just kind of testing stuff out in the templates and the pages. But again, it's not like presentational components pattern lab container components Drupal. You are able to show off how to use it. Likewise, if somebody wants to make a Drupal template that is, you know, like card dark they can go to card dash dash dark copy that, paste it in and then start replacing those values with, you know, the Drupal values. One thing I forgot to mention is on the pattern lab side you'll note that the container components on the left are using things like headline.short, excerpt.medium. Pattern lab has got some global data for stubbing in content. You know, it's just like excerpt.medium is, you know, I don't know, 50 characters of Loramipsum or something like that. And so, you're able to just kind of pass that in because that would suck to type all the time. So, yeah, this works really well for us and this kind of led to well, if we can do it like this then we, you know, back end and front end can work in parallel and we're not being blocked by back end development and you can be doing things on different sprints as well and this really, really helps out because you can also be a little less concerned about the other side and there's definitely the integration part as well but you still have that container component where you get to remap the values and that really works out very well. So, I talked a lot about Pattern Lab Starter and about how we kind of put it together. You know, you go ahead and roll your own with some of those lessons but if you want to get going and play with this we've got Pattern Lab Starter. It's up on github.com, slash phase two, Pattern Lab Starter. Just Google it and it's get up and go. I mean, it's get clone, NPM install, NPM start and you've got a complete working like front end. They're happy about it. So, you're ready to go and even if you don't use this to start your projects but you should, it's a good playground and the theme can stand alone. You're able to start the theme when the servers aren't ready or the database is broken or you don't understand Docker enough or something and you can just put it in there and it'll be able to work and there's some extra goodies that have been added on there because we've iterated on this for two and a half years and we think it's awesome. So, and I've actually got to say it's probably the worst Drupal theme out there because it really just doesn't even have any like template files or pre-processing functions because everything we do is custom and we leave that up to you but we've got everything else figured out as far as how you do the integration with Pattern Lab and a lot of the common tools necessary to build the stuff. You can do kind of some of the fun, creative stuff that's unique to your project. All right, so that's our process and that's how we got there and we've passed forward to the current time and Pinterest and Phase 2 start chatting and usually what we're kind of used to is educating our clients and be like, so a lot of great pages you got there, but let's talk about the components that build them up, you know, and we have to kind of prove that process and so when Pinterest and I started chatting they already had this broken apart. I mean, you saw those designs, they were beautiful and I remember the meeting where we all got together and it was like, if you listened in it was like a lot of like, yeah, uh-huh, me too. Wow, that's great. It was an alignment of our approaches and so we think that our process should be able to handle less than ideal input but also a very ideal input like we got with Pinterest. So let's go ahead and talk about how that project went so well. Part of how that project went so well is amazing people on it. Susie Arnold, who's here, was on the project and Ann Sturtivant from Phase 2 Morgan Key's the designer at Pinterest, a mac at work. So let's talk a little bit about the site that we launched using this approach and David Spiro is on the project too. You're right, you're right. I saw that, I was going to get some crap later. All right, this is what the site looks like, business.pinterest.com. Let's talk about it, Grant. Thanks, Evan. Really great stuff. I think what he was saying, the alignment was really great in the fact that when we came together there was not a lot of discussion around hey, we're going to come with this front end approach that's going to tell you how to build a CMS. We weren't going to build a CMS, it was going to tell you how to build the front end. Those things are completely decoupled. I think the slide he had about the front end back end process working in parallel was really key. We both understood that in order for this to work you come with strong APIs, you know what your core data entities are and you both build towards that from the beginning and then how you implement it in Drupal is your choice, how you implement it in Pattern Lab is your choice or whatever other data provider you're bringing into the system. Because this is a front end talk and we have 10 minutes, I definitely want to save time for questions. I'll talk about Drupal specific implementation a little bit, but if anyone wants to talk about architecture more in depth feel free to find me afterwards. The site ended up being a pretty cool use case. By focusing on components as the biggest building block enable localization, plan for future personalization of pages, being able to hide and show components on different pages in different languages and just get into these really advanced workflows that are necessary for having content shipped in 30 languages. That's also being fed through a translation service that's completely external to Drupal. It turned out to work really well. Definitely some caveats, but happy to chat about that. Again, I think the solution for success here is using the tools Evan talked about as far as the Drupal side, but also again focusing on just well tested core APIs, use nodes, use views, use blocks, use media entities, use paragraphs. I wouldn't stray too far from that. And all that seems to work really well, or custom entities as well. Kind of moving forward for the sake of time. We have a few components we can look at, but this is just kind of a quick view to showcase what it would look like in the browser, in the phone. We have the pattern lab data example. Give it a second. Yep. A quick screenshot of what we consider one of the presentational components. This is just a paragraph, kind of close up. You can see there's no WYSIWYG on the quote field. Got rid of all that. We're looking at the quote display size, which is feeding data to pattern lab directly, feeding variants. Again, pattern lab doesn't care where this comes from. Drupal doesn't care what pattern lab thinks about it. They just work together. We're feeding other data such as color variables, just really simple edit forms, getting rid of the whole WYSIWYG experience. It encapsulates data cleanly in the database if we ever wanted to serve this through an API. It's super easy to do. The other example is kind of more of a... one of the... not presentational words of my mind. Container components. Same idea. We have the pattern lab variants here. Do you want to say anything about this one? So those are all variations on one component. So that's the kind of stuff I was talking about there. Or you're basically able to just show how different it could be if you pass in different data or in different states. And again, on the kind of the quick version of the Drupal backend of this, again, we have a container paragraph just using nested paragraphs, which wraps our headlight component and gives admins the chance to enter a headline and then kind of select what the subcomponents are. So super flexible, completely extensible. And if you look at the bottom with the little publish button too, we can control layout per translations, per any data you want to pass it for personalization and really enable pretty advanced architectures that way. So this allows us basically... paragraphs inside, paragraphs here. I mean, this is molecules inside organisms. So you're able to create a subpiece there that gets used in the headline component, but it's also used in other components as well. And so this approach of basically having paragraph after paragraph is kind of this concept of slices on a content type has worked out really well for us, but it doesn't have to just be full-width stuff because you can put things, you can lay them out and with this approach, and we found that to be working really, really well. So there's a lot of benefits that we have seen from this approach. I mentioned the faster feedback loop because backend doesn't need to be changed or even present to be able to work on some of these things. So you can also build out new sections and pages that were not specced out at launch and just reshuffling around how the components are used. I talked about creating a shared vocabulary and making sure that everyone calls the thing the same thing. It really helps the communication and reduces the confusion and ambiguity. The approach with the presentation on the container components, I mean, one thing that's just super huge is that it's better reusability. If you create a component that gets used in one place, why? So you're able to use that same presentation component with completely different data sources. You could be using it in the block template, node, views row, paragraph, whatever. And so also with this setup, since it's a static site generator and it shows all the variations, it works really well with visual regression testing. And so with that decoupled approach, it's much easier to refactor and improve without the danger of systemic system or systemic regressions. So basically, you'd be able to swap out. You could completely change your content types and go from views to something completely else and then just re-include all the components. Yeah, you're refactoring your back end, you're refactoring everything. And vice versa with back and in front end too. Again, the variations are really helpful. You'll see everything on one page as a front end dev. It's so nice, especially if you're basically just getting styles injected without even reload. It's so nice. And yeah, most consistency prevents people from reinventing the wheel. It's a nice visual reference for the content editors too. So you open up that create node page and you just have a blank thing with a text label, create headline component. What is that? You can go over to the pattern lab and be like, oh, I can make all these things. You're basically opening up the pattern lab is like going shopping for the component you want to be able to use. It's a demonstration of all of them. And sometimes you might not know what words you're looking for, but you know what it looks like. You just scroll and scroll and be like, I want that. And then go and use it. And then as well, if you want to update your site design, you just update the style guide. So that has proven to be really, really helpful for us and we really like it. So we've got about four minutes left and we were going to talk a little bit about what's next and then some QA. I think we're going to jump right to QA, but if it ends quick, we could talk about a couple things that we think are next. No feature announcements or anything. Just kind of ideas bouncing in our head that we'd like to share if you guys are interested. But let's go ahead and start with QA. If anyone has any questions, come on up to the mic. We'd love to have them. Hey, Salem. Awesome presentation, by the way. Thank you. This is phenomenal. My question is actually about the cart component example that you gave. How do you guys think, what are your guys thoughts on evolving and changing that single source of truth? So one of the things you mentioned early on in the presentation was, your guys' vision is to have this be the engine that powers a bunch of different sites, not just one single business-specific site. That becomes tricky when you want to start evolving the components themselves. Any thoughts on how you might manage what variables are actually called or what actual internals are currently... When those things sort of change, how do you guys think you might tackle that? Well, kind of taking a page out of December, you've got major changes and minor changes. Major changes are going to break backwards compatibility. Minor changes are going to add new features without breaking backwards compatibility. So for example, if you were doing visual regression testing, that's going to make it a little bit easier to confidently add new features. Being able to put things in there, making sure that obviously you wrap things in if statements in a way that aren't going to get triggered by other ones. You got it. Yeah, exactly. It's a minor bump. So basically, yeah, new features, still backwards compatibility. And so if you wanted to be able to do a new one, there's a couple ways you could be able to do it. I mean, you could just duplicate it and be like v2 or whatever and then eventually kind of do some renaming. I mean, you also could have a presentational component include the presentational component and then the container components would include that. And so you would basically extend it and then that would be the thing that you got pulled in. It's an adapter. You got it, yeah, you got it. And then there's definitely a lot of... This kind of ties into a little bit of the idea that we had bouncing around the what's next, which is basically like versioned dependency like core style guide. And so you should be able to include your style guide at a specific version and be able to have a reliability that's work. So that lets you update the style guide while old sites are using the old approach and it's still consistent. Yeah, yeah. And so you're also able to basically register twig namespaces, not just in Drupal, but also in PatternLab. I didn't get to talk about it, but there's a PatternLab plugin that I've written that lets you basically do the exact same thing as the component libraries module, register more twig namespaces. If you Google plug-in PatternLab twig namespaces, you'll find it, or if you just ping on Twitter I'll send a link, you would be able to wherever it's at reference it and then include. Did I answer the question? Very much so. Sweet. Thanks. Just to add to that real quick, make sure you get the basics right too for extensibility where you're not providing everything in every option but just things people can override later if they want good examples. Like if you have a button that's just above myself but you want to maybe like add an image inside of it later, you don't necessarily need to provide that in your base style, but just make sure like the core of what it does really well, all your sizing grid, like the way the containers work. Yeah, and that way like if someone needs that they can implement it on their project without needing to roll it back into the upstream repo ever and just kind of keep what you're doing at a low level working really well, really help. And I think the other point is like versioning has a lot of benefits too as far as making sure your library is immutable and easily changeable and they don't drift over time. So I think there's a lot of benefit to that too. This is a question for Grant. Let's talk about designers for a second. And how do you go about communicating this process to designers? I felt a little bit of pushback in the past. It sounds like you guys were kind of like really with it from the beginning, but what if we're dealing with, you know, purely Photoshop and kind of poster approach. How do you train, how do you learn about this together with designers? This is a really tough question because I've run into that too when I was on the client side or the services side of it, but I think from my perspective, like sitting in a room with designers and like working together and addressing concerns and like having a real working relationship and not having these be separate processes that you don't communicate during the course of the exchange goes a long way. I think, again, like knowing that design is probably going to be leading business requirements and you're going to have to kind of meet on their terms a lot of times, but being there to like carefully consider edge cases, give thoughtful feedback. You're not going to be like, hey, this is wrong, but here's maybe a better way to do this and just being really demonstrative in the reasons you're doing it. It's kind of fuzzy, but it's like, it's hard to... Any advice for identifying those edge cases earlier, like before code, like purely in the design stage? Test with a variety of data, test against a lot of assumptions. Yeah, I think as much like real world data as you can test with, more context, yeah. Also, I kind of mentioned that I think that your process should be able to handle less than ideal input along with ideal input. I wish every client was like Pinterest. I mean, that would be amazing, but sometimes it's not and you get pages and I would still apply the same process and I still think that, you know, as front end developers, back end developers, looking at the comps and basically being like, all right, we got to break these down. What are all the pieces? What are the components here? Because even, I mean, if the designer wanted to make 17 button styles and waste their time, that's their issues. However, we want to do it better because we don't want to code 17 media blocks and it's going to be horrendous. I mean, not even just the initial implementation, but bug fixes, because you know you're going to do the bug fix on 15 of them and so then you basically just have they slowly float away from each other and then, of course, like some...