[00:00:00] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case what the WordPress Playground is, and how it’s transforming the scope of WordPress.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you or your idea featured on the show. Head to wptavern.com/contact/jukebox, and use the form there.

So on the podcast today, we have Birgit Pauli-Haack. Birgit is a longtime WordPress user, an influential voice in the WordPress community. She’s known for her role as the curator at the Gutenberg Times, and host of the Gutenberg Changelog podcast, and she brings her wealth of experience as a Core contributor to WordPress as well.

She joins me today for an in-person conversation recorded at WordCamp Asia in the Philippines, and we are discussing Playground, a remarkable development that’s set to redefine the WordPress development landscape.

Playground allows users to launch a fully functional WordPress instance directly in their browser, without the necessity of a server, database, or PHP, playground breaks down barriers, offering developers, product owners, educators, and everyone in between a new way to interact with WordPress.

We explore how this technology not only simplifies the testing and development process, but also sets the stage for more interactive and immediate web experiences.

We explore the concept of Blueprints within Playground, tailored configurations that enables a bespoke user experience by preloading plugins, themes, and content. This feature helps developers to present their work in a controlled environment, offering users an insightful hands-on approach that can significantly enhance understanding and engagement, and it’s all available with just one click. It really does eliminate the traditional hurdles associated with installing WordPress.

If you’re curious about how the WordPress Playground is set to usher in a new era of friction free web development, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Birgit Pauli-Haack.

I am joined on the podcast by Birgit Pauli-Haack. Hello Birgit.

[00:03:28] Birgit Pauli-Haack: Oh, hey Nathan.

[00:03:29] Nathan Wrigley: We’re actually looking at each other, not through a screen.

[00:03:32] Birgit Pauli-Haack: Yes. It’s a total different feeling.

[00:03:34] Nathan Wrigley: Yeah. Birgit And I chat a lot on various other channels, and it’s a pleasure having you right in front of me. That’s lovely.

[00:03:39] Birgit Pauli-Haack: Yeah, same here. I’m always glad we meet at a WordCamp.

[00:03:42] Nathan Wrigley: Yeah, thank you. So that’s the introduction then because here we are, we’re at WordCamp Asia, in the Philippines. It’s the first day of the conference in general. We had the Contributor Day yesterday, and we’ve got another day tomorrow.

And we’re going to have a chat with Birgit who is going to be talking to us today about Playground, because you’ve got a slot at the event all about creating a demo in Playground. And we’ll get onto that in a minute. But first of all, for those people who don’t know who you are, just a few moments for your potted bio. Tell us about yourself.

[00:04:09] Birgit Pauli-Haack: So I’m the curator at the Gutenberg Times and I’m the host on the Gutenberg Changelog podcast. And I also am a Core contributor to WordPress, and I work for Automattic. I live in Munich and I’m married, 37 years.

[00:04:22] Nathan Wrigley: There we go. That is a very potted bio. Thank you, I appreciate that.

So here we are, we’re going to talk about Playground. And I figured the best place to start is answering the question, what is Playground? And just before we hit record, it was pretty obvious that both you and I are very excited about this. And so I want to encourage people to really pay attention because this genuinely, for me is one of the most exciting developments, not just now, but ever, in WordPress. It truly is a transformational technology. But for those who don’t know what it is, just tell us what Playground is.

[00:04:54] Birgit Pauli-Haack: I’m totally with you there on the magic, yeah. And it’s not just for WordPress, it’s for web development. So WordPress Playground is a WordPress instance in your browser. Yeah, you go there, put in playground.wordpress.net. You get a full WordPress instance in your browser, and you can add plugins, you can themes, you can content. Test it out. Whatever you do with that and want to learn with Playgrounds, you don’t need a server, you don’t need a database, you don’t need PHP installed or something like that. So it’s just there.

And for someone who has been in the web development for many, many years, it’s like magic. Because before you’re always kind of, oh, where do I host things? What’s with the database? What’s with the server? And it’s all gone. Yeah, so it’s really cool.

[00:05:43] Nathan Wrigley: I think probably it’s best on this particular podcast to avoid the technicalities, but I would point the listener to a podcast that I did on the WP Tavern with Adam Zielinski several months ago now, where Adam came on and tried, in an audio form, it’s very hard to do, but explained in an audio form exactly what the underpinnings are.

And the only words I can use to describe it are, it’s voodoo. It is literal magic. Just two or three years ago, if you’d have said that Playground was possible, I honestly would’ve thought that you were talking nonsense. It could not happen. That will never happen.

[00:06:18] Birgit Pauli-Haack: Snake oil.

[00:06:18] Nathan Wrigley: Yeah, exactly. And yet Adam managed to pull it off. And so just to re-explain what Birgit just said, it’s all in the browser. When you go to playground.wordpress.net, there is no server. Just say it again, there’s no server. There’s no PHP that you need to install on your local machine. It all happens inside the browser. Close the browser down, it goes away. We’ll come to that. Maybe that’s changed.

But the idea is it’s happening in the browser, and so you can have any combination of website that you like immediately inside of Playground, and it really is remarkable.

I liken to the moment that the iPhone got the App Store. The iPhone was a very useful thing to have. You know, it did phone calls and it looked beautiful, and you could upload music to the phone with a cable. And then along came the App Store, and suddenly a thousand, a million, different developers could get their hands on it and tell you, here’s a different way you can use the iPhone. And here’s another way, and here’s another thing that you can do. And it feels a bit like Playground is WordPress’ moment like that. You know, it just suddenly prizes the lid open, and makes developers able to show you what they’ve got in a heartbeat.

[00:07:25] Birgit Pauli-Haack: Yeah. And that’s pretty much, that’s a very good analogy because we also have a Blueprints gallery that could be something like an app store where you can learn how you can assemble it. So the core technologies is not not, I don’t know any of the technology that’s underlying. It’s based on Web Assembly. And that has been around for about 10 years, trying to get a lot of different programming languages talk to each other in the browser.

And then it’s based, not on MySQL, but on SQLite database. And then Service Workers and worker Threads API, that are browser APIs. For storage, for instance, yeah, or for sending commands to other different applications. But that’s all I know, yeah. I have never worked with Web Assembly, yeah. And MySQL, I know that, just really amazing.

So you can use that. Many people use it to spin up a fully functional WordPress and demo that. So you can use it in educational settings. You don’t have to download a whole lot of stuff. You don’t have to, as a teacher, you don’t have to set up, talk to your IT department to set up a server for all the students. You can just point them to the Playground and then give them instructions on how to work with that.

It’s a sandbox environment. It could be, yeah, if you want to. You can upload your content and then see what else can you change with it without messing with your live site. You can integrate it with your development. There is a WP now, VS Code extension where you can, so when you’re working on your plugin and you click on the button, it loads up a local Playground for you with the plugin that you’re working on already installed, and that’s really cool.

Same with the theme. The training team has been working on interactive demos in terms of having code examples on one side, and then you make changes to the code and you see it in the right hand side. How it changes the website. So that’s really cool.

[00:09:20] Nathan Wrigley: I think one of the things that you said there, you’ve got an understanding of some of the underlying technologies, but you were stressing that, basically you don’t need to understand them. Having a knowledge of them is fun, you know, it’s interesting. But a bit like I don’t have the faintest idea how to build an iPhone app, but I can still use an iPhone. And I can still benefit from this application, the maps, navigation app. I don’t need to understand how that’s built, but I can use it, it works.

And really that’s, I think the purpose. The developers over there, thank you so much, but most people are never probably going to want to get into the weeds of that. They just want to click the button and see what happens.

And just to be clear on this, if you’ve never done that, I, at my home, have a fairly good internet connection, so I don’t know if I’m in a sort of slightly privileged position, but when I click the button at playground.wordpress.net, I’m imagining it’s somewhere in the order of three to four seconds before that website is ready to go. Basically it’s the length of time it takes me to blink and grab the mouse again. It’s in a heartbeat. So there’s literally no friction.

But if you go to playground.wordpress.net and click the button, what you’re going to get there is a vanilla version of WordPress, which is fine. Then you can do whatever you like with that, put plugins in, what have you. But wouldn’t it be interesting, wouldn’t it be great if somebody came up with, oh, I don’t know, let’s call them Blueprints or something like that, where you could pre-build something that then somebody else could use.

So this is the App Store, isn’t it? You know, somebody’s built the maps navigation app. Somebody’s built the note taking app. Somebody’s built the whatever. This feels like what the Blueprints are. But I want to make sure that you are describing it and not me because I am not sure that I’ve encapsulated it perfectly.

[00:11:00] Birgit Pauli-Haack: No, you did. But in opposite to the App Store, you actually can look at other people’s Blueprints and steal them. Blueprints are written in JSON has nothing to do with Jason. It’s JSON. It’s a data format for JavaScript. And there is a schema for it, so when you put it into your code editor, it gives you signals, yeah, that you formatted right.

And then you have two different ways of configuring your Playground instance. One is to do settings. So you could do which PHP you want to use? Which WordPress version do you want to use? Also, do you want to have network enabled? And most of the time you want it enabled because you want to import and install themes or something like that. Those are the settings.

And then you have steps. And those steps are also just formulated in JSON format. For instance, you can log in. Automatically log in the person in the Playground. Or you can say, I have a landing page that should land, so when somebody uses that blueprint, when Playground is ready to completely load it, you should land in the block editor, for instance. And you should have that particular block plugin already active on that post, so you can really play with blocks. Nick Diego with his plugin Block Visibility has done a great way for a live preview of his block from the repository.

Another way is to, so install a plugin, add content to it. Use WP-CLI to instantly load up new versions, add new pictures, or use an export from another website, an XML file from another website and load it into the Playground instance.

But sometimes you have, you said you get the vanilla if you just do that, if you just do playground.wordpress.net, you get the vanilla WordPress. But it’s one post, Hello World, and it’s one sample page. But you don’t see how content kind of interacts with whatever feature you want to demo. So you need some content there, yeah. And the Blueprints Gallery has actually some nice examples on how to configure that.

[00:13:08] Nathan Wrigley: Let’s come back to the gallery in a minute. Just to recap what you just said. So there’s a bunch of settings, probably more for developers. You know, you might want to test something in a particular PHP environment or what have you, so you can select those. And then you can do these steps where you can essentially design, if somebody was to use that Playground and somebody was to click on your link, they would wait the 2, 3, 4 seconds, whatever, and then, depending on the steps that you’d set up, they would arrive where you chose them to be.

So for example, you might pre-install the latest, greatest plugin that you want to share with the world. And you want people in a post for that. And you want them inside the block editor. And you can make it so that upon clicking the button, the first thing they get is, we’re inside your plugin, we’re about to use it. So the profundity of that is pretty amazing. You can really tailor the experience.

So rather than going from being like Playground, which sounds like children, you’re messing about, larking about a little bit. It also becomes like serious ground a little bit, you know? Serious developers can use this to circumvent, I don’t know, support tickets, the capacity to demonstrate to users who’ve never seen your product before, your plugin, your theme, or whatever it may be.

You can point them to a link. They can click the link. You as the developer configure everything within an inch of its life, so they get exactly where you want them to be. And in that way you can use it as a sales mechanism, as a support mechanism.

[00:14:29] Birgit Pauli-Haack: And sometimes it’s really hard to tell people what your plugin does unless you show it them in the video. But then they still don’t get their hands on it. And with that feature, with the Playground combined with the Blueprints, you can actually make them feel the thing. How it works with them, and what ideas they get when they play around with it, and have better questions, educated questions for you, for the product, yeah.

[00:14:51] Nathan Wrigley: So a Blueprint then is a version of Playground in which somebody has pre-configured things. Is that basically what it is? You know, let’s say that I have got this fabulous new plugin and I want you to experience it. I don’t necessarily want you to land on a particular page, but I just want the plugin to be available to you and you can do things.

If I install my plugin, use Playground to do that, I can then share a link. And because I’ve tinkered with it, it becomes a Blueprint because it’s not the playground.wordpress.net version, it’s my doctored version, adapted version.

[00:15:26] Birgit Pauli-Haack: Well, it also goes to playground.wordpress.net, but it has a query parameter, to be a little technical term, that says, use the blueprint at this URL. So a plugin developer for the repository, at the repository there are live preview buttons now. And the plugin developer can put in a separate directory Blueprints on the WordPress site, put all the assets, all the image that they want to load, and the configuration file, which is written in this JSON file, and put it there, and then make that live. And every time someone clicks on the preview button, they go to playground.wordpress.net with the Blueprint kind of loaded, the configuration files.

[00:16:09] Nathan Wrigley: So it’s all happening through playground.wordpress.net. But then there’s JSON configuration file, which gets sort of sideloaded, if you like, through the URL. That tells it, okay, add this and then end up here and what have you. The important part is that JSON, that’s what makes it the Blueprint. It’s going to playground.wordpress.net, but the JSON file means that it does something else.

And you said the word gallery, which tells me that there’s a whole host of these things. Pre-configured, pre-built, put into a box if you like. And we can go to that gallery and explore. What kind of stuff is in there?

[00:16:38] Birgit Pauli-Haack: So, what kind of stuff is there? So there’s one, how do I put an admin notice on top of the dashboard? How do I add a dashboard widget and load it up with my Playground? So most of the time, when you want to log into a WordPress site, you get the dashboard. And if there’s a widget, you can actually guide people to go some other places. You can say, okay, I have a plugin that needs 50 posts, for whatever reason. So there is a Blueprint there and how to use WP-CLI to create 12 or 50 posts automatically, that are then loaded into the post content.

So there’s also a Blueprint for a specific WooCommerce extension. So it loads WooCommerce, it loads the extension, it loads some products, and then you land for a shipping page where you can say, okay, this shipping plugin, what does it do for me? And you see it working with products on a Playground site. So that is really remarkable. It takes a little longer when you have content to load.

[00:17:38] Nathan Wrigley: Goes up to like 10 seconds.

[00:17:40] Birgit Pauli-Haack: So you go and get your coffee and come back.

[00:17:42] Nathan Wrigley: But it’s still profound.

[00:17:43] Birgit Pauli-Haack: Yeah, remarkable. Yeah, you don’t have to do anything, kind of just wait a bit.

What else is in there? Oh, there is a demo of 2025. So when you load 2025 theme automatically and go to your website and see it, you get the post, the blog site, where all the posts are in one one big site with the full content. And not a whole lot of people have that kind of blog. And in the demo, you actually go to the magazine front page, and then see all the patterns that are in there. You can see all the templates in that Playground demo.

That’s interesting for plugin developers that have experimental themes or experimental settings on the settings page that you can actually preload them as well. There’s an example in there for the Gutenberg experiments. They’re on the check marks on a setting site. And you can take that and replicate that for your own plugins site, how to do that, with the areas.

Because you can do site options. So the site options is not only site title and tag descriptions, also, oh, make my block editor have the top toolbar instead of all the other things or the distraction free model, yeah. So these kind of features, you can also preload there and have examples from the Blueprints Gallery.

[00:18:57] Nathan Wrigley: I think we’re just at the beginning really, aren’t we? Of of this journey. And basically, the underlying technology is now provisioned. It’s there. And we’re at point where, okay, people, developers, explore. And we’re really just at the beginning of that. And the gallery is probably a good place to go.

But if you wanted to put one of these JSON files together, do you know, is there some credible documentation out there that would help people to get started, learn the ropes?

[00:19:25] Birgit Pauli-Haack: Yeah, there’s definitely, there’s documentation of all the steps that are there, yeah, like how to run PHP, how to have additional PHP extensions installed and all that. So when you open the Playground, there are three, and you’re not going to the full page, so you have three panes. On the left hand side you have some menus, and one of them is the documentation link. So that’s good.

And another link is there, it’s the Blueprint Gallery. So in the middle of the section of your Playground, you see all the list of all the gallery content. And then when you click on the preview or the view site, the Playground loads that for you, and then there’s another menu item where is says, view Blueprint. And that gives you a Blueprint editor.

So you see the Blueprint loaded in, but then when you want to edit from the documentation, okay, what happens when I put that in? And you click the run button, and it reloads that Playground with your changes. So it’s really, very hands on, and you still don’t have to create a server or a local environment or something like that.

[00:20:31] Nathan Wrigley: Yeah, there’s this really virtuous cycle of, okay, so you’ve used something from the gallery, but you’re curious about how it works. Look, here’s how it works. Here’s the buttons to click to go and explore. Oh, and whilst you’re at it, if you want to edit anything, here’s the option to edit it. And when you click save, it’ll restart that whole thing and you’ll get the new version.

So all of the sort of helpful tooling is now built into it. Because when I talked to Adam, none of that existed. I mean, the version selection for PHP didn’t exist. The ability to land people on particular destinations when they first load up the playground, none of that existed. It was literally the technology of getting it working.

So now built into it is this knowledge base, if you like. Not really a knowledge base, but more, you want to know how this one works? We’ll show you. And it’s that beautiful, well, the purpose of WordPress, democratising publishing. In this case, it’s democratising the nuts and the bolts, and the bits and pieces of publishing.

Yeah, so that’s really nice. And that’s all built inside. So just follow the prompts in the UI, and you can adapt what you want, and what have you. But also there are some 101 articles out there, perhaps on Learn or something like that where can see in text format how do all.

[00:21:40] Birgit Pauli-Haack: Yeah, the developer blog has, on developer.wordpress.org/news has three articles about Playground. One is about the underlying technology from the Web Assembly people. That was really good for those who want to explore that even further.

And then there is one on what use cases you can do with a little bit of an example. And then also, so we are right now always talking about playground.wordpress.net. But you mentioned something that someone could put this on their website, and you can.

Playground can be self-hosted. It does not have to go through the wordpress.net site. But how to do this is in the documentation. It has a seperate section there. So if you say, okay, I don’t have my plugin in the repo, but I want to use it through my own website, then you can actually put it there, and it’ll have your own branding around it. So it’s even get further than just the WordPress part.

