Welcome to the third edition of the Jukebox podcast from WP Tavern. My name is Nathan Wrigley. Jukebox is a podcast and transcript for people who are interested in WordPress and the WordPress community. It’s happening once per month for now, and if you wanted to be updated when new episodes are published, you can sign up at wptavern.com forward slash feed forward slash podcast. If you have any feedback about the podcast, then please head over to wptavern.com forward slash contact forward slash jukebox and there you’ll find a contact form for you to complete and thanks in advance if you do. Okay, so the podcast today features Benjamin Intal. He’s the founder of Stackable, which is a suite of custom blocks. Benjamin decided early on that his company, we’re going to take the possibilities that Gutenberg offered very seriously. They had previously developed a page builder plugin, but felt that the opportunities presented by blocks was something that they could not overlook. During the conversation we talk about why Benjamin decided to devote so much time and energy towards creating blocks at a time when there was almost no certainty about the status of blocks and the block editor. Indeed, there was no clarity on whether or not blocks would become a core feature in WordPress. As we now know, blocks are an increasingly important topic in WordPress, and so Benjamin’s decision, with a little hindsight, appears to have been a wise one. We talk about some of the difficulties that have presented themselves over the last three years and how they overcame them. They ranged from having to develop in the absence of documentation to creating bespoke solutions to problems which were later handled by WordPress Core. We also discuss how they went about iterating their product in a technology space which was new. What methods the team used to ensure that they were building features, which their users really needed. We also get into the topic of whether or not the block system is now fully mature and ready to support a growing ecosystem of developers. Is it a good idea to create smaller blocks with a limited use case, or a large suite of blocks, which work in harmony with one another? Are we entering a future in which the ‘there’s a block for that’ mentality might lead to sites with block bloat. Sites with multiple blocks, with overlapping features. It’s an interesting chat and gives an insight into a transitional moment in the history of WordPress. A moment in which blocks are taking on much of the heavy lifting in a WordPress website. A moment in which reputations are made. If any of the points raised here resonate with you, be sure to head over to the post at wptavern.com forward slash podcast and leave us a comment there. And so without further delay, I bring you Benjamin Intal. I am joined by Benjamin Intal. Hi, Benjamin. How are you doing?

Hey, Nathan. Thanks for having me here.

You’re very welcome. I think as with all podcasts like this, it’s a really good idea to get some perspective on who you are and where you have been in the WordPress space. Although it’s a bit of a generic question, I am going to ask it regardless. Would you just tell us what your relationship is with WordPress? How many years you’ve been using WordPress, how you got involved and so on and so forth.

Yeah. So I started with WordPress development in 2010, and I stumbled into WordPress at first to create freelance websites. And I became a fan of WordPress. So I was surprised that you can extend it so much to create themes and plugins that did all manner of things. So I created my first theme, set it for sale. And then I moved into plugins, created actually a bunch of them. And now I had a development team here in the Philippines and our main focus is on building Stackable page builder Gutenberg blocks.

Thank you very much indeed. Now, as the title of this podcast will no doubt reflect. You’ve really thrown all of your weight behind the whole Gutenberg block system. I’m just curious about why it is that you’ve done that as we speak, there are a few packs of blocks, which are similar to what you offer. You jumped on board very early and therefore you must have been fairly confident in Gutenberg and what was going to be offered. So I’m just interested in that really? Why is it that you decided that blocks were going to be the future for you, your business, your company, and all of that?

Actually, when we started building Stackable, I think we released it early February, 2018, and Gutenberg was still in very early beta back then. And back then it wasn’t yet certain if it would get included into WordPress core, but we were doing other things related to page builders during that time as well. And we thought that it wouldn’t hurt to try building blocks for a Gutenberg. So it was something very innovative and new. So previously WordPress was all about PHP and this one, it was more about JavaScript and more about React. So it was a chance to learn new technologies. So we built actually just an MVP, minimum viable product. So we turned that into a free plugin that added blocks, uploaded it to the plugin directory, and then see what would happen. So if it works then great. If it didn’t, then at least we still had fun and got the good learning experience from it. So that’s how we got started.

