 All right, welcome to Decisions Not Options in the Age of Gutenberg, which is just such a fancy sounding title. The talk has kind of evolved since I originally pitched it, so I hope you still enjoy it. First a little bit about me. That is me. I am at Chris-Man Patten on Twitter. Please follow me there. It both stokes my ego, but also that's where I'm going to be putting the link to the slides shortly after this presentation. So definitely check that out. You'll also get random musings about life in Gutenberg and all kind of stuff. As mentioned, I am the founder and creative director of Tomodama. That is a Japanese word meaning togetherness, or each and every one. And we specifically work with magazine publishers, especially smaller magazine publishers, to help them build out their WordPress presence. And so I'm super happy to be here with other publishers and other companies who work with publishers. I love publishing. I love magazines. Really, I love print, which is kind of funny because this is a WordPress digital conference. A few years ago I went on a trip and was gone for like a month and a half, two months. I came back to this stack of magazines. That's all the stuff I subscribe to, and that's actually pretty indicative of my love of print. But even long before that, I actually studied theater. This is a set and projection design that I did for a show. Moved to New York for a little while and did that before committing full-time to WordPress. Now, the reason I bring that up is because I started doing theater around 10 or 11. And there's only one love of my life that has also existed as long. That is, of course, WordPress. So a little history lesson. In the beginning, this is WordPress. This is the first version of WordPress that I remember using. Gosh, you know, going on 15 years ago. And it's pretty straightforward. This is the editor, obviously. This is creating a new post. This is pre-TinyMCE. This is when we had quick ads, which were basically WordPress's kind of version of like AB code or one of those old forum style syntaxes. Pretty straightforward. Moving up through the years, we come here. And honestly, like this is TinyMCE, but this is kind of what we stuck with for a while. So at this point, we have a visual editor around this time. I think short codes have just come in. Custom fields in the bottom. You're kind of meta boxes in the side there. Of course, here is 3.0. And this was kind of the template for a long time. From 3.0 to now, 497. This is kind of roughly what we still have. And a lot of that code is still very similar. And it was good. It was great. We loved it. We got used to it. We got used to that model of sidebar of links, forms, and TinyMCE in the middle, and then meta boxes on the side and below. Here are familiar integration points. So of course, we all know and love or loathe TinyMCE. Short codes. Everyone loves short codes and meta boxes. We got used to all of this. This is the vernacular of developing WordPress editing interfaces. The tools are familiar to customize that. So of course, Advanced Custom Fields does a lot of work for us. CMD2 did a lot of the work for us. Pods did a lot of the work for us. Of course, WordPress did a lot for us. We're used to it. We got used to it. But the fact of the matter is that change is coming. You can see change is kind of creeping in. So the stuff that used to work will continue to work, but it won't be the best user experience anymore. And that's because there is now the introduction of a whole new vernacular. We've got so much new stuff coming with Gutenberg. Of course, Gutenberg being the new editor interface for WordPress. So we've got blocks. We've got inspectors. We've got toolbars. We've got menus. You ain't used to this. None of us are. It's brand new. It's still being developed. So with all these new integration points, we need to think very carefully. How can we create intuitive, elegant, and easy interfaces that fit in with Gutenberg and also follow and reflect the WordPress philosophy? We'll get to those right now. So philosophy, WordPress has them. And I'm going to kind of run down a couple of them right now. Design for the majority. I love this one. Try to solve the most people's problems when you're designing something. Out of the box, it should just work. It should be intuitive. It shouldn't have to jump through a lot of loops to make something work. Striving for simplicity. I don't really need to elaborate much on this one. Simple is usually better most of the time. And this is one of my favorites too. The vocal minority, which is that sometimes the loudest people on the project aren't necessarily the people whose opinions you need to follow. If you've ever spent time in a comment section or recently the GitHub issues on Gutenberg, there's a lot of jabbering about. And we appreciate that, but we don't necessarily need to listen to all of that. We need to listen to all of that. We don't necessarily need to make changes based on all of that. Again, that goes back to design for the majority, not the vocal minority. And of course, the one that everyone moves to reference, decisions not options. And this is one that has been incredibly controversial since it was added to the WordPress philosophy. And this is the idea that WordPress should, generally speaking, make smart decisions on behalf of its users. And Gutenberg is a really interesting case where all of a sudden you have all kinds of options that you didn't have before or the options you have options because of the user interface. So as we're kind of working on adapting to Gutenberg, this is a really great opportunity to kind of revisit everything that we've been doing and say, okay, what are the options that we actually need to provide? What are the decisions that we can make on behalf of our users? Of course, these are guidelines, not rules. In particular, these guidelines are intended for WordPress core itself. You don't necessarily have to follow them when you're building something yourself for a client or for your employer. But they're useful because the more unified a user experience is, the more consistent a user experience is, the more consistent a UI design is, that sort of begets usability. So predictability begets usability. So the more that we can kind of follow the WordPress way of doing things, the more luck our user is going to have and the more the ease of use is going to be ramped up dramatically there. So as we consider our integration points, which we're going to go over in a second, we need to consider the philosophy. We want to be the philosophy that we want to see in the world. So as you're thinking about stuff, think carefully about where a control belongs, literally where it's placed. Think carefully about whether or not a control should exist in the first place. There are really good reasons why you might want to provide fewer options than more options. Support the most essential options and no more. This is something I believe really strongly about. It kind of goes with the last item, but really think like, what are the actual things that need to be controlled here? What are the options that a client and user needs to have? Because a lot of the time they don't need the options that they think they need. And also we'll get to this later, you might think of options that you think they might need, but they don't actually need. So try to be really careful because the more options that you add, the more points of breaking you've introduced into your code, into your design. Every new item that you add, any checkbox that you add, that's something you need to maintain, that's something that you need to train on. It just adds additional layers of complexity, and those layers of complexity compound over time. And of course make decisions that let your users feel like they have options. This is one of my favorite ones. This is introducing magic into your UI, providing really intuitive presets rather than specific, you know, fine-grained checkboxes. It's trying to infer based on the context. So hey, we see you're adding a particular post into a post type. Maybe we can provide you some options that reflect the needs of that post type or something that's like, here are a million options for all those types. So just trying to be intuitive and trying to be smart about what those options are that you need to provide. All right, so now we're going to go into the fun part, which is we're going to meet the user interface. How many people in the room have played with Gutenberg? Awesome. I gave a similar talk, there was somewhat similar talk in Gutenberg like a month ago, and I asked the same question and no one raised their hands. So this is refreshing to see. But what I'm going to do in the next section here is I'm going to walk you through the different integration points that you have in Gutenberg when you're building a block. Basically, the goal here is that there are all kinds of places where you can put controls and options and things, but not every place is right for every type of control. So we're going to go over what the different types of controls are. So first, and most familiar to everybody, it is the toolbar. This is a toolbar on a paragraph block. It's pretty familiar. It's icons you know, it's icons you love. From TinyMCE, and in fact, TinyMCE is what powers all of the rich text functionality in Gutenberg. So this is actually a little TinyMCE instance that lives inside of the paragraph block, which you probably don't need to worry about, but we're trying to make the transition a little easier by keeping a lot of that stuff around. Toolbar buttons are kind of interesting because in TinyMCE, a toolbar button can do a lot of different things in the classic editor. Most often, most commonly, it's used for formatting. You can see the formatting options up here still exist, but sometimes it can also be used to insert things. Sometimes it can be used to pop up modals and do all kinds of crazy stuff. A lot of that, all of it really, is still technically possible in Gutenberg, but you want to try to avoid that. There are better ways for doing a lot of that stuff. Typically, the way that I describe it is that a toolbar button should have, one, an instant impact, and two, it should probably be changing the visual appearance of the block if not instantly and then like very quickly. For example, bold and italics, those are easy to appreciate. You can understand what those do, but they're an instant change. They reflect on the visual content of the block inside of the block canvas, which we're going to get to in a second. They're kind of instant impact changes, at least most of the time, but in particular, they're changing the actual visual appearance of the block in real time in the interface. Next up is the block action menu or the block side menu now. This is an interesting one because this is the first one that we're coming to that is a whole new paradigm in Gutenberg. There is no analog for this in TinyMCE and the Classic Editor. The block action menu is also a little hard to kind of exactly pin down what it's for. You can see the options in here. These are the defaults on the paragraph block. The blocks can add their own options in here. So we've got show block settings. That pops open the sidebar, which we'll get into in a second. Edit as HTML, which is exactly what it sounds like. It lets you edit the HTML representation of the block. Duplicate. That's exactly what it says on the tin. And convert to shared block. Now, in the latest version of Gutenberg, this is now convert to reusable block. And that basically allows you to take a block and save it into the database and use it in different places on the site. So when you edit it in one place, we're using that functionality for things like calls to action for specific menu, like list of links that get placed in a lot of places on the site, stuff like that. And of course, remove block. Now, what is the common thread through all of this? It's not necessarily easy to tell. The way that I've broken it down and defined it is that the block action menu is for features or functionality that change the block's relation to either the rest of the content. So in this case, edit HTML, sorry, for duplicate, convert to shared block. It's changing its representation with either the document with the site or with the user interface. So edit is HTML and show block settings relate to the user interface. They change the way the block is represented in the user interface. Duplicate obviously changes the block's representation to a page by adding to the page. Convert to shared block does the same thing. It changes the way that block is represented on the page, but also changes user interface. So these are for things that may not necessarily immediately change the content of the block, but change the block's relationship with the rest of the sites, with the rest of the document, and so on and so forth. This one is interesting because if only recently, I think maybe two releases ago, got the ability to add new items. A block can add its own items in here and we haven't seen a ton of use cases for it yet. So that's going to be evolving as well. The other thing here too is that it does change the block's relationship to the document. I also changed the document. Duplicate is a good example where we're creating another block. I think in maybe 3.6 of Gutenberg, they're going to be adding the ability to insert a block above or below from this menu. So there will be an option to insert block above, insert block below. The key word for me is relationship. This is about changing the block's relationship to the rest of the content of the rest of the site. The block canvas. So this is another fun one because for kind of the first time, we can go in here and you can see this gallery block up here. That's a block placeholder. So we can actually have controls inline in the editor that you can interact with. This was kind of possible with TinyMCE views, but if anyone has worked with the TinyMCE views API, you know it's a nightmare. So this is kind of really the first time that we're going to be able to insert kind of arbitrary controls into a user interface. And of course, below we've got a paragraph block canvas and that you can directly interact with. So block canvas is another one that we're still kind of figuring out, but the two primary situations that I've seen are either the rich text editor below. Whether you're making like a cusp of heading block or we recently did a text accordion block where you can actually just put your content inline. But then of course the other use case above here with the gallery is being able to upload directly into a placeholder, being able to pop up to the media library for a lot of the embed blocks. You can paste in a URL to be able to just put your embed right inline there. The block canvas I think is going to be really interesting to see how that evolves over time in Gutenberg Court a lot of the use cases are supporting rich text content or these kind of medium placeholders. And I'm excited to see what plug-in developers do when they get a hold of this to start doing some interesting things in the block canvas. One idea that I had that I hadn't got around to implementing is like you theoretically can put any kind of content in here so I'm thinking of maybe making a solitaire block. It would be a game of solitaire that you could insert as a block and just play it inline in the editor if you really wanted to. That would be possible to do with the canvas. Now we get into the really fun stuff, the block inspector. The block inspector is kind of another one that's like really challenging because this could really easily turn it to just like all of your settings and checkboxes and textboxes and text areas and all kinds of stuff, sliders and toggles and switches and it could get really overwhelming really fast. And that's something that we've seen going in blocks that kind of the instinct is to go in here and just put all your settings in the inspector but you have to be really careful when you do that. The inspector first and foremost you want to make sure that the controls that you put in here have smart defaults. The reason for that is that there's that little X at the top of the inspector. You can hide it. And I think it's going to be likely that especially for non-technical users like the inspector and then like forget that it exists. So when you're inserting a block you want to make sure that whatever controls you have in here kind of have smart defaults. So with the paragraph block the defaults are really simple. It doesn't impose a text size. It's just the default text size. It doesn't turn on draw cap. The color settings are empty so it's just black text way background. As you're building your custom blocks you want to think carefully like which switches in there at all. So think really a lot about that. One thing here as well is that typically you're not going to have these controls typically modify the content of the block. They don't necessarily change the content of the block but they change its appearance. That doesn't always hold true. Especially if you're using server side render blocks. So blocks where the server spits out some HTML at you because you're rendering them with PHP. I won't go too much into the complexities of that but in those cases you really can't have a rich text editor in the editor if you're using server side render which I think for a lot of implementers is going to be a big fall back to kind of quickly convert short codes over. And I can get more into that in the Q&A later. Next up you've got the document inspector. So this is the same thing as before we've just moved over to the document tab. And the document tab is an interesting one because it kind of is stuff that applies to the whole document but also that's not always true because there's stuff that we're bringing over from from legacy WordPress. So these are a lot of the things you can see in your sidebar. There's not a ton to say here. You can extend this, you can add your own panels but of course think really hard whether it's better as a block setting or something better as a document setting. I think more often than not things that you once might have considered document settings are now better as block settings but that can of course change. And we've got another fun one here. This is the plugin sidebar. So this we haven't seen a ton of use cases for in the while but plugins can actually register their own sidebars. They get triggered on the right hand side you can see here the three dot menu and you can top open a plugin and it gets its own sidebar. So this is one that inserts GIFs from Giffy. You could also insert photos from on the splash. We haven't seen a ton of use cases. This was kind of a big one that I could find quickly because I've used it before and what this does is it basically gives you an interface for picking an image from a search and then it inserts that image as an image block. Again we haven't seen a ton of use cases before yet so this is an interesting example of like it's an interface for choosing a thing to insert as a block but there could be other use cases here too. One off the top of my head is that Yoast SEO might use this to display some of their settings. They might have a plugin sidebar that displays Yoast settings versus the alternative which might be to insert that stuff in the document inspector as separate panels. So kind of deciding which way you want to go as a document panel or a plugin there's a bit of leeway there that you have but again it's just kind of what is the most intuitive place for that. And the nice thing too about plugins you can see up at the top on the right there the slashes. Those plugins can also get easy access from the top menu bar. You can see up there that it's got quick access to that plugin. So you can provide your own icon and users can just hit that and pop open your custom sidebar pretty quickly. Alright so now I want to go through some scenarios. So I'm going to show you a couple of blocks that we built and we can kind of explain why we put the controls where we put them. So this is Gutenberg hello where can. So this is a post block that we built and there's a recent post in Gutenberg but this is kind of our own take on that with a little more customization. So over here you can see that we've already broken the rules that I just gave you. So this one actually does control the content in the block. It does modify also the visual display of the block but primarily that interface up top is where you can go in and you can choose category, you can choose posts and that decides what populates here. Now the reason that we did that that you have those controls on the side there instead of over here in the block is one this is a server side rendered block. So this is PHP is spinning all of this out of the rest API call to show here. So there wasn't really a provision for adding that stuff in the block canvas or as toolbar buttons because also it's a little more complicated than a toolbar button. The other thing that I want to point out about this if I can get it to replay is that this is a case where we gave the client more options than we ended up shipping. So I'm going to scroll down here in a second and you're going to see on the sidebar here just a hint of it whereas there's like a toggle that's going to show up any second now should have done this. There we go. So like show post title and show post subhead. The original plan was we would let them decide in these post blocks if we were going to show a title or show subhead or show the byline or show a featured image and ultimately realize they didn't need that level of control and actually if I replay this those kind of presets that we provided in the sidebar where they can see a little screenshot the post block display options we called them we actually just hard coded those checkboxes based on what the display options are. So those little toggles there are no longer even in the interface at all. That was the case where we over delivered we're like oh we've got this inspector we can throw all kinds of options in and then realize oh wait they don't actually need or benefit from those options. So we got rid of those. Here we go. Another one. This is the text accordion. So this is an example of a block that's primarily controlled in the block interface. So you can put your like we're using this for FAQs. You can use this for spoilers or whatever. And this was also open source. You can grab this on our github. You've got the title up there which is just a rich text component inline but then we're using inner blocks down here which is fun because that allows the client to insert any kind of block content that they want inside the text accordion. And really simple examples over there that are optional things so we leave the block closed by default. That doesn't reflect in the editor so you can edit it but that reflects on the front end. And then the anchor attribute which allows them to kind of like have a little hash anchor that they can link directly to the content. So this is an example where it's really a super simple interface but also because we're using inner blocks they can actually insert any content in there and have access to all those formatting controls without us needing to bake that into the block. Another example here and this is the section header. So Gutenberg of course by default has header tags. You can insert your h1, h2, so on and so forth. But our client actually had a couple different styles of these that we needed and also needed text controls or text color controls which the core heading block doesn't provide. And these are for section headers. These are for page titles and things. So this is another example of where the primary editing happens in that in the canvas, you're actually inserting the text in the canvas and we set the default. So we use their default section header which they use most of the time. We set the color to what they need but they can also use the design options we provided them on the sidebar there. In the future we might migrate away from those thumbnails that you can pick there to something where you can actually set it as a toolbar button. For now this is what we went with. And again this kind of reflects sort of the fluidity of the interface where you can put controls in a lot of different places and ultimately have the same impact it's just kind of what's more intuitive, what's more usable. So points of confusion. So like I just referenced you can put controls in a lot of places. And as part of the nature of Gutenberg being still really like relatively active development we haven't seen a lot of use cases come out. So these are some of my points of confusion and I'm going to just share my thoughts on them. So first is the plug-in sidebar versus block inspector versus block canvas. So here we are with those three examples. We have those that GIF inserting thing in the plug-in sidebar. You can also easily imagine that as a GIF block you select from the block canvas. That is sort of a really easy way to preview and have the same functionality. Of course in the middle here with the block inspector as you saw in the post-block example that I showed you, that's a case of where we're using block inspector for managing the actual content. Which again I don't necessarily recommend you do unless you have a valid use case for it. So trying to figure out how content should be inserted, whether it deserves to be a block or whether it's a block, all these different things that can be kind of tricky to decide what the split is there and how we balance those different things. Another one again, the plug-in inspector versus the document inspector which I mentioned before. Yoast being a really good example and these are just kind of standard screen shots because Yoast does not release the full Gutenberg compact yet. You can imagine like an SEO interface either existing as a panel or as a plug-in and there are no really good guidelines on what makes something better in one place versus better in another place. So here are some of my humble recommendations. Use Gutenberg core controls wherever possible first and foremost. How many people have ever wished for a forms API at WordPress? Okay we've got one hand two hands, great. Gutenberg is the forms API that we've always wanted. It just happens to be built in React with React components. So we finally have a way that we can insert WordPress core control style with managing text and labels and all that kind of stuff really easily into Gutenberg. That's what we're getting here with the WordPress components. So use those wherever possible because the more that you can commit to standard WordPress design the better. Of course there are cases like that and I showed you a couple of those with the post selector with our design control on the side both of which are open source by the way but generally speaking we try to stick to the native options that Gutenberg provides. Innovate only when core controls won't work which I just mentioned. There are certain cases where the core controls just don't solve all the use cases yet and that's where you can innovate but even in those cases for us the custom controls that we've built and extend from Gutenberg core control. So we've tried to expand on those rather than reinvent the wheel. Separate blocks for separate markup most of the time. This is another one that's really tricky. When do you have a separate block versus just an option on a block? In my rule of thumb tends to be if the markup changes substantially you probably want another block. That section header block that I show you before both of those section headers have exactly the same markup which is why we implemented them in the way we did. But there's a perfectly valid use case of saying those should actually be separate blocks because over time they need to deviate. That's something you're going to have to figure out for yourself. Again there's no hard and fast rule they're just kind of ambiguous ideas. The post block is a good example where we went against this recommendation. That post block the markup changes dramatically depending on which preset you choose but that was a case where it made sense because ultimately the controls are the same it's just different markup. You kind of have to balance that a little bit as you're designing these interfaces. Don't fall back to meta boxes. Many of you when you install Gutenberg on your client's site or your employer's site you're going to have a bunch of meta boxes that show up. They will work. They will likely continue to work but it's just not a great experience. It can cause some like weird behavior around auto saves and saving. The UI is kind of clunky because you kind of have to like scroll down and they're kind of under there. It's just like not a great user experience. Now I say this we are using some meta boxes for our client. Co-authors plus hasn't been upgraded to support Gutenberg natively so there's a meta box. Yoast has not upgraded yet to support Gutenberg so there's a meta box. It's fine. There's going to be a transition period where it's a little awkward but one thing I would say is that if you're building in Gutenberg and you're building new stuff really try hard to build it the Gutenberg way as opposed to building it with meta boxes and kind of doing new stuff with meta boxes in Gutenberg. Again plug-in sidebars are really great. Document inspector panel is really great. A lot of that stuff can migrate into other places. Something that I didn't articulate or share with you at all is that soon you're going to be able to create modals. I think actually the code has but we haven't seen any really big use cases of modals in Gutenberg block plugins and things like that. Modals could be a really good place to put some stuff. Options in code don't have to be options in UI. This is more of a philosophical point but if you're not sure whether something should be an option or not that you're exposed to your client in the UI maybe just add it as an attribute on your block and then don't expose UI. Just have the default setting and then later on it might make it easier to turn into an option that you provide. But you don't necessarily have to commit to that. It's also possible to have options in code that the client can edit as HTML or you can edit as HTML when you're editing the code representation of the block so it's not in the UI but can still make that change on a case by case basis. Again as you add these options you have to be careful because you are adding points of breakage but this can be a really good way to do that without exposing it to the client and the user interface and just making it a little easier to maintain over the long term. Avoid the block settings menu probably. I have yet to see a use case for customizing and adding items to that block settings menu on a per block basis. I'm sure there's a use case out there which is why I say probably. I haven't seen one yet. Again the block settings menu is where it kind of changes the block's relationship to the document or to the site. Again there may be good use cases there I have yet to see one. Conduct user tests. Gutenberg is new. It's exciting. It's different. It's very, very different. So make sure that as you're doing this stuff as you're designing as you're prototyping get it in front of your clients. One thing I love about Gutenberg is how easy it is to just like mock something up because if you are using core components the core react like inputs and things like that it's super easy to just sketch something out see how it looks. Maybe you don't plug everything in maybe it doesn't all save correctly or serialize correctly. You can really quickly mock up ideas for user interfaces for your clients and see how they feel about them. So best practices and patterns will emerge over time and as Gutenberg gets along their life as it moves its way to core as more companies adopt it that's going to kind of happen sort of organically. We're going to see more plugins. We're going to see more blocks created and we're going to start to get a sense of like where certain controls belong and so some of those confusing points that I mentioned before are going to be smoothed out. But let's speed that up with collaboration. HIG human interface guidelines human interface guidelines are basically a set of documentation that makes it easier to kind of understand how to build an interface for a given platform. Apples are the most famous and I think probably from what I've seen still the best in the world and this is one of the reasons that when you use an Apple product and I'm not going to try to start an Apple iOS or Android or something like that, but Apple is really good most of the time at being consistent in their provided because of these guidelines third party apps are usually really good at being consistent with the platform because of these guidelines and Apple's guidelines are awesome so they can go into super crazy detail breaking down the anatomy of a window anything, dialogues, image views, outlines, panels you can go in here and find their recommendations on what kind of makes the most sense for them. So introducing the Gutenberg human interface guidelines these are a practical resource for Gutenberg UI best practices they are a template for agencies and product teams who want to build with Gutenberg and want to have internal guidelines but maybe don't want to start from scratch they're a guide for designers who are designing interfaces to figure out what is the best way to do some of this stuff because in my opinion and I think a relatively widely shared opinion consistency begets predictability which begets usability and the more usable our interfaces are the better they are for clients and for product teams so they're going to be here this is not open source yet but I'm going to show it to you real quickly so these are the Gutenberg user interface guidelines make these full screen for you and what I've done here this is still a work in progress but you can go in here and find a lot of recommendations for any area of Gutenberg's interface so here we go with the block toolbar I've got some screen shots for you describe them deceptively difficult design element along with some do's and don'ts and we're going to be fleshing these out over time but we wanted to share these and make these public and in fact let's do that right now make public Gutenberg so go start those this documentation kind of exists in Gutenberg already I actually mentioned that here there are some official guidelines but they haven't been updated for a while and one thing I want to point out in particular is that these are very opinionated whereas I think the official design guidelines might be a little more broad and try to reflect more use cases I'm very opinionated about what you should and should not do with these but I hope to incorporate feedback from the community they are strong opinions loosely held and we would love to have your input on those because of course each new integration point again is a potential point of complexity or confusion it's a potential point of maintenance it's a potential point of why isn't this thing working oh it's that option that we forgot to upgrade in our block forever so a careful planning smart guidelines thoughtful implementation you'll be able to create Gutenberg experiences that will delight our users and your users and help them to do powerful things thank you and do we have any questions? yes so I'm wondering what you're really hoping you've had a lot of suggestions but what are you hoping that will come about next once we're launched and we start to get feedback and it's in that everybody's hands what are you really hoping that is the first thing that you start to see? I would like to see more consistency in Gutenberg user interfaces and I say that like even some of our own block interfaces are inconsistent from other block interfaces and as we've introduced Gutenberg to our clients and we're Gutenberg first my agency is now everything we build is now Gutenberg going back and one of the big complaints or suggestions that we've gotten from clients is that why is this thing in this place but this thing is in this place and the lack of consistency is I think a big barrier especially because there are so many different new ways where you can put options in Gutenberg and with my guidelines and with my sharing them is that we can have more consistency across different blocks from different block implementers and just really make the interface more predictable as a result also happen to answer any general questions about Gutenberg as well if anyone has them either now or in the hallway yes yes sure so the question was I mentioned earlier co-authors plus not supporting Gutenberg yet are there plans to do so or alternatives I believe and maybe someone from VIP can speak to this but I believe they are planning to it's just that the interface or the APIs for Gutenberg have changed relatively quickly in a short amount of time I think they're just waiting for things to stabilize so I do expect that will happen and when I say that it's not compatible with Gutenberg I just mean that it doesn't have its own like document settings panel the meta box is still there still visible it still works it's just that they're probably in more Gutenberg way to do it and I do expect that to happen again you had mentioned you had mentioned the service user side render to kind of port over short codes do you plan that yeah so server side render is a capability of the functionality component basically makes it so every block can have a render callback in PHP and it can say when rendering this block on the front end it should render with this PHP you can also do that in Gutenberg with the server side render block that allows you to basically use your PHP render callback in Gutenberg rather than doing your display in react or something this is generally considered a fallback I don't I believe it's safe to say that it's officially like you probably shouldn't be using this but you can use it if you need to so that's just it's really nice because you can have your render callback just be do shortcode use the do shortcode function to return a shortcode so it's a really easy way to port over a block from a shortcode or something like that cool, question do you know if the WordPress component 3 is going to start denoting whether 8.1 is Gutenberg friendly or not it's really good about porting and stuff I would love to see that I don't know of any conversations about that right now you can follow the meta channel in a WordPress Slack I know there are a lot of changes coming to the plugin directory as far as I know that's not one of them but I would love to see that a little checkbox filter option is a Gutenberg compatible or not that would be super cool good suggestion if anyone from the .org team is listening cool any final questions I'll be around all week I'll be here until Saturday so if you don't have a question now that I have one later please feel free to find me, tweet me and there we go thank you Chris VanPetten