[00:22:35] Nathan Wrigley: So that’s a really important distinction to make. So in the cases that we’ve been talking about so far, if you want to go to playground.wordpress.net and you use your own JSON file, it will be able to suck in anything from the WordPress repo. And that’s the sort of, the WordPress way, if you like. I’m doing air quotes.

[00:22:51] Birgit Pauli-Haack: Also from GitHub.

[00:22:52] Nathan Wrigley: Oh, thank you. Yeah, that’s an important distinction. I’d forgotten that. Also from GitHub, but you know, it’s everything that’s open source out there, free to download already.

But a big part of the WordPress community, one of the things that makes it popular, is the ability to sell commercial plugins. And so that was another question that I had. Is possible to do it?

And so, yes, but you need to take the technology that builds WordPress at playground.wordpress.net, you put that onto your own server, and you can do whatever you like with that. So you can put your premium products in there on a, I don’t know, two day free trial sort of basis, and show people how that all works.

So Playground suddenly becomes more interesting outside of the free to play area as well. And you can imagine that being a really, really useful tool. Because we’ve always been able to play fairly straightforwardly with free things on the repo, but suddenly the moment where you’ve got to pay $100 for a thing, the capacity to see that really is the bit which opens the wallet.

Okay, it’s $100, maybe I’ll buy it, maybe I won’t. It’d be nice to see it. Okay, they’ve got a 14 day trial, but I’ve still got to pay for it. This opens up the capacity to, look, there it really is. Play with it for two days or whatever it may be. That’s fascinating.

[00:24:05] Birgit Pauli-Haack: Absolutely, yeah. And if you want to test that plugin, yeah, you still would need a local server or a hosting server to load it on. And you have that 14 day trial. And now you can really test it right now.

[00:24:16] Nathan Wrigley: Right. And that’s the other big thing. Because if you buy a commercial plugin, you then have to spin up a site somehow. You have to download the plugin, upload the plugin, get the plugin configured. This gets rid of all of that, because you don’t need to download and upload anything, and it can be pre-configured.

So the author of the plugin can say, okay, if you want to use my LMS plugin for this kind of thing, here’s playground version with everything just right. And if you want to do it for this kind of thing, I don’t know, you’re an elementary school teacher who might use my LMS plugin in this way, or you’re a university lecturer, who might use it in this way. Let’s build it a perfect version for you.

And you can imagine that a million times over for all the commercial plugins out there. You know, form plugins. Okay, this is the contact form that we’ve pre-built. This is the, I don’t know, the form which integrates with WooCommerce or whatever. So the developers can do all of this. And that really makes it super useful to them.

[00:25:11] Birgit Pauli-Haack: Yes, absolutely, yeah. What’s coming down the pipeline for Playground. One is that you can also use it with private GitHub repos. Which right now is not possible, but it’s in the works. And there was a problem with the proxy, that you get some cross site downloading errors because some servers are not set up to have images downloaded from a machine. They have created a proxy server now, where that is kind of circumvented that you can also from non WordPress sites download stuff, like images and content, or PHP plugins.

What also comes is, so SQL, MySQL, for some plugins Playground does not work yet, because they use very specific MySQL query, the union query, for instance. Select union and other commands like that. The SQLite doesn’t have those yet. And they are however working on it to replicate these kind of behavior of a database also with Playground. So to make it even more compatible with all the plugins that are out there.

I think they did a test of 10,000 plugins that are in the repo, and test every month kind of how many plugins don’t work with it yet. And they got it down from, I think 7% to 5%. So it’s always kind of progressing very well towards zero.

[00:26:33] Nathan Wrigley: Yeah, there’s a lot of things going on in the background that the likes of you and I probably, you know, because we’re curious about it, we’ll probably know about, but maybe the average listener who’s not wedded to this subject maybe doesn’t. But that’s really interesting.

So the intention is to get it so that more or less anything works in more or less any scenario. And really nicely putting it out there so that you can do things which aren’t bound to GPL, WordPressy kind of things, if you know what I mean. So, you know, you can use your commercial product over here, and you can use your GitHub repo over here. That’s really nice.

My understanding is that when Adam began it, he was immediately repurposed. So Adam Zielinski, he was an, was, still is, I think, an Automattician. And I think that it was immediately understood, this is profound. Let’s get Adam on this full time. You know, it’s no longer a hobby project. But I also think that he’s got other people from Automattic involved. There’s like a little team around it now, pushing the development of that. Is that still the case? Is this a team which is growing, or stagnating at, well not stagnating, maintaining at a certain number?

[00:27:33] Birgit Pauli-Haack: Well, it’s growing in scope. So they’re also working, and that was a focus starting in last fall, that they’re working on using Playground for the Data Liberation Project. And that’s what Adam was doing also full-time now in the last few months. That he looks, okay, what kind of parser do we need to do really good data liberation from other systems, or from WordPress?

Yeah, because the import and export in WordPress only gets you so far, yeah. And there are some quirks in there, and they want to really have a perfect data liberation through Playground. They have a browser extension. It’s all beta right now. It’s not functioning yet. But it’s really coming along quite nicely.

[00:28:20] Nathan Wrigley: So Data Liberation then is this very laudable project of being able to bring into WordPress, I guess data liberation on some levels is the whole point of open source really, isn’t it? Is that you can grab your data and just pick it up and take it somewhere else.

[00:28:34] Birgit Pauli-Haack: Open content.

[00:28:35] Nathan Wrigley: Right, yeah. It’s your content. This platform is no longer being used, or you’ve fallen out with it. You know, you no longer love it in the way that you did. You want to now move it here. And you’ll be able to, let’s say, go Joomla into WordPress, Drupal into WordPress, or as you said, WordPress into WordPress.

Which suddenly kind of opens up the whole idea of migrating websites, which a real mess frankly. It’s a really difficult thing to do. And I often think that people are bound to products and services that they’re purchasing on a monthly basis because the migration process is so difficult. And they don’t want to be caught up in all of that because things can go wrong. You know, it might not work perfectly and there’s all the just carrying it out.

But if you can essentially do migrations, and Playground is the sort of go between. It’s the bit which talks from, I don’t know, one hosting company to another. So it goes from hosting company A to Playground. Playground then serves it up to hosting company B, which is where you want to end up. And all of that happens through Playground. That’s remarkable. And you can do the inspecting in the middle bit, the middleware, Playground if you like. Check it’s all working before you deploy it. That’s amazingly powerful.

[00:29:41] Birgit Pauli-Haack: Yeah. And that’s actually the vision of Playground’s part of Data Liberation. They also have a browser extension to kind of identify a non WordPress site, the various pieces like the pages, the posts, the news, the events, kind of the custom post types. And then kind of teach Playground what it all is. But that’s kind of, it’s very technical on one side, but it’s also, you need to have a total different concept about content management systems to actually make that. So that’s not really for a normal consumer.

[00:30:13] Nathan Wrigley: Yeah, because if you’re coming from Drupal and you’ve got like 1,000 different modules in there, you know, think plugins in the WordPress space. Then it’s going to be difficult to one-to-one map that over to WordPress. But the endeavor is to do a half decent job and in the middle you can step in and say, okay, this might need modifying, that might need modifying. And then you can go back to your Drupal install, change things a little bit, try again because it takes no time to do it. That is really a key, interesting part. You do kind of wonder actually if hosting companies in the future will just offer Playground in as part of their bundle, you know, their onboarding migrating bundle.

[00:30:47] Birgit Pauli-Haack: Yeah. A lot of hosting companies have their own plugins for that. So I know that Pressable and SpinupWP, they all have their, or wordpress.com has their own plugin that they then connect with. I think it’s BlogVault most of the time. Pantheon, same, yeah. Where you can migrate in. But that part in the middle, that kind of always takes a long time.

And you are bound to the hosting company to actually offer that, yeah. And that’s not a cheap plugin. But if you go from one small hosting to one, another small hosting, you don’t have that luxury.

[00:31:20] Nathan Wrigley: Yeah, and if you’re crossing platforms as well, say Joomla into WordPress and what have you. That’s also really different.

[00:31:25] Birgit Pauli-Haack: Yeah. There are a few agencies who have built for their customer things, but it’s not open source and it’s, well, it’s open source, but it’s not meant for a huge amount of public to kind of use it.

[00:31:36] Nathan Wrigley: Yeah, I’d imagine that it’s fairly proprietary technology, isn’t it? It’s probably locked down because it’s the secret source of getting the Drupal installs into WordPress on their platform.

One of the things which Adam spoke about when we talked, I don’t know where we’re at with this, but I raised the question of the destructibility of it. So essentially when I spoke to Adam, when you launched Playground, you fiddle with it, played with it, the moment you click close on the browser tab everything went away. That’s how it was designed. But he said that at some point in the near future, and maybe that moment has already been passed.

[00:32:09] Birgit Pauli-Haack: It’s here.

[00:32:09] Nathan Wrigley: Yeah, so now we’ve got a more permanent version. Tell us about that. Are there any constraints on that? Like, can I close the browser tab? Can I shut my computer down, for example? I mean, will it last forever? Could I even use it as a, I don’t know, as a temporary website in, let’s say I work in a school and I want an intranet for my staff or something, could for those kind of things?

[00:32:29] Birgit Pauli-Haack: Well, it cannot be, it doesn’t have a domain or something like that. So that wouldn’t work. But yes, you can save. You have two options to save the site that you’re working on, so you can come back tomorrow. One is in the browser. So it uses the local storage of the browser and really downloads the whole WordPress stuff there. And then you open up the browser again, you get the site again. You cannot load it from another computer because it’s a different browser.

And the second option is to load it in your local file system. So you can, it downloads the whole thing, gives you a directory and that’s your website, and you can load it then back into Playground a day later, or a week later, or two months later, because it’s still on your computer.

You can also have multiple sites now in one Playground instance. So you can say, okay, save this site, and then now I use another blueprint, load it again and it’s another temporary site. And you load it, you save it again, then you have a second website there.

[00:33:29] Nathan Wrigley: A curious version of version control or something like that. You’ve added this plugin in, I’m going to save a new version marking that this plugin got added. Let’s see how that works. And then if it doesn’t work, we can roll back to the, just delete that one and go back to the previous one. Oh gosh. So essentially permanent. Locally permanent maybe is the better way to describe it.

[00:33:50] Birgit Pauli-Haack: And you need to think about the saving part. If you do a second site and you close it, a browser without the saving part, it’s going to go away. Yeah, it’s still ephemeral there. Which is also a good thing sometimes.

[00:34:02] Nathan Wrigley: But obviously as you said, you know, the point of hosting in the end is that, you know, it connects to a domain name, it goes through the DNS process and you you can see it online. No.

[00:34:10] Birgit Pauli-Haack: No, not yet.

[00:34:11] Nathan Wrigley: This is not. Oh, not yet. I wonder.

[00:34:12] Birgit Pauli-Haack: No, no, I don’t think that’s ever going to be. But what can be, soon hopefully is kind of pushing it to a hosting company. And that, I think it needs to be just finalised which hosting is going to be there. And the Playground team learns a lot from wordpress.com, because the new development, local development system that wordpress.com has, Studio, is based on Playground. They develop some of the features also for, that wordpress.com can use them in their Studio. And what was the bug fixes? Come to Playground.

[00:34:46] Nathan Wrigley: That makes real sense though, for hosting companies to be clamoring all over this, to build a Playground import functionality. Because then developers all over the world, you know, maybe if in teams it might be a little bit more difficult, but you know, a solo developer, certainly at the moment, you’ve been working on something. You’ve got this perfect version of the site, you’ve got all the plugins that you want, you’ve set it up, it’s working on my machine. Now I go over to my hosting company of choice, click the import Playground button and there it is. Why wouldn’t the hosting companies offer that frankly, it just seems too straightforward.

[00:35:17] Birgit Pauli-Haack: Syncing up with the live site or there’s also a GitHub deployment there. It opens so many ideas, yeah. And when you ask Adam, well, if I think about this, and can you do that? He said, sure.

[00:35:28] Nathan Wrigley: Give a few weeks. I’ll add it to list of 1,000 things that people have already suggested.

[00:35:32] Birgit Pauli-Haack: Yeah, we need to develop that. Yeah, the ideas are there, the prototypes are there, the proof of concept is already done. Just a matter of resources now, yeah. I can for instance see one thing is, if you have a documentation and you need people to contribute to documentation, you load the documentation in Playground, you make the changes, and then you push it to GitHub as a pull request. And then somebody can review it, load it in their own Playground and approve it so the documentation could be updated.

Something like that is already in use. That scenario, that’s in prototype. It’s not there yet, but we know that it can work, because some theme developers have that process. They’re not developers per se, that they go into the files. They load the theme into Playground, use the Create Block Theme plugin. Make the changes to the theme. Save it and create the block theme, so it’s in files. Then push it to GitHub as a pull request for this theme, and then have all the changes there. So that’s how a lot of designers work with their developers on the themes. They don’t have to touch any code, but it’s still all saved in code.

[00:36:48] Nathan Wrigley: It’s just such an interesting beginning of everything. It does feel like we are at a moment where there’s just so many different roads that could be taken, and lots of people coming up with lots of different ideas.

Just quickly circling back to the Studio thing that you mentioned. So Studio is a local development environment. You’re going to be downloading this as a software bundle for your Mac or your Windows machine or what have you. You’re saying that’s a wrapper for Playground, is it?

[00:37:13] Birgit Pauli-Haack: Exactly.

[00:37:13] Nathan Wrigley: But that’s immutably stored. That’s not dependent on.

[00:37:17] Birgit Pauli-Haack: No, it’s on your machine, yeah.

[00:37:19] Nathan Wrigley: Right. So it’s going for the files on the machine approach as opposed to being stored in the browser. So if you download and make use of Studio, you can close that machine down, come back to it whenever you like, it’s there until you decide to delete it.

[00:37:32] Birgit Pauli-Haack: Like any other local environment that you can, yeah.

[00:37:35] Nathan Wrigley: Yeah, okay. And that’s available free you to download for anybody.

[00:37:38] Birgit Pauli-Haack: Free, open source.

[00:37:39] Nathan Wrigley: Okay. Is there anything else you wanted to cover off, apart from the fact that we’ve both got ridiculously excited about this. Was there anything curious, interesting, quirky, novel that you’ve seen out there that we haven’t yet touched?

[00:37:50] Birgit Pauli-Haack: No, not yet. But I’m starting now to kind of dream about it. And sooner or later I come up with something, yeah.

What I would want and what I want to pursue is that I can have a Playground instance for writers. And I know writers who are not very keen on using the Block Editor, because it gets in the way. But the Block Editor has these settings where you can do distraction free, where you can do, put the toolbar on top, yeah, and hide it as long as I write, and just let me have when I’m not writing kind of thing, and log in and not have to go to the menu.

Right now, if I’m a blogger, I have to log into WordPress, and then I need to look at post, new post. This would give you, start writing, and don’t have to worry about the rest of it. And then click a button and then your WordPress site is updated with it. That’s kind of what I’m working on. I don’t know if really helpful, but.

[00:38:44] Nathan Wrigley: No, that’s really great. I mean, one of the things that I always thought was curious about it would be the idea in education, for educators literally standing in front of pupils, children who, you know, depending on what the kind of curriculum they’ve got. It might be we’re doing about poetry. We want everybody to upload and modify a poem, or comment on a poem or something like that.

And here’s the link. You know, we’re in an environment where everybody’s, we’re in the computer lab, everybody’s got a computer. Just click on this link, scan the QR code, whatever it may be. Give us your modifications, what have you. And I know that’s a sort strange example, but it’s the fact that instantly, very, very inexperienced users are in the same exact interface as all the other experienced users. And the level of difficulty was clicking a link. You just needed to click a link.

And the educator didn’t need a great deal of technology to set it up. The pupils needed zero technology to access it. And so it’s that one to many thing, where lots and lots of people can access the same thing in a heartbeat. And I’m imagining that the tooling to create the Playground installs, and to create the Blueprints is going to make it more and more easy in the future. So possibly not the perfect example, but I do like the example of one to many.

[00:39:56] Birgit Pauli-Haack: Yeah. What I like about it is that it’s not about WordPress. It’s about poetry. It’s about writing. It’s about, well, even image uploading and editing, yeah. You could certainly do that. Technology gets out of the way. And for the last 25 years, that’s always been in the way, yeah, and now it’s out of the way.

[00:40:14] Nathan Wrigley: Well, because the internet is basically a reading experience. I mean, I know we’ve got forms, but really all you’re doing is submitting a form so that somebody can read that. But you go to any website and largely websites, you know, if you’re going to some sort of SaaS app, that’s a different thing, it’s configured probably to be more interactive. But broadly speaking, you’re going to consume information.

But in this, you click a link and you’re reading information, but then you can do things with it. Oh, I think it would be better if there was an image there in that poem. Or, I don’t know, it’s an explanation of some principle of physics or something, and a diagram would be really useful at this point, and I don’t like the way they describe that, that could go in bold. And you are interacting with the internet. And it’s totally free, and it will be easy to deploy, and it’ll take seconds to load. And all of a sudden the internet became more interactive. And it’s just the beginning. It’s very exciting.

[00:41:05] Birgit Pauli-Haack: Yeah, it is.

[00:41:06] Nathan Wrigley: Birgit Pauli-Haack, thank you very much for talking to me today.

[00:41:09] Birgit Pauli-Haack: Thank you for leading me down the road of all the ideas here.

[00:41:13] Nathan Wrigley: Thank you for explaining it.

[00:00:00] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress, the people, the events, the plugins, the blocks, the themes, and in this case, the efficacy of website usability testing for WordPress projects.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice. Or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox, and use the form there.

Today I bring you the first in a mini series of podcasts I recorded in person at WordCamp Asia in Manila. This flagship WordPress event brought together hundreds of WordPress professionals, enthusiasts, and all manner of interested parties under one roof for a three day event. One contributor day, and two days of presentations.

I tracked down several of the speakers and workshop organizers and recorded them speaking about the subject they were presenting upon. I hope that you enjoy what they had to say.

