Your Component Library is Not a Design System

>> All right, cool. Hello, everybody. Welcome to your component library is not a design system. And let's get started. I'm Evan Willhite, based out of Nashville, Tennessee. Four kitchens is contributed, so we're all across the U.S. And I'm the project lead. 

>> And I am Brian Lewis. I'm a frontend engineer, I live in Wichita, Kansas, and I am also the project co‑lead. 

>> All right. So when it comes to design systems these days, words are definitely hard. We are in the midst of a period of time where terms are actually being defined in public consciousness, similar to a decade ago with responsive design. Folks in the design system space literally have glossary sections on their websites. That doesn't mean we can't talk about it. So let's get some terminology out of the way. 

 What do we mean when we talk about a component library? At FourKitchens, we use the term for this part of the design system, because it signifies to the widest audience what this piece is. But for developers, a better description might be project scaffolding. Because what we're referring to as a component library is more than a group of organized components. It's also a UI workshop for building and sharing them and a build system to process, stream, minify, etc. Let's take a look at the three pieces in the new emulsify. If you are familiar with Emulsify's history, you may wonder why these tools. So these are just massively popular and well supported products. Also rich eco‑systems. Just incredibly deep. 

 And then of course they use each other. So we had an interest from the beginning in trying to keep the tools as minimal and expendable as possible. So that's a benefit. Finally there's the components themselves. And FourKitchens is deeply invested in Drupal. So in fact, there is a starter kit project that packages these three pieces together. This is what replaces the old Emulsify. This is similar to that. But here's the cool part. Because of this new tool kit, we have opened ourselves to enormous other possibilities. So the frontend landscape is growing, and we all know it. Even within the Drupal community, there is a massive focus on flexibility of tooling, particularly on the frontend. And because of this choice of storybook and webpack, we get support for all of these and more that I haven't listed here. This is not limited to re‑Act, angular, html5. And because of our first‑class twig support, WordPress using the plugin. 

 So wow. Now that we have the component side well in hand, what's left to talk about? Oh yeah, design systems. So component libraries equal happy developers, or if you're lucky, a happy production team where designers and developers are on the same page. What we have found is no amount of component‑driven development, shared tooling, or UI workshops can guarantee long‑term success by only making one team happy. Long‑term success requires full buy‑in from all teams across an organization. It requires buy‑in from content strategy. From UX, a team that also cares about how and where components are used as well as whether those components are meeting their success criteria. From accessibility and compliance. Testing and Q&A, the team who fights for component usage to be documented well and components to be versioned. POs and PMs, project managers and product owners, the stewards. And then of course marketing, the ones who decide where the project fits into the big picture, those with the highest vision of organizational success. These are the audiences of a successful design system. All of these teams have to have buy‑in. 

 This is why component library is not a design system. So what is a design system? Let's start by imagining an organization. So FourKitchens does a lot of work in higher education. Allow me to introduce you to the totally not fake western university of Pennsylvania. It is fake. This is a prestigious university who in its rich 300 plus year history has risen. They have a strong core brand identity, one that must be shared and upheld by its many schools. Schools like studio arts. And of course you can imagine there are a number of other schools as well in an organization this size and obviously we can't spend all of our time making fake logos. So let's talk about the organizational needs. What are the needs of a top‑level organization? Here are a few. Brand consistency. So a clear identity. The ability to tell everyone in the organization how to tell the story across all products is documentation. The organization's web property or properties, because there may be multiple, including internal. And then of course cost. They are interested in keeping costs down across the entire organization and their subproperties. And then more than ever, there is a vested interest in guaranteeing accessibility across the entire organization. 

 So what about property needs? Likely they will need their own unique brand identity and their own web property, but they will also be interested in staying within their own budget and in maintaining the organization's brand consistency in general. So a good design system not only speaks to multiple audiences, it addresses both of these levels, the top level organization, and all of its individual properties. So let's take a look at the key ingredients to a design system that will address these various needs. So a good design system starts with a living style guide. And unfortunately, this is one of those terms that requires definition these days. By a style guide, I mean this is not a component library. Not storybook or patternlab or something like that. Those are what Brad Frost calls the workshop, and here is what he refers to as the store front. The style guide is the source for all teams to document what he defines well as the official story of how your organization designs and builds digital products. So the style guide contains that story and we'll speak to this in more detail here in a minute. And next, a good design system obviously also includes the component libraries like we just talked about, likely at multiple levels, the global organizational level and for properties as well. And finally it involves a smart, cost‑effective work flow. It involves sharing what needs to be shared and aligning efforts across all of those teams. Just to give an example, if a new component is created and blessed by the production team, its usage may still need to be documented by content strategy. And then its success measured by the user experience team and testing run by a Q&A team. Not only do you need technical work flows, but also organizational work flows for how to distribute that. So let's dig into these three columns further. And let's use our client, western university of Pennsylvania, as an example. So they need a style guide to document things like branding, colors, accessibility, typography and voice and tone. That documentation will include components, but not just components in code, but also content for a variety of audiences like instructions around component variations, when to use them, their look and feel, and any assets related to that component. And also, and this is key, this piece has to be easy to find, easy to digest, and easy to update. And so now that we're familiar with component libraries, let's talk about what is required at this design system level. So at this level, we need the ability to create components that are global and they can be used across all projects. That way we can reap all the benefits of component driven development except scaled across a variety of projects. So benefits like a single source of truth for each component. You can see on the slide here, we have a global component library in the documentation, reused components, and property components this is what we're talking about. And all of these will have build systems and tooling to help quickly build and iterate projects while getting the benefits of maintaining organizational consistency around things like branding and accessibility, things that I talked about earlier. This also means the tooling will have to be flexible enough to support a variety of languages and techniques. So you can imagine an organization's property may be built using Drupal. So let's say for Western University, their main property is built using Drupal and has a traditional Twig frontend, but they may have other properties that use things from WordPress to React and more. On the technical side, we need to be able to document the same components in the style guide that are being used in properties. So carrying that concept that we've always had in Emulsify in having aauthoritative living representations of your components. And this across all properties supporting a variety of languages. This is going to mean we need managing and versioning of packages. So work flows for updating documentation and updating across languages. And for notifying teams when those updates occur. These three things are the key ingredients to a design system. So component libraries shared across well‑defined workflows and documented in an authoritative style guide. And this is the Emulsify design system. A style guide generated built as a Gatsby theme. For components, the style guide has built‑in support for viewing storybook components and built in code block components for code and syntax highlighting. Also, it is extremely customizable via the Gatsby theming. We will show you this in the demo. And then of course the component library is powered via Storybook. And because of the flexible tooling, the work flow can come from powering an organization's component library via packages to a properties component library. So this is like our school of arts property. Their component library using a combination, maybe, of shared packages. 

 And so let's see ‑‑ I should mention, too, the kind of strength of all of this is built on webpack, and its ability to consume things from a variety of sources. It's at the heart of this workflow being able to share all of these things.  So let's see this in action. I'm going to stop sharing and pass it over to Brian. 

