Building Better Wagtail Sites: Traits of a Good CMS

Speaker 1: All right, everybody. I just want to make sure we're all oriented in the room. So please welcome to Building Better Wagtail Sites, Traits of a Good CMS. It'll be presented today by my good friend, Michael Tritall from Lincoln Loop. Take it away, Michael.

Speaker 2: Megan, just really quick, can you see my screen?

Speaker 1: I can see your screen.

Speaker 2: Alright, just we don't want technical difficulties at the beginning of a of a talk, right? All right, everybody. Um this is yeah, as Megan said, this is uh Traits of a Good CMS. I'm Michael Trithal. I am the director of strategy at uh Lincoln Loop. I've been there for about 17 years now. As a director of strategy, it's my job to work with our incoming clients as a Python Django consultancy. To figure out what their needs are and structure their problem, uh build a team around their problem and see it through. Um we build a lot of content platforms, CMS-based websites. Um We've been using Wagtail for a really long time. It's one of the few CMSs that we use, but I would say Wagtail is becoming um the where most of our efforts are. I've been in the CMS space for about 20 years now.

Speaker 2: Prior to Lincoln Loop, I did a bunch of work for a bunch of magazines and AOL and I've always sort of worked in the content space. So I'm always fascinated by the problems in this space for sure, and I'm always trying to figure out how to do it better. One of the things that's that's come up is um Over the past few years we've inherited some Wagtail websites and some other websites. Um and platform owners always want to know If this the the software that they've invested in already is one they should continue with. So the question I get is I don't I don't you know I don't really know this wagtail thing. I'm maybe new to the organization. Is this something that I should keep? I love Wagtail, want Wagtail to do well. I always want the answer uh to should we keep continue to invest in Wagtail to be a heck yeah or resounding yes. Um but it's really hard to say why, right?

Speaker 2: It's in other than the open source stuff and the community um and it just being a solid platform, it's really hard to look at someone's website and say, This is good, you should keep going with it, or here are the few places that you should make changes and it'll be great. Um, or you know, whatever. It's it's hard to objectively review something as complex as a CMS. The problem is that you can build a really good Wagtail website or you can build a really painful one. Just like any tool, if you use it wrong or if you set it up incorrectly, you're gonna have problems. Um and most people don't abandon technology, they abandon poor experiences. So Wag Wagtail is great, super you know, super user friendly um and uh allows a lot of flexibility and power. Um if you know over time it's not taken care of, people are gonna Grumble and they're gonna complain about Wagtail.

Speaker 2: And uh again, they're not gonna know what's working for them, what's not working for them, what's good, what's bad. A lot of a lot of software decisions are made around perception. It matters a lot what people think about the technology and what it's doing for them, not necessarily always reality. So I'm trying to figure out how to judge a CMS if it's good or not, so I can tell people, yeah, let's keep going, right? Um and this is a big topic I've been working on for um many, many years and has many facts to it. And if it's something that you're interested in, I'd love to talk about it. But I'm I'm kind of similar around these four things. A good CMS may be defined by how coherent Confident, resilient, and trustworthy it feels to editors and platform owners. Again, a lot of metrics and other things support that. I'm not going to get overly technical with some of this talk, but these are the four key areas that I try to I try to focus on, and I'll show you what they mean.

Speaker 2: The first one, coherence, is essentially content modeling. Coherence in Wagtail is this idea that everything just sort of clicks when you start working with the CMS. You know a CMS is coherent when you don't have to stop and think, where does this live? Um, why is this called that? Um why is this a little bit weird? Um coherence is when a CMS feels natural. And you don't need a whole bunch of documentation to understand it, but but maybe it just sort of just gets your feet wet and get started, or maybe it's you're new to the organization, or maybe you need some explanation for why things are the way they are But it it's light. It should just be one of those things where you can just pick it up and and and get moving. A coherent CMS is gonna be one that uses the same language