So on the podcast today, we have the first of those conversations, and it’s with Jo Minney.

Jo based in Perth, Australia, is passionate about user experience, data-driven decision making, cats, pockets, and travel. She’s a small business founder, and works with organizations creating digital platforms with WordPress. She also freelances as a UX consultant. She volunteers with Mission Digital to address social issues using technology, and is an ambassador for She Codes Australia, promoting tech accessibility for women. Recognized as a 2023 Shining Star by Women in Technology, Western Australia, Jo is an international speaker on topics like user experience, accessibility, and gender equality. She’s committed to ensuring a seamless user experience, and today shares her insights from practical, everyday usability testing.

Joe’s presentation entitled, Budget Friendly Usability Testing for WordPress, helped attendees understand what usability testing is, and clarified why it differs from other testing methods. She shares examples from her work showing how small changes can significantly impact user experience, which is better for you, the website builder, and your client, the website owner.

We also discuss how usability testing can transform a website’s effectiveness by improving conversions. Joe explains the importance of recruiting novice users for testing, and highlights how usability testing pushes for real, user-centered, improvements.

Towards the end, Jo share’s practical advice on when and how to integrate usability testing into your process. Advocating for early and iterative testing to preemptively address potential issues.

If you’re looking to gain a deeper understanding of usability testing and its benefits, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast where you’ll find all the other episodes as well.

And so without further delay, I bring you Jo Minney.

I am joined on the podcast by Jo Minney. Hello, Jo.

[00:04:06] Jo Minney: Hi. It’s good to be back again Nathan.

[00:04:08] Nathan Wrigley: Yeah, you’ve been on the podcast before. But this time it’s different because this time we’re actually facing each other. Last time we were doing it on, you know, something like Zoom or something like that, but here we are staring at each other because we’re at WordCamp Asia. We’re in the Philippines, Manila. It is the second day of the event, kind of. We had Contributor Day yesterday. Today is presentation day. It’s the first day of the presentations, and you are doing one.

[00:04:29] Jo Minney: I’ve done one actually. I did it at 11 o’clock this morning.

[00:04:33] Nathan Wrigley: How did it go?

[00:04:34] Jo Minney: It went really well, I think. I had very good feedback from it. Half of the things on my slides didn’t work. I think that’s normal for a conference though, and I’m pretty experienced now at just winging it, and rolling with it anyway, so. It was really exciting because it’s a topic that I’m super passionate about and I haven’t had a chance to speak about it at a conference before. So, yeah, it was really nice to be able to share something that I do on a day-to-day basis and can stand up there and really confidently talk about.

[00:04:58] Nathan Wrigley: I don’t think I’ve ever spoken about this subject before in any of the podcasts that I’ve done. That is quite nice, and it’s novel. I’ll just introduce the topic. The presentation that you gave was called Budget-Friendly Usability Testing for WordPress. And obviously that sort of sums it up. We’re going to talk about usability testing.

But before we do that, Jo, just to nail your colours to the mast a bit, tell us about you. Where you’re from. What you do for a job, and anything that you think is relevant to this podcast.

[00:05:22] Jo Minney: Okay, I really like cats and pockets.

[00:05:25] Nathan Wrigley: I saw that in your show notes. Why pockets?

[00:05:27] Jo Minney: Okay. So I think pockets are a great example of something that can be both a fantastic and a terrible user experience. You are like, oh yeah, maybe I know what you’re talking about. But, let me ask, do you live with a woman?

[00:05:39] Nathan Wrigley: I do.

[00:05:39] Jo Minney: I know that’s a very personal question, sorry Nathan. But, how many times on average a month does she complain about not having pockets in her clothing?

[00:05:48] Nathan Wrigley: Never, she carries a bag.

[00:05:50] Jo Minney: Yeah, but why do we have to carry a bag, right? She has to carry a bag because her clothing doesn’t have pockets. So I spoke at a conference late last year, and I asked this question. This has been a life goal of mine, was to speak about pockets at a conference. And I managed to do it. I asked all of the women in the audience, hands up if you’ve ever thrown out clothes or gotten rid of them because they didn’t have pockets in? And every single woman stood up and was like, yes, I’ve gotten rid of clothes because they didn’t have pockets in.

Most of the people that were there were men. And I said, stand up if you don’t have pockets in your clothes right now. And 400 men stayed seated. But this is an example of something where, yes, there’s a subsection of the population that’s experiencing this problem, but it’s a big problem for us. It’s very frustrating. You’re at a conference, you don’t want to have to carry around a handbag. So, pockets. They’re a great example of user experience.

[00:06:45] Nathan Wrigley: Okay, I get it. I understand now. Tell us a little bit about your sort of day-to-day work, though. You work with WordPress, I guess.

[00:06:51] Jo Minney: I do. So I run a small agency. We’re what I usually call a micro agency, and we have only three of us that are working on the WordPress team. We do website development, but specifically for charities, nonprofits, cause-based organisations, so a lot of social enterprises and that sort of thing.

On top of that, I also do consulting for user experience research. I’m not a designer. UX and UI often get lumped together. They’re very different. UI is about the interface and what people see, and UX is about user experience and how people use things. And they can’t be completely separated, but they’re also very different.

So I am lucky because I work in the niche that I work in, that I’m able to do a lot of usability testing and it’s something that a lot of people don’t get the experience to do. And so I thought I would share what I’ve been able to learn over having this sort of unique opportunity to do so much usability testing, and share with people how they can do it more cost effectively, but also the benefit that it can have for a project.

[00:07:54] Nathan Wrigley: Let’s dig into it and I’m going to actually crib the questions which you posed to the audience today. You put four questions surrounding your subject. And the first one is this. And I’m sure that the listeners to this podcast, if they’re anything like me, they’ll probably have some impression that usability testing is a thing that you could do. And I think the word there is could, as opposed to do, do.

I imagine most people have an impression of what it is, but whether or not they do it is another thing altogether. But that would then lead to this. What even is it? So what is usability testing, and what are you actually testing for? So that was a question you posed to the audience and now I’m throwing it right back at you.

[00:08:34] Jo Minney: Yeah, it’s a good question. It’s probably the sensible place to start. So usability testing is not the same as user testing, or user acceptance testing. And it’s focusing on, how do we identify what the problems are with something that we have created?

So a lot of UX research is focused on what we call quantitative testing. So, meaning we’re looking for quantities of something. It could be the amount of time it takes someone to do an action. It could be using heat maps. So we have a thousand users, let’s see where their cursors most often are going. Let’s see how often they scroll down the page. And quantitative testing is really good at showing you comparisons of whether one thing or another thing works better, but it’s not actually good at identifying what the problem is, only that there is a problem.

So you can do a lot of testing and still not know what the problem is. Usability testing is different because it’s what we call qualitative testing. So it means that we’re not looking for big numbers, we’re not looking for lots of data. We are looking for really deep user experience examples. And in a nutshell, the way that that works is you recruit some participants, usually five people per round is ideal. And often I get asked, well, how can you have statistically significant data with only five people? That’s not the point of qualitative testing. The point of qualitative testing is not to have statistically relevant data, it’s to have the actual user experiences.

So you recruit your people, you come up with your research questions and that’s the problem that you’re trying to solve or the question you’re trying to get an answer to. So, an example might be, are users going to recognise this label that I’ve used in my navigation? Is this button going to get clicked if I put it in this location? It’s often a thing that, if you’re working with a customer to develop a website for them, what we find is that often the things that we are testing for in usability testing are things that the customer and I disagree on, or things where they weren’t sure when they made the decision in the first place. And they’re a great example of things that you want to test for.

But the research questions are only the first part because if I say, the example I used in my talk today is that we had a support service directory. And this was for people who are experiencing family domestic violence. And they didn’t want to use the term directory because it’s a very harsh term. So they had called it support services, which sounds, on the surface like a good idea, but a lot of the people that are using their platform are not English first language. And they also tend to be in a really stressed out state as you can imagine.

And so what we actually found is that when we said to them, can you imagine you’re helping someone, can you help them find a legal service that will enable them to get a restraining order or something like this? What we found is that repeatedly they didn’t go to support services to start with. The minute we changed that to service directory, they started to find the thing that we wanted them to click on.

It’s such a small change, but it made a huge impact, the usability. Now, we found that out after the second test, which meant that we were able to change it after the second test, and then we had three more tests where we could show that every time they were able to find the thing that we wanted them to be looking for.

So this is an example where the research question and the research task or the activity that we’re giving to the user, they’re not the same thing. If we said to them, find support services, find the service directory, if we use that language, obviously they’re going to look for that label. But instead we asked them to do an activity that would hopefully take them to the place we wanted them to go to.

And then finally the last step is to iterate that and to actually take that data and make decisions, and make improvements to the project iteratively to try and make it better. That’s the goal, right? Is to find what the problems are and fix them. So we still have to work out how to fix them, but at least we know what the problems are and not just that people were not clicking on the button and we don’t know why.

[00:12:27] Nathan Wrigley: I have a couple of follow up questions. First thing isn’t the question, it’s an observation. So that’s really cleared up in my head what it is, so that’s amazing. But one of the things that I want to know from that is, do you filter out people who, let’s say for example, you’ve got a website, the kind that you just described. Do you filter out people who are not the target audience? So in other words, I don’t know, maybe that’s not a perfect example. But let’s say, on some websites, would it be better to have really inexperienced users of the internet as your five candidates?

[00:12:59] Jo Minney: That is exactly the ideal person.

[00:13:02] Nathan Wrigley: So people who are just, I’ve never come across this before. You want people who are potentially bound to be confused. If somebody’s going to be confused, it’s you five.

[00:13:10] Jo Minney: That is the ideal participant for a usability study. And often people say, I want to start learning how to do usability testing. Where should I start? And my advice to them is always the same, with your mum.

Recruit a person that’s a generation older than you, because I can guarantee that in most cases, sorry to generalise, but they tend to be less efficient and less used to technology because they haven’t grown up with it. So for millennials and younger, we have had technology for all of our adult lives and most of our childhood.

For my parents’ generation, they have had to learn that technology as an adult, and so their brains have a different mental model, and they don’t take for granted things that we take for granted. Like, when I click the logo, it will take me back to the homepage. I know that, you know that, your mum might not know that.

And I think that is something that is really valuable is to understand the benefit of testing with people who aren’t as experienced with technology. Who don’t speak English as a first language. Who are experiencing some kind of accessibility challenge. Whether that’s using assistive technology, being colorblind. Things like that are really good things to try and get some cross-sectional representation in your testing participant pool.

[00:14:25] Nathan Wrigley: So the idea then is that you’ve got these novice users who hopefully will immediately illustrate the point. And it’s driven by questions. So it’s not just, we are just going to stand over your shoulder and watch you browse the internet, and when you do something and describe, you’re looking for something and you can’t find it, that’s not how it’s done.

It’s more, okay, here’s a defined task, do this thing and we’re going to ask you to do five things today, we want you to achieve them all and describe what you’re doing, but it’s more of that process.

And then the idea is that you go from an imperfect website, slowly over time, iterating one problem after another towards a better website. The goal is never reached. It’s just an iterative process.

[00:15:01] Jo Minney: That’s it. Perfection does not exist.

[00:15:03] Nathan Wrigley: Okay, so that’s interesting. So we start with the novice. We’ve got a small cohort of people. We ask them specific questions, and we get feedback about those specific questions.

So the other thing that I wanted to ask then is, when do you do it? Because it feels like you need to build the website first, then show it to people. So there’s got to be something. This isn’t process of discovery prior to the website. You need pixels on pages. Buttons that are potentially mislabeled or what have you. Is that the case? Build first, then usability test afterwards. There’s no usability testing prior to the initial build.

[00:15:37] Jo Minney: It’s kind of a trick question because you can usability test at most stages. Probably the only stage you can’t usability test at is when you don’t yet have a site map. Having said that, my recommendation is, assuming you had unlimited budget and unlimited time, I would do at minimum two rounds of usability testing, and I would do one before you have any design, and I would do it just using wire frames.

So we build interactive wire frames using WordPress. So for the demo that I did today, I spun one up. I used InstaWP. You can get like a seven day website or something through there. It took me 42 minutes to build out the website in just the block editor, with no design or anything, just the layout of it. And I was eating a loaded potato at the time. So if I can do that in 42 minutes, eating a loaded potato, and that’s not my job, I think it’s a pretty efficient and cost effective way of being able to do early usability testing.

And often the thing that we’re testing for there is like, have I got the right navigation structure and hierarchy? Are the labels that I’m using sensible for people? Do they fit with the mental models of what our users are actually expecting? And the benefit of doing it that early is that when you don’t have a design applied, it’s a lot easier to identify problems.

Because there is a thing that happens in human psychology, and there’s a lot of psychology in user experience. And there’s a thing that happens where if something’s pretty, we will say that it is easier to use. Our experience is that it’s easier to use because it’s nice to look at. And that’s great. That means that UI is really important, but it also means that, if you have a really nice UI, it can mask problems that you have in the background. It is great that things can be easier if they’re pretty, but imagine how much easier they would be if they worked well and were pretty, that’s what we should be aiming for.

So typically we would do one round of usability testing when we just have a framework and just have the navigation. When someone lands on a page, sometimes we’ll just write a message on there and say, congratulations, you found the service directory where you can find this thing, this thing, this thing, this thing, and then we put a little button there. When they click it, it releases confetti on the page. So they get a dopamine hit and it’s like, yay, I completed the activity. You don’t have to have all of your content in place to be able to do testing, and identify early that you’ve got problems that you need to fix.

[00:18:02] Nathan Wrigley: It sounds almost like an overly complicated design is the enemy of usability. We are drawn towards beautiful, but sometimes maybe beautiful just is overwhelming. You know, there’s lots of colors on the page, the buttons get hidden, there’s just too much text on there. Looks great, but it might be sort of masking the thing that you’re really trying to show. And it feels like there’s this tight rope act of trying to balance one thing against the other. Yeah, that’s really interesting.

So, with the wire frame thing, in that case, you are really just testing, can the person find the thing? But I’m guessing once you’ve move beyond the wire frame stage and you’ve got a website, it’s literally out on the internet, it’s functional. It’s exactly what we hope would be the perfect version, then you’re drilling into more detail. You know, can a person find this resource? Do they know that this button is what we are intending them to click? Those kind of things.

[00:18:49] Jo Minney: Yeah. So I think things like searchability and discoverability are much easier to test for in the early stages when you’re just doing, say, using like a wire frame or a prototype. And things like usability, you really do need to have the complete designed product to be able to test for them well. And I say that, there’s actually kind of four categories of the different types of tasks that we can do. I’ll give you the link to the blog post that I wrote that has all of this in detail because we do not have time to go deep into that today.

But things like, does my search form work the way that I want it to? They’re the sorts of things that you do have to do some development to be able to get them working. So it’s not always practical to do that at the very early stages when you do want to start testing your navigation and stuff like that.

Something that you can do is if you’ve only got enough budget, or enough time, to be able to do, say, five usability tests total, you could do two of them early, and then you could do three of them towards the end, after you have the majority of the design and the development work in place. Users are pretty forgiving when they’re doing a usability test. If you say, this is still a work in progress, there might be a couple of pages that look odd and aren’t quite ready to go live yet. If you get somewhere and you’re not sure, you can just go back, it’s okay.

It’s not meant to be a perfect experience. The point is that you are getting their real time thoughts and feedback as they’re doing it. So it’s really important that you try and encourage them to follow the think aloud protocol, which is really outlining every single thing that goes through they’re head, just brain dump on me please. Like, I just want to hear all of your thoughts and thought processes.

And the only thing as the facilitator that I will say during a usability test is, tell me what you’re thinking. And other than that, I am completely silent. So even when it comes to giving them the activity, so if I’m asking you to do an activity like help somebody find a legal service that they can use in this particular state. I would actually send that task to you via the chat or something like that.

I would send the task to you via the chat, and then I would get you to read that task back to me, because I don’t want you to be thinking about how I’m saying it. I want you to be able to go back to that task and look at it, and think about it, and process everything inside your own head. But I want you to be telling me all of that.

So often we’ll find people ask questions during that, like, what should I do next? And the answer to that is really hard to train yourself out of replying to them with anything other than, what would you do if I wasn’t here? And I think that’s the hardest thing about learning to facilitate a usability test.

[00:21:24] Nathan Wrigley: Yeah, and in a sort of an ideal scenario, you wouldn’t even be in the room. But in some strange way, you’d be able to just get into their head and say, okay, now I want you to do this, but every time you’ve got problem, just figure figure it out, and we’ll watch. But you have to be there because you have to be able to listen to what they’re saying and what have you. Yeah, that’s curious.

[00:21:40] Jo Minney: Yeah, and we do, at the end of each activity, we’ll then ask them for feedback on how they found it. If they had any suggestions or things that they didn’t say out loud while they were doing it that they wanted to share with us. How confident were they with the activity, and did they think that they were successful in it, which is a really good way of telling, I wasn’t really sure what the activity was meant to do. Or I wasn’t really sure if what I found really met the needs that I was looking for.

Then we ask them, how certain are you with the answer that you just gave? And if they’re like, three out of five, you’re like, alright, this person didn’t understand what it was that I was asking them to do in the first place. Maybe the problem is actually with my question and not with the website.

[00:22:18] Nathan Wrigley: Okay, so the whole process is, you’re not just asking for feedback about the website, there’s a whole process of asking for feedback about the process as well which is, that’s kind of curious. Meta, meta processing.

[00:22:27] Jo Minney: Very meta, for sure.

[00:22:29] Nathan Wrigley: We’re in an industry where at the moment everything is trying to be automated.

[00:22:32] Jo Minney: Is this the AI question?

[00:22:34] Nathan Wrigley: Well, no, this feels like it’s a very human thing. You need actual bodies on the ground. So it’s really a question of economics. Because I’m wondering if this often turns out to be a fairly expensive process. And because of that, I wonder if people push against it, because the budgets may not be there. If this is something that clients typically would say, well, okay, tell me how much that’s going to cost. It’s a nice idea but, okay, it’s going to cost us X thousand dollars because we’ve got to put five people in a room and we’ve got to pay for your time to moderate the event, and come up with the questions and so on.