>> Can I get a verbal confirmation that you can see my slide as a demo? 

>> I see demo. 

>> Excellent. Thank you. In this example, we're going to walk through we have two web properties under the same organization that ewe uses shared organizational styles and components. The first is the western university of Pennsylvania and the second is the studio arts college. The arts prompt will use some of the organizational components but will also have custom components and styles that are not shared by the overall western U organization. So the first thing we did when we started this project is to create the components that would be shared by all of the western U properties. We created one repository for twig components and a second for the SaaS files. If your organization only has one property, you don't need to separate them out like this. Or if your organization is 100% standardized on Twig and SaaS, you can house them together. The reason we're demoing this with separate repositories is to show how one organization can have properties built with any technology and share the things they can. It can be a Drupal site and React app and if they are both configured with SaaS, they with both use it. So the point is the pipeline is flexible to meet any organization's needs. So here is what a section of our repositories look like. On the left we have the western U twig repository and on the right you will see the SaaS repository. We have chosen to structure chemoin an atomic structure. You see the colors here and the event card here. You will notice that the SaaS repo doesn't mirror the structure exactly because we didn't find it necessary to create folders that we knew would only contain one file each. It is flexible and you can organize these however makes the most sense for your team. In a twig repo, there is always at least two, like the twig and the yml, so we went ahead and put those in folders. 

 Now once those organizational repositories were created, we published them to NPMs so any current or future property could use them. Similarly yarn ad, and they are immediately ready to use. So this is the main Western U website. It's going to use the organizational components with no customization. The only file we have is a SaaS file that just says to import the main style of that SaaS file from the Western hub module. So this gives all the styles from the organizational repo. And you will actually see a comment that says we could import just the SaaS files we need like the colors and buttons, for example, but in this case, we do want everything, so we're just going to keep it simple. 

 And one quick thing to note is when you're developing the initial organizational components, we wanted to work with these various packages but maintain our UI library workflow and storybook. We had to use a yarn or NPM link. Lerna is also an option. But they were able to handle the files with hot reloading to meet expectations o6 a traditional development workflow. We will not get into detail on how to set them up because they're each different. Your team can decide what to use, but those are examples of tools that we found helpful to work with. 

 So the SaaS file in our components directory is pulling in the styles from the node module, but what about components? We need to set up configuration in two files to make this work. One for storybook and one for Drupal.  So this is the web pack config file for storybook, and on line 35, you will see a twig section. If we zoo in on that, you will see settings in name spaces. So atom points to ‑‑ in the node modules directory. This tells storybook where to look for templates when we type something. Drupal needs to know that. So in our yml file here, we are configuring the name spaces for the components module. We're pointing directly to the node module that we have installed. So here is an example of our component library. We we decided to separate our gray scale from branding colors. Here is an example of news cards in a grid. And our example home page. You will see the storybook Chrome on the left side bar and the top, if you're not familiar with that. And the add‑ones bar at the bottom. If you want to see it without it, just like the old version of Emulsify, you can open in separate windows without the Chrome so you can see the whole screen. On the top, we have a nice clean hero with a page title over the image. Scroll down and you will start to see the news cards. For some odd reason we put news cards in the event section, be we were moving quickly to get this together. You will probably notice a lot of little things like that. And then we have a big, beautiful CTA at the bottom and in the footer. That's the home page of the main Western U property. 

 I want to show you one more page, and that's the content type. Our arts property, a different website, is actually going to use all of these components and styles out of the box showing that 100% consistency between properties is possible because they're sharing the exact same code through packaged components. 

 So if we open this up, you will see that there's the page title. There's the image and text, the side bar has a basic CTA and an upcoming events list. There's a basic card grid a little further down. And finally the CTA in the body and then the footer. So, so far we have just been looking at the component library with static content. Let's switch over to the Drupal site now and see how things compare. Here's the home page. You can see the same big hero at the top, the text with image paragraph, the upcoming events section using news cards and the home page CTA at the bottom right before the footer. So here they are side by side. On the left we have the component library example with static content and on the right side is the Drupal site with dynamic content. I put the same text and images in to show that they can be 100% identical. The Drupal site looks a little smaller because we have the Admin tool bar visible at the top. If I were to log out, they would be 100% identical, but that wouldn't be a good visual for showing differences. And here is the full article page. I'm going to let Evan talk about the style guide part of this.  I will keep sharing my screen, but go ahead, Evan. 

