 All right, so it is five o'clock. We're gonna just jump in and people can wander in as they wander in. All right. Welcome, welcome. I'm here today to talk to you about one of my favorite topics, pattern libraries. Our goal today is to provide you with a couple of tips and tricks for converting mockups into patterns. And we're gonna give you some tools to write some really robust, reusable patterns that should save you some time and money. All right, so who are we to introduce you to patterns? Well, my name is Cassandra Roberts. I am a senior front-end developer with Red Hat. I work on redhat.com. I am on the tech lead on the UX development team with Kendall. And my passion is delivering highly reusable patterns. So fits in pretty well. And I do a lot of the front-end JavaScript for redhat.com, also a new mom. So feel free to hit me up afterwards for baby pictures. And I am Kendall Totten. Also the UX development team on the team lead and I work for Red Hat. And I've been there about three years. I've been in a Drupal space for close to 10 years and web development a little bit longer than that. I did start in the design space and I've kind of transitioned over to front-end development through time. I've worked on some cool sites like dallascowboys.com and weather.com and now Red Hat. And I'm passionate about reusable code as well. So we're not actually here to tell you about patterns because you probably heard of patterns. They're not new. Pattern Lab has been around for, I think, close to five years. Brad Frost and Karub have hustled in it. And there's also some other cool libraries that are similar like KSS Node, Fractal, Mannequin. So we're gonna talk today about the different ways that you can take these same basic concepts that we see repeated in these pattern systems and show them, show you how you can apply them to your mock-ups. But this is a front-end talk, so don't worry. We're also gonna throw in some twig and some code snippets. All right, so let me tell you a little bit about our system at Red Hat. So our system involves a couple of different concepts, atoms, components, sub-patterns, patterns, and pattern groups. And we're gonna focus largely on the center three. And these go from smallest to largest. Often in terms of their options, content and complexity. All right, so mock-ups right away. Let's jump right in. So mock-ups for our blog redesign project are what we're gonna show next. But we're also gonna sprinkle in a couple of little snapshots from other projects that we've worked on for Red Hat.com. So this is the blog listing mock-up. And those of you who have worked with Envision will probably recognize the framing of it. We use Envision for our design sharing tool. Gives us a common language with our designers. So the first thing that I like to do when I get a new set of mock-ups is print everything out and lay it all out in front of me and start to investigate all of the content without any agenda. I'm starting to absorb the design, pay attention to the visuals, and all the little chunks of content that I see. I'm taking a lot of copious notes, and I'm writing down any questions that I'm gonna have for the designers about what interactions or mobile styles I might not be seeing in the mock-ups. All right, so this is the listing page but from 10,000 feet. Don't pay too much attention to the detail here. This is kind of giving you just an overview. In red, you can see we have components. Yellow is our layout kind of boxes. And then in the center here, these are the components inside the layouts, and sub-patterns, and purple is our patterns. And this is just how we like to break apart when we're doing our architecture, all of the visual that we get. If you have remote team members, one of the great tools that we like to use, we have a super awesome teammate, Chris. I think he's here. In the back, Chris, what? We work with Chris who's remote, and so we like to use, this is done with Envision Freehand, which is really awesome. So it's really good to keep in mind if you're working with remote teams, having some kind of digital whiteboarding tool because it really helps for everyone to be able to sit down and collaborate together and draw. But yeah, don't worry about this. We'll go into a deep dive in the next few sections. So step one, go through all the mock-ups. Absorbing the design, looking for common threads. Be careful not to jump into coding too quickly. It can lead to inefficiencies in how you build your system. I am the number one offender of this. I love code. All I wanna do is code. The first thing I start thinking about when I look at it is how I'm gonna write it, but it's really important to step back, put your coder hat to the side and put on your architecture hat and start thinking about what are the pieces and parts. Next, you're gonna be starting to challenge any subtle differences that you identify in your mock-ups because it's really important to have consistency across your design system. This is good for not just you as the front-end developer. It's also really good for your users because anything that is different is gonna deviate for your user as well. You want consistency across the board and Nielsen Norman will back me up on this. Jacob Nielsen of the Nielsen Norman Group. I'm a huge fan girl. I love their research. So this is a great quote. Consistency is the most powerful usability principle when things behave the same, users don't have to worry about what will happen. Use this to back you up when you're talking to your designers because it's really important that you have that consistency. Card paddings is a really great example. You'll notice this as you're looking at mock-ups. A lot of times the card padding will deviate in all of the different mock-ups. You'll see, oh, five pixels here, 10 pixels here, 20 pixels here. Why is it different? And sometimes the answer is it does need to be different because it's fitting in a different design or the element itself is too narrow or the breakpoints that we want. Need to call for certain different padding. Use those to inform your design system rather than surfacing that to an editor. So something like that can be done through breakpoints or element queries. And it doesn't necessarily have to be something new. So focus on how and why those deviations serve the user. This is another example. This is the toggle indicator. Still notice we have a dropdown list over here and then we've got a menu with an accordion and they have different indicators and we're trying to teach our user how to use our website. So we wanna go back to the designer and ask which would you prefer? If you could only have one, which one do you think better communicates that this is a dropdown? Typography. This one's a fun conversation to have. So it can be a little difficult but consistency helps your user, right? So some of the titles here are black. Some of the titles are red but the contexts are really similar and the content isn't that different. So we wanna ask, can this be made more consistent? After we've done that first pass with all of our initial questions for the designers, what's the next step? Well, thank you. You may wanna start by asking yourself some questions. Now this might seem silly or uncomfortable but trust us, if you can ask the right questions it can be a big help. We recommend that you start with content. Now someone famous once said content is king but since his name rhymes with Phil Gates of Microsoft we're not gonna mention it here. We'll just say that content is really important and you should start there. And I think Jeff Eaton actually mentioned this yesterday in the summit that this is the most important part of your CMS, right? So if you can train yourself to focus on content first and not the styles and not the grid or the JavaScript framework you're gonna use then you're off to a good start. And as a side note for this section if you hear me mention components don't worry about what a component is yet we'll get there and we'll get into some details. So first of all you wanna ask yourself what kind of content is in the mock-up? Make a list of the different kinds of things you're seeing. If it's a dynamically generated view of content that you're pulling in from somewhere else you may not need to worry about the content editor. But if you're expecting a human to plug in this content somewhere you might wanna put yourself in their shoes. So consider their mental model as opposed to what you're actually seeing in the mock-ups and notice they might be different. So here's an example of a featured article teaser box and we've got a cute little tag up in the corner we've got the date and then we have like a large title at the bottom. But if I'm a content editor building this probably I'm gonna want to add the title first and then the date and then the tags or any other metadata. Next ask yourself if you can collapse any field sets that are not required or superfluous settings to just kinda get them out of the way. They're there if the content admin needs them but you wanna make sure they're absolutely focused on the content first. Figure out if you can reduce the number of field sets you're giving to them right off the bat. If there's any way that you can dynamically add them like through paragraphs or some other utility where they can just say I wanna add another set and I wanna add another set that'd be a great way to minimize the editor experience. And finally consider their role. Now on our team we have a very large group of people that we work with that work on redhead.com and people generally tend to fall into camps. Designers and content editors not to say that those are mutually exclusive. Maybe you have a power user who's both of those things but we tend to think that our content writers and editors they're not as focused on the design. They don't really wanna have to worry about design detail so we don't wanna put that on their shoulders but if they're a designer, if they're part of the UX team maybe we do wanna give them a lot more settings so consider that when you're building patterns. Next when you're breaking apart a design into fields ask yourself just how related are these fields? And yes they're all related because they're on the same page so probably you're talking about the same thing but you wanna break it down. So kind of try to figure out are they tangentially related like distant cousins? Are they the same vampire that appears throughout history time and time again? If you don't know about this meme it's really spooky look it up. Also I just really wanted Keanu in my presentation selfishly. So it's easy to think all those fields are related but try to keep them small. Okay here's an example. This is our article teaser component and yes it contains all of those fields because hindsight is 2020. So if I were to do this again I would probably try to remove that bottom section that tags at the bottom because that on its own could probably be a very reusable component. In fact I know I saw that on our blog DetailMockups it kind of appears in the top corner so I would split that out. And next I think I would try to remove the section where it's the summary and then a little like read more link because I see that all over the place there's been teasers for all kinds of content. So I think I'd remove that too. So finally, I know it's kind of hard to see there's a blue box going on there. Finally we've got the header section of this teaser and I just am down to my title, dates, authors and URL. So that's a little bit more simplistic I can run with that. So when you're looking at your new mockups if you have been working on this site for a while try to ask yourself does this look like something I've already seen? If I have a design system is there maybe already a component out there that I can reuse? An important point though is to not focus on what it looks like but actually the fields that are going on behind the scenes. If it looks like something else, that's great. Make a sticky note and maybe there's a SAS placeholder you can create and extend or a mix in perhaps but the components we wanna focus on the content fields. But be careful. If something similar exists question just how complex is it already? Because we wanna follow our design system commandments and not reinvent the wheel, very important but we also don't wanna shoehorn something together or make it so complex that it ceases to be reusable at all. All right, if you're ready we have a quiz for you. This is, there's unicorns on them for those of you in the back. This is a RSS link that we saw in our blog mockup and we're gonna review a couple of things that already exist in our system. The first is a social share component and then next to it we have a taxonomy header component. The naming is of no consequence. So we're kind of trying to look for things that are similar. Anybody have any ideas? If you think this is a trick, you're right. Because I didn't tell you what fields we're building those components and I just said you should look for fields. So here's your next clue. These are the basic fields that are making up these components. Anybody wanna try now? Which one of these would you use? The left, exactly. All right, this gentleman here in the front would you like a unicorn? Unicorns? Unicorns? Oh, this is Tony. All right, well, we have these. So, yes, that is the correct answer, social share component. And again, with the blue boxes, okay. We're highlighting that actually in fact the styles are quite similar too. So we have a label, we have one icon and it doesn't matter what's in the icon, right? That's just an SVG we can swap out. So it's kind of a red herring that our taxonomy header component already came with an RSS icon. It doesn't matter, it's actually content even though it's part of the design. All right, so I have one more very simple example of a component where our content fields have stayed consistent over time. It's simple, it's just the text within a link, the link URL and then the title hover tip. So we have one setting on this component called type. And even though our fields have remained the same over time, we keep adding to the type. So first we just had primary and secondary. It was either a big red box or a blue link. And then later we kind of got into this ghost button idea where we've got like the outline and later a brick which will grow to fill the container that you place it into. So we evolved the styles of the component because those are easy to flex with, right? But we didn't have to touch the fields. Context for the win. Thank you. All right, so components. Now we'll kind of deep dive into components. These are the building blocks of your system. And if you can get these right, they will be your best friends later on down the road and serve you well. Components are bite-sized chunks of how we control the experience of the content editor and the users. So we're gonna lay out a couple of techniques for how to build reusable components. All right, so here's our blog listing page. In the top section, we have a blog post teaser which we've seen previously. Headline, date, authors, brief summary, and a link to the article. And now at the bottom we have the blue boxes, similar sets of information, just smaller and simpler, date, headline, and a link. So the main featured blog post uses the same component as the featured boxes inside the cards. Does it have a few more fields? Sure, are those fields in a different order? Yep, that's no biggie. The key here is that the content underneath is the same. That said, let the thing be the thing. And this is Kendall quoting Micah, quoting Ben Frayne, quoting probably someone else because it's a great example of how things migrate through our community. So let the thing be the thing. Don't try to shoehorn everything into one component. If it looks similar, but it has different content, just let it be its own component. We know naming is hard. I think we say this probably three times a day. So here's a couple of rules of thumb that we use. Keep component field names super generic, whereas your patterns and your sub-patterns can get really specific and more contextual. Let's do one together. This will involve audience participation, so there's some more sparkles in your future. All right, so this mock-up shows a list of speakers at an event, kind of like this one, and their bios. We're trying to name this component down here in red. Let's see a couple of other variations. All right, so same family of mock-ups. Looks pretty similar. Name, description, different styles, but we can adjust styles in a component using a setting, so let's look beyond those variations for now. All right, so here's a view of the component by itself. Let's look really closely at the fields. We have a name, job title and company, and a bio. Okay, well, what if we wanna put something after the name that isn't necessarily related to their job? There might be a mock-up with presentation times in that same spot. That would be useful information. So we're gonna go a little more generic for that field name. Metadata is pretty open-ended. It basically just says anything that's related to this component. All right, so what would you guys name this component? Teaser? Introduction? Subheading persona? Persona's getting close. Speaker, cards? Who said persona? Yeah? Okay, it's really close. Person, that's what we went with. So person's really open-ended, right? Person versus a speaker. A speaker is boxing us into an event context, so it kind of prevents us from being able to reuse this outside of that. What if we wanted to include it in a bio page where we've got a list of all of our CEOs? Or if we wanted to include information in some other context besides an event? So person allows us to reuse that component. It's a little more generic. Components in their field names are the place where we wanna stay generic, and again, the patterns and the sub-patterns are where we'll get back to context and specificity. So here's a few more examples of components in our system, very generically named. We're focusing on naming them for what they are and not what they actually contain. So we've got a call to action, an image in bed, a standard header, things like that, teaser, quotes, footnotes, just kind of giving you a general picture of what's in our design system here. And then we're letting this same naming process bleed through to our CSS classes as well, so it keeps it really open-ended. All right, so some really exciting stuff. In our components, there are basically two types of different fields. We have content fields and we have setting fields. So content is where a user puts their content in, pretty straightforward, but settings are the real power in the system. Settings let the editor make decisions about how it looks or the semantic markup without necessarily knowing that that's what they're doing. So in this example, you can see primary doesn't necessarily let the editor decide that the button is gonna be red. Primary just means tell us what is the most important link on the page. Is it the most important or is it maybe a secondary link? But you might be saying, okay, but my editor really wants to add a red button on this page. They're really focused on that. All right, well, help text. Help text is super cheap, really easy to add and change in the system. It doesn't require you to update a bunch of database fields or raw HTML markup to make that change. In our system, if we wanna update primary from being red, weak to blue, and that happens. Sometimes your business comes back to you and they say, okay, we want everything on the site to be blue now because we've rebranded. You can make that change by making a one line change in your CSS variables, and that will propagate across the system without having to go touch a bunch of pages or make a bunch of markup updates. All right, so here's another example. This is a semantic example. This is our component called a band header. And when you're dealing with headings, your SEO experts are really gonna want you to use the right semantic markup because that semantic markup is gonna fuel how you rank in your search results. And not all of us can have a super awesome SEO PhD. Have we got any PhDs in here? No, no. No? Kendall, no. All right, so we have a couple of SEO experts on our team and this was really important to them that we start using this markup correctly. But our content editor isn't necessarily gonna know what an H2 or an H3 is. They just know what their content is. And so what we're getting from them is tell us what the most important information is in your content. So here's the fields. We've surfaced to them two options, position and priority. So we've asked them to identify the position on the page. Is this in the hero or is this in the body content? And then we've asked them to tell us the priority of the different headings. So we have a title and a headline field. So we've surfaced that in this dropdown. And they're making the decision based on what they know about the content. So as front-end developers, we can't know what that content is gonna be. There's no way for us to programmatically tie that in. Twig, we promised you twig. So here's some twig, special. All right, so this is how we parse out what the correct markup should be. We take the information from the editor, that position, primary, priority, and we convert that into title tag and headline tag. So you can see we're setting up correct SEO markup. All right, layouts. Layouts are kind of confusing and they kind of set our system apart a little bit from most design systems, so we're gonna go a little more in-depth in here. And if you abstract layouts away from your components, they can be really powerful and they're very reusable. Layouts are containers that have markup and styles, but never typography. They're just pigeonholes you can put stuff into. And this is a little different than the containers that we have in Drupal. Do you wanna talk a little bit more about that? I mean, there's the layout module or layout UI in Drupal 8 that you probably have heard of or plenty of constructs around layout in Drupal. So kind of put that aside for a moment and just focus on the really basic concept of a layout as a bucket. All right, so you use a layout when you want to arrange and space apart different components, hide and show your content. If you wanna set a background image or color, you can also use it to add rule lines or borders between different elements. Ours are pretty small, but you can have some pretty complex layouts and they can act as the layout for the whole page, but in general, we keep them pretty small. So here's an example, a card. If these were all different components, can you imagine how many different times we would have to code the container padding, the background styles, the margins between the text and the call to action? It would be a headache, it would be a lot of code. So in this example, we have a couple of different sub-patterns each utilizing the card layout. So each sub-pattern has a section for components and you can see in blue, we have all of the components kind of separated out and you have a content component and a call to action component and some different styles, there's some color, some alignment settings and all of that is abstracted into the layout. But each layout has the same basic sections. You have a card header, a card body and a card footer. So let's look a little closer at the architecture of a card. This is a YAML so that you can kind of get a sense. We use JSON schema and YAML is how we feed in some example data into our JSON schema. So this will give you a sense of the data structure. You have a couple of settings at the top for background and you can use an image background or just a color. You can have an overlay if you're doing an image so that your text is a little more readable on top. And there's also a separate background section here and this is so that your heading can have a different background color than the global card. Our system is using the at symbol to indicate that we're pulling in a component. So you can see in the header, body and footer we're pulling in the card header quote and call to action respectively into those different buckets. And then here you're seeing that kind of layout pull back out. All right so a band. This one's a fun, so here's some of our mockups from redhat.com. We use a striped design and so if you kind of squint and let the content blur out you can start to see that design and that banding start to pull out in these mockups. And bands are a really easy system in our layout using layouts. So this is a band layout. It has a band header, a band body and a footer with an optional aside that can render on the left or the right. Pretty straightforward and we're just putting components into those different fields so that we can render a band. All right, so layouts. Awesome, super excited. I hope you're all jazzed. But are we surfacing these to our content editors? What if you don't want your content editor to have access to the background color and the alignment and to choose from this whole list of components that you have in your system? Am I building a different layout for every single use case? Subpatterns, no need. You can use a subpattern to control what the editor accesses. So a subpattern is a really cool concept in our system. It combines components into a layout while controlling what settings and options are being surfaced to your editors. These are really iterable and they're really great for grid style layouts where editors might be adding multiple chunks of related data. And subpatterns can actually contain other subpatterns. So you can go pretty deep. So just be careful, don't lose yourself. So here's an example. Quote box combines settings and a logo and a quote component and a call to action. Requires fewer choices be made by the content editor and combines a bunch of commonly used pieces. Image, quote, call to action. Pretty straightforward and just focuses on the content. But it's all being rendered inside of a card layout with a background and we're choosing image sizing settings for them. They're not having to make any of those decisions. They're just focusing on the content. This example is called download set. This is a way to access digital assets. And in our old system, you would have a big old list that Kendall will show you later of 25 options so that you could add as many assets as you needed or as few assets as you needed but you still have to scroll through all those fields. In our system, you just add it one at a time for as many as you need. It combines all of these components, this digital asset component, into a layout that we call a divider layout and it's just called divider because it adds a divider line between the components. This allows us to iterate and offer them a lot of flexibility. And here is the sub-pattern in context. So this is a downloads band and we're surfacing the download set sub-pattern inside of the downloads band. So we have one, two, three. And you can see as few or as many assets are being added as they would like in this view. All right, so building a sub-pattern. There's basically two schools of thought when building a sub-pattern. You have ones that are built for content editors and ones that are built for your power users that Kendall mentioned earlier, your user experience teams, your design web teams, et cetera. Editor sub-patterns are focused on content and they have a lot of design settings baked in already in your twig, hard-coded. And the power users have a lot more design options. The editor patterns are also really great for Drupal dynamic views because you're just working on plugging in the content that you have from Drupal into predefined designs. So here's an example of an editor sub-pattern. This is a product card and it's how we sell products on redhat.com on our store. And you can see we're focusing in the yaml just on the content. We're just asking them to put in all their content information and make minimal design decisions. We're even abstracting out some information instead of asking them to identify the color blue at the top here. We just ask them to identify the product line that this is a part of and then we use that information in order to figure out what color to surface in the card. This one is an event box example and it is a way of clicking through to our detail pages on our event listing. Again, we're just focusing on the content, just getting the information first from our users and then we're using the type in person as a way of deciding what colors and alignments and settings to use for the card. And that way the editor doesn't have to make any decisions. All they have to do is put in the information that they know about this event. This one's a little different. This is a sub-pattern that's actually just simplifying a component. There is no layout involved. We're just taking an existing component in our system that has a lot of options and settings and we're saying we don't want you to interface with all of these options. We don't want you to make decisions as an editor about what kind of CTA. We just want you to put in the link. Just give us the link information. So here's the sub-pattern. Just links, no additional settings. We do have variables in the twig surface that our Drupal can map to. And that way you can still make changes to this if you need to or override settings, but there's fallbacks. So if they don't enter in anything or we don't feed any variables in, it's still going to work. And then here's an example for our power users. We call this a standard text box. It's really just a way of putting text in a card with a call to action. And the design team has a lot of options. They can do alignment. They can do background colors. They can do images. They can decide what kind of call to action goes there. So there's a lot of choices. And this is the kitchen sink, as we call it. Give them everything that they could possibly want to make their custom designs, their little snowflakes. Alrighty, so now that you understand the basics of sub-patterns, as you might have guessed, patterns are just the larger version, bigger and better. So we've already illustrated how useful they can be. So in this section, we're going to kind of get into the weeds of how you can assemble them. So when you're thinking about a pattern, think about it as a recipe. It says, go and get these ingredients and assemble them like so and sprinkle on some settings. Really get the metaphor going. So the UI goal, like we keep harping on, is really just to stay as minimal as possible and focus on content. Because they're only referencing the components and layouts. And we're doing so by vehicle of a twig mechanism that you're probably familiar with, embeds or includes. So what we're basically doing on the left here, or sorry, on the right, you can see an example of some code for a pattern, where we're saying, go and get the card or group layout and put the icon panel component inside of it. Notice that there's no HTML markup here. And just to kind of drill in a little bit, one of the examples of a variable for a setting that we are surfacing is container background. So you can see we're plugging in that variable and we're giving it to the layout so it knows what color to be. But at the top, we're also utilizing that same variable to determine which layout we want to go get. Because if we're not setting a background color, it's fine to just render it in a group, which is essentially a div, we're just wrapping it. But if we're loading a background color, we probably need some extra padding baked in so the text doesn't touch the edge of the container. So we're doing some logic up there. And then at the bottom, when we go get that icon panel component, there's a setting called alignment. And in this use case, we've decided to not surface that to the admin. So you can see we've just hard coded the value that we've decided makes the most sense for this particular pattern and we just baked it right in. Now here's an example of a testimonial band pattern. And you can see that the top of it, even though it says background options, you could kind of think of background as a design-y sort of thing. But in the context of a testimonial, we're expecting them to upload a picture of the person who's saying the quote. So really it's kind of content because if it's Johnny Cash saying the quote, we really want his face next to it, is that cool? And the configuration setting that we're surfacing is layout because if Johnny Cash is on the left side of the image, we want to put the quote on the right or vice versa. So we have to give them just the minimal amount that they need to get by and then back to the content settings. Now, unlike social media, patterns are a great place to incorporate logic. So rather than incorporating all of these different settings, see what else you can infer from the settings the content admins are already giving you. So now here's an example where we saw this in our blog listing page and this is some social media tiles. And even though these are technically dynamically created with Twitter for the sake of argument, we're gonna pretend that our content admin is filling these out. So the first one is a red background, the second one is white. And the most important thing here is that we reverse the text color so that it remains readable no matter what background color we have. So we used to have a system where we had a setting called theme and we said content admin is really important that you reverse your text color. So remember if you use a black background or red background, you gotta remember to switch the theme. They would forget, they would become confused, they didn't understand why a dark theme meant light text, it was a mess. So later we realized by virtue of documentation that we actually had all the information we needed. We knew if it was a red background they should change the theme to dark. So we used twig logic to kind of bake it all in and do it for them. Now here's an example of the markup behind the scenes because this is an important point, don't worry about all the craziness, but we're focusing on a couple pieces here. We use data attributes to style our stuff and I know it's wrong and bad, but forgive us because we love it and it's very readable. So you can see we have a data attribute for background and you can see it says red and white and we have a separate data attribute for theme which says dark and light. And we've actually added a desaturated theme later on because we realized we don't want blue links on red tiles so we're gonna go ahead and accommodate for that. Now the important point here is they're separate. We have built in logic but we've kept the attributes separate, they're separate fields in our database so later when we wanna break these apart or do more with the logic it's still very clean. Now here's one example, I think we actually already saw something similar with our featured event card but I wanted to highlight how easy this is for a content admin to very quickly change the design and get something wildly different. So we're saying tell us about this event box that you're building, is it the primary, is it the most important event on the page or is it perhaps secondary? When they choose one of those things you can see the background color gets more exciting, the text gets bigger, the layout changes and so all that stuff is baked in. And because we're in the pattern section I was kind of cheating by showing you the sub-pattern. Here it is in context, this is the full pattern that's loading all three of those things and we're actually pulling dynamic data into this so when we mapped it in Drupal we said the first one's primary, the second two are secondary, done. And we're twig. This is what it looks like behind the scenes. So we've taken that one configuration setting called emphasis and we've said when somebody chooses primary here's all of the things that we're gonna do with that information and again we've kept it separate and we actually have a couple of things up here that look layout related, layout and alignment because we're spacing apart the text or we're putting the imagery next to the text and we're doing a lot there so we wanted to keep them all separate as possible. The padding difference, so a stacked is 30 pixels of padding between each component and minstack is 15. Good question. Unicorn. All right, so now here's an action band pattern which is also on our blog listing page and I love this example because it showcases how we were able to reuse the same mini article teaser component over and over again and also the same list layout over and over again. Now this is a cool example because when we got these mockups we took them back to the design team and we said hang on, designing consistencies, what's up with that? Why did these ones have bullets and those ones have rule lines between each one and they said oh well it's because those ones have a date and the bullets kind of look weird when the content starts wrapping and there's an extra chunk so like we wanted to do rule lines instead. Like okay that actually makes sense so can we just go ahead and bake in that logic so if a date appears then we'll just add the rule lines and they're like yeah sounds good. So we're utilizing the very same components and layouts and we're just adding a little extra data attribute spice so I'm highlighting here this is their data RH list style it's called flush which just means there's no bullets it lines up with the edge of the container and it also gets those rule lines in between and just so you can see it in action. This is the sub pattern again I'm cheating but the sub pattern you can see when I'm removing or adding back the date it's dynamically updating and changing all of those styles. Brilliant. So remember the takeaway here is it's not just about what you see in the pattern it's also about what you don't see. Smoke and mirrors. So let's get technical because this might all sound super cool. IT crowd fans what's up? So this might sound cool but you're thinking I don't know it sounds like a lot of work but there's a lot of code out there that you can lean on and I wanna take it back old school and just remind you this isn't a new concept we've been doing this since display modes right? Display modes say use the same set of fields same content and render it a few different ways so conceptually you could kind of use this model and start using the same concepts and this is the paragraphs module which we actually are using we're turning our JSON schemas into paragraph bundles in Drupal and paragraphs module is saving us from the horrors of infinite fields. So this is what we mentioned earlier this is our old event content type I don't even wanna tell you how many fields are here it's disgusting and they have to keep scrolling and scrolling but now with paragraphs we have a download band pattern which the content admin can just say yep that's the one that I wanna add and as soon as they do that then they fill out a couple pieces of information about the heading and they get right into the sub patterns they add a download set sub pattern and then they've got some components inside of that for digital assets they can add one or two if they want it and be done. All right because we're short on time and this is a quick session here I wanted to just give you a lot to walk away with and go research on your own so handful of modules paragraphs I already mentioned the components module for Drupal 8 is what takes your components and registers them in your module or theme it registers them as twig namespaces so that you can basically structure and organize all of your twig templates in a model that makes sense to you or use the pattern lab approach or whatever and then bring it back and let your Drupal templates make use of them. The UI patterns module does something similar it takes all of your components and makes them registerable as plugins for things like panels or views or any other display mode and this code section here is because the community is always hard at work trying to basically drive this concept home and incorporate patterns into Drupal. I encourage you to go check out these projects a lot of cool stuff happening here much of it is Drupal 8 we're on Drupal 7 but if you're on Drupal 8 this is for you and pattern kit we gave a shout out to Micah earlier Micah helped basically build the tool that you were seeing when we were showing you the previews and if it didn't look like Drupal that was pattern kit so everything we're building is actually outside of Drupal and then we're just importing it which is really fabulous we have like a real time way of previewing what we're building and element queries if you were wondering how we can take a sub pattern and drop it in anywhere on the page and have it be responsive it's because we're not using media queries we don't care if it takes up the full width of the page or it's tucked into a sidebar because we're using a neat JavaScript library to basically detect the size of the container width it's fab and then finally we're gonna do a shameless plug for a talk that we previously gave gave about our CSS approach called Beaks and it takes the best from SMACS and BEM and it's block element attribute which is the data attributes that you saw earlier so definitely check that out and then finally a lovely video series and blog post that I thought was fascinating so I wanted to include it all right top three takeaways because you're thinking sounds cool do I really want to go to all this trouble can I just keep styling my Drupal content types the way that I always have like I'm a themeer I know what I'm doing here and I feel you because there's a lot of time that goes into learning theming but simplicity is a really big win simplicity especially for your content sorry your editors that are plugging content into your system every single day these people are hard at work give them some love simplify their experience and bake in all of that design stuff because we like to dump it all on their shoulders we're like this is where you edit the blocks this is how you change the view you're definitely gonna want to change that plug-in and at that setting and it's a lot so bring it back down to earthworm as a themeer, as a front-end developer simplify your life allow yourself the ability to reuse the code that you worked so hard to write and not reinvent the wheel raise your hand if you've ever had the feeling of deja vu like I know I've styled this before right? yes escape that and finally of course your end user your site visitor deserves to have a simple user experience if they take the time to learn how to navigate your menu system don't make them relearn it on a different page if they figure out how to hide and show content in an accordion reuse that pattern and let them understand it again and again flexibility we talked a lot about this about bundling settings and I really want to harp on this because this is actually something Jeff Eaton said yesterday in the summit and I was like that is so spot on he referred to this concept as design metadata so rather than saying do you want it to be red or do you want it to be blue call it primary if you can abstract a little bit you are maintaining control of what primary means you can bundle the settings you're simplifying it for them but you're kind of keeping it in house and if you can infer settings through logic basically you could say hey I saw that you added three components so I'm going to give you a three column layout wouldn't that be sassy magic do the work for them and like we talked about theme we inferred the text color for them when they changed the background color and last but not least time and money because that's why we're all here right so yes this is an upfront investment I won't pretend that this is something that you could do overnight or start using tomorrow without a little bit of legwork so it's an upfront investment so you want to take this back and discuss this with your business your product donors and convince them that this is a really great system because ultimately you're going to save time by being able to reuse your patterns and your components we're about three years into the system and I can attest this is this is a great system because we still love working on it and that's never happened before I've never worked on a project for that long where I'm like I love being in this code every day like usually it's spaghetti so we're able to reuse our code and we just got a whole new set of mock-ups for our newest section of our blog and we're like yeah we got a component for that we've got a layout no problem we'll add a tweak done and finally get your designers excited about this this took a little bit of work because designers don't love the word templates they don't like to feel like they're boxed in but when they understand that they have maintained a control behind the scenes and when they ask you to make a change you're like no problem I can do that because you have control so we're about out of time here so I want to give a shot again there's Micah's beautiful face we want to give a shot to Micah but you can follow all three of us on Twitter he is definitely the most active if you're a night owl 3 a.m. Micah's tweeting it's weird and then finally we want to open it up to questions so if you have any questions please come up to the mic and sorry I just want to do a quick plug if you're looking for these slides you can find them at bit.ly Drupalcon one word all lowercase Drupalcon-2018 and we're going to do a quick plug here for also reviewing the session if you would be so kind if you enjoyed it and also the Drupalcon survey alright thanks guys so I thought element queries were like like kind of had lost some steam it's now going to kind of pick it back up or someone else they're alive and well I don't know I mean I definitely have seen a few different libraries approaches to element queries and I will say you have to be careful about how you implement it I don't think it's wise to put an element query on everything on the page so our approach has been to add element queries to our sub patterns because we know that's something that's probably going to be variable in size because it could be in a sidebar it could take up the full width of the band and we don't put it on components because that would be 101 queries on the page yeah okay great thank you so much thanks Eric hey so this is really encouraging to see because you know sort of validating for stuff that I've been doing on a site that's about to launch but one of the things that I'm concerned about as I'm about to launch sort of just that first yeah the first release of it is am I going to be able to have the system evolve over time refactor these patterns how they evolve are there any insights that you have since it sounds like you've been released with this for a while about what things are important to be doing right when you first build the pattern so that you can refact them over time things like you know those those little changes that happen that you thought oh the pattern was this way well actually maybe it should be this other way and all that yeah don't add it to your schema unless you're sure that you want that for all eternity because the only way to get rid of it without doing a breaking change is to hide it and then it's going to exist in your database no matter what so once it's in your database it's in your database and you have to respect that choice that your editor has made that one's been the hardest for us to try and involve and walk away from certain settings that we don't want to exist anymore we're kind of locked in so definitely be wary of what you're putting in your database and what information you're collecting if you can get it in your twig instead or get by with something you think I might need this in the future but I don't need it right now don't put it in your schema yet just put it as a variable in your twig and set it hard-coded and then you can always add you can always add to your schema later it's easy to add it's harder to take away I'll add one thing which is to say that y'all are getting the benefit of us working on this for three years so all of the things that we are telling you to do we probably learned the hard way about naming our components generic and then the patterns getting more specific things like that thanks sure you need to make a new atom for each field or do you make a new component for each probably over 20 or so as far as content I'm just wondering how you make that good question yeah so I think the question was do you create a new atom for every field just to kind of boil it down so I focus on just making atoms when I see a field that is complex enough that we would need to reuse it a lot an example of this would be we wrote an atom for a summary the teaser summary that you saw in our example we wrote an atom for that because there was some logic behind the scene saying like how many words do we want to surface in our teaser before we do the dot dot dot read more so we kind of abstracted that if there's some complexity in that then pulling that out into an atom is really nice but if it's just a standard text field it's not necessary another great place for an atom would be we use certain HTML tags are allowed from our content editors in summary and text fields and so we will surface an atom so that we can kind of consistently control those HTML tags for a more consistent editor experience so if we want the editor to be able to add italics or bold or something else but not add links or not add p tags then we will write a special twig atom for that so that we can parse that out separately but you don't necessarily need for simple Drupal concepts to create an atom for it I was just gonna add we do have a couple for like image embeds because it's integrating with the media module and another for link whenever we want to make use of we use a tool called link it which is another module that helps you go find content on your page and build the correct URL for it so we want to make use of those because there's a little bit of Drupal integration so we'll lean on an atom to kind of build that bridge did that answer your question? Thank you It's really great to see that pattern kid is still alive and kicking I'm a huge fan And I have plans for it too I'm a huge fan I'm coming from the pattern lab world along with Evan Lovely who you had up on the screen earlier so we've been trying to keep the pattern lab lights on for the last couple years I guess my question is more from a content authoring and heck even Drupal developer downstream consuming what you guys are shipping from the design system You know, atoms and components totally make sense Do you find that they're actually working at that lower level having to do with every possible option or is the abstraction with choose your layout and then choose your sub-pattern really where that part of the team is really operating at So when you're describing well let me try to summarize the question I think so are you asking what the development team has to interact with the patterns what's their experience like? I guess one thing that we've noticed is having every component be a kitchen sink can get overwhelming very quickly so that's why you boil it down to a sub-pattern or a pattern Are content authors the main audience for those two or is it also really like it's pre-configuring how you want like how you wanna pre-configuring how you want your nitty gritty component or atom to actually show up Yeah, so sorry, let me jump in real quick because I see where you're going there and I have been strongly encouraging so our dev team when we're mapping for something that's dynamic content in Drupal when we're mapping it was originally mapping directly to a layout and calling a component and I'll be honest I'm very designy and I was really unhappy with some of the results of that because I found that some of the settings weren't being set correctly or there was a lot of guidance necessary for building that out and it was a lot of complexity like you mentioned and so I've been strongly encouraging when mapping to go through our patterns don't even touch the sub-patterns like the sub-patterns you'll access through the pattern but always go through a pattern is what I've been strongly encouraging our dev team to do when mapping and that's been really great and ensuring that we don't end up with any what we call ugly babies You get repeatable designs that look good Yeah, and are consistent across the site Yeah, that's work Yeah, I will definitely say mapping was a bit of a headache early on before we kind of got into the heavy pattern system where we went through so many cycles just trying to get Drupal fields to match up with what we were building outside of Drupal and these components and patterns so really it's been a great catch-off for both editors and developer mappers alike So I'm sorry if this is too technical of a question for the end of the day at the end of the session but I'm just curious if you would say more about how you determine where particular logic goes in terms of like within Drupal templates or within pattern lab templates and like how you wire those up I know it's a big topic but Well, I mean everything is literally in the twig templates that we're writing for these systems and it's only components and layouts The patterns technically are using twig but like again it's just a recipe looping through We're not doing anything on the Drupal side in terms of templating The modules that we're using to map Drupal fields are really just PHP modules and they're just saying take this field, render it here take this field, render it here So again there's no templates there So I don't know if that I will say there's a little bit of logic around translation and so what we'll do Drupal will sometimes be parsing the content to say like oh put this through the translation tool or they might be like rendering a date and it might be in UTC time and we're like converting it into like a pretty print and rendering it through our pattern but Drupal the only thing that we're doing on the mapping side that's logic based is around manipulating the content and then injecting the content into those fields that exist in our twig templates They're not actually messing with any HTML or styles Okay, that makes sense, thanks Thank you Anybody else for the questions? How are we doing on time? You guys got into definitions on your schemes, yeah? So bringing the part of scheming that is that you can swap it into a different market by experience? Yes, okay The question is have we gotten into schemas or breaking it down into really small pieces? Yes, so Do you want to call or? Yes, okay So we do have one atom called config Oh, thank you That's way more useful Okay, so we actually, we have one config atom which is kind of a little house for all of our settings that we keep using over again like background color or alignment or things like this So what I'm showing you here is probably the most inception like pattern that we're doing in our system This is our agenda pattern and every time we reference something Hold on, there's a mouse Every time we reference something we're basically calling another template So I just kind of wanted to showcase here First one is a pattern which references a daily agenda, JSON schema which is a sub-pattern And you can see here up at the top, here's the category And then we get down into the body of that sub-pattern and we're referencing a time slot row which is a layout So we come over here time slot row is also Oh, it's a sub-pattern, just kidding The time slot row references session and session breakout because in this particular instance we had We wanted people to be able to build dynamic agendas and they might be loading a regular session but it might be a breakout We wanted to give them some color coding options and things So this is an array where they can choose one or the other as they're building it out So you can see here this is our session component and then our session breakout sub-pattern Yeah, oh yeah, because inception because it keeps going and so then that one is then calling more layouts and more components It's been a little while since I looked at this So you're not seeing the I'm not pointing to the layouts in this screenshot here but it's actually loading all of this stuff inside a clean table layout and then there's a table row layout and things like that So I don't know if that helps usually for me looking at code kind of leads leads to some answers Did you want to add to that or? No, no, I love this example And then since y'all are still here thank you so much for being dedicated I have some more sneak peek slides if you want to see more code Always We just got to get through the DrupalCon stuff They're not being validated Okay Which makes me sad but eventually we will validate them against our schemas They can pretty much inject any variable that they want into our twig Right No, not on Drupal So Drupal's not doing any schema validation whatsoever I mean the twig is like Yeah, well we're not on D8 So we're kind of loosely using twig When we move to D8, I'm very excited So we wrote a module, a custom module called pattern builder importer that basically walks through the schema and turns it into a paragraph bundle So it is creating all of the fields but it's blissfully unaware of the layouts that are behind the scenes We're just using those twig templates So here's a sneak peek into the schemas again because I wanted to highlight if there's a field if there's an opportunity to reuse a field on its own we can reference an individual field so we don't have to recreate all of those So in Drupal, if it already exists as a component that's a field base when we reference it a second time that's another instance of that same field So it doesn't have to recreate it there And here's what it looks like If you were to look at the actual paragraph bundle you could see that those field names are exactly the same in the component and the sub-pattern And there's the UI which...sexy And then here's the schema that's basically showcasing a component and a sub-pattern or sorry, a sub-pattern that is referencing an entire component So we've kind of gotten away from this as time has gone on because again, once you give them a whole component you can't take it back Now your content editors have access to all of that stuff So we do this less and less but in this example, it's referencing the whole thing So all of the fields that are defined in the component are now showing up inside of that sub-pattern So in the paragraph bundle it's just an entity reference And so you can see it's just pointing to another embedded pattern The component itself is another paragraph bundle and so it's just referenced that way And here it is inside of the editor UI Anton, you have a question? Yeah, one question about terminology You are using a term, atom, in your system but you are not using molecules, organisms and other terms from atomic design Is there any special reason for that? And why did you decide to go away from this methodology? You should tweet at Micah about that So Micah kind of came up with the naming constructs I think it really came from a place of simplicity because if you're going to build a schema for a thing do you really want to have five different ways of naming it Or is it easier to just call it a component, which is fields or a layout, which is just a bucket So we started with those and then we kind of built upon it and patterns was the original MVC where we were showcasing it to the editor and then somewhere along the way we were like sub-patterns are a better way to go because we kind of saw the same repetition inside of a pattern over and over again So patterns are just the recipes So it was really just trying to boil it down to what was most important and not get lost in the naming conventions That's my loose answer Yeah, that's quite interesting because many companies actually switching from atomic design terminology to way around terminology So what was the second one? I mean, it doesn't matter many companies implement way around language for design components So atomic terms doesn't work well in real life Yeah, exactly Naming is hard Naming is hard, yeah You have to do what works for your team and use names that make sense to them as long as they understand it Yeah, absolutely Alright, thank you so much, guys Like, I'm gonna use it at work and do like all my presentations with this and like laser-cleaner it Awesome question Yeah, I just want to say that when it comes down like at the V8 you're retired or 20-star or not you're coming in and you know what I'm saying We used to take part of the motion and sat and go on and talk and talk I was chatting with him like before he submitted his session to try to like get an understanding of what he was going to talk about Yeah Yeah, the smart dude I was like, the conversation that he used like with him was like how I talk with Kendall about every two months and we just geek out about all this stuff Yeah I think one spark will go up with that Does anyone want my spark on that? Yeah One more swag? Anyone? Oh, alright Text me, like, or make sparking a loop Oh, oh Okay, so let's Google hangouts, whatever wherever you go Hangouts Yeah, that's what that's the text messaging That's how I get your messages Oh Oh, no Hey Thanks for coming Yeah Oh, nice Yeah So I did not take my own session I'm not happy with his work at Microsoft since we're going really well No, we're allowed to but we always have to like He just discovered views There's a word for it where you basically bow out That's really cool If I was going to submit something to my address I can't vote on it You guys is that or whatever What's that? There we go Thank you very much We're cute Yeah, something good like Oh, I'll wear it I'll never forget you Yeah That's a perfect name So We borrow a lot from Micah Thanks Okay, this is my sharing Okay WL WL WL WL WL WL WL WL WL WL WL WL WL