Building a Wagtail CMS Experience that Editors Love with Michael Trythall

Speaker 1: Thanks everybody. I'm really happy to be following uh hot dogs and uh cheesecake after this meeting. So if you're looking for a lullaby, I'll do my best to get you there. This is going to be more of a process oriented talk. So if you're here for um whiz bang exciting code samples. You'll be falling asleep. So this is yeah, building a Wagtail CMS experience that uh editors love. Um Thank you for the DjangoCon community for having me here again. I was telling my partners the other day that I think my first talk ever was at in Prague at a DjangoCon, a EurojangoCon or some time a long time ago. And I was talking about creating a better admin experience at the time.

Speaker 1: The admin hasn't changed very much, but I'm still sort of I don't know if I need to start talking about CMS as an AI or something new, but I've been stuck on this topic for a really long time. So yeah, just just thanks for the opportunity over all this all this years. So again, I'm uh I'm Mike. Um I'm the director of strategy of Linkin Loop. Um anyway, so so we're a Python and Django web consultancy. We've been around since 2007. Prior to working at uh Link and Loop, well as a director of strategy, it's my job to work with clients going from I got an idea, I got a big problem How do I build a plan? How do I get to the next step? So a lot of that is understanding requirements, understanding needs, talking to people, shaping plans, building teams, and then setting them off to the races.

Speaker 1: Prior to working at Django or uh at Lincoln Loop, getting my wires mixed there. Um prior to working at Lincoln Loop, I built a lot of content managed websites because there used to be a point in time on the web where about the most exciting thing you could do is make a blog. That's all technology would really let us do. So um you know and and Django has its roots in publishing. So Just kind of been in this space for a while. As such, I've been able to work with some really cool brands and some big projects over the year. I see some clients in the in the audience here. Um a lot of the problems that we're solving are in the I have a billion users a year type of problems or a hundred, you know, a million users a month or I have hundreds to a thousand editors or I have a design system with eighty components.

Speaker 1: And then on the other side it it it balances out with smaller projects, just small nonprofit websites small SaaS projects, that sort of thing. But content platforms are something that I think that we have done a lot of and it's been for some pretty cool companies. W the point of this talk and the reason why I've been bouncing around this topic for such a long time is because all of these people, all of these these customers of ours had an issue with their CMS at one point in time and they came to us to help fix it. And it's our job to sort of understand what the themes are on CMSs and understand the problems that these folks are hitting so that we can better serve them. And I I thought a lot about how to approach this talk today and I kind of boiled it down to a few things. People abandon their CMSs

Speaker 1: and they call up someone like us or Torchbox or RevSys or one of the other folks that work with CMSs in the Django space or any other agency and they say I need help because at some point in time their CMS platform becomes too hard. And too expensive to maintain. Um and it could be any number of things. It could be there's one person who knows all the secret sauce that how to make the thing work and they're on vacation and an opportunity was missed and that was expensive or the developers are now charging more money or this thing is harvest support. The point of the matter is is that they get grumpy, they don't always know why they're grumpy and they need to migrate. And that's a fascinating problem because Some of these clients of ours have invested 500, a million, two million dollars, millions of dollars over years to have a platform. And then one day someone someone comes along and says it's time to move.

Speaker 1: We're done. We're done with WordPress. We're done with Drupal. Let's move to something else. But the problem is that it's not always the underlying technology that's the problem. But when you talk to people, you see some trends. Editors and the people using the systems can't do the basic stuff that they want to do. They can't make basic changes. They can't do things they consider to be very simple. And they can't find what they need. The solution is to design these systems like any system with intention and consistency, like you would with any sort of information or any sort of architecture. And I think the problem that we've seen over the years is a lot of people run into content management projects thinking it can't be that hard. I'm not building some real-time chat experience or some chat GPT-powered AI

Speaker 1: whizbang piece of technology. It's just content. And they haphazardly go through trying to just slap things together until pages are built and editors aren't screaming at them anymore. The thing that they're lacking is content modeling. Content modeling is the process of, and I won't read the screen per se, but it's the process of organizing and structuring content to make it easy to create and distribute. That's really all it is. I think everybody here probably knows what content is, but it's just that it's it's thinking through how it's all going to come together, just like any type of architecture. The content modeling process is very much a design process. This looks like a this is a very standard product development, I guess loop you could say. Content modeling fits in the research and ideation steps.