>> As we mentioned before, the style guide is powered by the Emulsify Gatsby theme. It produces a style guide quickly. But the tooling also makes it easy to quickly customize. So we built this custom Western University one in a couple of hours. It was very crucial that this be fully customizable. There are many solutions out there for producing something like a style guide and storybook has one for documenting components inside of the storybook UI. But when you're inside of that UI, it is not able to speak to a variety of audiences. It is geared towards a specific team. So it was important that we had something that was its own customizable website. So we ended up going this route. You can see it has all the typical style guide. This is us building off of the Gatsby theme, but producing a unique one for Western University. Here is an example of a logo page. MDX is basically mark‑down but it has the ability to place JS elements and React elements inside. It has super powers that I will show you in a second. One of those perks, so here is a different page showing the colors. One of those perks is something called short codes, which if you're familiar with WordPress and things like that is taken from other places. But the short code, the dark section above is an example in our Gatsby theme is built in and gives you the ability to highlight that section. 

 And here is an example of that short code usage in an mdx file. You can imagine a mark‑down file that contains your traditional elements. It's as simple as knowing the short codes, which we document in the theme, obviously, and then just wrapping whatever content you want with that DarkWrapper short code. So whatever gets placed in there gets highlighted in your content region. 

 And also because we leveraged the theme UI tool, which I have linked to on the side. The theme UI is very vague, so I felt the need to explain what that was. I'm not going to go into detail, but you can check it out. This was a tool built with Gatsby themes in mind, but it can be used in a variety of situations, not just a Gatsby tool. It's a library for creating reusable interfaces. From that, we not only get this API‑based theming which allows for very quick overrides from everything from colors to typography to component styles. That's all via just a local config file.  So you kind of define those things in config at the theme‑level, which is something that is if you're not familiar with Gatsby themes, that's like a dependency that you install. And you build this in your own project. You can create a local config file that overrides those so you can easily and quickly add a look and feel to your project just in that method. But also a nice part of that is we get support for modes built in. So you can see here I have clicked on the dark mode button in the top right and we have nice dark mode styles, and that is based on the colors defined in that theme. 

 And then of course here's a component page. So the buttons you see here are actually being pulled in via storybook component short code. And that's from our storybook. And you can control where your storybook instance is coming from in your Gatsby config file. You just pass in that URL for the iframe and that's documented in there and it will serve your components from that authoritative source. These are the live components from the component library being pulled directly into our style guide. So this requires just the idea. Thankfully storybook uses a nice, memorizable way. If you're used to writing in storybook, you will see this is just the name of the section and then ‑‑the name of the component. We have atoms and then buttons under that. That is readily available in the storybook URL. And then also in the short code, we add the ability for you to pass a specific type. And that's just to make the high frame look nice. 

 And then below that component we have our code block. And that has built‑in syntax highlighting. This just works in the typical way of writing markdown. So you just surround your content with back ticks, and the syntax highlighting library gets used. 

 And here is another example of a component page. Notice we have kept the storybook component and the code block pieces separate. That was intentional so you can organize your content anyway you want. You can have pages with just the component display and content or pages with just code blocks. Here we have a component page with a display. That call to action is sort of a component. And then some markdown in between and then a code block. So you can organize your content however you would like. Because of Gatsby's fantastic tooling and pipeline we are able to swap the syntax highlighting when in dark mode. And finally you noticed there are tabs on the components pages. This allows you to organize the pages into sections. And the way that you do that in your markdown files is very simple. There's yml tags that you are used to using if you are writing markdown. There's one for tab and one for tab order to put it in the order that you would like. So that is a brief look at the Emulsify style guide, specifically the western university style guide. We will give you a repo at the end. 