Speaker 2: and nouns and verbs that the organization uses. Again, content should be easy to find. It should be predictable. It should just it should feel comfortable, right? Let's show an example of that. I built a lot of university websites. This is a pretty standard uh pretty standard setup for us where uh you know there's a department page, a program page, courses. Courses are tagged with instructors. Instructors are probably a snippet. Courses maybe have a subject area or a subtopic or something like that. Notice the naming of this. I'm saying department page, program page, course page, instructor, subject area. This is a coherent structure. The teams that I'm working with at universities understand this. This is the language that they're using. This is a well-modeled system. It works for them. They can understand this hierarchy.

Speaker 2: This is a system that I we've moved away from that I I have seen and had to migrate from where somebody set up a generic top level page. They have a section or a first level page that always has a big hero and a certain fixed elements, and then they have a listing page which is really just aggregating all the sub pages. Instead of having instructors, they have a generic person block because they anticipated being able to show anybody on the page. Uh could be a student, could be faculty, could be the JR. Um, but not a lot of structure here, right? Like you're not using the nouns and verbs that the team uses If you're coming into the system, you're going to immediately have to map uh what you understand about the the organization and how it works into the CMS. There's too much thinking involved. You can't just pick it up and start working with it. You're going to have to learn the CMS first. So when I'm looking at whether or not a system is is

Speaker 2: good or you know I'm trying to tell somebody to continue to working with it, I'm I'm looking at uh uh how it's modeled. So content modeling is a is a key thing for a good CMS. This also extends to blocks. Um this is a pretty basic example of a super composable page with loose block definitions. Hero block, announcement block. This is maybe a two-column block. It takes media, rich text. Perhaps you're you're instead of pulling in the news, you're just It's just a list and you're just linking out. Um because you're trying to be super generic, right? Um a card grid takes cards You're you're taking the cards and designing them like courses and maybe you have instructor blocks, maybe because that's the one thing that you didn't anticipate. This can lead to stream-filled soup. You'll notice on the left that I have

Speaker 2: that that structure that I was talking about. But any um if it's if it's overly composable and you can move things around too much and you lose the semantic meaning of the page. You can put courses at the top, totally throw off the accessibility of your page, mess everything all up. So again, this is not modeling the real world. This is something that has to be learned to pick up and get moving with. Here's an example of the program page that I was just picking on. In this scenario, maybe our hero is strictly defined. It's a page type. So we're asking for very specific hero fields. We maybe we allow announcement block because it's an optional thing. our two column block takes media as still as it as it did before and then uh maybe it's the news block is something that actually pulls from blog uh the blog app and it it's gonna it's gonna pull in any post that is tagged I don't know with this particular program

Speaker 2: We'll have tagged courses, so maybe they'll pull from a model or sub pages, and then we'll have tagged instructors. And this could all just be one simple page type, and there's really only a little bit of composability to it. Maybe these aren't really even blocks. Maybe this is just something that you drop a program page in and it all just sort of populates and works. Nobody has to think too much about it. It just works, matches the mental models that work with the team. All right, so when you're trying to decide if your uh app is coherent, your CMS is coherent, a couple questions to keep in mind. Again, does the CMS reflect how the organization actually thinks and works? Can editors easily describe what content what a content type is for and use them consistently? Um a lot of times I'll inherit a CMS where there's a bunch of types, but nobody can really tell me what they for because what they're for because they've been abused So if they're using a layout where they they uh

Speaker 2: maybe didn't intend to use it or they're putting content into a layout that doesn't make sense. The relationships, are they all clear? Um Is the taxonomy grounded in real organizational concepts or is it something that just sort of supports the developers? Um do you have snippets that are um actually using the nouns and verbs or the the nouns that the organization uses or are they uh uh technology specific um or tied too closely to the CMS. Um can someone new to the team basically figure out how to do things without an extensive training manual? Wagtail's great because it has really good editorial docs. But again, you should be able to come into the CMS and add a blog post without having to read a manual, I would think. All right, confidence. The effect of trust. Um, what is confidence in in Wagtail or in any sort sort of CMS?

