 So, let's get this party started. So my name is Micah Godbolt, you'll see that name on slides and all over the place. I am the author of Frontend Architecture for Design Systems, book by O'Reilly. You can pick up a copy there at FEA.PUB, frontendarchitecture.PUB, sending right to the Amazon link. If you're really interested, tomorrow I think at 11-ish, I'm going to find the time exactly for that. I might actually be doing a book signing at the Drupal Association booth, I think it is. Again, I need to find out where exactly that is. But be given away some free copies there, signed copies, they're going to be collectible items. You might want to hold on to them. Alright, you can follow me on Twitter, I talk pretty much consistently and all the time about web development. It's kind of my water cooler. As well as I write and blog at Micah.Codes. You'll love going there. It's going to load fast because it's pretty much just an HTML file. It's rad. Alright, enjoy it and let's guide Han with the talk. This talk is called Roadrunner Rules or more of what you call guidelines of a design system. Hopefully you know that reference. Those are going to be the only two horrible puns of the entire talk. From here on, it's going to be cute pictures of my kids. I want to take a little bit of a tangent. We are going to talk about design systems. But as I kind of got this talk ready, I realized there's a lot of back story that I really want to get people filled in with. Why we're even building design systems in the first place. Let me talk to you about my daughter. Of course, every dad likes to talk to you about daughters. There's like three, four, five seats up here. Maybe raise your hand if you've got seats next to you so we can get people to sit in if you want. Wow, look at all that. Cool. Alright, she is four years old and she loves flowers. We all love flowers. Who doesn't like flowers? Don't raise your hand. I will point you out. When we go and look at flowers, she likes to talk to me about the flowers. She'll say things like, Daddy, can I have a flower? And if I don't respond within three seconds or so, it's like, Daddy, I want a flower! Kind of thing. No last really? Do you even have kids? This is like, anyway. And once you give her the flower, she's like, this flower looks beautiful. And it's the cutest thing in a melt your heart. Alright, let's move over to my son. His name is Reese. He is two years old. He likes flowers too. Slightly different way of communicating about them. When he sees a flower, he says, flower. When he really wants a flower and you're not giving it to him within like a half a second because he's two year old, flower! That's pretty much all I can say. And then when he sees a flower and it's beautifully loves it, he says, flower. That is his language. That is his understanding of the language. And what I was really curious was how are these things different? I mean, obviously one's a two year old, one's a four year old. But if we can break this down and see what really distinguishes the difference between two kids and their understanding of our language. Why does one talk in single words? Why does one talk in full sentences? And to do that, we can actually dive into linguistics to get a better understanding of that. Linguistics, if you don't know. And we'll see this definition a couple of times. Is a set of structural rules governing the composition of clauses, phrases and words in any given language. That is just the Wikipedia. I should have an attribution. My apologies, Wikipedia. But that is what linguistics is. It helps us to understand our verbal languages. Understand the rules around them that govern the composition of these clauses and phrases and words. Inside of linguistics, there's a couple different fields. These fields kind of research different areas and have these expertise in different areas. The first one is called phonology. Phonology, phonetics, you kind of get this thing. It's all about the sounds. Phonology is understanding the organization of sounds within a language. For instance, we have this concept of onset and rhyme. In a word like beauty, the first syllable is b with the onset, u as the actual rhyme. The second t, or t, sorry, for beauty, the onset is t and the rhyme is e. Combining those different phonemes together, his wife is a linguist, so he's nodding when I get it right. When combining these different phonemes together, you're actually able to create these syllables that we're actually speaking. It's just the understanding of these sounds. It's nothing to do with the actual meaning of what these things mean. That comes later in the next phase of study, which is called morphology. The idea of the structure and composition of words and how do we put these sounds together to create actual meaning from those sounds. Let's look at the word beauty full. There's actually two morphemes there. One's beauty, that is a noun. The second is full. That is a suffix that we use as an adjective to say something full, full of. Combining those together, we get beautiful, which is another adjective, a more meaningful adjective than the noun or the suffix might give you. That is morphology. That allows us to create words out of all of these sounds we've described in phonology. Third one, and I swear I'm going to get out past this eventually, is syntax. Syntax is the idea that we've got all these words now. These words have meaning, and that's great, but we need rules that actually govern the structure of these sentences. Let's look at this last sentence my daughter said. This flower looks beautiful. She says it pretty much daily. We can break that down into an article and a noun, as well as a verb and an adjective. And yes, that's an adjective, not an adverb. It took me a little bit of time to make sure that was right. So those two can then be also expressed as a noun phrase, as well as a verb phrase. We can split our sentence up into those two things. And when all put together, that creates one big sentence. So we've gone all the way from the onset and rhyme, trying to explain how we create the sounds, combine those together to actually create words, and then understanding the syntax of a language and how that allows us to create sentences and even paragraphs and further and further on with those words. So what in the world does linguistics have to do with design systems? I'm sure that's a question that everyone has, and I would love to answer it for you. But first, one other thing. It turns out that there's not, there's a lot of languages out there. And actually this original talk, I was going to dive into sign language and body language, even computer languages. It would take way too much time, I found out, so it got cut. But what we do want to talk about is another language that's extremely important for us to talk about, and that is visual language. And it turns out that visual language is just as valid of a language for us to study. And what if we were to do a study of visual language? What would we find when we study it? So the first thing I want to talk about is the, basically what is a visual language? Wikipedia again says it's a system of communication using visual elements. So system of communication, cool. Communication is a good word. IBM on their design language page explains it as a shared vocabulary for design. So again, we're talking about vocabulary. Here's more of these like linguistic words. It's a lot of fun. So not just, let's see. There's a lot of things in common between a verbal language and a visual language. For instance, they both have extremely common goal. The goals of both language is to communicate. Especially with a visual language, it communicates a couple things. It can communicate ideas, such as trying to convince authority and reliability, trust, all those good ones. As well as maybe trying to position your brand within an industry as leader in technology. So our visual language is trying to communicate this to every single viewer of our website. But it also wants to communicate intention. What am I supposed to be doing inside of this interactive web page? It's not just a visual. It's not just an image. So it communicates an intention, like click here. This is the navigation. This is what you should be doing. In this example of this beautiful website that I happen to work on, I'm a little biased. You can see this entire design is leading everyone towards that one button. They want everyone to go and click that button. The background image, the text, the entire layout, everything in the visual language says click me. I'm right here. That's what a visual language allows you to do. Inside of this chaos of an e-commerce site, we do have a really nice visual right in the center. We have a navigation to expose all the users right within context of the actual advertisement, which is 25% off. Something to draw the user in and push them forward through the navigation and get them going through the steps towards hopefully purchasing something. So not only do they have a common goal, but they also share a lot of common traits. The first one of those of being dialects. A dialect is like a regional or cultural difference between languages. In verbal languages, that's like the difference between use guys and y'all and whatever else you might use for that. Or you people, whatever you want to use. Alright, in a visual language, we have the exact same differences. Things like word length, information density, power colors. You can see this is an example of a website, it's a Japanese news website called NHK World. This is our English website. You can see the use of reds, blacks, white space, very like contained different pieces of content. Really simple navigation up at the top. Here's the same website in Japanese. It's a little bit different. You see a complete different information density. You see a completely different use of colors. You have a completely different color palette. If there is a palette, it's all over the place. Word length, of course, can make a huge difference. We deal with German words all the time and it's ridiculous what it does to a design. It destroys you. These differences, these dialects are apparent within our visual language, just as they are within our verbal language. We've got three seats up here, a couple others, if you want to try and find one, otherwise, hello. Another common trait is the notion of jargon. Jargon is a type of vocabulary specific to a group or an organization. That's kind of like us with Drupal. We have lots of jargony words, whether that's a node or a module or you name it. Tons of jargon. We've got that within visual as well. We've got these ideas, these visual concepts that seem to all pop up all within similar websites or similar applications. One I thought of really off the bat was the notion of a price quality matrix. You find this all over the place in just about any software as a service. They all look basically the same. There are these four or five columns or three columns, one of them bigger than the other because it's the one that you want everyone to purchase. You've got prices, you've got features. It's all laid out in one page and you click what you want and you move on forward through it. It's to the point now that if you go to a site and it doesn't have one of these, you're like, what are my options? What are the prices? I need this. This helps me understand this type of website and this type of service. It's a jargon within visual language. Click. Hey, sweet. Slang. I can probably guess that you know what this is going to be in visual language. In a verbal language, we use all sorts of slang all over the place. I've tried to think of good examples to give and I just humiliate myself every time I think of them. I'm going to jump to the visual. One of them is things like carousel language. With a carousel, we've got this language. We've got this idea of left and right arrows. When we see those, we know what to do. We click on them when we expect something to move or slide. We've got dots at the bottom of a navigation that we're like, oh, hey, there's three elements here because there's three dots and I can click on the first one. It goes to the first element. This is slang in our visual language. This helps us understand how to use these things. These are very specific to our industry and our language and the visual language. Last one up. You've seen these before. They're everywhere. As just as fast as they came in to Vogue and were used on every single website in the entire world, they're now going out of Vogue and there's new paradigms coming in for our visual languages. These ideas are slangs. These invented words that are words. Ideas that are used out of context in something else like a hamburger menu. It's like, where does that come from? We just use it and it gains meaning because of that. The other big thing that's common between the two is they can be broken down into smaller units. So we saw this with our verbal language that we had syntax, which explained how the words go together. We had morphology, which explained how the sounds go together or the words go together, make a word, sounds the word, yes. And then we have phonology, which explains even how we just make those sounds. We break it down to the smallest piece and we need to do the exact same thing in a visual language. So to do this, let's dive back into our example of linguistics and figure out if we were to take a linguistic study of visual language, how would we do that? So first up, we're going to start with phonology again. And again, this is the origination of our sounds. So in a verbal language, we have all these phonemes. Phonemes, right? Phenoms. I always say phenoms. I have no idea why. These phonemes, we ask ourselves, what are the phonemes of a visual language? We have things like layout, white space, balance, all those things that give us space within our visual language. We have typography, the weights, the scales, the typefaces. How are we expressing this information using typography? Because there's a lot there. Well, there are. There are entire talks just on this. Probably here at Drupalcon. Thirdly, iconography. Whether it's actually part of the interface or something just ornamental. The style, the usage, where these icons show up are all part of visual language and need to be consistent. Fourthly, we have color. Whether it be the palettes, tints, shades, how are you going to be using this within accessibility? The color is going to make a large impact upon how your design actually looks. And if people in the back are squinting, you can go to the bit.ly address at the bottom, bit.ly. Road dash, runner dash, rules. It's actually lowercase. I'm sorry. The font is all caps. I didn't think about that. You can go to the bottom of the slides if you need to see them a little bit better. And that's also the link to the session. So you can go and do your voting there as well. So to the bottom of the slides. Sorry. Squirrel. All right. Last thing on here, animation. So we're not building static pages. We're not building just these displays that people look at. We're building things that people interact with. When they interact with it, with their clicking, their moving, their changing, changing the order of things. They're interacting with our designs. And all interaction can benefit from animation. But how do you implement that animation? Is it slow? Is it fast? What kind of curves are you using? Where are you using it? Where's an appropriate place to use animation? Where's a completely inappropriate place to use animation? This is all part of our visual language as we build out our design systems. So now that we've got all of our phonemes figured out, I think I got it right. It's going to be horrible. It's one of those things that once you screw it up you just never feel confident about it again. So let's talk about morphology of visual language and what that actually means. So we can take all these phonemes and combine them back together to now start building out our words, building out our nouns, building out the verbs of our site. Because we definitely do. We have nouns. We have content. We have verbs. We have actions. So we're definitely building all these pieces out and we're using all these phonemes. So let's take a real simple example of an input and a submit button. First thing let's do, let's add some layout to them. Not a huge change, but a little patty and a little white space. We're good to go. It's going to get better, I guarantee. Add some typography. We've got all uppercase on the button. We've got a different font face. We've got different font sizes. So we've got some weight. We've got some style. This is starting to get closer to our brand. Next we can add on our icons, iconography. These are things that help the user understand what these buttons are used for. And the crazy circle thing is like say like a password strength indicator or something like that. Next is color. Obviously it's now starting to look like a brand that we actually have. Some consistent colors that can be used across the site. We've got good contrast, hopefully, between all of our pieces. And this is something that someone can see and read and interact with easily. Lastly, animation. One more layer on top. Something to give feedback that when you're typing into this form field, you know, things are starting to illuminate as your password is getting stronger and stronger. Submit button that after you click it and after the, you know, your back end is doing some work, it's giving the user an idea that something's happening. Just wait a minute. We'll get back to you with some kind of response. This is morphology of our visual language. Pulling all these pieces together, creating these nouns, these verbs, creating these pieces of meaning that allow us to express to our users what we need to express. So lastly, this little foray into into linguistics is the notion of syntax. So again, syntax is the structure of our sentences. And I definitely take this past just sentences, but the structure of our paragraphs, the structure of our entire chapters in our books. How did all these things get structured together? So let's take a look at how this is going to work. We've got currently a verb and a noun on our page. Let's go ahead and put those into an actual sentence. Something that tells the user like, hey, here's a place to enter content and here's a place to submit that content. But there's more context to that than just a sentence. We've got an entire paragraph that makes up this context. So our syntax says that these input and these buttons go in a larger context of a header that has more additional navigation as well as logos, and this is our syntax of how these things are placed together. And that again is part of a much larger syntax which explains how the entire pages are placed together, the content inside those, and how all those other phonemes and everything get put together to create our designs. And yes, I have cute kids. Thank you very much. Thank you kids for good placeholders. All right. Now, this might look really familiar and I know this guy's not as had like crazy because like, yeah, I've done this before and a lot of this, of us have done this before. This is Brad Frost's atomic design little gift that just explains this concept so simply. The thing is this has only been around for I should have done the math. When was this? A couple years. It's been about two, three, four years at the most. We've been studying languages for decades. We've been dissecting languages and breaking them down in the smallest pieces forever. This is not a new concept. And I know Brad will quickly say that I didn't invent anything new. I just put a good name on it and I made it in a way that people can understand it. And he made a gift. Gifts are good. That's why I made gifts too. It totally works. So let's jump back to that definition I had of linguistics. Set of structure rules governing the composition of clauses, phrases and words in any given natural language. Let's change that to visual language. So we take that same definition. It's not really linguistics anymore. At that point, it's a design system. So our design systems, what we're building is actually a study of the visual language that we're creating for our website properties. First, we're understanding how these pieces are placed together. How can we create this meaning? How can we create everything we need to express about our company? Then let's figure out how do we create a system that is able to define all of those rules. Define how the pieces are put together. Define how animation and fonts and colors work together to be able to express our buttons and our action and our interactions. That is what we want to do with design systems and that's what we need to actually get to design systems. So in studying or getting prepared for this, I asked around like, hey, what do people want to know about design systems? What kind of questions do you have? Of course, the first question was like, well, what is a design system? In your own words. And this guy's mostly trolling me because I know he knows, but it's a really great question. And it was interesting that he gave me the question on Twitter because I had a couple responses when I could write an extremely lengthy medium post. I could do like a big tweet storm of 20 tweets to explain my like, you know, manifesto on design systems. Or I could try and squeeze the whole thing into 140 characters minus his name which sounded like a really good challenge so I decided to go for it. So what I came up with was this. A design system is a set of rules and assets that define how to express everything a visual language needs to say. And the great thing about fitness and new tweet is I kind of had to just dumb it down to really simple terms. I'd use short words and I couldn't really expand on everything. And that actually allowed me to boil it down to its essence. Actually, I tweet a lot for like promotional things and whatnot but it's a great, great tool to get you good at your microcopy. Like under 140 characters get all the meaning in there, find ways to say it. It's a great, great learning lesson. So let's dive into this definition and see what all these pieces mean because there's a lot to unwrap here. That's another unwrap, is that a word? That's a sling. One of those more slings. Unpack. Thank you. I was close. All right. So let's talk about rules. What rules mean? One of the first things that we usually introduce into the design system is our methodologies. How are we building all these pieces, all these components? And there's a few leading methodologies right now you'll see floating around. One of them being and this, this is a horrible I should have tested this because you can't see that whatsoever. All right. So OO CSS, object-oriented CSS. And again, you can download these slides. The main two principles of that is separation of structure and skin and separation of container and content. So just one methodology allows us to explain how we're going to build this system. Another competing one is called SMACS Scalable and Modular Architecture for CSS. And that imposes some interesting structures in file system and explains how CSS cascades down through it. So again, what are you picking? How are you developing this thing? BEM, block element modifier. It's an approach for how you're writing your CSS selectors. Typically a flat CSS approach can often be combined with the two previous methodologies. But what you choose doesn't as much matter as choosing it and making sure that it's explained and described to your users so that everyone is using a consistent methodology. Those are some of the rules. Other rules that we run into are like rules of thumb. This is a way we do things. Something we can see and go, hey, we don't do it that way, please change it. And one of those is the single source of truth rule. The notion that everything on your page has a single source of truth, whether that is a template whether that is CSS. So in this case, that one is a little easier to read. We've got this section with a blog feed up at the top and there's an H1 at the top. There's also an H1 with title class inside the article. And we bring in some CSS that targets that blog feed H1. But the problem with that blog feed H1 is it's actually hitting both of our first ones. There it is. Thank you. So, this no longer has a oh, I'm sorry. And then we also have article.title. So this is specifically styling the title inside the article. But you see that title in the article no longer has a single source of truth. That's what I was getting to. It's getting styles from two different locations. Which means that when you update one like if you update and you only mean to change the blog feed each one, you now have both of them. So then you have to go into the article title and override that change that you did and it just gets to be a mess. And these are like two CSS properties. It gets much hairier than that. Kind of on the flip side this is the notion of a single responsibility principle. The fact that everything is built for one purpose alone. There's a couple ways you can implement this oftentimes. It's kind of built with utility classes that do one thing and do extremely well. I kind of go a different direction with that and that is a very simple use. There's one place it goes, one block that it goes into and that's the only place it ever goes. So you're not using that class which has styles applied to it in other contexts. So in this case we've got again our blog feed and we've got a headline class inside of that. We also have a footer with a headline class inside of it. That's bad news. Because when we style our headlines great. They both look the same. Our blog feed, our footer, our h2s are just wonderful. But our designer comes back and says hey we're changing things and our blog feed headline actually needs to be uppercase text now. You're like crap, well I can't do that without also affecting that one down below. So you might write something like this, blog feed, headline, text transform, uppercase piece of cake and I'm done, right? Except now you've broken your first rule of single source of truth. So all these things are these rules that you can apply to your system to make sure that things are consistent and you're building them up. The next one, and this is a hot topic, I'm sure is a notion of a flat CSS selector. A single selector for every single item on the page instead of, well I've probably written at some point where I've got like five different class names all strung together with like three additional elements put in there. This is no fun because when you need to go and override that with say like an active class or something like that it's even longer and all this just to apply a new color. So instead, if we're instead not doing that but we're just using flat selectors, we're able just to have one selector and then have another selector. We save a lot of space, we save a lot of mental strain, we don't have to worry about the placement within the DOM, these things are a lot more portable and a lot more usable. Some of our rules actually just have to do with with asset creation, not necessarily with code. So you might have something in your style guide or in your design system that explains how do you create icons? What is the template that we're using? What is the style that we're using? Is it mostly outlines? Is lots of fills? Is it gradients? How do we build these things to create a common consistency between our design system and within our design language? It's also like photography do's and don'ts like the different types of color, whether it's like you know a light hue or kind of a blue hue or the subjects of those photos. Given information like that to your users as they're creating content, it's going to help create a consistent look throughout your site. We also come to this concept of like these custom rules, areas where we're creating a design system or coming up with really great ideas, but none of them fit into these standard paradigms, these standard methodologies. We found ourselves, I was working on the red hat project, coming across, we had a pretty large list of these and we were mostly in my head and that's there's a problem with that because with these custom rules they really need to be visible, they need to be something that's agreed upon and they also need to be actionable. So if someone actually sees that and can say hey, I see this documentation says we're not doing stuff that way, here's how you should do it, that's a very valuable rule for your system. So we realize we need to get these things written down. We would need to figure out kind of how we want to do this. And around the same time, this is a couple of years ago, this started circling around Twitter, circulating around Twitter and it's this concept of the road runner rules which is where the name comes from if you're wondering. The theory goes because it's been disputed a couple times but I don't care, is that Chuck Jones wrote these rules. He said of rules that say things like the road runner cannot harm the KOD except for going beep beep and there's no dialogue ever, ever except for of course, beep beep. Now these are the rules that he passed along to his riders and to his animators. These are the rules that they use to create a consistent universe inside of the road runner universe. So these are the types of rules that I wanted to write. These are the rules that I want to pass off to my team so they knew the universe that we were trying to create. And these rules to this day have led us to create a very consistent set of components and layouts and various other pieces. So when you're creating the system, these rules are important. They need to be something that people can find, can be actioned upon and can see and point out and keep people accountable. Just google that. There's great ones on there. Like road runner. He's got to stay on the road, otherwise he's not a road runner. It's great. Alright, so our definition talked about rules but without, with just rules, you don't really have much for a website. That really doesn't build much. You need assets. So what are these assets and how do they work? So the first asset that's obviously the most important is HTML. We need markup. Now there's various ways that we actually provide this markup inside of a design system. One of those is being just static markup. I mean if you go to the bootstrap design system, that's basically what it is, you go and you copy and paste and you drop in your application and you change whatever word they had in those filler into whatever you need and you hit publish and you're done. So you take that markup, you drop it in and you go. Obviously there's some downsides to that because if I want to go back and change my markup, I am SOL. So we have moved only in Drupal into more of a template system. So we've got these template files. This big, huge, nasty thing is coming from comments.html.twig and as you can kind of see on this really washed out screen, we've got markup but we also have template variables, variables and logic. So we can pass data into these templates and we can render these templates different for every single set of data. And that's extremely valuable because that means now whenever we need to make a change, we need to go back and find all of the markup in the body field and go make some regex entire website to figure out what we need to change, we can change it in one template and go on from there. But there's still a challenge with this template because it relies on you understanding this template or relies on you knowing the values in this template, the values that are required, the values that will break the template if you don't put them in. What is a string? What is a whatever? So as a limitation of this, the next thing you could do is actually provide just an API to your component. Now the Lonely Planet people have put together what they call Rizos, they're a stock guy, they take stuff from Muppets apparently. And it's this notion of every single component has an API. It's a set of inputs that need to be passed in to create an output and there's a couple of examples right there. Here's the fun part is any idea what template is on the other side of that or what markup is on the other side of that? Do we care? No. Does the output look like it should? Yes. And with an API we start to see that the actual markup to the user is completely irrelevant. It's this API, it's giving us an interface into that design that's completely important. So we might have this interface into our design and then to decide completely change the templates out. We're not even using the same templates, not even using the values in the same way but that API doesn't change and we have the same output. And that's a very, very powerful place to be because it makes extremely easy to learn and extremely flexible. All right. Other types of assets, because I'm sure this is going long, are the idea of linked assets. So we are always going to need all the, like your HTML is linking to all these assets and somehow they need to ride along with your design system. Oftentimes that just means they get placed in the get and they're along with the project for the ride and when that gets deployed they're there and life is good and golden until you start committing CSS and hating yourself. You're like, why can't I do something better? All right. So if you're not doing this approach there are a few other ways to do it. At Red Hat we've actually completely pulled our design system out of our main repo partially because the merge requests and everything that we go through to get code into the Drupal repo is really stringent. And we want to like just merge stuff in and get stuff done and move forward. So having a separate repo we're able to do that much quicker, quicker and we're able to create releases to send out to our main application. And you can do that using things like Bower or NPM package these things up and create releases to get sent out to your applications. This is really great as well when you want to send these design systems out to multiple applications. So along with those linked assets we also have lots of build assets. These are assets that allow us to take uncompiled codes such as dash or JavaScript modules or whatever we're using as well as all the tasks that do all this work for us, whether it's deployment or linting or concatenation or whatever we're using. That's definitely going to be part of your design system, part of that deliverable that is inside that repo. There's obviously a lot of ways to do these. It could be something as simple as MPM script like MPM run my thing and it's done or you could wrap it up in something a bit more complex like grunt or gulp. And there's a lot of things these task runners can actually do for your design system. One of them which is extremely powerful is to be able to automate how we are going to present our design system which leads us directly into the notion of style guides. Most style guides are going to have some kind of task runner component that you can just automatically run your style guide with a grunt or gulp or MPM command. So the idea of a style guide is the notion of we want to be able to put our documentation and our rules and examples of our code all inside some living document. That's something that people can get to and read and to see basically what we've built and how we've built it. And there's a few examples of these. We all have probably heard of KSS node. I know there's been a lot of talks about it around here at Drupalcon. But also the idea there's no one called living style guide, no one called hologram. These are all kind of for the most part pretty free form that kind of give you like a dock block at the top of your CSS to be able to put comments in and notes in a way that's going to be ingested and turned into something that looks a lot nicer. So whether that is actual code samples or color examples or font samples here's all the different font sizes we have but any kind of company identity here's our logo, here's how you use our logo, here's our corporate colors here's like examples of how we write. All that kind of stuff can be inside of that style guide. Another type of deliverable that we might really often produce is a pattern library. A couple good examples of that is a new one out at Nodebase called Fractal and of course our ever famous and ever popular pattern lab. The notion of these are slightly different than our style guides. These aren't really just this free form place to be able to write stuff out. They're more of a place for us to explore and experience our design system. To be able to go in and see our components see our pieces, see what does this look like with different pieces of content inside of it? What does our page look like and how does that break down into smaller pieces? Let's explore the pieces that are actually in that system. These are typically generated directly from your templates. The system will go in, munch all your templates, create all these interfaces for you. Whereas with style guides we usually find those like copy and paste an example of your code in there. I just found out KSS does a great job with this allowing you to link to an actual asset so that's cool. That's a pattern library. Super valuable for prototyping a great deliverable to your client. But sometimes you just got to you know, roll your own. And then we can see that with Salesforce's Lightning Design System Rizzo creating their own application there. And at Red Hat we're like, you know, we're crazy let's just build our own. We call it pattern kit. It's actually a Sylex application that allows you to go to a path and it dynamically renders everything for you when you get there. And the great thing about it is it not just gives you a static template but allows you to then interact with the data. See like if I change, you know, that title to 20 lines of text, what does it actually look like? If I remove the title, what does it look like? So we needed to create something to meet our needs and we decided to obviously roll around. So the first half of a Design Subs definition was a set of rules and assets. But that's only half of the definition. And I think the second part of the definition is almost just as important if not more. A Design System defines how to express everything a visual language needs to say. And again, I kind of had to cram this in here but let me try and explain what this means. Our visual language wants to say a lot of stuff. We want to express lots of things to our user. Here is a wireframe that we were given several months ago at Red Hat. Lots of stuff that we wanted to express. There's news and events, features on security, resource libraries, related videos. We want to tell our user all of these things and we need a way in a Design System to be able to express those. Here's the actual design what it turned out with our using the visual language we had at Red Hat. We need to figure out a way that we can build this as simply as possible with the most reusable pieces. So let's see how we would break this thing down. Yay. Alright. So we've got a couple bands here. We call them bands because they're bands of content. The first thing we need is some kind of layout, some kind of container that's going to hold all of these things. We decide on a band layout that basically gives us a header, a body, and a footer. Places we can put content that's going to give us some good spacing and get back to our white space and layout. And then the body can hold multiple different layout styles. So you can have a gallery with five items per pieces or you can have a three up gallery like a 444 and a 12 column grid or really whatever kind of layout that you want to have. And then from there we start building components. Here's an image component which is not a logo component. This isn't an icon component or a small whatever. Sorry. This is just our image component. This is the exact same component we use anywhere in the site. If we want to have a big huge image of something on a site, this is the exact same component that we use. The component is flexible enough. You can't really see it but these things go, they're black and white until they hover over them. Our designers thought that was really cool. Something that's part of our component. That's an option you can turn on. You don't need a hover image to be able to make that work. That's just part of our component. So we see we can drop those in and we've got all the images we need. We do the same thing with our band headers. Band headers actually a set of three or four pieces of different pieces of content. We can all drop in there all with different styles. Headline, title, summary, all those types of things. And we've styled those and we've basically given them an interface so you can choose whatever you want. And they can drop in and display all those headers in any form fashion that you want. They actually have two different modes too, a dark theme and a light theme. So if you have a dark background, it's the same component, same markup. You're just able to switch that theme and continue on. We've got CTAs basically do the same thing. Everywhere we need a button, we have one component. One set of markup with one set of options that allow us to do that. We've got a primary, secondary, disabled, all sorts of types of buttons. Again, same markup. Just a couple different options within some data attributes. And lastly, all we need to finish this display is just a video embed. Which again, it's a video embed. This is not a video thumbnail. This is not a video page thing. Blah, blah, blah, blah. This is the thing we use when you click on the title and it goes to the video detail page. It's the exact same component. So we're creating these reusable components that allow us to express what this visual language is trying to say. So let's jump back out to this huge, huge design. Like, you know, they brought this to us in a meeting and like, this is going to be a big job. There's lots of stuff to do here. We're like, really? Lots of stuff? Like, we've got that done and that's done and those are all done and that's done. And actually we had a bunch of other components done too. We saw this and kind of just laughed because we knew the work to actually get this thing done was like, two stories, two small components that needed some additional functionality or just need to be built. So as we start building out this design system, we get to a point where we realize we can express everything our visual language needs to say. Need to express something to a user? Hey, we got, you know, we can do that. We have the components to build that out. See, we're not building pages anymore. We're building all of these small components that can be recombined together to create everything we need. So you do. We get to this point where we realize we have a complete design system capable of expressing everything our visual language can throw at it. And the only time we need to change that design system is if our visual language changes. If we add a new word to our vocabulary, yeah, we need to go back and figure out how to get that into the system. But until that happens, we get to a point where we're done, which is a crazy notion. We're like, wait, am I out of a job now? This sucks. Okay, let's go back to the old way. But no, instead of being out of a job, what that means is we get to now focus on making things better. Figure out how can we get better documentation, better testing, better tools, better delivery systems, better accessibility. How can we go back in the system and make it better rather than how can we build yet another page, another page, another page? You see, design systems are the future of the web. And as scary as it might be, as much as you're worried about what this might do to your career, I didn't time that properly, I will not fight the future. Thank you. That was horribly timed. Because there's this. Really? Nobody? Come on. I forgot my... But there's one more thing. And really, that was it, finally. Let's try this again. One more thing. All right, yeah, grown. We've all been there. This is great and all. We've got design systems. And it's hilarious. I wrote this thing weeks and weeks ago. And I get here to Drupalcon, and this is the one more thing that always keeps coming up. And I'm happy that I can be here standing on the stage to introduce a new iPhone to you that's only going to cost $600. Fortunately, it's not an iPhone, it doesn't cost $600. It's open source. It's great. So how do we get our design system into Drupal? This is the elephant in the room. And we all have started to figure out how we can do this. But the really big question is why haven't we already done this? Why is this not already a thing? Why didn't D8 come with this perfect way just to do it and slap it in and we're done and we can move on? Well, I can definitely tell you why D7 didn't do it because we spent a lot of time struggling with D7 to try and make it work with our design system. One of the main reasons for it is we've got dirty data models. We've got some really nasty data models coming from Drupal. Coming out of a model our title might be a variable, maybe. It could be something that's returned from a function. Great, cool. It might already be rendered markup with h tags and classes wrapped all around it. We never quite know what we're going to get from Drupal when we start building something. That is very difficult to build a design system on top of. Drupal 8 solves a bit of that and gives us some really clean variables coming directly down into our templates. We know we have a set of variables and arrays and objects we can loop through and do stuff with and life is a little bit better. But then we get in the notion of the tyranny of the model view paradigm. We've had this for a long time. We've got a model, set of data. We've got a view, our template file. That's our existence. That is our world. Anything you want to do gets down the model and the view. They live together in perfect harmony and then we hate ourselves because we can't reuse anything because there's all these views we're constantly redoing over and over and over again for every single set of data. That's not reuse. That's not atomic. That's not going to solve our problem. What we want is we want this. We want our view to actually be composed of multiple different components and that's what atomic design and that's what component-based design is promising us, which is great. Yay, let's do this. Then we realize, oh crap, these two do not speak the same language anywhere close. It's probably even worse than this, actually. We see our model is saying, hey, I've got a title. I've got an image and I've got some content and our view is going great. I need a headline. Can you give me a headline instead? The image is great. Thank you for the image but I need to know how to align this image left or right. I don't really have any use for content but I need a teaser and I need a body section. Can you give me that instead? Sure, you could do this. You could now go back to your model and make all your models match your design. Please don't do that. We tried it. It's horrible because now you've got a model that specifically is built for your view. If you ever change a template, if you want to swap a template out, do your model and you're going to be migrating every time you want to make a design change. That's not very agile. What can we do about this? I want to introduce you to my friends. Say hello to my little friends. The presenter. The presenter is our savior in all of this. The funny thing is we came to this conclusion at Red Hat some months ago. As I started to think about it, I'm like, how does this thing work? Talk to some people at phase two, even ran into John and he's like, I've got this crazy idea and I don't know if it's sane or what. We're all building presenters. It's really kind of spooky. Let me explain to you how our presenter works. A presenter is going to be your translator. It's going to be the middle person. This person that stands between your model, stands between your view and says, hey, model, I know what you're doing. View, I know what you need. Let me get you both hooked up. It looks kind of like this. Zoom in. The presenter knows that I'm going to be getting a title and it knows that I actually need a headline so I can make that transition, just set the variables up and I'll actually show a demo of this shortly and it's going to spit a headline out the other side. Image will be passed directly through, but there's additional value that's missing from our design, this right value. Something that allows us in this design, in this view to say specify right. Now there's a couple other options that you could have done. You could have just always made that view right and always make those templates right, but now you've got a right template and a left template and you're back to just pulling your hair out. You could put all of that inside the model and say, okay, to make the thing, you got to choose left on here or you always have to choose right, but now you're asking the user to constantly have to make those decisions and what happens if down the road, you want to change it to left. You got to go back to the model. It's a mess. Let's do that in the presenter. We can specify that type of data right there. Lastly we've got this content that's being passed through and it's actually being split in our presenter. It's sent to two different places. One just straight out as the body, but it's secondly passed through some kind of a filter before sending out to, before being sent out to the teaser. So I'm going to dive through a quick example of kind of what that looks like in code and don't worry, this is horrible. You can't see it. I'm going to make bigger pieces and it's on the slides. Let's dive in. So the way that's going to look is pretty much what we've been doing is using twig to do this. So you're actually writing all of your presenters right in twig. Drupal is giving you the data. You're saying, hey, I know what to do with this data. Let's go ahead and start interfacing with some of our templates. So we include our template.twig or whatever you want to call it. And what you can see is we've got a title, which is horrible on the slides, that's being passed in as the headline. So there you see that data conversion. The model thinks it's a title, but the view wants a headline. Sure. We can do that, no problem. Second we include is our image. So we include our image.twig and we can use this great little object syntax right inside of our include statement. And we pass the image through just as it is. That's great. It's fine. But we also pass through one more value, which is our align right. That gets passed through and now our presenter is passing all of that through. Thirdly we want to pass through that content. So what that's going to look like is we're including our content.twig or whatever you want to call it. Again, I probably wouldn't use these names, for example. We're going to pass that content through twice. One's going to be passed directly through to the body. The other one is going to be passed through to the teaser. But the great thing with twig is we have filters. We have ways to modify this data before it's passed on to our view. And in this case we'll use like some truncate function or we probably also want to strip off all of the HTML as well so you don't chop off a middle of a p-tag or something like that. But this allows us to repurpose that data to multiple places. And what we get is a full presenter passing all this data on through. But it doesn't stop there. There's one more thing that we need to realize is we've got three different templates here. And these three templates are just going to sit in the middle of our DOM? Probably not. There's probably going to be some kind of a wrapper around this. So like in this case maybe we want to put like a card around it. Well, we have two options. We could just take our little twig file that has all those includes and card, sweet, we're done moving on. Problem with that presenter paradigm doesn't really work that way. And I completely actually missed talking about this. This presenter paradigm is actually within something larger called Model View Presenter. Very kind of similar to the MVC paradigm. MVP Model View Presenter is something that's actually been around since mid 90s. I'm reading like articles from 1995 talking about using MVP to create interfaces within Windows 95. Like this is a paradigm that's been used for decades and decades to create interfaces. Totally missed it. I'm sorry. But part of that paradigm says the presenter's job is just to be a presenter. It is not there to actually be the view. It has no opinion about the actual markup that gets placed out. So what we want to do is we want to make sure we keep that presenter pure. We don't want to get markup in there. So what we can do is we can use extends. It's another great thing, extend or embed if you're going to have multiple of these. To be able to find what are these wrappers that we want to put all these includes inside of. And twig makes that super easy. Which is why I was like, let's just do this in twig. When we've got our card that's got a block inside of it and when we extend card we can just put all of our content right inside that block. And again you can't see it too great. But here's my fancy laser pointer. We have extend up top and down below and we've got our block body with our three includes inside of it. That is our presenter. That is what we came up with. That is what Bloom here and Crew came up with. That is exactly what John Alban did. He's like, is this crazy? But no, we've all come to the same conclusion. This is basically the interface that allows us to use a design system while still using twig and still interfacing with our Drupal model. And it is going to blow the doors off the way that we're building all of our tools. Because at that point it really doesn't matter the tool to be used. Whether it's pattern lab, whether it's pattern kit, whether it's KSS or whatever. The methodology is the same. Recreating views, recreating models and creating presenters in between. So one other great thing about this is that now that we have a model, now we have a defined model and we have the system for turning our model into a view, why don't we get a little fancy? Why don't we start talking about the API of this model? How can we describe to Drupal what this data needs to look like? And we can do that with this great little syntax called JSON schema. And the way that we do that is with, it's also all written in JSON. So you've got little objects and properties and values. And we can say since this is an object we've got three values here. We know there's going to be three key value pairs going on. We can say that it is an object. I'll use that again. And it's going to have some properties inside. First property is going to be the title. And we're going to say, hey this title is a string. Cool. That's really informative. We have an image. In this case it's just a string. It's a path to our image. We can make it more complex if we want to. But lastly we've got content which is a string but format of HTML. A little bit more information about what this property actually is and how it should be used and how it should be displayed and how it should be treated. And you can also dive into, we have arrays and we have booleans. We have all sorts of different content types to be able to describe what this data is that needs to be passed into our presenter. We realize this and we're like, cool, we've got a great way to be able to document how we need our data built to be able to use our templates. JSON schemas, there's lots of great tools built around JSON schemas. One of them that's really cool turns your JSON schema into a form using JavaScript. I was like, oh that's kind of neat. JSON schema is pretty much the data I need so it can create a form that supplies that data. I thought to myself, well if we can create a form out of JavaScript using these schemas, why can't we do the exact same thing with Drupal? Why can't we tell Drupal go create a new entity for me click? There we go. Thank you. Go create a new entity for me and use this schema as your recipe. It's got a title. It's got an image. It's got content. Oh, that's why I then forgot one thing. You can also specify what's required, like what are the required elements in there and what's not required. That's why when clicked it and do it. So when we pull this into Drupal, Drupal now understands this is our data model that needs to be sent to our presenter. These are the fields. These are the names of the fields that we're expecting to come in. These are the data types. These are even the formats of how we should display those and how we should store those. That is the kind of the realization, the epiphany that led us to building Pattern Builder. And I'm not going to dive into this too much because I'm doing a bof right after this and I'll get that on the slide. But Pattern Builder is a new Drupal 7 module. We hope for a D8 port. We just haven't built it yet because we're still D7. But what it does, it allows you to prototype your entire design system. Pattern Lab is awesome. It allows you to design the view layer of your application but does nothing for your presenter and your model. Within Pattern Builder we can build the entire thing and prototype the entire thing. And then when we're done, using JSON schemas and twig templates. Which basically means we've got these really non-Drupal things. We've got schemas and templates that really we could use anywhere. D7 and D8 WordPress site? Crazy ideas. But in D7, what we're able to do with Pattern Builder is then take all those schemas and create we're using paragraph modules specifically create a bunch of paragraph entities automatically with a single Drush command. So our entire data model for every single view that we have are in all of our design system with a single import Drush command we build all of our paragraph entities out of that. That means that you can then create paragraph bundle for its model. Thank you. And then it allows you to go in create content types using all of these paragraphs. These paragraphs that have the data model defined by twig or by JSON schemas, they're all then rendered directly through those twig files. We're basically saying Drupal render engine, no thank you, you're a little bit messy. We're going to go directly to just a PHP install of twig right in your server. Render that template, bring it right back to us. Cache it, do whatever you need, Drupal but that's the way that we're going to roll. And as I was saying renders that model back through a clean model through our twig templates. So as I said, prototyping our entire MVP every single view, every single display, everything we need defined in not just what it looks like. Yeah, thanks. I know I've got a timer right here. It's like the last slide. What are you talking about? I'm good. Alright. Imported the entire thing with the Drush command. It usually took us six weeks to take a pattern bring it through the entire process of creating the story, creating the acceptance criteria, defining what we need built, three weeks of that, three weeks of development time, six weeks to develop one feature so someone could go in and enter three fields and get something displayed out. We've now turned that into a Drush command. Something that can be done on deploy and changes. We need to make changes to these. Again, we make changes in the designs of some do release that gets to send out with the next deployment. It's changed the way we build things. It's now open source on D. Oh, on GitHub with some surrounding tools. And I am going to talk about that in Room 291 right after this. So that is a thank you after I say also go to wireframes to widgets which is tomorrow at you didn't put the time on the slide. 215. They're actually going to be talking about how they're using pattern lab, how they're doing presenters, how they're bringing pattern lab into D8. And with that and paragraphs, yes. And with that, I'm definitely done. Now we have about fourish minutes. If you have any questions, I'd be happy to take them to you. But again, I'm going to be down and where is it? 291. Oh, come on. Too far. 291. Basically answering questions and giving some demos of this. Anyone dying for questions or can wait? We're good. Awesome. Thanks.