How do we manage that in an era of automation where everything is, the dollar cost of everything has got to be driven down. This feels like the dollar cost is going up because there’s humans involved.

[00:23:14] Jo Minney: Yeah, it’s a great question. Have you ever run a Google ad before?

[00:23:17] Nathan Wrigley: It’s expensive.

[00:23:18] Jo Minney: It’s very expensive. It’s very expensive to get a new lead. It’s a lot more cost effective to convert a lead than it is to get a new one. And the point of usability testing is to improve conversion of people being able to do the thing that you want them to do on the website.

So my first answer to that would be, look at the cost benefit analysis. It’s worth it in most cases to do usability testing. Something that we’ve found with positioning of usability testing is that if we offer it as an add-on, then people don’t want to do it because they don’t want to pay for it. They see the value in it necessarily. However, we don’t offer it as an add-on.

We actually have it just as part of our proposal right from the start where we’re like, this is part of the point of difference between what you get when you build with us versus when you build with someone else. They’ll tell you what they think is the best way to do something. If we are unsure about the best way to do something or we disagree on it, it’s not going to ultimately be me making a decision or you making a decision. We’re going to test and we’re going to get real evidence from customers.

And they’re the ones that are going to be developing it so you know that the final result that you get is going to be the best possible version of the website. And often we might be more expensive than our competitors, but people will go with us because we are not competing on price. We’re competing on offering a service that nobody else is offering. I asked today in the presentation who has done usability testing before and not a single person put their hand up.

[00:24:42] Nathan Wrigley: That would’ve been my assumption actually.

[00:24:44] Jo Minney: Yeah. And honestly, I don’t think any of the people that we’re competing against in the industry that I’m in are doing the same thing as what we’re doing. And so it is very much a point of difference. I think it’s not a well understood technique, but it’s so valuable that it is a really easy way to position yourself as being different, and really actually do a better job for your customers, for the people that you’re building websites for. Because ultimately you are going to have a better result at the end of it.

[00:25:12] Nathan Wrigley: The interesting thing there is, when I say usability testing, somehow in my head there is a connection between that and accessibility. And that’s not where I’m going with this question, but there’s just something about it being unnecessary. And I’m not binding that to the word accessibility. What I’m saying is clients often think, I don’t need to do that. Obviously, we’re moving into an era where legislation says otherwise. But I can just leave it over there. I don’t need to worry about that, usability testing, not for me.

However, the lever that you’ve just pulled, it completely changes the dynamic because you’ve pulled an economic lever, which is that if we can get everybody to follow this action, I don’t know, fill up the cart with widgets and then press the buy now button, and go through the checkout process. If that’s the thing that you’re usability testing, you’ve made direct line. You’ve joined up the dots of, okay, user, money.

So it’s not just about it being a better website so that people can browse around it all day. It’s also about connecting the economics of it. So the usability is about people buying, converting, getting the resource. And so there might not be an economic transfer there, but it will be some benefit to your business. There might be downloading that valuable PDF that you want everybody to see or whatever.

So that’s kind of interesting. That’s changed my thoughts about it a little bit. And it is more about that. It’s getting an understanding of what you want out the website, getting an understanding of what you think should be happening is actually possible and happening. Have I sort of summed that up about right?

[00:26:40] Jo Minney: Yeah, I think that’s a really good summary it. I think the only thing I would add there is that a lot of the times the conversation around accessibility and the conversation around usability do have a lot of crossover. They are fundamentally different, but one of my favorite examples is actually something that I think applies to both.

So two of the common problems that we find very early on in design is often to do with colour. And so one of them is colour contrast and the other one is colourblind accessibility. And I think it’s a great way to get people to change their thinking, and their perception of the way we have these conversations is, if you have an e-commerce website, Nathan, what would you say if I said to you, I can instantly get you 8% more customers?

[00:27:23] Nathan Wrigley: Yeah, I’d say that’s great.

[00:27:24] Jo Minney: And I’d be like, cool, change your buttons so that colourblind people can read them, because 8% of men are colourblind. So actually it’s only 4% of people because assuming half of them are men, then you’ve actually only got 4%. But still 8% of men are colourblind, that’s a big percentage of the population. So if your button is red and green, then you’re going to have a problem. People are not going to be able to find the thing that you want them to click to give you their money.

Likewise, if you want people to be able to use your website when they’re outside and using their phone in sunlight, then you need to have good colour contrast on your website. So often this conversation is around, well, I don’t have people who are disabled, I’m not trying to cater to people that are using screen readers. It doesn’t matter because not very many people that are using my website are blind. And I’m like, well, I’m not blind but I still struggle when I’m looking at something where the text is too faint, and I’m looking at it on my phone, and I’m standing outside in the sun because we naturally don’t visualise as much contrast there.

So I think being able to position it in a way where people can see the value to themselves. I want to use a website that has better contrast, and so it makes that conversation easier with a customer.

[00:28:32] Nathan Wrigley: I hadn’t really drawn the line between accessibility and usability, but it seems like they’re partner topics, basically. There’s like a Venn diagram, accessibility over here, usability over here, with a massive overlap somewhere in the middle.

[00:28:43] Jo Minney: A hundred percent. That’s why we always encourage having that sort of intersection between accessibility and usability in our testing pool. So we always try and have one person who experiences some kind of accessibility challenge, whether that’s being colourblind, hearing impaired, if we’ve got a lot of video on the site, for example. And I think that it can be a really valuable way of collecting multiple data points at one time.

[00:29:04] Nathan Wrigley: When you have a client that comes to you and they’ve obviously, by the time that they’ve signed the contract with you, usability is already part of the deal it sounds like. How do you decide, what’s the thing in round one that we’re going to pick up on? Is there sort of like a copy book that you go through? Is it like, I don’t know, buttons or the checkout or colour or? Where do you go first? And sort of attached to that question a little bit, this process never ends, right? In theory, you could do usability testing each month. But I was wondering if you did it like on an annual cycle or something, yeah.

[00:29:34] Jo Minney: If you’re not changing stuff super often, I would say, there’s probably more cost effective ways that you can collect information about it. Typically we encourage, long-term, have things like heat maps and stuff like that. They will help you identify if there is a problem. If you know that there is a problem, let’s say you’ve got a heat map and you’re like, why is nobody clicking on our buy now link? That is a good instance of where you would do some usability testing to figure out what the problem is.

But if everything’s working and you’re getting conversions, then probably doing usability testing isn’t the most valuable thing that you can do. If you’re looking at making significant changes to the way that your website works, that’s another good time to introduce a round of usability testing. So we don’t do it just for the sake of doing it. We do it because we need to do it, and because there’s value in it for our customers.

[00:30:18] Nathan Wrigley: Do you keep an eye on your customer’s websites so that you can sort of get ahead of that, if you know what I mean? So let’s say that you put heat maps in, very often that would then get handed over to the client and it’s somebody in the client’s company’s job is to check the heat maps. Or do you keep an eye on that and, oh look, curiously, we’ve seen over the last 12 months, yeah, look at that. There’s not much going on over at that very important button over there. Let’s go back to the client and discuss that. That could be another round of usability testing.

[00:30:44] Jo Minney: Yeah, so I think we’re not uncommonly, a lot of agencies now do have some kind of retainer program where they will maintain communication and assistance for their clients. So we call them care plans. I know everyone has a different name for it. I think it’s pretty standard now in the WordPress ecosystem. It’s a very common thing to do.

As part of our care plans we have scheduled meeting with our clients once every three months or six months or 12 months, depending on how big the site is. And one of the things that we’ll do at that time is review their analytics, review the heat maps, that sort of thing.

Ask them, have they experienced any problems? Have they noticed a downturn in the people signing up for the memberships? Or have they noticed, have they had any complaints from people about something? Is there anything that they’re not sure about? Are they going to be changing the way that they operate soon, and introducing something new into their navigation that we need to consider where does that fit in the grand scheme of things?

I find if we’re having those conversations early and we are the ones starting those conversations, then often we are coming to them with solutions instead of them coming to us with problems.

[00:31:46] Nathan Wrigley: I think that’s the key bit, isn’t it? If you can prove to be the partner that comes with, we’ve got this intuition that there’s something that we can explore here. You are proactive, you’re going to them not, okay, anything you want? Is there anything we can help you with, you know? And the answer to that is always, not really.

Whereas if you go and say, look, we’ve got this idea, based upon some data that we’ve seen, we’ve got heat maps and what have you, shall we explore that further? That seems much more credible. You are far likely, I think to have an economic wheel which keeps spinning if you adopt that approach, as opposed to the is there anything you want doing, kind of approach?

[00:32:18] Jo Minney: Absolutely. I think every developer’s worst nightmare is having a customer come back to them and say, I’ve just noticed that I haven’t had anyone send through anything in my contact form for the last three weeks. And I’ve just noticed, when I went and tested it, that the contact form’s not working anymore.

I’m sure I’ve had that nightmare at least once. And I think if you can avoid being in that situation where they’re coming to you with something like, oh my God, it’s broken, how do I fix it? If instead you can go to them and be proactive about it and just kind of keep your finger on the pulse.

Yes, there’s a little bit of ongoing work, but like honestly, I jump on, I check all of the analytics maybe once every three months for my clients. I set aside one day to do it. Go and have a look through that. If I notice anything, I can usually fix it, make sure that we’re collecting the data again before it becomes a problem.

And then that way when there is an issue, we’ve got data that we can back up and we can start from there and go, okay, yes, we’ve identified, here’s where we need to do more research. And then we can apply something like usability testing to that.

[00:33:16] Nathan Wrigley: How much of your time on a monthly basis, let’s say as a percentage, do you spend on usability of existing clients? Is this something that is a lot of the work that you do? What I’m trying to figure out here is, for people listening, is this something that they can turn into a real engine of their business?

Because you might get two days, three days work a week just on the usability of pre-existing clients. So in a sense, you’ve created interest and work out of thin air, because these clients already exist, they’re in your roster, but there’s a whole new thing that we can offer to them. So, how much do you spend doing it?

[00:33:50] Jo Minney: Yeah, so it’s a great question. I would say it’s cyclical. I couldn’t really say like, I always spend this much amount of time. There might be entire weeks that go by where my whole life is usability testing, and there might be a month that goes by where I don’t do any. And it really does often depend on where our projects are in the life cycle at any particular time.

So we’re often working on projects that will span over years. And because of that, they might introduce a completely new part of their project. And that’s a good time to reintroduce that usability testing. As I said, like you don’t really want to do it just for the sake of doing it, but at the same time, if you can show that there will be value in making a change, if you can show that there is a lost opportunity somewhere, then a hundred percent you can sell that, the value to them of, hey, you could spend $1,000 now, but you could be earning $5,000 more every month for the next several years. That’s a no-brainer, right?

People are happy to make investment if they can see that there’s going to be a cost benefit for them in the future. Or if the thing that they’re trying to do is maybe their government website or something, and they’ve got a particular thing that they need to meet, they’ve got KPIs. If you can show that you are able to help them meet those KPIs, then they are going to invest in doing that thing that you’re trying to offer them.

[00:35:02] Nathan Wrigley: We talked about the Venn diagram of accessibility and usability, and the fact that there’s a lot of an overlap. In the year 2025, this is a year where, in Europe at least anyway, accessibility, the legal cogs are turning and the screw is getting tighter. So accessibility is becoming mandated in many respects.

And I was wondering about that, whether there was any kind of overlap in legislation on the usability side. The accessibility piece is obviously easier to sort of define in many ways, and it’s going to become less optional. But I was wondering if there was any usability legal requirements. I don’t know quite how that would be encapsulated.

[00:35:41] Jo Minney: Sort of. An example that comes to mind is that there are a lot of practices that historically have been really prevalent on the internet, and they’ve been identified as being really bad for usability. And they’ve actually now been identified as being so bad that they’re almost evil. And they’ve started to crack down on those.

And an example of that is, have you ever tried to unsubscribe from a gym? It’s basically impossible. And so now if you, at least in Australia, I know if you have a subscription on your site, you legally have to have a way of people being able to unsubscribe without having to call someone or send an email somewhere.

And that is an example where that is actually usability. And I think there are definitely things where we are picking up on stuff that is maybe a shady way of working, and a shady way of developing websites. And those things are starting, we’re starting to cut down on them.

I’m not sure if that is purely usability, or just like not being being a bad person. But I think that there is definitely, the only reason that we know that those things are a problem is because we have all had those bad experiences. And ultimately that’s all user experience is, it’s just how good or bad is experience of using a platform.

[00:36:49] Nathan Wrigley: I share your frustration with those kind of things because I’ve been through that process. Not just canceling a subscription but, I don’t know, something that you’ve got yourself accidentally into and you don’t want to be on that email list anymore. Seemingly no way to get off it.

[00:37:01] Jo Minney: They’ve changed the unsubscribe link so it doesn’t have the word unsubscribe in it. And now you just have to look for the word that’s not underlined, or highlighted in a different colour. That when you hover over it, something pops up and you’re like, oh, that’s the link. That thing that says manage preferences down the bottom, hidden in the wall of text. That is a shady practice. That is a poor user experience just as much as it’s just a bad thing to do.

[00:37:23] Nathan Wrigley: I think it’s got the label of deceptive design now. It used to be called dark patterns, didn’t it? But deceptive design. This notion of doing things in such a way to just deliberately confuse the user so that the green big button, which is the exact opposite of what you want to click, is the one which is visible. And then there’s this tiny little bit of greyed out text, which is the one which, clearly, you’ve ended up at this page, that’s the one you want. That’s the enemy of usability in a way. But for the business, it may be exactly what they want because it keeps the economic engine rolling.

Yeah, that’s interesting. I wonder if there’ll be more legislation to tighten those things up so that they’re not allowed. Yeah, that’s fascinating.

Last question. We’re running out of time. Last question. And it refers to something that we talked about earlier. I’m guessing this really never ends. This is a journey which you begin, you tweak it, you do a little bit, you fix, and then you start again a little bit later and what have you. Is there ever a moment though where you go to a client and say, we did it? This site, as far as we’re concerned, is now perfect. Or is it never a goal? It’s a journey and never a destination.

[00:38:23] Jo Minney: I think you’ll probably agree with me here, Nathan, that it’s basically impossible to be perfect, because ultimately someone is always going to have a different opinion. Someone’s always going to think that your shade of purple is too dark. Someone is always going to dislike the font that you chose, because it’s not loopy enough, or it’s too loopy, right?

So I don’t think there is such a thing as perfect. But through doing five usability tests, five people, you can pick up at least 85% of the potential problems with your design. And I’m not aiming for perfect, but I know that for me, if I can confidently say to my customers that I’ve been able to identify 85% of the potential problems that they might experience in their project, then they can confidently go away and say, hey, we’re pretty happy with what we’ve got.

We can definitely improve on that over time. But that is a huge milestone to be able to hit. And being able to have enough data, and enough research to confidently say that, I think is a really big win both for us and for our customers.

[00:39:26] Nathan Wrigley: Sadly, Jo, time is the enemy, and I feel like we’ve just pulled back the lid a teeny tiny bit on the big subject of usability. Honestly, I reckon I could talk for another two hours on this at least. You know, because you’ve got into colours there and all sorts, and there’s just so many tendrils that we haven’t been able to explore. But we’ve prized it open a little bit, and so hopefully the listener to this has become curious. If they have, where would they find you? What’s a good place to discover you online?

[00:39:53] Jo Minney: Yeah, so I think the best place is to hit up my personal blog, jominney.com. So it’s J O M I N N E Y .com. And I have a lot of stuff on there about usability, usability testing. I have a blog post that I wrote specifically for this talk that shares all of the resources that I used to put together the slides and everything. The talk itself will be on WordCamp TV. If you’re on socials and you want to hit me up, pretty much the only platforms I’m active on nowadays are LinkedIn and Bluesky, and I’m Jo Minney on both of them.

[00:40:23] Nathan Wrigley: Jo Minney, thank you so much for chatting to me today. I really appreciate it.

[00:40:27] Jo Minney: You’re most welcome, Nathan. Thanks for having me again.

[00:00:00] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress, the people, the events, the plugins, the blocks, the themes, and in this case, WordPress, security, and the OSI model, which underpins the entire internet.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox, and use the form there.

So on the podcast today we have Robert Jacobi. Robert has a long standing history with the tech and CMS industry, having worked in senior positions at Joomla, Cloudways, Perfect Dashboard and more. He’s now the Chief Experience Officer at Black Wall, a company formally known as BotGuard.

Robert talks with me today about the transition from proprietary systems to open source, and the seven layer OSI model that underpins the internet. Drawing from his experiences in tech, Robert and I try, and perhaps fail, to break down the complexities of how website traffic is rooted over the internet. This is done to try to understand how Black Wall can position itself to mitigate risks before they reach hosting companies infrastructure.

We also discuss the evolution of bot traffic on the web, where upwards of 10% of internet traffic is identified as malicious. This kind of insight is particularly important for those interested in the security aspect of web hosting and website management.

We also get into Black Wall’s rebranding journey, and its continued dedication to the WordPress community by participating in events like WordCamp Asia and Europe.

If you’ve ever wondered about the unseen layers of internet security and infrastructure, or the strategic moves involved in rebranding a tech company, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Robert Jacobi.

I am joined on the podcast by Robert Jacobi. Very nice to have you on. I think I’m going to muddle up the company that you work for, because a little bird tells me that in the very, very recent past, the company that you work for became, well different in some way. Perhaps a name change, a logo change. Who did you work for and who do you now work for? And are they the same thing?

[00:03:08] Robert Jacobi: Well, I still have my original swag, the BotGuard polo, which all of us have at the team, but we are now Black Wall. So Black Wall, formerly known as BotGuard. So we’ve done a full rebrand. I’m sure a lot of folks have seen already. But yep, just bringing it forward. Allowing ourselves to take on more of what we do, on top of the highly focused bot security monitoring and mitigation.