Speaker 2: Um Confidence is how a CMS feels in daily use. It's knowing when you can do something versus knowing it will always work. It's fields being clear, it's the editor's trust in the system, it's being able to come into the CMS and Easily kind of figure out what will happen if you make a change. It's preventing catastrophic errors. It's it's you know if you delete this, this page will break. Or here's a little bit of help text that lets you know that this thing is required for this page to work It's you know ensuring ordering in your stream fields if that's important. Um it's consistency in the micro patterns. I think if you saw Mariana's talk just a minute ago, you might have seen that they were, you know, she was breaking down buttons. The way you build a button in one spot should be the same everywhere. Um it's it's knowing that you can publish and deploy, so even for developers, and it's it's not going to go catastrophic

Speaker 2: and break. Um, you know, I I And you hear a lot of CMSs where people are afraid to touch things. It's accurate preview. So if you're using something like a headless system, actually tying that in so you still have a working preview. Um some Some preview functionality gets kind of hidden depending on complexity. And it's really obvious to make edits. It's it's you're you're not hunting and pecking to figure out how to actually use the system. So it's yeah, I guess it's more of a if I had to say it it's it's kind of a vibe. You feel good about using this system because you can easily pick it up. Here's a quick example. If you were building a card, here's an example of a well-made form of predictable field ordering. This is a very simple card where you're adding your tag items across the top. We're allowing three. It's very clear what you can do. You're not going to be able to add 10. It sets the tone right away that this is going to be a very simple component.

Speaker 2: My headline takes text. Uh maybe it's rich text. I actually know this is a feature. If I remember correctly, uh you've you've uh the Wagtail team is gonna allow rich text editing within uh single-line inputs, I believe. Don't quote me on that. I think I remember hearing that at DjangoCon. That'll be a really cool feature But basically uh the idea here is is that I have limited capability to edit my headline text. I can't within my headline inject an H5 or an H4 or a table. Right, like right off the bat, I'm being told limit this to one to five words, super short. I have very limited controls. Um, rich text has a little bit more uh functionality, but I can't add images here, for example. And then I have some dynamic uh actions that I can add limited to. Super clear. The form fields match the card. This isn't out of order.

Speaker 2: I can come in and just easily grok it and kind of get an understand for how it's going to shake out. An example, if you've seen any of my other talks, you've probably seen this this particular view. And I pick on this example a lot, but this is one of those examples where um You know, uh we're not instilling confidence because we're allowing uh an editor to do something that doesn't make any sense. Um in this case there's an about us page. I can add a sub about us page, another about page. a careers page, a careers page, a career careers page, a careers page, a contact country donate page. This this is messy. This isn't a good guardrail. This is allowing me to mess up my taxonomy and stick templates and page types just kind of anywhere So this is this is the type of thing that's going to shake confidence in being able to use this system because you're not necessarily going to know what is an about

Speaker 2: page nested in an about page look like. Yeah, these little things add up to make things weird. Um speaking of the micro patterns, um you know, I I think I'd mentioned if you have um a button Um this is a hard coded button and a template. Uh we have a very cons you know, uh this particular um instance, um this CMS site. We have a custom link component that can be styled like a button, but the fields are always the same. A button always takes a label or a link always takes a label URL or a page a new window. you may have a different widget for this. But the idea is that these micro patterns throughout the site are all consistent. This level of care is something that we look for in our CMSs because this means that somebody designed the CMS with intention

Speaker 2: Which is a s an indicator towards it, you know, having some love and care and it's it's probably in better shape than the average CMS. The other thing you can do with restriction is oop. Keep doing that. The other thing you can do with restrictions is restrict your blocks. Folks probably know this that if you're building out something like an accordion, you can add an accordion item and then you can restrict the content that goes into an accordion. I feel confident building an accord accordion because I'm not going to be able to shove an accordion into an accordion or a hero into an accordion. That kind of thing. You have to set users up for success so that they can feel confident. All right. If you're going through your system and you're trying to figure out if editors feel confident, you can talk to them. And and just get their feedback and and see what they feel.