Speaker 1: There are some benefits to doing content modeling and modeling content just like any sort of system architecture. Thinking through the problem and how it's all going to come together helps shape requirements and scope. It allows you the opportunity to standardize your terminology and it which affords you some efficiencies. If we're all talking about the same thing, the same you know, this using the same terms. calling everything by the same names and we can all just go to the same page about how what the system means and we can start looking at how to streamline language. As we explore requirements and scope, we can start working on our roadmap and figuring out what is done look like. It allows us to take a step back if you're migrating, for example, and examine any kind of legacy thinking. We need to come up with a new system. What were the problems that got us here? What's broken about the current system?

Speaker 1: A lot of times you're gonna find organizational issues when you do that. Builds a core understanding of the project, gets everyone on the same page, and just like any kind of documentation, documenting your your content model just like you would do your system architecture is just good practice. It allows you to build a system with intention. The first step in any design process is to develop a shared understanding, so a mental model, if you will. And that the shortcut to that is to talk to the actual people using the system. So editors, writers, designers, translators, the people that are actually managing content. If you don't know where to start with interviewing them, ask them what they're grumpy about. We always say give us your list of woes. It could be in writing, it could be on a call. Give me everything that's that's making you mad. What's hard about publishing content right now?

Speaker 1: What's hard about writing content? Where does the content come from? Why uh why does it take Sally so long to give you approval on your copy? Let's figure all that stuff out, right? Start with editorial workflow and function if you need a little bit of help. Like say again, talk me through everything on your own terms, outside of anyone else, do your own research on, you know, look through Google Analytics. maybe monitor some users, get a sense for how people are using the site or interacting with content in any medium and figure out what's important. Think about what of your content needs to be syndicated, what needs to be pushed outside of your system. Maybe that's data, not necessarily content, or maybe it needs to be content that is structured in a way that can easily be transformed into JSON or some other format.

Speaker 1: If you are a developer, you're probably working with a design team, maybe someone is doing information architecture, look at what their plans are as well too. The point is is do the homework. Start with homework. Don't just dive in and start building pages because you're trying to fix a ticket. And I would say capture all your findings. When you're building anything that's abstract, being able to put it into writing or visualize it in some way, which I'll show in a minute, is really powerful. What to look for when you're doing a little bit of research? Look for the important nouns that power the key metrics. So our product page is the most important thing. Do people hit the home page and just leave? Are data visualizations heavy in your app? What are the important nouns that people care about?

Speaker 1: What's the stuff that someone has a job title attached to? Look for shared categorization and tags. A lot of sites have hidden taxonomy that people don't realize is actually there. A lot of times things are maybe sort of organized, but it's not always clear. and an organization structure hasn't been followed. So you're going to want to port that or at least sort of carry those mental models over. Look for any content that's masking as a uh as configuration or vice versa. If somebody makes a change one part of the site and it breaks something somewhere else, it's configuration. That sort of stuff can you probably want to decouple that in a future build. Obviously keep an eye out for anything reusable. Wagtail has snippets, it's a good thing to keep track of there.

Speaker 1: And then look for anything that is data-driven. or isn't going to be so much content driven or is going to be consisting of many object types. So home pages a lot of times will feature many many different types of objects. That's a very important dependency. How that relationship works is kind of important. How it gets built is kind of important. And look for pages and and in parts of a content of experience that have a lot of variation. We'll get to more of that in a minute. Once you have sort of a mental model and this is still in someone's head at this point, just take a stab at trying to map things out. You've built models in Django, I'm sure it's it's kind of that process, and there's some ways I can show you that to do this, but it's it's just the process of getting something just written down.

Speaker 1: Write all the types that you can find. Try to get them down to their most basic level. Don't let anyone tell you, well, I absolutely have to have this if it's not absolutely critical. Fight scope creep early on if you can Again, consider the relationships between things. What happens if something breaks? What happens if something is missing? Does an entire workflow bomb? That's going to be something you're going to want to think about in your CMS. And consider types that aren't site tree dependent because they're probably data. At this point, if you're working with Wagtail, you're probably thinking about models, pages, and snippets. Wagtail gives us some really awesome tools for organizing content. These are the three basic ones, models or traditional Django models that have been pulled up into the system that you can interact with. Pages are uh primarily content driven and site tree driven.

Speaker 1: Um they usually have a clear hierarchy. You're building out a site map or site tree. Um their contents um Contents can vary, not carry. Their content is more likely to evolve than models. The attributes are more likely to evolve than what you'd have in models. So models are giving you more structured data. Snippets are reusable. I think for a long time, and the Wagtail team may yell at me for this, but I think for a long time snippets were a a good way to to shove models into Wagtail. And that has since changed. You folks have evolved that, which is absolutely awesome. We now have a very clear system for what should be reusable content, what should be defining architecture, and what should just be random one-off, you know, maybe structured page content. So I think that model actually kind of completes Wagtail for me personally.

