 So, this is the first time I've given this talk, it's a bit more theoretical than a lot of the Gutenberg stuff you'll have seen this morning and I've seen today. It's kind of uniquely sandwiched in the middle between sort of some of the one-on-one and intro stuff and some of the actual how-to-build block stuff. But I'm interested in this question of structured content from a how do you build CMSs and how do you prepare and future-proof content and have content that is abstracted from its presentation layer and what Gutenberg means for that, right? And I'll be upfront, I'm very excited about what Gutenberg means, I think there's a lot of great opportunity for what Gutenberg is, 10 up we've been building a number of sites on Gutenberg and we're very excited about working with it, but I want to make sure that in the process we don't replicate some bad assumptions and carve ourselves into some, or paint ourselves into some corners. So I'll start with the blob in the chunk. So we've been here before. This is not actually at BU, this is from WordCamp Boston 2013, which was Halloween-themed and was held at the Nerd Center over in Cambridge. Anybody in the room who was there? A few of you, good, not just me. But so I gave a talk there about Beyond Posts and Pages about structured content in WordPress. And what I meant by structured content was pretty heavily informed by these two books, Karen McGrane's Content Strategy for Mobile and Sarah Wachter-Bookter, or I like to say Sarah WB, so I don't have to try to pronounce her last name, Content Everywhere. And what both of these books try to tackle is the notion of structured content and the notion that content management systems can be broadly divided into those that think about content as blobs and those that think about content as chunks. The key differentiation is that in a blob-based system, what you're doing is putting a lot of different pieces of content all together into a single big field, i.e., the post-content, right, the sort of standard single WYSIWYG field that has a lot of different kinds of content mixed into it. Those blobs tend to be a mixture of presentational logic and structure. So they're a mix of both what the content should look like and what it semantically means underneath that surface appearance. They tend to make reuse difficult because if you have mixed together the presentational logic and the presentation information with the structured information, it can be very difficult to separate them in order to reuse. But they're much faster to create both as systems to be developed and also as content author. It's much faster to create content in them in many cases. Systems that are more chunk-based, and this choice of blob and chunk, I think we can blame Karen McGrane for, but it's one that I have used ever since. Systems that are more chunk-based try to break the content down into smaller, more structured components. So a famous case study here is the NPR cope strategy. Create once, publish everywhere. And if you've seen sort of demos or screenshots of that system, lots of small fields that you're filling out form style, right? So instead of one big field that you're entering all your content into, think of 30 smaller fields, each of which has a specific semantic meaning, right? The value of that is that it separates the presentation and structure, right? So if you think in WordPress terms, for example, when you're writing a blog post, there's some stuff you're putting in the main content well, and this is true pre-Gutenberg or post-Gutenberg. And then there's other stuff that you're filling out in the sidebar, like categories, right? An author and post-slug. Why aren't categories just in the body field? Why don't you just start at the top of the blog post saying, this blog post is called X, and it appears in categories A, Y, A, B, and C. Well, the reason you don't do that is because then you'd have to manually go create the pages for categories A, B, and C, right? The fact that the system knows that when you choose categories or tags, they have a different meaning than the content that's in the primary well, is of tremendous utility to you. The fact that the system is tracking the author is of tremendous value in lots of different places. Only one of which, and maybe even the least interesting of which, is to show the author on the front end, because in many of the kinds of systems that turn up works on, the person who was logged in is the author isn't actually at all what's going to be shown as the author. It's actually going to be somebody else, right? Systems that are based on chunks more likely facilitate reuse, or the greater the chunkiness of the system, the easier it's going to be to create significant content reuse is maybe a different way to say that. But they tend to require more planning up front, because you need to decide what those fields are. You need to have that content modeling conversation to say, what are the first class objects in our system, and how do they relate to each other? So where is WordPress on the blobby to chunky spectrum? Well, the argument I was making back in 2013, in this video that I'm referring to, was that by default, many people use WordPress in a very blobby way, but that it can be made more chunky. If you take the time to create custom post types, if you create the time to create custom taxonomies and post meta fields and do a bunch of other work, you can make systems in WordPress that are very, very chunky. AMC, the channel, formerly American Movie Classics, uses WordPress and they have a whole system in their dashboard that's all about creating shows, series, episodes, and cast members. There's no post anywhere. There's no concept of a post, right? It's all very structured data and they have significant relationships to each other, so that you can very easily say in the system, I wanna show all the video extras from season three, episode two of The Walking Dead, that feature Daryl, right? And the system knows each of those things as cemented concepts and can very easily get to them. So enter Gutenberg, right? Gutenberg uses blocks to create all types of content, right? And you've already seen a couple of different demonstrations of blocks, thanks to Tammy and others. Blocks enable us to create richer content, but blocks are also buried in the main content field, right? So is Gutenberg making us more blobby or more chunky? That's what I wanna talk about today. Short answer is depends on who's doing the implementation and depends on where we end up, but done properly, I would argue, Gutenberg will enable us to get some of the ease of use features of blobbier systems by creating a direct modification, by creating a preview that looks more like the thing being edited by letting people edit in place in a way that's more natural to the author, while also if the developer does the right things, preserving structured content in the ways that we need to preserve structured content. And this will be especially important as we get out of the first phase, which is just the editor focus, and get more into some of the other phases where we start to touch other parts of WordPress. So quick sample, and I know this is placed in the advanced developer track, but this is actually the only code of any kind that you're gonna see in the presentation. These are some sample block contents on the left-hand side. The URL that's scrolling up the side there is just where I found this from. It's sort of a sample of every block in a single post. And then on the right-hand side is the HTML and what's actually stored in the WP post table as a result of that. And so what you see is the HTML comments, right? Open angle bracket, exclamation mark, dash dash, being the opening of a comment and then the one below it being the close of the comment. So that first one is a WP heading, has the H2 and then has the close heading. What that means is we're storing some content in a structured fashion, but its structure is somewhat limited, right? So categories down here at the bottom and latest posts, the headings that are interspersed are just the same headings over and over again, but the other examples change as you go through, right? The categories is a dynamic block, so it's actually pulling dynamically categories. So what's stored there is semantically a notion that WordPress understands that what's here is effectively maybe what we would have called a widget or a short code before. What's here is a thing that I'm gonna take some action on when this post gets consumed, right? So it's more structured than the old Bob style but it's still kind of they're all buried in one place. Here's a slightly more complicated set of examples. I couldn't leave the existing Twitter example in so I had to add my own at the top but I left all the other content the same. These examples get slightly more complicated if you look down at the bottom two for example, WP core embed YouTube. There's a structured representation of the URL, the type is video and the provider is YouTube, right? This carries some of the kind of metadata about this embed in a structured fashion that could be parsed by structured readers at the same time as we get sort of the default, what would have been automatically turned into an O embed the URL. So our blocks blobby or chunky is the question I'm ultimately asking. Blocks have structure in the sense that they are stored in a structured fashion but a block is a chunk stored inside a blob, right? So at the end of the day, what actually ends up being stored in the WP post table or in the post content in the post table is a set of HTML markup plus, right? And I think the Goodberg Handbook does a great job of trying to sort of explain the philosophy behind that using sort of type setting. What gets stored is the content of the blocks but also some of the information about how they were made in the first place. So it's sort of better than just the HTML that we had before but not as much as we might otherwise want. So to help us explore this, because I know it's a very sort of theoretical thing, I decided to come up with a hypothetical case study and I used album reviews because it's, I'm a huge time music fan nerd and also it's a thing that people actually understand in terms of relationships between content. Albums are by artists, reviews are by authors, they have relationships to each other, in genres, et cetera. I was going to, in the had I but world enough in time, make a mock album review site, which because I'm from Salem Mass was going to be called Witch Fork, but I ran out of time. So instead I used screenshots from Pitch Fork for which I'll apologize because I have nothing to do with Pitch Fork and they know nothing about this presentation. So let's think about metadata and data, right? So there's the contents of the review itself but then there's this other stuff that I've been calling metadata. The metadata in this case about an album is the artist, right? And I've highlighted these off on the right, the title, the cover image, the label, the release year and I would argue the categories that we can debate that one in a minute whether that's actually where categories belong or not. And then there are some things that are about the review. There's the author of the review, there's the date of the review. Arguably there's probably multiple dates of the review because there might be original published date and modification date, et cetera. There's the score, in this case a horrifically low score for what's really a fantastic album. The Decemberous I'll Be Your Girl, which I love. And this kind of subhead, which is one of those things that's sort of part of the review but not, right? And likely is stored in a structured way in the system so that it can be called out separately and used in other places. So how would you create this if you were building it in WordPress? In the pre-Gutenberg era, which some of us would call the present. That's a term, it's good. So in the pre-Gutenberg era, the bad way to do this, and maybe I shouldn't bury the bullet at the end of don't do this, but let's just walk through this with me. The bad way to do this is just use the wisdom editor in the content. I have actually seen people writing WordPress blogs whose theme doesn't support categories who are writing at the top of the post under the featured image, appears in music comma reviews. No, that's not the way categories are supposed to work. Use the categories that exist. So if you were to just open up a new post editor and at the top create, float an image to the right, create a title on the left, but the December's I'll Be Your Girl, put a little image for the score on the right-hand side, it's very easy to do, depending on your knowledge of HTML, maybe in your comfort with the wisdom editor, but it creates an incredibly bad problem, especially once you have thousands of these, right? So if you're writing a blog about lots of topics and it's kind of a personal or lifestyle blog and every once in a while you wanna write a review of an album, maybe this isn't a bad idea because you're just dropping kind of an image in. But if you actually expect to build a site around this and a business around this and have reuse and have the ability to abstract these things out, don't do this. Round one B is use a short code to insert the album bit. Slightly better score here for the Tree of Forgiveness, John Frens first album in 13 years, you should listen to it. You could use a short code to insert the album bit. You could use your short code UI, aka short take, which means just like you get insert image, you get a little insert post element, I think it's called these days, which then lets you choose what kind of short code to embed. What you get there is a bit more structure in the sense that the short code will have a certain number of kind of content fields and how they operate, right? But you still pretty bobby because you don't get good programmatic access to the data inside the short code. Many of you have run into this problem when suddenly a client says, I want you to find me all posts that contain the short code X, right? And now you have to go parse the post content table to try to figure out what are all the places where that short code is used. So better way to do this. Oh, and there's another meta field. So I said categories we could talk about. Is the category a part of the album or the review? Could be both, right? It could be this is a review that appears in rock. It could be this album appears in rock. It could actually be that the reviews and the album have different categories and then you'd have to figure out what that means. Here there's a track. Is that track metadata associated with the album or is it metadata chosen by the reviewer? I would argue the track itself is metadata of the album but the choice that this is the featured track is metadata of the review. So we'll have to think about that one in a minute. So round two, better way to do this. Review custom post type with specific post meta and taxonomy. So some of you have probably seen WordPress interfaces that work this way. You have your standard posts with title and excerpt and body and author and all that. And then you have a couple of other custom metadata fields where you say who the artist is being reviewed, what the album is, maybe what the score is, right? And those are all stored in structured way as part of the custom post type in its post meta or in its taxonomy. And the template knows how to display those things. So when you're typing drunk into the post meta field for this album, you don't need to put it in italics in a certain font. You just put in that it's drunk and the template knows that presentation data. So we get to that separation of presentation and content. This lets us, for example, then use that album cover which is a brilliant album cover as the featured image for the post because we have it stored in a separate field. We know it's something different. We can sort of control how that operates. And it gets you better reuse. Challenge, what if you wanna have multiple albums per review, right? So that approach works pretty well as long as you have a single album per review. Rollingstone.com recently relaunched on WordPress and Aaron's in the audience, so I'll call him out on it. Fantastic relaunch of Rollingstone on WordPress as a platform. One of the things I immediately went to look for is at the back of Rollingstone in the review section and I've been a print subscriber for years, there are often these reviews that are multi-album reviews, right? Sort of here, Electronic Outliers or Ken Popp's Heart Barbs to Grow Up. The red brackets there, there's three different albums being reviewed in each of those reviews. This is a print scan because I can't find those reviews online anywhere on Rollingstone.com and my hypothesis, which I won't ask you to confirm, was that the review structure, content structure doesn't actually account for multiple albums in a review and therefore you can't display it. So real case study that I know nothing about so I can't tell you that's actually what I mean. But pre-Goodenburg, round three, this is ultimately where most people end up, like this is how a lot of sites that 10-up builds operate is you would have a number of custom post types. You'd have a review custom post type. You have an album custom post type. You might even have an artist custom post type so that we can say, love this giant is an album by David Byrne and St. Vincent. Other systems will treat this as like album artist. So there's this notion that David Byrne slash St. Vincent is an artist, which they really aren't. They're really two different artists but again it gets more complicated. You would then have a way of storing the relationship between the review and the review. So in writing the review, you'd have some mechanism post to post or a post picker or some other kind of mechanism like that, maybe a shadow taxonomy to relate the fact that this artist is, and this album is the thing being reviewed and this album has this relationship to these artists enables a lot of reuse but the editing process gets a bit more complicated. Because if you think about it, I just wanna start writing a review. Well what if that artist doesn't exist yet, that album doesn't exist yet, all these things don't exist yet, I've gotta create them in that process. A lot of times what we end up doing is actually sort of for bonus points, changing the editing workflow so that we can actually create the album and the artist on the fly as we're going through that process if they're unknown. So that the editor can work in the order that they know the information rather than trying to adapt to the system. And to a Gutenberg, there should be some dramatic music when that happens. But budget is low so there's one. So round one of doing this in Gutenberg, you could replicate exactly the same bad round one we had before. You could make albums blocks. You make them a custom block. You can put an album block anywhere. An album block has these text fields in this image. Editors can have 50 of them in each review. They can have all they want or they can have one in the review. They can put it at the end of the review or in the middle or at the top or anywhere they want. But you're gonna get some inconsistency. So maybe I put John Coltrane, maybe it really should be John Coltrane Quartet. Maybe I put Decembrus and it really should be The Decembrus. Maybe I'm one of those crazy insane people who puts Decembrus comma The, right? Maybe our system ignores The and then you have the fact that you can't find any of your The Albums in your collection because your system ignored The. Maybe based on real experience. So you're getting some benefit. You get the benefits that Tammy talked about this morning in terms of direct manipulation, right? I'm seeing what the album looks like as I'm editing it. I'm seeing kind of how that will appear as part of the review and it's convenient. But it's not storing any of the kinds of relationships. So you could do a reviews custom post type and then you could use block templates. So what you would get is more consistency of layout and structure. And I know we haven't talked about block templates yet but essentially for each post type you can say, here's the set of blocks that need to be present or at least set of blocks that need to start at the top as placeholders. So you could sort of enforce a little bit more layout and structure. You can't still necessarily control the content. So is Beyonce's name properly written with an excellent aegoo over the E? Shenado Connor is a good one for acid testing music systems to see if they've actually handled Shenade's name correctly. Is Jay-Z really capital J-A-Y? Or should it be lowercase A-Y before the Z? Because each person is still adding in the same place there's really not a good way to do reviews and there's not really a good way to say, show me all the album reviews we've done of albums that contain Beyonce and the artist, right? Like the system doesn't have a good solid way of doing that. I'd say you couldn't get there through some effort but it's not as simple. So round two B, what about using the saved blocks? Or, and I think there's still an active ticket about what the terminology should be here, reusable or global or saved or shared blocks. You could do that and what that means is that then if you name your saved block correctly there's only one copy of Laura Marlings once that was an eagle in the system because it's a saved block that everybody can access and reuse. But under the hood, saved blocks are kind of just a custom post type with a type of WP block or something like that, I forget the exact name. So if you're doing that a lot, you're gonna get a lot of those blocks and there are gonna be a lot of different kinds of blocks and it's gonna kind of create a weird system of trying to find them and locate them and reuse them if they exist. And then I would say it's sort of a weak 1.0 and I don't mean that as a criticism which means it's a 1.0 implementation of what global box might be like. For a blogger who wants to have their standard subscribed to newsletter thing that they use on lots of different posts, I think that's a great thing. For somebody who's really trying to do structured content it's sort of the wrong tool for the wrong job. So Gutenberg round three reviews and albums both as custom post types each with their own post meta and taxonomy. Maybe there's still a point for a block that pulls an existing album custom post type into review. So a block that says maybe I want not just the album review that not just the album that this review is about but maybe I wanna mention Lucinda Williams other albums, right? So maybe it's useful in the review to be able to say I wanna insert a custom block here that refers to some other albums still pulls in the same layout still creates some visual consistency still creates a lot of structured content but is now using the CPT, right? And the CPT could still use a block template for editing. So you'd still get some of that kind of consistency of visualization you'd still get to sort of see the thing that you're editing when you're editing it because I'm going really fast here so I'll try to slow down the key differentiation of being able to actually see what you're editing versus not is core to this structured content conversation, right? If I go back to the original discussion about the blob and the chunk one of the sort of challenges is systems that are more blobby can do WYSIWYG because basically what you're editing is exactly what's gonna show up on the front end systems that are more on the structured end of the spectrum are not showing you exactly what the content is gonna look like you're actually editing the underlying data model, right? When you're changing the title of the album you're not changing that set of words that's gonna appear on this post you're actually changing the underlying semantic data that gets represented in multiple different ways on the front end. So there's a great set of posts under the hashtag WYSIWYGF so instead of what I see is what I get it's while you figure it out that are all about sort of the challenge of that abstraction and why it breaks. So again this would get us sort of decent reuse but I don't think is the end state. So I think we wanna get to ultimately and we've been experimenting with some versions of this Black Times is a fantastic album that's why I put it at the end. Reviews and albums both as custom post types but now let's think about the editing workflow and let's think about I could be writing that review custom post type it could have a block template and if that album doesn't exist at the time that I'm trying to edit it I can create it in the background REST API right there different kind of server side APIs actually go ahead and create and retrieve that album at the same time. So I can use a reactor jQuery component that has a type ahead that does matching and sort of then shows me if it doesn't match there are lots of kind of interface enhancements you could do and again this gets a little bit more into custom work but it wouldn't be that hard to actually kind of do a type ahead to see if this album or artist exists and if not actually create it and save it on the back end as a custom post type with the appropriate post meta so as though the user had gone and filled out these forms in sequence but with an experience that's more like the new Gutenberg right? So in general what I think is interesting is as we start to work through Gutenberg and what it means phase one in our first focus was this post editor right and I think that's the right first focus I think it will enable people to create richer content but that richer content will also in certain ways be less structured right? The example of embedding videos we actually wrote a plugin for BrightCove that's in the repo that's a lot of large publishers use for BrightCove. Inserting a video through OMBED or through a video block works really well for I'm writing a blog post and I want to link to a couple of videos it works really horribly if you're MSG networks and you want to show all the highlights from the latest rangers game in a structured way that can be searched over time right? So thinking about sort of how do we get the goal get the experience of editing where it feels like you're editing the thing that you're actually wanting to edit but still on the back end make sure that we're saving the data in a way that's actually going to set us up for success in the long term and not creating a bunch of blobs full of chunks which is I guess how I have visualized what happens here. So why does all of this matter? Future proofing. So what happens when new devices get introduced and necessitate different combinations of output? We went through this once already with the mobile revolution, right? Yes, responsive design saved our asses over time in mobile and let us sort of output one set of HTML and have it render on multiple devices differently. What happens when those outputs are now voice based, right? Or it's your perpetually arriving internet fridge that needs to be able to read the out latest album reviews to you, right? When we need different kinds of output if we've mixed together too much of presentation logic into the actual content itself it makes it very hard to do that kind of reuse. The more structured we are the more likely we are to survive those. New features, right? So maybe the first time I built an album review site I would have linked to Amazon because I still thought people bought music like I do. Now I'd want to link to Spotify or Apple Music or Title or whatever, right? As the place where they could listen to that album. If I want to change that after the fact it's harder I would argue to do that in a blobby system than it is in a chunky system. Consistency, so from a database side or information systems thinking side you really want to have a single record for each object. You really don't want to have 15 copies of information about an album floating around in the system. You really want to have one and link to it and use it appropriately. From a relationships point of view if you wanted to be able to show me other albums by this artist for which we have reviews other albums on this label or in this category other reviews of this album maybe Pitchfork finally allows me to write a response review to their takedown of I'll be your girl. Maybe you want to show other albums to which this artist contributed to the David Byrne St. Vincent or Jay-Z Beyonce scenario. And you want your system to be able to do that as simply as possible. Now of course your editor could just go in and create a block that says here are some related albums and they might know the catalog well enough to be able to know what those are but you really want your system to be able to do this in a more programmatic way, right? You want to be able to pull those things in automatically. So my conclusions about structured content in the era of Gutenberg. Block based editing there's no doubt can improve the user experience, the editor experience, the author experience because what you're seeing is a closer representation to the thing being edited, right? Instead of metadata fields in the sidebar that are used to create visual impact in the editing area, you can actually use those metadata fields for things that are truly metadata and still get the flexibility that you need. So in my example of somebody who's actually writing categories, why couldn't I edit the categories tag right on the page and have the system be smart enough to know those need to be saved as categories, right? Why couldn't I be looking at a post and edit its author right in place and have the system know that what I need to do is store that as author information. Block based editing can make WordPress blobby because done poorly it may be mixing presentation and structure and post content. As the WordPress community goes out and builds 15,000 plugins that create 40,000 blocks, how many of them are going to properly understand the distinction between what controls should be in line with the block and what should be in the right rail and what should be under advanced settings and how many of them will mix structure into post content, not just the HTML tags like the P and the H2, but I imagine we will get inline style information, we will get inline script information, we will get all kinds of the bad behaviors of the past. So you end up with structured blocks inside blobby post containers, right? And ultimately what this all comes back around to perhaps and I know my talks are good when I get back to where I started right at the end is that proper content modeling is required in either case, right? The same sets of technologies that we use in the pre-Gudenberg world, custom post types, post meta, taxonomies, taxonomy meta, right? All of those places WordPress provides for us to store data are places we can still use in the Gutenberg world so long as we're thoughtful about where it is that we're storing that data and how we're retrieving it, right? So I left all my intro stuff out of the beginning because I wanted to make sure I got through the talk, but I have been John Ekman, I'm the CEO at a company called 10UP, we're an agency that does strategy, design and development. We are hiring off to the right are some of our highly promoted positions. Please do visit 10UP.com slash careers, especially if you are an experienced senior web engineer, senior front-end engineer, et cetera. We're a fully distributed company so people are working from wherever they are throughout the world. And with that, I will take questions. I'm really interested in feedback on this. This is the first time as I said, I've given this talk, I'm giving it a couple of times more over the next year. I'd love feedback on sort of what concepts made sense to you or didn't make sense to you. You can tweet them at me or if they're really nasty, send them to my email so the rest of the world doesn't have to see them. But truly interested in sort of feedback and questions. And we've got nine minutes by my account. When I first came in, the teleprompter still said applause and I was like, I hope that's true, but thanks. Applause is good. Yeah, I think there is a mic, but if you can yell loudly enough, I'll repeat. Yep. Yeah, that's a great, so to repeat the question for the video, a lot of people when they're doing this kind of structured content are using a framework like ACF or pods or a field manager or MB2 or whatever that one is. My preference and I'm a bit old school in this is to write custom post types directly in code wherever possible. TenUp does have a sort of stated preference for field manager, which is the VIP approved thing in this space. We also have at times worked with clients who are heavily into advanced custom fields or other kinds of frameworks. I think the question is always how much weight am I taking from the framework versus how much value am I getting from it? So if you think about the frequency with which your post types and post meta actually change is fairly infrequent. One of my profs in grad school, when I did my MS, used as an example sort of life insurance. You can pull up life insurance records from like the 1700s and they have the same fields on them that they have now. The structured content type hasn't really changed all that much. A lot of the writers have changed, the core content types haven't changed that much. If you're doing a lot of frequent new content type creation and you need repeating fields and stuff, then some of those frameworks can be helpful. But if you don't, having a developer spend the time it takes to custom craft that post type and only have that code and not have any other exposure to code you don't need or ability to do things that you don't need is actually my preference personally. Yep. Question at the mic? Yep. So I'm not sure how well the audio picked that up because the mic's kind of soft, but you're saying from a relational database structure like database WordPress gets routinely exorciated for not having any kind of real relational structure, right? Everything's in the post table. It's kind of the giant pain in the ass. It creates performance problems. It's not the relationships between posts. There isn't still really a canonical way to do that in the database. So we get a lot of PDP is quite popular or other kinds of mechanisms are popular, but it isn't really a first class data structure in that way. As compared to say Drupal community, I also spent a lot of time in, which has had for a long time a fields API and a robust way to create what are now entities. So they're getting more complex every time but they have a much more structured way to get at that kind of stuff. I do think the grand irony of all of this is that Gutenberg might be a way we finally get a real fields API and a real set of data definitions and a real set of data types back into core ultimately, even though we tried for a long time to have a fields API and sort of didn't make progress on it. What's interesting is the WordPress community by design and go to wordpress.org slash about slash philosophy, right? Design for the majority, simplicity, work out of the box are more important than elegant underlying data structures, right? And for the vast majority of the WordPress community, I think that's the right decision, right? For people who work on larger scale problems or different kind of enterprise class problems that can be frustrating. But I think we'll actually get progress out of this. It just might be sort of in phase 1.5 or two of Gutenberg rather than in phase one where the focus really is on that first editor. There are already some structured parsers that know how to read Gutenberg content and use the annotations and make some smart decisions out of them, which I think is a really interesting space for some things that could happen in the future. What I don't think will happen is the community will one day say, oh, now that we have Gutenberg, let's rewrite the whole database schema of WordPress to be more closely relational and more focused on object orientation, right? And I don't think we should, right? So I think that's the right choice. The other thing I would say, and I probably should find a way to work it into the talk, is we often end up using ElasticPress, which is a tenant plugin that uses ElasticSearch because some of the ways WordPress stores data are not optimized for reading and for these kinds of relationships, indexing in ElasticPress and then using that as a query engine actually is sometimes a way to work around some of the limitations in WordPress's data architecture. The notion, if we had started out from the very beginning to say, we're gonna have an interface that's tuned for how editors edit, not necessarily tuned for a database structure, and then we're gonna find other ways to make the database structure work, kind of would have been the right idea, right? So I think there's something on target about that. Can I see what you're gonna do with this? Ultimately, the really structured content end people want your CMS to basically be PHP MyAdmin and have you literally be creating database tables as you enter content because the presentation should be totally separate, right? And all that should be there is the structured content. This goes back to the dream of SGML before HTML and the dream of XML and all that, right? Pure separation of content from presentation. The reality is we're publishing content in specific mediums with specific look and feel that we're after. Let's not pretend that's not true in that there's this perfect, abstract, ideal version of the content. But let's also not go so far in that pursuit that we lose some of the core structure data we need, right? Cool. I think I've got time for one more. There's my timeline at four minutes. All right, if not, I'll let these folks in then because they'll have time to line up for the next person. Thank you.