 Hi everybody, thanks for coming. My name is Greg Dunlap and this is a session about designing content authoring experiences. I am the Director of Strategy at Lullabot. We have been in business for 15 years and we cover a broad variety of different types of clients including media, financial services, higher ed and state governments. And as of two years ago, we are 100% employee owned and that's really cool. And we do full scale, full stack front and back in development as well as design and strategy services and I lead our content strategy department at Lullabot. I don't know why I have that slide twice. So about five years ago, I was at a conference called CONFAB and CONFAB is sort of the premier conference for content strategy and it's held in Minneapolis every year. And somebody was doing a presentation and they got up on their stage and they opened their presentation by asking the room, which was full of about six or seven hundred people, how many people here love their CMS? Does anyone want to guess how many hands went up? One, it was mine. And it was really interesting because it got me thinking about why people hate their CMSs and why people don't like to deal with their CMSs. And I think that the interesting thing is that in most of these cases, it's not that these people hate their CMS or hate Drupal or Psychcore or whatever they're working with. What they hate is the fact that their CMS was built without their needs in mind. They were built with opaque business requirements sent down from Ohio with no consideration for their use cases. They're complaining about being disenfranchised from the decision making process and from the process of anything involving getting their work done. And they hate systems that are not built with their needs and use cases in mind. And I think it's really important because you would think that when you spend millions of dollars creating a CMS platform, you would actually want people to engage with it. You would want people to make content in it because that's the whole purpose of it. If people are filled with dread every time they log into their CMS, guess what? They're not going to. And once they're in there, they'll do as little as humanly possible and get the hell out. And that's not how you create quality content in your content management system. And so I've been thinking a lot over the past several years about authoring experience and about what we can do to improve authoring experience for our customers. I'm actually in the process of writing a book about this that is going to be published at the beginning of next year. And this talk kind of highlights some of the things in that book as well. So let's take a look back. Before we look into how to solve this, I want to kind of take a brief look at the history of web content management. And for this purpose, I kind of divided this into three very broad phases. So the first phase is HTML files. Everything on the web is a single file sitting on a computer. You want a new page, you make a new file. You pull it down from the server, you edit it, you put it back. You want something on every page, you got to put it in every file. If it changes, you change every file. Hopefully you're not working on the same file as someone else because one of you is going to be really unhappy. This is how a lot of us built our very first websites in the 90s, and it was really exhausting. Now, during this time, most of the content on your websites was owned by programmers or system administrators. The people with really specialized knowledge of the internet and how the technology worked, because they were the only ones who understood what they needed to be able to make these changes, to log into these systems and edit these files. And if you needed changes to one of those things, you contacted them and they did it for you because the tools to make those changes were very complicated. However, the content needs at this time were extremely simple. You put some words on a web page and called it a day. Often the people running the website wrote the text on the pages, and it wasn't really business-critical technology back then. It was something that was done sort of as a Skunkworks project, basically in a lot of cases. So this was a situation where the tools required very specialized knowledge, but the content needs were very straightforward. Now in phase two, organizations start to realize the strategic importance of the web and marketing and executive stakeholders want more and more control over the content, but they lack the skills or knowledge to use the tools that they needed to make those changes. So people started to create content management systems to bridge the gap. The earliest ones were a little more than an interface to write HTML into a very simple form. This is actually a screenshot of the very first content management system I ever built. In 2003, for a church in Tennessee. And it's literally all it is, is editing paragraphs of text and dropping them into pages. The important thing here is that these new tools enabled normal people to have access to their websites. The sysadmins no longer held the keys, and it allowed a level of reuse. If you wanted a block of text in the footer of every page, you could do that. You got a little visual editor that gave you an idea of how your content was looked. It was very simple, but conceptually it was a very big step forward. And this was the beginning of a switch. The tools were on their way to becoming more approachable and less specialized. But the content was starting to become more complex. More planning was needed to create content that worked throughout larger organizations. And since that content was critical to their success, it started to require more care. And that leads us to today, and really this phase starts about 15 years ago. I would peg it as the release of the iPhone. And two critical things happened during this phase. And the first is that content management systems have matured immensely, to the point where they are really usable without any specialized training at all. But at the same time, the web has changed massively in this time. And the content itself has become immensely more complicated. We can't just write pages of content and call it a day anymore. Mobile devices have changed how we interact with the web. Enabling users with assistive devices has become a priority. SEO and social media have changed the way that people interact with content. Content is business critical at the highest level. And, you know, all sorts of external systems are using this content for different reasons, all the way up to AI agents that are now turning it into their large language models. And on top of all of that, all users expect a much higher level of quality and interactiveness than they used to. So here's the pattern. Our tools have become much more simple, but our content needs have become far more complicated over the years. So what? So what does this have to do with content authoring? Well, it's important for a few reasons. First off, I think a lot of us approach these issues from a Drupal context. Like, what can we do in Drupal to make things better? What can we build into Drupal admin to make things easier for content authors? And I kind of view that as the wrong question. What we should be asking is what can we do to support the complex and varied content needs that organizations bring to the table? And that leads us to the second thing, which is that if we're focused on solving complex content problems, then the answers are going to be very different from organization to organization. Different organizations have different needs and different types of content and different types of authors. And those, and as such, creating a single admin experience that's best for all of them is going to be very difficult. Here are two examples of organizations that I've worked with at Lullabot in the last few years. So we have a tech startup. This is a commercial enterprise that is running a single website with a very focused purpose. They have largely professional marketing people running and creating their content. These are people who have fairly extensive CMS experience, having used several CMSs in their careers. They are knowledgeable about the web and about topics like responsive design and SEO and analytics and how to gauge whether their content is being successful. And they're writing SEO-focused product marketing content. Now let's contrast that with a state government. So in a state government, we created a platform of multiple sites, one platform to run multiple government agencies. Most of the content people were subject matter experts. They were not people who had a lot of CMS experience. They were not very knowledgeable about the web. And they had a very, very broad topic base. They may be writing about taxes or about driver's licenses or about marriage licenses. They didn't have that focused content that the tech startup had. So approaching content authoring as a monolithic thing where certain solutions are right or wrong or better or worse is a mistake. There's no best content authoring experience. There's only the best content authoring experience for the authors you're working with and the organizations that they're creating content for and the content that they're creating. Context matters a lot. And so the question becomes, what can we provide that encourages better content for the use case at hand given the parameters that we're working with? And these answers aren't the same for every organization or every system, but finding the right answer is really critical for everybody involved. We can't change the web or the organizations that people work at, but we can spend time understanding the forces at play, taking those forces into consideration and working towards improving their lives. So how, how do we go about doing this? In my book, I outline a process that's actually very similar to the process by which you design the website itself. You do research, you prototype, you implement, you test, and you support your users after your product is launched. And this makes sense because from my viewpoint, content authors are users as much as the people who visit your website are, and they should be given the same level of consideration. We often refer to the content authors as internal users versus external users, the people who visit your website. Now, for the purposes of this talk, though, and for this audience, I'm going to focus really on the two biggest items, which are research and implementation. So let's start with research. The benefits of user research are pretty well known at this point in time, but there's one important goal to keep in mind when you're doing research with content authors, and that is that it offers you the ability to connect with them and get them invested in the process. In a lot of organizations, there's a big level of distrust or antagonism between the content authors and the people who run the CMS, and you need to bridge that gap, which can be really difficult. But sitting down and listening to people who have probably never in their lives been asked the question, what do you need or what problems do you have is a really big step in the right direction. You give them a seat at the table with all of the other stakeholders, and when we start a project, we are always very clear that when we begin our workshopping and research phases, we want content authors and publishers at the table with all of the rest of the marketing and executive stakeholders. If you want people to not hate the CMS that you're building, they have to be a part of the process. There are a variety of ways that we do research with people when we're starting projects, but the biggest one is just sitting down and talking to them. Authors' interviews provide the most direct feedback you can possibly have, and they allow you to hear people's day-to-day frustrations, identify functionality that's vital or missing, and establish big picture goals and priority issues. If you hear multiple people talking about their issues with document management or with design tools, then you know that's something you have to figure out. I actually love this. This is one of my favorite parts of the project, because you get to connect with people, you get to hear directly from them what they have to say, and then get them excited about what you're working on. Before we start interviewing, we always develop a protocol for the interviews, and this is a template that outlines everything that we would need to conduct an interview. The bulk of the interview is the questions you ask people, but there's also space for background information, introductory material, any instructions for people who are giving the interviews, etc. This can really help provide context for the interviewers who are conducting the interview, especially if they haven't been that involved in the project. For instance, if you know that one of the stakeholders is particularly prickly or has an axe to grind or something like that, you can put that into here so that they're prepared. You also need to identify who you want to interview, and in a small organization that's pretty easy, but in a larger organization, it can be more of a challenge. From my perspective, your main goal should be to get a broad range of viewpoints that represent a cross-section of the organization that you're talking to. You want people who are full-time web pros, and you also want people who only dabble in the CMS. You want your biggest cheerleaders and your crinkiest curmudgeons. The biggest departments and the ones with only five employees. Because if your system is going to work for all of these use cases, you have to hear them and understand them. Usually, when we set this protocol, we make a copy of it for each one of the interviews that we're doing, and we customize them as necessary. We'll do that in Google Doc or Dropbox Paper or something like that. These documents now are not just a guide for the interviewer, but a place for them to take notes that they can share after the interview is over. I've got a link to our sample protocol template in the resources section at the end of this presentation. Now, when you're conducting the interview, talking to these people fosters connection and encourages them to be more open with their answers. For that reason, I usually try to do these one-on-one with possible, because we want to, again, establish that sense of trust with people. Although you spend a lot of time creating the protocol, I think it's also important to feel like you can chase down threads when you want to. So, when you hear something broad or vague, like we need more design freedom, don't take it at face value. Dig into what the reasoning behind it is, because a lot of times people will come to you with solutions for problems that they have without thinking about what their problem really is. For example, someone may come to you and say, I need a color picker so that I can make my text multiple colors. But what do they actually need to do? What are they actually trying to achieve by doing that? Like, is it I need a way to highlight passages of texts that are important? Or our school colors are green and gold. These are very different problems, and they require different solutions, but for both of them, it's likely that offering a color picker is not the best answer. So, often you'll find that what people are asking for is related to a much broader problem, and the solution is something much different than what they need. Some of you may have heard of the Five Ways concept, which is when somebody gives you something they need, you ask why. And then when they answer, you ask why. And then when they answer, you ask why. And you continue digging down until you really get to the root of their problem, and that's what this is really all about. Finally, you shouldn't hesitate to ask your users to show you what their problem is. This is one of the reasons why I like to conduct author interviews in their workspaces, because then they can just grab their computer and show you the problem that they have without describing it. Because you'll hear a lot of comments like, oh, it's hard to work with images, or uploading documents doesn't work right, or stuff like that. But being able to see the problems that they're encountering, rather than just having them describe it, is really important. We were recently at a state government client where one of the people described to me how it took too many clicks to create a new piece of content. And I know how many clicks it takes to create a new piece of content, and it wasn't 10. And so I asked him, hey, can you log in and show me? And it turned out that he just didn't know the direct way to do it. He had this whole fumbling thing to get to add content that he had figured out on his own, because he had never bothered to look at the training materials. And so, you know, this is the kind of thing where, until he sat me down and showed me what he was doing, I wouldn't have understood it. Now, as you conduct the interviews, it can be helpful to summarize them in a matrix, which outlines key findings and interviewee engagement. It's really cool because when we do this, not only are we summarizing things, because usually we'll split into groups and do a bunch of interviews, and then everyone will come back together. But it's also really good because one of the things that we try to identify in these interviews is people who will kind of be, who are highly engaged in the process and highly enthusiastic about the project, because they're good people to come back to later when we need to run prototypes by them, or run tests by them, or things like that, because they'll want to be involved, and because they're so engaged, they'll be willing to take the time to give feedback for you. And so having all of this information in one place can be really helpful to identify groups of users or share key findings from these notes without everybody having to dig through them. And this template is also in the resources for our, at the end of this slide deck. So that's just one aspect of research. I mean, another, and we could go on and on with this. We do a lot of workshops at Lullabot with our people, which is where you get everybody in the same room and try and figure out the places where everybody's needs are aligned or not aligned and then sort it out and get everybody, hopefully, on the same page. We also do a lot of prototyping and testing with content authors. I do not have the time to get into all of that today, but they're all very important parts of the process, too. But let's get on to implementation because I'm going to assume that this room is heavily focused on developers and people who are building Drupal systems or involved in building Drupal systems. And I think there are some things that we can talk about here which are important to getting into supporting content authors. So I look at implementation from kind of two angles. There's content entry, which is the actual entering of content into like node edit forms, basically. And then there's content administration, which is the support of content that has already been created or is in the process of being created. So let's look at content entry first. When we think about content entry, really what we're doing is filling out HTML forms. And that's like one of the oldest features on the Internet. And a lot of people may kind of think that forms are very straightforward and the standards around them are pretty well known. And you're right, in some ways. However, there's a lot of differences between interacting with forms in a content management system and interacting with forms generally on the public web. For example, many forms, when you fill them out on the public web, are only meant to be filled out once and then you submit them and forget about them. But in a CMS, a content author may revisit a form hundreds or thousands of times over their career. Most web forms are standalone and designed to be as short as possible, but because of the complex content needs that come along with the modern web, CMS content entry forms can contain dozens of fields and many times the content is highly interrelated with each other which makes the forms more complicated. And general web forms are meant to work for anyone without any special training and that's difficult for us when we design content entry forms and we often need to offer training or documentation or other resources to help users along, hopefully. So while your content entry forms may seem like a simple implementation of known technology, there are a lot of elements that make this experience unique. So when I'm trying to design authoring forms, one of the things that I'm really trying to do is reduce cognitive load. And the cognitive load theory was developed by John Sweller in the late 1990s to describe the mental effort needed to learn new things. And the theory goes that individuals can only hold so much information in their brain at once and if you present more than they can hold, then their working memory becomes overloaded and learning becomes much more difficult. And this same concept can be applied to user experience to design to describe the mental effort needed to learn a product, like a CMS. The more cognitive load that is needed, the more difficult a product will be to understand and use and the less that people will carry over from session to session. And, you know, as we've already discussed, modern web content is very complex and therefore reducing cognitive load as much as possible is really crucial to designing a well-designed authoring experience. And cognitive load is not a flat scale either. The less familiar somebody is with something, the more cognitive load it adds to their work. So if your authors are web professionals who have been using content management systems for a long time, they're in a different starting place than somebody who is generally unfamiliar with web concepts and has received minimal training because if you've got that, now you're at a disadvantage from the get-go. They're going to have a higher cognitive load before they even get started and as a result, you're going to have to work even harder to improve their experience. And as I've said, since content authors are using your interface thousands of times, this load gets magnified accordingly. At the same time, we can't just reduce the cognitive load to the point where an authoring experience is so simplified that it doesn't meet the needs of your organization. CMS, that is nothing but a title field and a body text as we saw earlier, is very simple, but it's woefully unprepared for what the modern web requires. So the key is to build a system that's appropriate for your use case and make it as simple to use as possible. And there are some broad, as I've said, there's not hard and fast rules for how to do this. It's different for organizations, but there are some broad guidelines that I look at in order to approach these things. One is consistency. Consistency in your authoring experience is one of the single most important things you can do to reduce cognitive load. And this surface is in a lot of different areas of an authoring interface. When you make decisions about where things will be placed on a node edit form, you should make those decisions as consistently as possible throughout your platform. Taxonomy choices should generally be together in one place. If a field appears multiple times on multiple content types, it should be placed in the same general relative area to other fields. Display settings and metadata should not be put in the sidebar on one content type and in the bottom on another content type. Consistency in those factors will really help authors as they start to work with your system. You should also strive for consistency in the field widgets and paradigms for your system. For instance, we recently worked with a system that used three different layout technologies for different content types. And this lack of consistency created a lot of confusion for content authors who never really got the hang of any one of them sufficiently. There was a lot of technical reasons why those different technologies were used at different times, but left behind a lot of the people who were actually using the system and never got them to a place where they felt comfortable with it. And finally, you should be consistent in the terminology that you use throughout a system. Always refer to items on a form using the same words that you have across the rest of the system. And on that topic, let's talk a little bit more about the words. The words and text we write within the authoring system are a vital element in providing context and information to content authors. And unfortunately, on many projects, they're given pretty short thrift. How many people here are developers who have written their own help text? This is not ideal. I would raise my own hand too. In her book Designing UX, How to Create Forms that Don't Drive Your Users Crazy, Jessica Enders says that the core of any form interaction is the questions that are asked by the form and the answers that are given. And this is why the words we use in the form and not how it looks are the most important part of its design. The words on forms are everywhere. There's lots of words on forms. And there can be extremely valuable for helping your user navigate your interface as long as they're thoughtfully crafted. And as we've discussed, there's no one-size-fits-all rules about writing for content authors, but knowing your audience and writing for those needs is crucial. And here are some general principles around that. Keep it simple, right? Follow the guidelines for plain language. The less words you use and the clearer they are, the easier your conversations with authors will be. The more authors you have and the more diverse their jobs and experiences, the more the words you choose matter. Writing for a diverse group especially requires a laser focus on simplicity and clarity. That said, if all of your authors are well-versed in the jargon of your organization, then you should feel free to use it here if it helps you communicate with them. In state governments, you know, three-letter acronyms are the part and parcel of the way that they talk to each other. And we will use them in the admin interface because those are the words the authors use and understand. We wouldn't normally use that for web projects, like when we're writing for the front end, we tend to avoid that, but your audience here is different. But the flip side of that is that you should avoid the terminology of the CMS. We use words like node all the time because it's the words that make sense to us, but they don't make sense to the authors. They mean nothing to them. You should also avoid directional language, things like saying that something is above where you are or to the right of it. Relative placement can change over time, and updating the text to match is a lot of maintenance overhead. Also, different things may be in different places depending on context, like if you're on a mobile device or using a screen reader. In fact, all of these suggestions are really important for accessibility in general. And then possibly the most important thing, which is that saying what something is doesn't help as much as saying why it's important and how it impacts the content that's being created. Again, the less knowledgeable your users are with web concepts, the more this is probably important. Why does this field need to be filled in? What happens if it doesn't? How will your content look if you do certain things? What impact will it have on your site's users? These are all super important questions to answer, and it's very common for them to be skipped. I think another thing that tends to get a lot, not a lot of attention, is the ordering of information on a form. So during the design phase of a project, we create pages with a hierarchy of content. The most important information goes at the top of the page and then the next and the next and so on until you get to the bottom. And a lot of thought goes into this hierarchy. And so it makes sense that when authors are entering this content, they should enter it in the same order that it appears on the page. And it is amazing how often nobody thinks about the order of fields on a node edit form. So when authors are entering content into a system, they're often visualizing what it will look like as much as they're crafting words. And this is especially true for, again, people who are not experienced content authors. And so it only makes sense that we should lay this stuff out in the order that they expect. It's more intuitive and it allows them to focus on their tasks at hand rather than scrolling around trying to find where their next field is. Another aspect, though, to consider in ordering fields is how often a field gets used. So, for instance, in the example here, we can see that this featured image is the first thing on a page. However, we've made it the fourth thing in the node edit field and the reason was because when we did our user research and our content research, we were realizing that for this content type, they only used the image about 5% of the time. And so while it needed to be present and it is at the top of the page, most content authors would be scrolling past it to get to other things in the most common use case. So we made the decision to move it lower. And this is the kind of thing that like research and looking into your actual content and what your users are doing can really help with determining when to follow certain rules like things should be in the right order or when to say, we can move this down because it's not being used as much. At Lullabot, we create a spreadsheet for every project that outlines all of the content types and their fields and their properties. When we create this spreadsheet, we always lay it out so that the fields are described in the order we expect them to be on the node edit form. And that way, the developers have this guide when they're implementing these forms and putting them together. So, you know, consistency, the words you use and the order in which you put things are just three general broad considerations for content entry forms. And there is so much more we could get into on this topic. We could talk about error handling as a gigantic topic for this. Field validation, connected content. But this just gives you some broad guidelines that you can start to look at and think about when you're putting together your backend experience. So, where content entry describes the actual entering of the content, content administration describes how we deal with it once it's been entered. What content type should I choose? What is the workflow? How do people find and manage the content that they need? So, for most people, their authoring experience really starts the moment they log into the form, into the CMS. And a common feature of CMS is to put a list of recent content on this page with search options. That's fine, but something more customized can really give authors a personalized experience that sets the tone for their session. So, on one recent project for the American Booksellers Association we created a platform for bookstores to manage their online presence and e-commerce. And so, in addition to the standard list of content, this provides custom links to look at things like new orders and orders in process and orders with payments pending and other tasks that these authors are looking at on a regular basis. These custom landing pages can provide authors with an overview of their work in progress in addition to other information they might find useful. Now, again, what's appropriate for these things is different from organization to organization even between the roles in a specific organization, but here are some common things that you might want to think about. Work in progress. That's the work that you're currently working on or have recently worked on. This is probably the most common type of thing to have. Work that other people have worked on but which you have to review. In many organizations there are people who don't actually write content but have to review it for accuracy or style. And this is a great example of where one role might need information about what they're working on but another role might need information about what they're working on which is different in concept because they're not writing content, they're reviewing content and sending it back to people. We'll also often put things like alerts from SiteImprove or Google Search Console where we can highlight accessibility or SEO issues and surface them to the dashboard with URLs and tips and tricks on how to fix them and easy links to documentation and support. So thinking about your users and what they're doing on a day-to-day basis and what they might need when they log into the system can really help you put these kinds of dashboards together. Another thing is choosing a content type. Now, creating a new piece of content will often be the first thing that somebody wants to do when they log in and it's one of the most important choices that they'll make. Content types are designed to serve a business purpose but many content authors will often choose the wrong one for the content they're creating. This might be out of habit or because they don't understand the differences or because one content type is more flexible and they'd rather use that one but guiding users to choose the proper content type is a crucial and often overlooked part of the authoring experiences. Some of these choices are pretty straightforward. For instance, nobody's going to choose to create an event when they could create a blog post although I've actually seen plenty of places where they'll do the opposite but some examples are more subtle. For instance here, what's the difference between news and press release? So one of the things to focus on here again is the words. These descriptions don't really describe the difference between the two content types well. They talk about what they are but not why you might choose one or the other and clarification of the why of a content type that's used can guide authors towards making better decisions and thus creating better content. Think about the research that you've done. What are the use cases your authors have? What do they encounter in their day-to-day and how can they use that information to provide better descriptions that match their expectations? Another problem is that one short description doesn't give a lot of room to provide all of the context around the content type. So here's the same content type with some different information so there's a lot more here and it serves to provide better context for content authors. In addition to the short description there's an opportunity for extended information which can provide more context. In the case of news it clarifies where the postings will be used on a site as well as stating what it's not appropriate for. In the case of press release it clarifies where to go to check if the use case is appropriate as well as the additional information that images can't be used. So if you want to use then this provides more context to your authors because again, authors often think of their content not in terms of its use case but how it's going to look after it's created. There's also a thumbnail of how the page might look when it's done which helps ground them in something they can visualize. And then finally we have a link to provide two other content of this type that allows authors to check and see examples of how this content type may have been used which allows authors to easily learn from what other people have done. But that brings up another point the needs of new users are often different than the needs of seasoned users who have been around for a while and when we were testing this with the client's authors a common complaint was that the extended descriptions and imagery take up a lot of real estate and that means more scrolling to get to the content types that you might need after you've been using the system and users who have been around for a while probably have a better handle of what use cases are and when to use what content type so a lot of that information becomes redundant over time so we ended up adding a toggle to put this listing into a grid view which optimizes real estate and is better for experienced users. And this is another example of another context that is important to think about because people who have been using your CMS for a year have very, very different ideas and use cases than the people who are brand new to it. And the module that we used to do this was called TypeTray it was done for we did it for the state of Georgia many of our constituents are here it was largely designed by Jared Ponchot who is sitting over there and our design team at Lullabot and it's been released on Drupal.org and you can use it on whatever project you might like and a link is also in the resources in the in the I have that slide in there twice too this is all very confusing so that's content entry and content administration as broad ideas and the kinds of things you can think about when you're designing your authoring experiences and before we wrap up I want to talk about one last thing which is designing for accessibility because just as you want to design your end user experience to be accessible to users of your website for the users of your content authoring tools people with cognitive and physical disabilities are going to be entered content into your backends as well I think many of us are familiar with WCAG or the Web Content Accessibility Guidelines and there's actually a whole other set of standards called the Authoring Tool Accessibility Guidelines or ATAG and it's difficult to get into this topic in any real depth but the ATAG describes two broad areas of concern when it comes to authoring tools first the interface for the authoring tool itself must be accessible if you have status indicators like grammars and spelling markers they have to be accessible to those using assistive technologies the interface should respect any OS level settings around accessibility that the user is set like if they set it to dark mode for instance and any preview in the tool should be accessible as the content when the page is properly rendered in the front end and we've seen, I've seen a lot of live preview tools showing up around Drupal in the last year or so and this is a really important thing to keep in mind when you're evaluating those tools and then secondly the tool has to provide everything the author needs to actually create accessible content and this is the part more that when you're creating authoring experiences that we need to keep in mind does your tool create accessible markup in its templates are editors given guidance to create accessible content for instance given the ability to add alt text to imagery is there a way for authors to perform their own accessibility checks on that content and are they given the tools to fix them when problems are found and does the documentation for the system properly promote and encourage accessibility in the description of the functionality of your system now Drupal's default back end is pretty good when it comes to ATAG compatibility but most of the problems come when people try to customize that back end or create their own tools and that's where getting into learning about these these conformances is really important and while Drupal 10 and 9 are very good when it comes to ATAG compatibility there's a lot more work to do and if you're interested in getting into that work I've linked the tracking issue for ATAG 2.0 conformance at the end of this talk or is Mike Giffer here you can talk to that guy about it too he kind of runs the accessibility stuff for Drupal so I realize that this is it seems like just a little drop in the bucket when we're talking about authoring experiences but again here are some broad guidelines of the kinds of things to think about and I think the really important thing is just like prioritizing this in your web development process and in your web development systems taking the needs of your content authors into account and making them stakeholders in your project and listening to their needs and prioritizing them alongside all of your other needs because there's nothing more important than in making good content for your systems than making sure that your authors actually want to create good content for your systems as I mentioned at the beginning this is only the small part of a much larger process of a book that I'm writing I'm currently in the midst of edits on this book but I have a publisher and we're expecting to release it in the early part of next year if you wish to follow me in any of these places for updates feel free although I don't think I'm going to be on twitter much longer but at least if you follow me there you can hear where I've moved to and that's it I'll be happy to take any questions here yes so that's a the question is there from somebody who has a source code button that allows them to mess up their content a great deal can that be hidden for different roles and the answer is profoundly yes and I would highly, highly recommend that you do that in fact I don't even leave it on for admins because the problem that comes and we see this especially on large platforms of sites is that if you leave it on for admins then people just start turning everybody into admins and or sometimes the admins are the worst offenders in this process and so what we do is we design very tightly controlled design systems and we turn the source code button off and we do not turn it back on again and so I think that is a key thing that you should start to work on in your organization yep the question is is there any kind of survey where we have figured out what the most common pain points are in Drupal and what the best solutions are for them I know that some of that work has been done over the years but I'm not sure where it lives I would ask is Christina here who is also here who is just named Drupal core product manager congratulations Lori and they're working on a lot of stuff around the Drupal user experience and backend user experience and may have more information I will say though that when it comes to like what tools are best or not best for different situations that like one of the things and we struggled with this at Lollabot a lot is that we've spent a lot of time trying to figure out how to standardize on one of the tools like paragraphs versus layout builder and the truth is that they're both good tools they're different tools though and the differences are good for some clients and not good for some clients and that's a great example of a situation where we have spent a lot of time over the years talking about this topic and have never gotten anywhere because it's just there's just no best tool and that's just a great example of how hard it is to solve these problems in Drupal because Drupal doesn't have this is a little I'm going to go on a little bit of a rant here but Drupal doesn't have an audience like if you ask Dries who Drupal is for he'll say anyone who wants a website and as a result of that it's very very difficult to design Drupal for any use case because Drupal isn't for anyone basically and so that's one of the reasons why I don't think of this as a Drupal problem I think of it as a build problem because unless Drupal gets to a point where it identifies an audience and a product that that audience is trying to serve we can't solve problems in Drupal all that we can do is solve problems for ourselves using Drupal yes yeah well I'll say that we've never really done a design system for the authoring experience as much as we've just sort of set guidelines and analyze things on a case by case basis and the fact is that as a client services company we also can only ever spend as much attention on that as our clients will allow us to and so it's one of the things that we kind of when we're in the use case when we were working with the state of Georgia they were extremely focused on making sure that their content authors were well served but not all clients are the same way and so a lot of times we can't put the level of depth and attention into that as we always want to but what we have been able to do is develop tools like type tray or like the spreadsheets that we build or the ways that we develop products which work content authoring into our workflow sort of standard practice and then it becomes not a lot of extra effort for me to order things in the right way it just becomes part of what we do and from our perspective I think that's really the focus is that if we work it into our tools and our processes and the way that we work then we can deliver things to clients that move the needle in a better direction even if the client themselves aren't prioritizing it yes in the back there so the question is about the use of directional language and about clients who may want to have some control over where things are and how they're referred to I think that the argument well it's interesting because when I talk about directional language I'm talking about like for instance if we're in a node edit form and I say I'm blanking like if I say something similar to the field that you'll find above and so usually in those node edit forms that's not something that any of the clients have any access to change right and so that's the kind of thing where I'm talking about I would instead of saying the field above I would refer to the field by name as an example because those contexts can change over time or if you're on a mobile device or whatever and removing directional language from interfaces and text is actually one of the key points in accessibility in writing accessible text because people who are using screen readers don't have that context of above and below a lot of the times and so what I would just do is to encourage you and your client to figure out different ways to think about that and to refer to things more specifically because that is something that you know is just one of the key tenets to creating accessible content that I skipped did I miss anything there cat that's interesting apparently you can also use words like before and after instead of above and below interesting I hadn't known about that cat is our accessibility one of our accessibility experts at lullabot yes right here I mean to me the key is that like if you if you prioritize the content entry side then you're going to get better content like there's no there's no doubt about it because because people don't use systems that don't work for them and you know you may say well we'll tell them to use the system and then they'll do it and they're right but you won't get the level of quality that people get out of it and because you know we have plenty of systems that are very badly designed and when people have to log into them they will fill out the minimal amount possible copy and paste stuff in there and get the hell out of there because they don't want to deal with everything they have to deal with to upload an image or a document or to fill out these 80 fields and then have to jump over here and fill out these 80 fields and come back and stuff like that you know and so it's just it's just that I mean aside from the fact that we shouldn't be designing systems that make people miserable as like a concept you know as an ethical platform that we stand on but aside from that it's just it just makes good business sense because you'll get better content out of it you'll get content that is created with more care and you'll get people who aren't miserable at their jobs and apparently adding Claro as your admin theme will assist in making it more accessible as well what time does the next talk start do I have time I don't know when I'm supposed to cut things off I'll take one more right back there you yeah that starts to get I mean we haven't done anything on the note edit page itself and but when I think about that let me give that some thought I think that there could be a use case for sort of advanced uses of things where you may want to well I'm sorry I'm just like tossing things around in my head I'm thinking about I'm thinking about things where it's like it's not beginner versus experienced it's more simple versus advanced right so for instance there may be users or use cases where you don't want them to have access to for instance override meta tags as an example and remove that very complicated form from the interface because it clutters things up and is overwhelming or to be able to rewrite URLs is another one that like you know is sitting there that like nobody understands or to add menu links and a lot of times like a lot of those things will be sitting over there on the right and you open them up and you can't even do anything with them they're just there because they're there in the interface and I would just remove that stuff like again the more stuff that's there that you can't do anything with it's just like why right and so I think of it more in that way of more like what's a simple use cases first it's an advanced use case and it may also be you know a similar thing where it's like you don't want a new user to have access to that stuff but as they get more experience they could have access to it and but it's hard because I'm a Drupal person and I tie that to roles and then I just dive down the role problem and so it's like but that could be a good example and a lot of this stuff around like metadata that you see on like the side or at the bottom of a lot of Drupal node edit forms like 90% of users aren't using that stuff all the time it's just there for more advanced use cases so I think that's a lot of stuff that we could strip out one other thing and I didn't put it in here that I will often do is I'll also make sure there's a button in CK editor that allows you to blow the CK editor up to the full screen and it's not it's not enabled by default on Drupal I think and I always turn it on because it's like we have content editors especially when we're doing things with like entity embed and stuff like that where it's like there's so much in that form and it's this big and a lot of times like the little corner to drag it out is gone or the sidebar is there so you can't drag it out any further and stuff like that so that's just a little thing that I thought of I don't know more thanks everybody if you want to talk about this more I'll be at the Lullabot booth for a couple hours after this so thanks for coming