>> All right. So that was the style guide portion. Went through the storybook for the main website. But now let's dive into the studio arts property. This is probably what I'm most excited about with the new Emulsify, because we have never been able to do something like this before. This is the college of western U organization that should share components with the organization's main property, but also because it's an arts college, they want to have some visual flexibility through new components or by customizing the organizational ones. Since we do want to have access, we run the exact same command we ran for the first property. The main property's components directory was pretty bare if you remember, just the one SaaS file. In this case, we have a number of custom components that are specific to the arts type. We have directories for molecules, organisms, templates, and pages. We're using all of the default button components and styles as well as other atoms, so we don't need an atoms directory here. This keeps the properties repository super clean and easy to navigate. There's no duplication of the organization's components and styles. We only have to worry about the code that is custom to this property. And since these components are specific to the property, we're putting the twig, SaaS, JavaScript, yml files right next to each other. This is the same methodology that other component‑driven development tools use. The webpack config for the site is a little different. Now we want to pull in from the node module as well as custom ones. It's simple 20 do so. We add additional name spaces. Organisms is pointing to the node modules directory while the next one is pointing to the components directory for this property for western arts. This means I can call any component from either location at any time. I just use the regular organism name space to pull from the organizational's component or wa_to pull from the next. You can create unlimited name spaces. So depending on how you want to structure it, you may have more, like a campaign related that has all of your splashy ones that more than one site will use but not necessarily all of them. The possibilities here are endless. This is Drupal's yml file, and storybook and Drupal both know what to do. 

 So here is an example of the western arts article for the main arts site. It uses molecules from the properties components. They are prefixed with wa_. And then there's an organism from the organization site. Too many org words. 

 In Drupal, you can call up the component you need when and where you need it. You can see the art quote paragraph type is using the component from the arts property and the card is using the organization's basic card component, both on the same site. Back in the component library, the fact that the western arts component library can show exactly what is helpful to its users. In this case, we're not showing any atoms components because we're not customizing them. We decided in this case, it would just be clutter. It can go to the other storybook instance or better yet, use the style guide as a reference. 

 I did throw in the article from the main organization just to show how this would work. And in the code base, we just had a template for the WA article, but in the story's js file we are telling it to show the organization's article as well. We will set up the content type on the main site to look and function identical to the main organization's article. But we're also going to have a custom WA article that had a different look and feel for different use cases. So here's a content hero that's custom to the Arts property. And the example home page with the big splashy hero and then you will see the content hero a little further down. We also had to create a new layout for this property. It was designed edge to edge with no padding or margin. All of our other pages have some sort of minimal padding, but our designer, being he is on this call, he wanted something very different for this site, because he's artsy‑fartsy. Here is a couple of pages in Drupal that show everything we looked at. The home page on the left is made of entirely custom components specific to the arts property, while the article on the right is made up entirely of components from the organization's component repo. Again, still on the same site, though. 

 This last page is a fully built‑out WA article in Drupal. If you are familiar with this organization's components, you would realize that everything on the top of the page is custom to the arts property except the last item on the page, the card grid. If you break this down, you will see the code I referenced earlier that the art quote is coming from the WA molecules name space, which is the properties components while each card as well as the grid itself is getting its mark up from the molecules name space, meaning the organization's components. 

 So this just goes to show how any property in your organization can be built with common or what we call organizational components and styles, their own completely custom components and styles, and/or a combination of both. With the new tool chain you are given everything you need to work in a way that makes the most sense for your project and your organization. 

 That's the end of our demo, but we do have a few common questions we have heard so far and expect to hear more, so we will answer a few of those real quick. One, the first is can I have multiple style guides. Evan, do you want to speak to this? 

