 Hi everyone. I'm going to make a start because the sooner we do this thing, the sooner we get to afternoon tea. So thanks for coming along. It's a bit brutal having three sessions straight after lunch on the last day of the conference. So yeah, thanks for those of you who have hung around. For those of you who don't know me, my name's Angus and I am a content strategist and a sort of part-time Drupal site builder. So just to put this talk in a bit of context, first of all, I'm talking about paragraphs, the Drupal module and site building tool. I'm not talking about paragraphs in any other sense and the kind of perspective that I have on paragraphs is as a site builder and particularly as a content strategist. So I'm not interested in paragraphs as a piece of code. I'm interested in it as a tool that allows us to do things with content. And as a content strategist, I look at tools from the point of view of how well they serve the fundamental goal of most websites, which is to deliver the right content to the right people at the right time. So everything we do, everything we've been talking about over the last two days is fundamentally in service of that goal most of the time. So I'm interested in paragraphs, first of all, because I think it's a great, I wouldn't be talking about it if I didn't think it was a great tool that allowed you to do a lot of things that you haven't been able to do, I guess, in Drupal before, or not without a fair bit of sort of manual piecing things together. But I also think there's a few sort of risks and potential problems involved in using paragraphs without giving it a bit of thought and a bit of planning. And I think I fall into two sort of categories. There's the need to keep our content model coherent and sustainable. So there's the kind of integrity of the content model and paragraphs really needs to be part of that. It needs to be part of what we think of as the overall system that we're using to structure content on our website. And then there's also the author experience. So as a content strategist, one of my roles is to be a bridge between Drupal and content authors. So I spend a lot of time thinking about how easy it is for authors to actually create content. And although paragraphs is a tool that gives authors a lot of flexibility, if we're not careful, we can actually... It's very easy to build something that's actually very difficult for authors to use or to sort of understand. So in this talk, I want to start by giving a very, very brief rundown of paragraphs and what are the kind of use cases for using paragraphs. Just to get an idea, can you put your hand up if you have actually used paragraphs on a Drupal site yourself? Okay, so more than half. And has anyone completely used paragraphs? Does anyone not really know? Okay, so there's a few people. So this will be mainly for your benefit, but it will be brief if you want a sort of more detailed introduction. I'm sure there's also sort of videos, and I know the guys from Morft did a talk at Drupal South last year, which is probably still available. And that was a kind of introductory talk. I feel like since that happened around March last year, paragraphs has really sort of become embedded as a standard part of the Drupal toolkit. So a lot of people are using it. A lot of people are doing really interesting things with it. A lot of developers are taking it in interesting new directions. I'm sort of talking about it more from the basic sort of vanilla point of view of a site builder using it in a kind of out-of-the-box way. And so the second part and the longer part of my talk is going to be about what I see is the ways that paragraphs can go wrong and how can you avoid them. Okay, so what is paragraphs? Well, to start with, let's think about what we can do in traditional, how we can build a kind of traditional content model in Drupal. So Drupal has always been a content management system that is particularly good at content modeling. And especially at that kind of content modeling you can do using UI tools rather than having to delve into code. So the kind of traditional content modeling tools, I sort of think of them as being these five tools. So building blocks are kind of classic content modeling in Drupal. So we can define different content types. We can add fields to them. We can use taxonomy to classify pieces of content. We can use entity references to link one piece of content to another piece of content. And then we can use views to aggregate our content and display it in various sort of flexible ways. So that's your kind of classic content modeling tool in Drupal. And you can do a lot with that. And it's particularly great for capturing content, kinds of content that follow sort of set patterns. So when you think about things like the sort of classic Drupal content types like events, people, places, recipes. You know, recipes is always the example people give of content modeling. You know, so things that pretty much, where you pretty much always got the same elements and you want to display them in the same order. Case studies is another classic one that I use on a lot of sites. So yeah, so we've got these kind of set patterns and we've got lots of examples of them. That classic Drupal tool field of content types and so on is fantastic for modeling them. But not all content follows set predictable patterns. So websites also have things like landing pages. And a landing page is something where authors want to be able to put together a page of, you know, using relatively sort of complex structural kind of elements, but they want to be able to choose which elements they use on which page and what order they go in. Home pages, which are really just sort of a special case of a landing page. You know, home pages, the problem we always have with home pages, especially in Drupal, I think is that we hand over a design for a home page, we build the home page and give it to the content author and they come back and say, okay, well this is great, but how do we change things on this home page? And often we haven't really got a good answer for that. Longform articles. So I'm thinking about the kind of articles that might have a video, maybe an infographic, maybe a sort of an audience poll, and an image gallery kind of inserted in the body of the article. Again, authors want to be able to choose where they're putting those things. So we've always been able to give authors a video field on an article content type. But in Classic Drupal we have to choose one place where that video field goes on every article and authors might not want the video to be displayed at the beginning of the article, they might want it to be in the middle. And any kind of multi-part sort of content. So if you think of any of those kind of long scrolling pages that you see everywhere on the web these days, maybe with some kind of in-page navigation. So things like, you know, annual reports, sales pages, any of these kinds of content where authors basically want to be able to put together a piece of content out of building blocks. There are things that aren't very well catered for by the kind of classic content model. And the typical solutions that we've given authors in the past, you know, range from the very old-fashioned idea of doing early layout in the body field. So, you know, just use tables. It's really easy. The big bunch of blocks, so, you know, putting a page together out of blocks. And, you know, panels is obviously a solution that we've given people to have a certain amount of flexibility in the way they arrange a page. But there's a number of problems, I think, with all of those solutions. And the fundamental one for me is that the web is moving in a sort of different direction than the way that a lot of, you know, the kind of thing that the load those solutions were defined for. So if you think of sort of a lot of those classic theoretical solutions, they rely on the idea of regions. And, you know, a page having kind of fixed regions. You have the old page, you've got a region at the top, then you've got a left sidebar and a main content area and a right sidebar and then a footer down the bottom. And every page is going to have the same sort of regions. There's a kind of classic sort of Drupal model of how a page layout works. But, you know, the web these days is moving much more towards these kinds of layouts where pages are essentially a sort of a flexible sort of stacked collection of elements. There's really just one big column. But within that column you've got sort of slices that, depending on the device that you're looking at, you know, might be divided into columns or into a grid. But they'll also adapt to mobile devices. So essentially once you get down to a smartphone, everything you're looking at is going to be in sort of one big column. And those traditional Drupal solutions don't really, don't really cope well with that kind of structure. So into paragraphs. So paragraphs is a contributed module. It's available for both Drupal 7 and Drupal 8. I've mainly used it in Drupal 7, although the screenshots I'm going to be showing you are from a Drupal 8 sort of demo installation. But, you know, it's available for both. There are slight differences between the two. So what is paragraphs? Well, in Drupal terms, paragraphs basically creates a new entity type. And it's a type of entity that is specifically designed to be created and embedded within other entities. So essentially a paragraph is an entity that only exists within another entity. So that's the kind of technical Drupal way of explaining it. The way I explain it to clients and to content authors is that paragraphs basically gives you a set of building blocks for putting together a page. It's very flexible because you can define different types of building blocks. And authors can add those building blocks to the page in whatever order they like. And then once they've created those building blocks, they can also sort of drag and drop them so they can actually change the order at any time. And so, you know, the basic way that you implement paragraphs, obviously you download and install the module. And the module will give you a new item in your structure menu called paragraph types. It's called paragraph types in Drupal 8. It's using the term paragraph bundles in Drupal 7. Bundles is kind of Drupalese for a subtype of an entity type, but not a terribly auth-friendly name. I don't think so. I'm glad they changed the name to paragraph types, which is obviously, you can see the analogy there with content types. So you can create paragraph types in exactly the same kind of way that you create content types. You can add fields to them. Paragraphs uses the field UI, so you can use any of the same kinds of fields that you use in a content type. And then once you've got those paragraph types created, you add a paragraph field to your host entity, so your content type, for example. And then you make it a multi-value field. That means the authors can add in as many paragraphs as they like, individual paragraphs as they like. They can choose what types of paragraphs they use. They can combine different types of paragraphs in a single field, and they can arrange them in any order. So another way that I've heard it explained is it's a bit like field collection on steroids, but whereas field collection only allows you to add one type of thing in a field, paragraphs allows you to combine all kinds of different types of things in a single field. So I'll give you some examples of sites that use paragraphs. These are just a few just to give you a bit of an idea. So this one... This is actually a demo site for paragraphs that the guys at Morft created, but obviously it's using paragraphs itself. So you can see it's basically just a series of sort of vertically arranged kind of components that if I showed it on mobile, it would be nicely responsive. So you can obviously target those individual components, front-end developers can target them and make them all nice and responsive. This one is one of the first sites that I came across that used paragraphs. This is the Department of Communications. It's actually the first site to be launched on Dutch CMS, built I believe by Acquia and previous Next. And I didn't have anything to do with the build of this site, but I did get to see the back-end. And it uses paragraphs quite extensively. One of the things it uses is a forest for these sort of different channel pages, so pages that describe the different areas that the Department of Commons works in. And you can see that, again, the pages are being built out of this sort of stack of components. And once again, authors can go in and change the order of things at new components anytime they like. And I'll just show you one that we did at Weave. This is for the Energy and Water Ombudsman in Victoria. I'm just going to go to a report. So we sort of created this report content type, because this client had a lot of reports that were considered or sort of multiple sections that were a mixture of different kinds of things. So they had things like this that was sort of huge, great infographics, but they also had sections that were text. They had this standard section called the Ombudsman's View, which is in every one of these reports. So we're actually using paragraphs here, both for this in-page navigation. We're sort of using two levels of paragraphs, so the top level controls the navigation, and then there's a level, a sort of nested level of paragraphs that contains the actual content. So one of the things that paragraphs allows you to do is take existing content, which might not be ideal, and kind of build a sort of a minimum Bible product version of a page, and then sort of add things to it later without completely recreating the content type. So in this case, Ewof has these ridiculous huge... This entire section is one big image, which is obviously less than ideal from an accessibility point of view and from a responsive point of view, and we're really encouraging them to rethink the way they publish these kinds of reports, but they had a whole lot of existing... They had a backlog of existing content, so what we could do is we could say, well, we're going to use this system, and we're going to include a paragraph type that allows you to just dump in one of these big infographics, but then we're going to work with you on a better solution later on for publishing this kind of data, and that could be almost anything that could write up to full-on the proper sort of data visualization using data from some part of that end. And paragraphs actually allows you to do that because we know that we can just create a new paragraph type for whatever solution we come up with in the future, rather than having to go in and rebuild the entire content type. Okay, so that's some examples. 2%. Okay. Now, there are some alternatives to using paragraphs. I'm not going to go into much detail about this, but the people at Chapter 3 wrote a blog post about what they prefer to use instead, which is basically using inline entity form and creating custom entities. You can read their blog post if you're interested. Personally, I don't find it a terribly convincing argument for not using paragraphs, but I guess one of the things about paragraphs is that the entities you create using paragraphs are completely dependent on that kind of host entity. So if for some reason you need to create individual paragraphs that have their own authors or that will continue to exist if you delete the thing that they're part of, then you need to use another solution of paragraphs. Paragraphs is really designed to be entirely dependent on whatever you're sort of putting them in. But, you know, the big advantage of paragraphs compared to a sort of roll-your-own system is that it's lightweight, it works out of the box, and there's also a growing ecosystem of sort of supporting modules that some developers are coming up with. So another option is to actually just add... to actually add something to the wissy-wig to allow editors to embed things within a standard body field. And there's two modules that I know of that are designed around that kind of model. One is wissy-wig fields, which was created by the reality loop... let's do it over here. Reality loop people, which basically allows you to add a button to your wissy-wig toolbar to insert a field. And there's another one called entity embed, which allows you to add a button to your toolbar to insert an entity as opposed to a field. So they're both ways of inserting a component into our body field using a wissy-wig. You can see how that gives authors some of the same abilities that Paragraphs would. It's just taking a totally different approach to it. So I'm going to talk a bit later about why this is actually a really good model for particular use cases. But I don't necessarily see it as an alternative to Paragraphs. I see it as something that is, you know, probably ideally used in conjunction with Paragraphs. Okay, so that's my very brief run down of Paragraphs. I'm going to talk about how Paragraphs can go wrong and how to avoid them going on. This really comes from, well, it's partly inspired by a conversation on Twitter between Renee, Stephen and Jeff Eaton. So Renee starts out by saying, I don't know how I feel about Paragraphs, you guys. It encourages a lot of really sloppy content modeling, or zero. And Jeff Eaton replies, like many things in Drupal, it allows for well-modeled content, but it's up to the site builder to ensure it's not a mess. And Renee replies, that is a really, really huge butt, though. It's the biggest weak point I see on all the sites I get to lay hands on by far. So I sort of decided to, I guess, take up this discussion and run with it a bit. So what are some of the ways in which it can go wrong? Well, to start with, you know, one of the things that I've found with the Drupal community is that Drupal people really get the fundamental idea of content modeling because Drupal is so dependent on content types and we have content types just as a thing out of the box in Drupal. Drupal people tend to have learned by a kind of trial and error and maybe from some bad experiences how to do content modeling well. So I'm talking about things like not creating more content types than you need, being careful about how you name content types, not, you know, fields within content types, not, you know, trying to take a consistent approach, reusing fields, all that kind of thing that people in Drupal just tend to get. But I have a feeling that as a community we need to relearn some of those principles for paragraphs and I think there's five particular ways in which either I've seen paragraphs go wrong or I can see the potential for paragraphs to go wrong. And there to do with poor naming, it's probably, you know, if there's one thing, one thing I'd like people to take away is the importance of good naming when we're creating paragraph types. Lack of planning, so just an ad hoc approach, creating paragraph types just as we need them. Mixing content and presentation, issues with the editing interface and excessive complexity. So I'm gonna go through what I mean by each of those. So first of all, poor naming. Well, let's start with the name paragraphs itself. Let's be honest, it's a terrible name. There's actually an issue on the module page where somebody's trying to convince the guy who created the module to change the name and he won't have a bar of it. But it is a terrible name because we already have at least two things in the world outside Drupal called paragraphs. We have an HTML element, things that are enclosed in P tags, paragraphs. We also have a unit of language and we know what a paragraph means in the everyday world. So for Drupal to come along and say, well, we've got this new thing called paragraphs, it just causes a lot of confusion. So let's accept that we can't change the name of the module at this stage, although if anyone wants to keep up that fight, go right ahead. Maybe when it gets into core, someone will change the name. But let's at least hide it from authors. One of the things that I've always found enduring about Drupal is that it will come up with this very weird jargon, but then it's almost like there's an unconscious kind of acknowledgement that we need to hide it away from authors. So that's why we have an add content button, not an add node button, for instance. So paragraphs actually allows you to do this in a really nice flexible way. Within the settings for how you display paragraphs, when you're adding a paragraph field to a content type, you can actually change what you call paragraphs. So how do you present paragraphs to authors? So I will always go in and change that to something like sections or components. You could use chunks. Anyone used anything else? Yes, slices I've seen before. Modules is a kind of word here. People have come from other CNSs where modules are a bit more like what we call blocks and jungler as well, I think. Okay, so that's one thing to me. That's a basic part of any kind of paragraphs that I don't call them paragraphs to authors. We've then got naming of individual paragraph types. So there's potential for us to... And remember that when authors are going into create paragraphs, we're basically giving them a big list of types to choose from, in the same way that we do with content types. So it's important that we're not confusing them with these names, that they know what... When they choose a paragraph type, they know what they're actually going to get. Yeah, also ad hoc. So are we creating paragraph types that are based on a single use case and giving them names that are too specific? Or are we giving them names that are coupled to presentation? And I'll talk about these things. These are related to other issues that I'm going to talk about. So rather than spending a lot of time on them now, I'll move on to those other issues. So okay, lack of planning. So because paragraphs is... It's something that we sell to clients. It's something that's going to give them a lot of flexibility. And there's almost an implicit promise there that whatever they want to do, whatever weird kind of little content structure they want to add to their pages, we can make it for them. So I think if we're not careful, that can lead to a real mess of kind of ad hoc paragraph types. So we're creating a paragraph type for a single use case because some content author insisted that they wanted one particular thing on one page. Or paragraphs with too many similar sounding names. So we've got one called a highlight box and one called a highlight area and one called a highlight weird or something like that. It can lead to a lack of... just an overall lack of discipline. So just a feeling that our paragraph types are kind of getting away from us. In a way, the content types, you've all seen bad Drupal sites. We just have content types, right? Some of which are created for single pages and just over complexity. So what's the solution? Well, the solution is to plan our paragraphs in the same way but hopefully we plan our content types. So what that means is whenever our process is for planning our content types, and for me it's always basically an audit of existing content, we need to be looking at that content not just from the point of view of what types of content do we have but also, you know, is this a type of content that could benefit from paragraphs and if so, what are the components that we might need as part of this content type? And then putting some guidelines in place. So we're not blocking off... we don't want to block off the possibility of creating new paragraph types because that is one of the cool things about paragraphs. But let's put some guidelines in place for a new paragraph type in its place. So let's not say we're going to create a new paragraph type every time a content author asks us to. Let's actually set some criteria for when a new paragraph type gets its currency. So it's really a governance... it's really a content governance issue. Okay, so that's planning. Mixing content and presentation and I could easily give an insight talk about this but this is going back to the idea that entities in Drupal are content and content... a piece of content is not a page. It's what pages are created from. So just as Drupal developers like to separate content from configuration, those of us in the content strategy world are obsessed with separating content from presentation. And the reason for that is that as we move to a more decoupled world where we want to have things like headless Drupal sites where the content is in one place and the front-end of the site is created in another place or that kind of idea of content API where we want to be able to distribute our content to various different places, it becomes more and more important that we're not storing our content in a way that presupposes a certain form of presentation. And what that means is, and I'm sorry to say this because I have... I do seem to be seeing this all live but people will create... people will treat paragraphs as a way of creating layouts, whereas if we're serious about... paragraphs are part of our content, they're not part of our layout system. So if we're serious about this idea of separating content from presentation, what we want to do is treat paragraphs as structures, not as layouts. And that can be as simple as, again, a naming issue. So, for example... so it can just be a matter of avoiding that kind of presentational logic when we're naming paragraph types or paragraph bundles in their fields. So if we want to call a paragraph type something like a 3-column promo grid, maybe we call it a 3-item promo section instead. There's something that's agnostic about how it's actually going to be displayed. Text beneath image could become text associated with image. Blue background text box, highlighted text box, that way when someone comes in, when the client's brand color's changed and they can't use blue anymore, we can just change the CSS and it doesn't matter. Now this stuff is important because every time you name something, you are giving authors an expectation that that's how they're going to work. I've lost count of the number of times I've seen authors because they expect something to be lined up in columns, they'll actually write text that says see on the right for the next step or they'll add images that have little arrows in them. So the more we can train authors not to... this is one of the reasons for getting away from a wissily-based editing interface. So the more we can train authors to think about their content as in terms of its semantic structure rather than a specific form of presentation, the more kind of future-friendly and adaptable our content is going to be. Editing interface issues. Just going to whip through this. The editing interface is a big issue for paragraphs and there are smart people like Stuart working on... Stuart was telling me about an amazing thing that he's working on that is going to make this all better. But in the meantime, just a little tip. If you've added a paragraph... if you've added a paragraph field to a content type, you'll notice there's three options for how you display the paragraphs to authors in the editing interface. The first one is called Open and that just displays all the information from the paragraph within the interface. And that's fine until you add more than a couple of paragraphs and then you can see you're basically displaying a lot of information and then expecting authors to use those little drag-and-drop handles to kind of move it around. So it just becomes information overload for authors and very hard to work with. Then we have a closed option which displays nothing except for the type of paragraph. A lot easier to drag-and-drop with the trouble is if you've got more than one of the same type of paragraph, authors have no idea of what they're actually dragging and dropping because all they know is an image with caption. They don't know which image it is. So, fortunately, there is an answer which is the preview mode. The preview allows you to select usually one field from each paragraph type to display it. The authors are preview of what it is that they're actually working with. In both of those, by the way, that edit button on the right will actually expand the individual paragraph so you can go in and edit it. So this is more for getting that kind of overview. So that's great, but how do you actually do this? And it took me a while. I mean, I am a bit dim sometimes, but it took me a while to work out how to actually do this. So just in case anybody hasn't worked this out for themselves, it's actually a custom view mode within each paragraph type. So it doesn't mean that you have to go into each paragraph type, go to manage display, select preview on the custom display settings, and then create a display mode for that preview. And again, you need to do that for every individual paragraph type. And then you can go back and select preview as your editing mode. So it's a bit more work, but well worth it. The other thing to do with the authoring interface is paragraphs even the right tool. So paragraphs works well where our content is kind of intrinsically chunky. Where our content is very much divided into individual components. So that kind of landing page or that kind of multi-section sort of report, that kind of thing works really well with paragraphs. Where it can be sort of trickier for authors to understand is when we have long-form articles where essentially the mental model that the author has is that they're writing one long piece of content that's just kind of punctuated or interrupted by bits of media or other things at various points. So really what we've got is a single narrative that just happens to have things kind of scattered through it. And this is where a solution like Wissiwick Fields can be really good because you're still giving authors that body field. They're entering the article as one thing. But you can then give them the ability to add these kind of structured elements, that they're adding them in a well-structured way rather than trying to essentially add them as inline elements within the body field. So something like Wissiwick Fields in combination with paragraphs because Wissiwick Fields allows you to add any kind of field including a paragraphs field. So I think the two can work together really well for use cases like this. Excessive complexity. So we've already talked about the example of having just having too many paragraph bundles. Every extra kind of thing you create in Drupal creates an extra cognitive load on authors. It's more complexity. But another thing Paragraphs allows you to do is to nest paragraphs within paragraphs. And really, really easy to create something like this. So, yeah, I want to call the hall of mirrors in paragraphs. So I think a certain amount of controlled nesting is fine within paragraphs, and we've used that ourselves in that A-wob example. But really important that you go in and then limit the specific paragraphs types that authors can add within each field to actually prevent them from doing that kind of infinite recursion that you saw in that example. So, yeah, so again, it's a bit of extra work because you do have to go into every field where you've added paragraphs and make a decision about what paragraph types you can allow. But it's worth it to avoid authors from getting into all kinds of trouble. So, yeah, so that's my thoughts about how paragraphs can go wrong and how we can avoid that. I guess what I'd like to conclude on is I'm really, as a content strategy person, I've been really pleased to see over the last, probably the last couple of years, how seriously the Drupal community has started to take author experience. And you've seen lots of leadership from people like Dries on this. You've seen lots of initiatives that are to do with making the authoring interface better. Obviously Drupal 8, this is a really high priority in Drupal 8 overall. So, as someone who works with content authors a lot, I think this is fantastic and I'm really grateful for it. What I'd like to see is that we make paragraphs part of that effort, that we don't get carried away by the flexibility that paragraphs offers authors and end up just giving them too much complexity. So, that's my thoughts. Thanks, thanks everyone. Happy to... Well, I'm probably... I mean, happy to take questions, but I'm also interested in your experiences with paragraphs and maybe any lessons that you've learned because I know it's something a lot of people have started using over the last couple of years. So, yeah, really interested to hear. Like the last time I used it, and I guess a couple of months ago now, the problem was the document... lack of documentation, I guess basically what the presentation just gave, right? There's nothing out there to kind of... although I could find that adequately explains naming conventions and that kind of thing. So, like I said, I ditched that. How do you see that overcome documentation for paragraphs? Did you find that yourself? Is there documentation like that for anything in Drupal? Yeah, I think it's a big problem in not just paragraphs, but in Drupal more generally. I don't know. Maybe people will watch... will watch my slides, I don't know. But, yeah, I definitely like to start that discussion for sure. Yeah, I don't even think we've got this right ourselves. A lot of what I've been saying here is stuff that we've done ourselves, just because it's something new, and it's like... I got so excited when someone explained the concept of paragraphs to me, it's like, oh my God, Eureka, this is exactly what we've been waiting for. So I think there was an initial kind of over-exuberance, and I also have a habit of building completely ridiculously over-engineered content models as well, because I'm a content modelling geek, so... you know, if there's a content modelling mistake about their iPod, I've definitely made it, and I don't think paragraphs have any exception to that. In terms of naming conventions, I mean, what I was saying about separating content from presentation, there's a kind of... there is a tension between that and clear naming, because it's obviously... it can be easier for authors to understand a name if they know... if you do give them a bit of presentation information in the name. So I sort of recognise that I'm, in a way, recommending two different... you know, two slightly conflicting things, and it is about finding a compromise, and I do think that the... the idea of separating content from presentation is an ideal that we're never actually going to reach, because content and presentation just are inherently mixed up, but I do think it's something we should be aware of, and we should be asking ourselves, especially when we say, this is a three-column thing, well, most... more than 50% of visitors to a lot of our websites are now viewing them on mobile phones, and they're never going to see that three-column thing as a three-column thing. So if we're taking a mobile-first approach, what we should really say is, well, this is a three... this is three items that, you know, for the users who have the luxury of viewing this on a big screen, they'll get to see this as three columns, but most of our users actually won't. Yeah. There's obviously a lot of training for Authors and Dog as well, but naming's a good start. If you can avoid giving something a name that's going to make an author assuming that it's going to be displayed in a certain way, that's a really good start. Thank you for the talk. It was wonderful. Especially, like, I've used paragraphs that I haven't come into the situation of actually building the paragraphs yet, and I'm about to do that in the project that I'm currently working on. But I did want to touch on two things. One is, as you said, there's something that I've got in the pipeline. It's not something that I've started developing yet, but it's an idea I've had over the last few months, which is basically the male chimp experience for paragraphs. It's, like, a list of drag-and-dropable items of, like, these are paragraph types that we would like to use, drag them onto the actual preview of the page and give that experience. Like, you will get to see what you're building, and you... Like, the whole field system, the drag-and-dropping of fields, the Drupal field system, full stop, it's archaic and it's not a good experience for users. So, I mean, that's one of my major issues that I've seen. Which I'm not necessarily thinking of a solution. At the moment, I'm just sort of hoping that someone else has actually come across some sort of ideas for this, which is... And something that you didn't touch on is the biggest problem I see is giving too much freedom to a content creator. And it's like, here are a whole bunch of paragraph types go for it. And I think that is somewhat what that discussion on Twitter was somewhat pointing out as well. That was my interpretation of it. It's like, image gallery, image gallery, image gallery, image gallery, image gallery. Like, what's stopping you? There's nothing stopping you. There's no layout system. There's not like, hey, I want to have, you know, the whole...the point of the content type system in Drupal is like, a page will look like this. It's going to have a set type of structure. A blog page will look like this and so on. Like, when you have a landing page, it's like, you're going to have some predefined styles like this is the way we want it to look, but there's nothing enforcing that. So if anyone's got ideas, I'd love to hear about it. Even if it's just like a, maybe a set of sort of pre-filled templates that you could choose from, that kind of thing. There is a module that's fairly new called Paragraph Profiles, which pretty much handles setting up sort of generic profiles with pre-added default models, which don't have content in them, but will pre-populate the node when you create a new one. So we've actually combined the paragraphs with that sort of reusable elements as well, like inline entity form and a custom entity type, and then made a paragraph type that is a reusable thing so you can include sort of like, a paragraph type that is a reusable thing. So we've actually combined the paragraphs with that sort of reusable element as well, which is a reusable thing, so you can include sort of like a call to action in the middle of your pages as well. So I thought that was interesting to work on here. Thanks, Ricky. Yeah. I mean, the possibilities are endless. You can obviously include block, you know, block references within paragraphs would be another way of doing something similar. Another thing we use paragraphs for a lot is news. So just creating a paragraph type, which is essentially a view field, just to allow authors to, or not necessarily authors, because authors don't tend to work a lot with you, but to allow us to have flexibility about where we actually put a view on a page. So yeah. I think we're almost out of time, and I'm sure everyone's ready for afternoon tea, so happy to continue the discussion more informally, but thanks everyone for coming.