Yeah. I am curious about that. That’s quite a big commitment in terms of time and energy, and moving the assets around in your company in order to make that all happen. And I guess at that time it was a bit of a gamble. Were you prepared at that time to accept that perhaps Gutenberg wouldn’t be making it into core and that your endeavors might end up just as time spent in development, but nothing would actually come out of it. Were you in some way hopeful that it would come into Core and we’re banking on that happening?

It had something to do with timing actually, before diving into Gutenberg, we actually attempted to make our own page builder before using our own resources. In the middle of it Gutenberg suddenly popped out of nowhere. And then people were talking about that it would be a page builder killer in the future. So you had kind of a crossroads. So do we continued trying to build our page builder, or should we jump into the Gutenberg bandwagon if you say, if you can say that. So what we decided was, what if we just come out with something, and then while Gutenberg is still brewing, let’s just continue what we’re doing, the page builder. And then if Gutenberg gets merged into Core, then we can maybe focus our efforts more on that. But if not, then we can continue doing what we were originally doing.

Probably at various points dip into the suite of blocks that you have, which is called Stackable. I’m just curious as to what the difficulties have been over the last, roughly three years or so building this, because if you’re building something into a fully mature platform where the documentation is excellent and the roadmap is clear and everybody knows how to build things. That’s one thing, but you were building into the dark really into an area of it almost like shifting sand, something that was certain today could be removed tomorrow. It was complete state of flux. The documentation probably wasn’t as fleshed out as it could be. And the roadmap wasn’t necessarily clear. So I’m just wondering if there were any difficulties which you’ve encountered over the last three years, which meant that you had to perhaps rewrite things undo things that you’d already done or indeed find new opportunities in innovations that you didn’t expect to come, which did come.

Yeah, I guess to start off, I didn’t realize it’s been three years already. Oh my gosh. So some of the components that we can use, especially at the start, we’re a bit barebones. So we had to invent a lot of our own. So that’s fun actually. Some parts now are getting better. So like now Gutenberg has the focal point picker and the gradient color picker. So before there weren’t any of those controls, and I’m actually excited to use these new things and Stackable as well. So that’s one difficulty. About the documentation, I think it’s okay, especially if you’re just starting out, there are a lot of examples to get you started now. But a lot of the time we had to explore the code and go inside GitHub to study how things are done and how the components are used. Although even if we did that, it was still really helpful checking the code base. Since I think it’s very well written. It’s well segregated and well-maintained, there are hundreds of people who have contributed to the code. Most of whom are more knowledgeable in Gutenberg and React than me. So I also get to learn a lot of things from it. As for the roadmap, there’s a higher overview roadmap that Matt Mullenweg brought up before, the four phases. Phase one replace the classic editor and then phase two is full site editing, phase three and four are collaboration and multi-lingual. So we go around that. But what we do is we have some big assumptions, that we mainly use as our guide on the direction on what we do. So in our minds, one of the main goals of Gutenberg is to have it replace the classic editor. So it’s not meant to be a replacement for page builders per se. So if there’s no more classic editor, Gutenberg would be the best experience for writing content in WordPress. So we work around that assumption. And also, we always anticipate whatever new feature is coming. So for example, full site editing is coming in the future. So instead of creating our own solutions like that, instead of providing the ability to edit templates and headers ourselves, we just wait for the future improvements so that we can build on top of it instead of reinventing on our own.

During the last three years, have there been blind alleys where you’ve begun doing something only to figure out a) it couldn’t be done possibly or b) it was going to become a part of Core? You mentioned something just there, but I’m just wonderingh how the communication from the team that are building it has impacted what you’ve been able to do. In other words, have you always felt that there’s enough information coming downstream toward you, that you could confidently put your team to work building certain things or has the last three years been a bit of a stop-start… well we didn’t know that was going to happen? I realize that we’re at a point now where things are certainly better than they were, but just because of the fact that you are one of the few people who’s done this right from the start, I’m just wondering how that process has been over the last three years.