Speaker 2: One of the things that I've seen with people moving from one CMS to another is that they're almost always apologizing for the old CMS I'm so sorry that this is a mess. This is going to be a nightmare for you to rebuild. It's not, Wagtail makes a lot of stuff really easy, which is really great. Um, but do the editors trust the CMS to tell the truth about what's live? You'd be surprised how many systems don't actually do that. It's hard to tell if something has been published or not or if it's even being used on the site. WagTel gives us really good references for that. Our actions interfaces consist across content types. That's that button example. Um does the CMS work to prevent errors and promote good is good design? That's that's a the big topic, but basically are we are we setting people up to um create things that make sense? Um did anybody put thought into to guiding the user towards success?

Speaker 2: Does the CMS communicate when something goes wrong? You'd be surprised how many times I see in a CMS where you can build something that's horrifically ugly or break something and you don't actually know that it's broken. You just stumble across to a random page and see that something snapped because of a change made in a completely unrelated area. And our editors uh safe to experiment draft without breaking live content. Again, Wagtail gives us a lot of that. Experimentation is really interesting. If you go into a lot of established CMSs, you're going to see a lot of test pages in draft mode. Occasionally those get published and they end up inside site trees or whatever else. So yeah, what are the guardrails that help help users actually be successful? Um and if there are any or not is a good thing to check for. All right, resiliency. Bending, not breaking.

Speaker 2: Resiliency in Wagtail is uh can this can the system essentially uh survive a redesign? Can it survive a traffic spike? Is there any load bearing content? If you delete something, if you delete a key snippet, is it going to cause the homepage to to break You know, is there modularity in your page tree structure? An example I came across recently was setting up a generic page type and then inheriting from that and creating other page type or blog uh a blog type and then inheriting uh that and creating other blog types um as opposed to copying and pasting the blog model around the site as needed. Do you have appropriate test coverage? Um a lot of people don't I've talked to a lot of folks who uh think

Speaker 2: that uh CMS that has a lot of composability and a lot of uh struck blocks needs uh a test for every single one of those. I think a lot of um appropriate test coverage for CMS is Testing your dynamic views, your list views, anything that is more app-like. Um I don't know that you need to to write a test for if you're hero in your feature block. look right side by side. Um uh one of the things that I've seen that's worked really well is if I've if you have onion skinning or I'm sorry um screenshot testing. So if you're able to hit a page that's been built out and then test it against a prior version or another version. And just look for regressions either in the design system or broken blocks or something like that. But um yeah, are you going nuts with the the testing or is it just enough to kind of get the gist across? Again, exploring experimentation.

Speaker 2: Feature flags is something I don't use that often, but I've seen them really helpful on big projects. I've seen feature flags down to the block level, so experimental blocks even, that's kind of cool. Um avoiding snippet hell, uh which I'll get to in a minute, but basically having snippets that are flexible enough, at least the ones that are, you know, with regards to content, flexible enough to be used in different areas and not having hundreds of snippets that just do one very specific thing. And then balance composability is a is a big one. Basically If you've seen any of my other talks or and back to my earlier point, you're you're gonna want to model content correctly. One of the things that you're gonna look for is a is a clean content model, but you're also gonna want to see that editors have some flexibility, some some

Speaker 2: reasonable flexibility within some some rules. A site that is too rigid isn't going to be resilient. A site that is has no definitions and has no opinions. is also not going to be resilient because you're going to lose a meaning along the way. And that means it's probably too closely tied to your design. Quick example of snippet hell. This is a very limited example I've seen worse, but I have an embedded form widget. I also have a form. I have 109 forms, but I also have this these eight embedded form widgets. So somewhere along the line, we forked our form snippet. And I uh I I I They're both essentially just embeds, but um there's really no rhyme or reason to this.

