 OK, thanks, everyone, for coming. Thursday at DrupalCon, and you're here at lunchtime, so I'm really, really thankful that you're all in the room. Today, we're going to be talking about content editor user experience. So how many of you are content editors? Come on, come on. How many of you have edited a node in Drupal? Anyone here not? I'll give you a quick demo afterwards. Make sure we have all hands by the end of the day. OK, great. So we're actually, you know, this is a selfish session. You're not here for content editors using your site. You could just be here for yourselves. You're going to make that process easier every time you edit a node. Quick introduction. My name's Suzanne Degacheva. I work at Evolving Web, and I am a Drupal, one of these Drupal people who's been doing Drupal for a while since 2008. I run Evolving Web, so I end up wearing a lot of different hats there, and I run a Drupal training program as part of the company. And I put in some photos here just to convince you that Evolving Web is this awesome company. So you can take those for what they are. We like to come to DrupalCons. We organize trainings. We put on user experience events. We were the ones giving out the flowers last year, if you remember. Sorry I don't have any flowers for you today, but we like to do things like this, and we work for lots of different types of Drupal clients. OK, so we're here today to talk about user experience for content editors. And I put together, I'm trying to add more diagrams to my slides, put in a little diagram here to make us just think about what the content editor experience is. It's really just the way Drupal is architected. It's really just a subset of our site building experience. So how many of you, I asked you before about the content editing thing, how many of you are site builders? Probably most of you too, right? Even if you're a developer, a themeer, like everybody's ends up being a site builder in Drupal. And as a site builder, you spent an awful lot of time in this admin interface for Drupal. So we're all very familiar with the Drupal backend. And this is great, because that's our job. We are these site building experts. But it's also a huge drawback for us when we're trying to imagine what the user experience should be, because it's an interface we're in all the time. We're so familiar with it that it just seems natural to us. Some of us might even have dreams about the permissions page or whether we made that field required or things like this. So if it's in our dreams, how do we really imagine what the experience is for content editors who don't know Drupal as well as we do? So that's what I wanted to focus on today. So there's a couple reasons why building a good content editor experience is hard. And the words in this slide are out of order. No, content editor UX is hard. That's right. It's hard. It's hard. Why is it hard? Because we have a complex information architecture maybe on our site. How many of you have built out a site with entity references? Yeah. And do content auditors know about entity references? Probably not. So the UI for that might not make sense. And I tried really hard to add a screenshot in here of the UI for the information architecture diagram on the left. So for those of you with excellent vision, you're going to see that there's a screenshot on the right side of the page. The note on the page there is so long that you can hardly tell what it is. Basically, complex information architecture is going to lead to a complex user experience. So if you think about the Views UI, we're not giving our Views UI to content editors. But the fact that Views is a complicated thing to configure, it reflects the fact that Views are complex things. They're these database queries. So we have a similar thing with our content structure in Drupal. And that's why we often end up with these really complex interfaces. OK, so these are the challenges, right? The challenges that we're familiar with the interface and the interface is complicated. So what's the good news? The good news is that there's lots of tools out there to help us build a great UX with Drupal. And I'm not even talking about modules you have to download or themes you have to add on. There's just a lot of things built into Drupal that you can use right now. You can use, as you're building out your site, that are going to lead to a better user experience. So let's start with the easy things and use best practices to create a better user experience. So I'm going to talk through a lot of these things today. And basically, we have a lot of configuration tools. Most of you are site builders. Some of you are maybe themers or developers. So you have some extra tools in your toolkit. If you need to, you can go and make a custom admin theme, how many of you have done that before? Custom admin theme. Maybe it had two lines of CSS. I know I've built that kind of thing before. Or maybe you've done form alters to clean up the user experience for content editing pages or built out some custom widgets. So there's lots of things that we can do that are easy when we're site builders. And if we're developers, there's even some more extra things we can do to improve the UX. So you might have come here today expecting that I was going to give you a solution, right? So you were all probably at the Dries Note on Tuesday because that's where we all start our DrupalCon. And you heard about the Admin UI initiative. You all remember this? You were taking notes, paying attention. You probably all got really excited. Like you saw the screenshot. You heard the news. So I'm really excited about this initiative to make the Admin UI just look and feel better, work better, have better tools. So this is a work in progress. And then there's also lots of other things out there. Like some of you probably saw the talk this week about the material admin theme. Any of you were there? Yeah, I know. I know it looked really exciting. Like this nice admin UI that, or admin theme that's going to make the admin UI look better. So these are nice solutions. But I'm not going to propose a one-fix solution today because every user experience for every Drupal website is different, right? So you know how in Drupal, we have a very, well, I wish I didn't, I don't want to make controversial statements at DrupalCon. I'm not that type of person, but there's not that many great themes for Drupal, right? Compared to things like WordPress. I got some head nods here, some people agree. Yeah, you look on Drupal.org, you look for out-of-the-box themes and you don't find a lot. And why is that? That's because every Drupal site is going to have different content types and a different content architecture. So that's what we're dealing with. And that's also why there's not one solution for content editor UX in Drupal because every Drupal site has these different content types. And so the user experience also needs to be adapted for every site. So as site builders, as we're building out node edit forms, as we're configuring fields, as we're building out a content moderation workflow, we need to adapt this configuration to our content editors and to the content on our site. And so that's why what I'm presenting today is not gonna be a solution. I'm gonna present some strategies and then I'm gonna talk about some pretty common techniques that you're gonna find useful for most sites. Okay, so first of all, this process. So when do I think about the UX? Like when should I put on that UX hat? And maybe you don't think of yourself as a user experience designer, but if you're building a Drupal site and you're the one configuring fields and things, then you're already doing UX. So when you wanna put on your UX hat, it's pretty often. You wanna do it when you're planning the site, when you're building the site, when you're doing that QA, when you're training the content editors, the whole process. So what exactly do I mean by that? So in the planning phase, everyone's got some kind of planning phase in their Drupal project when you're building the site or building out features, you wanna be thinking of what the content editors are trying to do. What are their goals? What tasks are they doing? And you wanna get them a little bit involved, hopefully at the beginning of the process to define that. And you wanna listen to them to figure out what terminology you are using. How are they talking about the content on the site? And you want to pay attention to that and let that feed into your site building. And then as you're building out the site, obviously, you're gonna use that information. You're gonna build out the content structure. You're gonna be creating this admin UI as you go. And then again, at the end of the project, you're probably doing some QA. You know, at the end of the project, you do QA. And some training. Has anyone here trained a content editor? Yeah, oh, great. So we're all like Drupal trainers. That's great. And that is an awesome opportunity to do what is basically user testing. So your training, your QA, you're taking that time to kind of test out this user experience that you've built and make improvements. And if you have time, do that training sooner. So whenever you're doing that training, maybe it's the day you launch the site. Maybe it's the day after you launch the site. Or maybe it's at the beginning of the QA phase. But I guarantee you, if you do it sooner, you're gonna end up with a better user experience. So that's sort of the planning part. So let's actually walk through how this works. Strategy and definition. So these are terms that we like to use. Any salespeople here? No, sales, okay. So salespeople, because I have to do some sales. I'm not really salesperson, but sometimes I have to put on that hat. And we like to talk about, yeah, at the beginning of the project, we're gonna have this definition stage where we define everything. And you want as a site builder to kind of try and get in on this early phase of the project, so that you can gather some information as well. And you wanna gather information about what the content editors want and what their goals are. So what do content editors want? What is this? For those of you at the back of the room, this is a WYSIWYG editor, just a WYSIWYG editor. It's a really nice one, it's well designed. So you're gonna have some content editors who want this. Other content editors might want this. What is this? The layout builder, yeah. So some editors, or they might be thinking more like panels, maybe they're old school, not using an experimental module. And they're thinking, yeah, I want this builder tool. Okay, so those are great options, but what content editors want isn't always what they need. So that's why instead of just asking them what they want, we can ask some more strategic questions. So what kind of content are you editing? What are your common use cases? What are the requirements for the content on the site? And how can we, keep asking, like how can we make this simpler? Is it possible to simplify the process or simplify what you're doing? And then you also wanna pay attention to what are you calling things, you content editors? Like are you calling this a book or a work or an addition? Sometimes there's different terminology that people use at an organization. And you wanna try and build that into the site that you're building. So here are some common goals. Like this, these are things you probably wanna do on most websites. You wanna be able to find content, edit content, translate content. You wanna be able to communicate. Maybe your content editors are actually marketing people. So they might have some goals that are a little bit more a bit nuanced. Maybe they wanna be able to influence the styling of the pages they're building. Maybe they wanna have a workflow for getting content approved. And so you have to kind of gather this information and figure it out. So when you're gathering this information, you can think about this as like you're gathering some goals, you're maybe breaking it down into tasks like things that users actually do. And then architecture. So architecture, information architecture, wire framing, who here has done work like that before? Yeah, it's, this is fun. And we can be like, oh yeah, we have all these goals, we have these tasks, and then we're gonna build out this nice and min UI that's perfect for our users. So that sounds great, except that we're using Drupal and we're not gonna redesign the whole admin UI. We already have an admin UI. So what you wanna pay attention here to is how can you improve the admin UI in Drupal or how can you just build it in such a way that it's going to work better? You're not reinventing the wheel here. So unless your project has a massive budget for these kinds of things, you're probably just looking for making improvements rather than trying to reinvent the wheel. Okay, so you've gathered this information, you have some ideas about who your content editors are, and now you're starting to build your site. So let's just walk through some of these goals that content editors have, and what you can do is a Drupal site builder to achieve them. Okay, so one of the main things content editors need is just being able to find and add content. They wanna be able to find content so that they can edit it. They wanna be able to add new content. These are really basic things. And so you might think, oh yeah, you can do that already, you go to content, add content, it's easy, or you can just go click through the site and find the node and click edit. These are basic things, right? But in order for somebody to be able to effectively find and add content, there are some things that are really gonna make their experience better. So one of the easiest things we can do is just unclutter the admin UI by making granular roles for our users and limiting the permissions that they have. So as a content author, if I just have to be able to edit content and that's the only thing I'm doing on the site, I should just be able to go into the site and not see things about view modes or permissions or other parts of Drupal that I don't need to see. So just going to that permissions page and configuring things in a sensical way, that's step, like that's step zero. Picking meaningful content type and field names. So who here really likes building a Drupal site and impressing everyone and being like, I can build up this site in three hours? Who's that person? Come on, really? Nobody? This is what I love to do. It's like, oh, I can just build this so fast. So it's really a good idea to take a little bit more time than that and clearly nobody raised their hand so you're all very wise already. You need to pick meaningful names for your content types and for your fields. And this sounds easier than it is, right? Because sometimes at the beginning of the project we have one concept of what the content is and by the end that's changed. And so it's worthwhile asking questions from day one to make sure we get this right. And the reason to do this, it's because when you're creating content in Drupal, when you go to that add content page, you don't just see article and page, right? You see all these content types that you wonderful site builders have created. And so you want those names to make sense. The names that appear there on that add content page are the names that you've selected as the names of the content type. So you want them to make sense to content editors. So every time you're picking the label for a field or picking the name or description for a content type, don't think about you and what you want to call the thing. Think about your content editors. Clear links for adding content. So maybe you're using admin toolbar and giving that to your content authors. If you do, make sure you turn on that extra module so that they don't see all the extra links that they don't have permission to see. So admin toolbar, yeah, there's like a third checkbox when you enable the module. Make sure you turn that one on. And you also, in terms of finding content, yes, people can click around the site and find content and yes, there is a content overview page. But did you know you can change the content overview page? It's a view. Everyone knows that? Yeah, so your content overview page, you probably want to change that because your content is not just generic articles and pages. Your content is amazing. That's why you have a Drupal site. You have all this great content, right? So if you have courses, you have thousands of courses on your site and content editors are coming in and editing these thousands of courses, you might want to create a nicer content overview page just for courses with nice filters so that people can find the content more easily. So that's a really easy thing to do as well. And that one you can kind of do at the end of the project. So if you do these things, I think your site will be better than most sites for user experience. I think from what I've seen, a lot of sites don't miss some of these things. So I could just end the presentation here and you would already have some wins. So everything else is going to be a bonus. All right, so that's great. You can find content, you can add content. Well, what about editing content? Like that's really where it's at, right? So editing content, the experience for editing content. This is something I think that gets overlooked because when we create content types in Drupal, we're actually doing three things. Where you create a content type, let's say you create a course content type, you're creating the fields in the database, right? The tables that track each field. And then you're also creating the form that people are gonna use to submit the content. And you're also creating the display. So that's why we have those tabs, right? You're editing a content type that you also have managed fields, managed form display, and managed display. So the managed form display one, I think this gets overlooked. I think we should hang out more on the managed form display tab because it's a great tab. There's a lot going on there. So what can we do on managed display? So on the managed display tab, this is where we get to pick the widgets. This is where we get to move the form elements around. And this is really what we're using to build out the UI that content editors are using all the time. So picking the right widget, you might not think it's that important, but I think picking the right widget will actually affect the quality of content on your site. So here's an example. So when you add a taxonomy term field to your content type, right? The default widget is an autocomplete. So how many times is an, like how often is an autocomplete the right widget? Not that often, I would argue. So a lot of the time, if you've got thousands of taxonomy terms, maybe autocomplete is a good choice. But if your content editors aren't as familiar with your taxonomy terms as you are, then it might be easier for them to see a list of options. So that works really well if you have like 10 options. Once you have a lot of options, then that becomes a little unwieldy. So I put kind of all the choices that I see here. Autocomplete is good, radio buttons are check boxes and then you have a select list, which could work well for if you have a longer list. But if you have a lot of content and you wanna kind of give a hint at what the taxonomy terms are, then the combo box might work the best here. And how do we build this combo box thing? Does anyone, has anyone used this before? This is chosen, right? The chosen module. So there are modules that can give you even extra widgets if the widget options aren't enough. So just take the time to go through and pick the right widgets. Test out the editing experience and see what you need to customize there. So just one more example of this. So if you're allowing users to add media, like images, files, other things like that through the fields, then you might wanna consider using the entity browser. So this is something that's gonna make a big difference in terms of how people edit this type of content on your site. So this is kind of a UI thing. It's also a functional thing. I mean, it's just gonna allow people to reuse the content, but it's something to consider and it definitely will improve the user experience. Another easy thing you can do on the manage form display tab is hide things. So when you're thinking of user experience, one of the patterns in user experience is to simplify. And the easiest way to simplify something is just to remove stuff. So if you've got things like the sticky at top of lists or promote to front page, who here uses the promote to front page filter on your site? Like who has a front page that actually shows all the content that's promoted to the front page? Almost no one, yeah. So we can just hide this thing. So go through all your content types and hide the checkbox. Otherwise, your content editors are going to come to you and say, what is this promoted to front page things supposed to do? Okay, so another, maybe slightly more subtle thing we can do for our content editors is add things like help text to our fields. And help text is good. I think we can all agree, help text is often a useful thing, especially for fields that require a specific kind of format. Like you need someone to put in the URL of a YouTube video. They're gonna need some instructions there. But help text sometimes gets unwieldy. So for example, here's the help text that we see all the time. You know when you're adding a block in Drupal? And there's that little text in the block visibility settings that says, yeah, you can use front as a token to put this on the front page. I've, as a Drupal trainer, have watched probably a thousand people read that text and nobody gets to the end and reads the part about the front page. So that help text is just so long that nobody's actually reading it. So you have to think through and you're writing your help text like, okay, what's the most important thing to say here? And you don't want to be too verbose. Another thing about help text is for images. If you have images on your site, you probably have some kind of guidelines or requirements for how big the images are because usually an image field is gonna be used somehow in the design. So it's a really good idea to fill in those parameters for the minimum and maximum resolution size so that authors know what size to upload. And that's gonna put it right there in the help text so your job is done. Okay, so those are a bunch of really specific things you can do. Here's something stepping back a little bit more general. So when a user hits that save button or they're going to publish their content, the best user experience is one in which they are not surprised by what they see on the next page, right? When somebody publishes content, you want them to be like, yeah, I published this and this is what it looks like and that's what I thought was gonna happen. If they're surprised by the result, that's not a good experience. So from this, I'm gonna, we're gonna maybe use our imaginations here a little bit and look to some other tools. So this is not the Drupal admin UI. This is an example from Netlify. So it's another kind of CMS tool and it's an experience where you see the edit page and then you kind of see what it's gonna look like right away and that's kind of a nice experience. So we don't have that in Drupal but we can kind of think to that as a good example. And there is a good article that I found in preparing these slides from Brian Hirsch who worked on the mass.gov project or he's working on it and he's proposed something for Drupal that's very similar. So I think this UI is really nice and I think this is something to kind of strive for and maybe in the admin UI initiative that something like this could get built in Drupal. But in the meantime, just with the tools that we have for building our sites right now, what are some best practices here to make sure that we don't have surprises? So one thing that I like to do is look through the fields and figure out which one should really be required because sometimes we enhance things when extra fields are added but you wanna make sure that there's no fields that aren't required that it's gonna break the site if they're not there. So you wanna try and think that through carefully and make sure that enough fields are required. And if something's not required, maybe it should have a default. So if you have some kind of thing like a nice big banner image for your articles but maybe some content authors aren't gonna be able to find one, maybe you can provide a default banner. So thinking through things like that is gonna be nice. Ordering the fields consistently is also just gonna improve this so you see the fields in a certain order that's kind of what you expect, how you expect them to be ordered on the front end. And then enabling previews. So who here has used previews on their Drupal 8 site? Yeah, some people are scared to turn on previews because maybe you tried to use previews in Drupal 6 or Drupal 7. So Drupal 8 previews are way better so you can turn them on and maybe let your users see what the content's gonna look like before they publish it. Okay, so we've reached the part of the presentation where we're gonna talk about the WYSIWYG editor. And I decided to call this slide good WYSIWYG experience. I hesitated to call it great WYSIWYG experience because I'm not sure such a thing really exists. But let's try and make the WYSIWYG experience as amazing as possible. So first thing about WYSIWYG experience in Drupal because a lot of content management systems have WYSIWYG. It's a fact of life. You want your content editors to be able to format their text, their body text. But one thing that's particular to Drupal are these text formats. So this might be a sticking point for some of your content editors. What's a text format and why do I have to deal with them? Another really other than just the fact that we have text formats and there's this text format selector that maybe users aren't gonna understand. You also have the fact that sometimes if a text format has been assigned to content and the editor doesn't have permission to use that text format, what are they gonna see when they get to that edit page? Has anyone seen this? This gray box. Yeah, this is the worst. This must be like the worst user experience ever, right? It's like, I wanna edit this content. Oh, I get a gray box. Okay, so how can we avoid this? So basically your strategy is you wanna think through all the people who can edit content on the site and you wanna think about all the text formats that you actually need. Sometimes you need some special ones for certain types of pages, like you have a page where you have to embed some video and you don't want everybody to be able to add videos. So sometimes you do need a bunch of formats. So you wanna think, can everybody use the one at the top? Whichever one's at the top, that's the default. The default is what's gonna get assigned to most of your content. So if full HTML is the default and everyone on your site who can edit content can use full HTML, that's great. But if you've got some other formats in there that people are using and some of them are gonna be editing the content and they don't have that format, that's gonna cause problems. So one possible solution is using the allowed formats module. This will let you assign certain text formats to certain types of content. So you can say, oh yeah, these documents, this document content type, we're gonna have a special document editor format for this content type and everyone who has permission to edit documents also has permission to use the text format. So that module might solve some of your problems if you've got these sticky text format situations. Okay, another good thing for WYSIWYG experience, you can customize the WYSIWYG editor in Drupal 8. So yes, we have a WYSIWYG editor out of the box, this is old news, we know it comes with Drupal, but we can also go in and configure it and this is like a WYSIWYG editor for your WYSIWYG editor. So not only is it there, it's really easy to use, you just drag and drop the buttons around. So chances are you're gonna have to customize this for your content. And some things to consider here, you wanna make sure that it's easy for users to add the HTML that they need and you also wanna consider that you wanna help people make accessible content. So think about removing things that might create inaccessible content. We were asked once by a Canadian government department to create a WYSIWYG editor that would only create accessible content. That is hard to do, we do not quite accomplish this but you can make some improvements to this that are gonna get you some of the way there. So don't let people add H1s in the WYSIWYG editor, no reason for that. And you can think about limiting what they can do. You can also go in and customize the what's in the styles dropdown and the format dropdown to kind of help with this. Another thing we can do with the WYSIWYG experience is we can add in extra buttons. So if there's something that doesn't work well enough, if there's a lot of internal links on your site, maybe use the link it module to add a little link button so people can just kind of search for the content they wanna link to. Or there's an editor file plugin for the CK editor that's gonna let you add files to your WYSIWYG content. There's also a WYSIWYG template module that will let you add specific chunks of HTML in there. And these all sound like good things and maybe like scary things, like I don't want people to add all this stuff to the WYSIWYG editor. So it's really a balance. You want to try and get people to add things as fields because probably as a site builder you want control over how the content's gonna be displayed but you might have to give them some of these tools in the WYSIWYG editor just because they're gonna be adding those things anyway. So if they're gonna add them anyway, Maze will make it a good experience. One final thing for the WYSIWYG experience, I don't know if you've noticed in Drupal but what you see is not actually what you get. You use the WYSIWYG editor and you see the content and you're like, oh this is an H2, it's great. It's exactly how I want it and you click publish and all of a sudden it's in, it's all capitalized and it's a different color and it's not exactly what you thought. And this is because the theme that you're using on the front end of the site obviously isn't the theme that's used in the editor. So you can mitigate this to some degree in your theme by adding in some CSS that's specifically for the editor. So that's something you can just put right into your theme. But I have to warn you that this rarely is going to work well because a WYSIWYG editor is not the front end of your website. So they're never gonna look exactly the same. Things like spacing, things like, we get into tricky things here but the CSS that's loaded isn't gonna be exactly the same so you might still have some discrepancies but this is a good tool to know about just in case you need to make them a little bit more similar. Okay, some more things. So we've talked about content editing which is a huge part obviously of the content editor experience but there's also some aspects of what content editors need to do just around getting the content out the door. So the publishing workflow, getting content translated, getting content approved by the right person, these are also challenges that content editors face. So in general, you want to try and create a publishing workflow that's as simple as possible to meet the needs of the organization that you're working with. So maybe people think that they need a really complex workflow, see if you can try and get them to simplify it. So that's one just word of advice and that's obviously easier said than done. And then the other thing is we can create views like I was talking earlier about the content overview page. We can also create all kinds of other administrative views. So if you're dealing with content publishing workflow and content that people need to translate, you can create views that are gonna help people with these workflows. So if someone logs into the site, maybe they wanna see a list of all the content that hasn't been translated or all the content that's a draft or all the content that's been marked as needs review. So you can build these pages really easily with views and it's really probably gonna save people a lot of time if you figure out what they need and how to fit these views into their, maybe into their dashboard or just into the menus that you give them. So content moderation, how many of you have used the content moderation module for Drupal 8? Yeah, Drupal 8.5, check it out. So it allows for you to create drafts of content and then go ahead and publish the content. It's really great. It also allows you to customize the workflow to create something really complicated. So you could add a lot of different states that the content needs to go through before it gets published. So this is where I'm saying try and keep it simple, draft and published, maybe that's enough. Maybe just try and take out like one step of what of the process that people propose because I find often you spend a lot of time building out a complicated workflow and then nobody ends up using it. Complex pages, what do you mean? What are complex pages? Complex pages are like landing pages. Who here has complex like landing page kind of monsters on their site? Yeah, so the biggest, this is like the biggest problem in Drupal, right? Someone gets a Drupal site and this even happens to us probably as site builders. Like we inherit a new Drupal site, maybe someone else built it, maybe we built it last year and we're just trying to edit this little bit of text on the homepage. Have you ever had this happen to you and you're like, what is this? Is this a block? Is this a node? And then you have to go through this whole hunt to find what the text is. So you can go to the obscure part of Drupal to edit it. So some strategies to get around this. So you can store chunks of content in paragraphs and blocks. You might have heard about these things earlier this week and been talking about different strategies for this. And there's also the layout builder module for managing complex pages that you can start looking at. It's an experimental module, but might be a good approach for something you're trying to build. So yeah, so pages like this. I'm looking at this page and what are all these things and how do I edit this little bit of text? So if you are building out pages with these different content components on them, like I mentioned, using paragraphs to break up your page into different chunks is going to allow editors to edit those chunks of content just by clicking the edit link on the page. So they don't have to go over to the blocks page to go find the block of content that you've placed somewhere down here. They can just click the one edit link and edit everything on the page in one go. And so that's going to be possible with the paragraphs fields that you set up and it's also going to be possible if you use custom blocks. So you can use custom blocks that you reference from your complex landing page through a entity reference to a custom block. And then you can use the inline entity form to make that interface as simple as possible. So with the inline entity form, you can actually create and create the reference to the block all from your landing page interface. So those are strategies just to make those complex pages a little easier to manage so that all the content is in one place. And then added benefit to this that you might not necessarily think about right away. It's that when you have a complex landing page, you might also want content editors or marketing folks to be able to reorder some of the content on that page. Like if you look at the screenshot here on the left, there's these like three chunks of content. Maybe somebody wants to reorder them. So if those are created as blocks and you have to go to the blocks layout page to reorder them, then that reordering gets saved in the configuration of your site. And that means that that configuration has to go through a configuration management workflow to get managed, you know? If you're doing that on the live site, you somehow have to get that configuration back into your development site. And that makes things way more complicated. So if you're using instead paragraphs or a block reference field to manage that content, then that all gets saved as content. So ideally, if the block ordering gets saved as content, then you just save it on the live site and no one has to worry about the configuration being out of sync. Okay, a couple of last words of advice here. For the same reason that I just mentioned about configuration being something that's hard to manage between development and your live site, avoid putting a lot of marketing kind of text into configuration. So think about this whenever you're creating a view or something, if you're adding some text to the header of the view, you wanna think like, is someone gonna wanna edit this in two weeks? Is the content editor gonna wanna come in and change that text? If you're saving it in the view, it's gonna be hard for them to do that. Even if they know how to edit views, they're then gonna have to take that configuration somehow get it exported. This becomes even more of a problem if you're working on a multilingual site. Who here has multilingual websites? Yeah, you know what I'm talking about. A multilingual website like everything's twice as hard. So for a multilingual configuration like this, the person would actually have to change the text in the configuration and then change the translation of the text in the configuration and export both those things. So just think about this whenever you're adding any kind of text to your site, how is this gonna be editable by our content editors or maybe kind of more advanced site admins? And finally, for editing complex pages, who here has actually tried out the layout builder? Yeah, so if you've tried out the layout builder and I encourage you all to do it, then you might be scared to give this user interface to content editors. You might think, oh yeah, content editor can use this to manage, you can use this to manage what's gonna be laid out for the content of a content type, but also for individual nodes. But if you start giving this interface to content editors, they can actually move fields and blocks around for every single piece of content of that type. So it's a little bit scary, but there's a lot of work being done in the layout initiative on the layout builder and I know that they know about this problem. We need to have more permissions on who can add what kind of content to what kind of layouts to build out a complex landing page with this tool. So this is something to keep track of and if you're really excited about offering this kind of experience where you can create a page with a custom layout to your content editors, then you are needed at the code sprints tomorrow. There's work being done on the layout initiative as well as other initiatives that you can get involved with to improve content editor UX. Okay, so we're almost at the end of the project and the presentation. There's one minute left in the presentation, so imagine you have like one day left in the project and you're like, oh yeah, we have to do the testing. We forgot, okay. No one left time to test the content editor UX. Okay, so the most efficient way to test your UX is to take a content editor and sit them down and tell them what to do. So tell them, oh yeah, go and create an article. Maybe give them some instructions, but the key here is to watch them. So this is really hard for us to do because we've just built this site and we're like, oh yeah, let me just show you how this works and even in this picture, right? I am not letting her do the thing. I am doing it for her. So I couldn't even find a good picture. Because this happens so rarely. I'm just gonna watch you do it. So watch the content editor do the thing. And take notes. Yeah, that's what you should be doing is taking notes because you're gonna see, I guarantee, if you show them how to do it, you are gonna find things. Like as soon as you show somebody a user interface, right away you're gonna think, oh, I should have put the field in that order or oh, I should have also let them use that format for their images. Like you're gonna find things, but if you watch them, you're gonna find even more things. I guarantee. And it's just a good practice in giving up control. So that's all you have to do. And do it early again. Do it at the beginning if you're QA, that's a really good time. Don't wait till the end. Yeah, they're gonna find problems, but don't be such a perfectionist. Find the problems, watch them. It'll all work out. Okay, so a couple final things because we've been talking about user experience, which is really a fun thing. It's like we're site builders, but we also get to do this user experience thing. And I really encourage you to practice user experience more. Like if you're like, oh, I'm a site builder, I don't know much about user experience. You just have to practice it and you're gonna become like a user experience expert in no time. So we've started at something that I'm really excited about. We've started doing these user experience events at our office where people present little projects. They get quick feedback from people, like a random group of developers, designers, et cetera. And it's a really good way to get into a design thinking kind of mode. Like you think, okay, how does this tool work? And you can look at Drupal interfaces, but you can also look at all kinds of other tools and think how would a content editor see this or just how would I use this or how could this user interface be improved? So you can use this in all parts of your life, not just web development things, but just how could this user experience be improved? And the more you practice this outside of Drupal, the more that you're gonna be able to improve your own projects and the experiences that you're building, both for the front end and the back end. Okay, so just before I wrap up, I have to do a small plug. So I run a Drupal training program so if you really liked this session and you wanna learn more Drupal or you wanna send your colleagues to learn some Drupal stuff, come talk to me afterwards. I've got coupon codes and stuff for trainings, online trainings, in-person trainings. I would love to know what kind of Drupal training you guys are interested in. So please come talk to me and don't be shy. I would love to talk to all of you. I don't know most of you. I don't see that many people in the room that I know. So please come, I wanna talk to you about what you're working on. And that's all I have, so time for questions. So I'm looking for questions. I know you're all hungry, but for those of you who wanna stick around, if you have questions or comments, extra things that I missed, please feel free to share on the microphone. Yeah, I'm hungry too. Okay, oh. So thanks for a great session. I especially wanted to call out your comments around planning out text formats and role permissions. I think that that's actually real work in a site configuration that people tend to overlook and not build into planning. I think it can also be a little hard to sell people. We're gonna need some hours in here to figure out your content type and what these are gonna be, but I think that's as a project manager, like an area that I'm really interested in. One other question that I was going to ask, which has now slipped out of my brain, so I'll just leave it at that. Yeah, one thing on the content editing thing is that it's sort of part of your content audit, actually. When you plan what text formats you need, you're thinking about what content they have, so it's really a good idea to think about that when you're looking at existing HTML, that kind of thing. The other thing I remembered, so, and again, looking at the WYSIWYG, one of the buttons that's on there that we always have a hard time getting people to remember and use, is that paste from word button because everyone is constantly pasting out of word and bringing formatting in with them. Any suggestions around how to foolproof that or just better ways for stripping out other formatting? Yeah, I love paste from word. Shift, control, paste, okay. Yeah, depending on your browser, there might be better support for that prompt, yes? Thanks, I am still on Drupal 7 and I'm still new to Drupal and we're trying to figure out some of these problems, so it seems like a lot of your suggestions might be targeting Drupal 8, so is there like one thing that we could do right now? Actually, I should have mentioned this. Most of this you can do in Drupal 7. There's not too much here that's Drupal 8 specific, some things are a bit more flexible, easier to do, but you could go through this whole thing and kind of as a checklist and most of these things you can apply to Drupal 7 as well. There might be some modules like allowed formats is like better formats in Drupal 7, that kind of thing. And even with that, is there one thing? One thing? We only have time. What's the one thing? Largest impact. There's, go do the first slide, the first slide, adding and editing content, I mean, just make sure people can do that. Okay, thanks. I'll make it quick because I know you have a line here. So I do work in QA for an organization that we're on Drupal 7. Oh, nice. And we're trying to add some custom widgets and things like that now, but it does seem a lot of times that QA falls to the wayside, especially when building these tools that the end users are internal customers. So I like some of your recommendations as when I'm walking it, kind of walking them through not doing anything, just watching them, let them be the user. I guess my question is, do you have any other sort of test-centric ideas for users in advance? Like I like testing along the way, just sometimes things are moving so fast paced. So just any thoughts on that maybe? Yeah, so well, things like, if you're getting into custom development, I mean, one issue is that sometimes with development workflows, like someone's developing this custom widget and nobody else sees it until they're finished and then they apply it to all the content types and it's everywhere. So maybe as a QA person getting in a little earlier and seeing what that looks like before it gets committed to whatever, like the master branch, like that could maybe help. Or just even more in terms of the UX part, just having a quick wireframe, like if you're actually developing a custom widget, that's something to wireframe out. That's like a new chunk of UI. So I would recommend having some kind of prototype that you could show and just make sure it makes sense. Also just benchmarking against other tools is also a really good way. Like that's one thing that's being done right now for the out of the box initiative, well, out of the box initiative, but more specifically the admin UI initiative. They're looking at lots of other tools, other CMSs and what they're doing. So I would try that. Thank you very much. I just wanted to mention there's a great module out there that has a release 4.8 called Stax. It's kind of flying under the radar, but there's a company that's focusing on building it. They got a few guys maintaining it. So we've launched it for a couple of sites. We're mainly using it for those landing page type layouts. And we've done a few tweaks to it to make it work for us, but you guys keep an eye out for that. It's solved a lot of solutions for us, basically for those content editors that want to come in and just do full with images with text and graphics over top and building out these really complex things that are typically done in templates. We typically went through a whole design process, but now we're able to hand in that a non-tech person can build them out and they're having great success. So I think it's a little further along than layout builder, keeping an eye on that and we have big hopes for that too. Sure, yeah, I'll check it out. Yeah, we'll check it out. It's been a great solution for us. Just wanted to mention it, thanks. Thank you. I just had a comment for the guy who actually left. He was asking about the QA process. One of the things that I try to do whenever I possibly can and it ties in with what you said at the very beginning is try to do the admin training as early as possible. If possible, I would even go even further and say if at all possible, once you have your content types built, push that up to staging and do the training while you're doing development and you have the client starting that process right away so you can find if you have structure issues, you can find that and fix it right away. If there's something they don't understand, you can address it. Yeah, absolutely. And at the same time, you can also pull that down and now you're working with real content as you develop. So the sooner you can possibly get it, the site doesn't even have to be done. You can still be building up functionality but you have those inputs in there. You can train the client to do that. I totally agree. I think that becomes then a challenge more on the workflow side of like, okay, what's our master database? People are starting to add content types but we're changing them. So that can be, I know, a little scary for dev teams but I totally agree with the sentiment. I think that's a great idea. So one of the things I wanted to say is I left Drupal in 2012 for WordPress because one of the biggest reasons was the admin UX was just impossible with Drupal with my clients. And I was a Drupal developer for six years and I'm coming back. This is my first word Drupal camp in six years and I'm completely blown away by the amount of consideration people are giving to the admin UX. Yeah, actually I just found a thread today from 2012 when the current general admin UI was being revamped for Drupal seven. So welcome back and that's amazing. I love that. One of the things is a lot I've seen here is people talking about decoupling and creating your own admin. And I think that's brilliant and beautiful. And I've also seen the demo for the Layout Builder and that's super cool. I think that's something that WordPress has had a lot of and it's cool to see it sort of coming into Drupal. There's pros and cons with that definitely. I just had an idea though just to maybe think about and just to ask what if and is it possible maybe to use the Layout Builder and the admin side to build your custom pages. That is an option. Not something that exists but like what if, you know. That is already an option, yeah. There is already a way to override the layout of individual nodes with the Layout Builder, so. Awesome, thank you so much for the talk, I loved it. Hi there, you had a slide about help text and that's something my organization definitely needs. So I'm just curious if you recommend a module or custom coding that in. Oh, that's already there for every field. You can add a. So I guess in terms of every field in the content layout but in terms of lots of our users get confused with revision operations and URL alias and I don't think they know the terminology so is there any ability to add it to other sections? That's a good point. So for extra things that you can't do through configuration, one of the easiest module development things to do, like when I teach module development this is the first thing I teach people to do is just to go in and do a form alter to change the form to add to alter some of that stuff or for Drupal 7 you could use it to hide fields, Drupal 8 you don't need that so much but just adding extra text into the UI that's something you can do pretty easily that way. Awesome, thank you. Okay, thanks everyone for staying to the bitter end. Bon appetit and talk to you in the hallway. Can I post your slides on the website? Yes. I totally call that you, can you? I think it's an option. Let's just.