Pleasant Publishing Patterns

Speaker 1: I would like to go ahead and introduce our next speaker. Michael Tridhall is from Lincoln Loop and will be presenting a talk on pleasant publishing patterns. Take it away, Michael.

Speaker 2: Thanks everybody. Again, I'm Mike. Yep, I work at Lincoln Loops. Lincoln Loop's a Django shop. We've been around since 2007. We do everything from top to bottom. We're full service shop. I'm the director of strategy there. My job first and foremost is to just work with our clients to figure out how to turn what they're trying to do into something on the web. I've been at this a while and everybody know everybody knows that Django has its roots in publishing, so we've done our fair share of CMS sites and content platforms. I work with a lot of people when I'm doing that. A lot of my job is discovering requirements and making sure things are shaped and the team can actually work through development. And one of the user types that I work with is content creators.

Speaker 2: Content creators are power users. They're the people that are in the CMS day to day. They usually have very complex needs, but they don't. Always have a lot of say in the tools that they're using. A lot of times I'm working with folks who are two or three or three or four levels removed from the design and technical decisions that were forced on them They don't always have the flexibility that they need. And as such, I hear a lot of very common and basic complaints. They need to work around the system or against the system. system, their CMS to do what they need to do. They're dropping in raw HTML as opposed to using their design system, for example. They can't do things that they perceive as basic. Sometimes they're coming from WordPress or another system they've been able to drag and drop and build whatever they want.

Speaker 2: Now they're in something that's a bit more structured. So I get common complaints about I can't add a photo and put it where I want it. Or I get a lot of feedback on systems that we're redesigning or inheriting or even things that we've built that things aren't always super intuitive. And that's not that you can't always anticipate. The one that comes to mind is I recently had a project where you were editing the homepage. Homepage had a whole bunch of carousels. Carousels were in snippets, the snippets were actually nested So if you wanted to edit the carousel on the homepage, you had to not edit the homepage. You had to go find this snippet that had a slug that nobody knew about and edit it and just hope it worked. My hope today is that we can discuss a few early considerations and things that I try to keep in mind when I'm working on a new website.

Speaker 2: um that um have helped me create slightly better um content management experiences. A lot of times it boils down to um not a lack of planning, but a lot of times a lot of times uh a developer is getting um a specification. It's already gone through design, marketing, a lot of other people have made decisions for that. So you're getting a site map that you have to sort of figure out how to how to build or you got a bunch of designs that you have to work backwards. So there's a few things that I try to keep in mind early on in projects, some techniques and some things you might go to raise flags about that may help you as you're building out a wide test site. The first of which is content model. Content modeling is the organization of

Speaker 2: the process of organizing instruction content to make it easy to create and distribute. Thank you, ChatGPT. I will not give you an attribute because you are a super robot. So that one uh I'm gonna say uh is is in the public domain. Um but it's true it's um it's it's basically the process of working through content and figuring out how it all fits together. Um you'd be surprised how many times we inherit a system where you can tell somebody Started with something and it got away from them. You start seeing these weird one -off things that don't feel right. You see the model kind of fall apart or you see a page type or a fundamental object, it kind of bolted on because somebody six months later was like, hey, we forgot about this. Okay, let's Let's just slap it in, I guess. You did enough times over three or three years and then you 're contacting Portugal Lincoln for some other company to come and redesign the whole thing top to bottom

Speaker 2: So what's the project what's the process for content modeling? We're going to focus on the first three just because of time. The first step is to gather your requirements, the second step is to define your content types, and then the third is to visualize them. And there's some pretty clear reasons why you would do this. The first of which is that if you have a model, one of the things that I got from my design background is that if you're the person that defines the model or defines the artifact or defines the thing That's the thing everybody has to work against. Right? So if you're coming in and saying here's our basic architecture, you can now say, well, does it fit in this architecture? Or what's wrong with this architecture? and then somebody has to modify and change it and not fight with you, but convince the team of this thing that's in front of them that it's wrong. That's hard to do. It gives you the ability to manage scope and say

Speaker 2: no. It allows you to solidify your terminology. I can't tell you how many projects have come in where we have a product, an item, or we have an article on blog post. And you see that kind of all over the place. So when people are talking or writing documentation or writing labels or doing their design system, those things don't match up. And you just get this weird, gross smell to your project The other thing with your content models that acts as a roadmap, you can say we built X, Y, and Z. We have these other three models to build. It allows you to examine legacy thinking. You can look at I I do it, we we've done some projects lately where I'm moving from WordPress to ragtail I mean absolutely phenomenal wagtail's phenomenal I wouldn't be here if it wasn't um but you know and and some of those systems it's really easy to just bulk on these models and just make a mess

