Architecting for a multi-domain site

Speaker 1: All right, cool. Um so, uh hi everybody, my name is Ben Beecher. Uh I'm the CTO and co-founder of Light Matter, which is a design and dev agency over in New York City. Recently we've been doing a lot of work where large companies have been coming to us and they've been saying essentially we have 10 sites that we've got on a topic, you know We've acquired them. We had some like product launches, and now we're managing like 10 different WordPress installs, and it's a nightmare situation. And how do we sort of bring these together and do a cohesive pool where we have like a single single interface that all the editors can use. How do we share content? How do we sort of like bring this into the future? And so we've been doing a pretty good trade on converting these multi-domain sites into a single shared infrastructure.

Speaker 1: And I think the first thing you want to ask when you start working one of these things is you want to figure out what the content team looks like, what the people who are actually going to be editing the site, how they're organized inside of the organization. So we've seen two models. We've seen what I call the centralized model. Which is when we have one team that's managing multiple products, multiple audiences, multiple markets. So an example here for this is one of our clients is like a large New Jersey telecom. And they have a they have a product and they're targeting uh you know marketers, they're targeting uh police officers, they're targeting the government officials, and they're using um A lot of shared content, they're using a lot of shared uh assets, a lot of shared resources. It's one set of people who are just targeting different people, and they're they're okay with more duplication, they're

Speaker 1: they're okay with more

Speaker 2: oh I think I forgot to turn off this thing. Sorry. Uh

Speaker 1: these people are essentially better with um uh centralizing and and handling uh content in in a centralized fashion. The second sort of situation that we've seen has been what I'm calling decentralized teams. And this is when you have a lot of people who are separated by regional boundaries and they're maybe not especially happy about being forced to use shared infrastructure. So an example that we encountered with this is one of our clients is a large fertility roll-up firm. So they make their money by like buying these small regional fertility clinics. You know, there's one in New York, there's one in Austin, there's one in Alabama And before they had previously bought these clinics, they all had their own separate WordPress instance with their own separate

Speaker 1: SEO consultants and their own separate AdPress buys. And part of what we've done is pulled those things together and to try to figure out like what are the best practices that we can use to do once, share everywhere, so that you don't have to reinvent the wheel every time you you use a new clinic. A lot of the things we saw here was that essentially every clinic felt special. They felt like they had a unique use case and they felt like they had the right to dictate a lot of uh controls and changes and and content and functionality, which is in contrast to the centralized thing where they had a pretty solid idea of like what they were trying to do and how these things were going to be used on a cross-domain basis. So uh for centralized teams, uh we found that uh one of the things that was really helpful is we created a separate base page on a per domain basis.

Speaker 1: So we made essentially like a marketing page, we made a law enforcement page, we made a government page, and all of these things descended from a shared base page class. But we tried to get them to use the marketing page on the marketing website. And the reason we did that was whenever we needed to do a sort of one-off for a given page, a given domain, we had a hook to do that in already So it was easy to say that like the law enforcement page needs like a strange widget. It needs some kind of block that none of the other pages need, the other domains need. And we have a place we can just sort of stick that in right there. We found that as we were designing for these centralized teams, flexibility was the most important thing for them. They were constantly trying to go to different departments within their organization

Speaker 1: and they were constantly jumping from meeting to meeting, showing people these websites and trying to get institutional buy-in. And a really big hurdle that we saw was when they would put the content in front of one of the committees that was responsible for approving it for their little slice, they would always want something that made them a little bit of a special snowflake. And that's okay. In the centralized model, we found that they had sort of the skills and the knowledge to be able to maintain and manage those those one-offs, those exceptions. So we needed to have a way to place that flexibility in their hands. So we optimized for flexibility in this. Plus, they're gonna maintain it. So any sort of strange debt in the user interface you end up creating, like they're the same people who are entering

