 All right, we're going to get started. Hi, everyone. My name is Eileen Webb. I am the Director of Strategy and Livestock at Webb Meadow. We are located on a small farm in northern New Hampshire. My title is not facetious. And I am a content strategist and a consultant and sort of a digital strategist and a recovering back-end Drupal developer. I wanted to start today by taking a moment to acknowledge where we are in the city currently known as Nashville. This is the traditional ancestral territories of the Chickasaw, the Cherokee, the Shawnee, the Creek, and the Choctaw peoples. We are guests here. Today, I want to talk about improving your user experience. And not for the people who are visiting your site, but for the people who are actually building your site. And so I'm going to start by telling a story. And you just sort of nod along when it starts to sound familiar. It goes something like this. You launch a new site, or maybe you launch like a new section of your site, and everything on launch day looks great. And the article titles are just the right length. And the events in the calendars have all the relevant information. Teasers are teasing. Birds are singing. Everything's pretty darn good. And then three weeks pass. And you click over to a page, and you see something that looks like this. Or maybe you've designed a hero image that looks like this. And someone has created a new one that looks like this. Or maybe you open up your site on a phone, or you look at the information that's being fed through the API, and you see stuff like this. And the question rolling through your mind at a sort of fundamental level is, why are you breaking my site? I worked hard to make this site elegant, and performant, and responsive. And you authors, you site admins, you get in your grubby little paws all over it. So why is that? What is so hard about this? So when it's time for someone to create a new post, or to update an image on the home page, let's look at what they're dealing with. Oh, OK, wait, sorry. That can't be right. No one here works on a site that makes any of their authors ever touch code, right? We wouldn't do that to them. Certainly not code that looks like this. Oh, yeah. OK, good. That's much better. This is going to be way easier for people to use. I definitely, my favorite part about putting new content on a website is the time travel back to 1996. But Eileen, you say, my authors do not have to work in HTML. We have a CMS. OK, so when the first CMSes came along, this here, this was snazzy. I mean, look at this. There's fields. There are radio buttons. Look at all the formatting choices in the editor. There's bold. There's underlying. There's font family, which you absolutely want people choosing willy-nilly on a per page basis. There's binoculars for birdwatching. There's a purple horseshoe. You're set, man. Like, look at all this stuff your authors can do. This is great. Eileen, you say, this is a Drupal conference. And also, Joomla 1.5 came out in 2006. We're not using that. Our modern CMS experience is much nicer than this. OK, let's see here. Here's a current version of WordPress. Looks super different. I noticed that we have lost the binoculars for birdwatching, but we still have the purple horseshoe here. It was nice. Here's Site Core. Here's Adobe Experience Manager. I apologize for whatever is happening in this sidebar here. Here's Expression Engine, starting to look a little cleaner, a little slicker. OK, look, here's a current Drupal screenshot. All right, wow. Super unique, really different than all the other ones. Hell, seriously. Like, on the front end, we've gone all the way from web 2.0 shiny bubble buttons. Remember that time? That was a good one, right? Through skeo-morphism, chalk on chalkboards, photorealistic, all the way into super flat digital native design. And on the back end, we've advanced to a slightly cooler icon set in the WYSIWYG. Here's my thought. I think that these two things are connected. I think that authors do a crappy job with this kind of thing because we, as the developers and builders of a site, are doing a really crappy job with this. We talk about user-centered design, but the people on the back end use the site more than any visitor ever does. And how many testing sessions do we do with them? And how many design iterations and sprints are dedicated to improving this monstrosity? So I want to talk today about improving the authoring experience. So this is the experience for the people who are actually authoring content on a site. It's a huge topic. I'm going to cover just one narrow slice of it today, which is about writing content guidelines. So any sort of content creation that happens on your site, blog posts, event listings, service offerings, product pages, whatever it is, every piece of content has its own set of requirements. You've got ideal format, you've got length, underlying message, intended audience, keywords for SEO, all kinds of things. It's a lot to remember. And in fact, it's actually too much for a single human being to remember. And so content guidelines are the way that we attach reminders and help text to each field, to each section, to each content type so that authors can do their jobs well. And so if we're going to write content guidelines, it's important that we understand who's going to use them. And so when I talk about building guidelines for authors, who am I talking about? So perhaps you work at a big organization and you have a dedicated web team and there are people, writers usually, whose job is specifically full time creating and managing content. Those people are authors. Or maybe you work at an organization that doesn't have a dedicated web team and people from all over deal with content on the site. Maybe you've got a number of different departments and each department manages their own content, which means that it's really only one small part of their jobs. Maybe one day every few weeks is web day for them. Those people, those occasional site managers, those are authors. If you work with a site that has a community contributing content, whether it is an internal community of like interns and volunteers or you are managing an external community that connects people out in the world, those people have never had any training in how to use your site. And what's more, they're never going to get training because that's not the kind of relationship they have with you. But the site doesn't work well unless everyone follows the same rules. And so those people are also authors. And then there's you, maybe you are an author. This one is sometimes the hardest sell because you're like, why would I bother documenting the work that I literally do all day every day? Two reasons. One is that you might go out hiking and get eaten by a bear, who can say. And then no one will know how to do your job. Two is that you're not really doing it for like now you or even for tomorrow you. You're doing this for like Friday afternoon, three months from now, coming down with a cold you who just needs to update the press release page. We don't remember what size image you're supposed to go with the press release because you don't do it very often and you would just really like to go home and take a nap. You're doing it for that version of you. So the label author covers a lot of people all the way from full-time people all the way down to sort of casual occasional editors. And it's pretty obvious why casual people and sort of occasional users can use extra reminders and help. But even professional writers get distracted and they have bad days and they're working on four different projects at once. So everyone benefits from having a well-written help text. So the first step to building good content guidelines is to figure out a little bit about how to structure your content which means you need to build a content model. If you work in Drupal regularly this is probably like a pretty normal part of your process. What is a content model? What is structured content? There's like a four and a half hours I could talk about this just right now but I'll give you like a few sentences. A content model is a breakdown of all of your content types and relationships on your site. And notice that I didn't say all the content on your site but all of the content types. So we're not really looking at what it is that we are saying. We're looking at the patterns in the way that we say it. So structured content is when you look at a bunch of different pieces of content and you break them down into their component parts. If you work in design systems this will start to sound like some of the similar language. It's essentially the language and information version of a design system. An easy example here is a recipe and in fact I am federally mandated. I am not allowed to talk about structured content without using recipes as an example. So if you look at a bunch of recipes you'll start to see some patterns. So this is a recipe for fresh ginger cake. It's delicious. This is a real recipe that I use on a regular basis. If you look at a number of recipes in a row you start to see patterns, right? You see the name of the cake. You see a little description of it. There is an author up there up in the corners is by David Liebowitz. The original publication in Epicurious. As you start to scroll down you see like the yield. This cake serves 10 to 12. Questionable. Like maybe six to eight especially if you want leftovers for breakfast. And then we start to see an ingredient list, right? And you scroll down and there's like a bunch of ingredients that follow a relatively normal pattern. Then we get to the instructions. Instructions actually have patterns within them as well. Baking recipes usually ask you to preheat the oven. Usually calls for using a certain pan size. At the end there's often a finishing touch or a garnish around serving time. This is an important thing to notice because often we get to the point where we see sentences and we just sort of our eyes glaze over and we're like done, block of text. But just because something is written out in long form doesn't mean that you stop looking for patterns. So don't stop at words, look for patterns in the information and see if there's repeating patterns across your content. And then we have metadata. And so metadata is the sort of shorthand I use is that it's information about the content rather than information that is in the content. And so for recipes, your metadata might be things like categories like whether it's breakfast, lunch, or dinner, what the cuisine is from, whether it's beginner or an expert level recipe. This has tags on the bottom. That's a common way to represent some metadata. You'll notice that this cake is both good for fall and Mother's Day. It's a year round ginger cake, which I really appreciate. So figuring out your content model is a matter of looking across all of your content or at least a good sort of sample chunk of your content and teasing out some of the repeating patterns. Okay, Eileen, this sounds like a lot of work. Let's be honest. Why are we bothering? Why are we bothering to build a content model? So content models help you create really consistent content because if you show someone a blank box like this and you say, okay, put the recipe in here or like put all the event information in here, good luck having two people do it the same in two different departments, good luck having one person do it the same on two different days or even twice in a row. Whereas if you give someone something like this where there's a form and there's a field and each field asks for a separate piece of information and each field has its own reminder for what kind of information needs to be captured, what voice or tone or format each field should take. Now we're starting to actually get some more where we can get consistency. Writing content guidelines for a big giant white box like this is almost impossible. But writing a bunch of little guidelines broken down that's a much more reasonable thing for you to tackle and for your users to absorb. Okay, so let's write some help text. Yay, help text. When it comes to help text, we have to find sort of a middle point because you have to provide enough information that the authors know what is needed, right? Like just a label isn't gonna cut it. But you also can't give them three paragraphs of guidelines on like a single text field because they're just gonna skim right past it without reading. So there's a balance to be sought here and the thing to prioritize in the balance is what is actually helpful and useful for your team in particular. And this is very much like it's gonna be different for every person in the room. The last time I gave this talk, someone was like, okay, so how do you figure out which pieces to put in? And I was like, well, I mean, one thing is that it changes over time, right? Your team will grow and learn to understand things and then they'll sort of need different help as things happen. And I would like to be all sort of like high level and philosophical and give you some like beautiful guidelines about like, you know, maintaining tone and consistency and your marketing copy or whatever. I have definitely written sites where the help text is, don't you dare put the words click here in this box. Because that's what they needed to hear. And they needed to hear it for a while until they broke themselves with the habit and then we were able to use that help text to say something a little more interesting. But that's a legitimate use of help text is to remind people to like not do things that are gross in the UX. So I'm gonna talk about a bunch of categories of information that you may want to cover in your help text. So the very first thing is names. Names give context, right? Like what is this? Are we talking about a recipe or a biography or what? In Drupal it's really easy to put a description for the content type as a whole. So on the top of like a new node form or like when you're editing a node there'll be like a little paragraph of information at the top that can tell you what the content type is for. So like, especially if you're moving from a system where you used to just sort of put everything in like a basic page type of format and now you're separating out news versus press releases versus events, give people the information they need to figure out whether something belongs in content type A or content type B. Like does this information belong under events? Does it belong under lectures? Like what is this content type even for? Give people that information because you can't really depend on them especially as like turnover happens and teams grow. You can't depend on everyone having been in your meetings and just sort of knowing that institutional knowledge. So document that, put it in the content type description field. I always encourage people to replace generic field names. I never want to see title and body on a page. Even when they feel redundant calling it something like event name and renaming body to event description. Just helps orient the author. It helps remind them which content belongs where and what it is they're doing on that page. So editorial is sort of information about like what we're saying and how we are going to say it. So there's a lot of things that fit under editorial. So voice and tone, if you have a voice and tone guidelines in your organization, which not everyone does and that's fine, but if you have them and you have like words that you want to use in particular, reminders to use those words, any kind of underlying messages or things like be sure to mention our environmental initiatives in any of the things that talk about our Charlottesville programs. Intended audience, this is especially helpful if you're dealing with subject matter experts who write like academic nerds and you would like them to write things that normal humans can read. Grammar reminders, this can be like almost like a format thing like this should be in the form of a question or like make this a list of three bullets. An information that should or should not be included. So this is something that's especially helpful if you're moving from a less structured system to a new restructured system. People will often write things in the body like in the description of event like join us on July 3rd and you can sort of remind people like the date has its own place to live here. Like it's gonna be like highlighted in the design. Don't put the date in the description field. Same thing with like, oh goodness, sorry. I just touched a cable and I shouldn't have done that. Same thing with things like people mentioning who the actual speaker at an event is. It's like if that has its own field you don't need to duplicate that information here. This is a really good place and also in the description of the content type these are really good places where you can link to a style guide or a mission statement or like sort of supporting information on your internet or in your sort of Z drive or wherever that stuff lives. So next we have format. Where editorial was, what is it that we are saying? This is more like sort of how is it shaped? So we've got things like field length, data format so like do you want something in inches? Do you want it in centimeters? Like if you have a product catalog or when we say weight, what does that mean? If a field uses HTML, tell people which tags are accepted. I worked with a client who had a field, they had a form essentially where like regional offices could fill out some information and put it in and they could style it like, like wacky styling. They chose the font family and they could make it pink and sparkly and underlined. And then when they submitted it, like stripped everything but peas which was good and appropriate but they didn't tell people that and so they got all kinds of upset information from people saying like, I tried to put in bullet lists and links and they all got stripped. So if you're gonna strip stuff like let people know what they're allowed to use. And for things like check boxes and select lists how many selections are allowed? So these things it's really easy to say like well we should just validate this with JavaScript. Like this is all stuff that could be programmed. And some of them can be programmed but most content in the real world has exceptions. Like maybe for the most part things should be in one category but some things legitimately need to be in two categories. So you can't limit it to be a single category or maybe like field length to like be between 40 and 60 for the ideal design setup but if it ends up being 35 or 61 that's okay too and those kinds of things are really really obviously hard to validate through hardcore programming through like actual strict rules because they're not strict you have all these exceptions. So you could write the JavaScript to validate something very complex or you could write like a single human sentence and tell people like in these situations pick three categories in these other situations pick a single category. So under images we've got image file format and this is again something that like in Drupal the default you know tells you like which the allowed things are like things JPEGs, et cetera. Depending on how expert your authors are working with images they might need a little more information than that. They might need to know like they need to go export something from Photoshop and use the save to web file or whatever the process is. Things like image shape and size if you've got a particular, if you want people to upload something that has the particular aspect ratio you should tell them because otherwise it's gonna get auto cropped and it will always look terrible. Where and how the image will be used is a really helpful thing to tell people like is this gonna be shrunk down to a thumbnail and put in a grid or is this gonna be like the huge background header of a page and because we're using structured content and reusing things all the time in Drupal often a single image will be used in a bunch of places and most people unless they actually built the site themselves are not gonna remember all of the places off the top of their head and so they might always think of this as like oh I'm putting this in as the header image and you're like oh it's also used in three other places and we need to make sure we pick an image that works for all of those places. Similarly for art direction you know is this supposed to be a landscape photo of like a big expansive landscape? Shouldn't it be a macro photo of food? If there are people are they looking directly at the camera are we breaking the fourth wall? Like is it supposed to be an action shot? These are the kinds of things that actually like help set the mood of your design right and the reason designers take such a long time picking perfect photos whether it's stock photos or like doing photo shoots with your teams and with your products and things. The reason that those are so carefully crafted is because they do such a huge job they carry a really huge burden on the site the right photos and so if you're gonna give people the ability to change photos make sure you don't also sort of give people the ability to kind of muck with the entire intent and mood of the site. And then we've got display. So where does this content go? And again this is something that's really prevalent in Drupal because of the reuse and because we do like this some particular field might show up in four different views right? It might show up in a sidebar it might show up in a footer and it might show up in teaser format and there are all kinds of ways that stuff is gonna be used that is not necessarily obvious when you're just looking at the node edit field on the other side of the generic node template. A thing that's very helpful is to remind people if this field is gonna control where content will be displayed like for example this putting something in a particular category I mean it's gonna be pulled over to certain calendars or to different areas of the site. Will the contents of this field be displayed alongside other information? So if you have like a teaser field and a full description field do you stack those in the full view? And so if you said the same thing in both of them that would be very like duplicative and weird or is it sort of one or the other? And so they can be duplicative and that's not gonna be an odd experience. And also like what are categories and tags actually used for? Those are words that like we sort of we know what they mean right? We know what taxonomy means but what does it mean on your site? What does it mean in this case? Is it about browsing? Is it about filtering down a list of results? Are you grabbing sort of related? You might also likes? Are they only used internally? That's something that we have often fields that we're tracking something internally but it doesn't do anything on the public side of the site. And people need to know that so that they sort of know how it is they should be filling in the information in this field. Okay so that's a ton of information that you might gather. There's a lot of bullet points on those slides. Where do you start to get this information? Like who should actually be involved in creating these content guidelines? Where does this stuff live in currently? So when we talk about who you should talk to to start building content guidelines. Designers, very good people to talk to. Designers often have a piece of a design that they are very protective of where they're like look this section over here it is not gonna look good if this title gets too long it needs an image that has like a bright blue color on the left side in order to balance the rest of the page. So talk to your designers when they are working through the visual presentation for your pages and see if there are things that they are concerned that other people are not gonna be able to sort of keep up to the quality that they really want. Similarly the developers who are building out the actual features on the site. I know that when I am building sites I often get to a point where I'm like does anyone besides me actually understand how the categories make things show up in the related sidebar? No, no I'm the only person who understands. Okay cool. The answer is that you're always the only person who understands if you're the developer doing that. You're the only person who has wrapped your head entirely around that project because other people blessedly do not have to. And so it's really important to capture the essence of that into your content guidelines so that later on when you win the lottery and you're not there anymore people will still be able to look at that field and be like oh this controls the way things show up in the related sidebar, perfect. Marketing of course, marketing has a lot to say about everything often but especially the editorial aspects of the content, right? Branding messages, keywords and phrases if you have SEO specific people or even just people who are sort of SEO oriented. All that kind of stuff like you wanna make sure that you have gathered any requirements for them and that you capture them in the content guidelines. The content team if you have one might only be a single person content team which is fine. The content team often has a lot of information tied up in generic job knowledge. This is something I encounter a lot with writers who think of themselves primarily as writers and they sort of work in a CMS because that's how you do writing nowadays and they have this huge amount of institutional knowledge that they kind of don't even recognize as being important. They don't even really realize how much they know. The best look I have getting information out of content teams is actually shadowing them just like sitting with them for a couple hours at their desks and watching them do work and having them sort of narrate their tasks to me. So they'll be filling something out on the CMS and they'll be filling in some field and then they'll zip over to some other screen and copy something and I'll be like, wait, what was that? And they're like, oh, I just copied the part number from the manufacturer spreadsheet that they sent me and then I put it in over here. And I'm like, what? And they're like, yeah, the manufacturer spreadsheet on the Z drive. I'm like, you didn't, I don't even know you had a Z drive. Like, spoiler alert, everyone has a Z drive. And so you're furiously scribbling down. You're like, part number is Z drive. But that's the kind of thing that like, it's so second nature to them. Like it's literally their job just to like do that and sort of have all of that knowledge. They kind of, they would not remember to like write it down in a sheet necessarily. So it can be really helpful to just sit with them and watch them do their work and that can give you a lot of tips on how you could make their work better and easier. If you are lucky enough to work in an organization that has a legitimate QA department or a customer service department, those are great sources of information about habitual issues. We tend to know about really big issues, right? About things that were like, this is clearly broken. That's sort of wide knowledge. But often people like, especially in customer service, they'll be like, oh yeah, we get calls all the time about people asking for shipping weight because that's actually only on half of our product listings. And like, it's their job to just answer that for people and so they don't necessarily think to like let you know that the website should have shipping weights for all of the products. So talking to these people because their job is basically to deal with broken stuff all the time, see if there are broken things that you can fix for them. So as you're gathering these guidelines, the big most important thing is to actually build the guidelines collaboratively with the people who are going to use them. If you take nothing else away from this talk, take that you should not build things by yourself. That if you're creating a tool for someone else to use, you need to build it with them and not for them. See if you can avoid sort of the big reveal, right? Where you build something and you build it all completely kind of in silence and in secret and then you unveil it and you're like, ta-da, I hope you're happy with this because it feels very terrible when you've built something that doesn't actually match their needs and they're like, oh, thanks, that's great, I guess. If it's not really what they needed, then you just wasted a whole bunch of your time and you built these beautiful content guidelines and they're like, mm, shrug. To be clear, if this is not already a piece of your workplace culture to share things and sort of get feedback when stuff is in a draft format and to sort of work together through messy stuff publicly, it can be really scary, right? Putting something out there that you know isn't polished can be very terrifying. You're like, I don't want you to think that I think that this is any good yet. It's not good yet, but maybe we could work on it together. It's scary and it feels very vulnerable and yucky, but the ability to adapt and adjust something as you are building it is really worth it. So know that if you have that fear in you of sharing something that's kind of gross and ugly, that that is a real fair. It is a valid fear. It is not trivial. It is not silly, but it may be holding you back from doing some of your best work. Okay, so yay, we all love and understand the value of good content guidelines now. Good job, everyone. So you're gonna go back to work next week. You're gonna spend a bunch of time gathering up some information. You can get all these different sources. You're gonna have some meetings. You're gonna feel like you have a really solid start. So how do you get those guidelines from your notes into your author's brains? Maybe you're like, yes, of course I lean content guidelines. We already write those. We put those in a PDF training document. Look, I get it. PDFs are easy, right? You have tons of formatting control. You can just build them on your own. You don't need any development resources to build a PDF. It's great. Save as, right? Okay, here's the thing about PDF. No one reads them, which kind of belies the whole point. I don't know if any of you are knitters out here. I'm a knitter. Yeah. I am. Yeah. Nowadays, you buy knitting patterns as PDFs online, right? You download the PDF, and it's all these knitting charts and tables and whatever. I occasionally, so I buy these patterns, and I download them, I keep them in a folder on my desktop, whatever. I occasionally will get an update to a pattern. Someone will send, some author of a pattern will send an update, and they're like, here's a new version of this particular sweater. There were three sleeves in the medium version the first time. If I've already made the sweater, and I made the size small, and it didn't have three sleeves, or I just haven't gotten to it yet, I don't download the new version because I'm lazy and a normal human being, and so I don't maintain my own perfect library of knitting patterns. I just sort of download the ones when I buy them, which means that at some point I'm gonna make a three-sleeved sweater. But this is actually, it's a pretty normal behavior. People don't go searching for the newest versions of PDFs before they start things. They're like, oh, I got this one right here. Great, perfect. So you get multiple versions floating around. You get weird sweaters. So PDFs are really like, they're not a great way to deliver information. Even setting aside all of the accessibility considerations, like all of the things that are not great about PDFs. So I have a radical idea. I think that if the content is being entered on a CMS form, the content guidelines should live on that CMS form. It's crazy, but I think it could work. Okay, so we all have an appliance in our houses that has a button. Do you have no idea what the button does? I have a microwave that has a button that has a cursive cue and the number three on it. I don't know. I don't know what it does. I'm not gonna press it. It's not safe. I could look it up, I guess, but the manual lives in the manual drawer, right? Which is like in a different part of the house than where the microwave is. So you don't know what the cursive cue three is. It just sits in the middle and takes out the base. So when your authors are writing, if the manual is somewhere else, right, in the proverbial manual drawer of the Z drive, they're not gonna go find it. The chances are really low that they're not gonna go open it. And like, I get that this is frustrating because I feel like if we spend the work to create content guidelines, those authors should throw us a party. They should print out those guidelines. They should laminate a set and keep like a wallet version just in case they need to edit on their phone, but they don't do that. No one has ever actually chosen to seek out content guidelines in the history of the world. And so putting them in the CMS actually puts the information right where it's needed right next to the field that they are filling out. One of the other pros here is that because the instructions are right next to the fields, it means you can organize the fields in whatever way makes content creation easiest, right? One of the great things about Drupal is that you don't have to have the back end and the front end organized the same way at all, right? You can, in your templates, you can spit out the information in whatever order makes sense for your front end display, but the editing screen can have its own entire set of ordering and information and sort of UX treatment. So maybe you wanna group similar fields together. Maybe you have like a short description and a long description that you put in a field group together. Or maybe you have fields grouped together on like how they're gonna be displayed. So maybe you put like all of the fields that show up in the teaser in the same section. Or maybe you've got legacy systems that you have to sort of contend with. And if you have a manufacturer's catalog or some equivalent in your organization that gets sent to you by a third party, maybe you wanna make sure that the fields in your CMS entry form sort of match the order of the columns in that spreadsheet so that it's just easy for people to copy information back and forth. Or maybe there's even like old paper stuff and you wanna make sure that it matches so people can just sort of plow through work instead of having to sort of pick and choose everything. Fields should be organized in a way that makes it easy for authors to do their work, not in a way that makes it easy for us to template them in the front end. And when you customize things in the CMS, you can also customize the AX, which is authoring experience. I did not invent this acronym, but I just use it like it's normal when everyone knows it and eventually everyone will. So it's AX, authoring experience, which is like UX for users or for authors. When you're customizing things, you can customize them for your needs, right? Not for anyone else's needs, which might mean like maybe you have a calendar widget for choosing the date instead of making people type in a date, which is like a lovely easy thing to do in Drupal. Maybe you have default text so that authors only have to edit a few words if there's a text that will work in 80% of your cases. Maybe you have select lists rather than text boxes or you have places where you have autocomplete fields. When we think about things like entity reference, or you can customize what the autocomplete text says in the entity reference, like customize it to be stuff that's useful for your authoring team. Just pay attention to the overall user experience of your authors. Like this microwave here, this microwave has a button for grilled cake. My microwave has a potato button. I love potato button. I have a deep and personal relationship with potato button, but this audience doesn't need potato, right? This audience needs grilled cake. There's also healthy baby. I feel like that's probably baby food. Let's be clear. There's nutrient soup. There's fish, which you should never put in a microwave. Let's be honest. But this is like, this is a customized interface, right? This is an interface that works for the cuisine of the people who are heating this up. There's no potato button on here, so I would be completely lost. But if I need a grilled cake, this is where I'd come. My last pro here about displaying help text in context is that you don't have to worry about people using old versions, right? You don't have to worry about people having some version that mentions a program that has since been renamed or like sort of mentioning an executive who's no longer with the organization. Anytime you decide to change anything on a global level, you can put in reminders right in the CMS so that people sort of can't really ignore them. A great thing about Drupal, if you did not already know this, you can put HTML in the help text fields. So you can put in spans and you can put in all kinds of things. You can put in lists, right? You got ULs and all kinds of stuff. I mean, you can't go crazy because it's like, it's still gonna sort of just display beneath the field. But you can definitely put in sort of some basic formatting and in the same way basic formatting helps users on the front end, basic formatting helps users on the back end. So you can put in some spans and things like that and then add some lines to your CSS and all of a sudden they have like some colors and some icons and just things that make it a nicer experience for people. The one light downside to putting information in the CMS is that you might probably require some development resources. It's not a bad thing inherently but you're gonna need her help. That can be a roadblock sometimes because if you need developer help to make it work depending on the structure of your organization you might need budgeting and resourcing and project management and all that kind of stuff. As you know in Drupal, putting in per field help text very easy, right? You just, if you haven't done it before you maybe need someone to show you how to do it and make sure you have the right permissions but then it's very straightforward. A lot of the most effective authoring experience improvements are gonna be things like light UX customization like creating sidebars or creating collapsing field areas and field sets and things like that and that might take a little bit more than a site admin sort of knows how to do off the back and so that might take a little bit of developer time and so that's really the only downside is that it might take a little bit of developer sort of brain power to make sure that the full realization can happen. So you might be like, thanks Eileen, this is really great. Next time I'm redoing my site from scratch I'll add a great help text right into those edit forms but over here in the real world I already have a site and it does not have these things. I don't know what I'm supposed to do. I actually think that when we're doing problem solving there is a true fundamental value in understanding and sort of believing in the ideal end state even if that's something that we can't quite get right now because if we know what we're aiming for it is easier to choose solutions that sort of take us along that path. So what does that look like for content guidelines? Bare minimum, if you do nothing else you can put a link to your content guidelines in the top of your content editing screen. This might involve a developer if you don't know where the content type description field is. That's like five minutes of developer time. This at least means that if you have a PDF somewhere that like your authors will have a direct easy link to content guidelines and to voice and tone things without having to search them out, right? It'll just be a link on the top of every single edit screen. So that's like, it's not perfection but it's progress, it's worth doing. If you can do a little more, ditch the PDF, get your guidelines into HTML, right? PDF is a very untenable way to keep a living document and content guidelines are a living document. It's really nice to know that everyone always has the most updated version. The easiest way to do that is to have them be on a live website somewhere in a single place. If you have an intranet, right? You might be able to create some pages for your guidelines there and then just link to them. You can also create a page in Drupal and like leave it unpublished that is your content guidelines. And so then authors will be able to see it because they can see unpublished work but it won't be public on the site. Is that super hacky? Yes it is. Does it kind of work anyway? Yeah, pretty much does. Like it's not great, it's not beautiful. I would not recommend it as like a profound long-term solution but it's a pretty good way to get content guidelines into a single place canonical spot for the guidelines linked to right from inside Drupal. It's gross but it works. It's my motto. And then third, keep talking with your team. Check in regularly with the designers and the developers. Like I said, like three weeks after a launch, check in with people and be like, are you offended by something you see on our site currently? Like has someone uploaded a picture that is terrible or put in titles that are completely wrong? If there are places where they notice things that bother them, see if there are tweaks you can make to the guidelines to help prevent those problems happening again. Sit with authors and editors and say like, what's confusing here? Like if you sit with someone filling out a new node form and they're like, well I don't know what this field is so I always just check B. They're never gonna remember to tell you that because they just are sort of breezing past it but having people sort of narrate their own tasks can really help you find places where you're like, oh, you're right, that's a terrible label for that field. We're gonna change this so it makes more sense. And then also check with QA, right? Is QA silently fixing stuff that you didn't know needed to be fixed? Depending on how your QA sort of culture works, if you have one, sometimes QA fixes stuff and then just is like, I did my job, I fixed things. And if they don't sort of feed it back to earlier in the loop, they're just gonna keep fixing those little things broken over and over again. So I used to think that it was inevitable. I used to think that a few months after launch I would sort of be guaranteed to find kind of misused fields and confusing headlines, littering a site, that particular kind of chaos that comes from combining a really powerful CMS with untrained site administrators. But as I've moved my content guidelines into the CMS itself, my post launch check-ins have been like less annoyed grumbling and more places where I can just make small improvements. When we embed instructions where they are relevant and helpful and in context, we help our authors build good habits. We're also helping them build confidence that they have a sense of how this site works and what it is doing for the organization. We allow them to maintain and maybe even to start expanding a complex site without feeling really, really overwhelmed. A website that looks perfect on launch day is a cool and great thing. But when we improve the authoring experience, I believe that we can improve the content forever and I find that personally a whole lot more satisfying. I am Eileen Webb. I'm the director of strategy and livestock at Webb Meadow. I am a hireable consultant. I will come and yell at your teams about authoring experience anytime you want. And I would love to take questions because I love talking about this stuff because I'm a nerd. And you can ask me a question and I'll repeat it into the mic or you can stand at the microphone because we're recording. So yes. There's a big generational gap in that set. I mean, do you want to read the microcosm? Yep. Eventually they recycle. And then I get a new person and I point to it. Well, I know all this stuff and I can do this by hand. How do you deal with that? And you just tell them what you're gonna leave. So the question is, how do you deal with essentially different levels of experience and some people who want to be really controlling of things and some people who are happy with the site you set up for them and sort of how do you just be grumpy at them? Yes, always. I think there's a, especially if there's a team involved, I would usually lean on sort of the idea of creating something sustainable that works for the team overall. That it's not just you, it's that it needs to work for you and also for Sharon over here in this department and for Alex over here in this department and for people in the future. And if they're enthusiastic about wanting to do code stuff, because that's a place where they get a sense of confidence about their ability and their jobs, which is a thing that should be respected and revered. See if you can put them on doing improvements, like on AX improvements. If someone's like gung-ho about templating, make them give them AX template power. It's a good place to sort of test things out and make stuff better in a way that feels kind of profound and people are like, oh my gosh, this is so much easier than it used to be and that feels really good without having to sort of bend over to one person's whims. Yeah, I mean, there are definitely sometimes people who, I would caution against attaching those things to age. My mom programmed punch cards when she was in college and so like, she's good with all this stuff and she's way older than I am. But like, but like, but I mean, that feels to me like a management thing overall, like people have to learn to adapt to the way things work for the better of like, development of the whole team, not just for their own workflows. This is a great presentation. I appreciate it. I realized about three quarters of the way through this project I'm working on, kind of migrating from Silver Stripe. Is anybody familiar with Silver Stripe? So it was essentially like a big whizzy wig and everybody just put their content in there. And so I wanted to make structured content to make it easier. So the need is there because there's so many different fields. But one thing that I noticed that helped me is using the markup module, Drupal 7 and Drupal 8, there's like a beta version in Drupal 8 and you can embed markup within the edit field. And so I made some images that sort of showed where if you put something here, this is how it's gonna render on the page. And that really proved to be helpful for some of the content authors. Yeah, I have also done things where using just like a little bit of CSS and just like a few spans essentially put little tiny screenshots of like this is gonna be a header area or like this is gonna be a feature article therefore it's gonna show up in this thing over here. And it's just people tend to be pretty visual in their work. And so anything you can do, that's a great tip. Anything you can do to help people sort of just get a more holistic sense of how the site works. The site's a system, right? And so often we're working in a narrow piece of the system. Anything we can do to help people get a broader sense of the sort of systemic implications of their work I think leads to a stronger site. Thank you. Do you have any advice for when the in-context content guidelines are regularly ignored? Cause I have one field where I actually have there. Do not put this here and very regularly, it's like we'll put this here. Oh, how humans, adorable. I mean, so that feels to me like a people problem rather than a tech problem, right? Like there are times when it is great to be able to just like type something into a field and have people start paying attention which bully for all of us would get to do that sometimes. More realistic I think is sometimes where you need to do a little bit of culture adjustment and a little bit of sort of training and whether that means putting in sort of an extra governance step to like, I hate man, I hate that all the analogies that pop in my head are all dog training because that feels terrible to me. But like the idea is sort of reinforcing positive things and sort of giving people like a light ding when you're like, oh, remember how no click here on this one, we're not putting click here in this field anymore. You know, like it feels to me like if people are regularly ignoring something, there's a problem behind the problem, right? There's a reason they're ignoring it and that's the thing to solve. This is unfortunately a situation where training isn't possible because it's our broader user group who is. There are also places where, depending on your development resources, if it's something that is, if it's something as simple as click here or people putting dates where they shouldn't or something like that, you can do a little light JavaScript validation that just for a couple of months that like highlights a field red when people put bad stuff in, you know, like just that kind of stuff to sort of break a habit and make people pay attention anew instead of just doing rote what they used to do by habit. Thank you. Hi, from the perspective of a site owner works a lot with contractors on web projects, what, do you have any tips for kind of how to make, express all this in terms of requirements? They feel like we have been sort of trying to make this happen and we say something like, really good authoring experience and then, you know, projects happens and stuff happens and that's always kind of something that people think of at the end and right then you're behind schedule and everybody's tired of working with each other and we're barely making it across the finish line. She likes people. How do you, what's the best way to make sure it really happens? So one thing is definitely to start talking about it right in the very beginning and this takes sort of diligence on someone's part who cares about this is to just bring it up over and over again, much like accessibility, right? Like this is a thing that helps people and we have to put attention on it that when, even when discussions come up, like sort of early in like feature meetings, like think about, okay, well, what if someone uses that field wrong or like how are we gonna make sure people understand the difference between a category and a tag or the difference between using a taxonomy here and using an entity relationship here? I feel like there's a little bit of, we devalue this work generally and so it gets pushed way to the end and then it gets done crappily and then we're like, well, it wasn't even worth it and so then we don't sort of prioritize it again in the next project. So also making explicit that you want a couple of weeks in the schedule, just like you want an entire sprint for this or you want to make sure that like you actually have, and you might just start with like, I wanna make sure we have three one hour meetings in the weeks leading up to something where developers sit with our authors and the authors say what's confusing about the interface and developers, like when we work together to collaborate to find a better solution. So just sort of like building in some very like structural things. We need some meetings about this. We need to put time in the schedule for this right from the beginning so that it doesn't get shoved to the end. Yeah, awesome, thank you. Hi, if you have the benefit of working with your editors on the system that you're planning to replace, which may be completely different than the system you intend to build them, what are some tips or ways that you have of getting information out of them from that experience of what they're building so you don't end up making the same mistakes? Right, right, there's a bit of sort of we don't know what we don't know there. And also people, they just sort of want something lightly better than what they've been using and they don't necessarily realize it could be massively better than what they've been using. Treat it like a true UX research project, like do user testing, do user research, show them a bunch of pages. And the nice thing about this is that like, this is not UX, right, it's just UX. It's just UX on the other side of the site. And so all of the things that people talk about form design on like gov.uk and the Australian government have some really great information about form design like out there. All that stuff applies. And so treat it like you're building a whole other website and do some research and do some brainstorming and show people front ends of sites and all kinds of things and show them forms on gov.uk and say like, would it be helpful if you had something like this? Like give them some sense of what the possibilities are so that you can start to sort of break them out of the mold of like what they have been used to. Thank you. Thanks so much. This has been a great talk. My question is about how if you have a lot of different authors that have both different levels of experience but also different needs in terms of what they're going to use the different content types for. Some of them might just want the very basic fields. Some of them want to do more robust and complex things with them. How do you manage having high level help text and then more complex advanced things, knowledge base, any tips that you have? The, if you have like mad development resources and like an enthusiastic executive, you can do multiple templates, right? A single node edit can have multiple templates. The same way a single node can have multiple front end displays. You can have multiple edit displays. There's like definitely like super developer resources available to maintain that and create those. You can also sort of like fake that, right? With like field groups and with some tabs and with some sidebars and essentially have a default view that is pretty straightforward. And then I like expand this field group and see a number of more advanced fields behind it. I would almost start there with just making things lightly more sort of complex and layered and see how people respond to it and then sort of iterate from there and see if eventually it gets worth it to do something like a whole separate tabbed interface with multiple edit forms. Awesome. Thank you. Do you have any additional or different steps for multi-lingual websites? Oh man, that's a good question. Like all things with multi-lingual websites. So the question was if there are additional steps for multi-lingual websites, I feel like, this is kind of a, I feel like with multi-lingual websites you just have to do everything in every language. Like if there are three languages you're building three separate admin sites and that's like the most realistic way to approach it. So that's if we're talking about multi-lingual editors. If we're talking about having a single team of editors working on a multi-lingual front end, it's again like treating it like a real UX project, right? You have really complex intersecting. You have sort of like an octopus of needs like all layered and sticky and weird and treating it like giving it the legit like research and testing phases because you're building something so complex see if it works for people and then sort of be willing to adjust. I would say like, build a little thing, see if it works, build a little thing, see if it works rather than trying to like fix the problem because you might build something not helpful if you go too big at once. Hi there. I'm wondering if there ever any areas of content that you conclude are too important to be left to authors. And I have something very specific in mind which is tags. I got a system, we're putting in tags. If I let authors enter tags, I'll end up with 10,000 tags and it'll be useless. Yes, absolutely. That is a legit problem. And like, yeah, I think that happens all the time. If you have, especially if you've got authors who are maybe a more like a community group, right? You might have like a thousand authors but the taxonomy of the site requires like tightly controlled vocabulary for it to be functional. I think that's fine. Like I think that's a completely, that's essentially just separating out like, what is needed for the site to function versus like what are the things that our authors want to need to express and what's the information they're trying to share. You might like with something like that specifically you might see of having a controlled vocabulary. So you control the vocabulary but authors get to choose from the list of things. That could be one thing that works. It really depends on the use case, right? But I also think it's completely fine to have things that basically some people don't get to touch. The trick there is to make sure that there are resources on your end to like if someone needs to tag every post then you need to have someone who's like staffed and paid or whatever to tag every post. Do you have any tips or experiences about managing content in a content as a service environment or model where it's not tied to a website but can be used across multiple digital channels? In terms of what, tell me more about like what the, tell me more about the problem you're facing. So we're repeating content across digital channels. So we're trying to centralize that in one place and then reuse that with only one approval cycle, one review cycle. And you wanna make sure that like the content itself is like sort of written to work in a bunch of places. So that's mostly like that's less a technology problem how to communicate it and more to figure out like what are the actual guidelines you need to communicate. If you think, if you're thinking just like the simplest sort of example that pops into my head is like we're making something that needs to work on Facebook and on Tumblr and they have like lately different requirements for what sort of the ideal format is. You need to find what the middle ground is. Like define what it is that you need for it to work sort of what the ideal piece of content would be. A thing that I think is super helpful in many contexts is to give people an example of what the correct way of doing things is, right? And that might need to be a separate PDF or like something like that if it's a large enough piece but even within a field if you can give people a really solid example of like here's the ideal state that could be a really useful thing for people to sort of model off of. All right, thanks everyone. Rabbits and poultry.