What Editors Really Want

Speaker 1: Good afternoon everyone. We are going to get started with the uh second half of our last day at Wagtail Space.

Speaker 2: Yeah, yeah.

Speaker 1: So next up we have someone who you all should know by now, Megan Voss. She is the uh Wagtail Core Team member and the community manager and has uh done a lot of work organizing this conference. And she is going to answer the very important question of what do editors really want?

Speaker 2: All right folks, hello. Just to introduce myself one more time out in Zoomland, my name is Megan Boss. I work for Torchbox Um before I came to Torchbox, I've done quite a few things throughout my career ranging from research science to writing and editing freelancing.

Speaker 2: Uh the mic is hot.

Speaker 1: Alright.

Speaker 2: So everybody heard us. Troubleshooting. Yay! Okay. Alrighty. Cool. Do do do.

Speaker 1: That's you, right? Blog page?

Speaker 2: Yes. Yes, blog page is me. Alright, let me get my slides back. Oh well. That worked out. All right folks, let me start again. Hello everybody, my name is Megavoss. I work for Torchbox. You already know me as the Wagtail Community Manager and a member of the Wagtail Core team. What you might not know about me is that I've had a number of different things that I've done in my career ranging from research science to freelance writing to freelance editing. I've done almost every sort of role there is to do in publishing. um just kind of moving around through scientific publishing and different types of publishing workflows. And a common theme throughout all of this has been content management systems. So it's no surprise when I started learning to code that this is something that I latched on to.

Speaker 2: So I wanted to talk a bit today about what does editor mean? Because we use it as a generic term for the people who we create the content management. system for. But I want to go into that a bit deeper. I also want to give you guys some perspective on how creators tend to approach their work. Where those sources of creative friction come up when they use a content management system. And then with as much time as I have, I'm going to show you some common issues I've seen in Wagtail that have led to frustration for content editors and a few like small quick solutions that you can do to make their experience better. And then of course I will answer the question, what do editors ultimately really want?

Speaker 2: Alright, so when we say editor, it's a very like broad term because an editor in a content management system can be doing a bunch of different functions depending on how it's set up. and depending on what their role is in a publishing team or a publishing organization. They could be most of them, most all of them will do some writing at some point. So writers are pretty common. There are editors. You know, you can also have designers in the mix as well as data scientists. Uh Wagtail doesn't have to just be used for like traditional word type of publishing it can also be used for managing databases in a nice way. So sometimes people don't even enter words, they just enter numbers and data into Wagtail.

Speaker 2: Um you also usually because of the workflows in Wagtail, you'll also have people like legal reviewers and compliance reviewers, translators, so much more. And it's hard to make everybody happy or to know what everybody wants in all this. It's just a very, very broad term. So given my experience in publishing, I just wanted to reiterate kind of what a typical publishing team has, at least at a mid to large level like organization. Um like in you'd see a lot of these roles condensed in much smaller organizations. Sometimes th these roles are all on one or two people, depending on how things are set up. Just because like There's expectations these days to hold a lot of different hats.

Speaker 2: You know, these tasks used to be much more divided up, but now there's a lot more expectations that people will wear multiple hats on these types of teams So you usually have writers who are focused mostly on the prose. And then editors aren't just like it's another broad term. There are many different types of editors. You can have executive editors who are leading and making calls on what type of content to publish. You can have managing editors whose jobs are pretty much to move everything from point A to point B to publish C. Um because their their job is basically to keep everything moving and keep everything organized. And then copy editors are the ones who usually focus in on the grammar and the polishing of the words and the prose and making sure everything is in detailed in place.

Speaker 2: At larger organizations and government organizations , it's not uncommon to have a level of compliance check. with legal reviewers or in medical organizations, it's not uncommon to have a medical expert do some review on content as well to make sure it's medically accurate. Then you also have usually like the designers in the mix who are making sure visual style and visual things are in order. And then also on the team, developers, as much as they seem to be removed from the process are also part of this team, very key. And then the leadership are usually a key part of it as well. They make the big budget decisions. And so pretty much like you have all these different stakeholders working together to make kind of this one thing.

Speaker 2: But today I'm going to focus particularly in on two of these roles because writers and editors are honestly the ones who are going to spend the most time in the content management system. The others will probably be in and out, usually to look you know at reports or to uh make some checks here and there, uh, but they aren't going to spend as much of their day-to-day work. as writers and editors are in a content management system. So let's talk a little bit about how writers and editors approach their work. Even though they have similar goals, they don't usually have similar ways of approaching things. Writers tend to be the big ideas people, the people who want to throw paint on the walls