Speaker 1: are the same people who are gonna have to deal with it So, you know, they tend to be a little bit smarter after education about choosing where they actually want to pay that complexity cost. We found that because the team of people who was working on this content was constrained and known to us, we could be a lot more complex with the interfaces we designed, and we can double down on the training. Like this was a little bit of a captive audience to us. So we were able to say that like, you know, for instance, one of the conventions we used for these things was we we said that an A tag in an H3 uh had the styling of a button. Right. And that's not what I would consider like especially obvious behavior, but because these people were using the software this over and over, we were able to sort of like hack that little feature in for them. Uh whereas something were a decentralized team where you need to explain that over and over and over, that just wouldn't

Speaker 1: be possible. Alright. And then the final note we noticed on the central teams is it was okay to expect more from them. You know, there were situations where they would do things that I thought were silly in terms of entering content. And it was really easy and beneficial in the long term to sort of get on the phone with them and just be like, you guys need to, you know the right way to do this. Don't be lazy with this. just expect more from them in general. For distributed teams, so in this case, you know, this is like we have a New York City client, we have a an Alabama client, we have an Austin client that are all using shared infrastructure. We forced them to use standard components. So one of the things we noticed is that these these specific clinics were not talking to each other at all.

Speaker 1: So some of the like need to feel special really wasn't as much of an issue because when we came to them with a design and we said, this is how we want your website to look. They just accepted it, right? And like the the discussions there were things that we could guide and we sort of had a plan to be able to say that these are the five features you get with this specific component and we're not going to add a sixth one. And those were pretty easy discussions to have because they didn't know better. They didn't know that there was this opportunity to maybe hack this in a custom way The only thing that they will fight heavily on is customized branding and customized look and feel. They cared very deeply on being able to make their version of the website look completely different than every other version of the website. version. So uh that was a really important thing was be have a hook in place to be able to style these things.

Speaker 1: Uh uh standardization is more important than flexibility was a lesson that we learned here. When we were being asked to do cross-domain operations, you know, a bulk import of content or some kind of moving several pages from one base type to another. The places where we had done the work to standardize were much easier to handle with than the places where we had a lot of one-offs. So we found that forcing people to standardize was was a very powerful tool and being able to talk to multiple clinics at once. We found very quickly that the people who were responsible for managing their individual slices in these distributed teams did not have high proficiencies with CMSs. In general, these were people who were

Speaker 1: office workers who saw the website as one more facet of their individual jobs, and they didn't want to put the time or effort into like really mastering this thing. So we really needed to focus on simplicity and how to make this stuff as simple as and easy as possible. And that meant that some of the really cool features we just couldn't really expose to them. Snippets, for example, we decided did not make sense to give end users For the distributed systems, we doubled down on groups. We found that being able to express things in groups just using the standardized Wagtail model was really powerful to give people a sense of sort of security and stability. They really felt like I knew where I fit into the hierarchy and they felt like we had a plan and we had these things covered because we were able to express their relationship with the greater website

Speaker 1: in the form of a group. So uh we really use the heck out of groups to manage these people. Um we used a lot of snippets, but we didn't expose them to users. So we found quickly that anytime we needed to do sort of a cross-domain admin level operation, the only way we could realistically implement that was as a snippet. So we found that there was a pretty strong dichotomy of putting spite-specific content into like rich text blocks and struct blocks. And then when we use snippets, it would be for like dropping in the Google Analytics tag or if there was some kind of rich text tag manager that they wanted to do. We were able to use that for sort of higher-level add-in functions. The final thing we noticed is that people tended to just go in the treads that we we

Speaker 1: set for them. So we would do things like precede a database with a set of tags. to use for images. And people just tended to go with that and not not try to reinvent the wheel, which was pretty good because when you have a lot of distributing teams, it's very easy for each team to go in its own NEMI convention and its own different set setup So we just populated those, we gave them the list of the tags we wanted them to use, and we were able to keep that pretty well constrained, even though it was a lot of different people. We found in the design phase that radical changes in HTML is an enemy. So we found that it was much more complicated to customize HTML and markup on a per-domain basis. Than CSS. So when looking at two separate components or two proposed designs,