Speaker 1: So good job there. I like to start visualizing things. I'm an ex-designer, still sort of a designer. And I have found that drawing pictures is a lot easier than like a lot of hand signals and drawing and shaking stuff around on video calls So whiteboarding can work, but any any sort of situation where you could take those types and start grouping them together and start building some kind of loose relationship this is me trying to mimic uh what I would have with sticky notes at my house. But I'm trying to find relationships between content types and trying to see if content types can be stored in apps versus just put into the site tree. I'm trying to figure out what has to be protected with permissions. A good example in this scenario, it might be kind of hard to see

Speaker 1: if you have a store. Store is probably maybe only accessible. Those objects are probably only accessible to certain users in your organization, right? But publishing might be restricted to just blog authors or something like that. But it's good to just kind of get a lay of the land If you want to go low-tech, you can move into Markdown or some other low-key format, YAML, anything, even if you want to do Django models, whatever. I like to go through and just start out writing out. the different attributes tied to the type names and start to do some some low-level organization of how I'm going to lay things out in the CMS. As you can see I'm calling out the promo tab, I have a content section content section, and then a secondary section for an article And there's a schema override and a bunch of different little notes in here about how this may come together.

Speaker 1: Some folks, some teams benefit from actually visualizing the relationships. This probably looks familiar if you've ever done any sort of system architecture or looked at a map of a database. Have this in your back pocket. Some teams, if you make the big bucks, like to do uh spreadsheets. Um the one benefit to a spreadsheet is that just about everybody can contribute. So if you have to do some modeling in a spreadsheet, it's I don't I don't know what it is. I don't know what it is about spreadsheets, but like people can get in and they they feel a little bit more inclined to tinker and make changes and comment versus if you're inviting them to Figma or something like that. that. So if I'm working with a much larger team that's a much more structured, is living in Google Docs or or Microsoft 360 or whatever that nonsense is called these days. I'll move to a spreadsheet because that's just their

Speaker 1: that's their tool, right? That's what they use. Um don't love this because it's hard to move stuff around, but it's there One of the things you'll want to do is when you start thinking about what's actually a page, you might want to start looking at layouts and mapping out the components on a page. You're going to see this design a little bit throughout this. this talk. But you can start kind of laying out bits and pieces like you know this this is a hero, this is a brand, this is this thing, this is how I'm gonna build that thing. You can see I'm calling out case studies, testimonials, or snippets. I'm using section columns twice. Section columns can accept feature card or product card. A lot of ways to build that model. But again, visualizing this is getting it out of your head and being able to say, see what I mean? Lastly, our team has

Speaker 1: recently adopted a model where we're taking screenshots of individual components and we're actually mocking up because I have a very quick designer. We're mocking up the actual fields as how they would look in Wagtail. We have a little bit of a component library. There's nothing special about this little component library off to the right. It's any Figma-based component library you get off the shelf. You can just Just drag and drop some items in, you'll have forms. That's kind of what it is, right? But what we're able to do is show, hey, if you there's gonna be a button and you're gonna click it and you're gonna get these options. This is going to be rich text. We have different types of rich text. We have robust rich text. We have a little bit of rich text that goes on a heading, because a heading only allows you to do like maybe bold and italics and subscript and superscript. So yeah, we we kind of map it out a little bit more visually.

Speaker 1: You can go into one file and just kind of move around a map and just get a feel for how things are shaken out. And the reason this is important is because again, you get to have that see what I mean thing. Everybody gets on the same page, but this is, you can start looking at You know, how are we adding children to certain objects? How are objects cobbled together? How, you know, what language are we using across the board? Are we calling it an action, a call to action or CTA? What is editorial using? Those little things add up in an experience when they're not in alignment. But you don't have uniformity and consistence across the user experience It just starts to feel bad. And that's one of those subconscious things that's gonna creep up with everybody when people start going, yeah, Wagtail kind of sucks. It's not Wagtail, it's somebody just didn't take a little bit of time and effort to stink through the architecture

Speaker 1: All right, so applying some of this stuff in the wagtail. Now this is the part of the talk where I throw a bunch of stuff out there and I try to condense like 15 years of of knowledge and experience down into a bunch of examples. So it's gonna get a little messy. This might wake you up if you're in that food comb. All right, so we are form we are we are um completely in the developed side. You now have some sort of a model, you've visualized it, you've gotten some feedback, you've can kicked it around, you went through your research and ideation phases, and you're starting to apply it into the CMS. First things first, define some system principles. So many people skip this step and it's not a very serious heavy step. Everything that we're using has a set of principles. There's the Zen of Wagtail, which is awesome.

