Building Flexible Wagtail CMS Experiences for Editors

Speaker 1: Hello everyone and welcome to Building Flexible Wagtail CMS Experiences for Editors. I'm very pleased to announce uh or to introduce uh Annette Lewis and Eric Sherman. Both of them have been around Wagtail for a long time and have done a lot of really cool things. So here is building flexible Wagtail CMS experiences for editors.

Speaker 2: All right. Welcome everybody. Thanks for the intro, Vince, and hope everyone's having a relatively smooth day today. I'm Eric. And Annette is Annette. If you want to say hi.

Speaker 3: Hi, yeah. I'm Annette Lewis. I'm a senior Python developer with six feet up And uh I enjoy many hobbies, you know, coding, solving code problems, fool hooping birds, and I also really enjoy building good software solutions and solving problems in that way.

Speaker 2: Yep, and I my name's Eric. Uh here's a nice picture from me actually at the last Wagtail space uh taken by Tom Dyson. uh wearing one of my favorite Chicago shirts. Uh shout out to anyone who's able to make it to Chicago for DjangoCon this year. Uh I know we all had a blast. Uh and yeah, I am uh I also a software engineer. I work for Truth Initiative and um The fun thing about that is we work in the innovations department, which means my job title means that I get to be the innovations senior software engineer. Um

Speaker 3: So the title of this is Building Flexible Experiences. So I wanted to kind of talk just about flexible first for a moment. So I had this fun definition slide and You know, being able to bend easily without breaking, being able to be modified or altered for circumstances. But like the one that really sticks with me is having the capability to adapt um to new and different changing requirements. And if there isn't anything about development, that's what we're doing each and every day. So when I'm thinking about flexible experience, especially for content editors, it's about finding the synergistic balance between editors, developers, and the platform so that you can create a good editing experience with good ease of editing, allowing them to have a good amount of ability, and keeping the development effort at a consistent place.

Speaker 3: Uh

Speaker 2: yeah, so I'll explain uh a little bit of background context for the things we wanted to share today. Uh so X program is the main thing I work on. It's a digital uh nicotine cessation tool. Uh It's primarily uh uh mobile friendly, mobile first website. Uh there's also a really big part of it that is SMS messaging. And uh we have a a mobile app for people uh who have access to premium features through uh different uh Businesses that provide it as an employee benefit where they can chat with coaches and stuff to help them uh quit smoking, quit vo vaping Quit uh dipping, chewing tobacco, whatever the tobacco industry is throwing at people, trying to get people hooked on, uh, we help them quit. Um

Speaker 2: and we Uh have uh user traffic that varies pretty widely, especially depending on these platforms. Uh it can be anywhere between around like 9,000 users this past month I checked, uh but that can depend on different ad campaigns that we run and stuff like that. Most important for this talk, I would say, is the nitty-gritty of our our team size. We have about two to three public health experts who are working on editing content. And a team of about five or six developers. It has sometimes extended to as many as ten, uh, which is part of the work we're going to talk about. We did Staff augmentation with six feet up and cactus to get all this new stuff off the ground. Uh but you can see the ratio of uh uh authors

Speaker 2: to developers is what it is. The content editors are not just writing content, uh they're also helping to direct the direction of the product itself. Uh and We try to free up as much time and brain space for them to be able to continue to do that

Speaker 3: So to kind of demonstrate some of the things that we did when we were working through this project, we've decided to kind of take a case study approach and look at three particular areas. So one we're going to talk about the home page redesign and how we How we implemented that and the challenges there. We're going to talk a little bit about a page header update, which is our favorite in-place updates to something and trying not to break the old while making the new ones. And then really like a kind of really neat feature that was implemented was just the topic page and information architecture revamp and how that really created a much easier editing experience for the editors later on.

Speaker 2: Yes. And so thanks for bearing with us. We had such a hard time choosing what to talk about. We decided to talk about three things. So we'll we'll do our best to leave time for questions and uh keep things moving. So first I want to like briefly explain this homepage redesign. So we had a a a brand new ad campaign that we were launching around the end of last year. Uh we knew this would be a high traffic page uh with a very specific design. Uh lots of stakeholders were involved in the in the creation of this page. Uh and We needed this to exist side by side with our existing homepage. We're adding new features, including the ability to direct directly register for the program just by entering your phone number. uh we needed to build out that feature while also working on the front