Speaker 2: and see what's next. They want to like they want creative energy and flow and make things as like gorgeous and Like, you know, writing a like sentence of prose that is just beautifully written is like absolutely addictive to writers And they know the rules, they know grammar, they know like you know what's supposed to go into a good blog post and everything like that. But they also are the ones who are more likely to break them in pursuit of creativity They also do a lot of research and experimentation. They tend to be the subject matter experts. Sometimes they're the ones who like dig really deeply into a topic, even if it's like You know, a good example is a reporter who is on a beat where they have to become an expert on like, you know, one type of um

Speaker 2: one type of science one day and another type of science another day. So they very much spend a lot of their time being in the weeds and focused on the details. Whereas on the other side, editors who are also very detail-oriented and are also in the weeds, they are in different weeds Uh they are very much focused on precision and polish of the pros. They are very much there to enforce the rules uh and to make sure that everything complies with kind of the standards that they set for their readers. They are the champions for the readers. They want to make sure that their readers are getting the information they need. uh that they understand it, that it's engaging, and also like, you know, depending on the organization, they want it to sell as well.

Speaker 2: So they tend to be like larger big level picture experts. They focus on story structure and trends. Um they don't always get the credit they deserve, so they they tend to be the type of people who are like grumbling in the background whenever somebody does something. Like when one of the writers breaks the rules like It's not uncommon for editors. I have seen in newsrooms like all-in-all out fights happening in offices between writers and editors. It it's just the dynamic that happens sometimes. But they do have some similarities together. So both editors and writers are very deadline driven. They are all focused on like the goal of publishing by a certain time or by a certain goal deadline. And they also have a lot

Speaker 2: they tend to work in drafts and they also focus on word count. Pretty obsessive. Because there is some good science and some good evidence behind kind of the level of word count that people tend to pay attention to, especially on the internet. Also, and this is one thing they have in common with developers, writers and editors, love their keyboards. They are obsessed with keyboard shortcuts. They will do any sort of like keyboard shortcut to make their lives easier. So you know as if you ever develop like any like keyboard shortcuts that they should know about, tell them about it. They will love you. Alright, so let's delve in a little bit deeper into what writers and editors need. Writers typically need minimal

Speaker 2: distractions. Like they want kind of a calm blank page that doesn't have a lot on it so that they can just focus on the words. Typically they'll focus more on the words than the final product. This isn't always the case. There are some people who have to edit as they go along uh just because like in this day and age it's kind of expected for you to like do some editing as you're working towards the deadline. But ultimately they want to make as few design and layout decisions as possible when they're working on a draft. because they really want to focus on making the words and the content as good as possible. They also usually frequently need reminders about the little X extras that go with a piece of content, things like alt text or summary text or we need this meta description for the search.

Speaker 2: So those they tend to forget about all that stuff because they're focused on the story very much. All right, editors typically need to be able to find things and organize content very easily. They need the bigger picture. versus the writers because they are usually working on multiple pieces of cot pieces of content. They will juggle through different ones throughout the day. And they need to be able to switch quickly between different assignments. And they also need to be able to make quick decisions about layouts and page structure. They're very busy people. They don't always have time to consult a designer. or to like make sure that they're doing everything according to visual style. When I say visual style, most organizations do have a visual style guideline

Speaker 2: for websites. Uh so that they that you know editors and writers don't have to make decisions about what the font size will be or the color size or anything like that. You'll notice that my presentation looks very similar to Jacob's, and that is because I am using Torchbox style. And I did not want to make design decisions when I was putting together this presentation. So I took advantage of the fact that we had designers who make those decisions. And ultimately editors just need to be able to navigate very quickly throughout a CMS. So let's talk a little bit about friction. So friction, according to like the traditional one of the one of the traditional Newtonian formulas, this is for static friction. There's

Speaker 2: many different types of friction. Friction is the coefficient of friction times full Newtonian force. I think that with creative fiction the formula is like creative fiction is impending deadline. times anything that is not writing or editing the main content. Because that is what those folks like to focus on. And those things include stuff like Formatting, SEO. Like here's the great like secret about SEO is that pretty much everybody who writes in Ed is hates SEO. The people who make money off of SEO like it a little like they hate it a little less, but everybody hates writing for machines. They rather prefer to write for humans. Um but also stuff like social media summaries and alt text and meta descriptions and art.