>> Just had to find the unmute button. The Gatsby theme is just a dependency that they created themes literally to be a match for plugins. It's like the UI plugin that gives you styling and functionality, whatever you want to pass. And it's just a dependency in your project. And you design and build on top of that. You can have a style guide per property, but the interest of the style guide is a larger conversation than a UI library. A UI library is almost immediately used on a project, but remember that style guides must be maintained. Someone has to create the content for them. And typically only larger organizations and properties have the teams to maintain these well. I'm assuming I'm probably speaking to an audience of people similar to Brian and I who are providing development. We would not be the ones who populate the content. It's key that an organization knows how to maintain and support the style guide. 

>> The next question we're sure people are asking is where can we see this code and demos? Are they live somewhere? We're actually going to have these live somewhere soon. The style guide will be available to view. For now you can clone these down and spin each up with a couple of commands. We can use the emulsify Gatsby theme. And although they share tool choices like web pack, they are installed and run separately based on project need. We do have some pretty good documentation for this. We have some getting started help and installation instructions, things like that. 

>> There is also an upgrade path for the old emulsify. 

>> And what's the current state of the project? So, both are actually available and usable in projects right now. So emulsify Drupal is soon to be released in beta. We're actually using this in projects now. Emulsify style guide is in alpha and we hope to release beta in the next couple of months, but it is usable. If you have any feedback for this session, we love feedback. We would love to hear from you. Go to mid.camp/6296 to let us know what you thought about this. Don't forget contribution day is Saturday 10 to 4 p.m. You don't have to know code to give back. We have new contributor training from 10:00 a.m. to 12:00. We are, after this is done, because we are just about out of time, be hosting a virtual booth. So you can come talk to us. I will post this in the Slack channel and chat in a second. If you go to this Zoom link, Evan and I will be there to hang out since we don't have a physical booth that we will be standing out. We will be there where you can approach us digitally. And I think that's it. Do we have any questions? 

>> We have one in here in the chat, which I guess we can use that for anybody who has questions. Go ahead and throw them into the chat. One is assuming you are supporting Drupal 8 sites, would you still decide to go with Store Irybook, webpack and NPM? My answer is yes. 

 I think part of it is to remember that this is a front‑end workflow. And so we were always like split and fractured. In the old emulsify, we had the old Php‑based thing, which they are moving to node as well. And we had the gulp pipeline to do our build. All frontend workflows are node‑based. So that split was part of the conversation of how do we get rid of this split? And really the only wall, so to speak, is the move from Twig, to twig.js. So what we have found with that is that it has been just sort of bumps along the way have been very minimal. We were committed as a company and as an organization knowing that that was sort of going to make the front‑end work flow the right way committed to helping with that tool. So helping with the twig.js eco‑system. So yeah. We have not hit many bumps with that. It is a little bit different. We have run into some things and we have tried to document those in some of our components. Bordering is something you have to think about. Apparently js, the way it parses a file is a little bit more ordered. That is getting a little bit into the weeds. 

 What is the cat's name? This is actually a virtual background. So this is a fake ‑‑ I'm just kidding. That's Bug. JuneBug. We call her Bug. Great question. Great question. Do we have any others? 

>> At least we got the most important one about the cat. 

>> Yeah. It's critical. 