I’m not sure whether the communication has changed and I don’t think there’s something necessarily wrong with it. I treat the Gutenberg updates like normal WordPress updates. So what I mostly do is just good old fashioned research. So to be honest, I check WP Tavern on what’s new every now and then. And read the articles in there, although I’m more of a lurker in the comments than a commenter. What I also do is I used to check managewp.org before they shut down, actually. I occasionally also try out the Gutenberg plugin to see what’s new. So that’s, I think one of the main sources of my information on what’s coming, I read the change log rather actually try and read it since sometimes it can be quite technical. Make WordPress is also a very good resource for me on what’s coming. So some of the entries in there go into great detail on what’s new. Maybe there’s an API or a large change, and they sometimes have links to videos and show what’s actually new. And then actually there’s this video and Gutenberg times. So it’s like a news site, all about Gutenberg, by Birgit Pauli-Haack, where they demo the status of Full SIte editing before. So that was really helpful as well.

I know that the team themselves are very conscious that when Gutenberg was announced that there was real division in the WordPress community. There were many people who didn’t want to have anything to do with it and felt that it had been more or less forced upon them, shall we say? And there were many people who embraced it. It did bifurcate the community a bit, split it in two. And there was also the concern that, because it was a new project and there weren’t as many eyeballs and it hadn’t reached maturity that it was difficult to get involved. Like you said earlier, you’ve got to learn a whole bunch of new skills and many people who are quite happy using PHP, and that was as far as they wish to go, and all of a sudden there’s new requirements to learn new programming techniques and so on and so forth. But you obviously decided it was worth the investment. So that’s great. Well done to you. I’m just curious as to, because you’re shooting in the dark and inventing something new, I’m interested to know how it is that you discover from your growing audience, what it is that they would wish you to iterate on in Stackable. So obviously if we go back three years ago, there was very little that you had to show. If we go now and look at what it is that you’re offering, you’ve got a whole suite of different things with multiple complicated options. And I’m very curious to know if a plugin developer was keen to build their own block, what have you found to be a good way to discover from your audience, your memberships, your community, what it is that they wish you to build?

Communication is something that we feel that is very important because while we use Stackable ourselves for some of our own projects, I feel that there are a lot of scenarios and use cases that we haven’t taken into consideration yet, and that our users would know more about. So first in communication, there’s our support. Some customers email in just to request some feature that they really need. Then there’s our Facebook community. So this is something that we started early on. So we try and foster sharing in the community. We try to be as transparent as we can. We try and share what we’re currently doing. We share GIFs and screenshots and we get feedback on those. So whether it’s a good idea or whether to continue or whether it lacks something more. And actually now it’s a bit difficult catching up with the number of requests. And we’ve discovered that what we wanted to build and what our users want, can sometimes be a bit different from each other. What’s important is to remember who you’re building for. They are the ones who tell us, what’s a good idea. So for example, we have this role manager feature where you can lock up the inspector, and it would only allow you to edit the block text, which was actually suggested by a few of our users who had clients and those clients wanted to perform edits on their site themselves, but they didn’t want them to accidentally change the design. So we wanted to add features geared towards agencies, but this was something that we didn’t even think about. So it was a good match. So that’s why we added that in.

I wondered if there were any things that you wish you were able to build, but you are constrained by the Gutenberg project thus far, are there any limitations that you’ve run up against? What I’m imagining here is there’s a whole bunch of people out there in the community who never use page builders, and there’s a whole bunch of people who write template files, and there’s a whole bunch of people who really embrace page builders and it’s become their modus operandi, that’s how they interact with WordPress these days. And the level of sophistication that has been built into some of these tools is pretty incredible. They can do some fairly amazing things and their team have worked very hard. But they’re in their own little silo. So as an example, page builder A over here, they’ve got their team and they’ve built all of these fantastic features and page builder B over here, they’ve built there’s and they’re completely separate, and they’re not interoperable, but we’re trying to build it a system here where everybody can bolt on top of it, Gutenberg the block editor. But I’m just wondering at the moment, if there are things which you see in third-party tools that you wish to build, but it’s simply not available to you yet. There are constraints within what’s possible.

