 So, I've been involved in WordPress for a few years now and I've been working on the Gutenberg project for the last year or so and more recently I was one of the WordPress 5.0 leads until yesterday. I spend a lot of time just talking to people, hearing what they have to say about where WordPress is headed and what their feelings are about it. There's certainly excitement about where Gutenberg is taking us. Some folks are feeling a bit nervous about it. They're not sure how they can keep up. Some others are skeptical about whether this change is really necessary at all. I'd suggest that this actually isn't as big a change as you might think. Gutenberg is, it's not throwing everything away and starting again. It's simply the, it's building on everything that's coming before it. In my time working on WordPress, one of the few constants I've observed is that no new feature starts from scratch. Everything is an iteration. Whether it be a feature on a dashboard, a new API or even a completely new way of interacting like the customiser was, it's still iterating on what we've learned from previous work. Gutenberg is no different. It's certainly a bigger leap than what you might expect. If you're only considering the classic editor, but WordPress doesn't live in a vacuum. Gutenberg has drawn upon the experience of the entire WordPress ecosystem. WordPress features have often been inspired by what's going on outside of WordPress as well. When we talk about the future of WordPress and how Gutenberg is a part of that, it's important to look at our past and see how that got us to where we are today. So let's take a look at the history of the editor. The idea of content awareness in the post editor isn't new. And one of the earliest steps towards that was post formats. Now, post formats have kind of fallen by the wayside these days, but they're an important milestone in changing how WordPress treats post content. Maybe you consider the post content to be just the words you type in the little editor window, but it's been a lot more than that for a long time. Post formats have really introduced the idea that post content is more than that. The content in the editor window, combined with the metadata about that content, combines to produce the post content that you see on the front end. Tags and categories and the author and the publication date and all sorts of custom metadata come together to produce the content that your visitors read. Post formats were originally introduced in WordPress 3.1 back in 2011. It was refreshed in WordPress 3.6 and this is one of the interfaces that was tried but ultimately never released. I think it's a really clear indication of how WordPress was evolving at the time. Recognizing that information about the content is just as important as the content itself. I don't think any of us could produce the content we do today without embeds. This simple idea of pasting a link to a video and having that video appear in the editor is an integral part of modern editing. This was introduced in WordPress 4.0, but it's actually the coming together of two much older ideas. WordPress 2.9 introduced the original embed support. You'd paste a link to a video in the editor and when you publish the post then you'd see it on the front end. It was simply a way of not needing to deal with pasting messy iframes or a bunch of JavaScript. A few years later in WordPress 3.5, tiny MCE views were added. Views were an API that allowed you to replace some content in the editor with a visual representation of itself. The earliest example is probably the gallery view. You could embed a gallery of images which would be a short code behind the scenes, but when you were writing a post, it would display as the actual gallery. You don't need to preview your post just to see what it would look like. A couple of years later, these two ideas came together to produce visual embeds. Inspiration also doesn't just come from WordPress Core. In 2013, Alavandorp started looking at how to build an entirely front-end editor. This is an extraordinarily complex problem. Most front-end editors that you'll usually encounter work in one of two ways. The first option is to have a highly controlled environment. For example, a hosted service can require themes to all produce HTML in a particular way. They'll all have the same markers to point out where the different parts of the content are, and it's fairly simple from there to insert the editing interface where it's needed. The second option, when you don't have that kind of control, is to create an editor that controls its own HTML. It perhaps will have styling information from the theme, but it generally knows how all of the markup is going to look like. This is how the classic editor worked, and it fairly clearly showed a downside that it's difficult to make the editor look like the front-end. Alavandorp chose a third option to create an editor running on the front-end of the wildly uncontrolled environment of WordPress. There's no guarantee of how any theme is built, how it outputs HTML. Nevertheless, it worked. It's also very clearly showed that the best editing experience comes about when your editing looks as close to the final product as possible. Front-end editing wasn't the only way that folks were thinking about this problem. Shortcake started in 2014. It's a plugin that allows short codes to easily register a view. Based on the same views API that the WordPress core used to show galleries, Shortcake expanded the functionality to allow any short code to present themselves in the editor in the same way. In a lot of ways, Shortcake turned short codes into proto blocks. Treating discrete chunks of content as a block is certainly not a new idea in Gutenberg. A lot of editing software does the same thing. At Automatic, there were experiments to replace the post editor as well. One of those was called ZEditor for my American friends or ZEditor for everyone else. Much like other editor experiments, they didn't make it into WordPress core. This editor is open source, but perhaps you might not have heard of it. It's kind of something that you might have only seen if you follow WordPress really, really closely. ZEditor was an experiment in starting from scratch and making an explicitly block-based content editor. It was quite lightweight, it was fast, and ultimately taught two important lessons. The first is that writing a rich text editor from scratch is really hard. This is why Gutenberg uses TinyMCE for rich text editing, because it's already solved a lot of those problems. Second, backwards compatibility isn't just a nice thing to have. It's critical to maintain as much backwards compatibility as possible. The editor needs to be able to load content, create it in old editors, and old editors need to be able to read the markup that the new editor creates. Calypso is another project from Automatic, which replaces the classic WordPress dashboard with a new modern interface. Calypso's own architecture has gone through multiple iterations as it's matured, and it's that maturity which has helped inform how Gutenberg is architected. The Calypso editor started with the classic editor and it iterated. It started talking over the REST API. It polished the user interface and it removed the cruft that it built up over the years. To avoid the backwards compatibility issues of moving to a block-based editor, it kept the content as a blob of HTML. It was important for the Calypso editor to provide a more polished experience, but it didn't need to take on the challenge of fundamentally reworking how content was stored and managed. All of these changes bring us to today. Gutenberg, the block editor. The interface you see today isn't something that's appeared out of nowhere. It's the result of iterations and experiments over many years. Our past directly influences the future decisions that we make. Gutenberg isn't just the user interface, however. How it interacts with WordPress matters too. Headless WordPress has been a bit of a buzzword for recent years, but it's kind of always been possible. Even before WordPress, since the days of B2, the XMLRPC API has allowed you to remotely manage your site content. The downside of the XMLRPC API is mostly the XML. It's extremely verbose, XML parsers are, were and still are difficult to work with, and it just generally wasn't that much fun. For over 10 years of WordPress' life, however, it was the only way to work remotely with a site. It's changed with the REST API project. What started as a Google Summer of Code project for Ryan McHugh ultimately became the new way to remotely talk to WordPress. One of the most important lessons from the REST API project was that we shouldn't go that long without iterating. Where the user interfaces that have inspired Gutenberg have iterated constantly over WordPress' lifetime, the programming interface it relies on was a complete rewrite, done more than 10 years after the last programming interface was introduced. As Gutenberg has progressed over the last two years, it's inspired the creation of new features in the REST API as well as iteration of existing features. The use of the REST API for a WordPress core feature benefits everyone who already uses it for their own projects, and I think we can look forward to continued iteration in the years to come. Design practices in WordPress have evolved as well. In recent years, these efforts are focused on simplifying and standardising how design is done in WordPress core. In 2016, the Shades of WordPress project countered 174 unique color declarations in the WordPress dashboard. It was an unworkable number of colors, and so there's been a lot of works in stand to reduce those numbers. Much like many other projects in WordPress, this is still a work in progress. It's something that can easily iterate. It can build on past successes to make each of the next steps easier. Similarly, there are a few different pattern libraries for WordPress that were created as references for designers to more easily put together interfaces. Rather than being concerned with how elements need to be aligned or padded or shaped, designers are able to move their focus onto solving more important problems. Pattern libraries are pretty common in the web development world. Most companies will have a pattern library for their products or for their services. They're a valuable resource for creating consistent user interfaces. There's a good reason for that too. The reason is us. Humans are the ultimate pattern recognition machine. We have an inbuilt ability to recognize patterns. That's how we evolved as a species. We recognize the patterns of predators to avoid them or prey to catch them. We recognize the patterns of the moon and the seasons to grow crops. Later, we recognize the patterns in ourselves to which enabled modern society. There are patterns all around us, from the smallest flowers to cities to civilization itself. There are patterns in how I'm talking right now, which give you a sense of rhythm, a way to follow what I'm saying. But if I remove those patterns, it becomes really hard to follow what I'm saying. Patterns are how we interact with the world. Our long-term memory contains descriptions of patterns. When we see or hear something, we compare that to what we remember. Irving Biederman proposed the recognition by components theory. It's a bottom-up process to explain object recognition. We separate objects into 3D shapes called geons in order to recognize them. A mug, for example, is made up of shapes. It's a cylinder and the curved handle. Recognition by components means breaking an object down into the smallest design elements and building it up from there. That's how pattern libraries are created. Perhaps a different analogy would suit our modern WordPress world of blocks. Design patterns are very much like Lego. With Lego, you have the basic bricks and the components are built from bricks. In a pattern library, a basic element might be a link which goes with others to form a navigation block. With Lego, you put together wall components to create a house. Both pattern libraries and Lego allow you to build by combining components. When building a pattern library, it's important to start with well-defined base elements. They fit together well, but they offer no information on how to put them together. A pattern library takes those base elements and builds them up into components. Along the way, it defines how components connect to others. Let's look at some simple Lego models. In particular, I want to draw your attention to the windscreen of each of these vehicles. They're different vehicles, but they all use the same pattern for a windscreen. An angled clear piece represents the window, colored piece on top of the roof, and another colored piece behind it to represent the column or the wall behind the seats. Having this pattern doesn't prevent variations. They use different colors. The back piece is translucent in the taxi, but solid in the pickup and the tractor. The tractor is two studs-wides, while the other two are four studs-wide. This is a repeatable pattern that you could reuse to build an entire fleet of different but recognizable vehicles. You might also notice that I never really identified which vehicle is the taxi, the pickup, and the tractor. Despite them being made of Lego, your brain was able to break them down into their component shapes and match them against the real versions of those vehicles that you've seen before. A cool side effect of that is that you can replace the base components, perhaps refining their appearance, and the pattern remains completely recognizable. Pattern libraries are extraordinarily useful. They give you pre-built components. They describe how those components fit together. More advanced pattern libraries perhaps provide code examples for using those components too. But what they don't do is tell you when or why you should use a particular pattern. The next evolution of a pattern library is called a design system. Before I go into design systems, however, I do want to talk a little bit about design. I think it's important to note what I'm talking about when I say design. Historically, web design has been relegated to a very small part of the process. Web design has been the chrome. It's the eye candy, the paint you slap on at the end of the process. That is not what modern web design looks like. If we look outside of web design, say to industrial design, that's the designer role has never looked like that. Design is a process that needs to be infused at every stage of the product lifecycle from the earliest user research through to concepts, development, launch, and post-launch iteration. Design is focused on how people interact with systems. They can involve what the user interface looks like on different devices. It includes accessibility. Traditional web accessibility is very similar to a pattern library. It provides the base tools that you need to make an application accessible. But it doesn't tell you how or why you should use a particular tool. It doesn't tell you what to do when two tools clash. Modern design includes the user interface. It's not just a list of components that create the interface. It's what happens when you're using that interface. It's looking at what tasks you need to perform and how the interface helps or hinders you. Design systems then are not just style guides or accessibility guidelines or pattern libraries. They're something more valuable than the sum of their parts. They take a holistic view of how everything works together. The Google's material design and Apple's human interface guidelines are great examples of design systems. At the base, they each provide a comprehensive pattern library. They have icons and buttons and lists and layouts and all those sorts of things, but they move well beyond that. They describe when and why you should use a different pattern. They focus on making a consistent user experience throughout their respective ecosystems. In fact, the teams who work on the WordPress mobile apps didn't have a dedicated designer for years. They were able to rely on the Google and Apple design systems to make quite usable experiences. That's not to suggest you magically don't need designers if you have a design system. Rather, your designers are able to focus on bigger issues. Historically, WordPress hasn't had these kind of resources. WordPress Core does things one way. Jetpack does things another. Yoast SEO does things a third way. And Advanced Custom Fields does things a fourth way. This isn't about those plugins doing things differently to Core. The problem is that each of them are complex products. Building sophisticated user experiences and there's no WordPress design for them to use as a reference. Each of these plugins has needed to build up their own design system from the ground up rather than being able to draw on an existing system that every plugin or theme developer should be able to use. And so this brings us to Gutenberg today and the key principle for how we can look to the future of WordPress. Everything is an iteration. Nothing that happens in WordPress is a fundamental rewrite. It's always just the next iteration of what's happened before. It's maybe it's the combination of a few somethings. Sometimes it feels like a smaller step. Sometimes it feels like a bigger step. But it's always just a step forward. To understand how we got to today, we can look at WordPress as past. To understand where we're going next, we look at what's happening today. Let's see how the new Gutenberg APIs might inspire the next iteration. When adding new APIs to WordPress core, the most important thing we've learned is that there needs to be a practical implementation of those APIs added as well. This is where it's important to think of the first phase of the Gutenberg project as actually being two strongly linked parts. Sitting on top, we have the block editor, the new post editor in WordPress 5.0. This is the most visible part of the project, but that doesn't make it more important. The block editor is the first implementation of the APIs running underneath. At the very base, we have the WordPress element. This is the very basic building block, which all other components base themselves upon. The WordPress element itself is an abstraction layer for React. That means we have the breadth and the variety of tools that the React ecosystem makes available to us. But we're also able to maintain the level of backwards compatibility that WordPress has traditionally provided. Components are implementations of the WordPress element, creating the basic UI. These are your buttons, checkboxes, text fields and such. Fairly similar to basic HTML, but with modern capabilities that React provides. Then we have editor components, which are the larger UI elements in the post editor, such as the publish panel. They're constructed out of combinations of base components to create more complex interfaces that may only be used in one or two locations. And on top of all of that sits the post editor. The post editor draws all of the editor components together into the block editor interface that you've become familiar with. What we see here is a few layers of abstraction that between the base element and the user interface that you interact with. This allows for basic components to easily be reused or to create more complex components. That set of APIs describes how the user interface is built, but it doesn't say anything about where the data to populate that UI comes from. To define that data, we have the block. In the block editor, the block is represented as a rectangular area in which you can edit the data associated with that block. Importantly, the block editor has no knowledge or opinion on how that data is stored. The Gutenberg APIs aren't the only path through which we're building a better way of making WordPress. The Gutenberg design process is very much still in the seed stage, but it will eventually provide a WordPress design system. As with the APIs, the focus is on providing a practical implementation. Rather than building a theoretical design system that aims to cover everything at once, this should grow organically and mature as each of the next phases of Gutenberg are worked upon. Should be a living system that can grow and evolve with WordPress. As WordPress' existing design resources iterate into becoming a design system, we can expect more defined, constant interfaces and experiences. Historically, WordPress is aimed to distract away the hard or repetitive parts of creating plugins or themes. The existing WordPress APIs make it easier to build complex products without needing to know how the underside of it all works. You don't need to build your own user management systems or database layers or plugin architecture. The Gutenberg APIs continue and refine that philosophy. Having a few layers of abstraction where necessary, but not putting so many in place that it becomes impossible to understand what's going on. The abstraction layers we do have allow parts to be selectively replaced where necessary. For example, with a few modifications, components can be compiled using React Native to create a native mobile interface. Here's a video that's not playing, but the block editor is able to be compiled into an interface that just works in the mobile apps. It is in the web view. Everything is rendered using an appropriate native component, but it's compiled from the JavaScript that Gutenberg has written in. The alpha version of the block editor will be released in the WordPress mobile apps in about a week, I think, and the beta version is due to be released early next year. After the beta version, things get really interesting. As the next focus, we'll be looking at how to support blocks defined by plugins. Plugins have never been supported in the mobile apps, so this is a pretty huge leap forward. It's also a good indication of what we can expect in the future. Plugins will have the opportunity to work with every interface that WordPress supports, rather than just the traditional web interface. So this is a cool site. It's a Norwegian charity raising funds to fight childhood cancer. It's a pretty good cause. It's the website. You can check it out. But along with being an amazing cause, their website happens to mark a milestone of its own. It's the first Drupal site, launched and powered by Gutenberg. We're looking at a future where Gutenberg isn't just the future of WordPress. It's potentially the future of the open web. Agencies have always pushed how far WordPress can go, exploring what can be done with the tools that WordPress provides. If we want to look at where WordPress might go next, it's a good idea to see what agencies are doing. The agency Bigbyte created a set of custom blocks when they were building a new site for Amnesty International. They've taken a really interesting approach here. Rather than being focused on adding a single piece of content, like an image or a button, they're kind of treating those content pieces as basic components. By putting those components together in useful ways, they've created a set of blocks that can be used to very quickly create detailed pages. Having the ability to do this was an important part of the Gutenberg block API. You should be able to build your own toolkit of blocks that help you build client sites faster and better. Bigbyte have also focused on ensuring that the blocks look quite similar to how they appear on the front end. When the post author is adding these blocks, they're easily able to see what the page will look like without needing to preview it. This is pretty cool stuff. I was seriously impressed when I saw how Bigbyte had embraced the block editor. They're experimenting with how they could use it to move into the realm of page layouts. Pragmatic, a UK-based agency who have taken a fascinating approach to building sites, they have a great term for their approach, which they call the data experience engine. The idea here is that it's the content that drives the experience rather than the design of a particular interface. This mindset allows for new user experiences to be easily created based on existing data. Here they worked with an R&D firm called FX Digital to cook up something pretty cool. Imagine you had a frequently asked questions page, which is really just a list of questions and answers. What if you were able to tell Alexa about this list and people could ask Alexa a question and get the answer from your FAQ? It turns out Alexa has the APIs to do this. By separating content from a particular user interface, Pragmatic and FX Digital were able to easily add an entirely different interface for the same data. When we're looking at the future of WordPress, I think we can pretty clearly see that the next iterations will move us closer to platform agnosticism. The things you build won't just run on a website. They'll run on mobile devices. They'll run on different content management systems. They'll run on voice driven devices. If personal heads up displays ever stop being ugly and catch on, they'll run on those too. The key here is to adopting the mindset of separating content from presentation. The process of building any software is only as simple as the tools we use allow it to be. WordPress is simple because PHP runs everywhere. It requires no command line magic before the code will run. It just works. MySQL is much the same. WordPress installs easily with minimal configuration and your first plugin can be as easy as modifying Hello Dolly. I absolutely agree with the argument that modern JavaScript development is harder than WordPress development. That's not because of some inherent quality of JavaScript, however. It's because the tools are more complex. I remember when web development was easy. I also remember a little further back when the same development with the same tools was hard. The tools we find easy to use today had to evolve to become that. And we had to grow as professionals too. Don't let nostalgia take away the work you did to get to where you are today. Don't let nostalgia convince you that you can't keep up. You've learned new tools in the past. You can learn new tools again. But I'd like to digress for a moment with perhaps a bit of a hot take. The best web development environment ever was ASP.net and Visual Studio. Nothing has surpassed the combination of powerful development environment, simple language, and ability to create a site using well-defined set of components. In my opinion, it had three failings that prevented it from becoming the thing that ran the web. First, it did an excellent job of letting you build consistent user interfaces, but it was terrible for content management. The web was driven by content in a way that desktop applications never really were, and Visual Studio came from a world of desktop development. They hadn't really made that switch yet. Visual Studio was expensive to scouraging hobbyists. You couldn't just pick it up and hack away on a weekend project. 20 years ago, it was easier to download that weird PHP thing and start modifying your favorite blogging tool. And the .NET platform really only ran on Windows. Not a huge problem if you're just messing around on your computer, but every web host used some sort of Linux or Unix. You couldn't launch something written for .NET without having a Windows server. And that's it. Honestly, if Microsoft had made their current pivot to web sooner, we'd probably be attending Windows camp or Edge camp or something. Matt would be screaming developers, developers, developers during state of the word. And that's a mental image that no one can ever take away from you. So perhaps that was a longer digression than was entirely necessary, but it did make my point in a roundabout way. If you want to know where web development tools are going, you can just look at where desktop development tools were in the 90s. IDEs were all some combination of slow, clunky, or expensive. Now, Xcode or Android Studio are available for free. There's even a free version of Visual Studio available. Hobbyists really only had command line tools available to them, much like we do now with NPM. Component libraries were small and incomplete. Now, look at the game development world where the Unreal Engine marketplace has a never-ending supply of whatever component you need. Development tools need to be simple. They need to work everywhere, and they need to be available to anyone. TestPress is a tool I've been experimenting with building over the last six months or so. Aiming to address this problem. Building things for WordPress or even building WordPress itself should be as simple as downloading the tool to do it and pressing start. Now, TestPress is in a very early experimental stage. I wouldn't encourage you to switch over to that being your main environment, but it's showing promise. It's something to build upon. It's not just WordPress's past that we can look to for inspiration. So much of what's happening here and in the wider web is analogous to where desktop or mobile development has already been. We can skip 20 years of their evolution and use the best bits of how they work today. We can take any inspiration from anywhere, not just from the things that have come before us. We can integrate with modern web design practices, which let us build better applications faster. Can you imagine a marketplace for components where it's as simple as dragging and dropping new functionality into your project? Can you imagine adding entirely new interfaces such as voice or augmented reality by simply defining what content you want to use for them? Can you imagine an open web that has the features and the tools that people want, allowing them to choose to use it over closed platforms? I can imagine all of this and I don't think it's that far away. Everything is an iteration. As Isaac Newton wrote, if I've seen further, it is by standing on the shoulders of giants. It's humbling and it's inspiring to be building upon the work of those that came before us. If I could ask something of all of you, as you experience this work camp, it will be to allow yourself to be inspired. It's easy to get caught up in the hustle or the drama or the politics of the day. Take a moment to step back and absorb the passion and the creativity of the people around you. Think about the kind of web that you want us all to create and how you can help bring it to life. If you're a developer who's discovered an interesting new API, reach out to a designer and see what you can come up together to use it. If you're a designer who's created a fun new design, reach out to a developer and work together to implement it. These don't have to have a practical purpose. You can take the time to create simply for the joy of creation. Think about how you can explore and experiment and have fun with new technology. Iteration is an opportunity to create something exciting. Allow yourself to be open to that excitement and you might be surprised about where the opportunities take you. Thank you.