Speaker 2: I'm just gonna spend some time on art because writers and editors like there was this I'm not sure when the trans like the transition happened, but there's this assumption uh that writers and editors just because they can upload an image must also be able to create them. I have lost so many hours of frustration trying to sort out art for pieces, uh, just because like that is not a skill set that I have or as a writer or an editor. I can resize an image Like I'm more than happy to take care of that part of it. But then sometimes you have to go through and like figure out like what is the actual resolution that looks good on the page type that I have. And sometimes you wind up just troubleshooting for so long and your image is still fuzzy.

Speaker 2: So this is like, you know, a big one that is a usual big source of frustration for writers and editors. So, with that in mind, here's a few ways that creative friction tends to arise in Wagtail and different implementations. So typically like where writers and editors tend to get the most frustrated is around like unnecessary clicks. Listings that are hard to organize. Like we've invested a lot of time in upgrading listings recently, so I'm interested to see how that will change over time because I think they're a lot better than they used to be. One of the other things is like one of our menus lists the older content first, and it's really hard to change, so sometimes developers don't change it.

Speaker 2: And you should know that most writers and editors don't care about the stuff that was published five years ago. They want to work on the stuff that was published today. do tomorrow. So if you're like making it hard for them to get to their most recent stuff, you're making them very like that's a big source of creative friction. Also things that tend to show up are like poor labeling, sometimes unhelpful validation, under tested stream fuel blocks. This is where I have also lost a little bit of time here and there just because like you know I get a new block that's added to a project and somebody sends it to me and it was clear that all the fields had not been tested Because like if you do if you take nothing else away from this talk, developers in the room, please use actual content in your

Speaker 2: testing. Um don't just like fill out the same word like I don't know cookie 500 times and assume that that'll test things. Um use like you can even set up things in Factory Boy or other tools to kind of mimic actual content. And also remember that your editors are human. Sometimes they will try and leave leave things blank. So you do have to test many different field value like variations. The other thing that tends to be frustrating for editors and writers is like the visual cues for layouts. So the preview in Wagtail is a really Great tool. But sometimes like editors and writers don't remember what the blocks and the pages look like, and so they usually need some sort of visual reference.

Speaker 2: uh to be able to like refresh their memories because you're like you're asking the editors to do some design work in addition to structuring the content on the page by having them use stream field blocks And so they need to be able to remember how those things fit together so that they know how well it's going to look on a page. And then I already granted about art troubleshooting enough, but that's also like a pretty common source of friction. All right. Alright, so now I'm going to pull up my uh my IDE and show you some kind of small live examples of things that tend to show up and kind of make me get a little frustrated whenever I see them

Speaker 2: So I started out this demo just pulling from this template that Tebow pulled together from our Wagtail tutorial And so that's that's just what I started with, and I'm gonna go ahead and add a few things to that. So let me um see if I can escape this, and we'll go over here. Alright, so pretty much we have a pretty basic project here with a basic blog. I did not start with our favorite bakery demo because the bakery demo is honestly a little too opinionative for what I'm trying to show you. So right now we have a basic blog site with a blog app and a home app and pretty much not much else in here.

Speaker 2: So Let me go over to my browser and we will go back to I tend to use badgers in all my examples, it's just a habit from high school when I tested everything with the Badger Badger Badger video. Another great UK export besides Wagtail. So Okay, so right here, this is our homepage, Badger Bonanza. So you'll probably like, you know, when you add a chow page here, you get what you expected, which is a selection of different page types. And this is to be expected on a page like a homepage because you're going to have all these different types of page types that need to be nested underneath it. However, if we go back here, you'll see I have a blog index page here.

Speaker 2: And if I want to add a child page to the blog page, we get these choices again. And I'm like, why? I don't need anything but a blog page here. Why are you making me choose? Why are you making me click? Why are you taking me an already busy editor? and making me make another decision. Like this is unnecessary. So pretty much the way to fix that is there's a setting in Wagtail that you can use on your pages called parent page type and subpage type. So let's go back into our code here. And here we have our blog page model here. And I'm just going to go ahead and scroll down and add something to the end of it here.

Speaker 2: Right, let's make sure it's intended properly. Alright, so this is the parent page type setting, which is basically saying blog page now belongs to blog index page, and we're going to find blog index page in here, which should be. Further up. And we're gonna add the corresponding setting here, subpage types All right, we're gonna save that. We're gonna go back. to our page here and refresh it just in case.

Speaker 2: And so now I'm going to go here and I'm going to add another child page to Badger blog and you'll see it just takes me to the blog page. Easy peasy. Don't need to make a decision. It took two lines of code to simplify that for your editor. I have seen so many instances where they don't do this and that really needs to change because like if there is only one page type associated with an parent page type you should not be making your editors and your writers choose that So that's one key way to help out your editors with that particular situation. All right. The other thing, if we uh go back here to our