I think something that fits that very well, is that the ability to edit page templates. Every now and then we get this request. Would I be able to edit headers? Can I edit my footers in all of my pages? But unfortunately we can’t do something like that in Gutenberg yet. That’s probably one of the main limitations that we have right now. And for that, there’s an answer that Gutenberg has, although it’s still in the pipeline, so we just have to wait for it, and then we can dive in and add features on top of it so that people can start creating their own page templates.

I think people give Guttenberg flack because it’s not entirely clear unless you really go out of your way to discover what’s coming down the pipeline and so on. It can be quite a confusing experience. And the idea that it’s in the future, going to be able to do these things, and these things. It’s a fairly drawn out process and it’s taking a long time and we had Anne McCarthy on the podcast last time talking about why that was and why that’s intentionally a fairly slow rollout because they’ve got 40 plus percent of the web to protect. But I’m just interested in whether any of that. Is a cause of frustration. If you’d have been building this yourself you may be, could have advanced things quicker, but your users are asking for the ability to, like you say, alter page templates and so on, and you can’t provide it for them, but it’s not your fault. And it may be, there’s a bit of you, which is thinking, do you know, I wish they’d hurry up and get this thing finished.

Yeah, I think that’s really something. So it’s not really a frustration, but more of something that we always have to keep in mind is that we are quite dependent on Gutenberg’s progress. So really have to time things right most of the time. So like Full Site Editing, there was a hint that it would maybe come out late last year. And there was another hint again, that it will come out earlier this year. But fortunately that didn’t happen. So we always have to be on the tip of our toes when it comes to what’s going to be released, and what can we do about it? One funny thing, but not really funny, but maybe unfortunate since we’re building something that’s tightly intertwined with Gutenberg is that some people mix up what’s with Stackable and what’s in Gutenberg. So for example, they recently changed how reusable blocks worked. And we got some emails from users asking us why we changed the behavior, a few usable blocks, but actually that wasn’t us. It was part of the WordPress update.

From the outside that would feel like a point of frustration because suddenly something that you have got no control over is causing you to have to spend time answering support tickets and so on. Something that, that you didn’t do is consuming your time. And while it’s not a frustration, I guess that’s just the fallout of jumping in early with this. If you’d have waited to create this for another three or four years, when everything was much more mature than it is now, you would have probably had a great deal of a smoother road, but you would have missed that opportunity to become one of the people that jumped in early and made a name for themselves. So I guess as a company, you’ve just got to accept a bit of that. That goes with the territory. You’ve done this early. There’ll be a benefit to that down the road, but there’s also going to be moments right now where things don’t go as smoothly as you’d wish.

I think you said it quite right. So it’s just part of the territory. We just really have to accept it that way. Since if you really jump in early, there’s going to be a lot of changes, especially in Gutenberg. Where everything isn’t certain yet. So you have to keep on adjusting on what’s out there, what the people want. So I think it’s just really part of the territory. And it’s just something that you have to accept.

Speaking of which let’s gaze into the crystal ball a little bit and think about what it is that you’re planning to build in the near future. Now, obviously, anything that you say now, may have to go under the microscope of what Gutenberg actually allows you to do in the way that we’ve just discussed. I’m just interested to know what it is that you’re hoping to build in the future, given what the project is hoping to provide for you.

So right now we’re busy with the version three of Stackable. So currently we’re at version two, but in the middle of adding new features and listening to feedback from the users, we realized that there were some things that we weren’t able to do with how our blocks work right now. Cause right now what we did was every block, that we have, we try and make it so that you can turn any block into a whole section of your website. So while that’s good. So that also gives us a few limitations on what we can do. So in version three, we want to make things more flexible. So for example, we want to add more dynamic content stuff and also better responsive editing. So things like, adjusting how columns would collapse in tablets and mobile. So for example, if you can specify your four column layout to be a two column layout in tablet, we want people to have that ability as well, so much more advanced editing capabilities, similar to what some page builders already have. Probably down the road, maybe towards the end of the year, we hope to be able to provide starter websites, a fully package website that you can just import and start from there and probably a design system, so you can change what all your Stackable blocks would look like. Something like that. Although that’s just something we’re currently thinking right now.