Speaker 1: it was much simpler to be able to say that we can tweak something at the CSS layer than it than at the HTML layer. When we found ourselves using customized HTML on a per domain basis, we found that one struct would have multiple templates on a per domain basis and it and it sort of exponentially grew in terms of the code that we had to manage there. Um we yeah, as I was saying, we try to keep the markup the same as much as possible. We had a different style sheet on a per domain basis, and we just sort of baked that into the base template that we used. There was an assumption that the styles were going to be different, that maybe there was like a shared style guide in terms of typography or something, but there was going to be a slot to be able to say that one

Speaker 1: clinic's color was blue and another clinic's color was red. Uh this was really important to them to have that level of customization and uh you know uniqueness feeling. And we really found that it was easy to push those those domain-specific changes into the CSS.

Speaker 3: More specifically?

Speaker 1: I found this was true for centralized ones as well. We found that like the needs for customization on the display level were lower for centralized teams, but they're still there. And it just it becomes very challenging when you start managing one template per domain. You start having things where the domain starts touching into the code where maybe you want to segregate those template files by domain so then you suddenly have like five different folders. And now you have a strange situation where like Your folder structure on disk is mapping your data structure in the database. Right? Someone goes in and they change the primary name of a of a of a site and suddenly you have like a difference there. And you might never know because you're not you're not looking at that data day to day.

Speaker 1: Um we pushed as much content to a rich tag as we as possible and we found that to be really portable and really powerful. So as much as possible we extended the rich text editor as much as possible. We did not give people strange weird blocks. We said, you know, 80% of your content lives in a rich text, so use a rich text to drop that stuff in. It was easy to move cross-domain. It was easy to perform migrations on. Anytime we had stuff in rich text, it was easy to work with. So we really found that to be like the Swiss article. army knife as much as possible. I know it's pretty obvious to say that rich text is powerful, but we really extended that to the level to de-emphasize custom blocks. Um we found that uh when we extended a rich text control, like adding a button into the into the draftel editor, for instance.

Speaker 1: We found that was being used across multiple domains much more than if we were to create a new block. There was a higher communication cost around what does this block do and how do you use it? What are the contexts you use it in. Uh on the on the contrary, when we added something to the rich text editor, people seemed to get it more instantly and they had a WYSIWYG way to play with it. We found that to be a lot more discoverable. So we just found that the uptake of new features when they were added directly into the rich text editor be way heavier. We did not allow Raw HTML. This was sort of a hard-fought battle. The original scope for one of the sites that we built, we ended up uh intaking a large amount of raw HTML. from a previous maintainer and we found that keeping those pages alive was a huge burden on our maintenance.

Speaker 1: Anytime we wanted to be able to change the site in a meaningful way, it was very challenging to do so. And we found that the HTML standards and conventions used were radically different across the different domains. There was no communication here, there was no pre-planning. And so we ended up needing to go into a per-domain basis and sort of validate and clean that HTML by hand. which was super time consuming and inefficient. So we just disallowed raw HTML. And as I mentioned before, what we did for JavaScript snippets, analytics snippets, is we tried to manage that that and give it to them in the form of drop-in snippets that they could use. And we found that to be a lot better in the long run. Obviously, this is not possible for every organization. A lot of them do require raw HTML, but as much as possible, you want to limit this, I found.

Speaker 1: We need to do a lot of work around cross-domain migrations where we would create like a Django migration and like move some pages around or just do a data migration. And we found without fail that the ones with raw HTML were the hardest to do that. with so one of the things that we did in the upfront designing process was we identified uh like per site choices, essentially like where are the places that we foresee sites are going to be different on a site-by-site basis. I don't think it's possible to identify everything. It's going to shift. It's going to be different depending on your problem domain. But the ones that we found that were good were headers specifically. Footers were always different. The meta tags were always different, and that meant finding ways to let