Speaker 2: homepage. I'm gonna sh we're gonna go to this list here again. Um And you'll see that blog page has actually gone from this list now because it's been affiliated with blog index page and it won't get chosen again unless you go that direction. And you'll notice like here it's kind of again like you're making people try and make a decision about what page type they have. But they might not like if you have a website like the C F P does with what, 30 page types was it Like not everybody's gonna remember what 30-page types do. You need to give them some cues. And in this small example. The one like mo names are great and most editors are smart enough to figure out the blog index page is probably going to be the homepage for the blog.

Speaker 2: But they might be confused by something like, what the heck is blog tag index page? Which in this demo, that page type exists mostly to give the opportunity for tags to be used in the blog. And it's not really meant to be set up more than once. And so what I'm going to do is just show you how to add some page descriptions to make this easier for your users. All right. So black mobile. So I'm actually gonna go over to the homepage as well.

Speaker 2: I'm going to add in this page description here, this page description setting, and just, you know, a little text that tells people what this page type is for. You might not have to be terribly explicit. It depends on how involved your users are and how many new people you have churning through. But you know, it might be wise to add something like there should be only one type of this page. If there is more than one, there is a problem. So that's the label I'm going to put on the homepage. Let's go back to log models and let's add this to

Speaker 2: And we'll go down to blog tag index page, which is all the way at the bottom here. This should not be Let's go back and refresh. And now you see we have this list And a little bit of help text that tells your editors what those page types should be doing. Like the the text is a little bit small on this, they might miss it. Um to be honest, but at least it's there and it provides some sort of guidance if they need it. All right. So now that we have things kind of like labeled well on the page side of things, I'm going to show you how you can use some help decks to help your editors out with images.

Speaker 2: All right, so on our blog page let's go back to pages And let's go to actually we want the child pages. So here's one of my uh blog posts here, badgers are the bomb And so down here we have like this is where the um where the images get added. And I can you know go ahead and select an image, I can go ahead and add a caption. But I m don't necessarily get a whole lot of information about like this is again a very basic demo. There's not much in the way of styling on this. But I don't have much guidance on how this image is going to look on the page.

Speaker 2: um or what size it needs to be. Like, you know, somebody might like this happens all the time. Like somebody sends you an image that is like 200 by 100 pixels and you need it to be more like 2,000 by 3,000 or something like that. And then you there's a lot of back and forth on that. So it's good to know ahead of time, especially when you're requesting. um you know, art from other people, what size you need it to be, because then you can just ask them. And since most editors and writers don't have access to the code, like I have an advantage as somebody who works on Wagtail. org quite frequently. I can look at the code anytime I want because it's open source. That's not necessarily true for your editors and writers at organize other organizations.

Speaker 2: Okay. So let me So we're going to go to our model for the blog page gallery image here, and we're going to add a field panel. like some help text under image. So right here, these are the panels that show the different information on the Back end of Wagtail. Actually, yeah, that's right. I need to update that one. So I'm just going to

Speaker 2: Update this. And so what I did here is I added to this like a little bit of hex help text right here that basically says this image should be at least this size. This is just an arbitrary number twenty ten twenty four by seven sixty eight pixels. So if we save that and then go back to our site and refresh that. You'll see now under image there is some help text that shows the editors what size they need. And you don't necess you don't just have to use uh help text there. You can also use something that is called a help panel It's a panel that just provides information and nothing else.

Speaker 2: So let's go ahead and add a help panel. Say like I was working on a this blog needed to have like multiple images for it to look good. Then I can also like above this add a little help panel as well. If my copy and paste works. Oh yes, that's right. I need to put the import statement in. That is very important. Do not forget your import statements. This one imports from Wagtail. admin. panels up here. So we're gonna go ahead and add

Speaker 2: help panel as well. All right, if we save that. And refresh. So now we have you know a little bit of guidance at the very top of the image section that says like you know choose one to three images for each blog post. Like this is what it needs to look good You know, it's uh you can add like cues along those lines. All right, um because like this is short on time, I'm going to show you one more thing. I'm gonna like kind of show you how you can um like one of the other things again I said that You know, somebody like me can look at the open source code and see what the code looks like in the templates, but that's not true, necessarily true

Speaker 2: for everybody. So if we go into one of our templates here Like honestly just our base. html. Like it's not uncommon for fail safes to be programmed in. But with editors, like you know, especially with this promote tab here If this is blank, they assume there's nothing there, but that's not necessarily true. So this title tag is SEO underscore title um in in Wagtail. And so if we look at our code here on the template, like you know, we have an if statement here that's checking to see if there's the Nesio title. And if there isn't, it actually substitutes the default title from the content page.