Speaker 2: WordPress isn't always the the biggest thing I see with WordPress sites is that they aren't very well architected and that ends up being the problem. So it's a it's a fresh start to be able to look at everything and say, does what you're what you were doing, does that make any sense at all Alright, so you're on a project, you're starting something brand new, you need to build a content model to keep some sanity and have the ability to fight for your architecture. How you go about gathering requirements. Shortcut, talk to people. You can look at systems all day long, but the easiest thing to do is to go talk to content creators, designers, and people that are working with the system and ask them to walk you through their workflow How do you build content currently? How do you want to build content? What's your ideal system? Let's just talk through it.

Speaker 2: So going through the editorial process with people, the publishing process, usually turns up all the little things they're going to hit along the way. I like to record these conversations. Again, I do a lot of discovery work, so it's a lot of just getting on the phone with people and just trying to figure out what's in their heads. If you're talking technology or going through your workflow, it's really easy to go up on a tangent lose your train of thought, start giggling about something, somebody starts to gripe whatever else and next thing you know you forgot this really good point you had earlier on. When you're building requirements or building any kind of model, it's always good to have something to reference If you're doing a redesign, a big thing that's helped me is asking for a list of woes. What is making you angry? What's getting in your way? What are your biggest pain points? People. If somebody's mad about something and they are grumpy about the system they're using, they'll tell you. They'll tell you what's wrong with it.

Speaker 2: This is messing me up. I can't do this. I wish it was better. I wish it was just like X So if you don't know where to start on how on building a model, it is looking at what is currently there, what problems somebody's having, just saying, tell me what's up. You can also evaluate other data sources. Obviously, you can open analytics, you can find out if there is content that If you're looking on a big website, it could just be as simple as, you know, yes, I know the funnel is this and we're hitting these major navigation paths, but oh I found this weird thing that exists that we can't have a 404 for. So we have to figure out how that works. One of the questions we always ask is are you syndicating content? Is the content and the data that we're producing, the model that we're producing, does it ever leave this system?

Speaker 2: Because that could impact the attributes that you defined. Maybe you have to have something a little bit extra. And then if there are any third-party dependencies, are you pulling in any data that impacts this data in this model? Alright, so defining content types. And a lot of this is if you've done any kind of database architecture and school or work or whatever else, this is similar, but just think about it as your as the core objects that are in your system, not necessarily the pages that you're building just yet. Um I 'm I'm very visual thinker, so um when we start this process, um I will go in and just Stickies on a whiteboard, this is fake jams, best I can do in a remote environment. Um but you can see I'm just doing some very some some basic um classification I'm not everything is singular. It is I'm not talking about design just yet.

Speaker 2: I'm talking about just my core objects. I've got categories, tags, I've got subscriptions. I've got documentation and this is imaginary, but very, very low level, and this is probably enough to get some involvement if you're working with a developer or a marketer or someone else, right? They're probably not going to be able to read your Python model that you've stubbed out, but they should probably read this. As tech lead, I'm often working in Markdown. Because it's really easy for me to copy and paste history and GitHub issues. This works for me. You're making big bucks if you're working in spreadsheets. This is again a fake model, but I've had some of these that are just horribly horribly long and it works for some people. But you know, if I were to scroll right, you'd see 20 other fields here

Speaker 2: That talk about how things are grouped and the validation rules and what happens. Alright, so some tips for defining your types in a CMS system. Focus on the nouns, not web pages. I'll get to that in a minute condense things down. You don't want two types that are too similar, at least in the beginning. If something is going to be displayed on its own, That is a consideration for later. You may be looking at that as a one-page template, or maybe it's not a template at all, or maybe it's a piece of content that is actually or an object that actually appears on the page of another object. Product features come to mind. That's one where you could have a product, you could have features, but really you're not going to have a product feature

Speaker 2: model appear outside of its product page You may in Wagtail have a product page and just plus plus plus all the different features, but if you're doing some kind of weird system where or more complex e-commerce system I could see that getting messy if you have some features like 4K display and you're going in, you have some text related to that, you may end up having that. split out so something to consider. If a type has more than it only has one attribute, it's probably just a tag. You probably don't need a whole object for it. Again, you're trying to keep your initial model really simple. And on-page objects are not content types. So if it is something that is, I don't know, just one thing that appears on a page that doesn't interact with anything else