In terms of what you can do at the moment compared to one of the proprietary page builders that you could go and seek out in the WordPress space. Is there still a big disconnect with what they can do? So for example, you just mentioned a certain feature that page builders can currently do that you’re hoping to bring. How long into the future, and obviously again, we are crystal ball gazing. Do you see that sort of feature parity there being equal amounts of features in page builders, which you can purchase and download from the repo and what Gutenberg will provide? How far in advance do you think it’s going to be before they’re feature equal?

Oh, I think probably around maybe two years or so, because right now, Gutenberg is still quite new. So we’re still in the area where we can just edit the contents of single pages. We’re not yet there in terms of editing the whole website in just Gutenberg and nowhere else. So I think we’re maybe around two years from that

In a couple of years time in two years’ time say when maybe there’ll be many more features that people require to build full sites. Do you think that there’ll ever be a point where the people who build page builders currently need to be concerned about there being a business left for them? In other words, Do you feel that Gutenberg will replace page builders? Or is it more a case of that’ll be one option, but there’ll still be a completely viable business for people who sell their page builder software.

Yeah. So you’re asking if Gutenberg will ever replace themes and page builders? For that, I don’t think so. I think if it replaces anything Gutenberg probably just replaces the classic editor, but with the plugins that extend Gutenberg, it can be a great alternative to page builders. Yeah. But I think in the future you can just get Gutenberg and then with the power of other plugins, it can be a viable page builder. So it can just be an alternative because there’s always going to, it’d be some people that would want an alternative version. Another way of building things.

I also feel it’s a bit of a case of a rising tide carries all boats. What I mean by that is that as WordPress’s market share seems to keep going up, a few years ago, it was in the mid thirties and then it became late thirties. And now we’re into the early forties percent of the top 10 million websites. You feel like the market is just getting bigger. And so even if you were wedded to a particular page builder and you’ve been using it for many years, it feels like the market’s just going to get bigger for them all. So there’s nothing to be particularly concerned about. It’s just going to be one option. You’re going to be able to do all sorts of different things with that option, but you’ll also be quite able to just carry on using the existing stack that you’ve got. If you’re happy with it. Speaking of developments in the future, there are some lovely initiatives in the WordPress space to make the creation of content, much more straightforward. And I know in your case, you can drop pre-configured blocks in and you can style them and make them look however you like. And there’s all sorts of options in there. I just wondered what you thought about some of the new developments, things like block patterns and reusable blocks, which allow us to save time by creating content, squirreling away somewhere, and whether you’re intending to use any of these features in the future within Stackable.

Yeah. So reusable blocks are great for repeated content that you want to be consistent across your entire website. So something like a signup form for your newsletter that you can add in the middle or at the end of your blog posts, those are really helpful. So if you wanted to change something, you won’t have to go through every single blog post to update it. Block patterns on the other hand are great also, but I feel that they’re a bit under utilized. So they’re like reusable blocks, but unlike reusable blocks, if you’re the user, you can’t add block patterns on your own, and it’s up to the theme developer to add them. So I found that a lot of our users use reusable blocks like block patterns. So they add their designs as reasonable blocks, but when they add it into their pages, they just convert it back to regular blocks so that they can use that as a starting point and then customize them. So it’s like an unofficial way to save your own block designs or patterns. So I think that’s a use case that the Gutenberg developers can take into account and maybe add that in as a future update.

There are so many awkward problems with the Gutenberg UI at the moment, in terms of exposing those things to us, I feel that sometimes the proprietary page builders, I feel they do a really good job of showing you what all of that looks like with their overlays and things. I’m not sure yet that, the Gutenberg project has hit upon the perfect UI. We’ve got the bar over to the left, we’ve got the bar over to the right and the fact that they’re fixed in width and you’re not really, you’re not really able to moderate them. It feels like there’s a lot of work to be done there to improve the UI, to discover all these things, and particularly in the case of reusable blocks, and block patterns. Nice ways of seeing, not just as a tiny little thumbnail, but something, large and full screen. So you can get a real idea of what it is you’re about to drop into the page. So really a conversation about, where the UX could be improved if you’ve got any thoughts on that.

