 Okay, y'all, I think we'll go ahead and get started. Looks like it's 11.45 on the dot. Thank you very much for coming to our session. We're excited to talk to you today about content patterns. Okay, let's think a minute. Why are we here today? What are we talking about? Basically, in a nutshell, what we wanna do is take lessons from design, things that we've learned from the design world, and apply them to our content architecture. What we've observed over the years is that a lot of Drupal content architecture out there ranges from somewhat half-baked to a total mess. And we have some ideas to fix it. So just looking at the agenda, we're gonna talk through a lot of material. We'll try to keep this on time. First off, I'll kick us off with some common architecture kind of problem, some quick wins that can help you there. And then we'll quickly segue over to design. Justin's gonna talk to you about some design ideas and patterns we use, and then we're gonna walk you through our journey and show you how we apply those same, you know, those ideas, those patterns from the design world over to the tools that we use. And yeah, hopefully by the end of it, you have some ideas to take home with you. First, a bit about Media Current. Media Current is a full-service digital agency focused on open source, development, strategy, and design for enterprise organizations. My name is Jay Calacot. I am VP of Technical Operations for Media Current. I've worked with them for over a decade now. And I'm very excited to join you here to talk about content patterns. And I hail from Little Rock, Arkansas, where I live with my wife and two kiddos. Good morning, can you hear me? Good morning, Drupalcon. I'm not Jay. My name's Justin Rent. This is my first time at Drupalcon and my first time speaking at Drupalcon. So to see you all is pretty awesome. So thanks for coming. I'm a UI and UX designer at Media Current. I've been working for Media Current for about two years now. I work in between our digital strategy and our development teams to plan and build digital experiences for our clients. Outside of Media Current, I am an adjunct professor at Keen State University in Keen, New Hampshire. I teach an undergraduate web design course in their graphic design program. I live in Keen, New Hampshire with my wife, two kids, two dogs, and I enjoy music, skiing, running, and just being outside. So to start the presentation, gonna introduce you to two friends of mine. They're not actually my friends, they're friends I made up. But this is Sarah. Sarah is a lead developer and she works for XYZ Corporation. She enjoys her job very much, but it has arrived at a point of complete and total frustration with the architecture of her company's main website. Over time and through several staffing changes with a focus on making new things, the database has grown so much that it is now a maintenance nightmare for Sarah. This makes her anxious and she feels as though the site is frail because of it. This is her colleague, Jeffrey. Jeffrey is a content editor at XYZ Corporation where he is responsible for creating, updating, and editing content across the entire site. From his perspective, the editorial experience is messy and that some things that should be the same aren't. There isn't really one way of doing things for different parts of the site. And because of this, there's a steep learning curve for new people who come to join his team. So Jay, how about you shed some light on Sarah's frustrations for us? Awesome, thank you very much. Okay, let's set the table here. We're gonna walk through some common architecture problems that we see, hopefully give you some quick wins here. Okay, several different problems. The first one that I see a lot are basically too many content types and taxonomies. We created a little graphic here. So I would benchmark the kind of average number of content types from sites I've seen over the years, somewhere around 12. If you've got too many, if you get in that kind of 20 plus, you're in the Kenny Loggins Danger Zone a little bit, you wanna avoid that. When I see a bunch of content types like that, I'm just really seeing too many. You might consider consolidating. You probably have some content types that are just cruffed that aren't actually being used or they're one-offs. You wanna avoid that. On the other side of the spectrum, if you've only got a couple content types, maybe they're trying to do too much and you need to break them apart a little bit. And then for taxonomies, I would benchmark average around 10, same idea. You don't wanna have too many. The next problem I've seen many times is too many similar entity structures. So in Drupal, you have a lot of ways to store content, right? That's what's great about Drupal. You can organize your content in a bunch of different ways in a structured way. And that's great. Core gives you node, it gives you taxonomy, it gives you blocks. And then with Contrib, you get even more modules. So you have paragraphs, which we like a lot, ECK. I'm sure there's plenty of other options out there. That's great. What you wanna do is try to pick the handful of best structures that are gonna work for your build. If you add too many, you're gonna create confusion, a bunch of different interfaces that your editors are gonna have to use and it's gonna turn into a mess. And that kind of leads us into the next point is a confusing editing experience. You don't want too many interfaces. So we mentioned about all these content structures. In addition to that, you could have just too many interfaces in general because of all these page building tools, right? Drupal has, in Core, it has obviously node edit. It's got block admin. And then Contrib adds panelizer and panels and Core has layout builder in it now. We mentioned paragraphs. All these different tools, many times they have their own interface. And I know I've made the mistake in the past of just having too much stuff there. And I'm like training a editor who's not as technical as your development team that put this together. They can struggle, right? And so again, try to pick the handful of best tools that are gonna meet the needs of the project, roll with those, don't add too many. Last thing before we segue over to Justin again that I've seen is poorly named fields or redundant fields. We wanna have meaningful field names and try to avoid a lot of duplication. Oh, you probably don't need 10 different link fields. You can usually share a lot of different fields. That's really gonna affect more the Sarah developer side of things more than anything else. It's gonna make it more maintainable. Okay, so we set the table, looked at some common architecture problems. But let's take a step back. Let's try to think more strategically about how we organize our content. And so next we're gonna start diving into some design principles and see what we can learn from those ideas. All right, enough with the boring Drupal talk. So I think it's hard to talk about design patterns without recognizing atomic design. So I'm sure there's a lot of you in the room that know what atomic design is. Can I get a show of hands with those? Okay, so I'd say that's a majority. I'll try not to belabor it, but I would like to introduce the concept for those in the room who are not familiar with atomic design. Atomic design is a methodology that was devised by a guy named Brad Frost for creating digital user interfaces by breaking things down to their simplest most essential elements and then putting them back together in a modular system of components which can be used to create extraordinarily consistent and customizable digital products. The popularity of this idea has helped make the concept of software design patterns more accessible to visual designers like myself and has shifted our mindset from designing a series of individual pages to designing this collection of reusable components that can be mixed and matched to create the different pages and sections of your website. In my opinion, this concept is now rather well understood within, we'd say, the development community, the front end development community especially, and within designers now that Frost has brought this to light, but I still think it needs to work its way into the content creation and content editor roles that we all work with, I'm sure. So this quote is likely familiar to most of you. One point of friction with atomic design is how Frost has named his things. So he uses a chemistry metaphor which makes a lot of sense to some people, especially if you read the book, I recommend it to good reads, nice and easy, but to some, it doesn't make really any sense at all. So because of this, many who have adopted this methodology take the concepts and then they apply their own naming conventions that make better sense to their individual teams. Beyond big picture concepts, when we really dig into the work that we're doing, there are all kinds of things that need or already come with names baked into them. So we all have digital properties, we have websites, we have native mobile apps, we have multisites, microsites, landing pages, email campaigns, digital products, and within all of those things, wouldn't it be nice if we could have a consistent naming convention across things like simple things like a button but expanding that out to all the different components? So when it comes down to getting to work, I recommend naming things as a group exercise. And when you do this, I would recommend including participants from all different disciplines. So back end, front end design, content, strategy, potentially even project managers and things like that. Anyone who's really gonna be involved in the creation of the work that you're doing. For one, this exercise promotes collaboration and buy-in to the patterns that you're creating. So from the discussion, but the discussion that ensues around the name of the thing often tends to tease out details of the functionality and can sometimes refine the original idea to a more succinct and reusable component. We'll have some examples of that coming up. I can tell you one thing, tasking one individual person with coming up with this naming convention will only lead to failure directly from the start. As anyone who has to come in and use this system will immediately start questioning why someone made a decision, what they were thinking, what does this mean, what am I supposed to do with this thing. So if you include others in your decision-making and then you take an effort to promote or market that to the rest of the people that you work with and really kind of shop it around and get people to understand it, the better off you're gonna be and the time will be much better spent in the end. So for our pattern library, we examined a body of media currents work over a period of several months and we pulled out patterns that were most common for page building. Does our library include a component for each and everything we've ever built? No, it does not. But we made them generic enough with just the essential markup in bare-bones CSS styles to create a solid foundation that can easily be extended and customized on a per-project basis. Let's take a look at our pattern library here. So we started at the atomic level by breaking down the different components we chose to include in our library. We looked closely at what was required for these components to be effective and what could be optional. Then we applied and documented names that we commonly use between teams to communicate these bits and pieces. Looking at this example, we see five items. We see an image, which we call a media item. We use a broader term here to encompass all types of media that may be used to illustrate or compliment an idea. So you have an image, but you also have a video. So if I call it image, then that excludes video. So media item, I think, is a better term. Next is what we call an eyebrow. It's a common pattern we've seen in displaying often a taxonomy term or a content type or some sort of relevant metadata in smaller text. And it oftentimes displays above a headline, just like you see here. Next are headings, which, as we all know, common HTML element. Here we have two sizes. And next we have a teaser. In a case like this, we often place short snippets of text to pique the interest of the user to, of course, click more or read something that we hope they read. And finally, we have a CTA, short for call to action. These are short links are usually action-oriented and are the primary desired action that we want the user to take with a particular piece of content or a section of the page. This exercise helped us establish a lexicon of atomic level terms. Let's take a look at some of the molecule and organism level components that we developed. So after wireframing, after wireframing, we put all of these components into a living style guide. And so that we have a digital reference, a digital repository of all these things that can show the markup and the CSS for any and every component that we included in this library. So this is what we call our accordion component. This offers a nice way to declutter an otherwise long page of text and allows users to self-select information they need to read most. But we originally called this an FAQ accordion because the idea was born out of repeatedly building FAQ pages. But as we built and discussed it among the team, we realized that the name was limiting the reusability of that. For someone like Jeffrey, having FAQ as part of the name would likely narrow the use case in his mind to frequently ask question content. So we simply just removed FAQ from the name so that the component could be used for any type of content that may need that hide reveal feature that is offered with that accordion. This is our card component. It probably sounds simple to a lot of you or basic, but it took us a little while actually to arrive at the name of card. We started with several different components that were individually called things like spotlight or promo and listing during the wireframing process. But once we started writing the markup, Sarah's concerns came to light. We realized that we were displaying the same atomic level content and could all be combined into a single base component that uses a CSS modifier class to create flexible presentations of the same types of content. So here's what we call card wide. As you can see, it includes the same bits of atomic level content as the card. It's just oriented in a horizontal layout. As mentioned, we simply add a modifier CSS class to the base card component to adjust the layout of the elements. On mobile, it returns to the true card form. Before a realization with the card that I just spoke about, this was called a promo, which was too descriptive yet vague as a name, promo what? Or, oh, can I use this because I'm not really promoting something, I'm just displaying something. So in some person's mind who's not really technically oriented, they might start to question why do I have this thing and what can I do with it? So all along the way we've been considering not just the developer perspective, but also the content editor perspective so that when creating these pages with these components, the names don't mislead or misdirect their purpose. To round out our suite of card components, we put the cards and lists. Here you see card list. The lists are responsive, of course, and can accept any number of items, but typically end up with two, three, or four items with this type of layout. And this is, this one you see here we call card list wide, shocking, I know. It's the same base component, same atomic level elements, same collection of molecules. We just add a modifier class to present the list vertically with the one, third, two, third layout of the content. And responsibly, it becomes a vertical list. Other components in our library include a hero that can be used individually or as a carousel that cycles through a collection of heroes because everyone likes carousels. Every client likes carousels. We have two types of galleries, one that presents a group of media items in a carousel and one with a light box. We also have a form, a map embed, that's a quote, sorry, map embed, which is a large testimonial, of course, and a media item, again, it's just a way of adding a photo, an illustration, a video to any of these components. For us, this was a very collaborative process where we worked with a cross-section of our disciplines in order, again, to create buy-in amongst our teams. We're sharing all of this stuff publicly. Jay will talk about that towards the end of our presentation and you'll be able, you're able to use all of this in your own projects and we'll give you links to all that stuff and we'd love feedback and conversation afterwards if you have anything to add. So now Jay's gonna show you how we've packaged this all up for Drupal and in order to alleviate Sarah's architectural frustrations and in order to streamline the workflow of our friend Jeffrey, who is super frustrated because he doesn't know what to do with the editorial interface. Awesome, thank you, Justin. Okay, so I'm gonna walk you through the next phase of our journey and our time remaining here, it shouldn't take too long. Basically, we're gonna take some of what we learned and we applied it back to the tools that we use, right? For us, the way we implemented patterns, we liked paragraphs as the vehicle for that. The reason we like paragraphs is that they're like, kind of like many content types, they're reusable, you can mix and match and they simplify your content types in that you can delegate some of the content structure over to your paragraphs. So we liked it for that, we liked that paragraphs line up pretty nicely with the components that Justin was walking you through, kind of one to one. So as an example, we've got a quote paragraph. You can see how it lines up, below, and with the style guide above. This is gonna be easier on Sarah, she's got something to work with instead of starting from scratch on all these different common components that we use. Now, Jeffrey, or Jeffrey persona, likes the flexibility they get in that they can mix and match all these different components on the page. So what we do as kind of a general practice is instead of having the ubiquitous, whizzy-wig body field on every content type, as kind of the centerpiece of your content, we have a super paragraph field, again, where you can mix and match all these different components. When we like that workflow, we've seen that Jeffrey likes that workflow, and this isn't something we invented, some other organizations take that approach, and we really like it. What kind of led us in this direction was a couple of years ago, working on habitat redesign, and they really wanted a lot of flexibility. I think what I can tell from the recent years where clients are getting educated on component-driven design, they understand components, what they are, instead of just thinking in terms of the fully rendered page. It's natural that once they understand that concept, again, they want the flexibility to take these components and mix and match them wherever they need them. So just looking briefly at our timeline, we started identifying some patterns a couple of years ago. There was so much overlap in the work that we're doing. Even though we work with a lot of different verticals, different size organizations, we saw there was a lot of overlap. We started identifying some patterns, and we had an early version of our install profile that has these different paragraphs. The next step was we thought, well, let's, again, along the path of reuse here, let's come up with wireframes that we can reuse that. The design team can take advantage of that, and as we're collaborating with the design team and others, we're finding that we're not using the same design language, and Jessyn walked us through some of that. So we're further along the journey as far as getting everybody on the same page in terms of what we label things. And then the next step and kind of the evolution was building out the market for all these components and integrating them in a base theme that we can use. It's all open source, of course. And so just looking at our adoption of content patterns, we think that encourages best practices on our team. Sarah's got the tools to jumpstart development. Jeffrey has flexibility in how he edits the content. And so that's basically our journey. We think it's been successful. You might take a different approach, and that's fine. The number one thing I want you to take away is just that content patterns, the whole idea is just about reuse. So similar with atomic design. You just wanna take advantage of reusing as much as you can, and we want you to think more strategically about how you build your content architecture. So that's the main takeaway. Hope you have some ideas to take home with you that are gonna help your Sarah developers and your Jeffrey predators. A few links before we wrap up here. And we mentioned paragraphs a lot. We dropped a link to a good paragraph session from a couple of years ago. We also have some links to our open source tools. We talked a lot about them. We're also going to release soon our sketch symbols and things like that that we use, wire frames. That could be helpful for some of you. And yeah, we'd love your feedback. We also got a blog post coming right. Yeah, so from the designer's perspective, we do, like Jay mentioned, we do have a sketch symbol library if anyone uses sketch and you're interested in checking this stuff out. We're gonna put a link to it on that tools page. So probably within the next, hopefully, week or so, we'll get that up there. And I'm finishing up a blog post that talks more about naming things and it gives kind of a sort of a dictionary representation of the things that we came up with that we use. Awesome. Okay, quick plug. Love for you to join us on Friday for the Contrib Sprints or Core Sprints, I should say. And that is it. Again, thank you for coming. Would love to get your feedback. Any questions you have, if you have a question for the group, if you can use the mic or if you just wanna talk to us afterwards, that's totally fine too. Thank you, everybody. We've got about five minutes. Yep, go ahead. So, great to see you guys doing this. I've done some very similar kind of stuff. And one of the things that's a question on my mind is with Layout Builder coming, advancing as much as it has, where that kind of positions paragraphs, I mean, have you guys started looking at whether that's a direction to go instead of using that super failed paragraph? Yes, so the question is about Layout Builder versus Paragraphs. Definitely evaluated Layout Builder. It's still kind of in progress. There's some things I like about it and some things I don't like about it as much. I like paragraphs right now. I like the translation workflow. Like a lot of things work really well. We do decoupled sites as well. Paragraphs works really well with the JSON API module. Layout Builder is kind of like hand wavy. I'm not exactly sure. They have a way to export that in decoupled fashion, but we're definitely gonna evaluate whether we want to have a similar approach where we integrate those same components with block entities or something so that they could be leveraged with Layout Builder. And definitely, if you've got some ideas on that, we'd love your feedback if you think, well, hey, that's the direction core is going. Why don't you guys build that into your tooling? I mean, we'll definitely look at it. We're considering it for sure. Okay, thank you. So that was my question. So I'll make up a different one. Make up a new one? Yeah. So I guess like, have you guys, so I'm gonna throw a couple of theoretical questions that you like, what's the average number of paragraphs you're seeing on, say, a page that you make? An average number of paragraphs on a page. It can really vary. It can vary from just a couple to a bunch. I think it's just like, I mean, it's kind of overkill if you get too many on the page. I mean, you're kind of equipping your editors to add whatever they want. So maybe they could add a ton. I haven't seen it on the projects I've worked on. I haven't seen it become a problem or anything. It's usually a handful per page. Yeah, so are you watching the database side of that at all? Because paragraphs has this really nasty habit of exploding databases. So for example, if you had 20 paragraphs on a page and you edited that page and hit save and did nothing other than that, you'd get like 20 new revisions. The revisions is an issue with paragraphs and maybe Drupal Core in general, where I wish they had a cleanup process for older revisions. We have run into an issue on a site with a ton, a lot of content, a lot of revisions where we had to prune the revisions. So that's kind of technical problem. I wish Core just kind of already had a solution for that to just kind of give you a setting to retire older revisions and then you probably be good. There's some contrib modules that can help you with pruning and all that. That's kind of a housekeeping thing, but yeah, I have run into that before. It could be a problem. So the last thing I'd say is just like, as an FYI for you, layout builder was like built, conceived from the beginning to totally prevent that problem. So just like as an FYI, that's a thing that we really set out to make sure it didn't happen in that ecosystem because at least at the scale of clients that I've had to work with here, I've had a client come to me and say, I have a 50 gig table of just paragraph revisions and it's all integers. And I'm like, okay. Yeah, that is a concern. The one last thing on layout builder, I mean, I like it, I like the interface, although it is another interface that's separate. I like that paragraphs already is in the node edit interface that editors are typically pretty comfortable with. And so you give them panels or layout builder, it's cool. It's still another interface I've got to interact with to add the content. There's certainly, yeah, so I'm also gonna talk a little bit about the, so I'm curious, like it'd be cool to see some of these contributions go into layout builder because that's the future and paragraphs is sort of like this best for Drupal. It's like this miracle thing that fixes everything for now, but it'll cause cancer, right? Because you get these revision tables that are huge and then you get these really obnoxious content models and then not only in paragraphs, like we saw someone say, ooh, we're gonna avoid paragraphs. They built everything with nodes and so we have 150 content types of nodes and then it destroys their site. So really the problem is exactly what you talked about. Entity references is the problem. We shouldn't be doing layout and content modeling with entity references necessarily if you have nested entity references after entity reference because even one entity reference may have like 10,000 references to other things. But the thing that really would be cool to see is how you guys could help contribute to layout builder because we need to have all these components you're talking about in layout builder. So being able to bring that would be really cool and there's the whole layout initiatives working on that. So if we need to have that with you. Awesome, yeah, I definitely appreciate that feedback. You're a core contributor, right, so. Yeah, we've been working on that for a while. We've worked on it, you've deviled. Right, we see a lot of these things. So like working and trying to do content syndication and language syndication, paragraphs destroys like that whole model and not just that but any entity reference thing does. And the last thing I would mention is there's a bof going on tomorrow from 1130 to 12 to talk about just that. So if people are having issues with paragraphs or how do I model my content in a way that's atomic but not destroy my site, that's what we're trying to figure out because honestly, paragraphs is the best way to do it right now. Even though we know that it doesn't scale to where we want it to go. Right, yeah, that's kind of the catch 22 we're in. So definitely we're not opposed to having a layout builder kind of approach which kind of captures in essence what we're doing right now. I definitely not opposed to moving that direction. Well, thanks, wonderful talk. Awesome, thank you. Can I ask a quick question on this note here? Since I'm not really a developer, right, I'm a designer and I can understand all the concerns here but like for me as someone who has transitioned from simply a designer to someone who knows some Drupal and then I was in a position where I had to be the guy who made things happen and I saw paragraphs and I'm like, I need to do this because I can't, like the title and body field just isn't working for me and I'm not gonna do all these crazy page templates and like, okay, so that was the thing and I can understand that now it's kind of, the folks like yourselves is becoming like, like you said, a cancer maybe in the long term but how can a designer get, it's not easy for me to contribute to the layout builder. Are there things that they can use from a designer's perspective that isn't pushing code to the repo or whatnot? Right now, no. So the, well, yeah, yeah, right. That's good to know. And the big difference there is that instead of doing like tens or hundreds of entity references to paragraphs in the back end, layout builder actually has a third party setting which is a JSON blob that actually stores all that stuff. So on the back end, the architecture is a little bit more scalable than how the entity reference system works but the end result for you is that you should be able to do exactly what you're doing with paragraphs because at the end of the day, blocks and paragraphs are somewhat similar. They're very similar. Exactly. So I would like to see what the kind of approaches for exporting that data as JSON so that you can have a representation in a decoupled site that works. We've got to get integration with Gatsby and paragraphs that I really like. So if we can do something similar with layout builder in some way, definitely interested in that. I'm not gonna make a comment about layout builder. Oh yeah. Yeah, that's fine. We can move on from that. I work at a university and we have a lot of components. They're built on a bunch of different entity structures. We're looking at paragraphs right now but the main issue that we're realizing is that things are kind of all over the place. We didn't have this process because we've developed these things over years where we carefully thought out, what are we gonna name these things? How are we gonna develop our text on? Do you have any recommendations or have you dealt with a situation like that where you have cleaned up an existing system that kind of had gone out of control and you kind of had a, I don't know, even if maybe you just have some ideas on ways that you might approach that. Well, yesterday it's not exactly your situation because we didn't, the site we were rebuilding and redesigning was a hard-coded site for a library at a university. And yesterday at the library summit, we presented that as sort of a case study of how we went about doing that for the Georgia Tech Library. And we did it also as a Drupal Association webinar about a week ago. I think they have a recording of that. So that might be something to just find the link. If you give me your name, I can get you the link to that and just listen to that. Jay might have other ideas or exposure to other projects where we did something that was more of a migration or I guess in my mind, you would have to start some sort of paragraph structure in the site that you already have and then start to rebuild pages that can utilize that and then just get rid of the old stuff, but okay. Right, I mean, sometimes you just have to, you have a new style guide, you have a new structure and you try to migrate as much as you can from the old model to the new model from the old stuff to the new stuff. And it is a bit of work, but I mean, you have to just look at it as you're in a better place moving forward to spend the extra effort to move from the old system to the new thing. I mean, that's, that's great. I would offer, that's exactly what the woman we worked with, her name was Heather, she was here, but she walked out from Georgia Tech was that even though they had a hard-coded site, it was great for them because we couldn't migrate their content, but they had to go through an exercise internally of looking at analytics and seeing what pages were getting zero, absolutely zero traffic. And for them, that just cleaned out a whole bunch of stuff that they didn't need to deal with, right? So their migration in their case was very much manual, but they were only building pages that were meaningful to people coming to their site. So I could assume that you may have a similar situation where if you looked at Google, you'd be like, wow, okay, we don't even need like maybe 20% of this stuff. So we're in, like Jay said, you're in a better place because now it's a little more maintainable because you don't have old things. I'm more thinking of it from like a functional perspective because our users, we have 1,700 site managers, they're kind of used to this dog's breakfast of all these different kinds of entity structures right now and to tear that apart for them and introduce something new with a new taxonomy, we'd obviously want to do it in the right way where we were kind of starting, I think from ground level, I think that's a good probably, I mean, exposure, maybe they already do, but exposure to the concept of atomic design and how that applies to the websites that they look at. And just getting familiar with, we're not really looking at a page here, we're looking at pieces of things that can be puzzled together. I think that in our experience, the editorial experience shift from a common node edit form that now includes paragraphs is a little bit of a learning curve. People have to understand what they can do with this new interface, but once they're trained on it, which is usually part of the process that we go through at the end of a project is training. So once they're familiar with it, they're like, okay, wow, this is freeing. With that situation of migrating from old to new, it's like you gotta get buy-in from, especially power user types, get them at the table as you make decisions that you bring them along. You take a big effort to move from the old thing to the new thing, and you think the new thing's better, but if you've got buy-in along the way, that's gonna help. Yeah, I was kind of thinking of your workshops for kind of brainstorming the taxonomy name, naming structure, of getting them involved somehow. Absolutely. Yeah, so they were good suggestions. Okay, great. Thank you. Do you have a card? Thank you. So my question would be, so we model very similar as you, but in Drupal 8 you have very different entities to choose from, you have taxonomies, you have media, you have paragraphs, you have content types, you have blocks. Yes. Do you use any best practices, when to use what, when you just model content for a new website? So what I'm thinking of is, for example, we use paragraphs when we don't want to reuse it because we actually want the paragraph to live in the host entity and have it die when the host entity is removed. So that would be our pattern, say okay, for that, that's definitely paragraph, but if you want to reuse it, we would actually create a custom entity and manage that separately because we're not so much fan of paragraph usability because it kind of breaks the simplicity of having a model, how you actually create your content model, I was wondering how you do it. That's a tough question as far as how to evaluate one structure versus the other and paragraphs also has that reusable paragraphs feature which we use sometimes. I think it's really kind of case by case, but we do have these common paragraphs we try to steer people in that direction to say, these are good components for you to use kind of out of the box and so you're gonna use a paragraph structure for that, but as far as whether to use taxonomy, sometimes we use ECK for things that are kind of like more like data, it's not quite a taxonomy, it's not quite a node, you're not sure what it is exactly. I mean, it can be kind of a difficult choice. To me, I like paragraphs for, I kind of think of them interchangeably like with components because they match so well to components and it could be inline blocks next year or whatever, but do you not have like a standard in your company like or somebody that looks over that it's built the same way for maintainability or so? I mean, we try to steer people in the paragraphs direction, we still gotta leave some autonomy to the architects on different projects, we work on all kinds of different projects to give them some flexibility as to what the end content model is gonna look like because it's hard to have a one-size-fits-all, especially for some organizations, just things that are a lot more complex can't say you have to do it this way or that way, they still have to evaluate it. Just try to steer them in this direction to reuse as much as we can and we think in doing that we're streamlining things, we're encouraging reuse, we're not reinventing the wheel or naming the same thing like 10 different things all the time, which can happen at any organization, certainly at an agency. Try to get away from that. So I don't have like an easy answer, like definitely do this, this way or that way. I mean, I try to use paragraphs for a lot. It's kind of my short answer. Okay, thank you very much. Good session, thank you. All right, we ran over, but nobody's in this room, so we did get it. So thank you again very much.