 All right. I'm impressed at how many of you are up this early in the morning after all the parties last night. Well done. It's a good group. Just a minute as last year, you're kind of jumping in. There's still a couple seats up front. It looks like. All right. Well, as was mentioned, thanks for coming out early in the morning today. Hope the keynote was good this morning as we went through. So we're all here right now. Hopefully we're all here for understanding the shift of user experience design over to editorial experience design. I hope, if not, the door's still open. Feel free to run to something else along the way. But we'll be talking today about that side of it. Yeah, throughout this talk, we'll reference this shift. But what is this shift? It's not a shift of resources. It's more of a shift of thinking. It's priorities. And it'll spend more time on your site than the end users do. So we should really be making some sort of an effort to prioritize their experience as well. So what if we can make improvements without totally rebuilding our entire site? Yeah, so one size does not fit all. And we'll kind of get into that a little bit after a little bit of our word from our sponsors. Before we start, we want to really make sure to emphasize for tomorrow the contribution sprints. Hopefully all of you are coming out for that tomorrow. We've got a bunch of different ones going on all day for people from hardcore developers, all the way to business, to strategy, any type of side of things you can contribute back to Drupal. And let's make sure that we are contributing back to what's actually made our careers and everything great on the side of that. I'm Kevin Basterab. I'm the director of development at Media Current. I come from 10 years of Drupal experience as well as the editorial teams before this. So I was actually an editor working in these systems before going into development from there in systems that you might loosely call a CMS at that time. And I'm Mike Prasella. I'm an engineering manager at Group 9 Media. I've been working with Drupal for about six years, working very closely with editorial teams. Awesome. So you may not know what Group 9 is, but chances are you've seen some of our content online. We are a partnership of four brands, Thrust, NowThis News, The Dodo, and Seeker. We are quietly one of the world's largest digital-first media companies. We have over 4.5 billion video views per month and 1.7 billion minutes of content watched per month. We are headquartered in New York City with offices in LA and San Fran. Awesome. And I'm with Media Current, as I mentioned, and Media Current's a full-service digital agency that we're working to implement world-class, open-source software development, strategy, and design to further to reach defined goals for enterprise organizations, seeking a better return on investment. So all sorts of sides of things from the digital agency experience for over 10 years now on into our 11th year. So today we're gonna talk about, like I said, what the shift is and try to give us more context. Then we'll explore why this matters, how you can leverage contrib, how you can write a customer code to improve experiences, where we see it moving towards the future, and how you can start today. Yeah, so first we wanna have a little bit of a recognition that editors are probably the voice of your company. Whatever you're in and what industry you're in, you likely have people generating content. That's why we're using Drupal. And most likely these people are you spending more site on your site than your actual end users that you're delivering products to. They're working eight, nine hours a day directly in your systems. And we're here at DrupalCon, so we're all familiar with what Drupal is. We know some of its quirks. We know all those little ins and outs of little intricacies of the node forms and all that good stuff. But your editorial users might not. So before we kinda get into how we improve that, we kinda wanna know what this Drupal thing even is sometimes. We have to take a step back and understand what that might be. So these editors, they're interacting with their tools and your tools first and foremost and constantly comparing them to what they're doing in other industries or where they might've come from in the past. So let's take a minute and think about where they come from in the past. For us in Drupal, oftentimes we're comparing Drupal against things like Sitecore, AEM, or WordPress. But your editors might be thinking of things and working in things such as Google Doc or Word or Notepad even at that extent. But there's also other areas that have come out along the way. So things like Squarespace and Wix. We often are hearing about these and editors are working in those all the time. They love that fancy whizbingy drag and drop that we always see along the way. We can go to another level and think of things like Contentful, which is an API-first CMS that doesn't even have a front-end site. It's strictly focused on the editors. And then things like not even CMSs at all, but Medium and Buzzfeed. Oftentimes who we're working with and who is using our site have come from these types of CMSs and sites in the past. So editors know these other systems. They don't know necessarily what Drupal is, like those of us here at DrupalCon do. But oftentimes that system and Drupal itself becomes the system that doesn't do what they want to do. And that's not just a simple thing that Drupal has as a problem either. It's easy for users who aren't familiar with Drupal to identify its forthcoming or shortcomings, but oftentimes those same users don't like any of these other CMSs either. If we think about all those other alternatives, they don't have, they're not without their faults either. Looking here, almost every alternative we listen to the prior slide has similar problems. It might be slow. Hard to use, not working, not good. Why is it such a widespread thing? And furthermore, why are we all laughing here and not shocked by this at all? So let's take a step back real quick and think about your tools. As an audience here, name some things that you don't like about the CMSs at your end. Are there things that kind of stand out? Just shout them out. Maybe too many fields. Is it too convoluted, opaque, unclear? Workflow restrictions. I heard visual design. Visual design all the time. These aren't unique problems to Drupal and we need to continue to think about that and we can make those improvements along the way. The point is that when a site reaches a certain level of complexity, everyone runs in the exact same hurdles no matter where we are. So here you are with an intricate and complex website that requires complexity in the tools. So who cares if the tools are complicated? It works, right? As a developer, you don't really see the day-to-day of the editors and as an editor you don't see what the developer does on a day-to-day basis. But we're both on the same team and we both benefit when the other succeeds. So work can be done to improve these bridges to build empathy between the teams. We have to make sure the content creators have the tools available to them to create content for as many different platforms as possible because we're in the business of content management, not website management. Your CMS is the source of truth for all content consumption, not just the website. For the Dodo, Facebook Instant can account for 55 to 60% of all of our traffic per month. So whenever a new platform comes along, so Apple News, Facebook Instant, Google AMP, or people are consuming content, we need to be able to easily and quickly send our entire backlog of content to that platform. So it's not just content creation, content management, and more and more data management. So let's take a quick step backwards for a second. So at Group 9, we have freelancers almost every major city in the US, including many international cities. The current workflow for freelancers involves sending a Microsoft Word document or Google Doc to a production assistant to input into the CMS. We're not just supporting a team of four, we're supporting a team of 300, and that is a terrible process. So in there publishing over 100 pieces of content per day. At this scale, imagine the time and money being wasted by making the tools not friendly enough for our users. Unfortunately, the current reality is that the tools are largely built without editorial input and by people who enjoy using Emacs. So why does the idea of focusing on the editorial experience matter? Well, visual refreshes are common. Separating the data in the display layers enables more frequent visual refreshes. Editors spend more time building content, not creating content. We as developers spend hours to shave 100 milliseconds off of the front-end render time, but rarely consider optimizing the back-end. Happy editors means better content. An editor that feels supported by their tools feels empowered to create content and feels ownership over the tools and the content. So as a developer, I'm not just focused on content creation, like I said, but data management. Yeah, and this is why developers of itself don't like WYSIWYG. I mean, this is a very popular tool set because it emulates that tool set that we're talking about that editors are familiar with. As Mike was mentioning, most of their editors are using Word and emailing those documents in to actually get these onto the website. So it's familiar. And a lot of times, editors will request that something familiar like WYSIWYG get put into their CMSs. The problem is, as we all know, what you see isn't really what you get. Who has ever tried to move an image in a WYSIWYG editor and had the entire file or anything explode as we go along? So more than that, though, if we think about just even this layout side of it, WYSIWYG goes against our entire desire to split the display and data layers and adapt to these new platforms that are coming out. It severely limits our ability to create once and publish anywhere. There are systems and modules that we can use to help make this better. Things like NT embed module, link it module, different things along the way. But all of these are still making the assumption that the content is always gonna be preceded or followed by the exact same content in any instance that we have along the way. So, we know WYSIWYG isn't the tool of the future, but it is gonna be familiar editors. So how do we go ahead and transition to a modern and unfamiliar editing experience while keeping our editors happy and productive? So, contrived. That's here to the rescue. We're all here working on Drupal 8 now, right? Anyone? We're all also updating the new point releases. We're getting those new features every six months. We're updating that right away, right? All the new stuff? Somewhat? As you're aware, with Drupal, we have a wealth of individual modules available that can do all sorts of things for us. But, even for those modules that don't exist, we now have Drupal 8. And with that comes this great new object-oriented architecture. It's got a great plug-in API. And we have the ability to extend core more than we ever had before. So we're at a great ground level spot to really build out and make these tools. So, aside from the custom and building, let's think about what we can do right now with modules that are available to help improve your tools, your editor experiences, and allow your team to see sunlight for the next couple of months. Things like field widgets. Plug-in field widgets are a great thing that Drupal's had for the longest time. They've come a long way in Drupal 8, but it's one of the simplest changes you can make. Just by, without any code changes on our form displays, we can modify the widget and make a really big impact to our editors. For example, something like utilizing autocomplete deluxe versus the core autocomplete module can give an editor a friendlier user interface for selecting terms. They can see the difference between terms more clearly, and we're still retaining the same data structure on the back end. Has anyone ever had terms that have commas in them and trying to use a general the core autocomplete field with that? Doesn't really work that great. Other things though, such as like inline entity form or the entity browser are helping to keep the editors and users on the page and still ensure your data architecture is intact. Just because we want to make a good user experience doesn't mean we need to cluster all that together one giant JSON object. We can still keep a good data architecture. Remember, for all of us here, and I think there's probably a lot of people that are more on the business and marketing side here too, you're not getting ad revenue per click in your CMS. You want to keep editors on the page. Make their jobs easier. The other thing that we always look at a lot is media. This is notoriously one of Drupal's biggest weaknesses. You heard a lot about that during the Drees Note earlier this week. It's been a big focus of this conference and it always has been a big focus of us in general. But our experiences are more and more more media heavy versus text heavy. So media is a core part of what we're doing day to day. So improving that experience is going to vastly improve your user's experience along the way. Look at that focus of the media initiative we've had within Drupal Core. But just by using Drupal, doesn't mean you're limited to a terrible media experience and we just got to wait and wait for things to happen. There are numerous modules already out addressing most of this media problems within Drupal and the experience. For example, I talked about that NT browser a little bit ago. That allows reuse of your image library. It also could allow things like friendlier access to S3, dams, remote file systems, things like that. You can use something like the focal point module to actually allow automated cropping to crop where you want things to crop. Why do we need to create 15 different aspect ratios or have to rely on the front end teams to tell us what we need to do? We can pass one value, say where this image should be cropped around and let our designs determine that from that point. We can also think about things such as multiple upload, the drop zone JS module, it says right away for you. But there's a lot of individual modules to kind of make this good experience. There's lots of individual configurations, things like that. When I first started using Drupal, one of the things I try to do is make a slideshow. The first tutorial in Drupal 4.7 or 5 was like download these 50 different modules to make it happen. Didn't really make any sense. So they do require a lot of configurations, lots of updates. But that barrier entry can be reduced quite a bit by using distributions that can help pre-configure some of this for you. So things like the lightning distribution or thunder or even some of the new experimental things that are going in core like the new media entity in core can help us get further along that way. Also looking at the other sides of forms and just the general organization of our structure. Think about what our editors are gonna be looking at there. If you're not using things like the sticky or publish the front page options, it's nobody that ever does. Go ahead and use the override node options module and get rid of those fields. Why do we want to show our editor things? If we're hiding form fields there, why not hide the various administrative menu items that we're showing to our users all the time as well? They're... So if you had editorial users, SEO users, super users, maybe it makes sense to hide things like taxonomy management from your editorial users and allow that for admins and super users. Yeah, we have, we make user personas for almost everything we do on our front end of our sites. Do we ever really think about the user personas of the editors using our sites? They aren't just a one-size-fits-all. They have very different roles that they have to do, especially as your organizations scale up. So don't confuse your users with menu items that don't apply to them. Things like the menu per role module helps set up that a lot easier and sets you up for those individual roles to only surface those relevant items to the content and the persona that they exist in. Then you can expand that even further by using something like the admin toolbar and eliminate those unnecessary clicks and make an editor get to things quicker along the way. But why stop at just menu customization? What value does seeing our own user profile on login do whenever we log into a site? Oh yeah, that's what my name is again. I really forgot that this morning. We always redirect our users to that by default and even at that side, what even value is if you go to slash admin? I just see a list of a bunch of menu items. I don't really know where I need to go or what I need to do. So why not give a user a list of their most recent content instead? Why not give them something that needs a review or their most popular article to see what's performing well for them? You can do this without control modules at all, just using core views to create a nice dashboard to showcase some of this. But if you want kind of that baseline and starting point, there's a module, total control module that'll help you set a baseline for these dashboards that you can easily then expand upon. And then from there, you can take things like the login destination module, which still needs a Drupal 8 stable by the way, and gets out to redirect your users again without doing any code, but it's a pretty simple code change to if you wanted to do that. And then finally, we talked a lot about all the fields that you saw when we talked about earlier about why systems are so bad. So why don't we control our node forms and use field group module and help control our field vomit. Hopefully it doesn't have any problems for anyone after last night. So Contrib's only gonna get you so far. And but your organization's architecture is going to be unique. None of this is gonna necessarily work for everybody. It's a good starting point but you have to still do some customization for your organization. So you might need to consider some other customizations. For example, the Paragraphs module, which we all probably know and love at this point. You can start by doing something as simple as replacing a WYSIWYG field on your content type with a Paragraphs field while retaining the legacy field for display purposes. So while we were working on the G9 redesign, we had to, let's see, products such as Paragraphs are not without the flaws. So we at G9 have some articles that have 250 plus elements on a single page. That might sound crazy and it is. But we have list of goals such as, you know, top 100 things to do in Nashville and those articles consist of body text, image, body text, and when you think about that, 200 makes sense. Now imagine trying to use core paragraphs and add a element that adds it to the bottom but you want it at the top. The drag and drop is not the solution there. So we patched and added some functionality to add inline buttons for the paragraph elements and it's helped immensely. Yeah, those inline buttons are amazing. That was patched against the original paragraphs. And again, as we talked about the contribution sprints tomorrow, the community took that initial patch. We had actually built it upon one that had been started already, got it to work for G9. The community took that even further and now that's part of the Paragraphs feature module so you can download individually or use as part of the Thunder distribution. In addition, we also patched paragraphs to allow for some inline saving of paragraphs which inadvertently created this auto-save functionality. And that was done by one of the developers in the room here too actually. So that is something that's right now in a custom field widget but it is something that is planned to contribute back into the community as it's own module and eventually get pulled into different pieces from there based on the experimental field widget. And finally, we utilized the Paragraphs browser module to group the available components for each of Group 9's brands. And as we're talking about even that 250, there's a lot of individual performance concerns there too and I know Mike and your team's been working a lot on helping to fix that that we look into to contribute back soon as well. So without a box paragraph, we still have a bit of that field vomit though. You still have a bunch of fields lined up and especially when you have 250, there's all sorts of things in the row. What's this content actually gonna look like? I just see a whole bunch of fields with random content along the way. How do we showcase that? So at Group 9, we display what I like to call a caricature of content to the editors. So on the left here, we can see what this article looks like in the admin screen. On the right is how it looks on the production site. This doesn't require any additional modules at all. This is all CSS and Twig extensions overriding the default preview for the paragraphs, changing the default state to closed. And it's not pixel perfect, but you don't want pixel perfect with editors. It kinda gives them this representation of the content and forces them to think outside of the website context and think more about the content. Yeah, if you're trying to make this pixel perfect on the back end, the editors are gonna expect that on the front end. And oftentimes, they're not gonna see the content in the same context that they're seeing on a desktop. They're seeing it on mobile. They're seeing it on random devices. It might not even be visual at all. It might be voice at that point. So what about some other things we should consider along the way that you're not gonna find in Out of the Box contrib? And things we can think about that aren't just like a module you install, but ways of thinking about our editorial experiences. So one of the things we don't wanna do is don't make editors remember fallbacks. Make sure to put your fallbacks into presaves or something. So what do I mean by that? Oftentimes we have a front page headline or a teaser image or something like that that goes out to a landing page. And that's in a separate field on our CMS. Rather than putting the logic for rendering if else of what to display depending on things, put that on your form saves or into something so that the next time the editor edits that content, that field's filled out with what is there and they can edit one place. And then for you on the front end, you don't have to put all that display logic every single time you use that content. And when you change it, it's much easier to change up. You can also do things such as using logical defaults. So say you have an editor that always writes about restaurants or always writes about super cute puppies. Why not set their taxonomy automatically for that individual content based on their user profile? Give them something to default to what they are always doing. If you're uploading a video or doing something else, determine the video aspect ratio automatically for them. Don't make them think about things that you can do programmatically for them. Also, don't make your editors think about how your content is going to be displayed. We don't want them thinking in the context of just a desktop experience. We're expanding out as we're talking about it's a content management, it's data management, we're expanding to all inclusive website platform not website in and of itself. So do think in terms of what content is best for this field. Use your help text, use good labels, make sure it is understandable and editors don't need to know what the front end looks like or how this is ever going to be used. They just know what the context is in this side. And we do want to also eliminate unnecessary actions. Things like required fields. How many of you have ever, I know for myself working in news, breaking news is always terrible on some sites because there's 50 different required fields and I just want to get content up fast and every time I save, there's something else that's required that I didn't fill out. So save those additional clicks, eliminate those required fields, maybe give some guidance on them if you save and say, hey, you might want to go back and look at these, but don't force them to not edit at that point. If it looks bad, they're going to figure that out pretty quickly and don't force them to go to another page along the way. So that's a lot of kind of what we're doing right now and what things you can do right now, but Drupal's always continuing to evolve. We evolve our website interfaces all the time. As we were talking about earlier, we're going into new systems, we're redoing our front ends very often, doing these visual refreshes. We need to also understand that the editorial experience is going to continue to evolve as well and we need to keep up with that. So what kind of things should we think about that are coming next? So things like preview in context versus in context editing. Remember your content is going to be used anywhere. You don't know what the context is or where it's going to be. So I'm avoiding using inline editing there because we have made great strides in quick edit, but oftentimes now, things aren't actually going to display right on a site like that. It could be in an app or somewhere else that you can't just quick edit that way, at least easily and scalable for all the use cases that Drupal has. Think about things like what effect the JavaScript initiatives are going to have. Things like decoupled editing are coming along. That can make things as well. We saw a lot about the Project Moon Racer from Weather Channel the other week, or the other day. So those kind of things coming up as well. Stop thinking about just making an article. You're making content and content is consumed all outside of the website. Your website is a syndicate to other sources. Also be aware of the upcoming layout initiative. We focus a lot on paragraphs during this session. That's what Group 9 is using. It's what we immediately use often for everything, but the new layout initiative is changing the game a bit. Let's adapt to that, but while we do that, let's ensure that our editors have a consistent experience. We don't want to send people to different parts of the site and oh, on this page I edit this way, but on this other page I edit a whole different way, and on this other page it's a whole other system. Try and stay consistent. Feel free to try it out, do prototyping, but understand that you need to keep consistency across your experiences and your editors from getting confused in that direction. And then be aware of where our editors are actually editing in general. Be cognizant of maybe mobile-first editing. We talk about mobile-first design, but mobile-first editing. Utilizing things like native functionality, such as your phone's camera or media, where are your editors gonna be in a year from now or two years from now? Just like we think about where our users are gonna be in a year from now or two years from now. This is a Google Analytics screenshot showing all of the operating systems that have accessed our CMS in the past year. So just like how users have been moving to primarily mobile experience, our editors are more and more moving as well. Sounds weird, but at now this, we have reporters on the ground in places with low connectivity and they need to be able to create content on the fly. We're seeing more and more that they're accessing through mobile devices. In addition to one cowboy who decided that Nintendo Wii was a viable editing platform. Do you think he actually did what he needed to do? No. No. I'm not sure that the Drupal Ajax system works so well than Nintendo Wii. All right, so at this point, all of you are sold. That's why you're here in the first place. It's time to redo our entire editorial experience. Time to hire a full-time UX designer for your tools, walk developers in a Windows room and fix all the things. Well, no, as we've said, this can be an iterative undertaking. There are plenty of contrary modules that you can install today and there's custom modifications that you can add very easily. That being said, the first step is gonna be the same no matter what. Talk to your editors. Editors are the voice of your company. Get to know them, love them, understand their needs. Determine workflows. What's most important? What's their current pain points? We have a weekly meeting actually that we have between project managers, tech and editorial. This allows us to understand their needs and be proactive when it comes to that. Be prepared to iterate and continue improving. Sure that you're willing to help their concerns. An easy way to do this is to let them know when one of their suggestions makes it into a deploy. Just a quick deploy email. Each deploy should keep the status quo. Don't make their experience worse. And most important, an editor that feels supported by their tools, feels empowered to create content. It feels ownership over the tools and the content. Happier editors means better content. Thanks. Thank you. That's what we have for today. I'm still high. We have about 10 minutes left for questions so we've lined up perfectly on our timing. But one of the things I do want to remind everyone for real quick is make sure to come back and give us feedback on the session. Let us know how we did, what you liked, what you didn't like. Some links up here on the slides kind of used for that side of it. But any questions? The microphone is open up here. We can talk about that. Hi, thanks, that was great. We just did a big upgrade from six to seven so we're a little bit behind. But we just went from a WYSIWYG to paragraphs and I get to train over 200 editors and convince them that this is like a really good thing. And I think I've made some good progress but I was wondering if you have any advice on working with editors who are transitioning from a WYSIWYG to paragraphs for people who are training and instructing. Sure, one thing that actually we, we're not fully off WYSIWYG. We have paragraphs like body text which has WYSIWYG inside of it and we severely limit what tags they can use inside of it. Also the caricature of the content, it doesn't make them, they don't see all these fields so it kind of looks nice to them so they don't complain too much. So a combination of weaning, so still having this WYSIWYG but maybe limiting how many, how much functionality you have inside of it and also making it look better. That's what we found. Yeah, thinking about things like that ad between and that's kind of getting into that style of what Medium and BuzzFeed are doing. Like I'm just writing one little piece of content and then I expand out from there. If you're thinking in that direction it's a lot easier to kind of think about it in there. And I know in the paragraphs feature module also there's like a WYSIWYG tool there that you can actually just paste something in there and just start splitting that up. So if I only have one image I can just hit a split it'll jump it out and you can add another pair up between for that component. But giving them those guidelines and guiding them into it. So my question is about when you have huge giant nested taxonomies and I've used hierarchical select, simple select widgets but either for the editor or for the user when they're subscribing in these huge interfaces. Do you guys have advice about that problem? You do as well. It's a tough problem. We have some large hierarchical taxonomies as well and we've utilized autocomplete deluxe with some custom code that we're hoping to contribute back at some point. It's a really tough problem right now. I was actually just working on a site where I had a similar problem and I used hierarchical select. But hoping to expand autocomplete deluxe to pass what it has right now to support that. I'm sorry I don't have a better answer. Some of the things done in autocomplete deluxe right now because actually as part of this site we took over a maintainership of that module as well is actually making so you can search from the parent terms and get the child terms in it and also showing the display of the parent child all the way down. So that way, for instance on our example we have cities and kind of cities up to the state and regional level. So if you type in a city like let's say Springfields that's like the most common city in the whole US. You don't just see Springfield and not know what context is. You get the hierarchical up from there to understand which state you're actually looking at. I think while that's in the control module now already and then there's some additional ones of like how do we make sure to tag even the terms up from there. So we used to use taxonomy term tree in the past to say oh I'm using Springfield but I also want to tag the ones above so I don't need to do these massive joins in depth when I'm doing views for performance concerns. You talked about thinking of editors using phones and mobile devices. Is there any way to add an image just by snapping on your phone yet or is that coming up and coming? Yeah right now, at least in the stuff that I've seen so far and there's a lot of smarter people in the midst than they might have other ideas but I haven't seen that yet so far but a lot of the new especially the new JavaScript initiatives should allow us to get to that point and I'm sure there's some people doing some of that already actually on the individual widgets but I haven't seen that in contrib yet but I'm sure it's on the way at some point but it's definitely I think one of the things that we're heading very much toward because that's a very obvious thing of oh I need to actually I want to snap that image right here and other sites are heading that direction but yeah. Great question. When you're browsing all these contrib modules out there how do you determine when you're adding just enough functionality for your editors to feel more productive and when you're just adding module bloat for the sake of like this looks really cool. Yeah that's a great question. Actually some of the examples we gave in here something like override node options is something that I normally wouldn't install on a site because it's just as easy to write two lines of code and get rid of those fields without an extra module but trying to focus on that side of where do you go and where's the cost benefit analysis of that I think is what you're looking at there and oftentimes where one of the biggest benefits are is getting you to that 80% side. See what's happening and what's actually giving some good benefits to the user without putting a lot of customization into it and then figuring out from there how do we evaluate from that and what do we want to add on to it and that's one of the nice as we were talking about earlier with the ways of object-oriented now we can actually extend contrib a lot better rather than just copying and pasting the module over or hacking the module in the past to that to the point about how do you even evaluate that and understand it oftentimes just thinking about what the code is to do that custom. I'll often look at what the actual module code looks like. What are they adding, is there, oftentimes one of the benefits you get with contrib is extra admin selections and options for it so auto-complete deluxe for example you have a lot of different options you can choose from for different varieties of things you can do on the widget settings. If you did that custom you might not get all those additional options with it you might just do the very core piece you want to do along the way. Is that line up a little bit? Awesome, thanks. Thanks. Anybody else? I'll repeat it, that's okay. Yeah. Yeah, so I'll summarize that a little bit just for the recording and all but basically the question is about how do you take something when you've done some customizations and how do you understand where that line is to figure out how to contribute that back and when you go down that path and that's exactly actually the reason why when we mention that autosave functionality it's not in contrib yet because it was that exact same situation where it's just gone through its custom widget there were so many patches we were using to kind of get to the initial point it just became its own custom beast at that point and now it's that idea of trying to stay following the community and where it's going and adapting yourself to that and splitting things out that are logical along the way. So we always talk about tech bloat along the way and like the technical debt we make through sites we have to make sure we're prioritizing to come back and fix that just like we're looking to always continue to improve our experiences as well. So as we're thinking about, I'll use that autosave as a good example there too and you mentioned drag and drop because that was part of when we were looking at doing the add between there was no way at the point we were doing this product that was gonna get into paragraphs because there was a first initiative to get better drag and drop added in. That's now landed in contrib so now there's an option to kind of go back and say okay maybe we can reassess this and add it back in. Also looking at things like using a sandbox module I think that's what we did on auto complete deluxe where we sandboxed it first and then got everything kind of where it needed to be and created one patch from it instead of trying to follow and track six different issues that don't necessarily always line up along the way to get that initial piece and then reassess after to break it up again. Anybody else? Yeah. I lost my voice so definitely. We were worried about that too. Yeah. Good night. Thoughts on admin themes which you like, don't like and you know we don't need to talk about that. We use a minimal. Adminimal. Adminimal. You know we get a lot of grief from our designers and our marketing guys who are like is this the best you can do? Yeah it's the best we can do. Unless you want to hire some designers and make a theme like by all means but Adminimal is what we use and we love it. Yeah it was like going back and looking at like Drees Note from the other day I remember we were on separate sides of the room at the time and like we immediately text each other the exact same time we saw kind of the mock-up of the new admin theme we're like aw this is going to be great but it is that side of things that right now Adminimal is the best thing and you can add onto it very easily and that's where we try to focus on let's not recreate all of it but focus on the small part that's going to give the biggest impact to your editors. So if there's something and this is where talking to your editors comes in so much we might think of something that's a problem and all the random over-engineered solutions likely to solve it but oftentimes an editor just needs one simple thing done that would save their lives so much more and if you find out what that is you can make a huge impact for them on that and if there's some random style that just never made sense to them let's just fix that one thing first rather than trying to overhaul everything from the ground up. That's one of the differences in Drupal is we're still so developer focused to begin with and we're making that shift away from developers in general to help assess the greater area we have to be looking at that as well as we can't always make the perfect solution but let's make the solution that gets the most impact back to our editors. Yeah, a great example of something that we might want to add to the site but isn't necessarily needed is a little while ago I was looking at coffee I'm not sure if you guys are familiar with the coffee module but it's basically an Alfred-like search. Yeah. And I'm talking to the editors and they're like, well, we just bookmark everything and I was like, oh, okay, so I probably don't need to add this fancy bell and whistle when you guys just have one in your Chrome browser you just have one large list of bookmarks. That's even where we're going to where your editors are and understand your organization. We talk a lot about media and media library but the group nine is a great example of this of where they just have them in a great organized system already on a file system and they don't need it in the system because they know exactly where to find it in an original form and just upload it into the site. Yeah, so for the recording there was a session earlier so we can go back and look at the recording on two on the material theme. It's called material admin. Material admin theme. It's kind of based on the Google material design principles. Thanks for a great session. On one of your points about reducing mandatory fields sort of flies in the face of an accessibility session I just went to and some of the changes we just made to our site to force everyone to add alt text and all these types of things. So how do you square that circle? Alt text is a required field still. Yeah, it depends on what the field is. Of course, one thing that we do at group nine is we have a taxonomy term for our brand so we have four brands and each content is tagged with which brand is four but we don't allow our editors to see that. It's a required field but what we do is we just logically set that based off of the domain that they access it from. So things like that where you can kind of, not alt text unless you have some crazy machine learning but if you have a field that is always gonna be this value or if the, like we said, if an editor is a news editor and they always tag their content with news and what the location is, then maybe you can glean that from the session and just auto fill all those. Yeah, we have to trust that our users, we do have really smart editors. I know there's this stereotype oftentimes that just editors are just putting things in. They're really smart, they understand things and they're gonna understand your site but oftentimes where the required fields that we're talking about there come into play is we have to have three pieces of content to make this look the most perfect hero display ever and it has to only be 60 characters long and it can't have any variation than whatever we define in the designer UX side of it. That's not the real world situation. So yes, we know we might wanna get to that but maybe we need to get something up really quick just to have it there and it might not look perfect for the next 10 minutes but we're gonna come back and edit that and helping to guide them on that as well and this is where there's probably a good contrib opportunity, I haven't seen one yet on it but a way of saying that optionally required fields is something we've talked about in the past where before you save you might see like, hey, don't forget about these things or after you save even, hey, you might wanna go back and look at these that will help you out in the end and help guide the users to that along the way. Something like a checklist API or things like that too. One thing that we've also experimented with is doing context-required fields so that we have some required fields like which city the editor is in and such which is required but we don't require it during content creation, we only require it on publishing. That way we don't limit the editor when they're creating the content but we make sure they have everything that they need when they're actually sending the content out. I know there's work being done in I think even core to head to that direction of making sure that, hey, we don't need to require it until we're ready to publish because that often gets in the way if we have a required field, yeah, it's great to have that when we're going to publish but it's gonna go through 10 iterations of editors likely before it is ready for publishing and maybe someone else's job is add that required field in. We don't need to add a placeholder at that point. All right. Well, thank you all very much. If you have any other questions just dig her out for a few minutes. That's good. That's good. He's good. He's good. He's good. He's good. He's good. He's good. He's good. He's good. He's good. He's good. He's a great person. Yeah. Yeah. I agree. I agree on ... Your guys lead? You guys, how are we? Power of my wisdom. More of the debate or the IT? Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah! Yeah!