Speaker 1: There's design of Python. We have design uh Django design philosophy. If you've used Tailwind CSS, you know it has some opinions about how CSS should be written. You can build something like this for any architecture. And I think once you start thinking about what looks like a good system to you and what are the rules are that you want to follow in a system, you'll find you can carry that to other projects as well. Having a set of principles help you make helps you make decisions. It helps say no. It helps you push back on scope creep. having a set of principles lets new contributors who are new to the project jump in. If you were to start programming Python, you would go through all of the literature and you you kind of get a vibe. Right? If you start with Wagtail, you'd get a vibe. Start messing with Tailwind, you would read the blog and stuff like that, and you would just get a feel for how things shake out.

Speaker 1: If you're working with a team of developers, this is kind of like defining linting for your architecture. Does that make sense? And again, it helps helps with consistency. Some of the examples that we that that I try to follow, and this list is not exhaustive, but this I'll I'll point to some of these in the next few slides. These are some of the ones That when we're building a CMS, I try to keep in mind. And I haven't really written them down everywhere. I don't think everyone on my team knows about all of these, but they come up when I'm giving feedback. The first one is preventing errors. A lot of these are just good user experience as well, too So trying to prevent errors, avoiding letting an editor build something that's gonna be ugly or stupid or break or violate something. Error handling is good, but I'm talking about building relationships between objects. I'm not gonna let you put A pink button on a green background.

Speaker 1: You're gonna break accessibility. That's just not gonna be an option in the CMS. I'm not gonna let you put 15 cards in a row. Little things like that, um, you wouldn't think, but they they add up, right? Like it's it's something that you have to sometimes say. We're not gonna we're gonna put in some some guardrails. Any sort of block-based system, and Wagtail has stream fields, is going to allow you to do some nesting. We don't allow more than four levels of nesting. I I think I want to go to three. I think four might be too much, but there have been situations where I have driven us into a corner and we have to just make an exception. But I I I I don't think any anything you're gonna build, any little individual block on a page needs to be that complex. Limit variability, power optional is an interesting one. I'm basically saying build templates but with some flexibility.

Speaker 1: I'll get into that more in a minute. The second half of this talk is all about really the struggle between structure and flexibility. Respect an editor's time, make it easy to find stuff, make stuff obvious, don't make people hunt for things, don't make them have to decipher your help text to see what you mean. Try to keep things well organized. I don't think it's necessarily even an issue of what's the best organizational structure or which parts of Wagtail are the best to use because you know, 50% or 60% of users did better in this situation. It's just having some intention to it. Thinking about organization, building a mental model and selling that mental model to your team is really all it takes. Avoid surprises. You'd be surprised how many times I've come into a project where

Speaker 1: the fields on the page did not match the ordering on the display. So the fields are just kind of mixed all over the place. It's just little stuff like that that just feels off when you're using it, right? It makes it adds to that this is gross type type of uh situation. And then yeah, consistency. If you're and I'll show some examples of this, but you're gonna be adding lots of bits and pieces to to objects and blocks inside. glagtail. If you're gonna add a button in one context, it should probably be added the same way in the other context. Simple stuff. This is an example of kind of what I was talking about. This screenshot gives me such a headache.

Speaker 1: If you look at this example, we're in Wagtail Duh and you're adding an about us page, or at you're on an about us page trying to figure out the children that it can have. The children that an about us page can have And I'll read this out loud, are the an about page, an about us page, an article page, a board listing, a campaign page, a career post, a careers page, a contact page, a country page, and a donate page. I don't know why you would add an about us page to an about us page as a child. I don't know what the difference between an about page is and an about us page is, but I know why it exists. And some of these other ones do make sort of sense. I would expect board listing to exist or anything about us. That's cool. Not gonna fight you on that one. We won't be that mean. And just as a heads up, this list like scrolls a lot.

Speaker 1: A lot. This is just what I could fit on the screenshot without making everybody mad. So there are no principles here. Nobody said, hey, we're gonna have some rules. You can't create an error. You can't do something stupid. It's just no rules. It's just chaos. I hate it Somewhere along the lines, somebody created an about us page and said, I really like that layout. I want to put that layout in other places. But put content in it that isn't about us. So that's why we have an about page. Again, there's no rule, there's no logic, that doesn't make any sense. It's that that design is someone like the design and then and the the template or the the The experience in the CMS was not flexible enough, so they just copied it. We'll get to that in a minute. Um Yeah, I don't know. This this whole thing is a mess.