Speaker 2: end design. Uh and so in this case like flexibility like might have meant uh uh editors being able to create a page with minimal developer involvement, but we knew in this case that what we actually needed was flexibility in terms of when this information would go live, when the design would be live, the ability to enter content before it's live for users, and making sure that the launch goes smoothly with zero surprises. And so just side by side, uh, you know, here's some examples on the left. Hopefully you can tell is the older uh site design, which had gone through several different iterations. On the right was the news site design, which is significantly more content, but a lot clearer to follow.

Speaker 2: And you can see there's two different ridges where you can register. uh via phone number. So there's a lot going on on that page and both of them live at the same place on Wagtail. This is a a common pro issue that you might run into. Working on a project where you need to be able to move from something old to something new. This was also a time that we were basically doubling the size of the developer team. So I was also looking at how do we structure this and onboard uh five new developers to work on this project, some of whom had varying familiarity with with Wagtail itself and the ins and outs of that. And this all needed to happen basically simultaneously. And so what we decided to do for this is you have flexibility, like we said, in terms of rolling out previewing features, uh, but also having guardrails

Speaker 2: and like very simple Wagtail Django fields are are perfect for this sort of thing. Uh we took the simplest possible approach. You know, if if you were to go into the CMS at the time this project was in place, we had all of the homepage content fields for the existing page and the new page were all on the same page. Uh I nested them under two different uh sections so that they're easy to find. But this avoided the complexity of something if we were going to use string fields. I didn't want to have to deal with migration conflicts as I'm sure some of us have dealt with and know that's easier newer versions of Wagtail. I also didn't want to spend as much time as could be possible explaining how stream fields worked to developers who are less familiar with them and while that might have ended up in a like more flexible design in the end, what I knew

Speaker 2: our editors cared about most in this case was again that flexibility of rollout. So we even included pre-populating these fields with content that we knew was already drafted and reviewed by many stakeholders. So that lives in our code base, but it also meant that When we deployed this uh page, it pretty much was already in place and allowed us to do QA and testing and kind of have a real tight control of uh the rollout.

Speaker 3: Yeah, and so getting back to the rollout, it was really important that during development we were able to see what we were doing, those changes, but keep that hidden behind the flag. And we were still pushing to production. We still needed to keep that work going. So during development, we had the simple redesign flag and then a URL parameter that could control which version of the website you were viewing at a time. And that meant that we could actually do user acceptance testing directly in production without exposing that new version to everybody. So it allows you to manage all the content, preview at any time. And that way when it was time to go live, you could just toggle the status live And then there's no additional development needed or development deploy needed to get that going out. And that was a pattern that was used with truth before Um, because you know it's simple, it's predictable, it lets you safely roll out major visual changes and keep control.

Speaker 3: We just add a little code snippet of that little uh flag that we had and how we could just flip the whole different type of template when it was time to go live.

Speaker 2: Yeah, exactly. Um And so, yeah, some of our our takeaways for this, uh everything went very smoothly uh with zero surprises. And so it really kind of validated this approach of Starting sometimes if you're dealing with a project like this, it makes sense to just start simple rather than bake in a lot of uh flexibility or complexity that sometimes your stakeholders will will ask for, you know, sort of I don't want to say naively, but you know we are powerful people able to magically create solutions for people and It's important to actually kind of dig into that and say, okay, what are the most important things? What can we deliver most concretely? And sometimes uh I know I've seen in other talks too, we talk about this that people often ask for flexibility, but digging into what that actually meant

Speaker 2: in each context is always going to be important because it's unfortunately the answer is always it depends. In this case, definitely being able to empower editors to preview and test the content the content uh using that the URL param, the feature flag to control that rollout, uh making uh very obvious simple uh fields so for example we have three testimonial blocks in the design uh for quotes for people who use x program we just made three rich text fields uh for First, second, third testimonial. So really just help to avoid any sort of miscommunication, even though that could have been something more complex with like a stream field or even an orderable list of uh testimonials that's extra steps for authors that we didn't want them to have to worry about.