Speaker 2: and it is decorative. It's not a content. Visualize your model, really simple diagram. I always like to produce something at the end of this process. I had a project recently where we had brought on a new developer and he asked for system architecture documentation , deployment notes, all that other good stuff, and then he wanted to know what the object structure was for the CMS. We didn't have one because we just, you know, super focused on everything, didn't think too much of it. I wish I had had this because it would have onboarded him a little bit easier. And it would have made it um We would have gotten a little we would have been moving a little bit faster with some of the page building. Um there were some instances, there's always instances when you don't define this stuff, and I'll look I'll show you this in a minute.

Speaker 2: There's always instances where you're trying to figure out Am I pulling in this object that currently exists or is this content I'm overriding and duplicating it? Anyway, the point is you need artifacts for a lot of things. Your content model is one of them. Okay, so the content design integration, you have stubbed out the content model, you've got some initial documentation, you've you've paused the team, you've taken a step back. question the site map and you said okay here are the core things I know we need to have here's where everything is going here's the system around it um how do you take the those initial plans and the designs you've been handled, the designs you've been involved in and turn it into a content management system This is where it's going to get a little messy because it's a big topic. I only have so much time.

Speaker 2: But I'll show you some of the things that I kind of keep in mind and try to do at the start. Once you have your content model, you can start looking at a page like this. So this is an example homepage, right? And you can structure this a bit more intelligently. If I were doing this page now, I would say that the top of this section, the top of this page is probably a stream field, and I'm going to have three blocks, a hero block. brand list block, a column block which takes feature blocks, and the bottom are going to actually be types. They're not content, it's data. You're going to go through select a field. Field's going to be select the case study, select the case study to peers, testimonials, and then three spots for products. There's a million ways to do this. If you've worked with Ragtail, this whole thing could be stream fields. And all these different things could be blocks, but the whole thing could be just

Speaker 2: Very hard-coded and we're going to get into that in a minute. But once you have types, you can start actually looking at designs and going, well, how is this going to get built? And what do I already have? And what's going to be reusable? You can't do that until you put some thought into it. Um what one of the things that I think all of its systems have is a philosophy We're familiar with this. We have the Xenobacto, Zen of Python. Django has a design philosophy that was pretty big for me when I came into it. The whole idea of keeping things dry was was awesome when I was a junior and just making a mess of everything A lot of people are familiar with Tailwind's utility first model and the benefits of that. When you're implementing anything that a user is going to touch. You're doing design, right? You're you're designing an experience for them.

Speaker 2: So I think it's worthwhile to take a step back and figure out what are the best practices that I want to follow, what are the things that I want to avoid What are some of the things that are going to be our guiding principles? A philosophy can create a much better feeling design. So some examples, and I wish I had time to get into all of these, but some of the ones that I've picked around lately are Only have positive relationships. It should be really hard to print bad content. I'll show you an example in a minute of that. Avoid unplanted nesting. I don't ever want a CMS to have layers and layers and layers and layers and layers and layers. I will question the site now. allowing anybody to have more than four levels in their site tree. Cattery spectators time is one. A lot of the stuff is just good user experience stuff.

Speaker 2: It should be easy to find things. You should really put thought into the grouping of your fields. I don't see enough projects use the tabs on page models I don't know why. Minute page hierarchy. This is a big one. It's a really interesting thing. A lot of times on projects I will see that a design has been built out and it's block A B C, but when you go to edit it, it's C B A Or it's a mess. So users are jumping up and down their page model in the CMS trying to figure out where things are. One of the worst things that I can see is somebody open a model or a page in Wagtail and they say control after finding the field Should be able to scroll and kind of know where it is or use the stuff on the stock. Mindset you can't use control F, but if it's hard to navigate your models, you might have an issue. Obviously keep an eye on your labels,

Speaker 2: use consistent language. I mentioned that earlier. The labels and the the naming that you use for your fields and database aren't always the most user-friendly. Ride help text, that kind of stuff. And be consistent. Consistency makes for a good system. And then limiting variability, making power optional. So one of the things that you're going to hear me say a couple times in this talk is that I like CMSs where you have structure And things are well defined and within that you have some customization, but at the end of the day you can always go through and build whatever the hell you want. Not every single client works that way, not every single product's gonna work that way, but I never want a content user to come to me and say, I want the about page, but I don't want it to be an about page.