Speaker 1: And this is really easy to fix, right? It's really easy in the Wagtail to go and say, you know, this type only allows these types But you see this throughout the whole through through a lot of projects. And unfortunately, I have to say that I have seen some folks who adopted Wagtail. get a bad experience in this department and then are have migrated away from Wagtail. So it's it's not like Wagtail is the magic solution to all problems. It's it's the architecture. You can build a bad architecture or a good architecture in any piece of software. I don't want people leaving Wagtail thinking it's cr it's trash. So we need to fix we need to not do this. So Um that example kind of gets into this concept of composability versus structure, which is really just how flexible is the CMS versus how locked down it is Structure a lot of time is going to mimic how an organization works.

Speaker 1: You're going to have objects that just so happen to tie directly to roles. The concept of composability is being able to build a page or a piece of content out of smaller pieces There are pros and cons than both. You never want to be too far into structure because then you're just locked into how the organization works. If you're too far into composability, you're too locked into how the design looked at the time of creation. Those two things need to change periodically. Designs that are highly flexible appease power users. Every project I've done has a power user who wants to be able to go into CMS and build whatever they want. That's fine. Not everybody needs that that capability. They can be faster to put together. You don't have to go through a design or development team to piece together a new page. If you have all the blocks documented and they work really well.

Speaker 1: Rigid designs are easier for developers to build. If I give you a picture and it has A, B, C on it and you go build it, you're gonna end up back over here eventually, but it'll probably be it'll probably get done really quick. Pages too closely to tie the design are inflexible. That was a situation we just looked at. Too much flexibility loses semantic meaning. So if you're familiar with JSON LD, it's the process of describing your pages by a little bit of JSON. Google loves it. I think robots, chatbots probably love it now. But if I give you a bunch of blocks and you build anything, there's nothing under the hood saying, well, this page is a company page or this page is a user page, just blocks. Right, so um too much flexibility and you you kind of lose the the sight of things. Another downside to um overly flexible designs is that they can be really hard to test and they can be tricky with accessibility

Speaker 1: So if you're building a bunch of blocks and you have an H1 and one block, but that block for some reason is at the bottom of the page because somebody liked the design of it at the bottom of the page. Now your H1 is now at the bottom of the page. You might have a bunch of H2s, H3s, it just throws off the whole order of things. And there's a bunch of other problems that compound when you let people move stuff all over the place. So it's a problem you'll usually have to solve. There's a lot of ways to solve it. But it's just something to take into consideration that you can lose meaning and make things a little bit more challenging Let's look at a couple other examples. This is a page that 's entirely structured. It's one of those pages from that example. I don't know which one it is, but featured video makes sense to me. I like the idea of being able to put sections on a page, but I only get four sections and I can't put anything between them.

Speaker 1: It's kind of weird. If you notice, if I were to open up section two, I have a very rigid structure. I get one button. I can override its URL. I get a background image, I get a foreground, and then text alignment. I can't add a second button. I can't drop a video in where the background image is. So this is the sort of stuff that, you know, someone probably got a design and built it to spec and it looks exactly like this. Well all those quotes from the beginning, they're about this page. People can't align stuff. They can't update images easily. They can't just drop in content where they want to. And it just seems like a wagtail problem and it's not. It's just bad architecture. On the flip side of too much structure is too much flexibility.

Speaker 1: So on the left is my beautiful example with the hero supported by some brands, feature page. So maybe it's, you know, hi, we're Lincoln Loop. Here's who we've worked with. We're smart, Mike is pretty and good at presentations. Then we're backing up with a case study talking about how good I am at presentations. And then uh another testimonial also supporting that. And then three products because apparently we sell products, maybe shirts. In the middle you can see I've moved a few things around, but on the right, it's completely out of whack, right? Testimonious case studies are here is down at the bottom. This is totally possible in a composable system unless you put some rules in. So too much flexibility can be bad. Now, because I just dumped on our on our own website, this is our artificial intelligence page

