 All right, hello, WordCamp. Good to see all of you. Glad you all could be here to join us for this keynote this morning. Apologize if you expected us to fly onto the stage and jetbacks, or possibly drive out the moon buggy onto this thing. I think Abby left that at home. But it's an honor and pleasure to be here this morning to talk with you about the web modernization project that NASA has been working on for the last few years. You're probably going to hear us shorten web modernization to web mod. We say that every single day. It's pretty much ingrained in our vocabulary about this project. But that project has started to produce some visible results to the world. Just last month, we launched what we're calling a public beta of the future NASA flagship website. So NASA flagship equals www.nasa.gov. So that's another thing that's in our language a lot. You might hear us say that. So beta.nasa.gov will ultimately be the WordPress-powered future of NASA's flagship NASA.gov system. We're running our final flight checks on that right now. We'll be launching out of date to be announced very soon in the future. Let's just say pretty soon, definitely not while we're here in National Harbor this weekend. So what we are here to talk to you all about today are the challenges that we faced along the way with this web modernization project and what we've learned along the way as we've worked alongside our users to make our dream a reality. And we're going to try to do that with a minimum number of government acronyms for you. So at NASA, what we do, we explore the unknown in air and space. We innovate for the benefit of humanity and we inspire the world through discovery. And if you follow any of our social media accounts from NASA, you know that our content creators are exploring, innovating, and inspiring the world through our digital channels every day. But our first mission into cyberspace wasn't in social media. It was actually with good old HTML back in 1994, almost a decade before WordPress was even a glint in Matt's eye. So see Brian Dunbar, really small and tiny print down there at the bottom. He's actually our chief editor of www.nasa.gov still to this day. So as you explore around the beta site, check for his name down in the footer. All of these sites that you're going to see, we have a lot to thank Brian for. So as the years and decades passed since 1994, our site evolved along with browser capabilities and web design trends. We started putting our agency's inspiring imagery front and center, culminating in our current website that first launched in 2015, which we all know and love, the classic. But as all classics, it's time for a shift. So help step the stage a little bit and give you an idea of where NASA is heading on the web and our digital platforms. We have a short video previewing what lies ahead. Boosters and engines and lift off of Artemis One. So that was a very, a teaser sneak peek at three new digital experience from NASA that is coming soon to a screen like your U and WordPress is integral to all of them at the center or close to the center of all of them. So the most obvious one is what referred to as, as I said, the NASA flagship. That's powered by WordPress. It's built to integrate the seamless with our sister site developed by the Science Mission Director currently operating at beta.science.nasa.gov. And it's pretty much a traditional WordPress CMS implementation. Users log into the WordPress admin, the dashboard, create content, tell their stories with NASA, and deliver that to site visitors coming to the flagship site. NASA Plus. One quick call out I'll do for the science friends. So they actually implemented this in a decoupled way. So while we kind of took the traditional route with our custom theme, the beta.science.nasa.gov, I think it's a really great example of how we took two different technical approaches to WordPress. And we're able to hopefully marry them together in an integrated web experience for everyone. So NASA Plus, it's NASA's new streaming service and an evolution of the NASA TV cable channel. WordPress serves as a control room functionality within that. So the way that works is we're leveraging the REST API videos that are on-demand videos and associated metadata and information about those videos are stored in a separate media digital asset management system. So WordPress, with the power of the REST API, we import ingest that information. Once it's in WordPress, we have control room users who are managing those videos, putting them into playlists, putting them into topics and categories. Then on the other end of it, the REST API is used again for the NASA apps team. Those are the people who are building TVOS apps, Roku, Amazon Fire. And they're using the REST API to absorb all that information and pack it into a TV or set top device viewing experience. And the third one in that video was the NASA apps themselves. These are the iPhone, iPad, Android apps. Similarly to NASA Plus, they are consuming information from both NASA Plus and the flagship, using the REST API to package that information and present that in the apps. Within the flagship CMS, we actually built a special iOS Android apps content manager. So NASA communications people log into the flagship WordPress CMS. And if there is a need to highlight specific stories, specific podcast episodes, specific NASA missions in a kind of way that is unique and curated specifically for those apps, they can do that within the WordPress CMS for the NASA flagship. Our goal is to basically build a WordPress mission control for the app, for NASA Plus, and for the web experience. OK, so there was a technology factor initiating this NASA web mod effort. So the current open source management system being used for NASA.gov, it was facing end of life situation at the time that the web mod effort started a few years ago. NASA, we took a look at the associated level of effort to upgrade that open source CMS and stay on that platform. And when we evaluated, it was concluded like this is a bit of a significant project. And the level of effort kind of opened up opportunity to look at other CMSs. And hopefully I tiptoed around that correctly. I come from Drupal. So JJ has to be very, very gentle with me and careful because I love Drupal. WordPress was actually the first time I was using it as part of my job was when I came to NASA about a year ago. And I love WordPress, but I also love Drupal, right? It's where I got my start. So that basically represented an opportunity for NASA to look at the CMS landscape and consider all these alternatives. We spent a year looking at the CMS alternatives. We looked at both open source solutions, commercial solutions. We gathered evidence about a bunch of them. We narrowed it down to a small handful. And we looked up and did some rapid prototyping with our users and our content creator users. Another factor was in that decision-making process and the evidence that we gathered was the amount of WordPress that was already being used at NASA. There was about 100 sites, 100 different NASA websites using the WordPress CMS by far the most adopted CMS within NASA. And so there was already some in-place knowledge that was distributed amongst the NASA enterprise around software developers. And so we considered those software developer user types as well. So the WebMod program, we were trying to instill a culture inclusion. Ultimately, there have been some small examples of this. We want software developers that are in the various field centers, the various NASA programs and missions. We want them to be building Gutenberg blocks, building their own plugins, extending the capabilities of the flagship WordPress CMS. So thus, knowledge acquisition and skill building is really important in NASA. So that was a factor in this evaluation as we looked at different CMS solutions. And so the work that this community does, to bring all people together, hold WordCamps like this, both big WordCamps and regional WordCamps, share knowledge, build the community, and be welcoming, and help people learn it, that mattered a lot. So thank you to the WordPress community for that. So as you might guess, at NASA, we aren't afraid of challenges. We boldly set out to do missions of incredible complexity. Artemis is a great example. So as many of you may know, with the Artemis program, our goal is to get to the moon again, to stay, and then use that as our launch pad, our gateway, to Mars, and the rest of the solar system. So Artemis began in 2017. And just a year after that, in our web modernization world, things got a little shook up. Congress passed a new law called the 21st Century Integrated Digital Experience Act. And of course, we have to make that an acronym, so it's the IDEA Act. This introduced quite a few new requirements for federal public-facing websites and digital services. But I think, as you'll see, a lot of these are common sense. And they're things that all of us should be doing with our websites and digital services across the board. But in government, we've got a lot of old sites. So it is a bit of an effort to get everything up to speed. But so what the requirements in the IDEA Act centered on is using the web design system that's designed by TTS and GSA. I have to give them a call out. It's an incredible design system. You can go check it out, I think, at designsystem.digital.gov. I think I maybe hear some folks in the audience from there. So we built our design system based on theirs. But then beyond that, every site needs to be meeting eight specific requirements. It has to be accessible, first and foremost, to users with disabilities so that everyone can access government information and services. They need to be consistent in visual appearance and design so that people know that they are on a federal government website, and we can help cut down on some of the spoofing and getting people confused on where they are. It needs to be authoritative. We need to make sure any information on a.gov site is accurate up to date that people know when they go there they can trust that source of information. And it needs to be searchable so that we'll get onto this with the NASA example. But when people go search for information, we have all this SEO-optimized government content for people to be able to find. And then it needs to be secure, user-centered, customizable, and mobile-friendly. So no big deal, right? We all do that with our websites every day. But at NASA, this was a bit of a tall order for us. So for the last three decades, right, we've been on the web since 1994. You're one of the first federal government agencies to get on the web. We've had a lot of teams across the agency in those three decades creating countless public websites on every topic under the sun and beyond. So for example, if you go search for the Apollo program, you're going to find tons of different NASA.gov sites and sub-domains all with incredibly rich content about the Apollo programs, history, recordings, pictures, videos. This is an incredible wealth of content. However, it's spread all over the place. And as you can see on some kind of more outdated sites. And so one of our goals with web modernization was to take that burden off of the user of going to all these different places to try to find all of NASA's information about a topic and bring it together into one authoritative topic hub on these different subjects so that users have one place to go. They don't have to keep searching across a universe of content. So this is one of the ways that we were really trying to make our information both searchable and authoritative for our users. I'll add to that that that's one another reason why that culture of inclusion within this program matters a lot. The teams and resources managing all of that information it's very decentralized. So in some ways we need them to be like extensions of the web modernization programs and feel included in both what we're doing and how we're doing it. Absolutely. So another challenge was that a lot of our content was filed away according to our very bureaucratic organization structure. So I don't know how many of you guys have memorized the NASA org chart. I haven't yet. I've been here a year and a half. I think people have been there 30 years and they haven't been able to memorize the org chart. So as we found through user research, tree testing, users are struggling to navigate to what they're looking for on our flagship website and elsewhere. Many are relying on Google or direct links because the nav menus end up being confusing. No one should have to have a PhD in astrophysics or memorize the org chart in order to find the latest information on a mission or any other topic. So those were the challenges that NASA faced in the Web Mod program was trying to solve a little bit. So we had users lost within a sprawling web footprint and new legislation from Congress asking us to fully modernize and consolidate NASA's information into a centralized place. So the response to all that was to form a Web Mod team under Dr. Jim Green, the agency's chief scientist at the time. So working with Blink UX, our team found thousands. Whoa, that was supposed to be you. I know, I've had a sore throat for a week. So that was supposed to be me losing my voice. So Dr. Jim Green, the agency's chief scientist at the time led this, was the first leader of the Web Modernization Team, Abby's here now. So, and then we started working with a company called Blink UX who helped us identify the thousands of external websites across the agency in an initial, a lot of that. The next steps there were to interview and survey members of the public and the site visitors and users who are coming to NASA's websites to learn about their information needs and experiences with our web presences. And we took our time with that. So that was what, I think a full year of user research of an extensive survey, one-on-one interviews. So this was a big part of our project, was gathering all that information that we could before we moved forward with the next steps. So in late 2020 and in the 2021, NASA began to work on the visual design phase of this project. This actually was running parallel to the CMS evaluation that I was referencing earlier in the prototyping phase. And that had a lot of benefits. So it was an agnostic approach to the CMS. It kept the design focused on user needs and outcomes instead of like the trap that's a lot of us fall into where we start trying to like solutionize things with WordPress. And here's how you would do that. Here's how you do that. It was free of all that, which really kept the focus on the true UX experience. And every element of that experience was designed and considered with accessibility. So in our interviews with NASA content creators, we heard over and over and over again that they wanted more flexibility and room for creativity on the flagship website. In fact, the perceived inability to be creative and flexible within the flagship will lead them to kind of building their own solutions on their own website and just furthering the problem of information sprawl across a lot of different NASA websites. But again, that was all driven by this need for bespoke storytelling options that they really, really wanted. So in all those interviews, eventually we started migrating to an atomic design system to deliver a visual language that NASA could use across its digital platform or also providing controlled ways of creative flexibility for storytellers. If you're interested in learning more about atomic design systems of the book by Brad Faust, it's an excellent read and I highly recommend you take that up. So that work became known as the Horizon Design System. Another acronym in our vocabulary every day is HDS. So you might hear us use the phrase HDS as we talk and that stands for Horizon Design System. So that was crafted to help NASA tell its story from the technical to the logistics. And so as we were working through the seamless evaluation process in parallel, it became pretty clear to us that Gutenberg would be a perfect fit for this. So in the design system, there's a concept of components and modules and those lended themselves to blocks in the Gutenberg editor. And then there's a further concept of it called templates which lended itself to block patterns within the Gutenberg editor. So at the time, as I mentioned, we had around 100 or so sites built with WordPress but they were all used in the classic editor so there was a little bit of hesitation and can WordPress really, really do this design system and bring that thing to life. But as we prototyped this thing and started integrating and testing the integration of the design system using Gutenberg to provide all these storytellic parameters and prototyped and tested that with segments of our content creator user base. It became pretty clear that the potential WordPress was the right solution for this project. Before we move on, I'll give you a really quick thing that I really loved coming on, learning about the journey that NASA and Blink went through to come up with this design system and you can see it on the left. We went through a lot of different options and iterations of our navigation that you'll see on the site, particularly the desktop version. And as you'll see, we tried a rocket booster kind of vertical menu. We tried a double-decker horizontal which is more typical of the USWDS, the web design system from GSA. And we actually landed on what we like to call the Murphy bed menu. And basically it opens up, right, comes out. I just love that name. I think it's adorable. So at NASA, we design amazing missions to go and do amazing things like explore the surface of Mars. But even with the best of plans, things sometimes just work differently in the real world. You fall into craters, you bump into rocks, you get dust on your sensors. In Web Mod, we had set out to empower NASA's content creators to tell their stories using this one cohesive platform in design. We had a great plan. We had everything mapped out, design system, a new information architecture, we were ready to get building. But once we actually started bringing in those users into our new CMS and handing them this beautiful new Gutenberg toolkit, we ran into a few bumps along the way. So by 2022, we were well underway bringing that horizon design system to life in WordPress, identifying existing content from the old CMS to migrate over and onboarding and training our first core group of users. We set up an internal help site for users. Great idea, right? Website.nasa.gov. We had frozen all of the new domains at NASA, but we like let ourselves have just one new one to help the users. But on that help site, we decided before we had even onboarded the first users to publish the full design system specifications. Every single module block and template with incredible detail. We thought this was a great idea. We're gonna have users be able to explore through this new design system, get familiar with their building blocks, and then once we bring them into the new CMS, they're gonna be ready to build. It did not totally work out that way. This backfired a little bit. So once users saw this whole finished product, over 100 pages of all these mockups and templates, they were a little hesitant to use the more basic MVP versions of those blocks that we had ready for them sitting in the CMS when they came onboard. Understandably, right, they wanted to wait until everything was ready. I want everything to look as beautiful as it does in these specifications and that I'll get to building. But with Agile Development, we could not wait for that. We needed them in the system today using and breaking what we'd built so far so that we could iterate and improve. And this gets to our point where we learned the hard way that our design system was our starting point, not our finish line for both us as developers and content producers, as well as our user base. So it was a massive variance in the types of content creator users we have. We have four new users in the CMS. Some of them are highly skilled, highly comfortable with Gutenberg. Some of them have never seen it before. So one of the things we learned pretty quickly early on is we needed to curate or craft a different editing experience or modify the WordPress dashboard a little bit to help users at their level and help them get comfortable with the design system and all these new tools and possibilities at their disposal. So like any user community, there are a lot of variance in the skills and needs and dreams of all these people. So one of the things we started to do was building a lot more pre-built block patterns within the WordPress dashboard. The idea there was like get people creating their stories, authoring something and publishing something as quickly as possible. So instead of trying to figure out with a blank screen, a blank editor screen, like which blocks do I use? Which do I put this one on top to put this one below? What's the order of all these things? How do I configure them? What are the variations of them? Basically some pre-built block patterns that were also like pre-filled out with some example content that they could start with and start manipulating and modify for their own purposes and business needs. So this should move some hurdles, but users were still a little bit overwhelmed. They felt like passengers on an airplane that were, we were building around them as we flew it. And as a result in the beginning, many of the pages started looking very similar in layout and common. That wasn't necessarily a bad thing, but not the intention of the design system. And so another key thing we did, and that really, really helped as we start, we have a team that we call the web contemporaries, which I basically refer to as application super users. And they bring a wide range of experience, they understand institutional knowledge, they understand content strategies, and they're really, really skilled with using WordPress, using Gutenberg. So they started leading hands-on trading and working sessions to build, pledges in real time alongside our users. It's a lot of community management. There's a lot of communication tools they did, internal blogs, newsletters, showcasing some of the great content some of our users were doing. What we found was the community really, really liked seeing examples of what their peers were doing. And then we started fostering that community of inclusion where those users were kind of commuting with each other and giving each other help, just like this community does as well. So this made a big difference. People liked hearing from each other and seeing what others were building. As they got more comfortable, users grew more vocal with their needs. And those needs didn't always align with the work we'd previously planned, so we just did our development approach based on their feedback and gave weekly demos of our work in progress. I'll also say that the web content producers, there's a lot that goes into web stellar telling. There's using the design system, how to make your content look good, but then there's also the accessibility information. And so we have all this kind of tooling in there, like there's accessibility checkers that help you monitor how accessible your content is before it's public. There's SEO analysis tools going on. It's a lot of information, like publishing stories to the web in the most effective way, takes a lot of data inputs. So the web content producers, they cover all of that stuff. They help make sense of all that stuff for the users who need them. And in a lot of cases, they've built hundreds of pages on behalf of NASA missions, programs, and projects who just need a little more help. And without them really being the first tier of support for this user community, sometimes they're coaches, sometimes they're just a shoulder to lean on, and sometimes they're just there to kind of psych the users up and encourage them, but they've been really, really assistive and critical in this process. And I'll say, this is kind of a recurring theme for us, where the technology part was actually relatively easy, and the really hard part was the people. And our web content producers, we've got a few of them sitting right here and more online. We couldn't have done this without them. They ended up being the linchpin of our entire project, because they were the ones forging those connections with the users, listening to their needs and bringing those back to the development team so that we could be agile and respond to what they needed that moment to get their content onto the next step. So once users started trying to adapt existing content and create new content with the blocks they had and not the blocks they were waiting for, and once devs started feeling freer to branch out and kind of deviate from the design system and really listen to what this user community was telling us and asking for now, we started to see the site and the contents truly come together. There was a little bit of refocus on the web mod, you know, strategic approach to this. It wasn't necessarily about the quantity of Gutenberg blocks that we were delivering. It was mostly about the quality, making sure those things really help people tell the stories in the specific ways that NASA desires and needs in a lot of cases. So as we build for GoLive, we started seeing users doing incredibly creative things with blocks that we never even dreamed of. One example we actually pulled up right here, it's the Meet the Block, which sounds a little bit like the Meatball Block, that's not what it is. It's a bunch of little icons that people can put under their big nice photo header. To highlight, it was built to highlight specific people on a given mission, which astronauts are on the ISS at any given point. So we were like, this is a great block. We built it to be flexible, to take different images, text, include little flag icons or not, and then the users got ahold of it. So they used it, you know, in the way that we had thought. So looking at the Mercury mission, right, which historical figures linking to their bios, but they also started doing some pretty cool stuff. We had not been able to build their Q and A module yet, and so they used it to build a really cool Q and A bar on their site. They also, we hadn't built, we had built a vertical social media list for them. We had not built kind of a horizontal one, and they wanted it, and they decided not to wait. They used the Meet the module to include their social media icons on the page. It's hard. So one of the things we discovered as we started building these blocks, and if you think about how you build these blocks, and as you, that starts from a original UX specification, it's a little bit challenging to keep the intention, you know, focused on that. So for example, in the Meet the specification there, there's a little headline that says like, at the station, well, you need editors and content creators, they wanna be able to edit that, but you can't, you know, that that means they can edit and put whatever they want into it. And similarly, the intention was like to be able to put this with like profiles of astronauts. Well, obviously, it's hard to just zero and narrow that to only showing astronaut avatars and images and only showing astronaut names. But that worked to our benefit, right? So by building this box in a creative way and a flexible way, folks were able to use it to do incredible stuff we could never even dream of. So as I said, right, it's easy. I'll put an asterisk on that. It's easy to change your CMS, but it's hard to change how you do web together, whether in at NASA, in your company, in your organization. This is a lesson that we learned once, twice. We're continuing to learn it every day, but the hard work was really unifying our internal user community who had been decentralized, all working on their own different websites and creating a shared vision for what's possible. So when we look at our different user groups, right? On the left, we've got our CIO or IT and comms folks who obviously have a big stake in the web presence. We have mission directorates from aeronautics to technology to humans in space and including the science mission directorate which had over half of our web footprint sharing the incredible science data and information coming out of all of our scientific research and discoveries. Then we had our 10 NASA centers spread across the US, everyone from Cape Canaveral over to JPL. They're also all used to having their own website highlighting all the incredible things that their center's doing. And then we have all those little agency websites all coming together into this mosaic of different stakeholder groups, all wanting different things at different times. And our job was to bring them together in one big user family, making sure that they were able to learn how to work together where they hadn't necessarily before to have one page on a given topic even if it was drawing from content from all across the organization. And that was the right thing to do so that we could present this one unified, sensible presentation of content out to our audience which ranges all the way from what you might think of normally with US taxpayers, educators and students but we have people coming from across the world to look at our website. No one owns space, right? We're doing this for the benefit of humanity. And this was really important for us to make sure that we had our website as accessible as possible to everyone across the world. So how are we going to bridge this gap and get people working together? We came up with a concept we called managing editors. So these were this first core group of folks we brought on board from every mission directorate. We worked with them to designate one or two folks who was their job was to get on the CMS first, understand the system and then start onboarding and organizing all of the different users within their part of the org chart, bringing them on board and learning how to work together. Some of these had already done that before. So I'll give a shout out to our aeronautics folks. They are incredible. They had already organized even before we came to the new website and they picked it up like that. But then we had other groups that had never worked together. And so these managing editors, this was not something they got paid to do, right? They had a full-time job and we were asking them to do all this extra work organizing and bringing their people together. And they pulled through. They've done an incredible job. Similarly, at all our NASA centers, same thing, same concept, we had those editors working to unify all of that content and all those users at their center, connect them up with the mission directorates. So I'm doing aeronautics at the Ames Center. I'm connecting back up with the aeronautics group at headquarters and we're making sure that we're bringing all of our content into one place. So this was a really key thing that we did where we empowered kind of our core early users to do that self-organization and they basically became an extension of our team. They ended up training themselves, a lot of the users, sending out their own newsletters, sharing information that we did. So to date, we've got 440 of those users onboarded to the new content management system. They've created 3,000 new pages from scratch. So every landing page that you see on the new site, we had no way to migrate that over from the old Drupal CMS. And so for the past year, people have been building by hand, including our own web content producer team, building these new landing pages for every active mission and all of these different topics across our agency down through the information architecture. We also worked to migrate 68,000 pages from the old CMS. That's not all of them, okay? What, there's like 100,000? It's a fraction. It's a fraction, 200,000. There's quite a few pages on the old site. It's been around since 2015. Every past redesign, they brought over all the old sites, all the old pages. So we took a different approach where we really tried to curate what we brought over, leave some of the older content behind. We wanna make sure that we keep an archive of it. And it's an ongoing process too. Like we had to mature the migration technique so we can start doing this on a daily basis. As we approach the go live date, we're gonna have to figure out how to do this, you know, in smaller recommends that as well. So that, as well, so that we can just avoid the duplicate publishing of content in two systems as we approach a go live. And as everyone who's done migration into Gutenberg blocks knows that's not really easy. And so we're still working out the kinks in that migration process, but we're getting there. So our takeaway, right? What is the, all these lessons, all these mini lessons filtering up into one big thing that we wanna leave with you today. We're here to build with our users, not for them, right? So the ethos of WordPress is for everyone. We need our CMS to be for everyone, but that doesn't happen automatically. It doesn't happen just by installing WordPress, getting your users accounts and letting them go wild. You have to be in the trenches with them, building pages with them, listening to their needs, making them partners in the journey, not just customers. So maybe that's a no-brainer for you guys. We had to learn that lesson here and we continue to learn it every day and get better at better at working with our amazing content creators at NASA. And so these are just some of the pages that were built by our hundreds of talented people who have already, they come from building award-winning websites, webby-winning websites across the agency and they trusted us to come into this new CMS and start using the tools to build these new pages. And we're really excited to now be working completely across NASA, across these different silos to tell one unified story to our global audience. Okay, so we're a moment away from taking some questions here, but one last thing here. Abby and I were not the only two people working on this effort, though I'm sure there were some days that we both felt like we were the only ones working on it. It took a huge, massive team of talented people of different types of skill sets and we wanna take a moment to share some things and give them some gratitude. It took a lot of collaboration and a lot of people put in a lot of sweat into this. We won't say it's as complicated as the Apollo program was, as Gene Cernan says here, but it was pretty complicated. I can say personally, I think for both of us, it is the most complex project I think we've ever worked on in our careers. So these are just many of the incredible people who have been working to be part of the web memorization journey over the years. We wouldn't be standing here without their hard work, so thank you to all of them. There's hundreds of them, they're now all represented on this slide. Some of many of them are here today. You can look for some of us wearing these bright orange shirts with the NASA Worm logo on them. Feel free to approach us. But we're still just one part of this wider NASA team, this wider NASA family, that's making that dream work in all of our missions, from the depths of the Earth to the furthest reaches of the cosmos. And we are just one part of the larger WordPress community, part of all of you here trying to make the CMS work for our users to make it do incredible things. And we would not be here without all of the contributions from everyone in the WordPress community to this incredible open source project. So thank you, all of you. All right, so if you wanna start taking some questions, let me tell you a little bit about the breakout session that's happening in the Annapolis room at 1015. Like I said, Team NASA and the orange shirts will be there. You can come to there and ask us technical questions. If you wanna sit with somebody and look at some code, how we did some things, like how we integrated the flagship WordPress CMS with the images.nasa.gov. So content creators can use those assets within their stories. You can do that if you want to surf the site with someone and see different parts of it, that's a possibility. If you wanna sit down and actually use the block editor, publish a page in a testing environment, a staging environment, and create a NASA story for yourself, that's something you can do as well. So please join us there in the Annapolis room at 1015. But before we jet off, we will now take a few questions. So I think there are maybe mics around the room. I'm not sure how, if Julia's here, how she wants us to take questions. Or you can just shout really loud. I'll repeat it. Sure, so the question, he's from another government agency and his question was how do we approve users to come on to the new CMS in the first place? How do we make sure that people are approved to become, have user accounts, go through legal, all of the different lovely review processes we have to go through in government to make sure what we're publishing is accurate. So we have actually a kind of an open door approach, which maybe is a little unique, but all of our mission directors and centers have existing really robust approval processes for publishing content. So actually before they even get to us, before they're even ready to put a new story into the new CMS, that story has already gone through all of the normal approval channels before it comes to us. So we were able to kind of leave that there for now as it was working and have an open door approach of, hey, if you work at a center or a mission directorate, you're a NASA employer contractor and you have a need to use the CMS, you're welcome in. Of course, like any site, we've got user permission levels, so we limit who has the ability to create in certain content types, who has the ability to delete content. That's all a little more locked away, right? But anyone can go and publish their own content and edit their own content. One other thing I'll bring up quickly is, what was I gonna say? No, if you have something. Go ahead. I think you might be interested in talking about Gutenberg phase three and the collaboration of that. That is what I was, that. Before you do that, so in addition, we do require our new users to go a little bit of, take a little bit of on demand training to get familiar with WordPress concepts using the block editor, what are post types, what are categories and stuff like that. There's also a concept that we're really interested in, which basically is role level, so different types of training to have additional capabilities, for example, to be basically the ability to be an editor versus an author. So as JD reminded me, we are so excited for Gutenberg phase three with all of those different capabilities for live editing together, like a Google doc in a WordPress CMS, how cool is that? All those different new tools that will be coming soon to WordPress and Gutenberg to be able to collaborate and actually probably move some of those approval processes into the CMS itself. So instead of doing all the drafting in a Word document outside and sending it through the approval process, starting to draft your story in the CMS and sending it through those approvals within the system. So that's the dream and we gotta make it happen. Other questions? Yeah, great question. So the question's on SEO and how we're accounting for, as we consolidate these different sub-domains into one place, how are we preserving existing SEO value and making sure our new pages are really easily findable by people who might be used to looking them in the old place. So we've just begun that consolidation journey. That's really this whole giant phase two of the project, but we're making sure that we're keeping those sub-domains on, redirecting ideally at a page by page level basis to the new pages so that we can retain some of that really rich SEO. One great example of this actually is the new beta.science.nasa.gov site. So previously a lot of that science content was published on the flagship but it was actually published in three or four different places, right? The Mars.nasa.gov site, the solar system.nasa.gov site and the flagship. And so one thing we wanted to do is decrease that duplication and make sure that as we migrated things over, we were migrating science content over to the new science website so that we could make sure users have that information findable and not lose their old bookmarks and links. That being said, we're probably gonna break some links and we gotta plan for that. Yeah, so part of the SEO conversation within NASA is just, quite honestly, it's just building awareness of it. It hasn't really had a whole lot of great consideration. The shift from NASA organization, structured, organized information to topical-based. There's a lot of awareness building we have to do around that and getting people who are telling their stories, publishing content to consider how users are wanting to find an interface with that type of information as opposed to how NASA thinks about it on a day-to-day basis. Great question. Is it open source? I knew that question was gonna be asked. Okay, I'll repeat it for the online. So is it open source? If so, where is it? If not, when is it gonna be? I was excited for somebody to ask that question. So as anywhere in government, of course, we have a long bureaucratic process. We're making code open source, but we're in the middle of that now. So hopefully soon we'll be able to share that code with the public. It's going through its nice approval process as we speak. Bottom line here is the intention and the spirit of the web modernization program. Just like NASA's original charter to share what they learn with the world. And to some degree, releasing the stuff that we've been building, the blocks that we've been coding as an open source, in an open source way as an extension of that ethos. I don't know if you wanna mention the work that your folks have been doing outside of the NASA project on the US web design system theme. Yeah, so one of the things we've learned about, as Abby mentioned, a requirement we have in the IDEA Act that I mentioned, accessibility, consistency, search security, all that kind. And then it's funny how it's phrased it. It's almost like the ninth requirement. And also federal websites must adopt the US web design system. So it's kind of interesting. We had this UX specification, which was very specific and the US web design system also kind of has a lot of specificities. So we had to figure out how to bridge all that stuff and integrate it within WordPress block editor system. So we learned a lot about that and that work has resulted in a theme product that my company's been working on called CivicPress. And so basically what that does is bring the US web design systems to a Gutenberg ready full site editing WordPress theme to help public sector agencies with their web modernization. And if you wanna try an early alpha of that, go to CivicPress.us. You can launch an environment on InstaWP with that. Thanks for letting me plug, Abby. Yeah, absolutely. Go ahead. Can you share a little place in a page or a template? And finally, how to ensure that the content creators create accessible content? Absolutely. So the question was, how do we bring in accessibility everywhere from when we first build the block to educating our users on how to use that block in an accessible way? Great question. Obviously something we really care about. We had actually a whole section on accessibility that we had to cut because we didn't have enough time, but we would love to give a talk just on that part of our project in the future. So we worked with a company called Equalize Digital. They have a free accessibility checker for Gutenberg and WordPress. And we actually worked with them to actually expand that tool, the free version of it, to make sure that everyone could use some of these features we really wanted to have at our content editors disposal. But we know that automated accessibility, the things that an automated checker can check, is I think about a third of all of the different requirements under the WayCag, and I forget the whole name of it, but the Section 508 or WayCag standards for accessibility, we wanted to make sure that we were actually meeting the full extent of the law and not just checking the box. So we had manual audits go through all of our, all of our whole page-level templates, every single block as we develop it to make sure each block in isolation, both on the back end and on the front end was fully 508 compliant. Because we don't just care about our external users using the site, we also care about our internal content creators who are using assistive technology, making sure that they can use the site to its full power, as well as our external users. So great question, we have more work to go, but. Yeah. Yeah, Equalize Digener, they were a great partner in this. We really couldn't have done it without them. Like they helped us on various levels of the WordPress solution architecture, taking a look at the accessibility elements of all those things. And Amber is gonna be at the breakout session, if you wanna see accessibility checker pro in action with the WordPress CMS that we built for NASA, you can do that there. All right, so I'm looking back at Matt there. I'm gonna call you out how we do it on time. Do we have no more questions or one more? One more, one more little question, if anyone has one. Otherwise, please come join us in the Annapolis Room at 10.15 and we will get hands on with y'all. Thank you so much. Thank you.