Speaker 2: Which is this, I'll talk about the one in a minute. I have a project that we're in the process of cleaning up where we do have an about page and the site is so structured, the design is so closely tied to the models. That the content creators have requested that there be no limitations on message. So this is an about page where you can add an about page and an about us page underneath of it, which makes absolutely no sense But if you're a content creator and you really like that about page layout, this is how they've gotten around it. Nobody took a step back and was like, well, what are you trying to do? Why do you like the about page content, ear about page design? How can we make that a bit more flexible so that it works for everything that you need Instead, it's just, all right, go nuts.

Speaker 2: You can add a campaign page, a career page about careers, about contact, about country. Go nuts. And this list is actually long. It includes every single model in the site. It's about 60 models or 60 page types. So again, they're trying to work around a limitation in the system by creating more of a mess. When I talked about consistency earlier, this project also has a lot of hard-coded fields. You can see there's section one button Section one button URL on the right on a newer project anytime someone's working with a button I'm giving them the option to add a button or a link component That way I now have a consistent method for adding a link. Like I can put validation rules in one spot everywhere.

Speaker 2: You can see they have a little bit of text formatting. We have some more of these that are a bit more complex, but I'm not not every model is aware of and has hard-coded fields. So I get some consistency. I have some some variability. My model is not this long when you expand everything. It's a little bit easier to work through. And again, it's consistent. This custom link component is everywhere. Alright, so breaking down the design. We uh everybody does this a little bit differently, but a lot of iron design is blocks. Right, you've got stripes and strips of things, right? And then within that you have columns and layout and whatnot. So we always start with what are the big the big containers.

Speaker 2: It could be called sections, containers, ribbons, whatever else, but what are the big things that take up most of the site? You've probably seen on the web where you're scrolling and then something hijacks or scrolling or you're sucked on one thing. That's a section, right? So what are those things A lot of that determines theming. If the whole block is dark and every other element on it has to inherit that CSS solves a lot of those problems these days for us. What are inline elements? What are the things that I'm putting in sections or inside columns? Define what's global. Global elements, probably snippets or something like that. The reason why we always call out them a little bit differently is that they're the things that editors might not always have to go to the control. So think of ads. Ads just pop in. You have ad spots a lot of times, but they aren't necessarily content, but they impact the design So they're just considerations.

Speaker 2: You might have some ability to turn things off, but when you're thinking about building something out in Wagtail, it's always just kind of good to know. What could wreck my design or what could throw things off or what do I have to consider? And maybe you adjust the help text. Find your smallest possible blocks, which I'll talk about in a minute. And then a lot of times your singular patterns are just pages So if I have one really one-off thing, it's probably a page type and not a content type or a data type. It's just this one thing you can knock out When you're talking about the flexibility of your system, you really have to start breaking down what's the smallest possible things. because they're the things that get added randomly and in random places and they a lot of times they're grouped but they have a lot of variation.

Speaker 2: So we focus on links, buttons, lists, icons, cards, and grids Blinks are actually incredibly complex. They have a lot of different rules. Open it into the window, type your refers. You could change some of the design a little bit. Buttons, obviously. This is our starting button sheet for some projects. We use a design system called FlowBite and a bunch of other ones, but if a larger project is coming in the door, I have to consider all the different variations and ways that you can make a button and I a lot of times have to surface that to the user. It's weird if I say you're stuck with this color even though this other color makes complete sense. Or I'm sorry you can't make it that bigger you can't make it just a little bit bigger even though it makes sense in that design. So you have to think about these common components all over the place and how a user is going to add them.

Speaker 2: Thinking back to that example earlier, you don't want that stuff bar-coded. A lot of these things you want as their own components that get added or their own blocks that get added. Icons, another one. Right tail icon choosers, a package we found a while ago. Very nice, allows you to use SVG. SVG is really interesting because in any system it's completely variable. You could completely change the color of an SVG. You could change the size, the stroke width. If I were to take something that's poorly made and try to stretch it up, we're going to see gaps between the lines. So um yeah, I don't know. I think a lot of it is it's just thinking about the chaos that can be ingested or injected into the system This leads me to a point about composability and structure. Composability is the ability to build a page from a bunch of different elements, right?

Speaker 2: And it's this new huge buzzword that's in all the CMS's uh kind of going around and this whole idea that anybody can drag and drop and build stuff and and whatever else. White tail I feel like encourages you to create structure and that's the whole point of my my point about the content model. The there's pros and cons. Pages that are two-type design are completely inflexible. We saw that section model that I was talking about earlier on. I have an example of that in a minute. That was the about example earlier too Bridget designs are easier for developers to build, so it's a lot easier if I'm saying just go build the about page instead of go build a design system and anybody can drop whatever they want and make sure it all works somehow.