[00:03:32] Nathan Wrigley: Okay. That’s a perfect introduction then. So give us your potted bio in tech, in CMSs. I’m not going to say WordPress because it’s a bit bigger than that. And maybe just throw in the BotGuard, Black Wall bit at the end there, and what your role is there. So just a couple of minutes. Just tell us who you are and whatnot.

[00:03:49] Robert Jacobi: Minutes, I could spend all day talking about myself. So I’ve been in the industry for a number of years. Mumble, mumble, how long it’s been. Let’s go with CMSs because, actually a big passion way back in the day, had an agency where we created our own, of course proprietary CMS because that’s what you did.

And then moved into open source for a number of reasons. Primarily, which I hope all agencies don’t need to talk about anymore, because I think it’s pretty obvious. It was the hit by a bus theory that, we put all our eggs into a proprietary basket, and we get hit by a bus, then that customer is stuck. With open source, there’s the community of the ecosystem, and it’s huge.

And, you’ll always have your preferred vendors for many, many, reasons, but if something happens, you’re not locked into that code. You’re not blindsided. That was a fairly quick transition, and wound up working at the time, sorry WordPress universe, went to Joomla because hey, back in that day Mambo slash which became Joomla, was honestly just more of a stack that our team leaned towards. It was MVC based. It was geeky. There were tons of features, and functions that the types of customers we were working with, it resonated with. Especially multilingual at the time.

Fast forward, let’s say 10 years, and now WordPress is beyond a competing product. It’s got an ecosystem a, value with its name brand, and literally the immense community that’s been built around it.

From there went to, transitioned off of the Joomla space, and popped into a company called Perfect Dashboard. Oh, I forgot, I actually was the president of Joomla, briefly, so.

[00:05:31] Nathan Wrigley: Just a little fact there, yeah.

[00:05:32] Robert Jacobi: You know what, I should not forget that because that one year felt like 10. It’s a lot to work with a huge community, for many, many reasons. You have so many stakeholders. People whose lives depend on the product, the solution, the community, the ecosystem. Certainly not going to get into WordPress drama, but I understand how difficult it is to bear those responsibilities. And, it’s a lot. Immense amount of work. And WordPress has done amazing things in sustaining that for decades.

So, moved over to the WordPress side of the universe. Company called Perfect Dashboard. We were acquired. Moved to running the WordPress business unit of Cloudways, also now acquired by Digital Ocean. And today I’m at Black Wall. I’m the Chief Experiences Officer for Black Wall. So that includes community, includes evangelism, includes investor in government relations. It’s really making sure that there’s an ability to communicate all the things that we do to the right people.

[00:06:32] Nathan Wrigley: And what does well formally BotGuard, now Black Wall, what do they do? What do they offer up into the market? Is it a WordPress thing, or is it more of a, we’ll get into the OSI model in a minute, but is it more of an operating system thing?

[00:06:46] Robert Jacobi: It’s at the top of the stack. So while, let’s just call it 50%, I know that’s not the exact number, but it’s close enough that I, think it’s fair to say, 50% of the web is run by WordPress. We’re still very heavily involved in the community. So we were just at WordCamp Asia. We’ll be at WordCamp Europe. These are places want to meet folks, communicate our solution, and engage with hosting providers because, when we get to running through our little OSI stack that you and I are obviously super experts in, we’ll kinda see where WordPress falls into it and where security matters, up and down that stack.

We’re trying to help WordPress end users and hosting companies before you ever actually have to get to WordPress, because we already see that a significant portion of internet traffic, 40% of internet traffic is bots. AI agents, whatever you want to call them. And 25% of that 40%, so 10% is completely malicious. And you don’t want to get near the hosting company, the actual application, or anywhere further down the stack if you can avoid it.

[00:07:50] Nathan Wrigley: So it sounds, just the name, and I confess, I don’t know much about what BotGuard, Black Wall do, did. But it sounds to me from the naming of it, that it’s a bit like you are literally a sentinel. You are standing in the way of things. Examining things that are coming your way and saying, no, you may not pass, but you may.

And a bit like throwing it into dev null, if something is unable to pass, you are just black walling it, as it were. You are just saying, nope, off you go, drop, you’re outta here. Is that basically the principle? You are a security firm preventing things that are bad happening to whoever it is that uses your services.

[00:08:25] Robert Jacobi: Some of it’s super, super bad, so you’re going to dev null it. And then there’s a spectrum of how bad those connections can be. We want to focus on humans getting to human content. Our key, sort of value propositions, humans are secure, humans are actually visiting your site. That’s what’s important.

But there are good bots, and there are good bots who accidentally do bad things. And then there are the bad, bad bots. We obviously want Google to index our sites. We may or may not want Open AI indexing our sites. We certainly don’t want it. causing an accidental denial of service by how much it’s scraping our content. Which we have seen many a time. Where it’s like, great Open AI, come on in, take one quick look and get out. But it’s like, I’m going to stay there and I’m going to churn through everything. And we’ve seen it and it knocks sites out. And the AI engines, agents are particularly bad about that, because they’re trying to fill in and understand that data.

[00:09:25] Nathan Wrigley: Yeah. Okay, so we’ve got some idea of what you do. Just as an aside, what a shame that the internet has a need for a company like yours. I don’t mean to take the food off your table, but back 20 years ago this just wasn’t really a thing. Just this promise of the internet to be this philanthropic place with unicorns and rainbows everywhere, where we were all going to throw our content in, and we were all going to consume it and it would be wonderful.

And now we have well, human beings presumably started the whole thing, but now human beings have written codes such that they can step away and let their robots carry on. And what a shame that we need to have things like captchas on forms. and we need to pay security companies to do all of this stuff.

And again, I’m not trying to say that your business doesn’t have a place. Clearly it does. But from a philosophical point of view, I wish that they didn’t need to exist, because the place was benign and harmless all the time.

[00:10:19] Robert Jacobi: I’m going to poke a tiny hole in that bubble.

[00:10:21] Nathan Wrigley: Please do.

[00:10:22] Robert Jacobi: Actually, this is not a bad thing because we’ve actually moved most of the troublemaking away from us locally. You want to go back 20 years ago and we’re dealing with Norton Antivirus on everything, and crossing our fingers and praying that something doesn’t sneak into our immediate homes.

We’ve actually been able to, because we’ve gone to cloud, push a lot of that super local personal risk a bit further downstream. So these security issues didn’t magically appear, they were much more, in fact, they were much more terrifying before. And I, oh my god, my Windows PC got hacked and now I have to like completely just throw it on the grill, light it on fire five times, and then reinstall Windows.

Most folks don’t worry about doing that with their laptops, with their phones or whatnot anymore. The scalable risks are completely different, because me getting hacked was one person. Now a cloud website platform application, and then I’m, 10 million people get hacked. But we’re pushing it further away and away and away.

[00:11:24] Nathan Wrigley: Yeah, it’s interesting. I remember in the dawn of computers that I had, I didn’t begin my computer journey right at the very, very beginning. You could walk into a store and walk out with a computer in more or less, every town and village in the country, when I began using them.

But the media, the way that you got things onto the computer was a physical thing. You held the object in your hand. It was either a CD or some kind of media that you could physically hold. And now of course literally nobody is installing anything off a CD. And so I guess the, inexorable rise of the internet, and everything coming down a, well, telephone line, and we’ll get into that in a moment. Putting it in the cloud makes way more sense, doesn’t it? It doesn’t really seem to have so much utility having the antivirus, if you like, on the computer. I know it does, don’t get me wrong. But I can see that the shift to mitigating the risk and detecting the risk and doing something about the problem in the cloud. Obfuscated, abstracted away, so that you never even really know what’s going on is probably the best way forward. So, yeah.

[00:12:25] Robert Jacobi: For 99.9 9, 9 9 9% of people, they’re not going to know or understand that they just want it to work. They don’t want to be robbed from, or in danger online. I always put it, as techy as I appear to be, I am the worst car person on earth. So when I think about internet security and what most people want to know about it, it’s pretty much what I want to know about cars.

I want my car to turn on. Go forward, go backward, get me to where I need to be as safely as possible. I don’t know, or care about anything else that’s going on under the hood. It’s a tool that I use and I want it to work like I expect it to work.

[00:13:04] Nathan Wrigley: Yeah. Given the population at large, it must be, one in a hundred thousand who care about the internals of their machine, probably even less so. Doesn’t matter really what you’re using, be it Mac, Windows, Linux, Chromebook, whatever it is, you just to flip the lid open and you want to just.

[00:13:18] Robert Jacobi: Check my email, log into my social media, buy something, call it a day.

[00:13:23] Nathan Wrigley: But because it’s becoming an increasingly crucial part of our lives. Certainly where I live in the UK, more or less everything has gone online that’s of any use. So shopping has gone online. Appointments for doctors have gone online. Dentists, it’s gone online. Pharmacy appointments, it’s all gone online. Paying your taxes, it’s online.

And so we really do need to protect this stuff. Really need to protect this stuff, because if it’s possible to, I don’t know, inject some problem in that path, we’re not just going to take out the beautiful experience of buying from a shop. We’re going to take out our ability to get fuel into our houses and into our cars and all of that.

[00:13:58] Robert Jacobi: Yeah, if you need that prescription, you don’t want that to go down, so.

[00:14:01] Nathan Wrigley: It’s become almost like, almost like a human right. That seems a bit of a ridiculous thing to say, but on some level, it seems like the internet or access to the internet is almost on that level. It certainly feels like it is as important as other key parts of the country’s infrastructure. So power and gas all of that, and the road network and what have you.

[00:14:20] Robert Jacobi: It is the information utility. So you have your power utilities, you have an information utility. It’s got to be available. In the States we always have our last mile issues, especially for very rural folks, about how connected are they, how fast is it? We always do this to ourselves. We got this great new toy, now let’s see how, great we can make it. Yeah, but if you’re not running at a hundred megabits a second your experience might really not be functional.

[00:14:46] Nathan Wrigley: So we’re going to talk today about something that I confess, I don’t know anywhere near enough of. So, Robert and I have shared an article, and I’ll put the article in the show notes. And essentially this thing that we’re going to talk about is what’s called the OSI model. And the OSI model comprises various different layers.

And basically, dear listener, if you’ve never thought about the gubbins of your computer, you, might just have this fairy tale notion that you open it up and start typing and it just works. I can send an email, of course I can send an email, you just click send and it’s gone and that recipient receives it.

But the breathtaking quantity of things going on in the background disguised from you. Really, honestly, Robert, none of this should work, and yet it does work.

[00:15:36] Robert Jacobi: Which is why I love my car analogy. I have no idea what is going on 99% of the time. I still have a gas car, so I know there’s a larger motor than an electric car. I know gas gets in there and lit on fire and moves pistons around, but really, in the most abstract sense of it. It goes, and that’s what I want it to do.

[00:15:56] Nathan Wrigley: There’s explosions happening all the time, and fuel is being funneled around, and things are turning because they’ve been lubed with oil and all of that. And honestly, your car is nothing compared to the internet. The complexities in the internet, because I know that electric cars have taken over from, or are taking over from gasoline cars, but broadly speaking, the gasoline engine probably hasn’t changed terrifically much in the last a hundred years. Whereas I think the infrastructure comprising the internet, although the OSI model probably hasn’t changed much either.

The things that are coming down the pike, and the things that have happened in the last 20 years, it’s breathtaking. So, dear listener, get out your tinfoil hat as Robert and I attempt and probably butcher what the OSI model is. And if you’ve got the capacity. Perhaps pause this podcast, go to the wptavern.com website, search for this episode and read the article. And the one that Robert came up with, which was a good one, is called What is the OSI model? It Standardizes How Computer Networks Communicate, and it’s on bluecatnetworks.com, but I’ll provide the link.

[00:17:00] Robert Jacobi: The best one I found that had the good pictures to also help. Because visually it’s hard to, you think you have a server, some wires and a browser and it’s like me saying I have an engine, some gas, and a steering wheel. There’s a lot of pieces that go in between all those parts.

[00:17:18] Nathan Wrigley: The amazing thing is this all happens really at the speed of light and. Okay, a perfect example is Robert is literally half a world away from me, and I’m talking to him through a browser, and I imagine that there is the most fractional delay between the words that I’m saying and him hearing it.

It’s probably like a thousandth of a second or something. And yet somehow that sound and that image is getting consumed by my camera. Traveling down a cable. Getting into my computer. The computer’s making decisions about, what the heck am I going to do with this? And then pushing it down a wifi network.

That wifi network is then thinking, where do I put this thing? And then it puts it there. That then decides to shunt it along somewhere else, which shunts it along somewhere else. And eventually it gets to Robert’s computer. Robert’s computer does all of it in reverse. Unpacks it rather than packing it up, and puts it on the screen. And it’s all happening like thousands of times a second, and it shouldn’t work.

[00:18:20] Robert Jacobi: It’s more live than live.

[00:18:22] Nathan Wrigley: Yeah.

[00:18:22] Robert Jacobi: Because not only do we have the video, we have a chat window on the side. It’s all encapsulated. Use some of these acronyms, but, we have our streaming protocol for the actual video and audio. And then we have our standard internet protocols for the content and everything else that’s holding the streaming protocols together.

It’s crazy. Why I’m excited to have this conversation with you is like, I feel, very anecdotally, but people are like, I’m just going to spin up a WordPress site. I’m going to be a WordPress agency. And they just do it. And there’s just all this stuff in the mix that, while it’s great to take for granted, it might help to know just a few of the pieces that are critical in that security portion of infrastructure.

[00:19:05] Nathan Wrigley: Yeah, it feels to me like a bit like you’ve been to a really nice restaurant and you’ve eaten a fabulous meal, and then you realize the 12 hours of labor that went into creating that tiny little sauce on the side or something like that. And you get real appreciation for it. And hopefully something like that will come out of this.

Again, caveat emptor, we’re not going to get everything right. Please feel free to give us a comment when we do get things wrong. But the OSI model is basically, it’s a seven layer stack and I think we’ll start at layer seven, because it sounds easier to describe it from the top down. So seven through one. And I’ll just say what all the layers are.

So they go from the application layer, that’s layer seven. Presentation layer is six. The session layer is five. Four is transport. Three is network. Two is data link. And then the final one is the physical layer. And this point, I completely stand back and say, Robert, tell us a little bit about the top one, and Robert puts his hands on his head, the application layer.

[00:20:06] Robert Jacobi: It’s funny, it’s like the top most layer and the bottom most layer are the, I feel, the easiest to like grok. Let’s use geek terms, to understand.

The application layers is as well as a WordPresser, I can explain. It’s really the top, you’re connecting from the client, your client application, so a browser, email, whatever, with specific protocols.

And what we primarily use is TCP IP, because that’s that magical thing that is able to grab a bunch of information, split it up into a billion pieces, and somehow put it all back together. How are we communicating with other devices is the way I look at that layer. It’s very high level, very abstract, it’s sort of fundamental. It’s like the air we need to breathe to actually get stuff done.

[00:21:00] Nathan Wrigley: It’s the layer, if I’m correct, it’s the layer closest to us, the user. It’s the layer which we can most readily understand, because it’s the layer closest to which we do things. So I think maybe a poor example, or an incorrect example, would be to imagine it’s something like Microsoft Word or something like that. Because it isn’t, the application itself isn’t that layer. It’s more how that interacts with the protocol underneath. So it might be HTTPS or FTP or something like that. But you are writing an email or something like that, and you hit send, and then the application layer gets in the way and says, what do we do with this?

[00:21:38] Robert Jacobi: Bingo. That’s exactly it, so we use all these, and generically they’re just called clients. So whether it’s Word, Microsoft Word, whether it is Safari, whether it’s Chrome, whether it’s Apple Mail. This will only entertain a few people, or Eudora mail. Just taking it back. Those are discreet applications on our devices.

And then the application, to your point, you hit send, you hit go on your browser. And now we’re like going crazy, okay, what do we do? We have a request. A request needs to go somewhere. That’s where the application layer kicks in.

[00:22:11] Nathan Wrigley: So we have this protocol in the application layer, which then makes decisions about what to do. And each of the layers is collapsing into the layer below it. And that layer then takes something that the previous higher layer gave to it and does, some shenanigans with it, and we get something which can then move into the layer below.

[00:22:30] Robert Jacobi: Everyone knows the application layer, because we’ve all typed in HTTPS://. That is literally the application layer request.

[00:22:40] Nathan Wrigley: Okay, so in the case of a browser, it’s the capacity for the browser to send something through HTTP, what have you. And then we get into the presentation layer, which is the layer beneath. And I think, again, I’m just cribbing from this article, if I’ve parsed this correctly, it says that this layer comprises things like translation, encryption, decryption compression. And it turns all of the bits and pieces into machine readable data. So for example, it says it will convert all of the binary ones and zeros into machine readable data. If the devices are using a different communication method, the presentation layer translates that data into something understandable, so that it can be received from layer seven.

And there’s a lot more to it than that. It’s like this layer of converting what came to it, into something else, which can then be moved down the stack into five.

[00:23:34] Robert Jacobi: Bingo, that’s literally exactly it. And it’s something us as humans completely don’t interact with unless you’re the person building out that infrastructure. It’s really just we’re having computers talking to computers at this point. So when you typed in HTTPS WP Tavern, that was your human interaction. Now we’re all like, what is the process? So presentation is making sure that that data moves forward the stack.

[00:23:59] Nathan Wrigley: And my understanding as well is that this is the moment where encryption and decryption occur. And so it’s high up in the stack. That is to say it’s near the layer seven, because you obviously can’t have it encrypted before you do anything with it. It’s high up in the stack so that at this moment, before it’s gone anywhere, it has become encrypted, before it’s passed down the stack and sent down the wires. But also, this is the moment if it’s coming up the stack, towards you so that you can read it in your browser, so that it’s getting decrypted at the last possible moment as well. So the encryption, I guess is at the first possible point on the way out, and the last possible point on the way back in. Have I got that right?