Speaker 1: clients edit their favicons, their SEO icons, their page tags. Inevitably everyone had a different SEO consultant who had a different piece of snake oil to sell you. And we just found it a lot simpler to sort of like step back and give them a slot to do whatever they wanted to do with that And so we ended up just saying, look, you guys manage this and and we'll make sure it renders, but we're not going to give any sort of guarantees of effectiveness. So we needed to needed to have ways to jam stuff into the header that was completely different on a per site basis. We found over the course of the creation of these different sites that we needed to create essentially a God object for all of these things. One example is for the fertility clinic, we needed to create something called an institution. We ended up having a list of doctors.

Speaker 1: A doctors would be placed in the institution, and then on a per-site basis, you could filter based on that institution. The alternative to that would have been like a model chooser on every single page, and we wanted to be able to centralize that content association a little bit more. We sort of ran from this every single time we've ended up using it and we've introduced it a little bit later into the process. I think it's probably better to do it straight away and just accept the fact that there's going to be some kind of database object that you have control over that you're going to use as a filter point. We found it really helpful to have and inevitably there were pieces of content that that you wanted to filter on everywhere. I wanted to talk real quickly about our wish list. We think that there's a need for a swappable sites model. We talked about this briefly.

Speaker 1: I think that would be really powerful. Uh there's also right now, as far as I know, only one published notification email and we wanted to be able to customize that so that one thing we found was that different uh clinics wanted to be able to have different from addresses when they saw the published email. And it's a it's So things I could hack on maybe. Uh all right, that's that's everything I got for you. Does anyone have any questions or Yeah.

Speaker 3: So what are some of the examples of extensions that you've done to the rich text editor?

Speaker 1: We found that a button was really useful. Everybody wants a button all the time. And it's essentially just a link, right? But like, yeah, everybody wants a button always. Um we've extended it out to include, you know, all uh H1 through H6, P tags, underlines, you know, and We basically gave everyone all of the basic typography controls all the time. We've done a lot of interpage linking, so like anchor tags on pages has been something that's been really powerful. So

Speaker 4: like inside of the respect header you can probably think?

Speaker 1: Yeah, there's actually a pretty good example of it online. Um getting the anchor text into the template itself can be a little annoying, especially when each header has a different height. So you're trying to figure out that offset, it can be a little gnarly, but We definitely found that to be really useful. So those examples share somewhere? Not currently. That could be a good thing for us to do though. Yeah. Yeah. And to be fair, the anchor text is something that we pulled offline too. So I think someone's already got an example of that online. Yeah.

Speaker 4: Uh I would like to hear more about this this god object. Uh like so that wasn't defined as a snippet, is it like a particular model and how is it managed?

Speaker 1: So yeah exactly. We made essentially um a model that had a a reference to the site. And then when you're able to grab the site from the request you could just follow that relationship and grab that model and that gave us access to any sort of filtering we needed to do in in that in the context So it's a little it's a little bit longer than I would have liked, and that's why I think a swappable model would be better because then you could flip that relationship and get it with the one fewer hop. But essentially in the in the case of the institution, for instance, each institution is paired with a uh a site. Actually I don't have a many, many relationships with the site. When you grab the access to the site on the request, you could pull the other side of that relationship to get the institution and that would give you access To the doctors, the hours, the locations,

Speaker 1: stuff that was sort of site specific. A lot of this stuff could have been managed with like site settings. Uh and we did try to leverage that as much as possible, but we found that some of this stuff was just uh the filtering stuff was really hard to do as a site setting.

Speaker 4: So it's a model I'm trying to do like a concrete example to it would be like a model. that would have like the the name of the site or whatever and then like list of doctors just

Speaker 1: no we did a foreign key to the site is how we handled it. So a model with just a straight up foreign key to the site model. The Wagtail site model. And then you have access to the Wagtail site model and the request. And then you just define the reverse accessor. So like request. sites dot request. site. uhinstitution in our case. Anyone else have any questions? Thanks.