>> Cool! If there aren't any more questions, we can certainly wrap up. They will be in the virtual booth. We have got to wait for another question. So we can get to that. And then also another way that some other rooms have been handling follow‑up questions, there is a room in the Slack, the Midcamp Slack with the same number as this room. And we can post follow‑up questions there. But the question is when is the video available? I can take that one. The process is a little bit different as far as how we're saving videos.  So we're trying to get those up as soon as we can. We already have some from yesterday. But it's probably going to vary on a session‑by‑session basis. Hopefully in the next few days. And we did have another question from Tyler. Is storybook a replacement for pattern lab? 

>> Short answer is yes. You can do everything you can do in pattern lab in storybook. That's the tool we decided to use because of the eco‑system around it. Because of all of the storybook add‑ones and plugins that are available. There are plugins for everything. So you can completely customize it however you want. You can theme the storybook UI if you wanted to. It's all very flexible. It's a little more flexible than pattern lab in my experience, because we can pick and choose what we show in there. Whereas in pattern lab, if there was a twig file, it was shown in the component library unless you did the underscore thing. But in this you can have as many components you want and just show only the components you want with the variations you want without having to do any hacks like that. 

>> Brian, we have some more questions. Do we still have time to take those? 

>> Yeah. We definitely have more time. And I've also learned that threatening to stop questions is the best way to get more questions to come in. 

>> Great. I think the next one is are there alternative systems and how do they compare? I'm assuming this is to the design system that we have spoken to as a whole. So the sort of the entire pipeline we have been talking about. We did not find ones that address this but we're addressing a variety of needs. The piece that we saw that was missing was the style guide piece. There are style guides available. They built it using Gatsby and open sourced it, so you can use their style guide. But their UI is free. So one of the key things that drove us down this road is the importance of the style guide to be designed to the organizational need. That's not just colors and look and feel. That could be the flexibility of putting a menu at the top versus on the left. That ‑‑ it's a much more highly designed tool than a UI library. We did not find a solution for that. That is the space we're trying to fill to say here's a Gatsby solution for this gap. And obviously we benefit from it ourselves when we use it with clients. 

>> Rebecca asked how do designers specifically use the design system in terms of design items? 

>> I can speak to this. It's funny you asked that. That's literally at the top of our list of to‑dos. And Gatsby has a plugin for it. It will probably be a matter of getting this in for just allowing files to be referenced in mark upand downloaded. There's to‑dos that we have. We are leaning on the eco‑system here. I don't remember the name of it. Sorry. I can probably look now. 

>> I think once you're asking is once we are creating a new property the designers ‑‑ I'm not a designer, so I'm going to be guessing here. But yes, I would imagine they would use the existing components as much as or when necessary. But like we saw with the art school, if there isn't a component that solves the need or the vision that the designer has, then they create a new one and that new property would have a custom component just like our arts school did. One other thing is that you can ‑‑ I briefly mentioned you can package things like campaign components or splash pages or event components. You could find out that on that law school, the designers created a new thing that they also want to use on other schools. What you could do is take that component and styles and mark upand package those into its own node module in the case of what we're doing and publish that. And then that school could just NPM install that package again as well as other schools could NPM install that and have that new shared component. Or it could be pushed upstream if we decide to use them on all sites. You can develop however you want. It can start up as a custom component for one property and then get pushed upstream to share. 

>> I can hop in on that question as well. One of the key things that we found. There is ‑‑ the design ‑‑ often audiences have different responses to a design system. So accessibility, for instance, is one of the most compelling arguments to the top level of the organization that you can build an accessible component and then everyone can leverage that. Because it's very important to them, to the compliance office that that happen now for legal reasons. But for the design teams ‑‑ they are looking at it and saying please don't hand me something that restricts me. So it was always important to us to build the ability to support any level of control. So you could literally build a property that uses just organization components. And that might be for cost effective reasons. It might be for accessibility relationships. You could build a property that uses just some of the styles and then overrides some. That's the fastest way to kind of use buttons, but your buttons are green and not blue. All the way down to complete control. And that's what Brian showed on the western arts is he used some from the org and built some that were completely custom.

>> There are things that I'm going to post. The Drupal twig Slack, Evan and I are both in there. I think there was a channel for storybook that we're in. You can find us. Ping either one of us in there. And that's ‑‑ we're just kind of always in there, so you can do that at any time. 

>> Excellent. All right. I think it sounds like we're running out. There are a bunch of great questions. Thanks Evan and Brian for the great presentation.  If people want to use their clap reaction or unmute and clap, feel free. But thanks again. 

>> Yeah. Thank you. 

[ Applause ]