[00:24:40] Robert Jacobi: Yeah, and that’s a great way to look at it is, when we look from the top of the stack to the bottom of the stack, it’s almost in physical proximity to you as the human end user.

[00:24:48] Nathan Wrigley: Yeah.

[00:24:49] Robert Jacobi: Because at first you’re typing in something. Now something’s happening, that encryption is happening locally, because otherwise it wouldn’t be safe. And as we get further down the stack, you are physically further away from what’s going on.

[00:25:02] Nathan Wrigley: Yeah. And the other thing that’s going on here is compression. So you’ve got some giant blob of data that the stack can compress to make it more efficient to fly over the wires, then that will be handled at this layer as well, is my understanding.

[00:25:17] Robert Jacobi: We have compression on the servers as well in the applications layer as well. Don’t forget, you can compress data on the protocol.

[00:25:22] Nathan Wrigley: So that all sounds really remarkable, but also quite humanly understandable, because everything that I’ve said makes perfect sense. And we start from five down. It starts to be really the domain of networking experts, and people who really obsess about computers and understand this stuff. But if you’re just the person using the web and WordPress casually, honestly, it may be that you’ve never come across this stuff, and I found it just breathtaking, to be honest.

So layer five, is called the session layer, and it is literally that. It’s managing sessions, so it’s figuring out who’s connected to who. How that communication should begin. How it should end. When it’s decided that, okay, that connection should be destroyed. We’re not using that anymore, but okay, now we’ve got something else that we need to do. And it figures out, yeah, sessions basically, which I guess is the easiest way to describe it.

[00:26:15] Robert Jacobi: Everyone knows what a session is. It’s me being connected, and my information being managed for me, so that when I log in, Nathan doesn’t get all my information.

[00:26:24] Nathan Wrigley: And also, an understanding here is that usernames and passwords, so authentication is happening at this layer as well. And again, that kind of makes sense. So you would have to authenticate before the decryption happens in the layer above and vice versa. But yeah, this is opening up connections between, in this case, you and I are chatting in a browser, so we’re occupying one session, and then there are million, literally millions of packets of data just flying around over the internet via who knows what route. They’re all going in completely different routes.

[00:26:57] Robert Jacobi: Some of these packets can literally be going through Australia or South Africa or Brazil, and back and forth and they, catch up.

[00:27:05] Nathan Wrigley: Incredible, isn’t it? Literally. It’s like, I don’t know. Imagine getting a handful of rice and chucking it all down on the floor, but it assembles itself into a tower. It just lands and it just assembles itself. That’s basically what we are dealing with.

[00:27:19] Robert Jacobi: That’s a good one. Yeah, like I have my own rice tower at home. I throw it on the ground. It gets shipped by FedEx to you, but when you open up the box, it reassembles itself.

[00:27:28] Nathan Wrigley: Just in perfect condition, yeah. So the next layer four, is the transport layer. And this is the bit which actually I guess begins the process of sending my stuff to you, and your stuff to me. And typically the protocols for that are something called UDP, which is User Datagram Protocol or TCP Transmission Control Protocol.

And my understanding, which is very basic, is that UDP differs from TCP in that UDP can be more of a stream of data, because it doesn’t require everything to come through perfectly to say, yeah, that’s now finished. So a perfect example would be us talking to each other, streaming. If bits get lost along the way, it doesn’t want to say, right end the call.

We haven’t got one bit. We need to just stop. Until that bit has been found, it just keeps going and just disregards the missing bits. Whereas TCP, this is just incredible. This is the rice tower, isn’t it?

[00:28:28] Robert Jacobi: TCP is the rice tower, exactly.

[00:28:30] Nathan Wrigley: It requires every single piece to be sent. Acknowledged. Counted out. Counted in at the destination, and for the both ends of the connection to be saying, did you get that bit? Yeah, I got that bit. What about this bit? Did you get that bit? Yeah, I got that bit. 23, did you get 23? No, 23 has gone. Where, where’s 23? Oh, I’ll send 23 again. Here it is. A million times a second for this conversation that we’re having. Well, it’s probably not a million times a second, but you know what I mean.

And I’ve summed that up very badly, but these packets of data that are flying around. They egress my computer. They go through 7, 6, 5, now we’re in 4, and they’ve got to go through further layers. But they’re not just going in a straight pipe, like a hose pipe from your faucet, spraying the garden. These are just going anywhere they choose. So one packet, like you said, might go via Australia, one might go through South Africa, and then somehow they just reassemble themselves magically at the other end.

[00:29:26] Robert Jacobi: Routers, because that’s what those do. Obviously that’s a physical component further down the pipe. They’re saying, this is the order of information. I’m going to just spew out, and everyone else needs to figure out how to put it back together, one piece. It’s crazy.

[00:29:38] Nathan Wrigley: Yeah, it is crazy. My understanding is that back in the day, when the internet was conceptualized, I think it was possibly something like Darpanet, or something like that, but it was a, I think it was a military endeavor, the enterprise was something along the lines of, we need a communication system which if various nodes are taken out, let’s say, I don’t know, bombed out of existence, or just the power is cut, the system is intelligent enough to just work round the problem, and figure, okay, we can’t go there anymore, let’s just go a different way. And that is what we now have.

[00:30:12] Robert Jacobi: It’s all about redundancy. I’m going to take just a slight tangent on federated social media. Any kind of federated application. Those exist in a lot of ways to ensure redundancy. I’m going to go way, way back, to where most of the audience probably wasn’t born. So we had these things called modems, and they would be attached to a phone, and you would run something called a bulletin board system. Those were single points of failure.

So you actually saw groups of independent bulletin board system providers create these distributed federated networks. So if you sent an email to a specific person, at a specific BBS, if that phone line was busy, it could go to another one that would take it, and keep pushing it along until you actually got it to the right place. This idea of distributed and federated systems is really what makes the internet functional because we take care of failure points. We ignore them and just work around them.

[00:31:17] Nathan Wrigley: And obviously we know that works as well because parts of every country’s infrastructure are breaking all the time. One router somewhere will just go down, even if it’s a crucial router, it doesn’t in the end stop the system. It probably creates bottlenecks in various places.

[00:31:31] Robert Jacobi: Slow it down.

[00:31:32] Nathan Wrigley: Slow the egress of traffic around, yeah. But in layer four we’re dealing with the ports that things fire out of as well. And then when we get down to layer three, that’s when the actual data is divided up into little packets and little segments. So data four and data three, honestly, to some extent they feel very similar in my head at least anyway.

But layer three is using things like IP addressing, to decide where this packet’s going to go. And I think wraps the packets up in the IP address, if you like. It’s almost like wrapping up a Christmas present and as it travels down the stack, by the time it gets to layer three, it’s being told, this is not what it’s being told, but this encapsulates it. This is a gift for Robert Jacobi. You must find Robert Jacobi.

Then it reads that, and then finally, it’ll rip off the wrapping and finally give you the gift at the end as it goes back up the stack. So, there’s not a lot to say on layer three, I don’t think, other than it’s using things like IP v4 and IP v6 to make decisions about how it’s going to be spread around. Have I got that about right? Do you think?

[00:32:35] Robert Jacobi: That works for me. I think that’s enough information for most folks. Again, we’re trying to give a taste of how complex security is, for what we do day to day. But also how we can apply it to how WordPress understands it.

[00:32:48] Nathan Wrigley: And then we’ve got the two layers where, the data link layer and the physical layer. The data link layer is handling the data transferred. So the actual data moving around. So it’s getting pushed around on the same network is my understanding for layer two. So that’s when you are, for example, in the same office building. I think layer two is just for that. I could be wrong.

[00:33:11] Robert Jacobi: It’s getting to your router and then your router will start moving stuff around. Cause don’t forget, your router is on your network as well as any other computer in that closed. So, our 192’s. Our internal network, so that’s the closest on the networking side, that hardware side, because as soon as it hits our router it goes to the cable, or whoever you’re using, outside of your office, home, your LAN.

[00:33:35] Nathan Wrigley: And then the final layer, the physical layer is the cables, the actual infrastructure out there in the world outside of your house, basically. Or your office building. Well, maybe there’s some of it in the office building as well, but the majority of it, the miles and miles of things are all in the physical layer. And it says here on the bit that I’m reading. Finally, this layer encompasses the equipment that carries data across the network, such as fiber network switches, and so on.

And so finally, our packets of data that we started off at the beginning, writing the email to Robert Jacobi. Finally, that packet has made it out. It’s escaped into the wild, and is now just rattling around on the internet desperately being told, very quickly, where to go. And then hopefully it’ll arrive. Travel to Robert’s computer. Travel in the reverse direction of the stack, and he’ll get a nice email from me with cat pictures in it.

[00:34:27] Robert Jacobi: Why is it always cat pictures?

[00:34:29] Nathan Wrigley: Why not? Okay, so all of that shenanigans is happening, and honestly, I feel a, it’s very difficult if you’re inexperienced like me, to get the words out in the correct order so that I have demonstrated that I understand it. Because I do on a very, very slight level.

And I know that entire careers, very, very, well paid careers can be built upon really understanding what we’ve just spoken about. But in there, I presume, is the capacity for threats, and the capacity for things to go wrong, and the capacity in all of these layers for people to inject things which shouldn’t be there. For clever people to figure out ways to disrupt that information. To take that information. To delete that information. To rewrite that information. And is that essentially what your company does? Prevent those things?

[00:35:18] Robert Jacobi: So when I look at it from a CMS stack, and again, let’s focus on WordPress. My mental model that is slightly different. I’ll use, I think what most of us feel like is WordPress infrastructure. I know, the really smart folks are going to yell at me for this. You have a server somewhere. It has an operating system, it has PHP, MySQL, it has WordPress, and then whatever else is in front of it.

So there’s a whole stack and layer on layers of communication that go from when I hit my browser and type in WP Tavern and hit go. And let’s move away from all the really highly technical networking protocol issues.

At some point, it’s going to make a request to a hosting company that needs to be able to say, oh, yes, let’s give them the WP Tavern homepage. In that process there are caching services, firewall products, local security on the networking side of that hosting company. What I feel personally, but also which is what makes products like Black Walls critical is, detect and defend as far away from the website as possible.

So if there are a million bots coming at you, get them before they even hit the hosting company’s infrastructure. Some will always sneak through because it’s a battle that’s just never ending and, you’re going to keep learning and fighting and learning and fighting. Mitigate the risks as close to the bad actor, and as far away from the site as possible. So, mitigate, mitigate, mitigate, mitigate, mitigate. And there are tools and solutions up and down that entire stack.

So you’re going to have stuff way before you hit the hosting company. You’re going to have some solutions closer to the hosting company. You’re going to have solutions directly on WordPress. There are security plugins that are running on your install of your site. Those are great. I personally feel that you don’t want to even get that close if you’re a bad actor. Mitigate that problem as quickly, as soon as possible.

And even solutions that work at the operating system level, or at least the language level. There are products out there that are constantly monitoring, looking for and mitigating PHP corruption. So, you really don’t want to let everyone have access all the way down to that level, because then you’re already, you will have problems, how to put it nicely. We don’t say bad words on the show.

[00:37:53] Nathan Wrigley: So do you sell your product into the WordPress space? So, you know, to freelancers, agencies, or are you more at the hosting level, or is it even more like infrastructure level? So at the router level. So in our case, this sort of physical layer that we were talking about. Is that the kind of place where your products go? I honestly don’t know where your product sits in all of that.

[00:38:16] Robert Jacobi: So, if you look at it from a hardware perspective, there’s going to be the end user is going to make request. It’s going to get routed somewhere. We sit between where it’s getting routed and the hosting company. So our goal is to prevent the hosting company from wasting physical resources. Now we need to amp up our service because there’s so much traffic coming in.

Now we need to amp up our customer support because more stuff is happening with our virtual machines or hosted infrastructure. So that’s our place in the universe. Get the bad guys before they get to the critical infrastructure.

[00:38:51] Nathan Wrigley: And another question, forgive my ignorance. Is Black Wall’s solution, is it software? Is it code that sits on an operating system? Or maybe you even have hardware that sits in the way of things, the packets have to transfer through your hardware and be inspected in a way, like a router might get in the way of those things.

[00:39:10] Robert Jacobi: Our secret sauce is that we are software that emulates the hardware that used to be required. So there are hardware companies buy this kind of routing and prevention, traffic mitigation. And we do it on the software side so that you as an agency or MSP, if you’re running a bunch of virtual machines, you can deploy this on your own. Certainly as a hosting company, you can deploy this across your entire enterprise.

[00:39:36] Nathan Wrigley: So you are dealing with very technical, the people that purchase from you they’re not me, for example. They are very technical. They’re in the data centers. The sort of technical end of the hosting companies. They understand what I’ve just butchered during this episode.

It’s not like a freelancer market. You will not be selling Black Wall as a plugin. You are dealing with, directly with hosting companies and the tech side of those hosting companies.

[00:40:01] Robert Jacobi: There’s a wonderful German word called Jein. So yes and no.

[00:40:04] Nathan Wrigley: Oh, that is a good word.

[00:40:05] Robert Jacobi: For all the Germans listening. You still want to be able to control a lot of times exactly what kind of traffic comes in. You might want to get scraped by AI bots more than someone else does. Or you might want to turn off all scraping if you’re an e-commerce store and you’re worried about people taking your pricing and not allowing you to sell at your level.

We’ve had, and are currently reworking our entire WordPress plugin, to enable that end user control of that infrastructure. So it’s not running on your WordPress install, which is great because it’s not taking up resources, filling up your hard drive. But you can control, as an end user, the granularity of the traffic that’s able to access your site.

[00:40:45] Nathan Wrigley: Oh, so you have a plugin, so you are reading what the hosting company is doing. You can view it through a GUI on your WordPress website, but you are not actually, it’s nothing to do with your WordPress install. You’re getting the data from your hosting company, and that is another layer away from you. Okay. That’s interesting. I didn’t realise that.

[00:41:04] Robert Jacobi: Yes, it empowers all these website owners, agencies, MSPs, to fine tune, for lack of a better term.

[00:41:10] Nathan Wrigley: Yeah. And then do you offer a sort of GUI for data breakdown, tables, graphs, charts, and ways to block things that you imagine are suspicious, and alerting and things like that?

[00:41:20] Robert Jacobi: Yep, as well as defaults for all sorts of things of course, just to make life easier for folks. You can go and visit our site and get some initial monitoring for your site for free. We enjoy having that as part of just an offering of the reporting and monitoring, you can see it. My traffic has been great, and then all of a sudden you look and it’s oh wait, it’s just been Chat GPT.

[00:41:40] Nathan Wrigley: Sad realization that the million visitors that seemed to be going to your excellent article were in fact Chat GPT.

[00:41:47] Robert Jacobi: Bots stealing that information.

[00:41:49] Nathan Wrigley: Sadly, time has got the better of us. We’re at the time where Robert has to walk away. I know he’s got a hard stop. Firstly, my apologies, dear listener for utterly butchering the OSI model. I’m sure there’s a lot of geeks out there who were just throwing things.

[00:42:01] Robert Jacobi: They’re going to kill, but my hope is everyone looks it up, a lazy Sunday afternoon understanding.

[00:42:06] Nathan Wrigley: Exactly. And that, really was my capacity to understand it. Doesn’t matter how much more I read it, I will be able to get no more out of it. But an important conversation, and one that we’ve never had before. We never get into the weeds of all of that. It’s always WordPress all the way down.

And this is what’s happening before, WordPress gets to put the bits and your screen. So really important and hopefully, like Robert said, it will encourage people to go and have a little look.

Robert Jacobi, thank you so much for chatting to me today, and good luck with the new rebranding of BotGuard into Black Wall. I hope that goes well too. Thank you so much.

[00:42:39] Robert Jacobi: Thank you Nathan.

[00:00:00] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, creating a successful business in enterprise WordPress, and working to foster the WordPress community.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice. Or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox, and use the form there.

So on the podcast today, we have Rahul Bansal.

Rahul is the founder and CEO of rtCamp, a large agency that specializes in enterprise grade WordPress projects. He began his journey quite differently, starting as an individual blogger back in 2006, discovering WordPress in 2007, and gradually transitioning from being a publisher to a freelance developer, before founding rtCamp in 2009.

Today, rtCamp is an enterprise grade WordPress consultancy agency operating globally and trusted by clients such as Google, Meta, Automattic, News UK and Al Jazeera.

Rahul sheds his light on working with enterprise clients in the WordPress space. Many of us are familiar with WordPress in the context of small businesses and blogging, but the enterprise space demands additional layers of security and scalability. Rahul explains the factors that set enterprise projects apart, and why meticulous code reviews, and security audits are essential when working at this level.

He talks about the opportunities in the enterprise space, recounting how rtCamp initially stumbled into enterprise level projects, not even realizing their potential until a client’s high expectations led to a decision to market themselves as an enterprise agency.

We also discussed the role of WordPress in enterprise environments, from why Gutenberg has become a credible selling point due to its powerful editing capabilities, to how the platform’s flexibility supports varied enterprise needs.

Rahul also gets into the importance of positioning. How historical context offers advantages, and the expanding market that makes WordPress a compelling choice for large clients today.

Towards the end, we explore rtCamp’s innovative intern program, aimed at growing the WordPress talent pool, and the way they’re contributing back to the WordPress project, a win-win for the business and the broader community.

If you’ve ever considered what it takes to work with WordPress at the enterprise level, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you, Rahul Bansal.

I am joined on the podcast today by Rahul Bansal. Hello.

[00:03:47] Rahul Bansal: Hello.

[00:03:48] Nathan Wrigley: It is very nice to have you on the podcast today. We’re going to talk about the enterprise, which I confess is something that I only really know about because people talk about it. I’ve never worked in the enterprise, I’ve never worked with enterprise clients. So Rahul is here. He’s very much in the enterprise as you’re about to find out, and he’s going to educate me all about that.

