 I think I'm going to get started maybe half a minute early because I made too many slides. Thank you very much for having me. This is my first DrupalCon, so I'm very excited to be here. And thanks for showing up to Pattern Language, Pattern Libraries in the Wild. I'm Mark Loubera. I'm the Technology Director for Blue Cadet and based at the Philly Office. We also have a New York office. We're a small interactive agency, again based in Philly and New York. We do websites, native applications. And we also do interactives for museums and higher ed and nonprofits. That's basically the wheelhouse of all our work, exclusively. And the talk I'm going to give today is intended to be descriptive, not prescriptive. This talk was really hard to write. I get writer's block in the best of times, but trying to capture the working experience of a team is really, really difficult, as opposed to something that just sort of like crawls out of your own head. So, yeah, I hope you all take this as just a little bit of documentation about Blue Cadet's journey, my journey through pattern-based methodologies. There won't be any, there's virtually no code at all in here. This is more of like a top-level talk, so I'm sorry to disappoint you if you were looking for like super front-end focused stuff, but hopefully you'll stick around. So, about two years ago, we started shifting away from page-centric thinking into more of a system-level approach. And we were writing the same way that many of our contemporaries were, with respect to pattern-based design. So, here's a couple of pieces that, you know, we've done over the last couple of years using that evolving methodology. This was for BRIC, based in Brooklyn. They're an arts organization. This one was for Science Friday. This one is in WordPress. But we used a lot of the techniques that we use across the board. We're very agnostic that way. We don't really cue too much to one platform. This one is for the Institute for Advanced Study in Princeton. It's kind of like just a great park for geniuses to hang out and think. And this was the site, new site that we launched recently for the Albright Knox Art Gallery in Buffalo, I believe. So, patterns and components are a bit of a big deal. You know, in the last couple, several years, we're seeing a lot of great editorial design come out there. You know, the New York Times with a lot of their interactive pieces have certainly been pushing on work and, you know, forcing a lot of people to catch up. Atavist, what they're doing with sort of their publishing platform and exposing this is sort of like a tool set for people to make really engaging content. They're doing great work too. Slate recently has been doing a lot of future articles that they're sort of designing out in the open, which I really love as an approach. And ProPublica, with their investigative reporting, they just have like a really great design team there that's doing incredible work. So, you might ask, why? Why are we doing all of this? And for Bucadet, the reason is pretty simple. We want to create visually interesting layouts to help support our content. You know, at the core, you know, it's a pretty simple thing that we want to do. But, and, sorry, improv rules. And we want to reduce complexity. We want to encourage consistency both on the code side as well as on the visual design side. And we want to support flexibility. So, that flexibility, we want that without spiraling into tens of unique templates or convoluted logic within a template. And there's lots of stuff out there that can support this from like the very beginning and genesis of an idea all the way through to execution. You know, we've got style tiles and element collages for, you know, design focused tools. We've got CMS structures to do this. So, like, Expression Engine and Kraft CMS have matrix. WordPress has advanced custom fields, flexible content field, or ACF SCF, which sounds like a football club. And paragraphs in Drupal. There's lots of other things in Drupal, but for the purposes of this talk, I'll mostly focus on paragraphs. And we've got pattern library frameworks. So, pattern lab, obviously, most people have heard of. And I'll talk a bit about that in a minute. But there's also fractal, which is a little more recent, I think, from the clear left folks. That one's really interesting. And there's styleguides.io, if you want to just, like, drink from the fire hose of pattern and style guides. And there's books. So, entire books on ways to do this. Anna Devenham, she's one of the maintainers of the styleguides.io site. There's a great small book called Front End Styleguides. And, obviously, Brad Frost recently published Atomic Design, sort of like an encapsulation of his methodology. And way back in 2010, Nathan Curtis with modular web design. So, what's the problem? The problem is us, actually. So, we've got all these great tools, but we're human, we're messy, and the language we use around design and pattern-based methods is very messy. So, lately, I've been thinking about small goals when I've been working on a lot of these projects. And that's, if you can just talk about specific things using the same words, you've accomplished something actually very meaningful and actually difficult to do. And that dovetails with one of my recent favorite articles written by Alaa Kolmatova. I hope I'm not mangling her name. But she wrote a piece in a list of part called The Language of Modular Design. It's a really great read. One of the quotes that jumped out at me was, you know, she says, we should start with language, not interfaces. As a way of sort of getting this abstraction of the content that you're really focusing on. Some of her suggestions just like really speak to me and talking about establishing consensus, naming modules by function and not positions. So if you've got like a header or a hero, and you call it events header, but you're using the exact same visual pattern, you know, on a donation page, should you still be calling it an event center or should you think of a better name? That's more geared to its purpose and not where it is on the site. Next, do this together. There's most of the, when we're breaking down projects, we do it in multidisciplinary teams. So we usually have a content strategist or content person, a designer, a developer. That could be anyone from the dev who's actually going to work on it, to somebody like me who's just in it to break down the project in complexity. And oftentimes a creative director if the concept is really kind of nebulous. But yeah, that really helps, you know, because everybody's slightly different in that approach in these problems. And so going back to what Ala was saying in her article, you know, favor consensus over best laid plans. Here's a quick example. This one was for the site we did for the Association for Public Art in Philly. You know, this is a call out and I wasn't directly coding on this, but I just remember the discussions around what to call something simple like this. You know, is it a billboard? Is it a promo? The client calls them a house ad. And one of the takeaways I got from this was, you know, sometimes consensus around language is much better than coming up with the perfect name. So if house ad is something that's well understood in the organization and it's consistent, then maybe call it a house ad. The other thing I've really been thinking about lately is this idea of liminal spaces. You know, the in-between. These are really fertile areas where things can either go really well or go wrong. So here's another quote from Dan Mall where he says, when thinking about patterns, content strategists are primarily thinking about content patterns. Designers are primarily thinking about display patterns. And front-end developers are responsible for bringing the two together. That's a bit of a long quote, but it really, let's talk about each of those sides in turn. So content patterns, you know, is sort of a piece of content. This is where content strategists can really help hone in on what the pieces that make up a piece of content are. And when we're breaking these down, we usually express them with words written on post-its or note cards with lots of tape. And a helpful question, of course, is if you put up an agile methodology to the story, the cards underneath are what it needs to be successful or complete. In terms of CMS, like mindset, a helpful question I always ask is, what do you see when you open the content edit form or expand the paragraph bundle? What are those fields? And that maps pretty closely to the content pattern. This can get messy. And I did not stage this photo. This was after seven hours with a client rewriting and discarding. This is a sign. When something like this happens, it means everybody's engaged. They're writing cards. They're changing the language to fit and get to that consensus. These roadmaps, as we call them, can get really, really big. But we had to get on ladders to put this up. This was for a project that served a website, two native applications, two kiosks, and a 200-foot touch wall on the website. But we broke it all down on cards. Let me shift gears a bit. Talk about display patterns. These are usually wireframes. Low res, high res. I used to be on one side or the other. I really don't care now. It's up to the designer. High res invites design discussions earlier when you may not be prepared for them. Low res, on the other hand, can make it hard to sell a concept because sometimes they can be too abstract. You have to feel out where your client is at. So the problem in doing this in sequences, on the one hand, all the cards are great, but they can be a little bit too abstract. Wires, on the other hand, are great visually. You can picture those things, but they hide a lot of complexity. You're looking at one particular scenario, but there might be a ton of variations for that pattern. And people absorb info differently. So there's a bit of that, something in the middle, again, that liminal space. Mash these content and design patterns together early. You can do that. You can see we like the physical component of things quite a bit. So cards and wires, you've got your abstract cards on the one hand, and you match that with the visual representation, your wireframe. That really helps expose things that are missing on one side or the other. The other thing I like to... is derive your patterns as one of them. I'll talk a bit about this later. My first experiment with Pattern Lab, I actually tried to build the smallest molecules and atoms first and tried to build and build and build. I thought that was the way you're supposed to do this thing, do it linearly, and I kind of quit halfway because I couldn't come up with the perfect staging. I kept going back and fixing things. So it's often easier to bounce between the big and the small. I'm really a little obsessed with those dual poles of understanding. Another thing you can do is actually cut up those patterns and again derive them. The depth, I don't know if you can really see, but those are all patterns that we thought looked close enough to each other that we would stack them on top of each other. The depth of the stack was actually a visual clue that we might need to consolidate some of this stuff. So again, work in the middle, don't be afraid to cut stuff up and actually use physical cues to do this. The other thing, get into the browser early. I should pause here and say it's up to you how you do this. We've done this with hand-built, very bespoke HTML prototypes. This is something we'd probably do with Pattern Lab now. Because with Pattern Lab you can get a code view. These mustache templates actually map fairly easily if you're in D8 and using Twig. I will say that if you're going to get into Pattern Lab you should read Atomic Design first. Again, that story about trying to build the perfect little units and turn them into pages. I was frustrated. I thought it was a linear process and it was a lot better when I started thinking of it as like, oh, you're going to go from the big to the small, back to the big and keep refining this. But even with all of this, you're looking at a very narrow like periscope-like view of a pattern. So, you know, that can be troublesome. Even if your client understands a pattern in isolation like they get the call-out block or whatever you're working at, it can be very disorienting when you start combining those with other things. So, if you do this work enough with Patterns, somebody's going to make a Lego analogy or use Lego as a metaphor. And so, even if you've got these little units and they're okay with these little units in isolation, throwing them all together and then just handing the CMS is often like, you know, just dumping a pile of bricks and saying like, hey, here's all the pieces you need to build amazing stuff. Good luck. Which brings me to my next point, which is show patterns in context. Right? Have an opinion. Is this appropriate? Is this pattern, this visual pattern appropriate for this content type? Situate your components in scenarios for content your client is likely to create. You can build presets. You know, we do it in documentation and sometimes we actually build out nodes that we just leave unpublished as reference for our clients. So, here's really quick. I'll go through this because I'm running out of time. Some pattern documentation. You know, you can have an index just detailing, you know, the common patterns you're going to get in the site. And then you can build from there so you've got the small again and the big again, playing off these twos, this two up thing. And then finally you can get combinations. Right? So, you can have all the possible things on the left and then a couple of, you know, examples or presets, suggested layouts that make sense for their content. Again, cards and wires, small pattern, collection of patterns, like just bouncing between the two. What you're really trying to do is narrow the abstraction gap. You're trying to like almost like slow down to speed up is another thing I like to mutter to myself. Okay, so, real quick, looking to the CMS, some real helpful translations like content pattern to content type or paragraph bundle. That kind of works for me. I can picture that. A display pattern often is expressed as a TPL file or a twig file. And a collection is, you know, something bigger that might combine something outside of the node that you're working on. So that could be a page node or a view template. Still a little messy, right? You know, the CMS tends to flatten this stuff out. So even if you share a visual pattern, you'll often have multiple templates that are doing the same thing. Another thing we've used are short codes, you know, for WYSIWYG stuff that doesn't require a lot of fields or structure. And that's often illuminated through, you know, like a style preset. We'll do everything in just this one node that's like, hey, here's all your styles for the WYSIWYG stuff with the short codes. Which brings us to paragraphs. I hate the name, but they're super useful. I'm excited for phase two session later today. I think they're going to go in depth into more of the technical connections between something like pattern lab and paragraphs. I think, you know, they're solving some of the same problems, and they're probably slightly ahead of where I am right now. But when we map to paragraph bundles, we'll, again, chop stuff up, throw it on a board, and this is like a set of available paragraph bundles for a content type. We'll just use that as reference. If I'm building out this type, I'm just looking at the side of my desk and looking at what bundles I've got available. So concrete example, Princeton admission, we recently launched this site and they had a flexible grid. It's pretty simple, but there were rules on what could sit next to each other, and some of those things needed to be entity references, and some of it were actually just like custom content that they entered. So the structure, like from one level up, is actually pretty simple. Like you've got these rows, and there's only really four types of rows after we, there's like the second or third iteration that we went. But once we got down to columns, we had columns for full width for each of those things, and then we had columns for half width, and then we had more columns for quarters. And then we had about 17 of them. And that actually worked well, but, because we didn't want to nest too deep. So we're like rows and columns, but we're going to go one level in, that's as far as we're going to go. That's a lot of cognitive overhead. So, you know, we're coming to the end here, but what can you do with that overhead? And often when you're building something, you're building, you know, the site in layers, and you're going all across the board, right? So you're, you might start with cognitive types and taxonomy. You know, you throw some views and blocks on top, you build out some TPL files or twig templates, and then maybe you're layering on your front-end code, your CSS and your JS. And then finally, you let your client in like two weeks before launch, and you're like, here's a complete system, here you go. Good luck and Godspeed. I like to think more more recently of trying to build a cake in slices. So here's my terrible drawing of a slice of cake. I really need to get an apple pencil because I'm actually not a bad artist, but drawing with your finger is kind of hard. But think of a, think of a cake from the top down, and you've identified maybe six pieces of really, you know, sort of crucial functionality. And you could build one of those things all the way from the back-end out to the front-end and get that in front of your client early. You know, this is nothing new. This is like agile methodology. Like ship something, get feedback, right? And then you go on to the other pieces. So like the flexible grid for Princeton, we got that in front of them early, but then we moved on to something like the video header, and we had a stats header, and then we had an FAQ section, and then we had like a whole bunch of other things. But by the time we were done with those key pieces, they had already been absorbing and sitting with the flexible grid and getting used to it for a long time. So, you know, give the complexity time to settle in. Give them focused practice. You know, we got feedback from them after, you know, they'd been playing with this for a while that really helped improve things. So I'll close with next steps and a.k.a. My hopes and dreams. I'm really interested to get context right in the CMS authoring environment. So Eileen Webb, there's a lot of writing and tweeting about the authoring experience, and recently she showed, you know, just a little technique that she's been doing. She's just using CSS, and I think it was like before or after pseudo classes. But what she's doing I'll blow this up. She's actually providing visual context for the entity references that go. So it's like, if you're entering these hero articles, there's a lot of information and hierarchy just as a visual thumbnail. And so I'm really thinking about that, and, you know, what are ways that we could extend that and, you know, hook into the editing content form so that when you're working on, say, a paragraph bundle you not only understand the small bundle itself, but the potential ways it can sit with the other bundles that are available for the content author. And I think it's totally grail, as Brad Frost calls it. You know, he talks about going from the style guide to the CMS, but I actually want that to feed back into the style guide, because it's really difficult once those things really start to drift. You know, Brad talks about solving it by having a team really responsible for the governance of a style guide. But not every place has the staff or the willingness or the ability to maintain something like that as a separate thing from the CMS. Like I said, this is all about our journey. I don't have this. This is something I want, and I hope somebody here is going to build it. But I think it's really important for the long-term success of the design system and the CMS that people can look at it and understand it years later if they're working on the CMS for, you know, a second phase or they're, you know, taking the style guide fresh, they're new to the project and they need to understand it. And again, narrowing that abstraction gap. Close. Start with language. You know, work in that liminal space in the middle. Narrow the abstraction gap as much as you can and show things in context. And get your client-focused practice on your stuff. Like, get it in front of them early. Like, we delivered that flexible grid to Princeton before the header and footer were even really in place. We just gave them the grid for like, this is what you're focusing on, sorry. We'll play with this and see how it feels. Thank you. So just info on the contrived sprints on Friday. And again, my stuff is going to be up. I'll update the session page and I've thrown my slides up on speaker deck. And thank you all. If there's any questions, I guess I have like maybe one or two minutes. You're still taking questions? Sure, I'll take them. So using paragraphs and the functionality seems great. It seems like everything can then be one content type, if everything can be like, you know, plug-and-play. Why not make everything an article? Why still have different content types that you were talking about, content patterns? Yeah, yeah. It's kind of a judgment call you'll have to make. The reasons we make them separate types are because for things like a view or anything you need to filter or if you need related content to show up elsewhere, it's helpful sometimes for it to be a discrete type so that you don't have to have a layer of taxonomy on this like article that says, what kind of article is it? But for a simple site, yeah, that might be all you need. And it's just a function of whether your clients are okay with much sort of that breadth of stuff available to them because there's also the danger that they could really craft a really Frankenstein-like page out of those elements. So that's kind of our mindset when approaching those. Thank you. Thanks.