 So I'm going to talk a little bit about how to get people to like Drupal and specifically how to get your content editors on board with Drupal. Just a bit of an intro about me before I start. My name is Suzanne Darvacheva. I work at Evolving Web where I Drupal shop based in Montreal and we just do Drupal projects. I do a lot of theming, site building, sometimes module development or project management. And you can follow me on Twitter at Suzanne underscore Kennedy. We work with lots of different types of clients on lots of different types of Drupal projects. And I run the training program at Evolving Web. So I spend a lot of time working with people on their Drupal sites, maybe after they're built or while they're being built. I help people with a lot of best practices and that kind of thing. And we have some training coming up in Ottawa, also in Toronto for you Toronto folks in September and October and all that information is on our website or you can come talk to me afterwards. There's actually some conflums in the back as well if you want to get a discount code for the training. So to jump into the topic of the session today, we're going to talk a little bit about how to improve your website and how to think about content editors as you're doing that. So I'm going to kind of talk about how to do this throughout the process of building your Drupal site. So just to get an idea, how many of you are Drupal site builders or will be Drupal site builders? Yeah. So we often think when we're putting together a site about the user experience for our end users, like the people who are going to be using the site on the front end. But it's also very important to think about how people are going to be using the site on the back end. And arguably the back end is more complicated and those people are actually creating content for your site and that's going to have a big impact on the value of the site, like the fact that people are actually putting together good content. So right off the bat, you want to be thinking about who your content editors are. And you know, you might be creating content as you're building the site, but the people who will end up managing that site after the site is launched often wear many hats. So often content editors, they're not just people who sit around editing Drupal site, they often have a lot of other responsibilities. So they're often administrators or they're content experts or maybe they have another job and that's just a small piece of what they do. Sometimes they work a lot with documents or they're translators. So technical, non-technical people, it's really a wide range. You're sitting down and thinking about who these people are and maybe even doing some research to find out who's actually going to be updating the content before you start designing an interface for them. And in general, when you're thinking about the content editing UI, there's some goals that you can keep in mind, some high level goals. So first of all, you want to make sure that the site is familiar to your content editors. So any terminology that is being used at your organization or the site's organization, you want to make sure that you're reflecting that terminology in the content editing UI. So words that they're using to describe things, you can use those in help text and labels in the whole interface. You want to have predictable results. So that means when somebody clicks save, when they're editing content and they're publishing something or changing a component, they should be able to predict what's going to happen. It shouldn't be like a big surprise that they click save and they see something on the page. So if an image gets resized or there's a certain field that's required to make the page look good, those things should be indicated in the edit UI. So you just want to make sure that it's always a predictable result as much as possible. You want to have clear pathways for key tasks, so just like on the front end of your site where you have nice calls to action and clear and navigation, you also want to have this for your content editors. So even if it's just a simple menu with key editing links, you want to make sure that those are planned out and available for your editors. And as much as possible, you want to have built some documentation. So sometimes when we're putting together a proposal for a project, we talk about creating at the end of the project some documentation. But oftentimes that documentation doesn't get used very much or it gets out of date quickly. So it's useful to have documentation just built into the interface of your site for content editors and that way they don't have to look up some information in a reference manual to know what a content type is or what a field is going to do. They just have that information right in front of them in the UI. And there's different ways of doing that. We'll talk about it very soon. I'm going to go through and talk about some specific components of the UI. And I'm going to start with just the overall interface. And I'm going to start with something that seems really simple but is important, especially since we're here in Ottawa and a lot of us are building multilingual websites. So we take it for granted when we install Drupal, but it's usually installed in English and we're editing it in English. But often if you have a multilingual website, it's actually possible that someone will be editing the site in other languages. So in Drupal 8 there's a great feature that allows administrators to pick their language. And that's going to switch the admin UI into that language even if they're editing content in other languages. So this means if someone hits translate and translates something into French or Spanish or Portuguese or whatever language, the site will always still be in English with the interface. And that's an important thing to just make sure you set up on the site because otherwise it can be really disorienting to be switching languages all the time if your editors aren't bilingual or multilingual. The theme. So another overall UI thing to consider is just the look and feel of the back end of the site. And as you may know, the back end of Drupal is just as flexible as the front end in terms of look and feel. So anything that you can do in terms of steaming you can also do for the admin UI. So if you need to change just even minor changes to the visuals, adding icons, moving things around, reprioritizing just with emphasis, these are things that you can do with a theme. And if you like the admin theme that you currently have, the default admin theme or another contributed theme, you can always make tweets to that with a theme. So incredibly flexible with Drupal and something you should just keep in mind is easy to do. Once a content editor actually accesses the admin UI of Drupal, the first thing they're going to be doing is probably looking for content that they need to edit or looking at how to add content. And there's always some key tasks that they should have access to. And one of the first things that they're going to be looking for is where all the content is. And we know as Drupal people that you can just look for the content on the front end and you can edit it that way or you can go over to the content overview page. But this page can be kind of overwhelming like if you've got thousands of pieces of content on your site, it's a lot for a content editor to go through. So it's important to keep in mind as a site builder that this page is very flexible. This is just a default page that lists everything, but you can go and add filters to this page. You can add columns. This is a view. In Drupalite the content overview page is just a view. So it's completely configurable. And you can also create additional content pages. So having just a single content page for thousands of nodes and maybe 15 different content types, it's a lot to fit into one page. So it might be more appropriate to have separate content editing, content overview pages for specific content types. That way you'll be able to add specific filters at the top and columns that make sense for that content. So for example if you have a press release content type and you're using some kind of tagging vocabulary for it, you can create a separate view for that by cloning this. And then you can add a filter for the tags at the top. So this is an example with recipes. So same kind of thing. You have a recipes tab. This is just another version of the content overview page and it's got a filter for cuisine. So it makes things really easy to find. In addition to just content listing pages, it's also possible to create a dashboard. So if you wanted to have multiple views of content that you combine into one, you can set these views up as blocks and then place them on a dashboard page. So just like I said, the front end, the back end of Drupal, they're the same flexibility. There's nothing stopping you from putting more than one content listing on a given page. I think that I would put at the top of the list of things to consider when you're setting up your content editing UI are permissions. So permissions in Drupal are what allows people to do different tasks and when you are editing Drupal as an administrator, you have permission to do everything. So you really get a lot of admin pages that you have access to. And for content editors, this would be really overwhelming. So giving just somebody who has never seen Drupal before permission to do everything just means that they're going to have access to all these pages and all this terminology that they're not familiar with. So if your content editors, they'll never have to edit view modes, for example, or content types or views. If that's true, you should just hide that interface from them by removing those permissions. And in Drupal, when you remove a permission, you remove access to a page, you remove it from the menu. So it's the easiest way to simplify the admin UI. And typically, you know, this process is going to involve creating specific roles for different types of users and then going in and assigning the permissions. And I know a lot of you know all about this. You know that you need to make permissions. You know you need to make roles. But one of the key things to success is making sure that you're doing this earlier on in the site building process. So don't wait until the end of the project to say, oh yeah, I'm meaning to have authors and editors. So let's set up some roles. You should try and do this early enough that you have time to test and adapt the site, set up specific things like navigation for these users and really do proper testing of their user experience. So essential permissions that I would make sure you have for your content editors. Of course, node editing, sometimes block editing. So you want to consider other content editing other than just nodes. Adding menu items, text formats, text formats are different. I'm going to talk about this later, but just different ways of displaying content. You'll have to assign those to content editors as well. Access to them in taxonomy, menus, I already mentioned, media, web forms sometimes, and sometimes block placement. So these last two involve actually a bit more complex configuration. And one thing to keep in mind is that if you give your content editors access to due configuration on the site, that means that you'll have to have a way to manage that configuration and make sure that you're not overriding that with any development changes that get launched on the site. So that's because Drupal 8 has a configuration management tool that you'll probably use to manage this configuration on your site. And if you take that configuration from your development site and you import it on your live site, that's going to override any block changes or any other configuration that's been done. So if you give permission for editors to do those kind of changes, you just need to make sure that you're tracking that so you don't override it on them. Key tasks in Drupal site building is setting up content types. And when you're setting up content types, usually your focus is on the actual content. It's on creating the pages of content on the site for end users and making sure that they look good and all of that kind of thing. But when you're creating a content type, you're also building the interface for offering that content for your content editors. So the exact same process of creating that content type is also creating this interface. And usually we don't think about this when we're doing site building because we're so eager to get the content onto the site that we don't think about the UI that we're building. So when you're setting up your content types, each content type is added to this page. When you click add content, you see the list of content types. And if content editors are using this as their main interface for selecting the content type, it's important that the content types make sense to them. So you want to pick the content type names carefully. Having content type names like data or entity are really not helpful. You want to make sure that the names make sense. And then if you have relationships between the content or if you're using the content in a way that might not be obvious, you just want to make sure you're including that in the description. So the title and the description of the content type are really easy, but you just want to make sure that that information is there and it's going to make sense for content editors. So you want to pick content type names that are familiar. So if there's names that are already being used in the organization, this is where you can put those in. Meaningful descriptions, describe the relationships. And just in terms of the content types that you end up building, just in general in Drupal, you want to make sure that your content types are modeling different data types. Don't just make content types because you're using content in different places on the site. It should actually be modeling different content structures. And if you do it that way, you'll probably end up with content types that make more sense to the people offering the content. So just think through that a little bit because you're going through that site building process. So field configuration. So once you've got your content types that you're building and as you build them, you're adding all kinds of fields. And of course the fields also have an interface that's going to be presented to content authors. So for every field you have all sorts of configuration you can do that affects the look of the field in the content editing, the node editing form. So probably the most important thing is the widget selection. So widget is a technical word in Drupal 8 that refers to the actual input element in the form. So widget would be like a text field or radio buttons or checkboxes or date pop-up. Those are all examples of widgets. And which widget you pick is going to make the interface easier or harder for editors to use. And it might actually impact what content they end up putting in. So if you put a really big text area, for example, it might make people add more content. You can also add help text for any fields in Drupal. So that's your opportunity to put in that built-in documentation. You want to make sure that you're requiring fields that are required. So a required field means like if you publish the content and the field is not there and the site looks broken, that means the field should be required. So you can't just assume that authors are going to enter fields if they're not required. Default values can also really impact content authoring. So you should put those in if they make sense. And then just the logical ordering of the field. So if you have a lot of fields, you've got to think about that order a little bit to make sure that it's going to reflect the order that the content is going to be displayed in or that it has some other logical order. So don't just put a random order through your fields. Sort of think through that process, whether the image should be collected first or the longer text fields. That's something that you can change to make the interface easier to use. So choosing the right widget, there's so many types of fields in Drupal that the widget selection is going to be different for each one. But I just wanted to give you a couple examples. So this is an example for a list text field. So list text field means you have a field where the user can pick from a set of predefined options. And if you just put in a list text field, actually it would be the same for a textonomy term reference field. You would have the same set of options here. So you could have, for example, an autocomplete field. So if you have maybe thousands of options available, maybe you think autocomplete makes sense because you can't put everything into a drop-down list. But autocomplete can be tricky for content editors because they don't necessarily know what options are available. They just have this light box and they can put anything in there. And they don't know what the options are because they don't see them. Radio buttons, again, like if you have obviously even 50 options, radio buttons are going to take up a lot of space. So it's problematic from that perspective. Select lists, you have the same issue. It can just be really long. And even with, you know, starting different options, it can be tricky to use. So one option that you have available would be the chosen. A chosen kind of input. Chosen is a library that you can use. And there's a Drupal module for it. And it provides this combo box. So you can do an autocomplete. And it also provides a list of suggestions of either maybe the most popular or the highest, the lowest-weighted option. So it gives some examples so you know that where the authors know what kind of content should go into this field. And then they can also do the autocomplete. So in general, when you're picking widgets, you just want to think through this. So kind of like preview the node edit form. Think about it from an author's perspective. And look at each widget and think of it if it makes sense to you. And this would also be a good opportunity to go in and add that kind of help text. Every widget has different configurations. So for example, for images, you can set a minimum and maximum resolution. That's going to add some help text to the user to tell them that they have to upload some image to that specific minimum size. And so those little bits of configuration are really going to help give you consistent content on the site. Another module you can use to help organize the fields if you've really got a lot is the field group module. So this allows you to group together related fields. And you get to pick the kind of element that's used to group them. And one new element that's available in Ripple 8 is the details element that's being used here. So details provides a collapsible box to contain whatever fields belong together. And it's already being used if you look at the node edit page. It's used on the right for all the settings. Those are all detailed boxes. And details is just an HTML5 element. So really simple element, collapsible, works on different devices really well. And you can use it in a form but also you can use it outside of a form. So that's the field group module just for organizing fields. You probably only want to use this if you've got a lot of content or if you specifically want to group fields together because they're displayed together. So you want to think through that, but it can be useful. And it's a really simple module. Another module that's going to help you with your field configuration is the insert module. Is anyone here using insert? Ah, Dika, are you using insert? Awesome, no idea. Okay, insert is a module for taking usually images and inserting them into say a body text or a long text field. So if you have authors who like to put images alongside text, a lot of times content authors want to do that. They want to create long form text that has images and text and other elements like HTML elements mixed together. But sometimes you as a site builder, you want to have that image as a separate field so that your site is more flexible and you can use that as a thumbnail or manipulate it how you want. Maybe resize it, put it at the top of the page. So you want to have it as a separate field but you also want to put it in the body text. So the kind of naive way to do this would just be to have the separate image field and then tell the user, oh yeah, copy the URL of this image, right click on it and then stick that into the HTML body text. But most content authors aren't going to like this plan and they might not listen to you and they might not remember what you told them. So it's way better to just have this little insert line. So that's what the insert module provides. It just gives you the interface for sticking an image that you've uploaded into the body so that it can be included in both places. And it avoids having to re-upload images, things like that. Another module that you can use that's going to give you more flexibility for authors, a nicer interface, is the video embed fields. So if you have videos that you're posting on the video or YouTube and you want to embed those on the site, rather than having content authors go and copy the embed code from the video hosting site and then paste that into Drupal and using the source mode, which maybe they'll remember to do and maybe they won't. Instead, this allows them to just take the URL of the video, stick it in a field and Drupal's going to take care of the rest. So it just provides a nicer UI. The video embed fields module, it provides the formatter and it provides the whole field type. But you do want to make sure that you put in some good help text so that the user knows what they need to do. Because if you didn't have this text here to enter the URL for the YouTube video, you'd have no idea what to put into the video field box. Okay, so there's obviously a lot you can do in terms of field configuration. Another thing to consider is that there might be fields that come with Drupal like properties on nodes that you're not actually using, that you might just want to get rid of to simplify the interface. And one example of this is the promotion option for Drupal. So are you all familiar with promoted to front page, sticky at top of lists? Yeah, we all know about this stuff because we're like, oh no, we know Drupal, we know about these things. And we know that sometimes these checkboxes do something, like sometimes there's a view on the home page that uses this and sometimes there's views of news items that respect sticky at top of this and promote those items. We also know that some content types or some content types just does absolutely nothing. So sometimes checking sticky at top of lists doesn't do anything. And for a content author that's really frustrating. Like I check the checkbox and nothing happens. So if you're not using these for content types and I think for most content types we usually don't use these. I would just hide these. So in Drupal 8, any component in the content editing interface you can hide through the manage form display tab. So when you're editing your content type, you've got manage fields, manage display, and you've also got manage form display. And that's where you can go and disable these elements. So disabling them doesn't remove the data for these fields. It just removes them from the node edit form. So your form is going to look like this and everyone's going to be so crappy. Other fields, so the long text fields tend to be more complicated because they have text formats and RISIWIC editors associated with them. So if you're working with long text fields, which we usually are, you have to take this into account and kind of plan out how these are going to be configured. So in Drupal 8, every text format like full HTML, basic HTML, restricted, they have a configuration and if you have a RISIWIC editor enabled, everyone knows what RISIWIC is. What you see is what you get. So the little form for editing your content. You actually have configuration options for this for each text format. So this is pretty cool. This is like the RISIWIC editor for your RISIWIC editor. You can go and drag and drop the buttons and create the RISIWIC editor that makes sense for your site and your content and your content editors. So if you have brand new content on your site and you don't want to have anyone adding tables, you can go and just get rid of the table button and hope that nobody adds them. You can also go and change the filters on the text format to change what it actually does and what it actually filters out in terms of HTML. So you have lots of options there too. And some things that I like to add, I always add the paste from Word, paste as plain text buttons. Those are useful for those content editors who love writing their content in Word and facing it into Drupal. It helps make that content look a lot better. And so you can experiment with those kind of buttons too. So it's worth taking the time to configure these. Text formats themselves are not in this order by default. Usually the default is basic HTML. And I think that's just because basic HTML comes before the other ones in the alphabet. So that's the default text format, which means that as people create content on the site, most of the content is going to have the text format that's the default. So if you have full HTML at the top of the list, then most of the content on your site is going to be full HTML because people don't change the text format generally. And so this is fine as long as most of your content editors have permission to use this text format. If they don't have permission to use the text format and the content's been created and it's using the text format, they won't actually be able to edit the content. So if somebody creates the about page for the site, they use full HTML, I come along as a content author, and I only have permission to use basic HTML, then I won't be able to edit the about page. So you have to just plan this out when you're assigning the permissions to use text formats and when you're setting what the default is and what the text formats are for the content. It's also important to keep this in mind for content migrations because usually in a content migration, you're setting the text format for the content as it's imported into Drupal. One tool that might be useful to add to your WYSIWYG editor is a link-it button. How many of you have used link-it before? Are you fans? Not fans? Sort of like, not sure. Yeah, so link-it is a tool that's useful for adding links within your content. So if you have content authors who want to link to a page that's already on your Drupal site rather than having to memorize a path or go and copy and paste that, they can just type in the name of the content and this will insert the path and the link for them. So it's just kind of a user-friendly tool for creating links between nodes. Media management. So another thing that comes into play sometimes in the long text field and sometimes just as independent fields, you often want to have your content authors uploading images or other media and it's pretty common for content authors to want to reuse media. So they might be reusing an image that they uploaded or one of their colleagues uploaded. And so to enable this, you'll want to add the entity browser module along with the file entity browser module. So together these two modules provide an interface which kind of looks like a library of images and so users can just pick the image that they've already uploaded if they want to or they can always upload a new image. So it just makes that image reuse a lot simpler and avoids having difficult files as part of this section. Previews. So another thing that is part of the content editing experience as you're going through in creating content is that you might want to see what the content looks like before you publish it. And if you were using Drupal 7, I know there's lots of Drupal 7 people here, you probably think that Drupal previews are terrible and you should never use them because in Drupal 7 it really didn't work that well. But now in Drupal 8 the content preview, like if you click that preview link, if you enable that for your content types, it gives you a pretty good preview. So it shows you what the content looks like on the front end of the site using the front end theme. And you can switch between view modes. So if you're using teasers or something, you can preview what that will look like as well. So you can consider building this into the content editing workflow and enabling that for content types. Something that content editors often find particularly challenging is creating content that's not just one piece of content that's standalone, but creating pages that are more complex. So often in Drupal we end up with these landing pages or we end up with these complex pages that involve multiple data types. So it's not just one page with a bunch of fields, it's one page with a reference to this piece of content and a reference to that piece of content and maybe three calls to action on it. And that can be really complicated for content editors because you have to explain to them that, oh, first of all you have to go create this promo message and then you create the page and then you make a reference to it and then people's eyes start to glaze over and they don't remember the instructions the next time. So one thing to kind of strive for as site builders is having one-click landing pages. So if you have one of these complex pages, whether it's a landing page or something else, try and get the interface for editing all that content into one editing page. And one module that really helps with this, it's available for Drupal 7 as well, but it's been used a lot in Drupal 8, is the paragraphs module, and this allows you to have compound pieces of content within a node or within another entity type. So for example, if you have a promotional landing page and you have a bunch of calls to action, you can set up those calls to action as paragraphs within the landing page and then the content editor can just edit them in place. So they'll have to go to a different page to set these up. And you want to pay attention to the configuration of the paragraphs widget, because sometimes when you're using paragraphs and you have really complicated landing pages, you end up with these forms, like forms for the calls to action inside the bigger landing page form, and you end up with all these nested forms. So you can come up with a really big node edit page that's kind of too complicated. And so if you're configuring the content type, you can actually set these up to be previews. So these are configured to be previews right now, so you don't see the form until you click Edit. So it just simplifies the big landing page form a little bit and makes it easier for content editors to skim through and figure out what they need to edit. And this same thing can be applied to lots of other data structures. So another example would be like an event content type, where there's event instances within it, so each of those instances could be a paragraph. So every site is going to have kind of different content, but any content that's kind of compound, you can consider building that with paragraphs. The one downside of paragraphs is that when you use paragraphs, that content is only available to be referenced within the content that is defined in. So if I have these calls to action within a landing page, I can't reuse those on another landing page. So if you want to have more of a reusable content experience for your content editors, you can set up those chunks of content as separate nodes or separate blocks, and then you can reference them using the inline entity form module. So inline entity form just says any two pieces of data that are related in Drupal, if you're referencing another piece of data, you can edit it within the parent item. So if you wanted to have calls to action that was reusable, you can set them up as blocks, and then you can use inline entity form to edit a block inside of it. So it's kind of like this cool recursive thing. And so for example here, you can either, this is an example with like a cookbook of recipes. So in the recipes field, you can add a new recipe, you can reference an existing recipe, or you can edit a recipe. So you can do all these content actions on the sub-items within the parent item. And you have access with inline entity form to really design this form, so you can customize these labels and things, and that makes the experience again a bit easier for content editors to know what's going on. Another thing you can do, because sometimes you can't necessarily do the one-click edit thing and put all the data into a single form. But some modules that might help with the block placement experience, if you have a more complex page where editors have to place blocks themselves, there's two modules, settings, tray, and place block. And these are new modules in Drupal. They're new four modules, I should say. And these improve the block editing experience. So you can actually edit blocks in place and place blocks. So it kind of creates the block layout experience, but on the front end of the site, so you can actually see what's going on and edit things more easily. So those are two modules to try if you have content editors placing blocks and you want to improve that you are. So finally, I've given you a bunch of advice, but every site is pretty different. I should say that I think the reason that Drupal, out of the box, doesn't have a perfect content editing UI is because every Drupal site is so different. It's really hard to build a UI that's going to work for every kind of content editor and every kind of content. So this is why we as site builders have this extra work to do to improve the UI for our users. And that being said, a big part of making the best content editing UI is doing some testing. And I know whenever people talk about user testing or like, oh yeah, this extra testing you have to do, this always gets pushed to the end of the project, and then it usually gets pushed so far that it falls off the edge and never gets done. So just some advice about testing. I really recommend trying to build this into the training part of the project so when it comes time for content editors to learn how to use the site and to actually start entering new content, you want to show them how to do their common tasks on the site, show them how to edit content and do whatever else they need to do, and then watch them do it. And this is the tricky part. So it's really easy to show somebody and you've got the mouse and you're typing in some sample content and showing them. But it takes a lot more patience to watch someone else go and edit your site. But in watching, you're probably going to figure out if you missed things, if something's hard to do, or if you need to adjust the permissions, like maybe you missed a permission or you gave too many permissions. So you want to take notes just when they're doing their job and then you can adjust the UI to the settings of permissions and try and do that before you launch the site. So if you wait till after the site's launched and then you're new training and then you realize, oh, we forgot the permissions or oh, we should have added another user role, it's kind of harder to do that after the fact. So something to try and do as part of that training. And that way you're kind of doing two things that want to build that into the training bucket of the project. And hopefully that doesn't get thrown off the edge of the timeline. So that's all the content I have for you. So thank you very much. And if you have any questions, I'd be happy to talk about other components I didn't get to or if anyone has any comments. Yes? What can you do to make progress idea when they're used to throwing everything into the body of people? Oh, that's a good one. Yeah, I remember one time doing it, making a job posting and I came to the job posting site and I had the whole thing like copy paste, ready to paste and then it was actually me separately for like, what experience does the person need? What education? And I was so frustrated. And then I realized, oh yeah, this is the one building a paragraph. Sorry, back to that. I guess they might not like it at all. It might not be possible. But if the paragraphs at least model the content that they've already created, that will help a lot. So it's going to be really frustrating if they only have, if they have to throw their content in there and it doesn't match up at all to what they've already written. If they actually have to rewrite every sentence, then the body and the margin will be frustrating, but it's just a bit more like, maybe if there's enough content types or enough paragraph types that it matches what they have, then that is actually easier. Another thing with paragraphs is that it's very flexible in terms of referencing multiple paragraph types. So if they've got some content that's more structured like an image and then text and then a list, and you want to make those types, and then you want to have some more free-form paragraph type that you can create in both. So they have the option to either put a long text or write the text. If you use the copyrights and then configuration that belongs to this man. To avoid overwrite? Yeah, to avoid overwrite configuration which I've been doing with my form support. That's a good question. There's a lot of different options available. You can do config ignore to just say you want to ignore that configuration, or you can just do, like when you're about to import the configuration, you can do config export first to make sure that you know what's changed on the production site and then you can more agenda those changes if they make sense. So, depends if you can predict in advance what all the configuration changes on the card that you want to allow. But there's other modules available that seems like can be split that are being developed to help manage that workflow. So for those of you who have no idea what I just said, he was asking about the configuration workflow of taking changes that you've done to develop it and integrating that with maybe changes that have been made in production and that's a lot of places that are actually being run. Yeah. You showed in certain modules that we did browser. It's a browser. That's the thing I always started with where should I use to evolve into the field to just insert something or actually to follow the long media solution where you put it into the body field and it's easier to manage. Do you have experience in what users tell you and what you prefer to use? Well, users say that they usually say that they prefer having a big text field so they can put whatever they want. But then as soon as you want to do something like a redesign where you're taking the context and making it look better or for example making it work across devices it always works better with the search engine. I wouldn't necessarily trust what the user tells you in terms of what's best for this site. Yeah, I mean it means that it's not going to be ever consistent. There's definitely ground implications for SEO and accessibility. I mean most sites I mean any business just one thing I'll point out if you are having to allow for more things to be put into the loopy wave editor you can customize the styles and the format here so you can pick what can be added in terms of HTML and the styles is in terms of like HTML with classes applied and at least if you configure this it's going to streamline a little bit what offers our entry. So if they're trying to put things into a grid and you allow them to put some CSS like grace back grid at least you have that control and your CSS but yeah, encouraging the content to be more structured and having less written than HTML added to the loopy wave is going to be better for the site long term but in my series it's very challenging if you're doing that if you have a lot of legacy content and you're trying to clean all of that up I think that's more of a challenge like encouraging people to use structured content and they're creating new content so that it's easier to use given the fields and they will use them but if they're just converting content just a whole chunk of HTML into a new structure that's when it's really challenging you might have to have some kind of talk about it Other questions or comments? Okay, well thank you so much and if you have anything else that you wanted to ask feel free to come find me I'll be wandering around after that