Yeah. Yeah. I think there are a lot of things that we can still improve on. Although I think it will only just take time because right now, even if it feels like there are a lot of stuff being added to Gutenberg, and there are also a lot of things that are being studied and adjusted. So I think as an example of something that can be improved, like I mentioned a while ago, I think block patterns, I think a lot of people have, can have a good use by having the ability to add block patterns or their own block patterns. Oh, actually one of the good improvements that we can do in Gutenberg, because one of the hard things to do in Gutenberg is to know where you are, in the current page. Cause it’s if you check out the block editor, if you check out Gutenberg, it’s basically a tree of a lot of blocks and then blocks inside of other blocks. So it can easily be hard to know what you’re editing. Although the, I forgot what it’s called, the navigator button on the top. The one where you, when you click it, it’s going to show you a bullet list of the blocks. So I think that can be improved. I think that can be transformed into something that you can use to actually manipulate the blocks that where you can, for example, if you want this heading to be moved into inside another container, you can just click the navigator, and then you can move it around from there directly. So I think something like that can be a good way or a good alternative for you to be able to move around blocks and figure it out where you are. Cause it’s actually sometimes hard to click on something, especially if you’re inside a columns block because inside a columns block, there’s two column blocks, and inside that you have your other blocks inside. So it’s hard to master or it’s a bit hard to make sure that people can click around and figure out where they actually are. Actually, I think the difficulty here is that there’s a balance between building a what is what you get, editor, and then also making it spacious enough that you can click around and easily figure out where you are, because if you add spaces everywhere and add outlines. So I think that’s a solution. If you add outlines everywhere, that’s going to be easier to know what’s going on in the screen. So for example, if you have the columns block and then maybe an outline block to signify that you’re inside the column. So that’s going to be easier than if you didn’t have any spaces and they don’t have any outlines. That’s going to be way easier than what we have right now. Although it’s a delicate balance because now if you have outlines and lots of spacings, it’s not going to be a, what you see is what to get builder, no matter what you do, it’s going to be, you’re going to have people who don’t want what’s going on right now. You’re going to have people who don’t like this change, or you’re going to have people that would prefer the other way around. It’s just finding the balance on the what works.

One of the most fantastic features that ever I suppose, came to WordPress was the ability to add in plugins to extend what WordPress could do with extra functionality, and in the near future, we’re going to have the block directory will be available to everybody and we’ll be able to search for blocks that we don’t have yet installed and install them on our website. I’m curious about whether you think this is a good development. What I mean by that is I just wonder if there’s a concern that we need to have about people wanting to have a block for every little thing, and then downloading a ridiculous amount of blocks, most of which they don’t need, which will be consuming up resources on their website and so on and so forth. I’m just wondering what your thoughts are on this block directory, whether it’s something that you’re going to be involved in, whether you’re going to do anything like that become involved in installing directly one of your blocks at a time as opposed to selling it as a whole suite.

To be honest, I was initially excited about the block directory. And I think it’s already live right. It’s working right now, except that, although I thought it was going to work more like the plugin and team directory, where there’s an actual directory that you can go to and browse, I think right now the current behavior is that you have to search for a block inside the inserter, the plus sign that you click on to add blocks. And if what you type doesn’t show a result. If you don’t have any block that matches that keyword, then that’s the only time the block directory shows up. So I think that process can be improved. I think it’s a bit off since you can only see the block directory, if you type in a search term that doesn’t match anything. So you’ll have a lot of instances when the block directory won’t show up at all. So for example, it won’t trigger. If you type in text like the t e x t since that’s the keyword of the native paragraph and heading block. So I think that’s something that can be improved on and they hope they’ll improve on. And I think if you have a lot of blocks turned on from the block directory, like a block bloat. So I think it’s just the same as with plugin bloat. So it’s like the notion of having just too many plugins installed. I think it depends on the plugins that you have in your setup. And they think with blocks, it’s going to be the same thing. So it’s quite possible to have this block bloat by installing lots of individual plugins. Especially if you add in lots of blocks that load their own style sheets, their own Javascript files, but they think this depends on how the blocks were made. So like with plugins, it depends on how the plugins were made. If you activate a lot of plugins that just loaded a lot of their stuff, every time. So that’s going to be a bad experience. So I think it’s going to be just the same. It’s going to be up to the block developers. It’s going to be the responsibility of the block authors to make everything optimized so that everything would load up properly.