Speaker 1: with all of our composable blocks. And you can see up to the right, it is a very uh complex group. blocks, right? Is a lot to build this page. And if I were to expand all of these blocks on the left, you'd see a whole bunch of fields and whatever else. This is great. You know why? We're all developers. And we're just trying to figure out what works in Wagtail and we're using our own website, the dog food. I would never ship this to anybody who could not also build it themselves. But it can get really messy if you decide to go full composability. All right, one of the tricky things with going composable or any sort of structure is you're gonna have to break your design down into bits and pieces. So I don't know if you're working with a design system, if you have a team that is uh already done some of this for you, but you're gonna be looking at layouts or or or pages at some point in time and trying to figure out how that maps to the CMS.

Speaker 1: So start with full width stuff. Every Pretty much every website, every content-based website is going to have some large block, and in that block you're going to put stuff. And it's going to either be in a grid or it's just going to lay itself out. So you're going to define some full width components, you're going to define what goes inside those full-width components, and then you're going to figure out what's global and gets sprinkled throughout the site. Anything that's going to be data-based, sorry, data-oriented your models, they probably have very fixed views, or they provide a little bit of modification along the way here and there But primarily focused on pages for this next couple bits. Taking an example from also from our website. This is sort of an ideal state for me. This is about the level of complexity that I've been comfortable with lately. So

Speaker 1: allow somebody to specify a section or a full width block. They get a few fields, maybe title. There's some block level specific attributes. In this case it's columns. They only get two to four. I don't let them have 5, 10, 15, or 1. It wouldn't be a column block if you only had one. I have built sites where, you know you could add a column component inside of a section and that provides a different level of flexibility. But most folks just need to say I I need something with you know the mental model is it's not I want to add a section and then I want to add columns. It's like I need columns Right? That's that's what I've seen from from my little bit of research. And then within that block, I'm allowing in this situation someone to add a feature. So there's probably a feature card, there's probably a couple different cards they can add, but it's not everything

Speaker 1: And then the button, I don't like floating buttons, so that's just it's an action on the section column. Really simple. You know, you're adding, you know, you have this this one one block that takes a few options underneath of it and that's it. You're not having to add a title and then add a grid and then add each item to the grid and select each icon and then it's it's it can be it's too much. You define these little bits and pieces and you say these are the building blocks that you're gonna have. Okay. All right. One of the benefits knocked me off kilter there for a sec. One of the things that I see a lot of times with too much composability is something like cards. where

Speaker 1: this is an example that I got recently where I had a system that had probably half a dozen to almost uh maybe like eight different card types And the conversation came up, do we want to allow people to build their own cards or do we want to have very specific card types? I tend to think that when you get down to this level and you're talking about Uh if you're familiar with Brad Frost's uh atomic design, you've probably heard the term like atoms and I think it's organisms and things like that. There's there's a little bit of a structure here, but um if a tag is the most smallest item that you can have Same thing with the heading level three here in the text. Do you want people to be able to build this from scratch or should you just give them some predefined shapes and let them fill out a few fields? And I would say there's very little or almost no situation where I would give someone so much control that they could custom

Speaker 1: build their own card. And the reason being is there's too much design consideration. that has to get baked into that. Cards, believe it or not, are actually fairly complex. They can be themed, they need to stretch, they need to expand. You can see the three of these aren't even aligned. I don't like that. And this is my own concept that I whipped up. But I I think this is about where you stop with regards to how much flexibility you should add. And I, let's see, one more. Um, a few more slides. So the really cool thing about um Wagtail is that it provides uh This really cool pop-up, you've probably all seen it using Wagtail that lets you specify the the sub blocks that appear and you can search down. I believe the newer Wagtail, you might be able to attach little screenshots to those Which is freaking awesome.

Speaker 1: I love that. But you can actually get a sense for what these these look like. On the left is a is a more robust composable system. Again, more tailored towards a power user. On the right is something that's a bit more slimmed down. There's only a few options that you can do there. And again, how you treat this list is important because it's going to prevent errors, right? You're not going to be able to, in this situation, we're probably filling out this section block. columns if you want to use your imagination. I'm not gonna let you put in a section block there. Alright, quick example of the model that's been working for it for us lately. Typical scenario, I need to build a landing page Landing page has some very unique features on this site. A landing page is always gonna have an intro, it's gonna have a hook, right?

Speaker 1: Let me tell you what's up. And then it's gonna say, let me support that point with three other bullet points. There's my features, right? Everything after that I don't really care about It's as long as I get you to sign up, right? That's that's that's it. That's if if I were to give you an elevator pitch, it'd be it's Uber for dogs and it's cool, it's fast, it's funny. Boom, that's this page you want to buy, right? Um So those things are the defining characteristics of this landing page in this example. Everything that's marked in red is completely composed That's about the level of flexibility that I've it still gives it still gives editors a a a model of a page type with some things that aren't super rigid, but they still have flexibility to move things around. And the reason why you need a little bit of composability here is because the story that you're gonna tell to enforce the intro and the features at the top might change.

