 Hi, everyone. My name is Daniel Vezza, and my talk today is about creating the optimal editorial experience with Layout Builder. It's a very long title. I've stumbled over it a few times, so I'm glad I got through it okay. Like I said, my name is Daniel Vezza. I work at Previous Next as a developer, and I've been using Drupal since about 2014. The slides for this talk are going to be on my GitHub later, or also available at this URL, which unfortunately you can't see. But they'll be on my GitHub, so if you do want to have a look later, please do. My username on Drupal Slack is Daniel Vezza, very original. I mainly hang out in the Australia New Zealand channel. What normally happens with me is I think of 100 questions right after the talk finishes or when I leave the conference. So if you do think of anything, just come talk to me either here or on Slack. So let's start with a Pre-Layout Builder history lesson about what is one of my least favourite forms in Drupal, which is the managed display form. I won't go too far into this form, since I'm sure it's something that we're all pretty familiar with. But I couldn't even begin to count the number of times that I've went and made sweeping changes to this form, especially with something like the display suite, and then just gotten to press save and lost it all. This form has worked in the past and it does still work today for creating content that has a very similar look and feel, it has a lot of consistency, but it has limited ability for the editor to make dynamic content or to see their changes in real time. Sometimes having your content have a very consistent look is a requirement. But the good thing is that with Layout Builder you can still do this. With Layout Builder you can choose whether a content type all looks the same or each individual content item can be overwritten and given its own layout. So by using Layout Builder the consistency that you've got here is not, you're not losing that. So a new requirement's coming and our editors now want the ability to create very dynamic, very cool, very flashy landing pages for the marketing team. We don't have Layout Builder, so what do we do? We reach for our good old friend Paragraphs. I'm sure many of us will be familiar with building dynamic layouts with paragraphs similar to this. But if we step into our poor content editor's boots for a second here, this can be a really tough way to build a page. I mean, what is the page even going to look like? Yeah, I can probably guess what a hero is. I can probably guess what a two column is, a hero with subtext, that's all kind of pretty clear. But what is a wedge image? And what on earth is a horizontal left-aligned five-sided cube? I don't even think a cube can be five-sided. I mean, it's my first day here. I don't know what any of this means. And that leads to revision screens that look like this. They descend or in this case ascend into madness. Our editor has had to make multiple changes to the page each time they've gone in, they've made a change, saved it, looked at the page, gone back again, saved it, looked at the page. And it's just a pain. And I know that this is a bit of a silly example. I mean, I really hope nobody's calling their components a five-sided cube because Layout Builder probably won't really help there. It can only really do so much. And that leads us into the future, or I guess really the present, because Layout Builder has been stable for quite a while now. And how we can actually use Layout Builder to enhance our editorial experience. So to start us off, I've set up a demo site that's using the Umami profile, which comes with Core. Umami uses Layout Builder extensively across its content types, and the benefits, they do become clear right away. I mean, you've got a really visual look on how the website is going to actually look, or how the page is going to look. You can drag and drop these blocks around the page, and you can do everything, adding new content, all just within the page itself. You don't need to go back and forth like you have to with other experiences. So there's just no more guessing on how something's actually going to look. You can just already see it. So it's amazing, right? Things already a lot better for our editors. Unfortunately, just with the time, we don't really have the time to go through a full introduction to everything that Layout Builder can do. But there is a ton of really good information out there around Layout Builder. And a really good place to start is just installing and playing around with this Umami profile in Core. It's got a lot of best practice stuff, and it's a really good way to learn how Layout Builder works. But Layout Builder is scary. These were my thoughts before I started at Preus Next. I had only really played around with Layout Builder. I'd installed things like Umami and had a few tests, but I'd never used it on a proper site, and to be honest, I was a little intimidated by it. We've spent a whole bunch of time building these really consistent, really nice layouts that match our designs, and handing over control to the editors to kind of do whatever they want and build their own pages was a bit of a scary idea. But it doesn't really have to be that way. At the end of the day, both us and the editors want to create the best pages that really show off the site that we've built. So with that in mind, let's enhance our editor's experience with Layout Builder. There are four common modules that we use across our sites that really make this better, and we pretty much use these across everything that we do. So the first module is Layout Builder Claro. It's a very simple theming-only module that requires no configuration, assuming you use the Claro theme. So as a reminder, this is what Layout Builder looks like out of the box. It's pretty nice, but after enabling Layout Builder Claro, everything has just been tidied up to look a little bit cleaner. Things like the ad block links or the ad section links, they pop a bit more. And the off-canvas has also been tidied up. So this is what the off-canvas looks like out of the box. Inside Layout Builder, it's pretty narrow. If you've got a WYSIWYG field like I've got there on the right, it's pretty hard to see what you're doing, especially if you've got a massive bit of content in that WYSIWYG. So with Layout Builder Claro, it's gone a lot wider. So it takes up about a third of the page now. If you're editing a whole bunch of content, it's a lot easier to see what you're actually doing without needing to scroll a bunch. And it gives you a more realistic look at the content. And if you want to go even more extreme, we're proposing to add an advanced mode or an alternate mode into Layout Builder Claro, which takes this again another step further. For the sake of the talk, I've made everything visible. But normally things like the ad block or the ad section links, they only show up when you're hovering over that region, so you're getting a more realistic look of how the page looks. It also displays the name of the region and the section that you're editing. So rather than just seeing that you're editing section one, now you're seeing that you're editing the default region of a default layout, or you're editing the main or the aside region of a two-column layout. It's really just all about giving more clarity and more visibility to the editor to help do their job. We've trialed this on one site so far and the editors really love it. So our Layout Builder looks cleaner. Let's help our editors out some more with the actual editorial process itself. The first module that helps us out with this is Layout Builder Lock. So if we revisit our Layout Builder screen for a moment, on this page here at the bottom we have a two-column layout where it's got an image on the left and there's four boxes on the right. Out of the box they could do something like adding an image to one of those small boxes or adding the entire contents of the body field, which realistically it's not going to look that great. It's going to expand the page. It's going to potentially break out of its layout. And it's things that we don't really want them to be able to do. Layout Builder Lock, it's one of the modules that helps solve these problems for us. So when you're editing a section, you can start checking some of these boxes to restrict what actually can be done here. When I think about it, I try to think of it in the context of a hero section. So a hero section is going to be at the top of the page. It's going to have an image, the page title, maybe some subtext. And it's going to be themed a very specific way to work with specific blocks. So in this case you would start checking most of these options. You don't want the editors to be able to move new blocks into the content. You probably don't want the editor to be able to add content before the hero, because the hero should be at the top. Realistically the only thing you'd want unchecked here is the option to add content after this section because the hero will be at the top. You probably want content to come after it. So this is one way to really help restrict some of those potential breaking moments in the content. And the second module, the next module that helps us with these restrictions is aptly called Layout Builder Restrictions. So out of the box Layout Builder, we've talked about how we don't really have the control that we want. Editors can play fast and loose with the layouts. And there's also an information overload when they try to do something like add a new block. In Layout Builder, every single field and every single block is available for the editors to use. So for example in Umani, when you're editing a recipe, there is 76 blocks that the editor can choose from, which is just way too much. I mean, there's nothing there. Nothing needed. So blocks powered by Drupal are there under System or things like the revision log or the moderation state or the default language. I'm guessing you're probably not going to want the editors to be able to actually use those fields. And that's where Layout Builder Restrictions comes to our rescue. It allows us to choose which of these blocks we actually want to be available to the editor. So at either the section or the region level, you can choose to restrict these blocks. So for example, on this first page, I've said give us no blocks under the system, you know, because that is the stuff like powered by Drupal and a lot of those, the help block I think is another one. It's blocks that you're probably just going to want to wipe the entire section. And the next checkbox is where you can start to choose specific blocks that you either want or you don't want. So in this case, I've chosen to restrict some blocks in the content fields header. And I've just started going down and choosing blocks that I don't want anymore. For example, the ID or the language or default translation. Realistically, those are fields that the editors are not going to want to use. Yeah, I'm guessing it's pretty close to zero the number of times that you've had an editor want to embed the revision log into a page. So when we go back to edit the content after making all of these changes to our restrictions, you can see it's a lot cleaner. We've only got three headings now instead of the seven or eight that we had before. And there's only 20 options now for blocks instead of 76. This is much better for our editor. They don't need to see everything. Let's make it easier for them. And the last module I wanted to cover is layout builder browser. So once again, heading back into our layout builder screen here. Some of these headings aren't really that helpful. I mean, core content fields system. I mean, these might make sense to us knowing Drupal, but if you're just a content editor, I don't think core really makes any sense. What layout builder browser does is it allows us to sort our blocks into better categories that we can define for ourself and the editors can use. So for example, looking at this form, I've taken a content field block in particular the ingredients field. I've given it a new name, which is pretty basic. And the cool thing that layout builder browser gives you is an icon field. So the inside your browser, you can give each block its own dedicated icon. So it sticks out a bit more. In this case, what we've done for some projects is just chosen the material UI icons. Because they just work quite naturally out of the box really well and look quite nice. So what I've done is I've created a whole bunch of browser blocks under the recipe heading, and I've configured my restrictions. So now when we go back to our recipe heading, oh, sorry, our layout builder will be at a block. We have the recipe heading and we have our three new blocks with the nice icons. So instead of saying content fields now that says recipe looks a lot nicer. So we've gone over all four modules and we've had some really quick wins already for making content better and easier to edit for our editors. But there is still a problem with that border out of the box. And that is when it comes to our editors wanting to add fields with layout builder. So our content editor is wanting to add the authored by field to the layout. This makes sense. We have configured our restrictions for our blocks and decided where they can be added. And we've said that yes, we can add the authored by field to this layout. So if we have a look at this image and put on our content editor hat for a second here, does anyone think they can call out what might be difficult for our editor when they're trying to embed this block? Exactly right. So a formatter is something that our editor doesn't really know about or even need to know about. I mean, normally this formatter option is just set on the managed display if you're doing it the other way and that's just hidden from the editor that they don't need to know. But now in layout builder, we're giving them the option to choose a formatter. This is something, yeah, they don't need to know what an editor is when they choose a particular formatter. So let's take that option out of your hands. And this is even worse when you look at the authored by or authored on block. I mean, there's four different options here. If you include all the fields, there's six fields they have to fill out. And if you had custom formatters or extra configuration on top, it's just information overload. It's information they don't need to know. So what we wanted is to have all of this configuration in this case things like the formatter, the time zone and the date format just using default values and hidden. So how did we solve this problem? I've tried to keep this talk pretty light on code itself and instead focused on quick wins that we've been able to have with the modules so far. But I think that this is something that's too important to leave out. So what we have done on a recent project, hopefully that code looks okay. It's created a block plugin for all of the fields that we want the editors to be able to use. So in this case, we start with an abstract class that all of our new block plugins will extend. So in Get Field Item List, the first function, we get the field values from the field that we want to display. And the second function, Get Formatter Settings, is the secret source in the whole setup. In this function, you define things like the formatter settings. So you set them to default values and you take the stuff out of the editors' hands like we talked about, just like you would on the managed display form. And finally, in the build function, you just return a render array of the built field data with the items and the formatter settings. So if we see that in action, it's the authored by a block that we talked about before. So it extends our abstract class that we just looked at. And we're implementing Get Field Item List, where we're getting the node and then from the node, we're simply returning the user ID. And then in the Get Formatter Settings, we're not really doing much. We're just setting the type to Author. Author was one of those formatters that we looked at before. So we're just setting it to a default value. So reminding ourselves the field looked like this before and it looks like this now. So it looks like adding any other block. So all their settings, they don't need to know are gone and the form is a lot easier for the editor to use and to understand. After you've done this, you'd want to add a Layout Builder Browser block, hard to say, for this and configure your restrictions. So you would stop the original field from being able to be edited and make sure that only this new one can be used in your layouts. So Layout Builder is a really awesome tool. It empowers our editors to make dynamic content. It's got a visual layout that's a lot easier to use over the generic kind of node edit form. But it does need some help. With Layout Builder Claro, we make our Layout Builder look a lot nicer. We make the off canvas easier to use and we can even go more extreme and really take out a lot of that extra weight that's on the form and just display the page almost exactly as it will look. We have our three modules, so Layout Builder Restrictions, Layout Builder Lock and Layout Builder Browser that enable us to provide a cleaner editorial experience. These modules help prevent layouts from being broken and they stop information overload for editors when they try to do things like add a new block when they're using Layout Builder. And finally, we have our custom block plugins which take information like the format of settings, takes it out of the editorial, uses hands, and allows them to just focus on the content itself because that's what they do best. I feel like I've really only scratched the surface with how far you can actually go with Layout Builder. Hopefully I've eased some nerves that people like me may have had about using Layout Builder and hopefully I haven't introduced any new ones. Thank you so much for listening. Do we have any questions while there are a few moments to spare? Mike here, so I'll come over to you. I'm going to get captured for the recording. Coming. Have you tried using this with a client theme instead of Claro and if so, did you run into any problems? We haven't... I haven't at least used it with a non-Claro theme but I know that GIN is another really popular admin theme and they have a GIN Layout Builder module. So I assume that might do the same things as what we've done with Layout Builder Claro but I couldn't answer that for sure. Related to GIN, there are modules you use for exposing layouts through API? We've built one little... to coupled Layout Builder experience, I guess, but it was very custom. I think probably these days if you are wanting to build something to coupled, probably it's still a good idea to use the paragraph option, I would say. All right, great presentation. One question is, have you successfully used Layout Builder to replace paragraphs? So instead of there being 20-odd paragraphs on a field, have you in a project successfully used it as kind of like a page builder? Or have you used just Layout Builder purely to just modify the look and feel of a content type? Sorry, I'm just trying to make sure I understand the question. We are using it as a full page builder so we've got, on a recent site that we've just finished, we've got, I don't even know how many components, we've got something like eight custom layouts, and then, I don't know, 50 plus components that the editors can use to build their pages, they all seamlessly work. Well, together kind of thing. So we are using it, and on that site we have no paragraphs at all, like we didn't even have it installed. Kind of related to that question. When you say site editors, do you mean people that can change the layout per node, or do you mean changing the content type, so letting them change the configuration of the site? In terms of the configuration of the site itself, like for example, setting the default layout for a content type, that would still be done by a site editor, like an administrator, because that's all done through configuration management. But editors themselves, like content editors, they can edit how the page looks on a node-by-node basis. For example, on a recent site, landing pages have no default layout, like if you make a landing page, it's a blank slate, and they build the page out totally from scratch. So when I say editors in that context, I mean the content editors. This is the first time I've seen a talk that's focused so heavily on the editorial experience, because usually a lot of Drupal modules are built for site builders or site developers, hence some of the nomenclature and the conflict forms. So my curiosity is, do you have clients that are wanting to focus time on customizing the editorial experience, or is this something that you've found just adds value in another way for people? So yeah, all of the content, I guess, from this talk came from the experience that we've had recently in about a year-long site build. And that's where we've kind of got all the information about where we should be cleaning up the content, like forms, the editors, and making changes to layout builder. It was stuff a lot of the team already knew, but it was some stuff that was new to me, I suppose, so I wanted to share that for anyone else that might be new to layout builder. Are there any other questions? Is your hands down there? I don't know how to get to you from up here. The question about, so for example, when we take your mommy, you have a recipe and ingredients and cooking time is sort of required filled, but layout can be this sort of swipe or slider or whatever, how do you mix required blocks in the layout builder if you remove fields or paragraphs altogether? Yeah, so that was one of the things that layout builder lock fixes, so that what you can do is say servings is a required field. On the default template, you can add the servings block and then when you have layout builder lock, you can say editors cannot remove this block from the page at all and then so if they try to do that, they get a notice that says this block can't be moved or can't be removed, so there is a way to make blocks required in a sense or locked into place. And we're using that on a few slides. Great. Well, thank you Daniel for your talk. We give Daniel a round of applause.