So Rahul, I wonder if you wouldn’t mind just for a minute or two minutes, just tell us who you are, what you do in the WordPress space, where you work, your position there, and so on. A little potted bio.

[00:04:18] Rahul Bansal: Currently I am founder and CEO of rtCamp, which is a large agency specifically dealing in enterprise grade WordPress projects. I started quite differently, like I started as a individual blogger, back in 2006.

In 2007 I found WordPress. I started developing with WordPress in 2007. And slowly from being a publisher, I become freelance developer, and then around 2009 rtCamp started. So I’ve been with rtCamp for the last 16 years.

[00:04:46] Nathan Wrigley: That’s been quite a journey. I see the name rtCamp everywhere. And we should just say, so it’s spelt, lowercase r, lowercase t, and then Camp with a capitol C, a m p. Go and Google that, and have a look at what the team over there doing.

How big has the team grown to? How many employees, staff do you have over there now?

[00:05:05] Rahul Bansal: So currently we are 230 people, all spread over.

[00:05:08] Nathan Wrigley: That is truly an enormous agency. So bravo for growing that. That’s really incredible.

The first question that I want to ask though is, when does normal WordPress become enterprise WordPress? At what point do we cross the Rubicon where a site is, I don’t know, big enough, or your agency is working with a different type of client? Can you define what you think that means? And I’m sure that if you’re on the cusp of being an enterprise agency, this is something that, you know, may be slightly confusing.

[00:05:37] Rahul Bansal: Firstly, there is no formal definition to that. Many agencies believe they’re serving enterprise space when they’re not. Some people are actually serving enterprise space, but they don’t realise it.

So in my opinion, it’s where the requirement changes a lot. Like, for example, if we’re building a small WordPress site, which I don’t consider as an enterprise site, we will be tempted to pick first theme and plugin that matches our need, like if it works, if it gets a job done, that’s it.

But then in enterprise space, there is a lot of security and scalability concerns. These two concerns are very big. Something might be working all right, but then when you look at the code, you realise that there’s going to be a security issues, or there could be scalability issues. Many times, indy developer person, they design small WordPress plugins. They don’t have data or big enough site to test it on a large installation. So those things are not tested on really high traffic website. So enterprise can mean really high traffic website, with a lot of scalability requirement.

On the other hand, the traffic can be less, but the security requirement can be enormous. Consider the White House website. It was on the WordPress with the previous administration, and it’s again, on the WordPress with the new administration. So in both cases, I don’t think White House, like a website we can classify as a very high traffic website, but it is a very sensitive website.

It would be a lot embarrassing if that site gets hacked. So every piece of code that goes into White House website, which agency is working on it, will be thoroughly checked for security attack, for audit, for all the compliances. And this additional efforts is what makes it enterprisey, in my opinion.

[00:07:12] Nathan Wrigley: Okay, so it’s not necessarily the size of the client, or the fame, for want of a better word, of the client. It’s more about the kind of work that you’re doing in the background. So custom code largely, because you simply at that scale cannot have something off the shelf.

[00:07:28] Rahul Bansal: So we can have things off the shelf. The thing is, you cannot just take it and use it. You still have to own it in that sense. Like, for our clients also, we go and use many things from WordPress plugin directory. But then when we put it on this website, it is kind of like signed by us. So it’s like we have to verify, even if it is not coded by us, we have to verify line by line that it is following best coding practices, database queries will scale with high traffic, if it is a high traffic website.

There are many checks and balances in place. So no matter if you are doing in-house, like as a custom coding, or we are buying a premium plugin or using a free plugin, everything has to go through certain checks. And those checks are very expensive to do, because that’s a human labor. You have to literally go through things line by line. And in many cases, you have to put extra efforts to make it scalable with their existing system.

Because usually a large enterprise won’t use just a website in silos. It’ll be part of multiple system like authentication system, where if an employee joins a large organisation based on some rule, they might get automatic access to their website. Likewise, if they leave organisation, their access should be automatically revoked, or they have some CRM integrations, data integrations, some kind of asset, like digital asset management solution integration.

So all these have to be connected, and this all need to work together. So a lot of effort goes in doing these extra things, which are either don’t exist for small websites. So, enterprise website that I’m talking about, this can be really unknown website. We have a client which is basically a government public origin fund. Common people don’t even know about them, but they basically want pretty much all the big companies we know. Like, they have stake in all the big companies. Their asset is something like $400 billion in under management.

Most people don’t even know that company. But then it’s very sensitive because that money they’re managing is public money, it’s not like VC fund. It’s actually state reserve. Now, seriousness, we need to demonstrate in the security is very high, because if something gets hacked or somebody uploads the wrong investor report or something like portfolio report, it can have a lot of consequences.

[00:09:32] Nathan Wrigley: It kind of sounds to me as if the assurance that you are giving an enterprise client is basically that what we’ve built is, as far as we can tell, it’s bulletproof. We’ve gone through it line by line. We may have custom coded bits and pieces, but certainly the bits that we didn’t custom code, we are totally guaranteeing that this is going to be robust.

And also it’s sounds a bit like, if a client at an enterprise level approaches you and they say, can you do this? Your answer is yes. Basically, yes, we can do it. We can do it with WordPress. There may be a cost, but we can do it. There’s almost no scenario where a client would come to you and say, can you do this, forget the money, can you do it? The answer’s never no. The answer’s always going to be yeah, yeah, we’ll figure it out.

[00:10:15] Rahul Bansal: So that’s the thing, like if the budget has no limit then there is no limit on technology. Most often, like even where enterprise agency, WordPress has this large spectrum. So we end up with a lot of low quality leads, where somebody knocks on an enterprise agencies’ door and they really have budget constraint. They really want something really good out of the box, but they don’t want to pay for it. Or they don’t want to pay as high as it’ll require to deliver that kind of solution.

For some enterprises, budget is no limit, but then we try to be mindful of resources. For example, many enterprise agencies, including us, if you go to their GitHub account, they would have list of published themes and plugins. Most commonly plugins, themes rarely are used off the shelf. So we will build these plugins to ensure that the cost of rebuild project is less, like if we have to deliver another project, we try our best that we reuse as much as possible.

And that’s the open source spirit, that the entire WordPress committee follows. We use many times solutions that are already put in open source by our competing agencies. They also use our solution. So that’s where the enterprise solution with WordPress is also affordable. The right enterprise client that we target, usually have higher budget than we would need to develop because we are competing against a lot of experienced managers, which are very expensive, super expensive.

And when I is super expensive, I’m just talking about licensing fees. Before you hire an agency to write custom code for you, you have already paid a lot of money just for the right to use the software. With WordPress, that right to use costs zero. And then all the nice agencies in WordPress space, big, small, no matter what size they are, try their best to reuse existing solutions, to bring the cost down.

So enterprise WordPress, relatively, cost less than other enterprise CMS, but then it certainly costs a lot than building a small website. Like, you cannot go to an enterprise agency and expect in $500 your site to be built perfectly, because the requirement gathering phase, like talking to all stakeholders and understanding all the solutions they use inhouse can take like many days.

[00:12:15] Nathan Wrigley: So you may have answered this question just now with what you’ve just said. I feel that you’ve definitely gone into this territory, but it sounds like there’s a lot of line by line checking of everything. So for example, if you use a plugin off the repo, you’re going to go through that one line at a time. And you said this can be an expensive process. You’ve also said that obviously there’s benefits of using WordPress because you can take things that other people have used and so on.

But I guess at some point there’s got to be some sort of tipping point where you think, okay, WordPress is going to be good for this project, but it might not be good for that project. Is it always WordPress for you? Do you always lean into WordPress, or does there come a point where you say, do you know what, with the custom things that this particular client wants and what have you, lets just build the thing ourselves, let’s not rely on the CMS, or do you always lean in on WordPress?

[00:13:01] Rahul Bansal: Maybe it’s the nature of our positioning that we rarely get things that we cannot do in WordPress, so we always do things in WordPress. The boundary varies with how much off the shelf WordPress we’ll use, and how much custom we’ll use. In one of the project, I remember there was a specific data crunching process that we needed to build. And we felt that it’ll be better if it is built as a microservice and run independently.

So we built that in Python, but then it was talking to WordPress REST API. So that freedom we have from client, for example like that microservice, that microservice was never visible to any of the client’s editorial team. Everything they were doing, their only interface was WP admin. There was no second login or no second interface to them. It was just something was running on some server and magically data was going inside and outside WordPress.

And that’s the power of WordPress. It has so many APIs to communicate with outside world, like rest API, GraphQL, and even from the traditional XML-RPC. That WordPress can coexist with other systems very nicely. And that’s where we never face that, can we do this on WordPress or not? It’s like, can we do everything on WordPress, or do we need to put some minor things outside WordPress?

And those decisions are not the engineering limitation. Like, that microservice, we could have put it in WordPress also, but we felt that its architecture was more suited for independent microservice. That was the right call, it turned out to be right call. Much later that microservice grew independently.

[00:14:26] Nathan Wrigley: If we rewind the clock to the beginning when you were just beginning with WordPress and beginning the agency that ended up being rtCamp with your 230 odd employees, did you intend for what’s happened to happen? Did you always know that you wanted to grow something to the point where it became, air quotes, enterprise with many, many employees, or did it just evolve over time unexpectedly?

[00:14:49] Rahul Bansal: Yeah, it all happened unexpectedly. Like, I started as a professional blogger. I used to make money from advertising, affiliate marketing. So it’s like, I wasn’t doing anything remotely related to agencies.

So one thing led to another and then I started freelancing. Then even after freelancing, when I started rtCamp as an agency, because I was coming from bloggersphere, most of my initial client were bloggers, like independent bloggers. Somebody wanted a theme, somebody wanted a plugin, somebody wanted a sidebar, which sidebar just used to be a lot more popular in those early days of blogging. Like, people used to have MySpace, like experience on the web, like lots of widgets, email submission form, this pop up.

So in fact, the first enterprise client that walked into our door, that’s why I said like many agencies don’t even realise when they mingle with enterprise space. I kind of felt very irritated because they asked so many questions. They got our reference from LinkedIn. We had zero, we were not even using enterprise word anywhere in our branding, marketing, anywhere at all. But back in 2010, also, we made a good name for ourselves.

So anybody who shouted, hey, any WordPress references, our name used to pop up on social media. So we got that. And they sent us a very large procurement checklist, which we never heard of. All of our projects were like email exchange, two, three emails, money via PayPal, and emails used to be contact. Like, whatever you committed on email is the contract.

And suddenly there comes like this long PDF, Excel sheets with check boxes. Do you have a data storage policy? This policy, that policy. If we end up filling this, we’re not going make any profit with this project. So then one of my teammates said, let’s price in that. Let’s price in and see if they can afford it. So we literally added another zero to our pricing, literally like 5 times, 10 times. And we said like, hey, this is our minimum, do you want to go ahead?

I said, sure, like this is peanuts. And they were worried like, do you understand the project? You are quoting very less, your starting point is very less than our internal budget. So they came to our office, they were based in India. Luckily they were in the same city. They came to our office to audit us physically. They put like remarks like, you don’t have a fingerprint scanner in your biometric sensors in your office entry. There is no employee log.

But we are not storing any of your data. So this office is not the building where your data will reside. Your data will reside on AWS, or all those cloud servers. And then they got convinced. WordPress was very small then, and we were the only known agencies, which was fully committed to WordPress at that point. So they didn’t have choice two, three, so they kind of crossed the fingers and gave us that project.

It took six months to close. I was very pessimistic. It’s only after two, three years that we realised that they’d become our largest client by a huge margin. All my blogger friend put one side, and this single client, one side. And that revenue was growing very nicely, year on year. Renewals, they had this retainers, every year they were renewing without asking questions.

So I realise that it’s very hard to win these big clients, but once you are in it becomes very smooth journey, henceforth, like after that point. And then I think 2014 around, after two, three years data, when I saw that this client was consistently, for the last three years in a row, our biggest client. Zero sales effort, zero account issues, no negotiation on pricing, and everything was smooth.

So then I thought like we should go in to some enterprise space, and luckily around that time I had a call with Chris Lema. Chris Lema used to be available for consulting calls on Clarity. I’m not sure if that service is still around. And I still remember it was exactly 33 minutes that I talked to Chris. He repositioned rtCamp. In 33 minutes he gave me some amazing breakthrough idea.

And after that call, first time we told ourselves, we are enterprise WordPress agency from today. Until 2014 we were not identifying ourself or branding ourself as an enterprise workplace agency. That moment was the first time when we put in bold letters on our homepage, in SEO Meta, everywhere we added, we are enterprise, enterprise, enterprise WordPress.

[00:18:35] Nathan Wrigley: Can you remember that moment? So if you cast your mind back, when you added the zero and sent it, and there was obviously some suspicion in your mind that nothing’s going to come of this or what have you. Can you remember the feeling? So it’s an odd question because I’m asking you about your feelings, but can you remember the feeling when they came back and said, oh yeah, this is not as expensive as we’d imagined? That really must have opened up an entirely new world for you.

[00:19:00] Rahul Bansal: Yeah. So firstly, it was very unexpected because we were selling like WordPress projects for $100, $50, $500. The biggest was $1,000. We still remember we built a complete BuddyPress plugin for $900. And we were like so happy when that client sent us $100 tip. He rounded up to $1,000 and we were partying, like with that extra $100, we throw a party to our team.

And suddenly this client comes and they said, $5,000 is okay? Are you kidding me? Because they sent so much data I didn’t want to fill in, so I just thought, let’s just give them a number and they will walk away. We’ll not appear as a company who didn’t want to fulfill their data request. I thought, I will give them a reason to walk away, but then it didn’t walk out.

Initially I was still skeptical because they really demand too much data. Just imagine, we were like some 20 people agency at that time, and we spent three to six months in back and forth sales call. We didn’t have typical sales team at that point. Writing those long answers. We were not even understanding questions. The problem was not that we didn’t want to give data or we didn’t take security seriously, there were things that we never heard of.

It was all like foreign language to us. What are they asking? Why do they want to do that? I was not expecting lifetime revenue, that concept was not in our books then. So it was project, money in, money out, end of email, site goes live. Then the recurring revenues hosting companies. We were not into selling maintenance contract.

So it was a project kind of thinking like big, big economy mindset. So even with 5,000, I thought like, the amount of effort they’re putting us, we won’t be left with any decent margin after this project. And that was a true case. For first year there was not much margin left because they had put us through a lot of work to fulfill that project. And then we realised we underquoted after that also, because when the data, we had to talk to their Microsoft vendor. They were using Microsoft SharePoint. There were many rough edges that we had no idea could happen to us.

In year one, they were the highest revenue, but project was in loss. It’s only a year, two, three, it was very good profit. And then we have the strategy that we call now land and expand. Land big accounts, no matter whatever price point you wanted to do, go aggressive, and then once you are in, then you spread within the organisation.

[00:21:08] Nathan Wrigley: Oh that’s an interesting insight. So land and expand. Land the client, the big fish, if you like, with the knowledge that if you maintain the relationship over many years, the profit can build up. Not necessarily year one, but maybe a bit in year two, and year three, and year four, it’s beginning to mature.

And, it sounds like such an interesting story. And, again, I’m going to rewind back to before 2014, so before you added enterprise to your website and have you. Do you think if you had begun your journey today, that you would have the same capability to expand in the same way? Because it feels like there are now quite a few players. Perhaps when you began that was less of the case. You were competing in a much less crowded marketplace.

But it feels like everybody’s intent now is to become an agency which can call itself enterprise. And I’m imagining that you got your foot in the door at a really nice time where you became a name that everybody could trust, and the recommendations come in because of prior work, but maybe that would be more difficult now.

[00:22:08] Rahul Bansal: The market is much bigger now. In fact, just imagine WordPress market share. When we were building the first initial websites, there was not even custom post types that were present in WordPress. So all the WordPress plugins, we used to do a lot of hacks. There was not standardisation. So a lot of things happened with WordPress as a platform. WordPress evolved. The market share has become so big. It’s easier to sell. We have so many examples like from White House to large publishers. And globally, it’s not like just the American companies are using WordPress. India’s second largest publisher also uses WordPress. So does Al Jazeera in Qatar.

So there are many big websites all over the world so it makes WordPress easy to sell. The market is big. There is a precedence where you can pitch somebody, this is WordPress used by so and so. I believe that no matter which lead you are dealing with, so if you have a lead from a certain industry, a certain geography, you will find a WordPress success story in their geography. You will find WordPress being used by your prospect’s competition. That makes it easier to sell WordPress.

So, yeah, the competition is more because opportunity is bigger. The pie is a lot bigger. Otherwise we would’ve stuck to the same size. Every year we are adding more people because we are able to get more work for them, even with these new agencies coming up. In fact, it’s easier to build WordPress agency, or any kind of enterprise grade agency now, because the recipe is quite clear. Because we can look at how other agencies are doing and you can take some lessons from them.

At that time we had no idea. Like, in fact, we didn’t have the idea that we should position ourselves enterprise grade agency, that was the call with Chris. Before that call, we had no idea that we should be labeling ourselves as an enterprise grade agency.

[00:23:42] Nathan Wrigley: If clients approach you, and it sounds like this may not be the case. It feels like people are approaching you because you build WordPress, not inquiring whether or not you would do a WordPress project for them. What are the one or two bits that you always bring out when a client says, well, why would we go with WordPress? What are the one or two top line items which you think, okay, if we’re going to build you a website, we’re going to choose WordPress, and here’s the best reasons at enterprise? So we’re not talking about a mom and pop store, that it really doesn’t matter if it goes down a bit. What are the one or two things which you bring out when an enterprise client wants to know why WordPress?

[00:24:18] Rahul Bansal: First we want to reassure them that WordPress is the right platform. So this is a difference between a product company and agency. A product has a landing page, which is more similar, it gets us to a lot of people. But an agency pitch is tailored for every client, every prospect. So our first goal is to find competition. So which are the competitors for this particular client, prospective client, and see if they’re using WordPress. If your competition is using WordPress, you will feel a lot more comfortable going after it, because nobody wants to be first, especially in large enterprises.