Speaker 2: Right? Too much flexibility is hard to edit and test. Too much flexibility means you'll lose semantic meaning. If I give you a generic page and you just drop in whatever you want, I have no idea how to really tell Google what that is. How do you set up set up your JSON LD? It's not I can't really give you a lot of custom stuff. I have to start parsing content. And then flexible designs can make accessibility difficult. If you've ever built a site where Your components had to be H2s or H3s or H1s or Heroes always an H1. If somebody moves a component that has an H1 below the H2, your whole structure is messed up. So you have to really think about the structure of your components as you're setting them up. This is an example of a highly structured page from that other project that we're working on. If I

Speaker 2: were to expand these, you would get that those those button fields, but they have clearly set everything up with a feature video and then four sections and that's it. That's all you get is four. And then you get a new section and a bottom CTA. If I were doing this now, featured video seems like that's content specific to that page, I would give them a stream field, I'd give them a section block with some variability inside of it. And then I'd probably give them a news and a and a call to action block that did something like that. This is essentially their homepage actually. So it could be a little bit structured. But if you have section one, two, three, four, eventually you're going to get a developer call you up and go, or you're going to get a content creator call you up and be like, I need section five. Or like, why can't I move section four? to section two and section two you know what I mean they can't do that that's copying pasting like six different fields up and around really would just be drag and drop

Speaker 2: so this is a limitation of of too much structure Here's a model on our own website that to kind of articulate what I would do, I would define a section block, my full page ribbon. Or I would allow you to add feature blocks, which would take an image title text, and then I would maybe add another optional button at the end of it. So kind of thinking about those sections, this might be how one of those those might look. Well structured with some flexibility. All right, uh I'm about out of time, so I'm just gonna recap here. Um I hit a lot of things. Uh I know I went kind of fast. Um but the but the gist of it is that uh think through your types up front. Don't don't just Don't just accept them from the design team, question stuff, really

Speaker 2: think about your page types and your content types. Because when you're starting a project and you're just sort of figuring out as you go, you're you're eventually just going to create a mess. validate your content model, it's completely okay to put together one of those those documents that I mentioned earlier and Test it with the team, talk through it with the team. Before you do design integration, consider the best practices you'll follow. Get into that mindset. Think about your philosophy for the implementation. Weigh the trade-offs with true flexibility versus structured page types or page types and then iterate on your implementation. The CMS experience is the one experience that I see goes stale The front of the website gets updated, ops gets updated, the site doesn't go down, but nobody ever circles back to the content management experience and fixes it.

Speaker 2: It just gets gross and the next thing you know five six years later everybody's complaining about the CMS is bad, WagTeal is bad, WordPress is bad, whatever. It's not the tools, it's how we're implementing them. All right. So we got any questions real quick? That's everyone.

Speaker 3: I want to begin to think more about because I feel like I've run into that tension between like flexibility. Um oftentimes like people ask for flexibility, which like you mentioned that requires more development efforts so we can want something quick and simple but flexible which is often impossible to deliver and and so I'm looking talk more about like how you I feel like oftentimes people will say they want flexibility but in reality they kind of want easy Right, right.

Speaker 2: So and I I that's a point that I was trying to make, but um last minute this morning was was cutting content. So the question is is how do you um focus on use to use and and allow some flexibility without making it complex and and supporting that. So that model at the end where I had um pages that have some structure And then some predefined blocks or sensible blocks with some variability in it is what's worked for us. So don't give them complete flexibility because that's probably problematic and very, very hard, and don't lock it down. But you can probably work backwards and figure out what are your common components and you know what's not going to change that often. The approach that I've that we've always done is

Speaker 2: agree on a common set of building blocks in the beginning. And then work backwards from there on theming and then the modifications that can be and then cap it like three. Like you get a feature block, you get two options to to launch. And then down the road, here's documentation for tail in and here's all these other things. And if you need to do something, we can totally do it manual. But um and then you know more advanced systems as you as you go on and you find uh that those things aren't working or if they are working you can you can always go in and add a few individual blocks and create a more generic page and start thinking about what is true flexibility look like. But I would say just don't start with that unless it's a core requirement. And it's a lot of selling people on the fact that constraints are good.

Speaker 2: It's good for the marketing. They'll be able to get pages out faster. They'll have better SEO. They'll have less errors. They'll have more brand integrity. It's a little bit of a pitch, but it is probably the best thing to kind of start somewhere in the middle.

Speaker 1: Any other questions from in the room? Anybody see any on Slack online?

Speaker 2: I don't see any more. Nope.

Speaker 1: All right, folks. Thank you.