 All right, everybody ready? It's time, 30 minute. Yeah, that's what I'm talking about. Yeah, that's some end of the day energy. All right, yes, coffee. And if anybody likes both Drupal and coffee, I have stickers that involve both of those things. So come get them. Yes, coming this session just paid off for everybody. Anyway, I'm talking about how it's a 30 minute session and then I'm just rambling up at the front. So let's get in. So this is an external design system in practice. And I am Brian Perry. I am a lead front-end developer at Bownious. I live in the Chicago suburbs. I am a lover of all things component-based and component-driven, building with components in Drupal design systems and tools like Pattern Lab and increasingly building with component-based JavaScript frameworks like React. And I'm also a lover of all things Nintendo. So if you want to talk to me about any of the cool games that you're playing by all means, I am available on the internet in a bunch of places and would love to internet with you, however you see fit. And I work at a company called Bownious. And I really appreciate them sending me out here. Work with a great team of Drupal folks. Drupal is one of a handful of things that we do. But love the people that I work with. We also have an open architect position if you're looking to work with us. That would be wonderful. And you might not know me as working at a company called Bownious. Maybe if you do know me, you know me working at HS2 Solutions. I didn't quit. It is the same company. We rebranded. And this is kind of the jumping off point to the story and how I fell into using an external design system on a project and changing my approach a little bit. So let's look at this through the lens of our rebranding story. So we have our old HS2 Solutions website on the left and our new Bownious website on the right. Different sites. We were looking to launch our brand on November 5th, 2018. Even though it didn't really feel like it to me on a day-to-day basis, the website was just one part of a larger coordinated effort. Press releases, new business cards, new email addresses, IT changes, and also a website. So part of the reason that we were rebranding is that we had a number of acquisitions and kind of new forms in the company. So we were actually looking to migrate a handful of different sites into a new Drupal 8 build. There was our Drupal 7 HS2 Solutions website, lunametrics.com on WordPress and infield digital also on WordPress. And the main thing that we were migrating was the blog content, especially Lunametrics had a lot of great, rich blog content. And because we were rebranding some of the other content, we were just kind of gonna be recreating from scratch anyway. But Nate was a dev taking the lead on the migration. So he's working on getting some of that data into our new Drupal 8 instance. And at the same time, I worked with our XD team, especially Leon, kind of taking the lead who is doing some initial wireframing for concepts for our new site in Sketch, sharing things in InVision. And then as best I could, I was following along in as close to real time as possible, prototyping things in code so that we could see it up on our feet, actually work with it in a browser, experimented non-traditional break points, all of that good stuff. And then the process continued. We had a more fully defined look and feel. Jolene was taking the lead on that and continued to do the same thing. Keep working with these prototypes and incorporate the stuff in code so we could see it in browser and work nicely. So at this point, we had a nice set of prototypes in a separate repository and a pattern lab instance working with it. So the question that we had to ask at this point is how are we gonna get that stuff into our Drupal build and how are we gonna make use of it and integrate it? And I'm gonna use a somewhat ridiculous analogy to explain this mustard anise versus separate mustard and mayonnaise. And if you understand the mustard anise reference, congrats on being a comedy nerd as well, big points. But so the mustard anise approach was what I had mostly done in the past. So pattern lab embedded in a Drupal theme and a lot of the component-based or pattern lab-friendly contrib themes do the same thing. There's advantages and disadvantages to this approach. So it's easier for Drupal to get at your components that are right there in your theme. Potentially there might be some ways that the build process is simplified in this case. For people who are not familiar with the component-based approach, it's gonna be a little bit easier for them to wrap their heads around. They're gonna look in the theme and find the things that they can then change. But it's also definitely prone to Drupal-specific things finding their way into the components and then thinking of the jar of mustard anise here with the layers on top of each other. You put your knife in there and take some out and then the mustard anise starts to kind of get mixed up and it gets harder and harder to just have mustard or just have anise, which may or may not be a problem. Alternatively, the state that we were at at this point in time is we had an independent project. We had a completely separate repository that had our work in progress design system and a separate Drupal repository. And in theory, that's gonna promote reuse beyond just the Drupal project. So the question that we had to ask ourselves is where should we put the mustard? Question you gotta ask yourself every day. So we decided to keep the mustard separate. No Heinz-Mellomust, which is a real thing that people can buy now for some reason. So it keeps the components Drupal agnostic and I think in some ways it continues to encourage prototyping. You can still, if panel line wasn't been on your theme, you can still prototype in there, but I think it's really easy for people to just start hacking away at things in Drupal rather than doing lighter weight prototyping and it's kind of more encouraged if it's separate. It already was a separate project, so it was kind of the path of least resistance. And then also some gut feelings that go along with this. It's always, this approach has always conceptually felt like the right thing, even if it wasn't what I was doing. Advocated by many in the community whose opinions I trust, big bonus there. And in theory it might let us reuse this on other web projects related to our brand. And also it kind of felt right for our company. So especially in our time of growth with some of these acquisitions, lot of these are not all developers but a number of them are front end developers and some of them work with Drupal and some of them don't. But there's a lot of people who can write really great HTML, CSS and JavaScript in our company. So structuring things in such a way that our more diverse set of skills could contribute on the front end was an attractive thing. So let's talk a little bit about how we approached it. So in our design system, and this is using the PHP version of Pattern Lab. So we added a composer.json file, gave the project a namespace and name, description, and then defined that type of design system. So we just made that up, it could be whatever we wanted to and we'll see how that's used in a second. So then in the composer.json file in the Drupal project, in the repository section, we added our GitHub, sorry, Bitbucket repository, right next to packages.drupal.org. So they can be aware of that dependency. And then in the extra section here, we added installer types of design system. And then we can define exactly how that, a dependency of type design system is handled. So in this particular case, we already had a number of composer dependencies at the root of our project, managing the Drupal project as a whole. I personally wanted to avoid having other composer dependencies in other places of our project. So that's why I took this approach. But I did find that if in the default location for the vendor dependencies, it was hard to get at templates and things. So that's why in this case, copying them to a library's directory in the theme. So it's just kind of part of the process when we pull in the new dependency. For future versions of pattern lab, the node version of pattern lab going forward might take a different approach because the node dependencies would be separate from our project level composer dependencies. But this is what we did in this project and it worked nicely. So now that allows us to require the design system as a dependency, so we can go composer require and require our design system. For the pre-launch cycle, we required it at dev because things were kind of moving fast. And then we can run composer update when we want to consume new changes from the design system. So on the Drupal side, we have control over that. We can decide when we want to bring in new things. We tag major releases in the design system. We often did still just require things at head, but it was helpful to be able to lock at a specific release or roll back to certain releases at different points in the process. So it gives you some control there. And then incorporate it into the theme. Really pretty common straightforward stuff here, but the compiled assets are in a global library. So we have our compiled CSS file, a couple of JavaScript bundles. So that stuff is available to our theme now. And then using the components module to find a few twig namespaces, a little images shortcut for some image assets that we're using in a handful of different places. And then the kind of different levels of our design system, not the default atomic design naming, but in the neighborhood. So now that stuff is available to our theme. So an interesting workflow that we kind of fell into working on the project. We had Sean who, who can Drupal, but definitely as someone who is the most efficient, just writing good CSS, JavaScript and HTML that's CMS agnostic. So he built out the majority of our remaining components in the design system and only had two commits in the Drupal repository, but he was at the end of the day responsible for the bulk of our theme. And then Wade was kind of the middleman handling the component integration. So he was wiring the design system components, doing the mapping, adding them to layouts. The bulk of his effort was in the Drupal repository, but sometimes he would make changes in the design system if it's maybe something that Drupal needed that wasn't accounted for or situations where it could make his life a little bit easier. So that, in general, that split worked pretty nicely, we found. And then as often happens in projects, there were some interesting bumps along the way, some changes in scope that having this design system as an external dependency opened up some interesting options. So there was the Lunametric site. They offer like analytics trainings throughout the country and they have a place where you can go register for trainings and sign up. And it was determined that in the time frame that we had, we weren't going to be able to rebuild the training section of the site, especially because they added some new functionality and new integrations and we'd basically be just like dumping it and rebuilding it again. But since we had this design system, I don't even know that we would have been able to consider this otherwise. We determined that we were gonna attempt to keep just the training section of their WordPress site alive, but have it match the look and feel of the rest of our Drupal 8 build. So for the actual WordPress integration, we worked with a company, Wildia Creative, and they handled the original build of the Lunametric site and were available to help us reskin it, which was great, because we needed some extra hands at that point. And they also introduced me to the Timber plugin, which I had never heard of before, which makes it possible to use twig in WordPress. They're slogan, because WordPress is awesome, but the loop isn't. Yep, yeah. Continue cheering from the crowd. Timber is awesome. Yes, I agree. So they created an initial prototype using Timber and our design system and used all the components with their twig templates in place and it allowed them to kind of get a prototype up and running quickly and kind of prove out that it was gonna be possible to do this reskin in the time that we had. Leading up to the launch, especially like trying to hit our timeline, there was a little bit less of the Timber use and a little bit more traditional theming that kind of happened and we'll revisit that later. But this is just a simple example of what it might look like. So on our training page, we have a list of upcoming trainings, an individual like training items stacked on top of each other here. So looking at some of the templates in the WordPress code base, we've got this training module, PHP, a wrapping div with some classes in it and then a for loop that just assembles the data that we wanna pass into this component so we get our training element. It's not unlike a render array or some of the mapping that we might do in a twig template in a Drupal presenter template. And then the training element PHP template is just going to render the template from our design system with the data that was made available to this template. So we just render the twig templates and we get the same training item as we would expect. Pretty nice. So we at the end of the day get a training section still on the WordPress site but incorporate it into the main menu on our Drupal site that has the exact same look and feel using a lot of the same assets all together. And then very close to launch, we also find out that we would be having some other new friends join our company, DMACC Media in Canada. And their site was gonna be rebranded as Bounteous.ca because of the timeline and for some other reasons, it was definitely going to be a bit of a smaller scale site. And it was acknowledged that some of the look and feel was gonna be different but hopefully in the same neighborhood. But still having this design system really changed the conversation. We had our first call to kind of get our developers together and I was able to say we have this design system repository, give you access to it. Here's what assets are available, what tools are in there. And there's a pattern lab instance and they were able to use it how they saw fit. So they reused some important assets, some of the SVG backgrounds and things like that and kind of were picking and choosing more a la carte different classes and structure and things like that. But again, allowed them to skin this site really quickly. So we did it. We made our intended, I guess it was, I think it was November 5th launch date and we had all of our sites under the bounteous look and feel using the design system. Everybody took a nap and then we move on post launch. So I was kind of transitioning off of the day to day and other developers were coming on to help out and maintain. Kyle and Steve were some folks who were involved early on and so at this point the WordPress sites are definitely changing less, a little bit more of just a maintenance thing. And the new functionality and the new tickets are definitely focused on new things on the Drupal 8 site. So for new people coming on board, especially their day to day is Drupal, putting words in their mouths a little bit but I think there was a little bit of the feeling of why can't I just Drupal? Why do I have to make my commits in the design system and pull that dependency down? And again, I expect to just be able to look in the theme there. So some lessons learned from that is that the documentation is important. I had documentation in the read me, some stuff on Confluence, but I think a thing that was missed that could have helped was getting into the why even in the documentation a little bit beyond just the how. So explaining what some of the advantages are, why we took this approach and potentially even some of the disadvantages. I think that would have made it a little bit easier for people to come on board. And then one thing that I was able to take on before people started rolling on and off was improving the workflow a little bit. So now that we were making smaller scale changes and a little bit more focused on Drupal, we just need to improve the workflow so it was easier to experiment inside of Drupal without having to make commits in the design system first and pull them down to take a look at it. So nothing really all that complicated here, but some gulp tasks that just made that a little bit easier to experiment, see how things looked in Drupal, and then commit that back to the design system and pull it in the traditional build process. But it does definitely add some overhead. There's potentially a cost here. And then also, and while this was a challenge in some cases, it definitely is a positive one from my perspective. The lines between the CMSs started to blur a little bit here. So like we changed the hover style for those training items that we saw before and people would expect that to appear in both places and you make that change once and it would just work everywhere. But the training site was in WordPress and as I mentioned, there were some cases where we took a little bit more of a traditional approach to be able to get things out the door. So Chris was working on QA and John our kind of marketing lead guy who also is a nail quotes because he gets his hands dirty on the WordPress site secretly sometimes. Sold them out on this talk, but. So yeah, they expected the change to apply everywhere. So what we did following the pressure of the launch is load on more of the timber approach made it a little bit easier to pull in the assets and dependencies in the design system in the WordPress site as well. So you may be asking yourself at this point what approach you should take in the future. You probably know where this is going that there definitely is not a one size fits all opinion there, no real answer. But units might be different, right? This might definitely isn't gonna make sense for everybody. So the robot site, they did a great blog post on their recent rebuild and they have a podcast episode that goes into detail on it. And now I have a different company makeup and a different focus. They wanted to be able to have a group of amazing Drupal experts to be able to do as much traditional Drupal and take advantage of that experience as possible. So they tried to focus on using as much core and common contrived, et cetera. So for a case like little bat, maybe this approach doesn't make as much sense. And then other things to consider when trying to figure out where to put your mayo and mustard is if there's gonna be value in reusing these components. There are certainly gonna be situations where maybe they really aren't going to be used outside of this one particular build. But especially from this experience, sometimes it's hard to know for sure. I really didn't know that that was going to be as important as it was going into this project. And then again, the prototyping end of it. I think that having things separated and not quite as tied into the theme makes it a little bit easier and lower resistance to prototype. So can encourage that a little bit more. And then also potentially, if you're looking to publish your design system or a style guide independently, there are potentially some advantages from having that separate as well. And then there's also your general workflow and your team makeup to consider. So is this approach gonna fit nicely into your workflow or could it be easily adjusted to allow it? And then will it allow more people to contribute as well? And again, while it's not a once-it-size-fits-all solution, I think it did work nicely for us. And again, I'm hoping that going forward, it's gonna allow folks who can do great front-end work to contribute to our website, which I think is a good thing for our company. And yeah, pretty much it. One other thing to mention, a plugging a session, but also another thing that we're thinking about on a project that I'm working on right now is we have a progressively decoupled site and we have styles and even some components that are gonna be in common between Drupal and React, looking at ways that we can do this. So one thing that we've been looking at in the CSS and JS space is CSS modules. And that offers some interesting possibilities as far as being able to use the same partials that go into maybe a fully compiled style sheet that's used in Drupal, but can also be pulled in on a component-by-component basis in React. So that's definitely something that we're exploring that's pretty interesting. And John Albin has a talk tomorrow on his experience with CSS modules and an overview of some CSS and JS solutions. It's an interesting talk, so check it out. That is pretty much it. I cannot believe it, but I do have time for questions if anybody has questions. And if you don't, that's cool too. We made it to the end of the day. Hands in the back. If you guys could come up and use the mics, that would be amazing. Thank you. And I also want everyone to get exercise. Again, exercise. Okay, so it sounds like this method of making your pattern library and external dependency is really excellent if you're sharing a pattern library between multiple projects, yes? Yes. And perhaps less useful if you're not. In general, yes. Yeah, I mean the comment was that it's more useful if it's a design system shared between projects and less useful if it's not. That is true. There are still potentially some advantages and conceptually it feels like the right thing, but there's overhead, yeah. Okay, thank you very much. You're welcome. Great talk. Thanks. What would you do differently? If you were to start in hindsight after going through all of the stuff in practice, start from scratch, brand new project, clean slate, what would you do differently? Or where do you see this kind of going next? That is an awesome question. I think that, again, timelines make it hard, but I would have tried to get everyone to stick to our guns a little bit more on the WordPress side and really use the same components as much as we can. So we didn't have to refactor that afterwards. And in general, I do think we found a really nice kind of workflow, but we had to kind of discover it with our particular team makeup. So something that still is always a pain point for me is the right way to handle the integration and the mapping between the design system and Drupal. And there's a lot of ways to do it, but it's always a little bit of feeling around in the dark still for us. And the more that could be kind of a lockdown approach and the more tools that could help us with that, the better. So I think there's a lot of opportunity there too. I agree. Awesome, thanks. We're working on a site where the client needs to see the pattern lab instance, maybe in a URL. Did you come across that type of use case and do you have suggestions for how to get an instance of the pattern lab within a URL for the search? Yeah, so the question was that they have a project where they wanna be able to see an instance of the pattern lab online somewhere where people can see it. There's a handful of ways to do that. Pattern lab can be used as essentially a static site generator to create a static build of the pattern lab that you can then pretty much host anywhere. So if you have a place that can host the static build of pattern lab, you can put it up on there, that you could put it on something like GitHub Pages if you need to do. Alternatively, in the case where you do embed pattern lab in a Drupal theme, if that makes sense for your project, you can actually access it there potentially because it's in your theme as well. So that's another potential approach. But it can build for you the static version of pattern lab and you can host it pretty much anywhere. Yes, that was our reason for embedding pattern lab. But as I'm rethinking it, I'm wondering if we can have it externally but also have it as part of the build process within the site URL. Yeah, it definitely should be possible. I mean, it kinda depends a little bit on the rest of your build process but it should be doable. Okay, thank you. Hey, talk. Thanks. Appreciate the topics. How were you handling releases, release notes, versions, like hey, you know, because there's a lot about being like, hey, let's launch it, but then what happens after? Yep. And so I'd like to hear some of the things that you did and also a little bit of things that you wish you did as well. Yeah, I mean, the honest answer is that however you're handling releases and versions is not as well as we should have. So that's kind of a big gap. And we were still tagging releases but definitely were not as formal with consuming them and the design system itself mostly kind of served as the documentation so we didn't have like good patch notes or anything. I would say in general that that's probably an area of failure for us and I think we just need to be more rigid about it. We need to tag releases and it's fine to have a lot of releases and be a little bit more strict about what gets pulled in on the Drupal side as a dependency. So I really have a great answer to that but I agree that it's important. Yeah, great. And then a second question. With Timber, any kind of gotchas that you came across that you wanna share? Yeah, I mean not a ton. So one thing that I ran into is that the Timber module, they made some major updates recently and are basically like stay on the old version. We're kind of fine by the seat of our pants on the new one. They actually disabled the update link in the plugins page. So mostly that but aside from that I found it pretty easy and reliable. That's great to hear. Awesome. Thanks for sharing. Thanks. Cool. Those are some awesome questions. Thanks everybody. Yeah, stick with us. Everybody get some stickers.