Speaker 2: Uh and then that gave us a simple, stable foundation that enables future growth. Uh a shout out to the talk on Thursday that Chrissy and Mike uh colleague Doug will be presenting uh because we have other kind of marketing landing pages that we've been rolling out onto truth that use this really solid foundation of the homepage. We were able to focus a lot on the CSS and the HTML template and everything and make that something that we can kind of iterate on with reusability in mind for future versions.

Speaker 3: Yeah, so that once again, like the key thing that I thought was really neat here is that we have that stable foundation for this page. And that you can make future iterations on it. So it's like start simple, get out the work, iterate later, and find those use cases as you collaborate with your editors to like hone that into what you need in the future because requirements change over time.

Speaker 2: Yeah. Okay.

Speaker 3: So then one of the other things that we worked on were page headers, and that was Something that, you know, almost every page has a page header, title, intro, hearer, image. And we needed to up implement a new style in place with existing content, but with a very different design. And then allow the editors to kind of choose the style based on the content that they're putting into that input while also like hiding that. So we we decided automated header styles were going to be the easiest rather than Saying, okay, well, you can have a drop-down and pick the type of style header you want. Let's link these to certain pages, link these to certain things, and change how the look and feel is based on that. So

Speaker 3: here, these are all three different types of headers that are on our site, and there's different permutations. So we've got title description. images, different colors, different themes. And I wanted to think of a really simple way to like how do I make this all be simple? Dry. Like don't repeat myself. Don't have to make multiple blocks. Use the same kind of coding and things And so we decided to use a themes approach and kind of set the theme of the hero block depending on the page that you're on, and then also depending on whether or not you had an image. So that way we could have multiple variations, different looks. And then also just clever CSS and styling to make sure that it looks good on all browser sizes with or without the description. So they have a variety of ways that they can use these blocks.

Speaker 3: So in here, this is just a little code snippet, and we were able to do it all with one code snippet, which is really nice, and that really shows the power of CSS and uh especially with SAS and um compiling things. So right there, like on the parent page, all you'd have to do is pass it the theme to that block, and then everything else would just flip accordingly. We would just apply the styles conditionally. And then the CSS takes it from there, even with the different wrappers and the rounded style. So we were able to keep one code block, manage everything in one place. And then if you need additional themes in the future, you can just add new theme classes and apply those and then pick that up in your CSS. And that ended up being a very clever way to manage this requirement. without having to get

Speaker 3: the developer involved again and again and again. And it's automated so that they can just have a predictable pattern of what they get when they use these content types. So that that key solution, as I talked about, is that editors get to make the choices based on their content You keep the brand and uniformity of everything, and then that simple template control with the variations allows it for easy management in the future.

Speaker 2: Yeah, and I'll say uh I was really happy with how this turned out. You did a great job in that. And one of the things we wanted to do that we focused on with this was also informed by past decisions that we had made with our code base and is also very much informed by the sort of Matthew Escott's Zen of Wagtail, which I always find handy as a as a place to to focus. Um you know, we have other parts of our code base and it would have been easy in this case to say maybe make a couple drop-down fields in the author interface so that the author would be able to choose which theme to use or which background color to use. But when we drilled down into those questions, we found that Oh, this background color is teal when there isn't an image because we want a slightly different design if there isn't an image.

Speaker 2: And so we knew, okay, just for the editor, just merely uploading an image. will change the style of the header instead of having them also have to click a drop down to change the theme or have us have to write extra validation of like what if this theme is chosen but there is still an image uh it just ups the complexity with the end result still being the same. Uh and similarly uh with uh you know the sort of curvy design you see, we learned that that was oh that was a design for our specific topic pages, which we'll talk about next. And so we knew that actually leveraging Wagtail's content types, we could we could know that we had a different type of uh design based off of the content without that being something that the editor has to configure uh

Speaker 2: directly. And so with that we'll come to our last case study and then hopefully we'll have time for questions. Um so another uh thing that came down during this redesign was uh a request for a new what ended up being a new content type basically we had pages on specific topics Uh and we r knew that we needed a better way to organize related topics. So for example, if you might have a page about coping with anxiety that happens uh both while you're smoking and while you're quitting. Uh that might be organized under a c topic of stress relief. But that might be uh kind of under this general umbrella of health and well-being. And we had spent a lot of time organizing our content uh in a way that made more intuitive sense.