Speaker 1: You might not have a testimonial for the thing that you're building a landing page for. There might not be a case study yet. You might have to drop in a video. You might have to drop in a story or, you know, an explanation from the founder or something like that. that. But your pages are going to have some unique bits and pieces that you can start with as a basis. Trying to get into the end here. One of the things that I see that trips people up a lot is in kind of going back to that card example. is thinking through uniformity and how small pieces are created. So we just talked about cards and how cards get made and how they can have variations, but they need a little bit of control. Same thing with links and buttons There's been a lot of times where I've seen and kind of going back to one of those other examples where I showed uh the section two

Speaker 1: and then it was the buttons, uh the you're building a button there. that pattern isn't consistent throughout that's that that site. Sometimes it's button text, sometimes the button fields are a little bit different. The way you build a button, the way you build links, the the way that you do very basic things throughout your site should be consistent. You can port those fields into the model themselves, you can add them as subblocks, but it's it's good to take a step back and think about well I have to do this really common pattern all the time. How am I going to go about doing it? What are the controls I'm going to have for a button in every context? That sort of situation. Icons, another one of those examples. There's some some really good, I think it's Wagtail SVG chooser or icon chooser. Can't remember, but there's a couple different packages that give you some of these stock.

Speaker 1: capabilities out of the gates. Lists are another one. A lot of aspects of web pages are actually just lists. Feature, feature, feature, step one, two, three. How those are organized, how you set those up is something that you'll want to think through and make consistent. A lot of our sites are it's literally just hit the plus button and then build like you would a stream field, right? But you can also get away with other lists. The other way to do lists are I've seen people just bastardize rich text fields and have rich text fields get converted over into something more complex, or they've they they're doing linkage. separating stuff by ID with commas. The way that you you you build sequences of things should all be somewhat similar.

Speaker 1: Same thing with grids. If you are going to allow the ability to build a grid, you'll need to decide if the author has flexibility and control over the grid or if the design system or the design is going to enforce how the grid works So a good example is I have seen scenarios where, and we built these, where someone can say, I want a four-column grid, but I never want it to go two by two. I want it to go four to one and stack. Or I, if I have three, I want the last item just to stretch across the bottom. Where how How you make that configurable can cause a lot of unexpected behavior and design output. So a lot of times I I tend to say just give me the list of things that you want in the grid. And then the design itself will handle the display of the grid and you just sort of have to trust that it's gonna do what's right.

Speaker 1: It can get complicated. This is a screenshot from a design system with just buttons and buttons have all different shapes, sizes. You can spend months building buttons. When you start talking about how they um where they can exist anywhere on a site, the theming with them You can see some of these have two icons left and right. I'm not saying your button would have that, but there's just a different lot of different variations Buttons can get really weird when you start talking about the length of text. There's a lot of rules around buttons. So again, this is one of those examples where it it makes sense to do a little bit of upfront thought about how these little bits and pieces come together in your CMS. Because if you don't nail that, or if you don't at least come up with some rules and some some some principles about how these things should shake out, it's gonna start to feel weird.

Speaker 1: Here's an example, kind of going back to that previous example and then a different one. A very rigid button shape, and then off to the right we have a reusable block for a custom link, which is essentially a button in this situation. And that custom link component kind of lives everywhere. So anytime you have to add a button, you're adding a custom link component or a button component. It's stored in one spot, it's dry. We're not bastardizing the button functionality throughout our website. All right, that's about it. To recap , plan and visualize and validate your content model. Actually, build a content model, just don't jump in and start uh building stuff. Just like any good system architecture, it requires thought and it requires

Speaker 1: iteration and plan with your team. Think about the best practices that you want to try to follow. You may not know those out of the gates, but it might be something to think about or you may start to see patterns or ideas as you start to visualize things You may decide that you know you're gonna keep all help text short and sweet. Um you're not gonna allow a lot of variation in components, you're not gonna give too much we had the whole conversation, the whole thing about flexibility and structure. Get a vibe, get a vibe for how you're gonna build this thing because once they get off the rails, people throw them out. Focus on consistency, consistency of the experience, guide the happy path. And then um like all things, uh don't build it and set it down and forget about it. Like we have we've been really fortunate to have built stuff that has lasted plus ten