I can see a future in which individual little blocks become a nice commodity. So at the moment, we’ve obviously got a very full free WordPress repository, and we’ve also got a very healthy paid for plugin and theme marketplace. And I can imagine a future where blocks also in the same way that Stackable is, you pay for the premium version of Stackable and that’s great, but I can see almost like on your Android or iPhone device where you are prepared to pay a smaller amounts of money for a smaller thing. It’s not a windows app or a Mac app, it’s just the Android app, you’re going to pay less for it. Just wonder if there’s a marketplace for. Individual little blocks and, you pay, I don’t know, $2, $3, $5 for a block that does this one thing. And does it well, and whether or not you’re interested in that marketplace, or if you’re going to keep your Stackable suite as one big thing, instead of lots of little things,

I think maybe it might be a good idea for other blocks that provide a very large functionality in just one block. So maybe a store locator block, or maybe a contact form block, but I don’t think that’s an option for us because one benefit though, with doing things as a collection is that you get everything in one go, so you get all the blocks. Maybe you can turn some of them off if you don’t need them. But if there’s an update that adds one more block in the future, then you won’t have to pay extra. So there’s that. And going back to block bloat, I think it depends on how the blocks were made. So for example, in Stackable we have optimizations in place that affect all of our blocks. So if we add another block in their roster, the plugin won’t necessarily feel any bulkier. That’s one of the benefits of a collection. So I don’t think we’re going to offer individual blocks. I don’t know right now we’re thinking maybe not, but we don’t know sometime, maybe in the future. But right now, I don’t think so.

I’m just curious about this sort of slight disconnect in the way that things look in the backend of Gutenberg. So if you’re doing something Gutenberg, you’ve made it and you’ve given it the correct padding and so on, but the UI kind of gets in the way a little bit. And I’m wondering if that’s a problem for you. Do you get feedback from people saying it doesn’t look the same over here as it does when I finally publish my website. Is that a problem that you’ve had to overcome and explain to people, look, it’s just parts of the UI, you’re just going to have to cope with it. How have you overcome all of that?

Surprisingly, we don’t have that much concerns over that. That it’s not a direct, what you see is what you get. I think it’s totally okay. Especially in desktop because technically it’s really hard to make things identical while adding all of the bits and pieces that make the content editable, like the inspector or the toolbar, but it’s easier for people to just accept that they’re not going to be identical. And they’re just going to be close enough. I think people have accepted that already, so it’s okay. And after a few edits, I think it’s easy to get the handle of it, of what your edits would look like in the front end, because basically you just ignore the sides of your website, essentially. Yeah. As I said, this is easier for desktops for mobile and tablet though, this is harder since right now, you can only do previews in Gutenberg. And all the times we see that people want to take control of how things get smooshed and how things collapse as the screen size gets smaller. So if you just keep on doing previews in Gutenberg, it’s going to be harder since, just like before you have to keep on pressing preview to view in the front end and resize your browser. So I think it’s more essential for a tablet and mobile. So first Stackable, we addressed this issue since when you do a previous in tablet or mobile our blocks would also change and you can set how they can look like on that specific screen size. Yeah, but I think it’s up to the block developers one way or they’d handle these cases as well, because Gutenberg already has some things in place. If you want to implement that in your own blocks.

It’s pretty clear that you’re very bullish about where this is going. I’m guessing that you are, you as a company are all in on keeping this going and supporting this and making sure that Stackable is something which is going to be around for the future.

Yeah, definitely, definitely. I think it’s going to be a very good future for Gutenberg.

Ben just before we go, is there anywhere where people could contact you if they wanted to find out a little bit more about what it is that you guys are doing?

Oh yeah. If you want to contact me, I am in Twitter. So that’s at @bfintal and I’m also in Facebook. So just search for me, Benjamin Intal, and I’m usually actually more there in Facebook than Twitter. If they want to check out Stackable, our website is wpstackable.com and we also have a Stackable community and Facebook, so you can join that as well.

Okay, Ben, thank you very much for joining us today.