Speaker 2: both for content authors and for users. We wanted to be able to show more of that information in one place and have a flexible structure where each topic could live on its own page. This is a a screenshot from our Figment design. When we initially uh grabbed this, uh what I was able to see is, okay, there's a lot of nested content here. Some of it is placeholder, so it hasn't been drafted yet, but we know that we wanted to be able to dynamically include content from one page on another. And again, a flexible solution would have been maybe we wire everything up in stream fields. Give uh page chooser snippets. Author can pick any page and display its content on any other page. Like that's flexible, right? But that also would have lost the information about how the content is organized.

Speaker 2: It would have been so many more extra steps for the authors. Uh our developers, we might have been able to just kind of walk away and say, look, we we did it. We made something flexible. But At the end of the day, going back to our context, we knew for the two to three people that are going to manage this, when we have, you know, 300 different pages, we need to step in a little bit more and kind of uh free that up for them. And so we did this also with a combination of simplicity and complexity. Uh we use as much built-in Wagtail functionality as possible. Uh so you uh if you've worked with BlackTel, you know BlackTel has really uh powerful page tree hierarchy concepts, and we decided to organize all of the content into page trees. Uh We you can also control the way that that is ordered uh inside of the CMS.

Speaker 2: None of this is code that we had to write. Uh we didn't have to write test coverage. We didn't have to make sure that it worked, we didn't have to onboard developers or editors into how it works, which is using the built-in functionality. And then this allowed us to use stream fields in specific context on those pages. So each child page manages its own content. But we're rendering some of that child page content on its parent page. Uh and so we defined clear page sections on each of the pages. for their introduction, for the body of the page, for the sort of footer of its section that would render on that page itself, but also render on the grandchild of the grandparent page uh as well, which is a little bit confusing probably to hear and to explain, but in practice

Speaker 2: ends up being more intuitive than having to manage it in multiple places. And um And yeah, so uh in this case flexibility meant having something be automatic, having if you move something, uh If you move the order of the pages, it it's already reflected on the page without an editor have to do to do anything else, without a developer having to modify a list of menus or anything like that. Editors are able to manage it manage this visually and the navigation stays perfectly in sync. was a bit more complicated to figure out from the beginning, uh but the end result is something that's simpler, can be scaled, and is editor friendly.

Speaker 2: So Yeah, I mean this worked really well. I it was uh using those page structures uh can uh Basically saved us a bunch of time, you know, in in deliver delivering this functionality. Uh this is like a I just wanted to share, you know, on the left hand side, this is a version that's live on the page. And so each bits of that content is managed on on the page that it's associated with and not anywhere else. So this was something that I mostly hatched together and it was around the same time that Annette came on the project as I was looking back at this. I think Annette was actually the one who reviewed and merged this code and thought it was good.

Speaker 2: That's my best impression of her in the GIF. Uh right there doing the thumbs up. And uh um it's also how uh this has worked since we've implemented it. So There's been like minimal developer support needed after we launched this feature. There's many different topic pages that are set up and I haven't needed to uh support editors that have been able to spend that time working on other things that have come up And it really was super helpful to focus on the functionality that Wagtail already had built in. It gave us such a strong foundation. And the sections that can have stream fields added to it, uh are ready and waiting for us to add different kinds of components and blocks to as that grows in complexity. But so far it's been simple rich text fields and we haven't had uh

Speaker 2: a need for anything else. And so we also avoided uh you know sort of over-engineering that from the get-go. But uh it still will be flexible for future needs and stuff like that.

Speaker 3: Yeah, that was fun when I was reviewing this page because It's one of those when you get this design, you think, how in the world am I gonna do this? And uh Eric really came up with a a nice design that was manageable. It's got a great foundation and the fact that the sections are organized and the stream fields are already there and available is that the editors can expand upon it and use it in many creative ways in the future without having to go back and reiterate and do all the code. And I think one of the most valuable things is that It's intuitive. Like when you're looking for that page or subpage or you need to change the description and the title of something, you can just go find that content and that owns all of its information. You can update it there and everything that it trickles up to, parents and grandparents are just automatically updated.

Speaker 3: So it's really a nice flexible scalable approach and just future planning without doing everything in the kitchen sink. You've got everything you need to move forward.

