 All right, thank you all for coming out here today. We had to do a bit of a switcheroo. So the normal person given this presentation every year is actually my boss, Michael Haggerty, who's the CEO of Trellen. I was actually the project manager on this project. And unfortunately, Michael had a bunch of other stuff to attend to. I don't know whether it was leaders of state or ice cream truck, but he couldn't be here. So you guys are stuck with me, unfortunately. What I will do, though, is do my best effort to guide you through the case study that we put together for a project that we did recently that I'm hoping you all find some nugget interesting or some valuable takeaway. Because as you can see from our description here, the main challenge that we had with this client was not that the work was incredibly difficult, although there were some challenging aspects to the project. It was that we had a very, very compressed time frame in which to do that work. So we had a client out in Massachusetts, a company called Brainshark, who was very cooperative. And a lot of the stuff that you're going to see on this presentation is actually supplied by them or even quotes from them. But they had really come to us, asking us to migrate their entire site to Drupal. And they had done a bunch of exhaustive research. And after weighing a bunch of options, they had made the decision to switch or make a transition from Sitecore, that platform, to Drupal. And then as we got into it, we discovered this was not just a straight out migration. This was also going to be a complete redesign, as well as in tandem with the reposition of their entire company. And it was also going to be done within three months. So typically for a project of this size, I mean, to put it in context, this is about $100,000 project. We were asked to do, typically a project like that might take us four to six months. Here we were doing it in three. So just to give you a sense of the old site that they were coming from and some basic information about it, I think it was at least two or three years old. One of the main challenges they had was updating content. I'll get to this in a second, but they had some challenges with their actual Sitecore implementation, which I'll talk about shortly. What you can see here, though, and this is just a point I want to emphasize because I've come back to it in a few, well, probably about 20 or 30 minutes, is the basic layout of these pages. What you're seeing here is really a site that is a format that we, at least at Trellin, would call like a wedding cake format or a layered page. So it's stack content that is being applied. So what they're really doing is creating layers of content that might have different templates or different designs, and then stacking content repeatedly on top of this. And they're doing this in various formats with different kind of media all throughout the site, whether it's a straightforward page describing their product that happens to have some video playing in Modals or whatever it is to the way that their blog is arranged. It's all stack content throughout the site. So one of the things to keep in mind when we get into out the solution that we wound up implementing was we needed something to accommodate the way that they were comfortable entering and creating content for. Because even though they were going through a redesign, and even though they were going through a reposition, they still kind of were comfortable entering content. And the company that they outsourced the redesign to was using that approach as well. So we had to keep that in mind as we moved forward. So here are some of the challenges. I'm not going to go through every one of them, because we started a bit late. But one of the challenges was they had very limited support and maintenance. There were some security issues. They had a challenging install and not a lot of support. And I think one of the financial challenges they were running into was the way that site court structure, some of their arrangements, is that if you drop support, you've got to pay arrears if you want to get back on support, which was the circumstance they found themselves in. So that was going to be expensive as well as, obviously, some security challenges as well. You can tell from my last slide they had some poor template implementation. I'll show you a specific screenshot in a second about the interface that they were actually using to enter content. But ultimately, it wasn't intuitive. It wasn't user-friendly. There were only like, in a reasonably medium-sized company, there were maybe two or three people that could actually do the content entry, which was not an ideal solution for a company that had an entire media department and bloggers and all kinds of other things where they needed accessibility to the CMS system. And then there were also some challenges with the licensing model. And redirects and their CDN system was also a challenge as well, which I'll get into in a second. So some more contextual issues. They wanted to change their hosting situation. I just mentioned the arrear situation with support and maintenance. They had a BAS installation. They couldn't upgrade. They had burned a lot of money trying to upgrade. One of the challenges was finding good people to help them with that site, because SiteCore is a lot less widely adopted than Drupal is. And the way that the client characterized their solution at that time was that it was like a race car, which was something that was really powerful if they actually knew how to operate it, which really not a lot of people there did. And so it was actually this really dangerous vehicle instead of something that could really be very successful. So here's my screenshot. There's their CMS interface. And so every page that you saw, that's really what they were having to code in. And like I said, there was really like two guys in their entire organization that got saddled with that sort of development, which is, as you can imagine, not really what they had envisioned when they selected SiteCore in the first place and really guided a lot of their decision-making for selecting Drupal and ultimately Trellin as a choice. And I think I've got this slide if I could figure out how to activate it. Well, we'll skip it. But basically, it was a heated mess. It was about as far from ideal as you can imagine. And that's part of the reason that we had to do this so rapidly, why we only had three months in their plan. Because I think they were really exhausted with the situation they found themselves in. So from a business needs standpoint, it was a major priority changing the CMS. And then one of the things that we discovered in our three-month journey with them was there was going to be a major rebrand. So first, they came to us saying, well, we really just want to migrate and put this on Drupal. And that turned out to be, well, then we want to outsource to a third party and have them reskin some pages. And then we'll just adopt that reskin template for the rest of our pages. And you're just going to be doing that in Drupal. And then it became, well, let's just redesign the whole thing. So that was a wrinkle. And if we had known that at the beginning of the project, we probably would have pushed a lot harder to say, this can't be done in three months. Because one of the challenges that we had to experience was and overcome was we didn't have design work. So they wanted to do all this rebranding. And we're waiting for a third party to come and deliver design work for us. It would have obviously much faster for us to just take our own designers and have that do that, engage in that process. But they were committed to their choice. And what really happened as far as the timeline was, we were two months into the project before we started to get finalized approved design work. So we had a month at that point to do everything design related, theme, et cetera. And that was a wrinkle for us as well. And then they wanted a templatized approach to coding pages. So getting away from the screenshot you just saw. And then something else to consider was they, the way that Brainshark works, they've got their own proprietary app that they use. And that's something that they sell to clients. They've got a Brainshark app, they've got a SlideShark app. It's for marketing and sales enablement. And we had to be able to integrate with that app as well. So that was another item that we had to factor into our approach. So here's the actual Brainshark plan from their own words. It was migrating to CMS. And then a bunch of research discovery milestones. They put together like 40 slide presentation using a bunch of research. If some of you guys were at the AQUA's presentation on Monday, you probably saw some of that research selecting partners. You'll see like SiteCore is in a quadrant and Drupal is in a quadrant. That was, again, a fairly exhaustive process they went to to make that selection based on some of the challenges I just described. And their timeline. So this timeline was the original timeline. This was without any rebranding. This was a three month timeframe. Notice that the design development phase is two and a half months. And I just told you we had to compress that into a month. And that this that you're looking at really didn't account for much new branding and we had to account for an entire rebrand. So we still tried to accommodate their schedule but with a lot of new factors thrown in, a lot of monkey wrenches thrown in that we didn't really account for at the project outset. By the way, if anybody has any questions about any of the details, please raise a hand, jump up. I'm happy to jump in. So a little bit of information about us. We do about, we've been in business for about 12 years now. Trellin primarily focuses on the non-profit and education and NGO space. So the reality is we don't even do that much commercial work. But Aqua came to us with this project. They said we've got a client that really needs help. They've got to get this done in three months. We said, you know what, we're up to the challenge. So that's kind of the genesis for us even working on this project because it's outside of our usual market space. There's about 20 of us divided up into full-time folks. We're a completely remote firm that's something maybe you guys have some questions about how we did some of this as a distributed workforce as opposed to everybody in an office where it could collaborate easily. But we just use a lot of online tools that Slack and Hangouts and all kinds of other things to work around that with both ourselves internally as well as the client. And then some information about our process. So first we go through a discovery phase, defining goals, understanding what the deliverables are, a design phase. As I've been indicating, this phase kind of got bumped a bit. It changed drastically throughout the project because really what happened was, and I'll get to this in the later slide, but there was, during this, the section of time which we would ordinarily devote to a lot of design work, we were actually doing rapid prototyping. So we had, we went through the next phase actually, the core configuration phase, which gathered the requirements. We documented everything as exhaustively as we could in our Wiki and met with the client, understood what their need was, and then translated that need into technical terms that our developers could then take, we could use to write tasks and tickets for, figure out what modules we need, what content types, et cetera, and we used that to rapidly prototype during that timeframe that we would ordinarily be doing design. So a bit of an inversion there, design actually came right before, really right before deployment and after implementation. So moving on, we had then development and the implementation. We'd have our weekly sprints, usually those were a week to week and a half, followed by implementation, preparing for launch, importing the data, and even then, that's when we sort of plugged in the design phase, followed by deployment, implementing the CDN and Fastly solution, et cetera, and then post delivery, doing a lot of review QA and bug fixes to make sure that they could get a working viable product within their three month timeframe. So just some basic methodology information, we use an agile process. What that means in practice is, like I said, week to week and a half sprints. What that usually means is we've broken all of the requirements down into user stories first with the client and then we take those, we size those user stories internally with our team. You guys are probably familiar with this, we use a Fibonacci scale to evaluate the stories that we can't include that are epic. We go back to the client and we say, how can we make this happen in a different way? Or we say, this will happen in post launch at some point. Once we've done that, those stories become, they're broken down by tickets, by priority, and by project plan. And then they're tasked out to developers as needed from there as tickets. We use RedMind, and one of the things I wanna emphasize in RedMind is our client has complete access to RedMind as well. So they're working through, one of the challenges I'll get to in a minute was some contextual stuff. And one of the things I wanna emphasize is on this project, given the timeframe, it was incredibly important that we maintain as open and transparent mode of communication with the client as possible. So they knew exactly where we were because the folks that we were dealing with on there they've gotta have accountability to their chief marketing officer, their chief financial officer, the rest of the executive team to make sure that their business needs are gonna get met within those three months. So it was important for us to make sure that they were invited to sprint meetings, to sprint planning meetings, they could sit down and understand why is the story epic versus why is the story a three? And they could understand all of the documentation that we were doing in our wakey. So, and I'll show you some of that in a moment, but we wound up for some of the aspects of the project that we knew were gonna require more of, there were gonna be a communication hurdle, working through the Fastly and Proxy issue, working through the migration issues that they had. We knew that we were gonna have to document that and make sure everybody was in the same page as far as what the problem was and what our solution to us, gentlemen. That's a vote that, so usually we grab no less than three developers and so I'll lead a meeting where we'll sit down with them and they're the ones that are voting and I'm just administrating that vote and then we've got a system that averages out their score. We make sure everybody's comfortable with that. Obviously we've compressed timeframe, we had to hustle a little bit during these meetings that we normally wouldn't, that we'd normally be trying to talk about them a bit more, make sure, first we make sure everybody understands what the requirement is, we vote, we average, we make sure that makes sense and then we move on to the next one. And then the point that I talked about a few minutes ago, the wrapper prototyping, one we would ordinarily do that anyway once we gather the requirements and core configuration so that we can start to build out something that even though it doesn't look exactly like what the client is anticipating, it functions exactly like the client is anticipating so that we can start to tweak that or refine that as needed based on any new requirements and obviously throughout this project, just in the design standpoint, there were a bunch of new requirements that emerged throughout this small three month window and the prototyping then allowed us to hit the ground running the moment we did get that design work done. So not only just as a little bit of more context, not only was, do we go from just migrating to some reskin to redesign, but the third part that they outsourced the redesign to wound up dragging their feet a little bit on that. So that was an additional challenge for us to make sure that we had everything ironed away as much as we could so that we could hit the ground theming as soon as we got that approved design work. All right, and so here's just an example of how we document stuff in the Wiki. I know that there are probably better systems that other folks use, but each one of those, you probably can't read it, but each one of these corresponds to a major item. One of those is, for instance, we've got page configuration, block configuration, content type configuration, module configuration, and then there are some additional challenges that we also document at the bottom, everything from theme setting to the issue with Fastly and the CDN system because they had to serve pages both to their BrainShark app as well as to Drupal, which is another challenge we had to work with. But the other thing I'm just gonna emphasize with that is, again, client can see all of that. So they know exactly when that's getting updated. If there's a question they have, whether it's understanding how we're working content types or whether it's some of the stuff that I'll show you in a few minutes about how we approach the CDN issue, all of that's in that same repository where they can view it to their satisfaction. So just a word here about the migrations. Cycle or handles their data a lot differently than Drupal does. So one of the things that we had to account for was a migration strategy because they had a lot of blogs, they had a few other content types that we would also need to be in there. The blog was the main challenge because they had links and media going back over a thousand blog posts going back several years in the Cycor system and it's very proprietary, they have their own internal IDs. We had to make sure that we could develop a package first within Cycor that contained all of the requisite information we were gonna need and then create a custom script within Drupal to digest the package so that Drupal could understand it. And then finally put that up in the development environment to execute the migration and then I'm just gonna mention that, like I said, there were additional migrations we had to contend with too, not just the main one. So that was something that, again, is gonna be documented in the same wiki that you just saw so that we were on the same page as far as both how to execute in the timeframe. And let's see. So yeah, just to run down to some of the items that they wanted to migrate from Cycor, a lot of pages, a lot of blog posts. They also had a database of press releases and news articles that I'm not even sure is listed on here. So it was a fair amount to make sure we had under control and that we had a strategy. In fact, I'll admit that we had one person working on that for about three straight weeks to get that done and make sure it was, we were on top of it. So the issue with the CDN Fastly, I kind of touched on this, this is making sure that we could serve data to both the native Brainshark app as well as Awkwia Drupal and wound up configuring a bunch of rod of slash rules to make sure that content was gonna be served in the appropriate place. And this was also just collaborating with them, making sure we understood everything from directory structure and how they wanted pages to be built out, to understanding how the Brainshark app worked and making sure, again, all this was accounted for in our plan. And yeah, and there were some issues where we just had to accommodate some conflicts and work through them. And like everything else that I've touched on, as an example, so here's how it was documented in the Wiki. So we had, again, one or two people sit down, come up with a plan and figure out the best approach, share it with their engineering team, make sure that they were on board with our approach and recognize, you know, we're in agreement with both the problem and the solution so we can move forward with that particular solution as well. And finally, our challenge and with theming, again, we typically would take at least four weeks on most projects. Here we had really about two weeks because those last two weeks were for QA and testing and making sure that we could actually launch the product in a format that they were happy with. So one thing I really gonna emphasize was, and this is something I had never done at this stage, was we essentially, for a lot of this, grouped up to coordinate our theming efforts. So if we had, say, six people working on theming at a particular time, we'd get everybody in a hangout and it really became a four or five hour hangout, perhaps, as people would hop in, figure out where we are at that particular juncture, we'd hand out discrete tasks, we need to create a particular style sheet class for something that handles something and that developer would go handle that and come back to us in half an hour, an hour, or two hours, or whatever it took. And then we'd be able to, we'd be able to add that to whatever additional style sheet classes we already had. Maybe a developer that was working on a specific kind of page would take his work, take the other person's work, and incorporate that maybe, so there were, we tried to work on a series of dependencies basically, so somebody would create a number of classes and then somebody else who was then doing different theming work would take those classes and actually build out the specific layers in a page. Ordinarily, the process of trial in is that the client, once we've trained them, does a lot of content entry, but in this case, there really wasn't the time to do that, so it was on us to do that. And I want to show you, in a few minutes, the system that we actually created, we used a paragraphs module approach to the layers, so this is where I mentioned at the beginning of the presentation, a lot of their content is stack content in those layers, so those wedding cake pages. And what we did was we used paragraphs to make sure that each paragraph had a different template, so we looked at their site, we realized, okay, there's 10, 15 major templates that they use for the way that they're creating these layers. Maybe it's a 40, 60 distribution of content, maybe it's an inverted layer that has four columns, something like that, and then all the user does is go and select that layer in a dropdown menu and then plug in the respective content from there. And then with each respective layer or even each content section within a layer, they have the option to add style sheet classes to make sure that content is displaying, like with a particular background. Or in a particular font or the content is centered or whatever it is, that it was an easy way for somebody to be able to look at the mock up and say, okay, this is actually a page with five layers, we're using these different formats for these five layers and here's the style sheet classes we'll need. And if we didn't have one, that's why we're on that call with all of my developers, we can say, okay, we have this need for a particular class, can somebody go make this? And somebody would volunteer and they'd go come back to us an hour and it'd be made and we could then go use that on the work that we were doing for the other folks that were actually building the content out. That's a good question. Sorry, I think if I'm not by the mic, it doesn't record, it hates me. So we actually look strongly at panels and it may be a better question if I talk to you afterwards and I can show you the specific setup we use, but ultimately Paragraphs was gonna accommodate the sort of specific layers that they were looking for in the layer templates as well as the style sheet classes a lot better than we could do with panels as an out of the box solution. So it was partly again a timeframe issue that we made that choice. Okay, so I think I've talked enough about that unless anybody has any questions about that approach. I'll show you visually in a few slides what that's really gonna look like. So the other aspect I wanna touch on is how we handle review and QA because this was really like the last two weeks of the project that we had to make sure everything was actually in order in a way that they could flip the switch and launch the site on time. And what we wound up doing was coordinating very closely with the client so that what they would do is on their end, when we were at a place where content was ready to be reviewed, we'd have, first of all, and I wish I had a slide for this actually, but maybe I can show anybody it's interesting. We first had a page index, which we were turning over pages and periodically reviewing them with the client. But after all of that was done, we had a separate Google doc that we were sharing with the client to catalog all of their feedback, which was broken down by page and then broken down by issue in the page. And I think I've got a slide for it. So that's actually, this is like 460 issues long and probably wasn't the end of the project. And some of it's hidden, but what they were doing was they'd have review parties on their end. They probably had in total, I think over the course of those two weeks, probably at least four of them, where they'd pull in all people from all kinds of departments that they'd sort of requisition or pull into service and sit down on evenings and go through these very in-depth review sessions, pouring over each page that we turned over and figuring out this match, what we're looking for. Does each link work? Does each video pull up in the right sort of format, full-screen modal? Does it look like it's supposed to? Does it function like it's supposed to? Where are the issues? Is the page loading correctly? Are there small inconsistencies or errors? And these all get documented on a line item base in our feedback worksheet. And so every morning, the following morning after the review party, we would connect with the client and figure out, okay, let's triage this list, figure out what the most important is, so they rank it. One of those columns is for priority. We make sure that we target the highs first and the mediums and the lows. Off from the side, I'm not sure you can actually see is a column for us to also use it to take, so our developers can take issues, put their name in there, say we're working on this to make sure nobody's duplicating effort and make sure that we can just, in a span of two weeks, plow through every item on this list. So that the site's in a good working order by the time it is actually launched. And then obviously each time there's a review party, more issues get added to this list and we repeat the process. And this, we again went through this four or five times through the course of those two review weeks, basically the QA weeks. And then there's something intangible I also wanna mention, which is attitude. And that's actually a quote from the client. That's there, I think they're marketing director and he called us the calmness and the storm. And I think probably people in the audience have been in similar spots where their client is a little bit anxious about the state of the project. Maybe they're anxious about the fact that we've gotta deliver this entire thing with a lot more requirements that we originally envisioned within just three months. And maybe they thought we'd be farther along for some reason. You know, I think one of the particular challenges in the case of this client was, and you guys have probably experienced this yourselves, if design isn't in place, even if we've got a prototype that works exactly to the specs that they needed, if design is not in place, it doesn't look like what they're expecting. And that is a psychological hurdle that we had to overcome. And so part of our solution that was just knowing that, you know, our confidence, we've done this for 12 years, we've done, we've probably been in as tight positions before, and I think the client really picked up on that attitude and appreciated it. And it calmed their anxiety. So when they had their own meetings with their own executive team, they could say, you know what, we get that maybe all the design isn't quite in place. We get that there's 200 issues still in the backlog, but we'll be ready. And yeah, we did have to work some weekend hours, and I know that they were working nights to review it, but it was all, none of it was, I would say excessive. In fact, in my history at the company, I think this is probably the only project I've had to work some weekend hours on. So the point is, if we needed to ramp up even more, if I needed to pull in more developers to put in a few more hours in the weekends, we still had the bandwidth in which we could have done that. And I think that's probably the knowledge on our end that allowed us to have that sort of calm attitude to take to the client so that when we engage them, they could really, they had the confidence to realize we were gonna get this done on time. This, you know, there wasn't an imminent crisis. We weren't gonna have to push back to launch date. Things were gonna be okay. So here I wanted to show you the paragraphs system that we implemented. I'm happy to walk to the site with anybody after, because I think we'll probably have a few extra minutes. I'm not sure I can actually am smart enough to figure out how to put on the screen, although I'd love to do that if I could. But you can see that content is again sort of stacked and you can't really see the bottom of the page, but it's in a similar format where it's layers and layers may have all kinds of different setups. They might have video, they might have images, they might have infographics, they might have contact us layers with, you know, it could have all kinds of contents and backgrounds and so on. And here's what it actually looked on the back end for our users. So what you're seeing here is, unfortunately it's kind of hard to see, but we call them wedding cake pages internally, but they're really just layered pages. And what a user is selecting in that drop down menu at the bottom is the template for that particular layer. So like I said, it could be a 60 40 inverted layer and then they get a system in which they can then edit that layer depending on the particular constant layer. And then they've got a section below that in which they can add or adjust any stashy classes that we've already set up for that layer so they can get the look and feel that they're hoping for. And that from here on out also, that more than just two people in the organization can be comfortable using this system. That it's very different from the system than the screenshot that I showed you at the beginning of the presentation. And let's see, I think that's probably it. So that's pretty much it. I'm happy to pull up the side itself and walk through some of their choices that we made with the client and how, you know, this particular content management system worked for them. I mean, they were pretty ecstatic with the solution that we delivered and the timeframe that we delivered. And yeah, with that said, I'm happy to take any questions you guys might have. Right, so any one of these systems can be edited and the fact that that's the first button you're seeing on each of those layers and pulls out into that expanded window in which somebody can do all those edits and adjust the stashy classes and so on per layer. I don't have a great answer for you as far as an engineering perspective, but the guys that worked in it are downstairs. Or you can shoot us an email and we're happy to walk you through that process. That's a great question for our guys downstairs. So I'm gonna defer to them because I'm probably gonna botch the answer. But again, quite happy to walk anybody through exactly what that page looks like when it's actually on the site. Any other questions? I'm gonna actually ask, so my team just walked in, at least a couple of them. So I'm gonna ask, so Joe can probably help you with the paragraph question that you just asked in the back and David here can help you with your migration question. If you guys wanna talk to the mic. What was the migration question? I'm sorry. How did they do that? It was a while ago. So the way we do it is just have the migration set and tested over and over again on our dev environment. It's gonna be one migration for their prod environment, their production. So we just had them continuously making content and we would just pull the, right before the prod migration, we would pull the final data set and go from there basically. Do you wanna repeat your question about the paragraphs? We can do it more in a second. The paragraph is actually easy to rearrange all the number we can do in paragraphs. It's the big block of content and you maybe get one and a half on a page or they all disappear up and it's really hard to read it. I was just in a bot earlier and that would take me points if you almost had them trying to collapse them all. I was wondering what you used to collapse them all. Sure. I think it was an option actually within the paragraph type we were creating them. There was another module. It's paragraphs extra features or something like that because it adds some defaults and let's just add some default settings for the paragraph types. And that might have been the one we used so we could say we start out with one specific paragraph type by default. Everything starts with a single text block by default and it starts flashed or expanded. The module was called off. It's something like paragraphs extra features or something like that. Any other questions? Go for it. It was a challenge and so we'd have, we usually had, like I said, sprints from about a week to a week and a half. We tried to engage them as much as possible so that they were as included in every meeting that they wanted to be included. What they chose not to in this particular case, they chose to primarily be included in a post-sprint review meeting where we'd say here's what we accomplished this week. We met nine of our 10 goals in this particular sprint. These core configurations are ready. We were here on the migration strategy. We're here on the CDN strategy. And that's how we essentially coordinated with them over the period of the three months. Is that sort of the answer you're looking for or more detail? I don't think there's any magic secret. There is in a magic secret. But they were a wonderful client. Yeah, I mean, they, you know, that's where I went into that slide about the intangibles and the anxiety. And I think part of that was solved just by transparency and part of that was solved by the attitude that we had, which was, you know, we're on track, we're fine, we've been here before, we can do it again. We've launched 505, 550 websites over the course of 12 years, you know, while the requirements may be challenging, they're not by any means impossible. And I think that also rubbed off on their project manager and their, you know, their marketing people that were, and some of their technical people too. So, you know, I'd say it's a combination of that process plus the sort of psychological component. That's a great question because, I mean, it's great for the developers and it's great for me. Right. Yeah, there's no question in any of our minds and we've certainly explored alternative PM solutions that are different from Riem and perhaps more user-friendly from a client perspective but haven't made that transition yet. So, you know, I think it was probably more their technical people and their engineering team that were using RedMind more than their marketing people and their PM people. I do think it probably on the whole poses a bit of a hurdle, as you say, for less technical people or people that are looking for information displayed in a more convenient manner. I think one workaround that we do is we try and maintain very well-organized wikis, both in terms of up-to-date and in terms of navigation. So, if I were to show you a wiki or even a brain-sharp wiki, you know, it's very easy to navigate from the main section of the wiki to dive into a specific section of content types within our core configuration section. Not only that, but pretty much all of the documentation of the whole project is in there and it's all pretty easily to navigate to. So, we try and overcome that. Yeah, exactly. We try and sort of have our own approach within RedMind so that it is a bit easier to use and it does vary from client to client. So, some that are more comfortable or maybe have used a similar system in the past, they do jump in there and they even maybe write some of their own tickets if they see something and others, you know, they're much more reluctant to do so, you know, their technical knowledge is, it's more intimidating for whatever reason. Sure. Do you guys recall anything? I don't think there were a lot of features that we had trouble with. You know, I think that migration, sorry, go ahead. You know, I think the main challenge was the one I listed earlier, which was the migration just because of the very proprietary way that Cycor stores that data. But beyond that, in terms of the way that the actual pages are set up, there wasn't anything terribly troubling. The main thing was, how do we replicate or generate a system that's easy to use as far as CMS that is comparable to both their old design, which we were originally going to use prior to being told, hey, by the way, there's a reskin coming, hey, there's a redesign coming after that. So, we needed a system that was flexible enough to account for that, and that's where that paragraph's module was selected to help us through that process so that, regardless of whatever the design solution was, we had a system in place that could do what they needed to do. Anything else? I think they actually had a lot of that. So, they shared with me, but I've got a 40-slide presentation of how they were debating that choice internally. And I think they went through probably, it was probably a very accelerated research, but it was still pretty thorough. Like, I was surprised when I saw it, and I only saw it far after the fact, I only saw like a week or two ago. So, I think most of that was handled on their end, their decision-making process, but there's probably information in those slides I'd be happy to share with you. In fact, I'd probably pull up that presentation if we really wanted to take a look at it. Sure, we can do that. Anything else? Alrighty, well, thank you so much for your questions and your interest in this. We're gonna be downstairs and around. If you guys have anything else you'd like to investigate, I'm happy to walk to the site with anybody. I'm sure our team would also be happy to share their thoughts if you've got any more technical questions because I'm just a lowly project manager and, you know, when it comes to fancy stuff. I'm just gonna pass it off, so. Yeah. Okay, thank you so much, guys.