 Hello, everybody. Welcome. Thank you for sticking it out with us. I know this is the last talk of the day before Matt's, and it's been a long couple of days. But excited to see you all here, excited to share some of our thinking. A few years ago, I had the opportunity to speak with a prospective client, somebody who is interested in working with us. And as we got into their current state of affairs, a platform that they were working on, as we started to talk about some of the challenges that we were facing, one of the questions that came up was the way that they published content. What does your process look like? How long does it take? What parts of it give you anxiety? What parts of it frustrate you? And how can we make it better? And as we went through that conversation, found out that it took them, on average, about two or three weeks to publish content from ideation until it got published, that's kind of a long time. And whenever we hear that, always start getting that little spidey sense, is there some very bureaucratic process here that we can maybe help build some tools around but isn't fundamentally going to be able to fix, started to get into that and found out it, in fact, only took them about two or three days to go from creating their content to having it ready to put into their CMS. The remainder of that time was them working in terror on a staging site, putting in a little bit of the content, previewing it, breaking something, putting in a little bit more, previewing it, breaking something, fixing it over and over and over again. And it took them the better part of two weeks to work through that for some reasonably long-form content, 1,500, 2,000 words, some graphics, some images, some video. And it sounded absolutely awful. They worked on the site for their living. These were professionals whose jobs were to manage the site. And they went to work every day terrified that they were going to publish some new piece of content, completely break their company site and have to deal with all of the fallout that came from that. That's an extreme case. And fortunately, they aren't a client that used WordPress at the time. So just by moving into WordPress, we made things a little bit better. But it's an example of the kind of challenge that over the last few years, I've heard more and more and more of as we've talked to folks who use WordPress. Back when I first started using WordPress, I think I figured out I installed my first site 18 years ago, back when Kubrick was at a fall theme with the cool little blue gradient that really drew me in. WordPress used to be known for being easy to use. When you talk to people about how you should build their site, they'd say, go to WordPress. It's easy. It makes publishing content simple. And we've kind of fallen away from that. Over the last few years, I've had a number of conversations with folks, including one yesterday with somebody here, where they said things like, we need to stop telling people that WordPress is easy to use. It isn't anymore. And we're setting poor expectations for them when they get into WP Admin and they start trying to publish. And they realize that things are a little bit harder than they're expecting. And that's not OK. This is a platform that's meant to democratize the web. It's a platform that's meant to make content publishing easy. It's a platform that's meant to help you do your work instead of a platform that you live in terror of using. And we need to do better there. So Helen and I have the opportunity to share with you all today some tips, some tricks, some examples that we hope will help foster and inspire a little bit of thinking about how exactly we can do this. None of them are huge or massive changes or whole new ways of thinking or designing editorial that user experience is. It's more about becoming mindful of the sorts of things that can be easy to diminish sometimes. There's not often a lot of folks using these editorial tools compared to the folks who are consuming the front end as a reader or as a customer. But they're still very, very important. They're the folks who evangelize the platform, the folks who tell their colleagues, their bosses, their new bosses when they switch companies. I used WordPress. I had a great experience. We really need to get this in here. Or the other way, I've used WordPress. It is a little tough. Maybe we should cast our net a little bit wider as we think about the tools that we use to do our day-to-day work. To begin, I wanna play a quick little game with y'all. So we'll go through the directions in a second, but it's easy. Everybody just has to raise their hand. Not gonna call on anybody or put anybody on the spot. The rules are pretty straightforward. I'm gonna show you a screenshot of the block editor, show you two different reader experiences that use a little bit different themes in the front end, but are from that exact same block editor screenshot. And your mission is to guess which one belongs to the screenshot of the block editor that I created. Which one matches the editorial side of things with the reader experience. So this is a block editor. Super simple example. Take a second to look at it. Take a second to note what stands out to you. What makes this easy to remember or what makes this recognizable? So here are two different front ends, and this should hopefully be pretty easy, or my next slide's gonna be kind of obnoxious. If you think the screenshot on the left is the front end from the block editor experience that I showed you, raise your hand. And if you think the screenshot on the right, raise your hand. Adam, you can't raise your hand twice. Why not? You're right, I didn't put it in the rules. So that was pretty obvious, right? It was the one on the left. For those of you watching at home, probably 98% of the room raise your hand on the one on the left. Adam raised his hand for both. Let's take a minute to notice why that was so easy. There's a couple of things that jump out to me. And by the way, all credit to the creator here. This is Brian Gardner's block theme, Bright Mode. If you haven't checked out some of the themes that he's creating, he's just starting on the journey of trying to figure some of these things out, but they're really well-designed. The editorial side of things is really well-designed. If you want a full-site, editing capable block-based theme, check them out. Thank you, Brian. To me, the things that stand out to here are the way that the editor makes an effort to match the distinct parts of the user experience that the reader that the customer is going to see to. You have that prominent gradient at the top that's kind of eye-catching. It's theme.json integrated. So you can use a customizer to change those colors to match your brand if you want. The layout matches the view that the reader sees. There's some structural elements there. There are some two-column things and a caption on the image that position the same way that the reader sees it on the front end. It makes it very intuitive to the content creator to be able to imagine what they see on the front end. If they look at a demo page from the theme, if they see another site using the same theme, it's not hard for them to put together the pieces to understand what they need to do to replicate that same kind of experience. All right, so I do talk. So the thing about this experience and the thing we talk about quite a bit in WordPress maybe you've seen occasionally from us on something like the Make blog is about user trust. This kind of experience builds user trust and I will elaborate more on that during this talk but this is a really fundamentally important part of what we're building for. When we think about the things that we're building for clients, for ourselves, for whoever, we think about ourselves maybe if you're a developer out there and our needs as developers and we think about, okay, I want the front end to look a certain way to reproduce a certain design, a certain look and it can be really easy to forget about what's in the middle, right? The front end of the back end which is the editorial experience and through that that's how we build user trust, that's how we win users over in WordPress and how we keep them. The reality is at this point that a lot of the block editor experience is the WordPress users find by installing themes, by installing different plugins don't really closely resemble what we end up showing the reader. There's a disparity there whether it be by trying to oversimplify the blocks that you see in the case of a very complicated plugin, trying to save a little bit of effort and creating two identical experiences, one for the block editor, one for the front end, if you're building a theme and often cases of both of those regardless of whether you're building a plugin and a theme. And to Helen's point, that erodes user trust. That creates a lot of frustration for the end users who are really your super users on these sites. If you think about it, even though they often aren't as plentiful as the folks who are experiencing the site as a reader or as a customer, our content creators are really our number one super users. They're going to spend as much time and often way more time using these experiences that we're creating in our plugins and our themes as any single end user on the customer side or the reader side ever is. And if we don't build these experiences in a way that help those content creators take advantage of the tools and the solutions that we're giving them, if we don't help empower them with the technology that we're creating, it's kind of all for nothing. If we build these plugins, we build these themes that can do all of these wonderful things, but then we make it a nightmare for the folks who have to build these sites to take advantage of it, they're never going to. That degrades their experience with WordPress. The content creators experience with WordPress. That degrades the customer or the reader's experience because they're never going to see the fruit of all of this technology that we invest our time and energy and efforts into creating. So before we keep going, wanted to tell you a little bit more about us now that we've been talking at you for a few minutes. As Ed said, my name's Phil. I'm 10 UPS SVP of Marketing and Growth. 10 UPS of Full Service Agency. We work primarily with WordPress through design, strategy and engineering. Way back in the day, I used to be an engineer. I spend our time now leading our new client strategy team. So I get to sit down and talk to a lot of our customers, many of whom are who are coming from WordPress, many of whom are coming from other CMSs and learn more about the challenges that they're facing and how we consult them. 10 UPS motto for a long time was that we make content creation simple and maybe even fun. And I think that ethos is very important for all of us to try to bring into all of the work that we do so that our content creators can take advantage of all of it and bring some of these things to their customers and their readers. And I'm Helen, and as mentioned, I am at GitHub. But I did previously work at TenUp for more than 10 years. It was a very formative part of where I've gone. And I'm just really excited to be here. I'm still somewhat involved in WordPress. I still care deeply about this project and the outcomes that we have for our users and where this project is gonna go and what we can create with the new technology that we have in WordPress. I don't know if I'm wandering out of range or something, but I'm sorry about that. Okay, so as I said before, we do think a lot about ourselves, our own needs when we're building things. We think a lot about reader outcomes and the performance that we've heard about in other talks, design, interaction. Sometimes, though, that content creator experience, the editorial experience, gets a little lost in between all those other concerns. So the thing that we want you to take away from today our challenge to you today is to dedicate that same focus and energy that we have to improving the content creator experience, right? As we do to improving the reader experience and our own as developers. How do we do that? There's no single answer. And as we know, I think we all know this. The web changes constantly, right? So something I might tell you today may or may not be super relevant six months from now, three weeks from now. Who knows? But what we can do is we can give you some of our tricks for how we think about shaping these editorial experiences. Maybe a few practical tips and tricks here. And then, of course, we'll have time for questions and a conversation at the end. So first up is to target intentions, not the pieces of what you're building. You might hear this referred to as like thinking about user stories or workflows, right? So like when you're building blocks. So who in here is a developer, an engineer, code writer, a lot of people in this room, at least half of this room. So for those of you who write code or are thinking about how we build these things out, it's really easy for us to start thinking about the individual pieces that go into that block, right? Each piece of data that goes into there, the maybe visual components, the UI components, the React components that are in there. And it's really easy to lose sight of what all those things together are meant to do for the content creator as well as your end reader, right? And so we can think about things like, okay, we have a header block. And as a developer, it's really easy for me to think, okay, I have a little piece of text here that has to be stored over there in this way and I have another piece of text here and maybe an image and a link. And that's what I'm thinking about. When in reality, I need to be thinking about this is meant to be, the intention of this is as a header block. And these pieces are meant to go together this way, right? So that I'm not just putting something together piecewise and giving too many options for something that's intention is not to be used that way. But through that, you do need to mirror some of those distinct interface elements in the block editor. So this goes back to, let's say that example that you saw earlier, where you have distinct things like colors, like imagery. And you do need to mirror those things because that is a part how users understand the thing that's in front of me, how is this gonna map to the thing that people see? Is this the thing that I expect to see, right? And is that going to be the outcome that I have? Does this build my trust in the software that I'm using? And also we have to think about the design that is being put into this, right? It's a lot of careful work, a lot of really hard work going into the design. And we want to honor that, right? To respect that through building a faithful content editing experience. Here's another example from everybody's favorite case study and something that I had the privilege to work on, which is the White House for the current administration. This is a really great example of a block. I guess I get to say that even though it's my work. I think it's a great example. A block that really thinks about what it's being used for, right? It's there, it shows you exactly what's going to happen and it gives you the tools that you need without giving you tools that you don't need in order to manage it, right? It doesn't distract you with things, it doesn't overcomplicate your workflow, make you take extra time in order to set up things a certain way. It is very directive and it says, okay, you know what? I've inserted this block and actually in this case it's pre-inserted into the page for you because it has a place it's supposed to go, right? And it's there and you're able to see, okay, I know where to put this header text. I have a little bit of sideways text which is kind of funny but it's there, previewable in that format. I can actually flip flop, you can see between the two screenshots of the editor versus the front end, the little white block is on two different sides and that's because you can actually pick aside for it to go on in order to fit the imagery behind it better, right? And by giving you a visual editing experience for this in the editor, you're able to remove that element of what we call save and surprise, right? Where you have some settings but it's not actually reflected anywhere visually in the editor and you kind of have to pick a setting, save it and refresh and kind of hope that you get a nice surprise instead of a bad surprise once you finish that process. And so by doing this, by making it dynamic by leveraging the block editor, leveraging React, leveraging the CSS that is from the front end and bringing that into the editor, we're able to faithfully replicate that experience that the reader is going to get. And by doing that, as a content creator, I'm able to quickly put together the content that I need, right? And for so many of these websites, communicating quickly in a timely fashion, right? The White House needs to communicate in a timely fashion is a critical part of what they need in the first place. And by building this tooling to be able to communicate quickly, to get your content out there quickly, that is far more important than, do they have a million different options for a thing that they don't have time to be managing in the first place? So all this goes back to that concept of trust. We call this live previews, right? The customizer is an older example of this and the block editor really is supposed to be the new pinnacle of what we think of as live previewing, right? And by live previewing, we don't just mean, again, you type something in one place and you save it and you see it over there, right? That's something that I think was very common, why I know is very common in the customizer, where you would have little fields in the sidebar, right? And you type into those fields and they kind of live update, sometimes not really. There's a little bit of a delay. It's not super faithful to the front end. And that's not really a true live preview experience, right? The block editor gives you the ability, if built correctly, to type into place, right? Rather than decoupling the piece of data from the way that it's shown. It puts those together and that's really your live preview context. I can type in place, right? Like if I slapped content editable on a webpage and just started typing away, what would that feel like? And that's really what the block editor should mostly feel like, right? We should be able to close the sidebars, get rid of our distractions and be able to get the framework of what we need at least into place before diving into the details. And through this, we continue building that high user trust through those faithful live previews. And again, draw people into WordPress and get them excited about using WordPress again, right? Other than seeing it as a slog that they have to get through in order to get their objectives completed. We spent a lot of time talking about the block editor so far, but the same principles apply to the rest of WordPress, particularly for those of us that are building more complicated plugins or more complicated themes where there's some effort involved to set them up up front. As somebody who's maintained a couple of plugins over the years, I know that it's really easy to fall into a pattern of kind of focusing on the middle part of that user experience. The thing that the majority of your content creators are going to see most of the time after they have the plugin installed, after they have it set up, maybe after they have it put into a few different pages and they're really just maintaining it. And it's true that you should spend a lot of time there, but what often ends up happening is we forget that everybody starts from zero at some point in time. And we end up giving them an experience that looks a lot like the famous how to draw an owl drawing where they install the plugin and their steps are, step one, draw two circles, step two, draw the rest of the owl, figure it out yourself. That erodes user trust. From the very start, you're beginning from a position where you have no idea what is going on, what is going to happen, and you're stuck having to experiment, save and pray, to find out what happens. And as we build those experiences, as we subject our content creators to those, we start things off on a very negative foot. Instead of focusing on that middle as dramatically as we often do, I think it's important to invest as much time, if not more on the first 10 minutes of a content creator's use of your plugin or your theme. Really spend the time to experience your own products just as somebody brand new would. Install it on a completely blank slate site, set it up and think about, what do I know as a creator here? Because I built this, I know exactly how it works, I've done this a million times. And what's maybe not so obvious? What is the user likely to want to do? And what can I give to them to help them do that quickly, help them understand how to do it, and help them understand how to keep doing it as they continue to use my plugin or continue to use my theme? We can make that easier by leveraging some of WordPress's new features, like the block pattern support, like global styles, to help create a more consistent experience from plugin to plugin or theme to theme. Yes, those features are under active development. It's a great opportunity for all of us to contribute, to try them out for our own plugins, try them out for our own themes, see where there are gaps, see where there are opportunities to improve. And by using these features, we make sure that no matter what somebody has installed, we're not going to surprise them. They want to change colors, they want to change fonts, they want to change layout of something. They'll know exactly where to go because it's the same place that they go for everything else. They don't have to learn WordPress and then learn this plugin or that theme and figure out how to glue together the configuration for all of the third-party tools that they're using independently. Instead, they can start to build a little bit out of that knowledge. They can start to build a little bit of that familiarity and they can rely on it. Along with that, it's also important for us to keep configuration predictable, keep configuration consistent. Yeah, and that ties into using some of these tools that are built in decor, by building that familiarity by leveraging what we have in WordPress, the infamous... Wow, this really hates me. By leveraging that infamous market share number, that we like to kind of argue back and forth about or boast about, but what we can really take away from that number is that so many people out there already have some familiarity with WordPress. It doesn't mean like 43% of people, it's more than that because a website has more than one user frequently. And we can leverage that by leveraging that familiarity that they already have with WordPress and by using some of these common tools built in decor, like block patterns and theme.json, global styles, we're able to take advantage of that familiarity. But in addition to that, we almost inevitably have to step outside of that box, right? Like every single thing that we build, maybe not every single, but many things that we build end up needing more settings, more options, more configuration. That's okay, we need to be thoughtful about that and ask ourselves, how do I really, really need that to be a setting prominently forever? But you do, it happens, we acknowledge that. But in doing that, you still wanna think about how can you keep it predictable and consistent, right? So I saw something recently where you had many, many options and it was really powerful and it's great to give power to your content creators. But in providing that power, it ended up with three different places to set a site logo. And each one of these, there is a global one, one type of override and a third type of override. And that's okay, you know, you can have overrides, it's a little bit complex for the user, but sometimes it happens, right? Powerful things are complex. But these were spread across three different settings pages. And in order to set just one thing for one single page, you would end up going through three different settings pages. Rather than something that would probably be a little more intuitive, which would be to have that setting be in the editor for that given page, right? This doesn't belong on a separate settings page. You shouldn't be editing a page, right? A piece of content on your site and then thinking, oh no, I need to override something that's in some other place on the site. But then I have to create another settings page in order to edit that thing that is actually coupled to that piece of content. And that's where concepts like full-site editing really do become powerful. They're scary, right? I mean, for me as a developer, it's scary to think about giving that power. But through that power, we're able to more cohesively grip together the concepts behind editing, right? Like as developers, we can think, well, menus are not a piece of content. They should not be edited in a content editing interface. This is not how people think, right? To a person, it's just this is a thing that's over here. And when I'm fixing stuff on my site, I want to be able to change that too. And that's where we should really embrace these newer things that are happening. Even as like the power behind them can be a little bit scary, the change behind it, you know, it's a lot, it is work. Nobody is discounting that. But I feel like that's the thing that we've accepted, right? As people who work on the web, things are changing all the time. And that should be a part of something that not only we accept, but that we're excited about. That we're excited to leverage these newer things in order to provide better, more powerful tools for our content creators. So we come to you today, not just with answers, but also with problems. One of the major sticky issues that we face sometimes at TenUp is we think about some of the work that we do. I know others I've talked to and countered this challenge as well is how exactly we encompass a spirit when we're talking about websites that are more than just websites. When we're talking about using WordPress for multi-channel experiences, where WordPress might power an app and might power your website and might power through content syndications and other websites. A lot of these patterns have clear use cases, have clear ways to implement them when you're thinking just solely on a single website. But there are questions when you start to expand a little bit further out. What does it mean to mirror distinct interface elements if you're building a CMS experience that powers a website and also a mobile app that looks a little bit different? We have thoughts, but these are fundamentally questions that we as a community need to work together to find the right answers for, whether it be a single answer in some cases or multiple answers depending on each use case. In that instance, we need to figure out what those use cases are. I think for the example that I shared, distinct user face elements, how do we handle those? There might be an easy way out in that we want the end reader, the end user, the reader experience to be consistent too. We want the reader to recognize the brand, whether they're in a mobile app, whether they're on the website. If there are what you would define as somebody building this content management tool, distinct user interface elements that aren't replicated in one, but exist in the other, that might be a sign that we need to think a little bit more systematically about our design approach. It might be a sign that we need to invest a little bit of energy taking the same spirit and applying it to the different channels that we create too. Even still, there are unanswered questions with full site editing. Menu configuration, as Helen mentioned, makes a lot of sense to include in the site editing experience because content creators think of it as part of the site. What do you do if you build a mobile app and the menu maybe needs to be different contextually or the menu is positioned a little bit differently? I think it's both important to hopefully take some of these tricks and try them out, but also to reflect on the spirit of trying to create as little confusion as possible, create as much user trust as possible in the content creator experiences that we're building. And as we learn what works well, as we learn what doesn't work well, as we develop opinions here, create those best practices, document them, share them, help others in the community understand what you've tried, where your thinking is, how you've gotten that way, and help to evolve these tools that we all use, help to evolve the best practices in the way that we think about these tools that we use so that we don't all have to reinvent the wheel and so that we fundamentally build the best experiences that we can for our content creators, knowing that that'll trickle down to the readers and to the customers too, it'll trickle down to the general spirit that we all have around WordPress, it'll trickle down to the reputation that WordPress has is hopefully an easy to use content management system once again, and we'll all be better off for it. All right, so we are already at the takeaway. We know that it has been a long couple of days and that you're all looking forward to a match-hat that's coming up, and we also wanted to leave lots of time for any questions or conversations that you might want to have. So our takeaway here, specifically in the Block Editor, right? We've been talking about lots of other things more broadly, but really the Block Editor, the concept of blocks is a really, really exciting opportunity for us to keep building user trust in new ways, in modern ways, in ways that users are expecting today, right? I think that one of the things that we hear about quite a bit is, I'm scared, right? Like, I'm not enjoying learning JavaScript. I'm not enjoying trying to figure out this new technology. Making a website today takes a lot more work, a lot more tooling than it used to, right? Like a little bit of that, like, back in my day, when I was using FrontPage, it wasn't like this. But I think that a huge part of that, like, yes, it is more work. You know what, it is more work. And a huge part of that is because user expectations today are much, much higher, right? And that's a good thing. That's what technology is supposed to be for. It's supposed to be about having things that are better for other people. And like, yes, it might be harder to achieve things at a higher level, but that's what we're really targeting, right? Like, we aren't just doing more work to achieve the same thing as before. We're doing more work in order to have things that are better, right? That create better experiences, that build user trust, that show the power of open source, of the web of technology, of open technology, right? These are things that should be exciting to us, even through being intimidating, being scary, right? Through the changes, through the amount of work that needs to be done. But these are fundamentally really great opportunities for us and a really great space for us to be in. So now we open it up to all of you for any questions or conversations that you might wanna have. Thank you. Thanks, y'all. That was really great. I just had a question, going back to the White House case study. Like, how do you think about block controls in that sort of context? Cause they obviously don't exist on the front, but where would you put that control to flip the block to the other side of the page? Is that in the sidebar or in kind of the toolbar on top of the block itself? And even just more generally, like when you're designing and building blocks, like if you have configuration controls or block controls on specific blocks, like where you put those? Yeah, that's a really great question. One of the things that I thought about a lot in figuring out like where should things go, right? Because there are, as you said, there are many places that we can put things. We can kind of break them into three-ish primary places, right? There's within the block itself, like visually, there's that toolbar, like the little three dots or the floating toolbar. And then there's the sidebar, the expanded set of settings. For that type of control, like where you're toggling the right versus the left, that's something you're not doing all the time, right? It's not something that you necessarily need to do in line because you do it once-ish, right, per block placement. And so that does live in the sidebar, right? Like you are able to manage the vast majority of this editing experience without opening the sidebar, which is really helpful, especially because sometimes the blocks get squished in kind of funny ways. I think it's better now with it being iframed. But for a while it was kind of funny, right? It wasn't truly responsive the same way because the breakpoint wasn't actually the same. And so you were able to do this without opening up the sidebar. But for something like that, where you're toggling it once, maybe twice, right, to figure out the right placement, it's okay to keep it in the sidebar because it's not something you're constantly accessing or needing to keep open. I just wanted to ask another question about the block editor and blocks. And so a lot of other page builders kind of show you the front end of the website and sort of layer the interactivity on top of the front end, you know, like Elementor or something like that. The block editor is the first one, it feels like where it really is two separate screens, there's the block editor and then there's the front end of the website. And I just wonder, did that open up like positive opportunities or are you able to do things a little bit different? Like what were the trade-offs and maybe benefits of being able to build something where it's not really the front end of your website, but it's kind of like a different app on the back. And if that like affected the way you build these custom blocks out. Do you have anything you want to say on that? I'll keep talking. So I actually don't think of them as being all that different between the front end and the back end with the block editor. Like for me, the mark of success is if I can barely tell that I'm in the block editor versus the front end. I did actually, I gave more of a talk about some of this White House stuff at last year's WordCampUS, so you should be able to see that online. And it has like more examples and I think a couple of screencasts which I should probably have pulled into here. But yeah, it really should feel like you're just kind of flopping between the two, right? Like if we could preload the block editor and click edit while you're browsing the front end, it would feel like a couple of toolbars maybe popped in right around the side, but it should feel seamless. That should be the ideal of the experience that we're looking for. And I think that actually it really challenged us to build something in a different way, right? Like we were coming from a site that was using meta fields extensively, like lots and lots of meta boxes with lots of little form fields and you're just like feels like you're feeling out of tax form in order to hopefully get something that looks nice on the front end, which when you put it that way is like, yeah, no wonder that feels futile to users, right? And that's fundamentally what we were having, right? And it is true, like web apps are dressed up forms online, right? But by being able to really think about like, okay, my ideal is I barely want to know if I'm in the editor versus the front end and by really chasing that, I think that challenged us in a lot of ways that were not always easy, but really kept us on track together, right? Like we knew what our end goal was and I think that also made us better able to work together as a team to get it accomplished, which also is very important, right? It's like, how do you work together as a team? How do you get people on the same page? And so I actually think that, you know, no, I don't think that they're actually really all that different and from a technology perspective as well, we actually were pulling in all the same markup as well as all the CSS directly from the front end. CSS was being pulled in directly from the same partials being used on the front end of the site and we were able to leverage that to have that true like one-to-one replication of it visually on the back ends. Hi, I am familiar with your work on the White House website. It's fantastic. I've studied it quite a bit. So good stuff there. My question is in relation to like design systems like the USWDS, which I know that you were familiar with because of that and then, you know, also like Bootstrap or Tailwinds or something like that, did you kind of experience any of the interplay between like using a theme.json, which is like intended to create kind of a design system and the exact same thing being intended to be done with the USWDS or something like Tailwinds or Bootstrap? On this site, no. We were a little bit ahead of theme.json really being like a reliable thing that we were willing to put into production. So that's really the short answer to that. I think I'm really interested to see what happens with some of the more popular CSS frameworks and what people do in terms of like, you know, using some of this available tooling and core and like how can we make, you know, pull that stuff into our advantage? Is somebody gonna create something where you could like leverage everything that's in Tailwinds, right? All in one giant theme or is it gonna be somebody, you know, getting in there and really pulling out little pieces to make something more targeted? That's something that's really exciting for me to watch how the community does these things going forward. Oh no, we have a Jake question. Where are you gonna answer that one? No, absolutely not. Hey, I'm curious how you're approaching training and getting content creators to handle adding content and knowing what to do in the right ways. I can take that one. I think it fundamentally begins with giving them the starting points they need to be successful and helping them understand how to build on top of them. Looking at a blank page, whether you are a content creator on a website or an author is tremendously stressful, right? Going from zero to one is always the hardest part. When we think about how we train our clients, our customers, it starts from showing them the way that we imagine them using these tools, explaining to them this is the intention of the design. We created this hero element because it does these things well. It draws attention to a particular category of content, helps users way find and try to both build their thinking around how you use each of these pieces that we talked about earlier, pieces and how you can take advantage of the flexibility that's baked into them to do things that you might wanna do. So we go generally through a lot of practical examples here is sort of a starting point for an internal page. Maybe a second level page is not your homepage which are usually designed a little bit differently but something that will cover the majority of the content that's linked to in your top navigation, your most important landing pages. Start with one of those it's already built to give them an example to work from and then take them through the exercise of what does it mean to create the second page or this third page or this fourth page that is a little bit different. It makes the steps to learning how to use these tools a lot more incremental so it isn't just like drinking from a fire hose like my Al example earlier but instead it's something that they can then build upon and as you move through that exercise start gradually expanding the footprint of what you're customizing, start gradually starting from a blanker and blanker slate where folks can use the context that they've built from those more complete examples to get a little bit more experimental. Maybe three or four pages into this we'll try creating a page where we have the body copy pretty much laid out. We can duplicate that from another page but it's a landing page for a special event so we want to like for WordCamp for example link to the schedule, link to the speaker is a little bit of a different both layout challenge and functional challenge than static landing page that's gonna exist forever and is pretty evergreen and by doing that you help the content creator learn what tools are available to them but do it in a way that's contextualized to the when you want to do X this is how you do it instead of just giving them an arbitrary list of we're gonna walk you through all of the blocks that you have available to you and show you all of the options and then you end that with okay cool now I have a bunch of pieces and I don't know what to do with those or I wanna build a page where I even start. So my question is more about assessing the editorial workflow and working with clients to figure out their pain points and so my guess my question is when you're working with clients when you're assessing workflow what are the questions that you ask to really understand their pain points what is something that's usually missed? So the root question that I always like to start with is what is frustrating you scaring you or taking longer than you think it should it's deliberately a very open ended question right there's a structured part of this too where you wanna talk through how do you create content where does it start you begin with an outline you begin with a brief who touches that as you work through it or their approval processes that need to be covered those kinds of things but I think in general most folks who are building these websites do a pretty good job of thinking through and asking the questions about the structural pieces of the process those more open ended questions and then the kinds of questions where you wanna ask and just not talk for 10 or 15 minutes and let people keep pausing and adding on and adding on can be incredibly insightful because they'll unpack the gaps in that process right most of the time if you've had a website for any period of time you have a workflow that you stick to whether or not it's something that your company is prescribing is something more open ended you're comfortable with it and you don't really think about it and if you try to zoom in too much on just the workflow pieces of it you miss those middle pieces that are the real opportunities for improvement and then from there you can ask yourself is this something that the tooling could help empower the workflow to solve or is this a more fundamental thing where we really need to revisit the workflow the way that we're doing this because it's the challenge that is ultimately creating all of these anxieties. Be surprised to hear that I agree with like how to approach this from like building the entire site experience agency experience one of the things that I've been thinking about talking to a few people that in the conference hall and everything that are building like block solutions going back to that question like the back end versus the front end I'm kind of trying to figure out there's a way to get to this vision of like the back end being very tight to the front end presentation for people that are trying to build generic block libraries where you don't necessarily know for the person implementing the site what is the design treatment gonna be what is the color what is the typography and I don't know if you I know it's a tricky question but if any sense whether like how am I think about enabling those generic block tool builders those plugin builders and are not necessarily gonna predict what the front end is gonna look like how you can be easier to you and both how you can make it easier to get to an outcome where it's not a surprise on the back end where the front end is predictable as well I'd like to see those more generic block libraries try to be a little bit more prescriptive in the way that they start I think there's two ways to cut that number one is more of a systems thinking question where you don't try to design these big block library monoliths where every block does everything for every possible customer under the hood as a developer you might try to homogenize things as much as possible but don't create blocks that have 23 different configuration options pick the intention of this block know that it's gonna be limited and create as many versions of those as you need to take advantage of block patterns I think there's another way to handle this that I'm a little bit more skeptical about but is interesting to explore it's really a question of configuration you know how many of these options to Helen's point earlier and configuration in the block editor really need to be exposed in the block editor versus how many can be abstracted up is there a way for us to build a block library where maybe we can configure outside of the block editor something whether it's pick your kind of business pick your kind of side something like that pick that configuration option and the blocks that we render then dynamically show you a more limited set of options that's not great because it hides all of the other things that we don't think you need and could inhibit creativity a little bit but on the whole in the trade-offs I think that's better than overwhelming folks with these big giant blocks with 15 different sets of configuration or 23,000 blocks that they don't need to figure out what to do something with and I think that for me it goes back to that good old question of like what is the problem of block libraries trying to solve in the first place like whose problem are we trying to solve with this right is it actually the content creators problems that we're trying to solve are we trying to solve our own problems as developers right and have we prioritized our own needs our own wants as developers above those of the content creators and I think that a lot of these libraries end up falling in that trap which is again completely understandable but through that we are fracturing the experiences and we kind of have to right like to Phil's point like you don't wanna provide this this one model of block to everybody with a million options because the more options you have the longer it takes to get it stood up and to a place where you feel like it's ready right as a content producer and so I think you know when we get into those things I'm not gonna stand up here and be like they're bad right block libraries are bad I'm just gonna pull that as a quote and it's gonna be on like WPTab or tomorrow but I do think that you know it's really important that we do that thing where we take a step back and we ask ourselves what is the problem we're trying to solve for whose problem is it that we're trying to solve for and do I have the right priorities right in building these things out I think we're out of time thank you for the minders so thank all of you for the questions they're really wonderful and we'll see you over in that chat Thanks everyone