Speaker 2: It's very common to set up those types of failsafes. On Wagtail. org, we have one for the search description that pulls the intro. on the page as a substitute if the editor leaves this meta description blank. Because honestly, the thing that edit things that editors are going to forget the most often are these items that are over here in the promote tabs or in the tabs. And so I'm showing you a way to kind of help remind them how to do that with labeling. Another way you can do this is through validation, but we have a very excellent talk on validation coming up after me, so I'm not going to delve too deeply into that. So I'm going to just go ahead and show you like a way to kind of add a label in the promote panel. uh

Speaker 2: to make things much easier for folks. All right. Because if you don't tell them it's there, they're not going to know it. And the smart ones will figure it out. But others will just get frustrated when they see these blank boxes and be like, oh, why didn't so-and-so fill this out? Alright, so let's go back to blog page, our blog page model. What's up, hi? Alright, and under content panels here, I'm going to add

Speaker 2: a change to the remote panels here. And pretty much what I'm doing here is I'm just adding another helpful panel up here like you could like this should follow whatever the logic is for your particular template. Like this one is a very very super simple example. But this like kind of gives the editor a cue Right here, like you know, right at the top of the page, if you do not fill out a title tag, the page title will be used by default. Like they need to know that those defaults exist and they need to know whether they're editable or not because Otherwise, what they'll do is they'll like copy the link over. Usually they discover issues with this when they're trying to put out their social media and there's something wrong with the photo, the description isn't displaying right, or something like that. And by that point, most editors and writers just be

Speaker 2: want to be done with everything. So it's very frustrating for them when they have to troubleshoot that type of stuff. So the more information you can give them on this type of thing, the better. All right. So that is it for The demo. So just kind of to wrap up here, ultimately what editors want is the same things that most human beings want. They want empathy. They want empathy from you as developers. They want empathy from their bosses. They want you to be thinking about their workflow and like trying to take care of them on this front. Um they want uh, you know, help with their

Speaker 2: making their jobs and their lives easier. And they want support. They want to feel like good support and like that they can focus on their job. And ultimately, like a lot of reason writers and editors and content creators do this work is they want to connect with other humans. They want to help educate people. They want to share their wisdom and knowledge with the world. And the more that you can do, the more that you can think about like how can I help this other human being succeed, the better off your content management system will be. All right. Thank you so much for listening. You can find my slides here. You can find the repo with those small demos here. I'll probably like expand that in the future. So feel free to subscribe to it. You can find me on X Twitter, I will never call it anything but that,

Speaker 2: at MeganBoss. I'm more uh active on Mastodon at WASDEBoss at Fastodon. org. Um I I'm listing all the image credits here because that is what one should do. Most of these came from Unsplash. And of course I have to thank my employees. employer for bringing me here today. I work with so many fantastic folks at Torchbox and within the Wagtail community. So thank you And I think we um are probably pushing it a little, but uh maybe one or two more questions. Yeah Anybody has any questions? Michael.

Speaker 3: You and I have talked a little bit about feedback from content creators and managers. Does First Talk to the WireCalf team have any effort? to reach out to that demographic specifically for their feedback. And I know we've talked about the design of the admin a little bit, but how are you, how is the organization

Speaker 2: All right, so the question was how um Is Torchbox reaching out to this particular demographic editors, writers, and how are we soliciting information to improve these types of things? So a lot of that I I know that we do reach out to our clients quite frequently and it's kind of difficult because like clients are very busy. You'll hear from them a fair bit when they have complaints Uh and you'll but you don't necessarily hear from them uh when they have uh feedback, like they can support things. I think we primarily reach out through the product directors and I know that I personally like whenever we have a roadmap come up, I make sure to get that out on social media and poke some key people.

Speaker 2: to make sure that they at least have an opportunity to provide their feedback on that. So it's it's kind of hard to reach this particular demographic because right now the developers are the ones who are most engaged with the community. Um but and also like it's small enough that you know Wagtail is is spreading, uh, but we don't quite have as many people like we do have some people wander into our inbox looking for tech support because they don't quite understand how it works. And sometimes I will like ask them some questions and get some information there, but it's it's honestly like we could be doing a better job kind of organizing that effort overall

Speaker 3: I suspect it's a very hard initiative because in my experience the folks who are working with the CMS have grapes but have very little idea how to actually fix those things.

Speaker 2: Yeah, yeah, that's definitely true. All right. Any other questions?

Speaker 3: More round of applause.