 My name is Helen Hosendi. I work at this really cool place called TenUp. You can also find us upstairs. There's like a Google booth. And so some of us have been up there through the day, today and yesterday. I'm also, I guess, still a lead developer for the WordPress core software project, which we're all here about, I assume. And I also led the 4.0 and 4.7 releases specifically. All right. So what I want to talk to you today about is the editing experiences that we build for other people, whether that's our clients, ourselves, theme and plug-in users, right? A lot of theme and plug-in developers out here, probably. Or really anybody who uses the core WordPress software. This is not a code talk. I have a really hard time giving those. And I think they're better suited for most people for workshops. What this is, is it's meant to be inspirational and to get you thinking about where we are and where we should go, especially with 5.0 being released two days ago. So broadly, what I hope that you get out of this is not actually that meta boxes themselves are bad and should never be used. Nothing sweeping like that. But that we, as creators of these experiences for ourselves and for other people, we need to be more thoughtful about when we're doing things that are familiar and when we're prioritizing our needs as developers and our desire for control versus really aiming for the best possible experience for our users. OK, so why did I call this meta boxes considered harmful, then? This is definitely like an incendiary talk title, is to get your attention, click date of talk titles. It's a riff on a really, really common trope in our industry, in the tech industry, where a given piece of technology becomes super popular, right? And it becomes popular enough for other people out there who maybe are using it, maybe or not. But they dedicate their time to breaking down the shortcomings of that piece of tech in a blog post, or sometimes a talk, or sometimes like a full on paper. This considered harmful structure, it actually originated in 1968 with a letter called go to statement considered harmful. This is actually something that's extremely funny to think about today in WordPress, because hooks are basically just go to. All right, so what do I mean when I talk about a meta box? What is this meta box that I'm talking about? At a base level, and on a code level actually in WordPress, it's these panels that we find all over the WordPress admin. They're a layout component. They can hold anything. Right here, this is your dashboard, sort of by default. I think I hid something. But you get your added glance, activity, WordPress events. You can see that my events here are for Costa Rica, because that's actually where I live. So these are the things that you see in meta boxes on your dashboard. They typically respond to your preferences. You can move them around, and that's retained in your user preferences. You can collapse them. You can hide them, all sorts of things. So that's what a meta box is at a base level. But I think in common usage, and definitely in the context of this talk, what I'm talking about are meta boxes as those panels that we use on the editor screen. There are a lot of them that are built into WordPress. So here you can see Publish, Categories and Tags, our favorite custom fields meta box. And then especially for those of us who do development or anybody who works on content on what we call enterprise-y or publisher sites, it's very, very common to see custom meta boxes. And there are a lot of really popular plugins out there as well that insert custom meta boxes. So here's an example of a very, very typical, very bare bones, but very typical custom meta box. So this is a real site. It's a real example. This is my husband's website. He's literally on stage at the Guggenheim right now, warming up for Peter and the Wolf. That's what this is. This is an actual listing from his website. So you can see in this meta box where we have start date, end date time, venue, URL address, content, title, our usual kind of stuff. So actually, before we continue on with that example, I want to take a step back in time. We're going to go back to 2012. The WordPress Customizer is actually just exiting prototyping. Custom meta box frameworks are, I think, about to enter sort of a Renaissance period. We're talking like CMB2, I think, who's what we all called it, advanced custom fields. I'm sure a lot of people are familiar with that. So we're about to enter into a period of high development and high usage for those kinds of plugins and frameworks. Brad and Angelina are about to get married, and Obama's about to get re-elected. The Nets have moved to Brooklyn, and the Knicks have Linsanity. I'm really into basketball. Mikaela Moroney is not impressed. Sandy happens. Superstorm Sandy happens. And a bunch of us are stranded on Tybee Island after the first WordPress contributor summit. A lot of terrible things also happened that year. Trying to keep this light, not going to get too dark. But basically, 2012 was a while ago. It's six years ago. We feel like, OK, now in 2018, maybe 2012 wasn't that long ago. But think about how you felt in 2004. 1998 felt like an eternity ago, a totally different era. Even this year, the 2018 Olympics, do you even remember that that happened? It feels like that happened so long ago. So I have no idea how we even measure time at this point. All right, so in 2012, this is what I was working on. This is an example of a site that I was working on. These are actually screenshots from a talk that I gave in 2013. I can't even find the actual site anymore to get current screenshots out of. But this is what I was working on. It was a fashion industry client site, a blog. And they had this highly artwork-driven homepage grid that I needed to build out. So it was really cool building out the HTML and the CSS and having these little crowns before pseudo-elements, getting into all the nitty-gritty of the code of building it out. And then when I got into having to create the editing experience, I had to really think about how do I make an editing experience for this. And for those of you who know me, I have a very certain aesthetic about things. And I couldn't just let it go by and be the usual that we might think about doing. So the usual, I think, would be something like this. Very basic meta box on the home page edit screen. You have a static front page, and you have a meta box that's just on that edit screen. And you put a bunch of stuff in drop-downs. We can split it into left layout, right layout. And we can say it's a three-up, it's a four-up, whatever. We can pick those from a drop-down and pick your up to eight posts that show up in that grid. Very controlled, very easy to understand what it is from actually picking stuff out kind of viewpoint. It's fairly easy to understand what's going on, right? This is very easy to build out. This is actually a screenshot that I made like an hour ago using advanced custom fields, okay? So that's what we would think of as a basic example of what a meta box for that might be. For me, however, this was not good enough for a lot of reasons. This is what I ended up building. This was a JavaScript-driven thing, not in backbone. I'm pretty sure it was just like really terrible jQuery that I don't ever want to see again. But it was a separate options page. So you have to remember, this was before the customizer, right? The customizer came out later that year. So I didn't have that paradigm to refer to. I couldn't even think of that as a thing that existed. So for me, I still thought of, right, like a default WordPress experience. And so for me, that was a separate options page because this was very wide layout and I didn't want to stick it inside a meta box. So we have visual representations of the one up to four up at the top for each of the sides. And then you get, as you change those, it changes live and moves the posts around just based on order, like one, two, three, four. And then you get a visual representation of each of the posts that you've selected to go into that grid. So you get a full-size, full preview of what you're gonna get on the front, right? And to me, it felt like for a fashion brand especially, this was very, very important to have for them. So this is what picking a post was like, right? We have like an empty slot here. I'm like, okay, I need to stick a post there. Click select posts. You get a little, you know, crappy modal that comes up. But with the featured images, remember this is very visually driven and we need the information, right, for them. They need to understand like what is, maybe the featured image will get into that, that's gonna show up in this grid. So you pick one, sticks it in place, okay? And then everything is there for editors to check out. They can check out that featured image, right? That's so important to this layout. They can check out the flow of the text, right? This is something that we really need to think about as we get into like dicing up mockups, right? Like a lot of mockups are for ideal situations and they don't account for people with long names or a really long post excerpt, right? They don't think about these things. So we have this preview mechanism where the editors can check the text flow, right? Where how long are these things? Do they fit inside these height-limited boxes? They are height-limited. So they can check their excerpts and decide, is this a good fit for this area? Maybe not. Maybe they can make some different decisions editorially and visually based on this preview that we're giving them. And this is a significantly better experience for them in all ways than sticking something inside of a meta box, right? So now, I know this is called meta boxes considered harmful, but I did actually involve a meta box in service of this site and service of this grid. The meta box that I built was for something else. It was for multiple featured images, okay? Or more descriptively in this case, we called them post thumbnails because there isn't like a single featured image or a bunch of different thumbnails that they could pull from. So because of the way that homepage layout was done, right? You had some really wide landscape images. You had some portrait-oriented images and their archives had square thumbnails and then they had like really wide landscape featured images like for individual posts. Editors really needed a high level of control over that imagery for all those different situations, right? So and remember, this is a fashion brand, right? So if you have a portrait shot of a model and you auto-cropped it to be wide landscape, not a good idea, right? So that's what we have here for them. So we do still involve meta boxes, but we have to be really mindful about which type of information we're choosing to manage in which way and when. So that's the meat of this, right? Meta boxes are okay, right? But they can still be harmful. And the reason why I think that they've become harmful is because we've allowed ourselves to kind of settle back into them a little bit too far, right? Back in 2012, before we had those meta box frameworks that would have made it really, really easy for me to spin up a bunch of fields, right? And before we had the customizer to think about, we really had to get creative about what we were building. Some of that didn't end up so great, right? We have, I think Gary might have mentioned this in his talk yesterday, where we have like very fractured UIs across different plugins, across different themes, right? Not all of the outcomes have been great, but we were being really creative about what we were doing. We were pushing boundaries. We were ripping our hair out, writing custom things, right? And trying to come up with different patterns that we could use within WordPress because unfortunately still WordPress does not provide you with a lot of patterns and reusable pieces and components to use. So we were doing that back in 2012. But I think since then with sort of like the Renaissance of meta boxes and the explosion of like sort of the WordPress development economy, right? We all have a lot to do, right? We're all very busy all the time. We're super busy at 10 up all the time, even though I don't even work on client stuff anymore. It's just, I know what everybody's dealing with. So we started to take kind of shortcuts and we started to think about ourselves as developers first, rather than thinking about that experience and getting creative with what we're doing. And so we've kind of settled down into using meta boxes for everything. So what's happened in the meantime in WordPress core, right? And where a lot of friction has been in those years in between between the developer community, custom development community and the WordPress core development community has been that the WordPress admin itself has actually fully embraced visually driven editing, right? Editing and management experiences, the customizer, even the new media library, new. It's not really that new, I guess. We keep calling it that it's not new at all. Now with Gutenberg and the new block based editor in 5.0, right? We've really embraced that in WordPress core and where in the meantime the custom development community has kind of stayed a little static, I think, and been reluctant to embrace stuff like the customizer. There are definitely people out there who have done really, really cool things for their clients. And if you go to talks at the.com VIP meetups and that sort of thing, people give really cool talks about really cool things that they're doing with these custom visually driven UIs, but I actually think that they're relatively uncommon, right? This is not the lowest common denominator for custom development in WordPress. The things that we see in really big agencies are not what people are doing day to day. Okay, so I want to go back to my husband who is currently pretending to be a cat by the way of playing clarinet in Peter and the Wolf today. Yeah, he's gonna watch this later and be like, why are you talking about me? Okay, so this editor has been working fine for years. Okay, I built this before I was even at 10 up. This is like code from 2010, 2011 when I still worked at a music school, as a web developer, but I worked at a music school that I had gone to. And I look at my code now and it's like, ah, it's so terrible, but it's fine, right? It's fine, it's working, he's happy, I'm happy, everything's good, right? He can enter stuff and it shows up on his website and that's what he really cares about. This is what it looks like, like an individual event, right? You get like title, a human formatted date after picking some specific, picking one in the back end and you get a map with it. This is what it looks like on the archive, which is the events calendar, right? You have like upcoming events and past events. And so that start date, that end date, that becomes critical in how we present this. I had no interest in messing with post-statuses at the time and I still don't. So it doesn't use the published date because everything that you're creating is in the future, right? So we don't wanna go messing with that. So it's a piece of metadata, it is appropriately a piece of metadata that we have set in a meta box. So we look at this and it's like, okay, everything's fine, it's working. So what am I doing with this site? Why am I messing with it, right? 5.0 is out. His site's already updated because my husband is a very, very typical user and I just have everything set to auto-update because he is never gonna do it otherwise, okay? So his site's already on 5.0. What's gonna happen? Nothing actually is gonna happen. He's gonna go to edit his event and it's gonna look exactly the same right now until I upload my changes. Once I set show and rest to true for the events post-type, it's like the only code in this talk. This is what it looks like in Gutenberg. It just works, okay? This is not some huge scary change. Definitely, I've been dealing with shoring up plugins and fixing up things for Gutenberg for the last couple of weeks, months. I understand, but I think for a lot of these things, like things are fine, they're working, right? All I did was add one line to the code, two lines. I think I had to do something about the meta box back in Pat mode and it just shows up and you know what, it still works. I tried it, jQuery date picker still works inside of Gutenberg, doesn't sound nuts, it works. It's fine, everything's great, you know? Kudos to the team for making that happen, you know? So yeah, this thing just works, it's fine. I don't have to go messing with it anymore. I don't have to teach my husband how to do anything new. The only thing that I wanna do further maybe is like turn off comment support because for some reason I haven't on for an events post-type, I wasn't thinking I guess that this discussion panel can't be turned off anymore, right? Like it used to be a meta box so you could like go into your screen options and turn it off and I can't do that anymore so I'm gonna turn off comment support. But let's take a step back, right? This is what I want, this is what I want all of us to do. I want us all to take a step back from these things that we have and that work. It's like they're fine, right? We don't have to change anything but I want us to take a step back, right? So let's go back to this front end view for his website, right? First of all, we still have that friction of save and preview for your changes, right? Which also comes with its own bag of technical problems around how meta is saved against revisions. Sorry, Adam. All kinds of fun things around how you store that data, how you preview that data, right? So it comes with a bag of technical difficulties and then you still have like that friction of like they have to go preview it in order to see what happens with that data that they've entered. So I want to think about like what can I do better to give him that kind of, that better kind of outcome, right? What's the best possible UI that I can give him? While still controlling the experience a bit, giving him guidelines, giving him guide posts and ensuring, helping ensure that sort of ideal outcome. So this is what I think about when I'm looking at this again with fresh eyes. I actually wrote these out as I was writing the code. So these are like really truly my life thoughts. So here's what I see. There's no way of verifying that this map is correct or is even gonna like put the pin in the right place in the meantime, right? Like, especially in New York, like we have the zip code here, so that helps, but like there are multiple streets named the same thing depending on the borough, depending on like, you know, you could mistype Ave and street, you know, like if you're in Queens, it's super fun. It happens to a lot of people. So there's no way of like verifying that this map is correct in the meantime, right? There might be more relevant links than just the venue and here he's like sort of stopped thinking about what kinds of links you might want to include, like maybe to tickets, maybe to like more information about individual artists, right? There are other links that you might want to include that of course you could stick in the content area, but because you've split out venue for whatever reason, and it's not used in any sort of like grouping manner, it's not a taxonomy, you know, just kind of stops thinking about it. And most importantly, the date and time, the start date and date, they're actually too restrictive. This show, we do need them. We need them because it controls that chronology, right? And on the archive, but this particular show, there are 10 of them over the space of two weekends. I actually thought I was never going to be able to come to a word camp US again because he does this every December. And we have small children. So like, you know, you go do the gig and I'll stay out of word camp. But I'm here. So this is an event that happens 10 times over the course of two weekends, right? It's nonsense to make individual events for each one. The way that his site is laid out, the way that people navigate his site, the way that we intend for people to navigate his site, has nothing to do with individual events, right? It's just you have a blob and you should be able to say, these days shows at one, two, 30, four, 30, right? Instead of like just one start date and one end date. So now that we've thought about this in the context of his site, what kind of information actually should be on his site? What if we started thinking about blocks instead? Here's the next step that we can take. This is actual code, actual screenshot. So here I have removed some of those fields that I talked about, the map field, the venue field and URL. What I've added is a block template for the event post type. So when you hit add new, this is what you see right away, okay? You can remove these blocks, whatever, but they're kind of there. They have placeholders to let you know. This is what we think would look really good in these areas. I didn't write a custom map block. I haven't gotten an API key because it seemed very annoying because I didn't bother doing it. I'm a normal user too. So, but I didn't write a custom map block. I installed a plugin to give me a map block and I think Jetpack comes with one now. So it's like, it's a super cool world that we live in where like, I don't have to write these things myself anymore. I can see what else is out there, pull that in, reference it. There's some funny things about, you know, specifying blocks in a template if they don't exist anymore. And so I need to file a bug report about that. But yeah, so what you get here is you get some paragraph blocks with placeholders in them to let you know what kind of information we think would look good there. You get your map box and you still get your start, time and ending. As I said, this is a real example, I'm not done yet, right? I still need editor styles. I need that blue background. I need the font, the font color, right? I need all of that stuff in there to mimic the front end of the site even better, right? So we're truly getting that visual preview, not full front-end editing, but a true visual preview of what you're gonna get. Another thing that I might wanna do is some trickery around that start date and date and populate that first paragraph if it's empty and all he does is enter stuff in the meta box instead. So he doesn't have to manually recreate that information if he doesn't need to for that particular event, right? So I might wanna do some trickery around that. So for something that is relatively simple, and again, that was working just fine, I did not have to touch it. There are actually a lot of possibilities if we take a step back and we really think about what's here, what should we be doing, what helps the user, right? I'm really excited about this actually. I'm actually excited again about this events thing that I wrote in 2011. I have a lot to learn about dealing with blocks and templates. I don't even know where to start with taking stuff out of that meta box and putting it into a paragraph block. I have no idea what's going on. I have to figure that out, right? I'm a developer and I have to learn it. But I am really excited about this richer, more flexible editing experience and how good it feels and what it becomes while it's still guiding my very handsome editor in the right direction. All right, so thinking outside the box. Metadata about a post, as I said, it's still really important, right? There's still spaces where having meta boxes that contain form fields for metadata are still important. They're still gonna be necessary for certain things, right? What's important here is to take that step back, like I've been saying, and think about what is truly that metadata about a post, right? We've spent a lot of time thinking about what is the difference between post meta and taxonomies, right? Like we've talked a bit about that. I think sometimes even still those get a little bit mixed up and conflated and it is hard to separate them, like what's grouping, what is descriptive, right? But you wanna think about what is truly that kind of metadata, what is descriptive about the post and what is actually content that is a component of that post, right? And we don't wanna be control first, right? We want to actually be able to separate that. What is a content editing experience from what is a descriptive metadata editing experience? So I wanna take a quick look at some interesting blocks for Gutenberg. These are examples of things that maybe aren't actually quite metadata, but they do deserve visual previews and they're really cool as blocks. So here's a super cool one from Nick Hamsey, I hope I'm saying his name, right? Called Guide Post. It's a table of contents block that updates live as you add headings to your posts. You know, semantic, well-structured HTML, accessibility, right? All those things, those matter a lot, right? And so this is a super cool block. Like think about it for when you have like long documents, right? Readmes, guides, recipes, like all kinds of things can really benefit from having a proper header structure, right? And sort of a table of contents that auto-generates itself so you don't have to do it yourself. And the fact that it live updates, that it's a block that you just insert and let it go is super, super cool, right? No more short codes, no more wondering how that's gonna look on the front end. You get this actual live updating preview of what's gonna happen. This is something I wrote a blog post about a while back, promoing my own stuff. Thinking about advertising as a first class component of your content. The publishing industry has become sort of hyper aware of what ads mean to them, mean to their content, mean to the industry, right? And I truly believe that it's critical that we treat them as a part of how articles are shaped, how they're written, how we put them together, and what kind of content is served inside that ad space, right? You don't want an ad interrupting you just as you get to like the really good part of an article, right? You don't want that. You want the cliffhanger to be in the right spot, right? You don't want a gun ad in the middle of an article about gun violence, right? We wanna be mindful about what we're serving up, how we're serving up, how we're shaping that story for somebody. So this particular mockup is showing pre-inserted ads. This is like the block template thing again, right? Where you open up an ad new and you've got these things already in place and you put your stuff around them. This is a pretty common paradigm where you have like a certain number of ad slots that have to be shown on a page and you kinda wanna shape your content to go around them and that's what it allows the editor to do, right? It allows the editor to think like maybe I want one introductory paragraph and then the ad is like a pause of sorts, right? It's like television, right? It is a narrative. You get a pause, you get a longer bit, you get to like a really exciting part, pause, right? And then you continue. And that's something that you can think about by treating ads this way. I think as the block API continues to evolve and you can see like how outdated these mockups are already, right? Like the UI is already different in Gutenberg. We might even be able to do something like auto-inserting ads every few blocks of a certain type, right? We don't wanna insert a new ad every few short little blocks but every few paragraphs, every few images, something like that, right? So we might be able to auto-insert a block every once in a while based on what's come before it. And then maybe you could even move them around within certain limits, right? Like you could move it up or down one. Maybe our days of like parsing HTML in order to insert programmatic ads, maybe those could come to an end, right? It's a very unpleasant experience for developers. This is a really cool demo I saw the other day. I'm like very upset that I didn't think to do this. This is using a block. Let me see, is it gonna play? There we go. It's using a block to control background imagery with shapes and patterns. I'm gonna let this play out. It's like a minute. I don't know if I should narrate it. Yeah, I don't know, it's like self-explanatory but for people I guess you can't see it. So there's shape control so you can pick shapes, sizes, where it's located, and then add another shape. And so these are blocks that don't actually take up space, right? These are actually background blocks that go behind your stuff. But because they wanna be able to layer shapes and patterns on top of each other, right? There are two ways that you can accomplish this, right? You insert one block and then you have like repeaters or you insert multiple blocks with different shapes. In this case they've chosen multiple blocks, which is pretty cool. And so you can do a shape. They've got a very lightly colored shape back there and then patterns. And I just thought that that was a really, really cool way of thinking about something that it is descriptive about a post, right? It is metadata and probably storing it as post-meta or whatever, but you get that visual interactive way of dealing with it and you get to see how it actually meshes with your content, right? Like maybe a triangle would look really stupid in those contexts, I don't know, you know? So you really get that level of control and control colors, et cetera to match your template and all of that. And I just thought that was a really cool way of thinking about blocks as something beyond the content but still as an integral part of it. The final thing that I wanna think about is thinking about outside of that single post preview concept, right? So this is a problem across CMSs. A lot of people have been talking about it recently. I saw somebody at Lulubot, a Drupal person talking about it just like a couple of days ago, which is what do we do about previewing stuff in different contexts, right? This is what comes next. This is what that first example that I showed you from like back in 2012 was about, was about previewing stuff outside of that single post in archives, right? What is your stuff gonna look like in an archive? What is it gonna look like on a homepage with a featured image versus the featured image on the individual post, right? That's the thing that we really need to think about going forward. And I think that this is what I'm excited about when I think about what has been declared as phase two of Gutenberg, right? Where we're getting into blocks now, right? They've been introduced in the editor, right? We have time to get used to it, hopefully, as like a concept of our sites as the base of our sites and what's coming next. And hopefully you've all heard of it, but if not, I would highly recommend looking up what's been declared as phase two for block-based editing, which is that it should encompass the rest of your site, right? You're gonna insert blocks and control lots of things. So we already have this, widgets, menus. These are blocks, right? So we're gonna take all of these disparate concepts that we have, getting unified on as blocks. And that's something that's really powerful to think about because we now can get ahead of the curve and start thinking about things like, what if we wanna preview something outside of that single post preview context, right? When we get into reusable blocks, dynamic blocks, that sort of thing. We can get into what is it like when you want to preview something outside of just the individual post context? I promise I was gonna do this. I put a Cardi B quote. It is really good and healthy for our community to disagree. There's been a lot of disagreement lately, you know? But what I wanna think about is focusing on getting creative again, right? Like focusing on something positive, constructive, right? Get out of litigating the process, right? It's done. I have opinions too, whatever, it's fine. I wanna get, I wanna move forward and I wanna really think about like, what are the possibilities that this brings to us, whatever the timing might be? You know, gotta change it up, change up what you're doing. I translated this for you, for those of you who are not super into Cardi B. This is me saying, embrace the change, right? You know, just stop, stop, you know, fighting with the software. Stop fighting with the software. Think about like, what is it gonna enable you to do? What is exciting about this thing that is happening? What is scary, right? It's again, totally natural and normal to feel scared by it. It is intimidating, the JavaScript stuff, like I don't know what's going on sometimes, you know? That's fine. You know, we have to figure it out, we have to learn, we have to grow as developers and hopefully we can create even better experiences. I don't want us to get stuck in continuing to want to do things the way that they always have been. I don't want us to think like, okay, my bed-a-box works, it's fine. I'm just gonna leave it alone forever, right? That's not good enough. I want us to be a better community. I want us to do better things with WordPress. That's a part of how we can grow as a software project, right? Agency's custom development, this is all a part of how the ecosystem continues to grow. And if we don't break out of that and get more creative, build better experiences, we're not going to be able to do that, no matter how much more the core software does. All right, that's it for my talk. Thank you very much. Thank you, Helen. Thank you. Is there... Do I have any questions for Helen? Really? No questions for me? Everybody's afraid of me. There we go, all right. Hey, Helen, great talk, thanks. So I have a question if you could think off the top of your head of a UI example outside of WordPress space in other apps or mobile apps or things in your everyday life that you're like, oh, I wish I could see that in WordPress. One thing that I've been using a lot recently for organizing my brain, basically, I still love my paper planner. I don't know how many of your paper planner users, I'm one of those. But another thing that I've been using for sort of trying to organize my brain a little bit more, especially as I've moved countries and had children and all this stuff, there's just a lot going on. So what I've been using is an app called Notion, which is super cool. I don't think that WordPress should recreate Notion, right? I don't think anything like that. But sort of the way that this single app environment works, the way that you have a very clean preview of what's happening, it is a block-based editor, extremely explicitly block-based editor. And it made me think of Gutenberg as I started using Notion probably about a year ago. And that's something that's been really cool to me, so it doesn't have the web preview context, right? It doesn't have that end of things, but as an app, it's just super interesting to think about what are blocks, how do they interact, how do I use this thing? How does my brain work? How does a tool match my brain? Like, that's, I think, one of the things about custom development for WordPress is we're trying to match the way people think and not everybody thinks the same way, right? So it's like teaching, right? You sometimes have to change up your teaching methods to match what actually works for a given student. You might have to try 17 different things for a class of 12 people, you know? But that's how it is, too, with custom development, right? We really have to think about, like, how is this particular set of users gonna need things to be shaped for them in order to work for them? And I think that's what's really cool about custom development, as opposed to something like Notion where I'm trying to bend the tool to fit my brain all the time. Cool. Someone else? Down here? I don't know. Hi, Helen. Hi. I'm wondering what do you see as the business or monetary benefits of better experiences that you get by not providing, you know, just a bunch of meta boxes are? Yeah. So I do think about this quite a bit, you know, being in the agency space, and I've been at Ten Up for seven and a half years. Yeah, Jake's not even ten. I was a first full-time employee there, so it's been a very, very long time and very involved in a lot of business and sort of things and thinking about, like, how do we grow as a business, like, in my role, right? Like, how does open source development, something that we're not, you know, directly getting paid for necessarily most of the time, how does that still translate to, like, business objectives and how does it help grow our business, right? So for something like this, there are a lot of different things that you can get out of it. I mean, there's the ideological, right? Like, we just should be doing this. Makes our clients happier, they're happier to stick around, they stay on their retainers, they do new projects with us, they refer other clients to us, right? Like, your client relationship, I think, is really number one, especially in the agency space, right? Like, the way that they continue their business and can bring in new business. I think that it helps your developers just be better developers, continue to grow, right? Again, it's very easy to kind of get stuck in the same thing and never really grow as developers. And I hope that for a lot of us, you know, that is still an exciting part of the web, right? Working in the web industry is that we do get to do new and exciting things all of the time, right? Sometimes it's hard, sometimes we don't know what's going on, but that should still hopefully be an exciting part of what you're doing and hopefully something that still appeals to a lot of us. It's not to say it's the only reason why people get into it, right? Like, I got into web development, so I'd have like health insurance, you know? Like, very, very practical consideration. But then it turns out that this is a really exciting part of the process for me, right? It says stuff like this, where the software is constantly evolving and I really get to sharpen my skills and not just the development skills, but also my UX skills, my thinking skills, my business skills, my communication skills, all of that, right? I get to work on all of that stuff, working in this community. And then, of course, it is a marketing advantage, right? You can go give talks in places and you can put out white papers and you can write blog posts and do case studies, right? Let's see, all of that, that all matters. And it all does add up. Sometimes not in a directly measurable kind of way, but it's definitely important and critical to a business. Someone, right over here. Yeah. My question is kind of about the difference between the way it's going, where you're seeing what it will look like, versus the value of, for instance, the distraction-free editor or that separating the form, like a nice meta box, you know, can really focus you to just pick exactly what you're talking about and not get distracted by the color or maybe what it might look like in this particular theme, when this data might live past this theme or any of that. So I think about maybe that there is value in not seeing what you're designing yet and Gutenberg just makes me really curious. Like, is there ever a danger in your mind of merging design and content so intimately when maybe there's value in not, or having the option to not? Right. So this is also a part of the Gutenberg project and sort of the block-based concept at large and what's in the 2019 theme, which I definitely encourage everybody to take a look at, which is that, you know, we're not trying to recreate page builders in WordPress Core, right? This is not a thing that Core is trying to do. We're not trying to replace them. This is not like a good central thing to what we're building. Instead, for the Core project, what it becomes is that themes should be more prescriptive about those blocks, right? Right now, we kind of have themes that do it all, right? You have themes that advertise themselves as like set it up to do any number of things and some of them include wizards now to do initial setup for you. We have starter content in Core. We have all kinds of stuff to support that. But really, I think themes should be more opinionated. They should be more restrictive about what kinds of blocks can you insert? What kinds of colors can you pick from, right? They should be more restrictive about that stuff. They should be more targeted toward specific audiences, right? Where you have that curated editing experience for that one specific use case, right? It gives us a bunch of benefits. We can have better previews of themes, right? Where people can truly see a theme and understand this is a theme that's gonna work for me and what I'm looking for, right? Your average person is not out there thinking, I can, like I was talking about, I'm not gonna take this theme and bend it into a thing that I want. What they're doing is they're going out and they're looking for a theme that matches what they have in their mind's eye, right? And that's what something like blocks can really enable for us is really actually getting more restrictive about those things, but in a predictable way, I think is what's important about it being in the core software. Hi, oh, sorry. In the center. Right over here, hi. Sorry, so I really like how you ended the talk, talking about kind of getting past the process and embracing the software and just start using it and building it. So looking forward to phase two, what excites you the most about phase two and what are you looking forward to and what are you excited to build on phase two? What I'm really excited about actually is the process part of it, funny enough. I'm really excited to see what UX and UI designers do with this phase two and Mel's looking at me like she's gonna be seasick. So I think this is a huge challenge, right? Because we have this existing customizer interface that does like some parts of theme customization. Now we have like block editor and the editor. Where do those things merge? And I think that's like a super interesting UX challenge. I'm really excited to see how that goes. And the other thing that I'm really excited about that, that we get to have a lunchtime meeting. It's like in my calendar and everything is about the design systems that could come out of that. And so we could have better components for reuse by custom development shops. And that's something that I've been on about for a very long time. And I'm really excited that this is a place where I really think that we can bring those things together and finally truly provide that for the community. Okay, one more in the middle? All right, Twin. Hi, Twin. So with the whole idea of making the editorial experience look more like the front end in the way it's designed and stuff. And so it's more even. Do you think there'll be a time when we don't have the preview button? That's a really good question. I think that's what this previous part about phase two is really gonna dig into, right? Like once we have blocks encompassing the rest of your website, what happens to previewing? What is actually the line between editing mode and viewing mode, right? And I think that that's gonna be a really, really cool but hard challenge to think about and to build around. And it is possible that we end up in a place where maybe it isn't like a preview button, but you kind of have view mode, edit mode, right? And that is a place that you could conceivably end up with. With like different screen sizes and all of that, I think we're still gonna be in a place where sometimes in context, there's a preview button, right? But I think we may very well be approaching a time where the preview button isn't as much of a thing and just like everything is a preview all the time. So. Thank you. Thank you. I'll be at the happiness bar after this for any further questions. Like from my CEO who's raising his hand. So thank you very much, everybody.