Speaker 2: Yeah, absolutely. And I know we've got just a little bit of time for questions. I go back a little bit to this slide and just explain a little bit more. For the stress management example, stress management is a page, it has an introduction section, which is the description you see below it. Right below that, where you see stress relief techniques, that is a child page of stress management. And the introduction of that page is what you see over on the right hand side. Over on the left hand side is a sidebar of content that is managed on that page directly. And then the list of pages that you see there are actually child pages of stress relief techniques. uh which you're able to see uh in the CMS by navigating through the page

Speaker 2: tree. Hopefully that's a little bit more clear. But yeah, that brings us to the end of our talk. I think we've got a bit of time for questions. Oh, and I wanted to say thanks uh obviously the six feet up team for jumping in on uh this project. And uh we also had some developers from Cactus. Uh through this mad dash. And so I I really appreciate everyone involved with this project. I don't have time to to list all of you, but uh it was great to work with everybody.

Speaker 1: Excellent. Thanks, Eric and Annette. That's super cool what you've built. Great job. Yeah, we do have about five minutes for questions. So if you have a question, uh go ahead and just drop it in the chat and I will uh ask it to our speakers. Um I've got a question of my own, actually, so I'll go ahead and kick things off. How do you usually choose between what should live in a page versus what should live in a snippet? Have you ever had to kind of weigh that decision?

Speaker 2: Yeah, no, that's a great question. And actually, I mean Annette and I worked on something else that we didn't include the talk that was a perfect example of that where we had um author pages that we were setting up. And we wanted to be able to have an article page that was written by a certain author and have the article page be associated with that author, but also have a page for that author Those authors are also affiliated with different organizations. So we are organizing content that way as well. And that was like a good example of a a time where I with my wagtail brain was like, okay, well authors are obviously snippets because they're gonna be reused in multiple places. And that was a situation where uh Annette and Anthony from Six Feet Up, if you want to talk about that part, you y'all like pushed back and were like actually like well if there's an author

Speaker 2: page does it need to also have a snippet if it's if it's just gonna be a page and so I don't know if you want to

Speaker 3: Right. Yeah we did talk about this. So we had we had some discussions. We used to have like little collaboration powwows and that was the thing was like well Let's think a step or two further in the future. Um, what do we need to display? And when we found that out, we realized, okay, well, if you have an article, you might want to click and look at the author. that makes sense to be an author page because it needs a solid place to live. And at that point, if we had little bits of satellite information, we could still use a snippet. We have like a snippet authority tag at the bottom that can pull from the author page. And get those details. So that way the information lives in one place, but then you have these little code bits that you can select and use it through other places. So easier content management.

Speaker 2: Yeah, definitely.

Speaker 1: Great, thank you. Okay, uh looks like we have one other question here. Um were there any uh performance issues or considerations with having to fetch children, grandchildren on each request.

Speaker 2: Yeah, no, that's a great question. Uh and was something that uh I considered when I was working on it. Um the short answer is No, not really. Um it that might be different for a different kind of a site. Uh But it was um I did some performance testing and querying at the time. And at the end of the day, when you're you're visiting a page, uh, we were only expecting it to go uh a few levels deep. Um there's you know not if there was hundreds or maybe thousands of pages nested that way as it branched out, um it might be more of an issue. We have about 600 pages total. That's in two different languages. Uh so it isn't really approaching a level of scale where it seemed like

Speaker 2: too bad of an issue. Um there there was some optimizing that I did when I was writing the templates and functionality where you know we only fetch the fields that we need. So in most of those cases we just need the the page title and and its URL. We don't need to be querying the entire page object and and getting uh all of that extra content. Uh so that was just kind of some common sense uh steps that made sure that that worked well. Uh but Yeah, and then the brief, you know, the amount of performance analysis I did, it didn't really affect performance too much. I think we can especially thank, you know, Tree Beard and Wagtail for optimizing those kinds of requests uh before I need to deal with that.

Speaker 1: Okay, we have time for one more question. It looks like somebody in the chat is wanting to ask one. Aman, yeah, go ahead and ask your question. And for anyone else who doesn't uh get the opportunity to ask a question, um you can always ask in the lobby uh later on. And Eric and Annette will be around to hopefully answer that for you Okay. Well, I think that wraps it up. So thanks again, Eric Internet. Great, great talk. And um we'll see you in the lobby.

Speaker 2: Yeah, thanks. I'll see y'all.