Another way we define enterprise is that, when you are not buying from out of your pocket. In a large organisation, your job is not to save the money or find cheapest solution, your job is to deliver result so that it can go very nicely in your annual review report. I still believe people, especially in enterprise, are looking for safety as a first because they know that they have budget to build anything under the sun.

So usually we say less like, WordPress can do this, WordPress can do that. Because for everything that WordPress or any platform doesn’t do out of the box, they have budget. What they need to know is that it’s secure, it’s safe, it’ll scale well. And if some government approaches us, so we show that public sovereign fund, that they’re managing. So that client has a special permission with us, like we cannot refer them publicly, that government agency, but we can refer them to other government agencies in private conversations. So that is how we convince like, okay, this is similar people to you who are using WordPress.

And I think safety is still the first thing that people are looking for because, it’s not even WordPress, it starts with open source. There is something, somebody did some marketing where people believe or have this misconception that open source will be easy to hack, because you can see the code, you can easily hack. That is our first step. If client mentions it explicitly, we go all in. Even if the client doesn’t mention it, if the prospect says that we are looking for rating interest, we still will verify. Are you sure that you are sorted on WordPress being safe? Any concerns, any doubts?

And then features, because WordPress has no match. And I’m not saying this as a WordPress agency. The Gutenberg editor itself alone is miles apart. If you go to any other platform, the editing capabilities are nowhere close to Gutenberg editor. Gutenberg editor demo itself is a deal breaker in many cases. We just show them Gutenberg editor, and they’re like, wow, is this possible? Is this thing real? Is this some mockup? No, this is website. After the call, we are going to send you a URL, go and try your hands on. This is no fake, that vaporware demo where you see something on my screen, but in reality it doesn’t work like that. This is the real website. Go and try it.

[00:26:53] Nathan Wrigley: That’s really interesting because in the non-enterprise, that message hasn’t necessarily landed. Gutenberg is, it’s very divisive issue, isn’t it? Whether you use it or not. And it’s curious that you are saying that it’s one of the key things which leads to the success.

Can you just dig into that a little bit? What are some of the aspects of Gutenberg which make the clients think, okay, this is great, this is perfect, this is just what we need? What are some of the features that you draw out of the block editor?

[00:27:19] Rahul Bansal: So I think the main difference that we feel like compared to the consumer WordPress, I would say. The consumer WordPress access technologies on very different platform, like proprietary. Just imagine somebody is using Instagram to create reels. With that mindset they come to WordPress Media Library and expect video editing experience like that to happen in WordPress, they will be disappointed.

But here we’re talking to people in large companies, very large companies, using legacy systems, probably from the nineties. They might have a desktop application to update a webpage, some ugly looking forms. We even have a memory where a client, their publishing workflow they had to write an article using a very poorly designed HTML web form, and they had to upload images via FTP. And then they had to reference images in document. There was no drag and drop interface.

So now if somebody like this person comes to Gutenberg, it’s like an iPhone moment for them. With that being said, Gutenberg itself is a very powerful editor. We haven’t come across a case where somebody said, oh, this is not flexible. As I said, like enterprise have a very good balance around the feature versus maintenance. For example, so Gutenberg may have one or two features less compared to a third party page builder, but then being part of Core, they’re assured that five years down the line, it will be very well maintained.

Security is more important to them because one less plugin means one less attack vector. Less things to break, less things to train, less things to maintain going forward. We as an agency develop so many sites on Gutenberg that we have our own libraries and our own patterns. So it’s like, whenever a requirement comes, we can easily map it to Gutenberg.

[00:28:51] Nathan Wrigley: I think that’s the difficult thing to imagine if you’ve never built your own block or you’ve never delved into patterns. But certainly at the enterprise level, if a client comes to you and said, we have this repeatable thing, and we need to put this repeatable thing on page every time. And honestly it’s real chore. And you can build a block, and they drop the block in, and now they just fill out some fields, drag an image in here, and suddenly, boom, it’s exactly on the front end what were expecting.

It’s that kind of thing, isn’t it? It’s that, almost like an app inside of an editor. So we’ve got a block which consumes perfectly the content that you want, and we can adapt it if your needs change. But if you’ve never really gotten into that, it’s hard to imagine. It’s just a bunch of paragraphs and images, but it’s not, it’s so much more powerful than that.

[00:29:34] Rahul Bansal: One thing I would say that, if you look at any large corporation, they have something called design systems, where they have their brand guidelines across products, not just websites like, across mediums like print and everywhere. With Gutenberg, it is very intuitive and easy to map the design system into WordPress. So that is where Gutenberg shines, that you can create patterns, you can create theme json. You can give them a starting point which blends very well with their existing design system.

That is where half of the job gets done. Like, compared to indie hackers or small businesses, large enterprises are not running after lots of plugins. They don’t want to try a hundred plus blocks plugin, a plugin with 200 blocks. They want to restrict number of choices. They want to have less number of blocks, but properly weighted with the user’s guidelines. So it’s like, the freedom they demand is easily given by Gutenberg, and with the assurance of, it is going to be around long term. It’ll be very well maintained. It’ll be very well supported, and performance. I still feel Gutenberg has much better performance, the markup, SEO qualities, top notch.

[00:30:35] Nathan Wrigley: I think it’s just the constraints that you can put around that editing experience. So if the client comes and they want this inexperienced user to be able to create content but have boundaries so they can, I don’t know, they can add an image here and it will be, it doesn’t matter, they just put it in and it will output perfectly. And here’s where the text goes, but they can’t change the fonts, you’re not allowed to change the color and what have you. All of those kind of constraints around the editing experience. It’s just miraculous really what’s possible.

And I think it gets lost because the majority of people, I’m imagining using WordPress are sort of tinkering with Core blocks and it can become confusing. There’s lots of choices. You try one thing and it doesn’t work out, and you throw your hands in the air. But if you’ve built the perfect thing, then all of those guardrails are in place and it will output the perfect thing every time. I think that’s really interesting.

How do you grow, and how do you find your next employees? Because I’m guessing at the level that you are now at, you must have some fairly exacting specifications when you put out a job description. And WordPress is becoming an increasingly JavaScript based thing. Lot more technical difficulties. Where do you find your talent, and is it becoming harder to find?

[00:31:40] Rahul Bansal: This would be unique to literally us. We have what we call our own training center where we, every year we take some 50 students from college, who recently graduated. Every six months we take 25 to 30 students from colleges. We put them through six months of training, like a complete, they get paid to learn WordPress for six month. They have no obligation to continue with us. They can join our competition, they can do anything with the WordPress.

But we really get this talent and this job is very popular in India. So this training we run, the pay scales are very popular in India. So last year also we had some 90,000 applications for 60 positions. We literally have to build a platform. So we have a campus adding platform, its name is Chitragupta. Chitragupta is basically is responsible for managing the ledger of your good and bad work. So in Hindu mythology. So we built  Chitragupta, which basically scans your GitHub repos and assigns your grade.

And those 9,000 people gets graded. And then we interview from top to bottom until 60 positions gets filled. So last time we had to interview some 1,200 students, by the time 60 students got selected.

Then we put them to the six month training. Our course is public, so people know what is going to be in the course, and so we find a lot of passionate people. Many times by the time they join our course, I’ve already gone through it from the public website that we have learn.rtcamp.com. From there, they already have checked it. And then we put them through the six month training. After that, this thing we started this year only. After six month training, we put them six months into the WordPress.

So WordPress Core has a mentorship program running on for new contributors. So this year we enrolled 10 people, managed by Automattic and Google employees, senior employees. So they are mentoring this people for further. So first year we, we invest them heavily. Zero revenue, only investment in year one.

And then from year two, we start getting, like some client work done from them. And this is something turned out to be very great for us from last three years. At some point we felt, there are same number of people switching between agencies, and net new addition to the WordPress worker pool was getting stagnant, especially around Covid.

I felt the way people used to discover life with WordPress, or a professional life with WordPress was mostly through WordCamps or meetup groups, and when that Covid happened, we suddenly missed those years, when new people didn’t come to the WordPress, as many as they used to come before.

So there was this gap that started hurting large agencies, like us. Because if we look at a small website, then the enterprise budget appears a lot, but there’s always a limit. No company approves unlimited budget for any venture. Like for every project there’s a budget. It’s usually large enough, but there’s always a number and, as talent was getting more expensive, WordPress was getting unaffordable at some point.

So I talked to some medium publishers, medium sized publishers, not the big ones, who complain a lot. Like the good WordPress agencies are either sold out or too expensive. It’s like WordPress is suddenly getting unaffordable, and that is when we started in this hiding experiment, where we onboarded people every year. And this is, we are doing from last four years.

So we have been hiring for many years, but early it was 5, 10 people. This massive scale of hiring we started from last three to four years. And, it turned very well for us. Like all these people in second year clocked, like in agency billable hours is a very big metric, and in second year, these people clock 90%, more than 90% billable hours.

[00:35:08] Nathan Wrigley: That’s incredible. What a great idea. Can I just ask, just to clarify with that, is that an in-person thing? So you come to a place where 60 people gather, and the tuition is taking place in the same room, or is it an online thing or?

[00:35:23] Rahul Bansal: So before Covid it was, it used to be in the same room, but the scale was 20 people at that time only. After Covid, we made it completely remote. It’s now completely remote. It’s still in the same time zone because, these are the Zoom calls, recordings. The time zone synchronization is needed. So that’s why it’s currently India only. But we are expanding it to other territories, and we are seeing like if we can create similar talent pool in other part of the world. Because,early it was in n office, then it went remote over Zoom. And this year, it is going async. We have a dedicated department, which is called Learning and Development Department.

So our agency head has implemented most lessons in a synced way, so that people can wake up at different time. And so it’s like they won’t get blocked. They can learn asynchronously, they can complete this six month course asynchronously.

[00:36:11] Nathan Wrigley: It just sounds like the appetite is incredible. The numbers that you just mentioned there, I think you said something like 1200 or something like that, people for 90 places. That’s just remarkable. So the appetite really is there. It seems like such a commendable project as well, in that you are putting out a limited, you know what, you can manage. 60 people out into the workplace. Some of them may end up working with you. Some may end up working with your competitors. But you’ve put 60 people out there who are really credible at pushing the boundaries of what WordPress can do, and hopefully just making a start on their career.

[00:36:44] Rahul Bansal: Yeah.

[00:36:45] Nathan Wrigley: But I know that it’s not just limited to that. And, I would like to get into this just before we finish, because I think this is important. Over the last few years we see these metrics every year of companies who put time into the WordPress project in general, in a whole manner of different ways. They may be sponsoring events. They may be committing staff to Five for the Future and what have you.

And the company, your company, rtCamp, it always seems to be right at the forefront of that in a growing way. I’d just like to applaud you for that and give you an opportunity to say what it is that you do so that we’ve got an impression of just how much good you are doing apart from obviously, having a very profitable agency and what have you, how much good you’re putting back into the community as well. So just outline your commitments to the WordPress project.

[00:37:29] Rahul Bansal: So, as I mentioned that, so we have multiple ways of contributing. So as we hire a lot of from college, unfortunately we cannot have a lot of Core committers with us, but we take care of the other end. For example, these 10 people, we have a commitmentt now internally that every six months, so we will put 10 people full-time, like full-time as in literally full-time. A hundred percent of their time will go in working on WordPress project for six months.

And then this will be rotated by next batch. So in rotation there will be at least 10 people. As we grow further, then we’ll make it 15, 20. And we want to keep this ramping up this number. So there will be always, WordPress Core will have enough junior people to pick the task. So, that good first issues will, somebody will be looking at them.

Then we have a QA people, work into the QA team, other teams. I myself as WordCamp organizer, for WordCamp Asia. We have other people contributing to different part of WordPress.

We have a training course, which is public domain, in public domain. We started that much before learn.wordpress.org is there. Now  learn.wordpress.org is there, it is much better resource. But then this course was there for many years, and many other agencies use it. So that is one of the way to build human capital. So this word actually drives me a lot. We want to consciously put our efforts in developing human capital of WordPress.

Because in the end, it’s people that do the job, no matter how fancy it is. You need a human to put a prompt to the AI. ChatGPT won’t build things on its own. You need to, you need a human to ask creative questions. And we want to ensure that WordPress economy continues to grow, and it never falls short of people. So we hire a lot of junior people. We put into the workplace. We publish our videos tutorial. We publish our training material also in the public domain.

Many companies use it, and we expect no link back, also, no credit. Because sometimes they have a apprehension that if they know, this is why rtCamp course will, for, example, our training course site doesn’t require registration. So if you’re sending your employees to learn WordPress on our site, we won’t track them. We won’t solicit them. We have no way of knowing who’s learning. Google Analytics just shows traffic. A lot of traffic is coming to those training sites, but we have no personally identify information tracked there.

[00:39:45] Nathan Wrigley: I would imagine that in every aspect of your business, except this, maybe, there’s gotta be some measurable ROI. Okay, we put this in, we get this out. Do you have any metrics to measure your commitment to the community, or is it just putting your finger in the air and thinking, okay, last year, our business did this, let’s put, I don’t know, whatever it might be. Do you have a pro forma that you stick to? A number of hours, a number of people? Or is it just, yeah, this feels right this year. Because you can’t measure this. And in some cases, I imagine people would think, yeah, they’re probably overdoing it a little bit over there and what have you.

[00:40:21] Rahul Bansal: So, we have a top line mandate that, so it’s like, internally we divide engineers in three categories in rtCamp. The junior ones were like less than two years in rtCamp. The senior ones like two to five years. And lead levels were like more than five years with us. The junior one, we target 20% of their time for WordPress Core. And the medium level, the seniors, 10%, and lead level is 5%. Lead level is very hard, because we have very less lead engineers. The demand supply gap is more evident on senior and lead level. But then, these metrics are, so our office structure is that we have some called business needs.

So every people need to submit their 20% report. Not only they need to submit the hours report, like they have their hours went into the WordPress Core or different part. They have to compile what are the issues they solved. It’s not like you’re just making time entries. You have to tell in the leadership quarterly review that I have 50 people in my business units, and together they clock 3000 hours. And this is what we achieved in 3000 hours. And this is approved. The props messages we see in WordPress Slack, those screenshots, if our employee names is mentioned, are taken screenshots and filing into those review reports.

Three people got props from my team. The WordPress Core release notes, like with major releases. So those contributor list also presented by them. If somebody’s doing some make WordPress blog post or activity, those are also tracked by them. So the heads compile this report, from like bottom ups and then present in leadership meeting. So this is not accidental.

The material ROI is very hard to measure. We cannot say that, oh, we made like X dollars because of this effort. I think, as a salesperson, when I tell a client like, hey, I’m going to give you an engineer who knows WordPress very well. I’m more confident if that person has contributed six months to the WordPress Core. And their patches is weighted by some amazing people in WordPress community, especially senior ones. It’s like a win-win situation for all. This gives me a very, very well trained people to sell.

[00:42:16] Nathan Wrigley: That’s exactly how I was just thinking about it. This kind of win-win cycle of you put people into WordPress, and obviously at a junior level, more time and I can understand that. That makes sense. Presumably the ones who are more experienced, they’ve got other work to be doing. But also they’ve probably gained a ton of experience doing those prior years of extra hours.

So you put the hours in, but also they contribute to Core, but they get experience back out. They’ll be exposed to all sorts of different things that your projects would never have put them in front of, presumably. So they’ll be touching on subject matters. Getting into plugins, themes, blocks, code, Core, whatever it may be in a whole range of different ways than they would be. So like you say, it’s like you slap my back, I’ll slap yours a little bit. Win-win. WordPress wins, you win.

[00:43:06] Rahul Bansal: There are three wins here. The person, that student, who came right out of the college, and usually in college, people here, people have some negative perception about professional life. That companies are evil. You are going to do labor. Somebody will steal your credit, and here they’re on their own. Like they go into the WordPress community on their own. They sign a patch with their name. They file a Trac ticket with their name. They get props in their name. They get treated very well by contributor. If somebody makes mistakes, WordPress committee is full of nice people. Nobody’s going to pull them down. Nobody’s going to shout at them.

Everybody corrects them with respect and compassion, and that helped them grow as a person. Like, they become better human. They become better coder. And that empathy, we see that, when they become senior engineers, and when they’re reviewing some junior’s code, they remember that, hey, when I was, it was my first day in WordPress community, and I made that patch. I made one mistake, but somebody was nice to me, so I have to pass it on. So that niceness cycle continues.

And, the biggest win is that these people like, who has an incredible job satisfaction. They love open source more. Many of them don’t join for the love of open source, they’re at a point when they, join rtCamp, they’re at a point when their college is ending. They just want to get a job, and secure a financial life. Whatever jobs comes their way, they’re okay with it. Open source, closed source, not much preference. But once they’re in, and then we take them through this one year of tour, like six months in training center, then six months in WordPress community, they become the advocate of open source for life.

And that is a very most important win for us because we want people to believe in open source. We don’t want them to say open source is good because their company is selling it. We want them to have that faith that open source is the right way to do things. And that faith is very important for growth. You cannot mug up your mission statement and stand for it.. You have to believe in something to stand for it.

[00:45:00] Nathan Wrigley: What a profoundly interesting thing to have said. I think that’s just fabulous. I think your company is doing so many interesting things. It’s obviously, financially it’s working out, but just the position that you’ve painted there of the way that you are treating your employees, and the autonomy that you’re giving them, and the future opportunities that you are giving them. And the training opportunities giving them, just remarkable. And I’m profoundly impressed by what you’ve been doing.

Unfortunately, time is our enemy. We’re going to call it a day there. Rahul, thank you so much for chatting to me today. That has been an incredible journey. Long may it continue. I wish you and rtCamp all the success that you can possibly have the future.

[00:45:39] Rahul Bansal: Thank you, Nathan. Thanks for having me on this podcast.