 Good morning everyone. On behalf of Kerasov Technology Corporation, I would like to welcome you to our AQUIA and OOMF webinar, Small State Big Dreams, Howard Island, a reimagined and modernized digital presence. At this time, I'd like to introduce our speaker for today's webinars. Jack Hartman, Head of Delivery for OOMF. Jack is the Head of Delivery at OOMF. On a daily basis, he's collaborating with OOMF's internal team to solve unique problems and deliver quality digital platform experiences to our clients. Ben Hamlin, Senior Back and Engineer at OOMF. Ben is busy writing custom code, developing site architecture, testing website functionality, reviewing code, or evaluating and contributing to Drupal projects. Kara Hall is Drupal Cloud Senior Product Marketing Manager at AQUIA. Kara has a focus on AQUIA site factory and AQUIA personalization. She has a passion for innovative marketing solutions in the digital experience space and finding ways to help marketers and developers work together efficiently. Jack, Ben, and Kara, the floor is yours. Thank you, Blake. I'm going to go ahead and share screen. Okay. So again, everybody, my name is Kara Hall from AQUIA. I'm a Senior Product Marketing Manager. Thank you so much for joining us today as we cover little state, big design dreams, how Rhode Island refreshed their digital presence. Just to give a quick overview of everything we're going to be covering for our agenda today, I'm going to give a brief introduction into the current environment or common issue that many people see. And then we'll dive into the case study and the state of Rhode Island, and I'll pass it off to the OOMF team then. And then finally, we will close with some panel discussion with Q&A, mostly focused on answering those questions that you can submit throughout their presentation at any time. So diving into the current environment. So we know that it can be challenging to manage hundreds to thousands of sites. And then when you add in the factor that some of these sites are multilingual or regional sites, both with unique information, it can become even harder to manage all of those large number of sites. This often leads to a challenge that many state and local governments face when delivering their digital experience, that challenge being site sprawl. With all of these sites to manage and often small teams to manage them, it becomes very easy for the number of sites to continue to grow and reach an unmanageable level with information across all of them being different or unique. This is a challenge that the state of Rhode Island face as well. So now I'll pass it off to Jack, who will walk you through how the state of Rhode Island overcame this challenge with the case study. All right, thanks so much, Kara. Hi folks. Thanks for everyone who attended today. My name is Jack Cartman. I'm the head of delivery of at OOMF and served as the project manager on this particular engagement with the state. What I'm going to be walking you through is the first half of the AQUI Engage Award winning case study for the state of Rhode Island. I'll aim to cover a brief overview of the situation, the challenges, some of those proposed solutions, and some of the contributing success factors. Then I'm going to pass it off to my colleague, Ben Hamlin, Drupal Engineer and League Architect for the project. We'll dive into a little bit more detail around the implementation. All right, next slide, please, Kara. Thank you. All right, so let's talk first about the background of the situation that we were facing. As Kara alluded to upfront, site sprawl is a big issue for many multi-site platforms regardless of whether you're in state government, higher ed, etc. And the state of Rhode Island was really no different. The status quo for them, if we take a look at it, was really a bunch of state agency sites, 99 of them to be exact, spread across a number of different sites that really led to a lot of inconsistency and a lot of key areas. First one being technology stack. So in taking a look at the landscape, there were some sites that were built using ASP, there were some sites that were built using PHP, and a lot of this inconsistency contributed to high levels of inefficiency in maintenance practices, standardization of the state's web practices, and increased level of costs. The next thing that was a key contributor was varying levels of proactive maintenance. Some sites had been kept up to date, other sites may have been more neglected, and it just caused the potential for further vulnerabilities. Visual aesthetic was really key. Many of the sites across the state's presence lacked consistent look and feel. You can imagine there are 99 of them. There's a lot of different visual aesthetics that we're competing with. And as a result, it was hard for folks to understand sometimes whether or not they were actually on, sorry, set a poll pop up, whether or not they were actually on a government website, or whether they had been redirected perhaps somewhere else. And then finally for state content admins, content flexibility was really key but unfortunately also inconsistent. Content admin permissions and contact creation really varied from site to site based upon how they were built. And as a user, a Rhode Island resident, it was difficult for a user to sometimes find the information that you were looking for. So we faced a couple of challenges and those challenges are that we, one, we needed to rectify the issue by bringing all 99 state agencies in under a single platform umbrella. Two, we needed to establish a scalable design language that could work for all of the agency's websites. And then three, we needed to establish a centralized publishing and notification system that was suitable for the entire network, let alone an individual agency. So needed to be scalable. Next slide. And then the pandemic head. So we have all of these challenges. We have all of these things that we're facing in our situation and COVID-19 happened. So as I'm sure many of you have experienced, it really impacted a lot of operations on a number of different levels. And this shook things up for us a little bit. And it moved the goalpost forward from a delivery standpoint. We had a plan in place for when we were going to roll this out, but this created a heightened level of urgency to get a COVID-19 information portal launched as soon as possible. So when we talk about the need for better, faster, more efficient communication, there's immediate need to reach many more Rhode Islanders, given the critical information that needed to be disseminated by the Rhode Island government. Via increased level of translated languages or accessibility options. Next slide. The good thing is though that this was a challenge that we were facing, but despite this unexpected and sort of ever changing nature of the pandemic. The original solution didn't really need to change at all, because we had a high level of confidence or an original approach. The first being the services selected from Acquia. So first and foremost, given the sprawl nature and what Kara was alluding to earlier, Site Factory seemed like a natural fit for this. We could bring all the sites into a single Site Factory platform. It allowed the states and its many agencies to deploy new sites quickly with confidence and have a single hub management administration. The next was EDCDN and this was a service that we had been considering and I think was kind of deemed an absolute necessity following COVID-19, because things were changing at a moment's notice. We were delivering critical, very important information to Rhode Island residents over the duration of this pandemic. Once we have the COVID-19 information portal up and any option or idea of latency in delivery of this critical information was just a non-starter. So Acquia EDCDN provided a good solution there. And then finally, edge security. The very nature of Rhode Island being a government body makes them a target to those looking to spread information, cause harm, you name it. Security was a really critical component of this to ensure that our Rhode Island constituents were able to trust the information that we were communicating. Alright, next slide please. So the second half of that solution was creating a universal design system built specifically for the state of Rhode Island using Pattern Lab. And this really spoke to helping ensure that there was a consistent look and feel and consistent presence across the entirety of their 99 agency sites. So the users had a general sense of where they were, who they were getting the information from. And we named it Kohog. So if many of you or some of you aren't from the New England area, it was our little nod. One, because we were working on the state of Rhode Island, but I think too, if you don't know Kohog, some of you may have heard it from Family Guide, but it's a little hard shell indigenous clan. And they're really tasty and I highly recommend if you're ever in the area. But anyway, so what kind of comprised this design system? Well, five key components, I would say the first one being color themes so site authors currently can go in, they can choose from five color themes that supports light and dark mode viewing. Each theme rigorously tested to conform with WCAG AA. And in some cases, depending on the sites themselves, AAA standards, and each theme was based upon a palette of 27 colors and 12 transparent colors. So a lot of options available, but stuck within, I would say, a consistent look and feel across all of them. User preference site visitors can toggle between light and dark mode as I alluded to, or use their own system preferences with adjusting font sizes, line height, word spacing, default language. There are a lot of different ways that people can digest and personalize this content to ensure that they can read the information appropriately. Mobile first, a lot of our users were coming on mobile devices. Each design that we did for Kohog. Treats the mobile experience as a first class counterpart to desktop so oftentimes there can be a drop off between the quality of information being able to be delivered or the experience from desktop to mobile. We started with mobile first to ensure that that quality was consistent across pretty much any device that you're going to access the sites from. Fourth being accessibility. Every design pattern is super accessible for screen readers, mobile devices, color contrast keyboard nav navigation semantic labeling and all text enforcement. They all contribute to highly highly accessible site, regardless of whether you have the largest sites or the smallest agency sites. We also added extra labels and help text to have been added to create context to actions while also following best practices of use of aria attributes. And then performance aware. As I spoke to earlier, they need to get this information of folks quickly. Each page is given a performance budget so design components are built as lightly as possible. They use the least amount of code and relying the smallest visual asset file size as possible. All right, next slide please. So, we've got this great new solution in place for the state. And we're going to Ben's going to speak a little bit more about how we actually got there and how we actually build it but now that we have it we're going to fast forward a little bit. How are we going to be successful. Well, we needed to start with a partnership approach with the state, and that was the biggest factor I think, as far as ensuring that we got this done the right way, the right time. So, clearly defined MVP must have for any project. The accelerated timeline made that even more critical, and there's little margin for error before the launch the COVID-19 information portal. A dedicated engineering team needed to immerse ourselves in the world of Rhode Island's agencies truly understand the scenario from the largest agency down to the smallest. So we knew that we were building a platform in an infrastructure that was going to support any agency size. A commitment to a phase delivery approach. That wasn't going to happen overnight. 99s a lot of sites for us to be able to transfer in a short period of time so we knew that we needed to face this out needed to have a prioritized site rollout plan. What is the most critical information that needs to be basically disseminated as quickly as possible. And we knew that happened to be the COVID-19 information portal. There are many voices to be heard in any size government and I would say yes, even in the little state of Rhode Island. So, while everyone's voice is certainly equal in say we're dealing with 99 different agencies as well as other governing bodies within the government who have a hand in this process. So someone really need to be the primary decision maker for the state to ensure that we were able to make decisions move quickly. And we are really fortunate to have Robert Martin, who is the web development manager at the state of Rhode Island and a few other select advisory team members on their side to help be a really strong partner in pushing things through and making sure that we were maintaining momentum. Communication cadence. The same teams needed to be in lockstep. As I said, we are all experienced a lot of new information being disseminated to us. Things were changing on a daily basis. It was crucial that we were able to adapt pivot and ensure that this new platform will be able to support the information that we'd be communicating to our constituents so talking multiple, multiple times a week over the duration of this engagement. And then the final thing I would say is a really responsive and supportive aquia team, which we had the team team from aquia was a fantastic partner throughout the duration and build and continues to support our ongoing maintenance of the application. All right, next slide please. So, where do we net out. Well, we had some really good immediate results and this is an ongoing evolution of the experience there still I think we've got over 70 sites migrated so far there's still many more to come, but so far we've seen some really positive results coming out of this so immediately paid speed 300% improvements in page load times compared to the legacy systems site deployments new site deployments are achieving 96 to 99% lighthouse accessibility scores and performance scores consistent above 90%. This is huge. And one click deploys one click deployment, allowing us to launch in minutes. It's been really great. Okay, so next slide please care. Thank you. This is great system in place. How do we not repeat past mistakes. We don't want to go back to where we were before. And how do we avoid falling back into old habits. The first thing is ongoing performance maintenance, ongoing performance maintenance, and with aquia site factory, it makes it really easy because instead of having to worry about doing ongoing maintenance for the sites, the maintenance that we're doing for the umbrella site factory environment is able to disseminate those updates and proactive updates I should say across the entire network of sites. Isolated feature development, we want to make sure that anything we're developing is not having an impact on a broader part of site audience and we're testing thoroughly before anything rolls out. This is the balance of agency autonomy and guardrails. One of the really nice things about that design system. And what this was built upon is it allows a lot of these agency content admins to have the autonomy to run the agency sites the way that they need to update the content the way that they need to, but we have a level of confidence at an umbrella level that it's going to adhere to both our design standards, as well as our practice standards. It also goes hand in hand with the pointed training of key state content teams and is team members who provide a lot of support beyond some of the regular maintenance that we do over the course of of a monthly basis here at home. And then regular consultation from the equity team site factory, as well as equity services are constantly being upgraded new features are being added. And there's work being done on them, having a regular cadence with them ensures that we're one step ahead of any changes that are made. It can understand the impacts that it might have to the actual platform. So, without further ado, I'm going to pass it over to Ben Hamlin, who's going to walk you through a little bit more how we put this platform together. Awesome. Thanks, Jack. Appreciate that. Thanks Cara. Thanks everyone for joining this morning. I'm pretty excited to share kind of the under the hood here of how we, how we got this site out. So I wanted to start at a high level and just talk about what this life cycle looked like. I did want to know with with Jack's mention of the cohog that none were harmed during the development of this, this ecosystem so I just want to make sure everyone was was clear on that. So I want to highlight the phases that that we that we went through to execute this project. The first is discovery. And then we're going to talk about migration specifically since this was such a key element of of what was extended to the state and enabling them to to migrate sites in that phased fashion that Jack mentioned. We'll talk a little bit about launch, not as much as we typically do. We're still in maintenance, which I think is one of the most important phases. We're still in the maintenance phase. We continue to be here we go two years out. And of course that phase is typically the longest of any project and this is no exception. And what I want to focus on as we go through these. I want to focus on some of the key timing and the ordering of deliverables that enabled us to execute. So with the most efficiency, given the escalated timeline that was introduced back in the summer, when COVID first really reared, and we knew that we had to expedite this work. I want to highlight the technical approaches that we took for maintaining this distribution. It's different than a typical Drupal maintenance project, given that we are dealing with the volume of sites and the ecosystem that site factory provides. And then I also want to focus around the decisions that were made that allowed us to extend some level of independence to not only the state itself, but also to the individual agencies. Next slide please. Discovery started actually really early with this project. If I recall anecdotally I think that this was kind of, this was an idea that had been floating around in a few folks heads for a number of years. And the thought of solving this, this sprawl problem with a Drupal distribution had kind of been fermenting for quite some time. The discovery phase, you know, was was fairly extended. But as we got closer to development, the key elements of discovery that started to happen. I really wanted to highlight here. I think this is really relevant for folks. You know, to be frank, those of you who are evaluating a new build a new approach are kind of in your own discovery phase right now and this is part of that. The key elements and the key milestones here for our discovery phase was that we began interviews and content modeling workshops with key stakeholders. As you can imagine, across this large sampling of agencies, we needed to find common ground for for what the content types in this Drupal nine build we're going to be. So we needed to find that commonality. We also needed to talk about flexible content. We wanted to extend the most flexible page editing system that we could knowing all of the use cases that we had to cover across all of these these content needs of the of these agencies. Of course, we had to identify a core feature set. You know, some examples include site search ability to execute translations, and as well as content moderation. We needed again to align on what those features are going to be. So, you know, over the course of discovery as we got closer to development, what these efforts produced was a final content model. A final site architecture, as well as a build approach with with how the development team was going to be able to execute on these features. So this is really key here this last point, the early sign off that we received on these items. It allowed for the initial site configuration to commence very early in the project lifecycle slide please. Thanks. So I'm going to talk about design and configuration in parallel. And that's because that's how these phases were executed. That happened in a traditional software development cycle. But it did here. And again, I want to highlight the fact that we had a content model that was approved that we could design towards and also build towards. And the beauty of that, that content model is that we can execute on some basic site configuration, while the designs are being finalized and being approved. And the development team doesn't even need to be aware of the designs, since we know what we're building. So the design itself. So we're using a custom Drupal distribution. But it stood up alongside of an atomic design system. And Jack mentioned earlier that's pattern lab. The pattern lab has a twig template renderer which essentially essentially generates the template files that we use in a Drupal system. And it's interesting to note that actually, since we began the project the pattern lab, twig template renderer is actually not being maintained anymore. However, we are able to migrate to alternatives such as storybook. There's other design systems that exist that would allow us to migrate away from pattern lab without having to impact the primary Drupal distribution. So the fact that we chose pattern lab in a non Drupal system to execute these designs in this was important. This allowed the designers and the UX team to work outside of Drupal. And again in parallel with the development team. So those tracks could continue at the same time. Designs were approved. And once designs were approved the component markup was actually developed and tested. So all the accessibility all the performance tests and QA that we needed to perform on these designs. Again done outside of Drupal at the same time that we were developing kind of the framework for the Drupal distribution itself. The final result of this phase from the design standpoint, produce twig templates that were Drupal theme ready. Another important note, the components from the design system that were generated. Again they're not Drupal specific they can actually be used and applied in some other web framework. So they can be used outside of Drupal, including standalone, and they can be used to demo just the themes themselves. So while this is all happening. I wanted to talk about the configuration that was happening from the development team side. And we're starting to develop a custom Drupal installation profile that includes your standard custom modules developing the custom theme, as well as custom features which I'll get to a little more in a little bit. We started implementing the shared content types that had been derived from the content model, as well as the flexible content components that were identified. And we implemented those using a combination of paragraphs and layout builder. We started executing on shared site configuration so some examples of these are SEO elements such as meta tags, URL aliases, XML site maps. We started working on the menu system. We started working on custom theme settings to allow for the selection of those different color palettes that Jack mentioned earlier. And other core Drupal elements such as user roles. So we call out here for this, for this build, and how it differs from a traditional Drupal build. We can't rely on Drupal 9's config management system, the way that we came with a single site. So in order to execute updates and other shared configuration updates as we're maintaining this system, we have to use a combination of Drupal features as well as update hooks. And again, what that allows us to do is maintain the core site configuration, search, user roles, etc., while also allowing autonomy for the individual sites. So for example, some sites could introduce a custom view or implement a feed from an RSS, from an RSS source, and we don't want to clobber those things when we're applying security updates and general maintenance. So that was the strategy we used. So we're not using a standard config import and export as you would in a single site. All right, we can go to the next slide please. Ah, so development. All right, this is my slide. This is where I'm most comfortable. So I'm just going to go through some of the key components that we integrated for the suite of sites. And of course, there's a lot going on here, but the first call it is the actual integration of the design components with the custom theme. Once the designs were finalized, we were unblocked from that standpoint. And that's when we really started to be able to marry the Drupal theme and the pattern lab work that had been done and start to see that work come together. We implemented an SSO single sign on solution as integrated with the state's Azure instance. So this allowed the state team to continue their access access management control outside of Drupal, essentially maintaining the status quo that existed. Users are assigned to one or more sites in the network. And then the roles for those users can vary across sites. So the actual role assignment is still managed within Drupal by that particular site admin is administrator. But again, it allows the authentication piece to live outside of Drupal and be managed by the state in one place since they're, you know, authenticating other sources besides this distribution. We had to do some custom development within Site Factory itself. Site Factory provides a series of hooks and other automatic code execution that facilitates the maintenance and the upgrades of this group of sites all at once. So we've talked about the dashboard and single, single click site creation. We also have the ability to stage sites down one or more from production to do testing and QA. Again, we're writing update hooks and we're using feature imports to allow for global site configuration to be updated while the existing site config anything that's unique that's been introduced is unaffected. We also developed an automated backup script and that executes prior to every deployment that we do on this and this environment so that we ensure we have database and file backups in case we need them. And that was done using the Acquia Cloud API. Another key feature of all these sites is global site search. So that was integrated with Acquia Solar Search on top of Site Factory. It's using Acquia Connector and Acquia Search. And each site connects automatically as soon as it's spun up to its own unique solar index. So right out of the box, as soon as you spin up a site, you've got enabled solar search and it's all pre-configured and ready to start indexing content. Translations. We provided two translation options here. Drupal Core, so multilingual out of the box with Drupal. It's more of a manual effort, as I'm sure some of you are aware. But we're not restricting languages, whatever languages need to be added and enabled can be done. I've seen example of that on the COVID site. I think it has the most enabled languages of all the sites that have been deployed. And those new enabled languages automatically show up. There's no additional development that has to happen. The site administrators just have to enable the languages. The second option for translations was a simple Google translate integration. It's more of an automated but still configurable option to allow the site admins to control which languages are available. Content moderation workflows. So, you know, almost all of the agencies had some sort of requirement for content moderation. So we simply established a standard editor publisher set of roles. All the default content types are opted in when the site is spun up. Key here, we're not forcing this on agencies, right? It's not a requirement for a smaller agency that only have a few folks writing content. They can bypass that system easily just by assigning the publisher role to all their content editors and then essentially the workflow is moved. This also provides a content moderation dashboard and email notifications for those users. The content syndication API, this was alluded to a few times about the need to disseminate information across this vast network of sites quickly, efficiently. And so we developed the custom content syndication API to fulfill this need. We leveraged Drupal's core JSON API as well as the QAPI and developed some custom modules for publisher and recipients. And that facilitated two-way content syndication for all the sites on this network. And it's, you know, the basic use case post a notification to the main hub site. And that notification is queued up and delivered to all of the sites that have subscribed. That's running on Cron. So it's not immediate, but it can be initiated immediately if the need did arise. And then with the edge layer CDN in front of everything, the ability to clear caches across all these domains, you know, in the scenario where we did need to publish that content immediately. And we can't talk about a Drupal build without talking about the web forms module. It's still in contra, but boy, I don't think that's going to last. Maybe I'm wrong. So we did include web forms in this build for obvious reasons, provides web forms by default. We use the web form node module to automatically create pages for each new form that was that's built within a site. And then we provided integration with the web form encrypt module. Again, that's an opt-in. It's not a requirement, but web form encrypt is available for those sites that want it or that perhaps need it as well. All right. Time check here. Good. All right. Next slide, please. All right, migrations. We needed migrations to be usable by non-developers. We needed them to be repeatable because that first pass isn't always exactly what you were looking at, looking for. We developed a well-documented process that includes training and post-migration quality assurance using some automated tools to ensure pages were brought in, ensure that redirects were brought in. So that was a really key part of this process. This enabled the content teams to execute migrations independently without developer support. The process under the hood, it's essentially it's scraping sites. It's scraping HTML and files from the source site using a combination of Drupal core and contributed migration modules along with some custom code. And again, this is really key. This is source site technology agnostic. This scraping process, as long as the pages can be loaded, this migration process will work. And again, it creates automatic redirects during the migration process for both pages and files. And then in an individual migration instance, the completed migration is handed off to the state agency and they can perform final approval and any additional content entry or massaging that they need. And next slide, please, Kara. All right. We built this thing. And now we're going to launch sites. Typically, this is a big day for the dev team. But within this ecosystem, we're not really needed. And dozens of sites have launched on this platform unbeknownst to us. And that's the way we would like it. Using Acre Cloud Edge, of course, DNS control, the state, it's at the state's discretion when they launch these sites and when they go live to the general public. And then we'll talk maintenance. Again, we're still in the maintenance phase. These things are still happening and continue to ongoing Drupal core and contributed updates. When we first launched, I believe we're on Drupal 9.0. And we're up to 9.5. We're starting to plan what this year looks like with a migration to Drupal 10. Of course, as with any maintenance days, we're adding features, executing bug fixes, as well as platform updates. Recently a PHP update. And Acre updated their MariaDB instances. So kind of those standard things that are happening with any Drupal maintenance phase. Again, just to drive this home, all of these updates are executed within one Drupal profile, one distribution, one code base. Update hooks and feature reverts are triggered during each deployment. And that ensures that the configuration that we're relying on is maintained. Right now, statistically, we're averaging two deployments a month. So here's here's my big bullet. This is my big closing slide. There's over 100 sites on this platform now we talked about the 99 but there's a lot of demo sites, there's documentation sites, there's training, etc. So there's over 100 sites. They're all updated simultaneously. And that deployment window takes two to four hours. So our average maintenance two to four hours 26 times a year over with over 100 sites is where we net it out. Thanks. I'm going to pass it back to Kara so that she can discuss some other benefits of Acre products that were used by the state. Awesome. Thank you, Ben. So, as he said, awkward solutions offered a variety of benefits to the state of Rhode Island. I'm going to start. Oh, better hit next slide. Sorry about that. There we go. I'm going to start with awkward site factory, explain a little bit about it, and then dive into the benefits of edge security and edge CDN. So again, some of the benefits that awkward site factory provides is that you can launch websites faster. You can quickly create those sites with a single click and then get them launched faster than ever before. There's also governance. You can assign user based roles and permissions so that teams have to access only their responsibility so you're not overextending permissions to anybody throughout the team. And then last but certainly not least of the benefits that I'm going to cover today is that reduction in maintenance costs with one central dashboard to view monitor and manage everything in one place that maintenance really becomes less so you can save money there and those maintenance costs. So then diving into edge security, the main benefit that our edge security offers is minimizing the risk of security incidents. You can see threads ahead of time. You can protect your sites and prevent attacks and more with the variety of solutions that edge security offers. And then last but not least we have our edge CDN. It has create you can create operational efficiencies you can route content through the best available pass speed up app delivery and ensure availability and even more with creating those operational efficiencies and then monitor website effect effectiveness with this you can cut low times up to 50% for static and dynamic content and much much more when it comes to the websites effectiveness and you can see how well it is performing on the back end with it. So with that those are the benefits that the awkward solutions can provide a little bit of more of a high level and then Jack and Ben both covered the benefits that are provided in a very more specific case study with the state of Rhode Island and it's always great to hear about those. I'll pass it off to you to kick off Q&A. Thank you, Jack, Ben and Cara. So we do have a few minutes left and would like to take this time to answer any outstanding questions. All right. So we have our first question here with 99 agencies platforms. How did you get design system buying across all stakeholders. I can take a first pass at that. I think Jack can chime in too. I think the two things I wanted to call up from a development perspective were the flexible component options. There were a couple of dozen I'd say around, you know, 20 to 30 components options, everything from inline image galleries to press release snippets news articles. I mean, there was, you know, a really vast options that for the content administrators. And so that flexibility really allowed us to cover a lot of the content use cases that had come up in discovery. So I think that's a that's a really big piece of that. Yeah, I would I would say the latter on top of what Ben said. Another piece of that was design is always a very, very subjective discussion. A lot of people have a lot of different preferences when it comes to what their design tastes are. So I think what made this really effective was keeping it very simple, but professional clean really helped buy in across across the board. I think some of those. You know, I spoke about it earlier but the idea of a design budget. Design budget kind of limits the amount of what we can do. And actually creates a really nice challenge for us to create a really phenomenal experience within that budget, but not overdo it with a lot of more. We call them like bloat assets that can be added to design with photography and animations and other things that well night and while might provide I think some nice visual appeal is not necessarily contributing to the function and features of the website. Yeah, and just one other thing to call out there and Jack mentioned at the beginning of his slides that the key partnerships that we developed with the agency. I know that personally as lead developer. You know, I wasn't in a lot of design conversations I didn't need to be the state and the project leads really took ownership of those conversations. They really made those amongst themselves, which is always ideal from the development side that that we can come come to a come to a final decision and see something that is ready to act upon. Instead of being iterated upon. I have another question in the Q amp a pod does also build components template, etc, and site studio or only and twig dash pattern lab or storybook. I know, although I myself am not currently working on this. We have a group of engineers that are working on an internal initiative to develop a component library. They're working in both react as well as in twig. And I know storybook has been has been surfaced a lot recently, at least in two separate projects that I've been working on. So I think the short answer Tyler to your question is yes, we do. And that is actively happening. Julia is it okay if I ask her a question. Absolutely take it away. Awesome. Kara, I have a question for you. What are some of the trends you're seeing with clients in the non government and public sector space that are doing their homework but are coming over to state and local gov. Yeah, I think one trend that I'm seeing today was actually shown in the case study of state of Rhode Island and this is a trend for everybody. Organizations are looking to streamline their site creation and the management of that and it's just a really big trend. We have lots of case studies on a variety of organizations across a number of different industries on our aquia case study resource page. And it just shows within those case studies that organizations want to quickly create new sites while allowing their teams to work on siloed from each other. So again, and at aquia we had a lot of our engage winners that were also highlighted doing this same type of transformation of being able to put all their sites in one place manage them from one place quickly spin them up and then giving their team the time to do the work that they need to without you know always relying on the developers to go in and spin up new sites. So, you're looking to see more stories that maybe aren't for state and local gov or maybe you want to read more about higher ed or retail we have a lot of this same trend in those case studies. Yeah, I've got another one for you as, as we were talking about plans for this year and getting prepared to migrate to Drupal 10. One of the, one of the thoughts that popped up was interested to know if there's anything. Anything in the pipeline for for site factory itself as an actual environment as we look at Drupal 10 and some of the new features that come out if something that we should be considering for for maintenance this year. In terms of updates to site factory for D 10 there are some things in the roadmap can't share those yet so we do have some things coming for site factory. But in terms of D 10 and working with aquia products you know all the aquia products were compatible with D 10 before D 10 launched back in December. And D 10 has lots of new innovations that people can take advantage of. There's a new front end theme all of arrow, and then there's also a new admin theme claro so admins can have a new theme to work in their starter kit theme generators. There's a streamlined core as some of those modules have been moved or depreciated and moved out of the core so D 10 has a lot of new aspects so if you haven't tried the new version of Drupal I would highly recommend testing it out or you know building one side on it or migrating one side and that's the good news about D 9 to D 10 the migration is super easy you can do it in five very simple steps. We have lots of resources on our website website outlined around if you want to read more about Drupal 10 in general and just find out more about those items that are outlined or if you want to read more on what that migration can look like. We also have blogs available on that and as well as support, if you want help with your D 9 to D 10 migration we're always happy to lend a hand. As I'm sure you guys are at oomph right. Yeah, I'm looking forward to, I'm looking forward to those the new features, the yet to be disclosed features. Thanks, appreciate it. I have a question for Jack or Ben if either of you want to answer. What additional trends are you guys seeing that might be relative to travel or transportation right now. Yeah, it's a good question. And I think it's within the travel and transportation space I think what I'm going to talk about is maybe a little bit expanded beyond that and can be in government higher ed etc it's kind of across the board but I think, you know one of the things that wasn't necessarily the impetus for this trends trajectory, but more I think it gave it a shot in the arm was when the pandemic hit the need to communicate to a much broader audience more quickly than I think we, we would have done in the past and I think that it goes back to one of the things I talked about earlier which was both an increased in height and level of translation needed, as well as an increased level of accessibility options. And as I said, the pandemic didn't start this trend, this has been a trend for a long time, but I think it really increased the need for it. And I think about, if I working back to maybe some of the projects and engagements that we've done in the past. There was always that kind of phase rollout approach where it was, let's get an English version of the site up and then let's maybe do a trickle campaign of next translation will be Spanish than something else than something else than something else and having these things right off the bat. It really broadens, and obviously it needs to be based upon data in your user base and all that other jazz but I think having more of those options available upfront makes you a much more sought after entity and platform right out of the gate versus a slow rollout of, basically opening the door to it to a broader audience group. Yeah. Absolutely. I think we're getting close on time. So I think Julia will pass it back to you. Awesome. Thanks team. All right. So thank you, Jack, Dan and Cara for your presentation. I would also like to thank all of you for joining us today. We hope that you found this webinar was informative and helpful to you and your organization. Thank you again for attending and have a great day.