Speaker 2: Um you can also see that the homepage, uh we have a snippet to override the homepage as opposed to actually editing the homepage. Um not really sure why this site is the way this is, but there's a lot of snippets here that are either have one specific job and there's really just one snippet. Um or they are forks of snippets. If I were to scroll down, you'd see a bunch of forks of snippets that are very similar, just like the forms at the top. Um but no one really knows why that happened or where they are or what's going on with them. Um nobody went back and and put in any care. So if they had maybe a um slightly more generic form model or if the homepage had been a little bit more thought out, these first three snippets would make a bit more sense.

Speaker 2: Um speaking of reusable content, um, one of the patterns my team has used a lot to get around um snippet hell is um The idea of a generic snippet. I don't know if this is an anti-pattern yet or not, but you're almost always going to have somebody saying, I have a block of content that I need to be able to shove just about anywhere. So it's not a super structured snippet. It could just be a disclaimer. It could be an ad. It could be a one-time ad. It could be something that exists in the footers or pages. But we've been we've been allowing this reusable snippet. Concept on certain sites with some success. But we don't let anybody go nuts with it. There's still a lot of restrictions. You can't just shove an entire page's worth of snippets or entire pages worth of struct blocks into the stream field that it allows.

Speaker 2: moderate flexibility. And then what we'll do is is if we see that this is getting used a lot, we'll go back and refactor down and talk with the team about, okay, seems like you're injecting this one thing everywhere. Let's make that a formal snippet. All right, questions to ask for resiliency. Um can new reasonable features be implemented without major architecture changes? Can your CMS evolve without you having to rethink everything? Are content structures and design systems decoupled enough to change independently? How closely tied is the design to the CMS? If the CMS is dependent upon the design, that's not resilient at all. Does the architecture prevent the CMS from serving its intended traffic? Sometimes you can relationship your way into a mess. And can the CMS, can CMS editors

Speaker 2: recover quickly from errors? You know, if they they do hit a problem, can they make a quick change? Is it really clear? Again, this is also part of confidence, but um sometimes they're gonna make a mistake for botch a page. Bigtail is really good about allowing you to revert. So some CMSs are not. All right, last category or last trait I should say, trustworthiness. Trustworthiness feels a little bit like confidence, but trustworthiness is uh what happens when editors and developers don't have to second guess the system. So simple changes work, every preview works, publishing works, saving works, um, it all works how you would expect. There's consistency over time. It's an accumulation of your system making sense, so being coherent. It's an accumulation of that.

Speaker 2: People feeling confident, and then it's standing up to stress. Don't bring it down. If confidence is the perception of the system and its ease of use, trustworthiness is its reputation, I would say, and the objective reality. You can have a system that people understand think they know how to use. It isn't completely falling over, but there's still gremlins in it. Or the technology is like kind of aging and no one's really supporting it. So you might not entirely trust its future, even though it's kind of working. So um trustworthiness makes confidence sustainable, I think. A CMS is trustworthy when you can create on-brand experiences with it. You know that you can put something into it and the output's gonna be really, really good.

Speaker 2: And that and and to that point that also means accessibility and also it means being able to hit marketing and SEO um SEO goals, right? Like it's giving you good output. It's allowing you to achieve your goals and and you're you're not Going off brand and it's not messy. It's just it's doing good work. It's just showing up, right? Um, there's realistic permissions. Um, the permission systems, um Make sense to everybody, they actually do promote security and they allow sensible editing. You're not fighting with them. You're not trying to I don't know, override them. Same thing with governance. The workflows actually get used, but they're not of you know not avoided. People aren't skipping the workflow because it's getting in the way. It's reflective of how the organization works. It's not falling down. The CMS

Speaker 2: enables intended uptime. So that's good cache architecture, good load, optimized pages, that kind of thing. It's all this over long-term over a long term. And then lastly , you can roll back changes and recover from errors. So again, a system is something that just works well. All right. Wagtail, one of the reasons why I love Wagtail is that and I don't know if this is something that the Wagtail folks are setting out to do, but um everything that I have seen. is pushing Wagtail users to create trustworthy, solid CMS websites. It's down to little things like the accessibility checker, which works so well that I had to struggle to find a site that I have that has broken accessibility.

