 Hi everyone, it is so lovely to be back up on stage and seeing real people in real life. Like it's cool that all of you have torsos and like legs instead of just faces on a screen. So hi, that was like a great intro so I don't have to talk about myself too much. But yeah I'm a designer, friend and developer, been doing WordPress for a while and actually I realized today I kind of did the math and today is my 50th WordPress event that I've been speaking at. I'm really excited to be sharing that with all of you. Thanks. We'll see if you want to clap afterward, it's fine. But I want to talk to you all about the future of theme design because as a theme designer that's kind of important to me and a whole lot's been happening and people have a lot of opinions about that. But before I get into the future of theme design I kind of want to step back through a little bit of the history of themes. So we can remember how we got here so that we know where we're going, right? So historically speaking with WordPress themes were basically these very cohesive templates that were generally separate from the content. And that was basically the whole point of themes because the content was now in your database and your theme was powering the output and that meant you could update your content without having to update code. That was like one of the best parts of content management systems. And the way it worked was that your theme was managing your look and feel, the structure, the way that everything laid out, your content, your words and images and media, those lived in the database or they lived in files. And then you started adding plugins to add new functionality. It wasn't always this perfectly cut and dry but this was basically the way that WordPress was set up when it started. And in this state when themes were like this what was the role of a theme designer? I kind of said that the theme designer was basically the design dictator here, right? Because we were, as a designer, we were dictating the use of color, typography, spacing, branding. You know, we were building like what exactly is this header going to look like? The footer, the sidebar, all of our page templates, our page layouts. Where is content going to be used within the layout? Which content needs to be where? Like the designer had a lot of control over what was ultimately going to be rendered on the page. But then slowly, as many of you remember, websites began to do more, right? WordPress started out with posts and with pages, but we wanted more than that. So sites started to become stores, sales funnels, membership sites, social networks, event hubs, learning centers, communities. And the basic template and content model started to get a little bit of strain. So as a result, what happened? Well, layouts kind of needed to start evolving as content was changing, right? It wasn't just text on a page anymore. We started needing stuff like landing pages and other kind of bespoke content to be able to speak to different audiences. There were a lot more complex functionality needs. You know, once you have products or testimonials or users, you want to be able to lay those out in different ways. And there were a lot fewer options to build these unique layouts without learning code, right? I mean, the number of people that are like, I just want three columns in a row with an image on top of each one. How do I do that? And the result of this was a lot of end user frustration, not being able to make these things that seem like simple changes. And there was also a little bit of resentment about, like, our developers kind of gatekeeping us. Are they preventing us from being able to do simple things? So we tried a lot of different things as a community to try to solve some of these problems. So what did we do? We, you know, we tried, like, widgetized themes. That was one of the first approaches to it. Like, we've got these widgets. Maybe let's put them everywhere. We tried to rely a lot on short codes, you know. Can we build things using short codes? A lot of big page builders were using short codes as well. We used a lot of customizer based themes. There's a lot of options in the customizer. Custom fields really rose up and stuff like advanced custom fields, of which I'm a huge fan. You know, can we use this to craft maybe more custom content layout experiences? Each of these things, and then obviously the page builders of which there are several, right? That was kind of a very big one. And each of these things, they each had their strengths and weaknesses. They had pros and cons. They were doing the best they could. And people tended to get opinions about which one was their favorite. But part of the problem here is that there were so many different solutions that the WordPress content editing experience became really divided. You know, if you asked one person what using WordPress was like and asked another person what using WordPress was like, you would get totally different answers. And you know, if you go to different dashboards, as you might have as a professional, they might not look anything like somebody else's dashboard. So we had a lot of splintering. So block based editing was introduced as a way to start to unify this editing experience for all of these different use cases and provide a visual and procedural set of standards for all of these different needs. We wanted to make the content editing experience more closely resemble how the content was actually going to look on the page and let people be able to do some of these more creative and more complex layouts without feeling like they were beholden to a developer. So the first phase of this was the introduction of the block editor, which has now been available in core for content editing for over four years. Though it's not perfect, it has undergone a lot of changes in that time to make it more stable, more usable and more intuitive. And that brings us up to kind of where we've been at the last couple of years and a lot has happened in WordPress theme and content management since the last time we were all like gathered together in a space. So I wanted to make sure that we're all up to date and kind of what happened during COVID a lot has happened. First of all, currently we've had seven major releases of WordPress during COVID. We are currently in phase two of four of kind of the roadmap for WordPress which is centering currently around full-site editing. The previous phase was around the block editor and how to build that. Two new core themes have been released in that time, so 2021 and 2022, which was the first dedicated full-site editing theme. We've also introduced like a whole lot more core blocks, including site-level blocks that let you actually build site layouts in addition to just page layouts. We keep getting more and more detailed block styling options, including stuff like typography, color spacing layout, and also the widgets that we talked about before have also been converted to blocks. And then block patterns were introduced, which is a collection of blocks, query loop block, and all of the block options that came with it became more robust. And then we also now have the block directory and the pattern directory to be able to search for individual blocks or individual collections of block patterns. Now patterns being predetermined groups of blocks that let you streamline your building process. And then this one you're going to hear about a lot from me in this presentation, but the theme.json file and all of the new kind of global styles and variables were introduced in 5.8, and then they introduced support for child themes, and then style variations in the last couple of releases. And then the big one, full-site editing, got merged in in 5.9, which is supporting this entirely new templating system for building WordPress sites. So a lot has happened in the last couple of years, and this is where we're at now. If you want to learn more about kind of where WordPress is headed and where it was coming from, you know, check out this link. It's pretty good. But I want to get back into what we're here for, which is what is the purpose of a modern WordPress theme? Because if any of you have been following block editing at all, you might be feeling like, I don't really know where this is going. And for the average end user when we think about a WordPress theme, modern themes are pretty far from these like mysterious black boxes that they used to be where you input content and then a custom layout just comes out the other end. We're also pretty far from the days where you needed to have a complex page builder system or a very heavy plugin just to be able to create three columns with images and a button. Nowadays, with full-site editing, the concept of even having predetermined templates is a little bit up in the air because a user could completely redo or rewrite or create new templates right from within their editor. So in this modern WordPress theme almost kind of feels like maybe it doesn't exist at all. So in that case, what is the role of a theme designer now? We're not a dictator anymore, so who are we? I propose that the new role of a theme designer is a creative curator. We care deeply still about brand and aesthetics. That's why we do what we do. But our methods and our audience have changed. So our job as a creative curator is to provide a thorough set of thoughtfully curated opinions, patterns, styles, layouts, templates that actually function as suggestions for the end user to be able to build their content off of. And that includes a lot of different things that we should be providing, right? We're not necessarily building bespoke layouts. We do have to think about color typography and spacing. We have to take into account all of the different core blocks and some third-party blocks. And we want to create all of these rules for how all of these things combine within the content and really help our end user be able to build these compelling layouts that are still understandable and on-brand. So we don't just design the experience for the website visitor, which we've been doing as theme designers. We are also designing the experience for the content creators. We are curating the content building experiences to enable their guided creativity. So we're asking ourselves a lot of questions as designers. Do we need full-site editing for this? Do we need to support every single block style option? How much control do we want to give the end user? And how free or locked down should our content creation be, right? So as creative curators, we can extend and enhance the block editing experience by providing maybe additional styles, patterns, and controls for blocks that already exist. So the questions we're asking ourselves are like, do we want to maybe create some block patterns or pre-populated blocks for our content within our theme? Do we want these to be changeable or do we want them to be fixed? Do we want to extend any of the core blocks that are already available with maybe some custom styles or controls? Do we want to provide multiple sets of styles? Are we including any styles for maybe some specific third-party plugins or other blocks? So then our job is we're not creating these pixel-perfect solutions anymore. We are creating comprehensive design systems where many future solutions can flourish because we're not just thinking about how do our design decisions impact our current content. We're thinking about how will our design decisions impact all of our future content as well. If you've ever heard me talk before, you know I love talking about design systems and I'm going to do it again because they're great. How many of you are familiar with the concept of design systems? Probably a lot of you, which is awesome. As a review, this is a language from InVision. A design system is a collection of reusable components guided by clear standards that can be assembled together to build any number of applications. And one of my favorite things to talk about when we talk about design systems, and I think it gets increasingly relevant in WordPress, is atomic design. How many of you have heard of atomic design? Probably several of you at this point, yes. If you don't know about it, it's basically just like chemistry, so I know you all remember your high school chemistry and this will be easy. It goes from our least complex thing, which is atoms, then atoms become molecules, molecules become organisms, and then the metaphor breaks down because organisms become templates and templates become pages. But what you have to remember is that we're going from the least complex to the most complex, the smallest to largest, and the most general to the most specific. There's a fun animation here, kind of showing how atoms evolve into molecules, which then evolve into organisms, and then these come together to become a template, which then becomes a page. So it's super fun, and we're going to be talking a little bit about this kind of as a review. So first of all we've got atoms, atoms are the smallest building blocks, and atoms in this case would be all of our HTML elements. This is a really fun graphic that I've found, the periodic table of HTML elements, pretty clever. But basically you're noticing that it is all of your unique HTML elements, but this also includes your colors, your typography, your various utility classes, those would all be considered atoms as well. So as an example, and this is from Pattern Lab, which is Brad Frost's site, Brad Frost is the person who kind of coined the term for atomic design. You can see an image, a heading, color, swatch, paragraphs, and input, these are all atoms. They are not very exciting on their own, much like atoms, they're just kind of floating there and not doing anything, but eventually we can build some cool stuff out of them, and that's when we start getting into molecules, where we are combining HTML elements together in specific, useful ways. So as an example, maybe it's an image with a caption, maybe it's a title with a link, maybe it's a small bit of a list that is navigation, or a photo matched up with maybe a title. So you're starting to see these start to look like stuff, these look like content, these look like content patterns. Still not that exciting yet, they're still kind of floating out there not really doing anything, but that's when we start getting into organisms, which is when we're now combining several different molecules together, and we're gonna start recognizing these some block-level elements, right? But usually organisms are more complex, they're repeatable, and they're their own contained unit of content. So some examples might be a gallery of images, or a list of several posts, or an entire form with multiple inputs and its submit button, those would be great examples of organisms. In the context of full-site editing and templates as well, variants of the same group of content would also be considered an organism. So these are like several variants of a header of a site, each of which could be included inside a full-site editing theme. Footers, sidebars, other similar things, you might have several different organisms. And that's when we also start getting into stuff like templates. So if we're starting to combine these block-level organisms together in different ways, we're starting to build templates, which are again repeatable combinations of organisms, and these often are entire layouts or entire content stories. So, for example, you might recognize some of these elements from some of the other pages, but now we're starting to combine headers and content and sidebars and footers, and we have now started creating templates, right? These can be replaced with other things. And then we have pages, which is where you take a template and put real content into it. So again, you have specific content, so you could have the same template, multiple pages, great example. Here is a template, here is some content. So we're all following. Atomic design makes total sense. Great. So, how has the move towards block-based content and full-site editing made WordPress theme design more atomic? Because I think, I've been talking about atomic design for years, and I think as block editing has become more and more pervasive, this is more and more relevant. And in order to do that, I want to talk you through a little bit about the structure of kind of a traditional or a hybrid theme versus a new full-site editing theme and kind of what we're looking at when I start talking about these things. So, first of all, this is a standard theme which can also be used as a hybrid theme, a hybrid theme meaning you're still writing PHP, but you can support a lot of the block content, editor stuff. This is your basic file structure. There's a lot of other things, but you have your functions.php or index.php, your style sheets, any other PHP templates that you want to support following the template hierarchy. You have any other functions in your includes folder if you want to. Any assets like CSS, JavaScript images you want to include, right? And then you also have you can have a theme.json file. And again, I said I'm going to talk about it a lot because it's kind of a big deal and it is usable in PHP-based themes as well as in full-site editing themes. I think we should all be paying attention to that. And then you have a full-site editing theme and the biggest difference you'll notice is that there's not that much PHP left anymore. I mean, you're still using it to write functions. But we have all of these like HTML markup block template things and it's a very different structure now. You still have your functions, your index, your style, but all of your content now lives in templates and template parts. And it's a little bit different. And then we have this new folder called styles which actually contains other JSON files if you want it to. So this is real exciting. So I just wanted to kind of give an overview of these things because depending on whether you're doing a hybrid theme or a full-site editing theme, it might work a little bit differently. I wanted to bring just a little bit of attention to how styling themes works because some new things have been introduced again with the theme.json. So traditionally, we're using CSS and then also maybe an editor style.css now that we have the block editor. These are both required if you want your front-end and your editor to look the same. I guess you could also just enqueue your style.css in the editor, but I wouldn't necessarily recommend it because they have a few different needs. But you can use these on their own. You can also, if you're using a theme.json file, use these to supplement that. I'll talk a little bit more about that. But I did want to also bring up stylingwiththeme.json. So this is the newest styling tool. Like I said, it can be used in both a hybrid or a full-site editing theme. And what's cool about it is it automatically generates things that are loaded in both the front-end and the editor. It generates both CSS variables and also CSS styles depending on what part of it you're working on. And it's responsible for most of the styles in full-site editing. I say most of it because I think the ultimate intent is for you to basically be writing almost all of your styling in theme.json. I, as a CSS person, support where that's going, but I'm skeptical that more complicated things can be written in a JSON file as opposed to a CSS file. But it will certainly be taking care of the bulk of your styling in full-site editing. So something to pay attention to. And now I'll get into actually how do we map all this atomic design stuff I just talked about to WordPress theme itself. So we kind of divide it into a few different categories. I have, you know, your Atom's molecules and organisms. I also put, kind of as a pre-Atom, I have this thing called settings. That could be an Atom, but I kind of think it's a little different because we're talking about, you know, editor settings, block options, stuff that's even kind of before you encounter an Atom. And then we have our Atom's molecules, and for layout, our templates, and our pages. I also want to mention, so I'm going to start showing some examples, and most of my examples are actually examples that have the Gutenberg plugin activated. I know that that is, you know, kind of the bleeding edge stuff that they're working on. I like to enable it for my personal stuff because I want to be aware of what's coming, and generally it's a pretty good indicator of what's going to be coming next in core. So just so you know, you might see some stuff here as examples that aren't necessarily in core now, but probably will be soon. So first of all, in our settings, Theme.JSON, there is an entire kind of section of Theme.JSON that is basically just about determining what the content editor is going to see when they are creating blocks. This kind of replaced a good deal of the stuff that they were doing with add theme support, but basically these things here determine if a particular control is going to be available in the editor. And there's a lot of controls that exist right now. There is, you know, whether or not you want them to see a color picker, whether or not you want them to be able to pick font sizes or font families, whether you want them to be able to control border radiuses, whether you want them to be able to control spacing, all of those kinds of things. Now this isn't setting the values of those things. This is saying like, can my user set custom values of these things? Which is important because again, designers were often concerned with branding. So I provided an example of a paragraph block, and on the left is with everything enabled so your user can do whatever they want. And on the right is a bunch of stuff turned off. And this is the same exact core block and all we did is change whether they are true or false in Theme.JSON. So this is really great if you have a pretty strict brand and you don't want your users doing bright red giant text in a weird font. Right? So we can turn that off. So we have controls here even though this is still a custom editor. We also have options as theme designers to kind of extend the user interface for existing blocks by creating additional styles or settings. So this actually helps kind of reduce the need to build a new block. So if you're like, I wish I had a paragraph block but it just looked like this, well maybe instead of creating a custom block for that you could just create a style for that user to be able to select that. So I kind of created, I showed an example of like here's something that I did for the cover block where we have our default style and then I also created a few other styles that have some special things and they just click on it and it loads. So these are all different things. You can also create custom block controls for existing blocks. The block styles are something that you can do within PHP. The controls you have to do within React. Depends on where your stack is at but this is what I found to be really nice for being able to give users more options without having to create more bespoke blocks. Then we get into our theme.json variables. So theme.json generates a lot of CSS variables and CSS variables if you're not familiar with them are basically just a value that is output in the like header in your CSS. This is the format that they follow. So if you look at the font sizes for example it would be WP preset, font size, slug name, so extra small as an example and that's how it would output. There are several different presets WordPress currently supports. I believe there will probably be more as time goes on but they support a lot right now in terms of color, typography, layout and spacing and these ones you'll be able to recognize if you go inspect the editor because they will have that WP preset at the beginning of them but these again are defining these aren't outputting styles they're not styling a specific element they're just saying like here are the colors that are available, here are the sizes that are available, here's the widths that are available this is what they are. We can reference them later. Theme.json also supports creating your own custom variables which right now I am using extensively I think it's great. You can create custom settings as detailed or as granular as you like I'm really in favor of doing this whether you're doing a full set editing theme or a standard theme because you can basically create a single source of truth for all of your different values and then you can reference that either in Theme.json or in your style.css and then as things evolve rather than having to rewrite things everywhere you can just like you know move stuff out of CSS into JSON or maybe change the value in one place it'll update a bunch of other places so I'm in favor of doing this as a methodology and as more and more of these are supported as part of the preset styles we can either move them out of our custom styles or just reference our custom style in our preset style either way it makes it a little bit easier to evolve but this is the kind of if you're looking if you're inspecting a theme and you see WP custom and then a bunch of other stuff that means it is a custom variable defined in this custom section of Theme.json Another thing so we're talking about elements remember our atoms our HTML elements stuff like headings and paragraphs and stuff like that there are several kind of block level elements that Theme.json will actually output styles so this isn't outputting a variable this is actually outputting CSS styles so instead of writing the CSS it'll do that I would recommend doing this if you're doing a full set editing theme you can also take care of styling your elements within your CSS if you're doing a hybrid theme but either way you can reference some of these variables that we already created so that is kind of all of our atomic things and I'm showing you just like a bunch of unreadable JSON which is totally fine you don't actually have to be able to read this right now but just kind of showing you as an example of like what does this look like and where you're going to be looking where you're going to be looking for it in your theme then we get into molecules so molecules again if you remember they are combinations of atoms many of the simple blocks that you're going to encounter in both the content editor and full set editing would be considered molecules where we've combined a few html elements into a more complex component so you might recognize quotes, lists, buttons, forms, images, audio post elements like the author post meta, post summaries, different navigation elements like the site logo taglines, menus, etc I've included and again I'll have a link to all the slides afterwards you don't feel like you have to panic and try to read all this stuff there's a link to kind of all the core blocks and many of these would be considered molecules now within theme.json if you are doing full set editing there is actually a styles section where instead of writing CSS to style these blocks you can write JSON to style these blocks and it will target a specific blocks if you know the blocks like the button one I think that's the one I have as an example here you can give it certain parameters so you can style the border radius right from here by referencing another thing you can style the typography the font family all this different stuff right from theme.json it's kind of fun or you can do it in CSS if you're doing a hybrid theme but the point is that there are a lot of support for atoms and molecules right in the JSON file so that's pretty neat speaking of organisms now we get into several different things one being more complex blocks some blocks I would consider organisms that you know these are things that contain several other blocks they're introducing complex functionality and other settings stuff like the layout blocks like the cover block the column block the group blocks mixed media blocks stuff like galleries the widget blocks also query blocks which are pretty powerful those are the ones where you're pulling in a whole bunch of posts into one block to consider an organism and a lot of other custom blocks these things that are testimonials or like a slider something like that these are generally considered organisms and these are more complex these don't necessarily have the core blocks you can style via theme.json most of these you're probably going to be writing styles for traditionally in style.css but again thinking of it atomically these are our complex blocks they're inheriting our styles from the atoms and molecules and then they're just getting more complex PHP template parts would also be considered an organism so if you've been writing traditional themes you know these are just headers, footers, sidebars, different repeatable bits of content that are included in our broader site kind of just an example of like you know here's where you'd see them in the theme structure also full site editing template parts would be considered organisms again headers, footers and other reusable content the difference being instead of just being included as a PHP file here they are and they are selectable in the site editor and you can see them there's a whole template parts section so that language is actually getting exposed to our end user profile which is interesting block patterns I would consider an organism and these are fun so commonly used groups of core or custom blocks that can be configured and inserted all at once I find them very useful they can be defined either using register block pattern in PHP or you include them in the patterns folder and then list them in your theme.json file for full site editing what about patterns they show up in the same place that you search for blocks they are tagged they're sortable they're searchable kind of an example here some patterns that I built into my personal theme you know you can sort them by type and then you it's just like you know basically a combination of stuff that makes it really easy to build stuff again those three columns with images text and buttons you can just build a pattern for that instead of expecting your end user to try to assemble that out of blocks reusable blocks these are interesting I'm not really sure they had a really good use case I'm not really sure where that use case is going as we move into full site editing but basically what reusable blocks are is you can actually create a block in the editor and then save it as a reusable block and then if you place it in any other spot when you update the content in that block it updates everywhere it's kind of nice if you're building like a call to action or something not necessarily sure where this is going to go once we have now you know let people build template parts and other things in the site editor it may become obsolete it might still be useful but it's still a thing that exists and it's something you should be aware of and that also if you have any will show up in the same block editor so here's my really great call to action as an example and this is just every if I change the text anywhere it'll change everywhere and that's fun and then we get into templates right so now we're combining all these blocks into bigger things both full set editing and traditional themes template hierarchy so you'll recognize that if you're familiar with it some of the PHP templates that you might be familiar with are standard you know standard page templates whether those are template hierarchy or custom page templates you can select in the template editor also post type block templates what I mean by that if you've ever used a plugin like the events calendar is a good example and you open up they use the block editor and you open up a blank event and there's already a bunch of blocks on the page for you that's a post type block template those are really useful as a theme design example of PHP templates there they are and then also full set editing templates so these are you know the core templates you would expect they can be created custom or they can be assembled out of the full set editing template parts so again we're building it kind of in a similar way to PHP but these show up in the editor in the template section where you can see they have template hierarchy names so you're single you're in your search etc and then we have the concept of pages in atomic design now obviously we think of pages as a single page of content but I would also argue that different views that are created by full set editing so maybe like a this specific page maybe has this content but it also has this header and footer and sidebar configuration that would be considered a page stuff to think about when you're starting to think about atomic design I also wanted to mention one of the cool things that they started doing and this is especially if you're doing I think like commercial themes or variable themes more so than bespoke client themes is being able to include multiple variations of JSON styles within your theme so your end user would be able to switch between different styles without switching themes that looks kind of like this so in your site editor looks like this right now there's some discussion on making this user interface a little bit more usable but your end user would be able to go into the stock section and be able to completely change what their theme looks like and that's something that you as a theme person could include I wanted to kind of close this by talking a little bit about I mean I said a lot of good stuff and how it works but I did want to also address that there are kind of a lot of concerns and considerations when you're working with this right now this is I mean it's not bleeding edge technology from a from like a technical standpoint like this is the technology powering this is pretty tried and true but it is still not even close to the most widely adopted form of WordPress interface and a lot of it is still either officially in beta or basically still in beta even if it's not so there's a lot of things to be thinking about and I wanted to kind of acknowledge that while I'm standing up here many elements of the block editor in full set editing are still in flux CSS class names might change how core blocks are styled might change different experimental APIs might change so I just wanted to present a series of questions that don't really have answers yet but I do believe that these are questions theme authors are going to be thinking about in the near future so one is like how do we address fricking changes right because you know I don't want to be you know it's hard to be shipping software that might break so things we're going to be thinking about you know how how do we know when we should be using this how do we monitor these updates you know how do we provide supporter updates if we choose to use new features right this is stuff we have to be thinking about where and how should we be defining our styles I just gave you I you know every other sentence was like oh you could put it in theme.json or you could put it in style.css right and instead of giving you an answer to that I'm like great question but we you know besides just deciding where we're going to style something we have to think about you know how much are we going to be accounting for WordPress's core styles do we want to include them do we want to overwrite them how do we deal if we want to include them we're battling against their specificity in CSS right also the question you know are themes supposed to be unique or are they supposed to be standardized you know if content and design are mixed which they are you know what happens when themes change like does that break something in your content how do we address these incompatible style issues between themes how do we address the assumptions that maybe third party blocks or plugins are making about what should be included in our theme how long how long is a theme supposed to last now right I mean now that it's becoming more ambiguous now that it can evolve along with their content are we even going to be changing themes or are we just going to change all of our options within the theme and just keep the same theme are we going to be just like loading some new like JSON files and some new patterns in there and just like keeping our theme forever like how long are we supposed to be supporting this and also and this is you know the fun one how are we supposed to learn all this new technology right like oh man like I just I just learned WordPress and I have to like learn new WordPress dang I mean there are there is a lot of new tooling involved there's a new markup language you know you have to get familiar with JSON if you want to write blocks you have to learn react you know modifying anything with JavaScript you're going to have to learn a whole bunch of build tools or at least find a good framework that does a lot of it for you and working with this stuff is a little bit harder to learn by reading because a lot of the stuff is a little bit obfuscated you know you used to be able to just like open up WordPress core and just like read the PHP file and be like I see but now it's a little bit harder to kind of figure out where everything is and how it all works you have to kind of work a bit harder to do it that's a little unfortunate but despite all of these things you know my key takeaway here is that theme design might be evolving but it is still a crucial part of the WordPress ecosystem so I say let's help people build creative content I have a list of resources so these will be included in the slides but different things if you want more about design systems if you want to learn more about the block editor and full-site editing in general but this is a slide to take a picture of here's me this is how you get a hold of me this this link right there is where these slides are located so it's the bit.ly link future of themes 2022 if you want to find me next I'll be at the social I'm online on WordPress Slack and Twitter in person I don't know what ever is next but I hope to see all of you again thank you thank you so much Michelle we have about seven minutes for questions if anyone has a question in the audience raise your hand and I'll come over to you it was such an incredible presentation very thorough not quite as thorough here they come thank you honestly it's kind of a similar question that I asked Rich in the previous talk I think that WordPress themes these days still have room to innovate in terms of the designs with kind of the constraints that full-site editing provides you of like these are the options that core can let you change can you still create an innovative WordPress theme do you think so can you create an innovative WordPress with all these constraints I mean I think that's been the question the entire time that theming has existed like as things are standardized can we be unique I would say yes and no it depends on what you need I think that there are certainly cases where you can create pretty interesting and revolutionary ways like what if you created styles that only happened when like two blocks were up against each other in a certain way and if they were in a different way they did something totally different right what if we did things where we weren't just thinking about squares and we were making things more organic we were giving things different containers there's lots of ways to still be able to push things and be creative just because we're working with a standard set of blocks and I know that there are ideas in the future especially now that like CSS is going to be supporting container queries which is very exciting you know that means that you can style something based on what it's inside rather than just based on the window that's very exciting I think there's going to be a lot of potential for that there's going to be a lot of potential for understanding you know the context of what block is inside or near why another block and being able to style based on that so I think we can do a lot of stuff if we're like forward thinking and thinking about like not just here is this block how do you style it but like what happens if this block is here what happens if this block is here what if it's here I think then we can do some cool stuff awesome thank you and we have an online question oh an online question oh man okay yeah Maestro Stevens is asking if you can touch a little bit more on the difference between using themes versus templates because it sometimes feels like it's used interchangeably and not necessarily right okay so templates live within a theme so the theme is the parent and templates are different things within a theme so a template will probably render a specific page view or a specific type of outline I understand um so yeah think of the theme as the parent it contains not only your templates but also your styles scripts everything else it needs to function and then the template is something that powers some specific layout hope that helps awesome and that was an online question for Maestro I think I know him in northeast Ohio awesome last question oh okay no pressure with full site editing and blocks becoming more and more powerful should we be focusing on building themes or just focus on building plugins that will add the blocks that we need to create the design that we want to create good question okay I think that it makes sense to do both so being able to control the theme means you're kind of controlling the kind of like main stack and then being able to add plugins means that you can make that stack more extensible so I think that most of the content that we want should probably still live in a theme but perhaps that can be like very extensible in a lot of different ways with a lot of different plugins so I imagine I mean this kind of happened before when we were doing page builder based things or custom field based things where we would have our theme but then when we wanted to do all the cool stuff to the theme we would add all this other stuff on top of it I think blocks aren't going to be okay thank you actually I do think we have time for another question alright great I see you there you go thank you thank you for your talk it's really excellent I guess I'm wondering a lot of this is pretty new and where would one go if one wanted to just start playing around with this theme.json you know this whole ecosystem like is there kind of a starter theme that you can just mess around with yeah what are some resources sure I mean I think 2022 is a good one just because that was kind of like the first kind of core theme that came out that supported it in detail I also recommend going to fullsideediting.com that's been one of my favorite resources so far they keep it very much up to date and they go into pretty great detail about like what is it supported right now so I think between those two things you'll get a lot of great examples alright give it up thanks Michelle that was incredible thank you so much