Speaker 1: years and it's It's not just because we architected or had the for the opportunity to build it right the first time. It was because we were allowed to continue to iterate on it from a good place. I think our longest running site, I think we built it in 2013. It's been up for three years, three years uptime, and it gets millions of people a month. And something that we're really proud of, but it wouldn't be where it is if we didn't continue to hack on it. So yeah, I don't know. Just your CMS requires architecture and love too. That's all I got. That's a cool robot picture for you. I would love to talk about this. I tried to condense a lot of stuff down into Whatever this was, I got to focus on one aspect of this.

Speaker 1: Um I would be more than happy to talk to you about anything regarding CMSs. Feel free to come up and tell me that I'm wrong. I'm stupid. I'm not actually that attractive or handsome and I'm not good at giving talks or whatever. It's an inside joke. I'm always joking about how like I have to do this. I have to get up. Anyway, the uh oh the last thing I'll say is is Lincoln Loop is hosting a um I guess we have an open bar at uh is it Bone Shaker? Someone want to help me? I missed it.

Speaker 2: Broken Shaker.

Speaker 1: Broken Shaker tonight. Um get a couple drinks on us. Again, you can get a couple drinks and then come tell me that I suck. That's if you need that courage, I will be there. I'm more than happy to have that conversation. Again, I love this topic. I've been talking about it for like 15 years. And our team and one thing I'll say is if you stop by our booth, just about everybody at our booth is in this space. We all have different perspectives. In fact, I had a bunch of conversations earlier with our team where I was like, crap, I wish I had thought of that. So yeah, if you if we want to talk about Wadd Tail or your CMSs, don't feel uh don't be afraid to reach out That's all I got.

Speaker 3: Uh so one of the one of the issues I See when we work on these is uh if you ask somebody how flexible they want their CMS to be, they're gonna tell you they want it to be infinitely flexible. They want to be able to do whatever they want whenever they want. uh but they also want it to help look a certain way and have a certain design. Like how do you kind of coach people through like the fact that they they they're saying they want infinite flexibility, but they they probably wouldn't want that once they had it.

Speaker 1: So I've lost that battle in the past. Um the thing that I've always tried to come back on that's worked for most people is um You don't want your CMS to turn into garbage. You don't want your brand to fall apart from building things that don't convert or don't work well or um Basically, too much flexibility breaks that consistency experience, right? Like what I'm able to do a lot of times is show them a well-made site and say, look at these pages, they flow, there's a structure here, you're actually navigation from X, Y, and Z if I give you too much flexibility or we you know get kind of nuts with it, you're gonna break that for the end user. Like there there is a there is a um an end impact for their audience if they're building something that doesn't follow some rules. And that's the thing.

Speaker 1: Humans look for patterns, right? Like we we we don't really want to be surprised until we want to be surprised. So um being able to point to like you this is gonna look good for your brand. It's gonna give you a good, clean, basic system. And the other thing that you can mention too is like let's let's build it sane now. Let's just follow some rules now and then let's see what power you need later on. And then we'll bake in some of those rules. But let's just start with something and then iterate from there. And if we need more power later, great. But if we start off that way, then there's there's really no architecture to it at all.

Speaker 4: Yeah, I had a question about Wagtail, I guess, a little bit more in the abstract, which is um Does it end up being a good framework for um like a like a a content site where like every use every single user is coming on and adding content? Or is it often more geared toward where there's more of like an administrative sort of side with a sort of limited number of user sort of generated content?

Speaker 1: Sure. So the Wagtail folks are here too, if you want to talk to them. They'll have a different they're probably a very similar opinion to me. But we've used it on some larger websites where we've had a lot of different people doing different things. So I would say at the most basic level, it's a much more user-friendly administrative interface than the Django admin with pages and some basic stuff to manage assets. and do categorization and manage settings. So I guess to answer your question, I've used it on small stuff and I've used it on big stuff and many different types of roles. And it's kind of worked for everybody as long as we put a little bit of thought into it and did some training. I think the problem is, is

Speaker 1: like A lot of the teams we've worked with, they're mental models WordPress or Drupal or one of these other things that they've worked at some other job. Whiteel a lot of times is a very new thing. So it's a little bit of walking through things and showing them the intention of your architecture, why things are the way they are giving them your mental model, selling them on it, and then showing them how it works for them. But yeah, I haven't seen anybody trip up over the interface trying to do manage models or manage pages or ads or whatever else. It's it's held up well enough. And it's just it's well designed. It's got a nice design to it. So I think someone over there maybe?

Speaker 5: That's all the time we've had.

Speaker 1: Feel free to find me in the hallway. Again, or get some drinks and beat me up. I just think that's a very good question.