Speaker 2: This is actually on my own profile and on the LincolnLoup. com website. I have no idea, you know, I think the email link is just trying to stop uh spam bots from finding my email, but like this works really well because it's You know, this is just baked in and we get this for free pretty much, so thank you very much. But it's it's it's allowing my teams and other teams to build accessible websites. We have this great information bar where I can see uh you know I can see the entire page structure. Um I can I know how much how many words there are in the reading time of a page. This is this helps people build trust. And one of the reasons why I call this out is I've I've met a lot of teams who don't know this stuff exists Um so or they they can't find it. And I think if if more people knew about these features within Wagtail, um

Speaker 2: they would start to see the the ethos and and and and the work that the team is doing. Um it's this is a little bit of a training thing. I think that's most people just don't click those icons, but when I point them out, they're like, oh wow, that's that's really cool. This you're you're you're helping me build a good thing here. Same thing with revision history. Being able you can see Mariana , saw this from the Lincoln Loop website. Um you can see activity on the website and revert back. That's a really cool feature that enables trust. If I make a mistake, I can go in and I can I can fix it and this just works. It's not going to break the entire site. All right. So questions to see if your CMS is trustworthy. Does the CMS consistently do what it says it's going to do? Has the CMS earned a track record of reliability through change? Uh you know, it I think some of that is just earned through time.

Speaker 2: If you if you've been able to make changes over the years and and consistently come in and update the website, it's not falling down. Um it's it's probably meets that meets that mark. Um does the CMS communicate honestly and transparently? A lot of CMS uh help text isn't uh all that great. And then the rules, permissions, a workflow enforced consistently over time. So are the guardrails and governance that you're trying to put into the CMS, are they respected? Or are people just sort of bucking those and going cowboy style? All right, I think that's it. I'm out of time. Thank you very much. Would love to talk with you about this topic. If you have any thoughts or opinions, please let me know.

Speaker 1: Hey everyone, I think we have time for one, maybe two quick questions. So if you want to throw a question either in the Q<unk>A section or in the chat, we can definitely take some time for that. All right. I think I see a question from Casey. I didn't follow the reusable content struct block. What happens when you click on that? Do you get a drop-down that lets you pick from a list of content that is maintained elsewhere?

Speaker 2: We have a reusable content snippet. That name is being workshopped as of this morning, but basically it's a it's a generic snippet. uh that would allow you to inject anything within that snippet. And it's it it comes up a lot because there is um there's always going to be a sort of one off case. And it's one of those situations where you need a little bit of governance, like I said. So yeah, in that particular particular situation, you're you're selecting a very specific type of snippet that just happens to allow a subset of struct blocks.

Speaker 1: All right, and this is going to be the last question because I know this topic will take us out. Luis is asking, where do you draw the line of what's too much flexibility?

Speaker 2: Yeah. Um I I tend to not like systems that are super composable that are incredibly composable. Start with a base set of types. Um, but allow composability within those types. So um I'm happy to speak more about this. Um even had a lot of talk about it recently, but If you were to build that program page, parts of that are going to be fixed because they're part of the design. But you're going to probably allow some flexibility, some composability within blocks or around blocks, maybe at the bottom of the page, in the middle of the page. something along those lines. Um I haven't seen fully composable systems hold up very well and super rigid systems almost always get thrown out. So I can't give you a number like 55-60%. It's just one of those things where if it's tied to the layout, maybe keep it defined.

Speaker 2: But someone's always going to want to like stick an ad or a card block in the middle of the page randomly.

Speaker 1: All right, everybody. I think that's all the time that we have. Thank you so much for being here and thank you, Michael, for speaking today.

Speaker 2: Yeah. Thank you. Take care.