Posted on

Where to Put Your Logo? What the Research Says

You’ve got a beautifully designed logo. Well done. Now, what do you do with it?

Once your high quality logo is designed and ready to go, it should appear on all your branded material, including your WordPress website. Typically, there are three schools of thought as to where logos can go: in the top-left, top-middle, or top-right corners of a page. So this begs the question: which position is right for your logo?

If we’re going strictly based on UX logic, then your logo belongs in the top-left corner of your website. No questions asked. There are two reasons for this:

  1. For those of us with a native language that reads from left to right, our eyes naturally look to the left first.
  2. In the earlier years of web design, logos were always on the left, and that’s where most people assume they are located now.

Despite what logic says, there are some websites that have eschewed the norm for logo placements in the center or right corner of a website. Would a unique placement of your logo fit better with your brand identity?

Let’s take a closer look at what the studies show, and see if left really is right for your site.

Experts Weigh In: Where to Place Your Logo?

According to the Nielsen Norman Group, there are three purposes that logos serve on modern websites:

  • They remind visitors where they are. In other words, whose website am I on?
  • They allow for easy navigation to the home page since most websites no longer include a “Home” button in the navigation.
  • They aid in brand recognition as the logo always remains there at the top of the site, and sometimes even follows visitors as they scroll down a page.

The NNGroup performed two studies to find the ideal logo location. Here is what they found:

Left vs. Right

In the left-versus-right study, the NNGroup tested and observed the response of 128 users. Similar to an A/B test, each user was shown only one version of a website: either the original with the logo on the left or the one the NNGroup manipulated in order to place the logo and navigation on the right.

They gave the users a minute’s time to review their version of the website. They were then asked a series of questions and shown photos of 10 hotel websites. This test aimed to establish what sort of effect logo placement had on brand recall.

These were the results:

  • Left-aligned logos lead to greater brand recall. Specifically, the average brand recall for left-aligned logos was 39% as opposed to 21% for the right-aligned version.
  • Left-aligned logos are more likely to be labeled “unique.” Despite the traditional placement of a left-aligned logo, respondents were still more likely to label a left-aligned logo as “unique” and “stylish” than one that appeared on the right.

Left vs. Center

The Nielsen Norman Group conducted an additional study to discover what happens when users were exposed to a center-aligned logo. They conducted two different tests to determine the viability of a centered logo.

Unlike the A/B test conducted between left- and right-aligned logos, this first survey provided 50 users each with one retail website to interact with. Eight of those websites had a centered logo whereas six had a left-aligned logo. They were then asked to complete different tasks that would test their ease in using the navigation and return to the home page.

This was the result:

  • Left-aligned logos are better for navigation. In the study, only 4% of users failed to navigate home in a single click when the logo appeared on the left. When the logo was centered, however, 24% of users failed to get there in one click.

In the second of these tests, the NNGroup presented 128 users with five different hotel websites. Four of the logos showed variations of a logo on either the left or in the center, while the fifth site included a right-aligned logo. Users were then asked a series of questions to determine brand recall.

This was the result:

  • Brand recall is unaffected by the difference between left or centered logos. Despite presenting users with variations of the same logo in different spots, brand recall was inconsistent in this comparison between left-aligned and centered logos.

The Winner Is…

After reviewing the results from the logo placement studies, it appears that logic does prevail:

Left is best.

Here’s why:

  • Many people don’t think about looking in the right-hand corner of a website for a logo, and so brand recall can be severely compromised as a result.
  • Many people are conditioned to look for a navigation in one of the top corners of a site, so placing a logo and/or navigation in the center confuses the process of getting around a website.

In summary, left-aligned logos are ideal as they are located exactly where the eye is naturally drawn.

Just remember that web design’s primary concern should always be with the user experience. While a centered logo may look sleek, it probably isn’t ideal if you have more than one page on your website (and you expect people to visit those other pages). The same goes for a right-aligned logo. It may seem like you’re giving your site a unique edge, but you may hurt your brand’s recall in the process.

It’s also important to keep in mind that it’s not just logo placement that matters. Logos should be exported in a high-quality file format, created using a legible font face, and positioned on top of white space so that background imagery, shadows, and colors can’t distract from it.

Wrapping Up

If you’re trying to get creative with your WordPress site’s design, there are other ways to go about doing it. You could create a killer landing page, add push notifications, or revamp your CTA buttons.

If this study has shown us anything, it’s that you shouldn’t mess around with the placement of your logo. Left is always best.

Posted on

Top 7 React Native Components for Software Development

React Native is one such framework that is used for software development. It allows app development for multiple platforms with a single code base for iOS, Android, Windows with a single code base. React Native is one of the most known and highly used cross-platform for mobile app development presented by Facebook and the most prominent active developers' communities.

What Is React Native?

React Native is a well-known JavaScript-based app framework used for mobile apps and software development. It enables developers to develop natively generated apps for iOS and Android. You can develop a React Native-Based application for various platforms using the same codebase as the software development company. 

Posted on

Git: Switching Unstaged Changes to a New Branch

I’m always on the wrong branch. I’m either on master or main working on something that should be on a fix or feature branch. Or I’m on the last branch I was working on and should have cut a new branch. Oh well. It’s never that big of a deal. Basically means switching unstaged changes to a new branch. This is what I normally do:

  • Stash all the changed-but-unstaged files
  • Move back to master
  • Pull master to make sure it’s up to date
  • Cut a new branch from master
  • Move to the new branch
  • Unstash those changed files

Want a bunch of other Git tips? Our “Advanced Git” series has got a ton of them.

Switching unstaged changes to a new branch with the Git CLI it looks like this

Here’s how I generally switch unstaged changes to a new branch in Git:

git status
git stash --include-untracked
git checkout master
git pull
git branch content/sharis
git checkout content/sharis
git stash pop
Yeah I commit jpgs right to git.

Switching unstaged changes to a new branch in Git Tower it looks like this

I think you could theoretically do each of those steps to switch unstaged changed to a new branch, one-by-one, in Git Tower, too, but the shortcut is that you can make the branch and double-click over to it.

Sorry, I’m just doing Git Tower but there are lots of other Git GUIs that probably have clever ways of doing this as well.

But there is a new fancy way!

This way of switching unstaged changes to a new branch is new to me anyway, and it was new to Wes when he tweeted this:

Cool. That’s:

git switch -c new-branch

Documentation for that here.

Git: Switching Unstaged Changes to a New Branch originally published on CSS-Tricks. You should get the newsletter and become a supporter.

Posted on

3 Things Every Engineer Should Know About Inclusive Design

Fact: Over 26% of adults in the United States have some sort of disability. To ignore such a massive part of the population would be ill-advised for any company, legally, financially, and above all, ethically. How can you stay ahead of the curve when it comes to maintaining a progressive and responsive organization? 

We reached out to two experts - Alwar Pillai and Perry Trinier of Fable – on the topic of designing products that have inclusivity for people with disabilities at their core. Here are the 3 things they think every engineer, developer and product designer needs to know about inclusive design and how it will inevitably affect the future of their companies.

Posted on

How to Provide Rate-Limiting Via Bucket4j in Java

Hello, everyone. Today, I want to show how you can provide rate-limiting into your project based on the Token Bucket algorithm via Bucket4j.

Every now and again, all of us face a problem with limiting our external API -- some functionality where we should limit calling to our API for many reasons.

Posted on

Brief, Yet Widespread Discord Outage Caused by API Issues

Discord, the popular social communications platform, experienced an API outage earlier this week that led to a significant disruption in operations on the platform. This issue, which is no longer causing downtime and has been fully acknowledged via the company’s status page, is the result of API issues that have not been detailed. 

Posted on

Migration of Microservice Applications From WebLogic to Openshift

The need for an environment to put software applications into service is a concept that is contemporary with the history of software development. While the software dimension of the business changes, there are also changes and improvements in technology, CI/CD practices, usage scenarios, and operational expectations — the environmental practices that allow the software to serve.

In this article, we will discuss our experiences with the seamless migration of Spring Boot (version 2.5.6) microservice applications from Oracle WebLogic to the Red Hat OpenShift Container Platform. Also, the practices to ease and ensure the parallel running of applications in both platforms will be discussed.

Posted on

The Role of CI/CD Pipeline in Software Development

The CI/CD pipeline includes continuous integration, delivery, and deployment. DevOps teams use it to generate, test, and release new software automatically. This pipeline benefits from regular software changes and a more collaborative and agile team process. You've probably heard about the benefits of CI/CD tools, which are used to provide code more frequently and reliably. Let's examine what it is and how it benefits software development.

What Does CI/CD Pipeline Stand For?

There are two abbreviations for CI and CD: CI stands for continuous integration and CD for continuous delivery and deployment. The software development methodology is known as Continuous Integration, and Continuous Deployment (CI/CD) is based on the idea that incremental code changes are made frequently and consistently. Continuous Integration (CI)-triggered automated build and test stages ensure that code changes submitted into the source are trustworthy.

Posted on

Does Windows 10 consider drive serial number?

My PC had boot failure, presumably due to M.2 drive failure. During debug, I disconnected the HDDs containing the StorageSpace volume witout documenting each of the 7 physical drive's serial number and their order.

Am I out of luck with regards to accessing the data stored in that StorageSpace?

Posted on

The 5 Principles of Agile Software Development Methods

Over the years, software development methods have also upgraded parallelly with technological advancements. Agile software development methods are one approach in the current software development trends. Agile methodology breaks up the project into many phases and distributes the workloads across the teams. We prioritize continuous improvement at each stage rather than working on changes at the deployment stage altogether. Progress is constantly updated with the team members during the daily scrum meetings. The examples of agile-based development methods are scrum, Extreme Programming (XP), Feature-Driven Development (FDD), Adaptive Software Development (ASD), Crystal, Dynamic Systems Development (DSD), Lean Software Development, etc. The methods are selected according to the type of product/service to be developed. All these agile methods follow a set of dedicated principles. In this blog, we will focus on five crucial principles of agile methodology.    

1. Be Open to Challenges and Changes  

The agile methodology focuses on being highly responsive to changes at all phases of software development. Our teams must be aware of what is going on in the project at any development phase. The agile method splits the tasks and deliverables into iterations to achieve this high degree of clarity. The iterations must be completed in shorter time frames, usually from a week to four. Ensure that the time frames align with the overall time allocated to the project.    

Posted on

Demystifying TypeScript Discriminated Unions

TypeScript is a wonderful tool for writing JavaScript that scales. It’s more or less the de facto standard for the web when it comes to large JavaScript projects. As outstanding as it is, there are some tricky pieces for the unaccustomed. One such area is TypeScript discriminated unions.

Specifically, given this code:

interface Cat {
  weight: number;
  whiskers: number;
}
interface Dog {
  weight: number;
  friendly: boolean;
}
let animal: Dog | Cat;

…many developers are surprised (and maybe even angry) to discover that when they do animal., only the weight property is valid, and not whiskers or friendly. By the end of this post, this will make perfect sense.

Before we dive in, let’s do a quick (and necessary) review of structural typing, and how it differs from nominal typing. This will set up our discussion of TypeScript’s discriminated unions nicely.

Structural typing

The best way to introduce structural typing is to compare it to what it’s not. Most typed languages you’ve probably used are nominally typed. Consider this C# code (Java or C++ would look similar):

class Foo {
  public int x;
}
class Blah {
  public int x;
}

Even though Foo and Blah are structured exactly the same, they cannot be assigned to one another. The following code:

Blah b = new Foo();

…generates this error:

Cannot implicitly convert type 'Foo' to 'Blah'

The structure of these classes is irrelevant. A variable of type Foo can only be assigned to instances of the Foo class (or subclasses thereof).

TypeScript operates the opposite way. TypeScript considers types to be compatible if they have the same structure—hence the name, structural typing. Get it?

So, the following runs without error:

class Foo {
  x: number = 0;
}
class Blah {
  x: number = 0;
}
let f: Foo = new Blah();
let b: Blah = new Foo();

Types as sets of matching values

Let’s hammer this home. Given this code:

class Foo {
  x: number = 0;
}

let f: Foo;

f is a variable holding any object that matches the structure of instances created by the Foo class which, in this case, means an x property that represents a number. That means even a plain JavaScript object will be accepted.

let f: Foo;
f = {
  x: 0
}

Unions

Thanks for sticking with me so far. Let’s get back to the code from the beginning:

interface Cat {
  weight: number;
  whiskers: number;
}
interface Dog {
  weight: number;
  friendly: boolean;
}

We know that this:

let animal: Dog;

…makes animal any object that has the same structure as the Dog interface. So what does the following mean?

let animal: Dog | Cat;

This types animal as any object that matches the Dog interface, or any object that matches the Cat interface.

So why does animal—as it exists now—only allow us to access the weight property? To put it simply, it’s because TypeScript does not know which type it is. TypeScript knows that animal has to be either a Dog or Cat, but it could be either (or both at the same time, but let’s keep it simple). We’d likely get runtime errors if we were allowed to access the friendly property, but the instance wound up being a Cat instead of a Dog. Likewise for the whiskers property if the object wound up being a Dog.

Type unions are unions of valid values rather than unions of properties. Developers often write something like this:

let animal: Dog | Cat;

…and expect animal to have the union of Dog and Cat properties. But again, that’s a mistake. This specifies animal as having a value that matches the union of valid Dog values and valid Cat values. But TypeScript will only allow you to access properties it knows are there. For now, that means properties on all the types in the union.

Narrowing

Right now, we have this:

let animal: Dog | Cat;

How do we properly treat animal as a Dog when it’s a Dog, and access properties on the Dog interface, and likewise when it’s a Cat? For now, we can use the in operator. This is an old-school JavaScript operator you probably don’t see very often, but it essentially allows us to test if a property is in an object. Like this:

let o = { a: 12 };

"a" in o; // true
"x" in o; // false

It turns out TypeScript is deeply integrated with the in operator. Let’s see how:

let animal: Dog | Cat = {} as any;

if ("friendly" in animal) {
  console.log(animal.friendly);
} else {
  console.log(animal.whiskers);
}

This code produces no errors. When inside the if block, TypeScript knows there’s a friendly property, and therefore casts animal as a Dog. And when inside the else block, TypeScript similarly treats animal as a Cat. You can even see this if you hover over the animal object inside these blocks in your code editor:

Showing a tooltip open on top of a a TypeScript discriminated unions example that shows `let animal: Dog`.
Showing a tooltip open on top of a a TypeScript discriminated union example that shows `let animal: Cat`.

Discriminated unions

You might expect the blog post to end here but, unfortunately, narrowing type unions by checking for the existence of properties is incredibly limited. It worked well for our trivial Dog and Cat types, but things can easily get more complicated, and more fragile, when we have more types, as well as more overlap between those types.

This is where discriminated unions come in handy. We’ll keep everything the same from before, except add a property to each type whose only job is to distinguish (or “discriminate”) between the types:

interface Cat {
  weight: number;
  whiskers: number;
  ANIMAL_TYPE: "CAT";
}
interface Dog {
  weight: number;
  friendly: boolean;
  ANIMAL_TYPE: "DOG";
}

Note the ANIMAL_TYPE property on both types. Don’t mistake this as a string with two different values; this is a literal type. ANIMAL_TYPE: "CAT"; means a type that holds exactly the string "CAT", and nothing else.

And now our check becomes a bit more reliable:

let animal: Dog | Cat = {} as any;

if (animal.ANIMAL_TYPE === "DOG") {
  console.log(animal.friendly);
} else {
  console.log(animal.whiskers);
}

Assuming each type participating in the union has a distinct value for the ANIMAL_TYPE property, this check becomes foolproof.

The only downside is that you now have a new property to deal with. Any time you create an instance of a Dog or a Cat, you have to supply the single correct value for the ANIMAL_TYPE. But don’t worry about forgetting because TypeScript will remind you. 🙂

Showing the TypeScript discriminated union for a createDog function that returns weight and friendly properties.
Screenshot of TypeScript displaying a warning in the code editor as a result of not providing a single value for the ANIMAL_TYPE property.


Further reading

If you’d like to learn more, I’d recommend the TypeScript docs on narrowing. That’ll provide some deeper coverage of what we went over here. Inside of that link is a section on type predicates. These allow you to define your own, custom checks to narrow types, without needing to use type discriminators, and without relying on the in keyword.

Conclusion

At the beginning of this article, I said it would make sense why weight is the only accessible property in the following example:

interface Cat {
  weight: number;
  whiskers: number;
}
interface Dog {
  weight: number;
  friendly: boolean;
}
let animal: Dog | Cat;

What we learned is that TypeScript only knows that animal could be either a Dog or a Cat, but not both. As such, all we get is weight, which is the only common property between the two.

The concept of discriminated unions is how TypeScript differentiates between those objects and does so in a way that scales extremely well, even with larger sets of objects. As such, we had to create a new ANIMAL_TYPE property on both types that holds a single literal value we can use to check against. Sure, it’s another thing to track, but it also produces more reliable results—which is what we want from TypeScript in the first place.

Demystifying TypeScript Discriminated Unions originally published on CSS-Tricks. You should get the newsletter and become a supporter.

Posted on

#11 – Vinny McKee on His Block Builder Plugin

About this episode.

On the podcast today we have Vinny McKee.

He’s the creator of the Wicked Block Builder plugin, which is a tool to make the job of creating your own custom blocks as easy as possible.

I’m sure that you know that WordPress’ editor is all about blocks. You can create content, and now whole websites with small components. A title here, and a paragraph there. But the real power of blocks is the way that they can be extended so that they can consume and display any kind of content in any way that you can imagine.

The WordPress landscape is moving towards blocks as the way to create and present all-the-things, and we’re just at the start of a very exciting journey.

You can download and try out blocks for almost everything. Some do one thing, other block packs bring entire suites of interesting blocks to the table.

But there is a problem… blocks are not all that easy to create. Yes, you might very well be a talented developer who has taken the lead in learning block creation. You burned the midnight oil and got your head around the complexities of it all. I suspect that it was an uphill struggle.

But WordPress’ mission is to democratise publishing. In an ideal world not just publishing, but extending WordPress would be something available to the masses.

Step in Vinny McKee. His Wicked Block Builder plugin is one of the tools out there that enables you to build your own blocks without the need to understand much of what’s going on behind the scenes, and there’s a lot going on behind the scenes.

Page Builders allowed users to create beautiful websites without needing to learn code, block builders are doing the same thing for blocks.

Today on the podcast we learn about why Vinny built the plugin, as well as how it works. What problems does it overcome, and are there any limitations to what you can build?

Wicked Block Builder on the WordPress repo

Wicked Block Builder website

Justin Tadlock’s post “Wicked Plugins Launches UI-Based WordPress Block Builder”

Wicked Plugins Twitter account

Transcript

[00:00:00] Nathan Wrigley: Welcome to the 11th edition of 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 themes, and in this case, the creation of blocks with a plugin. Up until now, we’ve released this podcast each month. But we’re going to move to a weekly schedule from now on. And that leads to a couple of things. Firstly, it goes without saying that there will be lots more podcast episodes, and I would encourage you to subscribe to the podcast so that you can get all of those episodes automatically each and every week. You can do that by searching for WP Tavern in your podcast, player of choice, or by going to wptavern dot com forward slash feed forward slash podcast, and you can copy that URL into most podcast players. Secondly, with so many more episodes, I’d really like to hear from anyone out there who would like to come on the podcast and talk about whatever it is that you do with WordPress. It might be that you’re a developer, a WordCamp organizer, a contributor, a designer, honestly… if it’s about WordPress, I’m keen to hear from you and hopefully get you on the show. Head over to wptavern dot com forward slash contact forward slash jukebox, and use the form there. Once again, wptavern dot com forward slash contact forward slash jukebox. And I look forward to hearing from you.

So on the podcast today, we have Vinny McKee. He’s the creator of the Wicked Block Builder plugin, which is a tool to make the job of creating your own custom blocks, as easy as possible. I’m sure that you know, that the WordPress editor is all about blocks. You can create content and now whole websites with small components, a title here, and a paragraph there.

But the real power of blocks is the way that they can be extended so that they can consume and display any kind of content in any way that you can imagine. The WordPress landscape is moving towards blocks as the way to create and present all the things, and we’re just at the start of this very exciting journey. You can download and try out blocks for almost everything. Some do one thing. Other block packs bring entire suites of interesting blocks to the table. But there’s a problem. Blocks are not all that easy to create. Yes, you might very well be a talented developer who has taken the lead in learning block creation. You burned the midnight oil and got your head around all the complexities. I suspect that it was an uphill struggle. But WordPress’ is mission is to democratize publishing. In an ideal world, not just publishing, but extending WordPress would be something available to the masses. Step in Vinny McKee. His Wicked Block Builder plugin is one of the tools out there that enables you to build your own blocks without the need to understand much of what’s going on behind the scenes. And there’s a lot going on behind the scenes.

Page builders allowed users to create beautiful websites without needing to learn code. Block builders, well they’re doing the same thing for blocks. Today on the podcast we learn about why Vinny built the plugin as well as how it works. What problems does it overcome? And are there any limitations to what you can build? If you’re interested in trying it out, you can find the links in the show notes, head over to wptavern dot com forward slash podcast, and look for episode number 11. And so without further delay, I bring you Vinny McKee.

I am joined on the podcast today by Vinny McKee. Hello Vinny.

[00:04:40] Vinny McKee: Hey, Nathan. Thanks for having me on the podcast.

[00:04:42] Nathan Wrigley: You are most welcome. Now, Vinny is going to be talking to us today around the Gutenberg subject is the best way to describe it and blocks in particular. He has a great deal of expertise in this area and has a plugin which may be of real interest to the people who are listening to this podcast.

This whole episode really was brought to my attention by Justin Tadlock, who on the 14th of January, 2022, wrote a piece called Wicked Plugins Launches UI Based WordPress Block Builder. So be sure to go and check that out. So I asked Vinny if he wanted to come onto the podcast today and here we go.

We’re going to be talking about blocks and building blocks. First question though Vinny, if it’s all right with you, I’m going to ask a more generic question. Would you mind just telling us a little bit about yourself, your history with WordPress and so on.

[00:05:33] Vinny McKee: Yeah. So I’m a freelance web developer and plugin author. I’ve been a freelance developer since around 2006. And I think the first time I really started using WordPress was actually in 2006. At that time, I didn’t really know anything about it really. And to be honest, didn’t even really care that much about it at the time. It was just a way to solve what I needed at the time, which was two blogs for clients so that they could easily create blog posts.

And so then I think it was probably around maybe 2008 or 2009, if I have my timing correct, when I really started using WordPress more and started to build lightweight sites that used it more as a CMS and started to build custom themes for it and everything. And then of course, fast forward to today and I’m using WordPress almost exclusively for all of the clients sites I built or build.

[00:06:27] Nathan Wrigley: Where are you based?

[00:06:28] Vinny McKee: I am based in Seattle, Washington.

[00:06:31] Nathan Wrigley: Okay. So we’re probably going to be talking today around the block builder plugin that you’ve got, and probably it’s going to be the easiest thing to just mention where that URL is right at the start. So the company is called wicked plugins, and you can find wickedplugins dot com easily enough, and from there, you’re going to be searching around for wicked block builder that will enable you to see what we’re talking about today. There’s also a wordpress dot org version. And obviously that’s over at wordpress dot org forward slash plugins forward slash Wicked Block Builder. Each of those words is hyphenated. I will put those links into the show notes and anything else that we discussed today that comes up, I’ll endeavor to put those into the show notes as well.

Tell us why you decided to put all of your bits and pieces into blocks. I know that for many people, this is clearly the future. There’s a lot of interest in this, especially right now. But a lot of people are staying away from it at the same time. What is it that you saw all those months, years ago that made you endeavor to build this solution?

[00:07:35] Vinny McKee: Yeah, I think it’s similar to what WordPress has been great for a long time, which is extensibility. So I think what’s really cool about blocks and what I like about it is that you can extend the block editor by creating your own blocks. And so that gives you a lot of freedom. It gives you the ability to create blocks that are tailored to individual projects. And I think that’s really useful. And I think that’s one area where it stands apart from other ways that you can build a site with maybe a page builder or something.

I know you can extend other page builders as well, but I feel like with blocks and Gutenberg, I like that it’s baked directly into WordPress. And I just think that it’s neat that you can extend it just like you can extend WordPress in other ways.

[00:08:23] Nathan Wrigley: Yeah. I guess the page builder analogy is quite a good one in that if you are a heavy user of a particular page builder, you may well be interested in creating the equivalent of blocks. So app like functionality within that particular page builder. But the issue I suppose there is that it will be confined to that page builder, and so the audience potentially may be limited. Whereas the block based initiative enables everybody with the default install of WordPress to manage to do these bits and pieces.

Yeah. So really nice inspiration. So why did you decide to actually put your elbow to the metal as it were and get stuck into this. It seems that this is a problem of building blocks. It’s tremendously difficult if you’ve never done this before, but equally you could have just sat there and waited for somebody else to build a solution or indeed for that to be no solution at all. What compelled you to create a sort of GUI interface in order to assist people who have the challenge of building their own custom blocks?

[00:09:22] Vinny McKee: Yeah. So what happened is, as I started to use the block editor to build sites for clients, I found myself wanting to create my own blocks. And because I felt that I needed to do that in order to achieve the look and feel and layout and functionality that the designers I was working with wanted for their sites. And so, I felt like I needed to create my own blocks in order to have the control I wanted over the markup and to achieve all those things as far as the look and feel and layout and those types of things. So what I did is I started creating blocks for the sites that I was working on. But what I found is, as I was going through and creating these blocks, I noticed a few things.

One is that, so when you create a block, blocks have two different functions to generate their markup. There’s one called the edit function, which generates the markup that you see for the block when you edit a page and you see your block in the editor. And then, blocks also have what’s called a save function, which is responsible for generating the markup that actually gets saved to the database when you save a page, and then that’s what you see on the front end when you view the page. And so if you want your blocks to look the same in the editor, as they do on the front end and vice versa, which is what I wanted, you have to basically code the block twice. And, you know, even if the markup is almost identical for both views.

And so that was one thing where I noticed it was a duplication of effort and took a little bit of extra time. And even if you want the block to look exactly the same in both of those views, you have to tweak the code slightly. You can’t just copy and paste. And so it ends up being a lot of… it can be a lot of work.

Something else I noticed was that I was spending a lot of time referencing documentation as I was building blocks. So even after I learned how to build blocks, was was still looking at the documentation a lot, because I couldn’t remember things like, okay, what is that control named? If I wanted to add a text field to a block, for example, is that called text control or is that called text field?

And then I would always forget like what attributes those components or controls accepted. So for example, when I would add a drop down to a block, I would forget what the attributes that allowed you to set the options was called options, or was it called choices? And then how did, how did the data needed to be formatted to go into those options?

Things like that. So I still had to spend a lot of time looking at the documentation, even though I had learned how to build blocks. I kept running into design patterns that were hard. So for example, if I wanted to add an arbitrary number of items to a block, something that would be good for a repeater, for example, like adding an arbitrary number of images, or if you wanted to create like a team block that displayed a grid of people where you could sort the people in the block that would take awhile and it was hard to do.

I guess what I’m trying to say is that what I found was there a lot of things that were adding up to take a significant amount of time, and I just felt I needed to create these blocks for these in order to build the sites that I wanted, but that it was too time consuming for it to be economical. And that I just felt like I wouldn’t be able to produce these sites without being able to build these blocks faster.

[00:12:27] Nathan Wrigley: Yeah. This is the problem that we hear about so much is that the move over to blocks really does create a technical debt, really. What I mean by that is, it’s difficult. There’s a new, whole new raft of things that must be learnt, new techniques that need to be acquired, whole systems that you need to put in place in terms of software as well and what have you. And I feel that a lot of people are put off just by this problem. They simply don’t have the time. They’re working. They’re busy. They’re building websites, possibly for clients or what have you. And the time to go out and spend learning is simply not available to them, and obviously in your case, you managed to find that time and create that bridge for yourself and make it happen.

Was that a difficult journey? So going from no blocks, several years ago to the ability to now create not only blocks, but software, which builds blocks. Did you find that journey fraught with difficulty? Was it fairly straightforward? What was your impression?

[00:13:24] Vinny McKee: Yeah, for me, it was actually fairly difficult because prior to Gutenberg, I didn’t really have a lot of experience with React and I didn’t have a lot of experience with a lot of the tooling either that you would use in a React project. So for example, NPM, Webpack, and some of the other tools that we use to maybe set up a React project. I’d worked with it just a little bit before Gutenberg, but not much. And yeah, I didn’t have that much experience with it, and to be honest, I was pretty intimidated by it because that just wasn’t something that I was familiar with.

And so it did take me quite a while to figure out how to learn React of course, but then also I think for me, what was even more challenging was some of the command line stuff and configuration stuff. Setting up Webpack, for example, to be able to compile the project. And I know now there’s ways you can use other tools like WP Scripts.

I also wanted to understand for myself, make it easier, but yeah, at the time, I also wanted to understand for myself, you know, how those things worked, but yeah, it was a challenge. And even today there’ll be weeks where I might spend hours trying to solve a configuration issue with Webpack. Yeah, it was definitely challenging.

[00:14:37] Nathan Wrigley: I think that’s a really valid point. This is not something which is going to be for everybody. If you are of a certain mindset and you have the time available and possibly the skills available, this might be open to you. And then of course, there’s the other people who presumably you’ve built your Wicked Block Builder for, is the crowd of people who perhaps don’t want to go through all of those steps, learning all of those different things. You mentioned React and the build process and all of that. They just simply don’t want to do that. But they would like to dabble in creating blocks, either for themselves, or for their clients. And I guess that’s the tool that you’ve built. Have I got your target audience about right there? Is it people who are keen to build blocks, but don’t really wish to do the learning that might be required if you wanted to do it all by hand, if you know what I mean?

[00:15:28] Vinny McKee: Yeah. I think that’s a big part of it. And that was certainly one issue I was trying to solve was to make the barrier to entry much lower. But I think too, I was also, the main reason I was inspired to build it was actually to save myself time. Even as a developer, I wanted a way to be able to build blocks faster.

And so, yeah, I mean, it’s definitely for people that maybe don’t want to learn React, or set up the tools needed to build blocks from scratch. I also aimed it at developers as well, hopefully make their lives easier and make it much more efficient to create blocks so that when you’re working on a client project, you can spend less time working on some of those other things I mentioned earlier and focusing more on just creating the blocks you need.

[00:16:12] Nathan Wrigley: Okay. Let’s dig into the tool. It is a plugin for WordPress. As we mentioned at the top of the show, it’s available in a free version on the repo and also a commercial version over on the website, which I’ll link in the show notes so that anybody who doesn’t want to hear the URL in the podcast can just find it, but would you just at the outset, just describe the main differences between the free and the pro so that everybody is really clear where that boundary lies.

[00:16:40] Vinny McKee: They’re exactly the same. The only difference is that the pro version has a couple of advanced features. And so the main features that one has, is a repeater component that allows you to add repeating items to a block as well as conditional logic. And then it has a couple of other advanced components as well. But for the most part, the free version has almost everything and you can actually build the exact same blocks.

The only difference would be something maybe like a repeater where if you wanted to have an arbitrary number of links in a block with the free version you had maybe add slots for five links to your block or something. Whereas with the pro version, you could use a repeater so that you can add an arbitrary number of items or links the block.

[00:17:21] Nathan Wrigley: Okay. Got it. Thank you. That’s made it really clear. Okay. So we’re going to try to describe, cause it’s a difficult thing trying to describe what is a graphical user interface on a podcast, but we’ll give it our best go. As with all things plugin, you must install it on your website. And then you’re presented with a range of new menus in the admin area.

Wicked Block Builder is what I’m seeing currently. And you have the option to add new. And the intention is that you go through the tool and at the end of it, when you go to a post or a page, And you click the little inserter, the plus button, you will hopefully have yourself a ready-made block available to be used to put whatever kind of custom data it is that you want to display on your website.

So, with all that in mind, do you want to try, you know the tool far better than I, I’ve really had just the briefest of plays, but did you want to just describe the process that you would go to in order to set up a simple block with some simple attributes and just discuss what kind of things we’re doing.

[00:18:21] Vinny McKee: Sure. Yeah, I’ll do my best. Yeah. Like you said, once you install the plugin, then to create a block, you just go to Wicked Block Builder in your admin menu, and there’s an add new option. So you click add new. And what that does is that opens up the block builder tool, which is just an interface within WordPress that lets you create your block.

And so that tool is organized into six main screens. And so what you see first is the setting screen and the settings screen just lets you enter basic information about your block and configure some things. So for example, you can enter the name of your block. You can give it a description that you can choose, like what alignment options it supports and whether or not you’d like to make it dynamic.

So then the next screen is attributes. And so the attributes screen lets you configure the attributes for your block. And if you haven’t worked with blocks before then, what attributes are a way to store and, or extract data from your blocks. So they kind of hold the data that’s for your block. And so once you configure attributes, which to configure attributes, it’s really just a matter of dragging and dropping an attribute type, a type, meaning like the data type that you want that attribute to store.

So that could be like a string, for example, or, a true false value or a number and array as the other type of attribute. So once you’ve got your attributes added to your block, then the next screen is called the editor view. And like I was talking about before, there’s two views, two blocks, there’s the edit view, which is what you see in the block editor. And then there’s the front end view. In this plugin we start with the editor view and on that screen, what you do, that’s the kind of the meat of it and where you really build the block. And you build your block by dragging and dropping HTML elements and components. So components are things like text fields or drop downs or radio buttons or check boxes or color pickers, anything that you want to add to your block, to allow people to interact with it, to change settings or to input content.

And so what you do is you drag the HTML elements that you want. So like a div tag, for example, if you want your block to be a div and then maybe if you want another div nested inside of it, you would drag another div and nest it inside the first div. And then if you want a rich text control to be able to input some texts, you would drag that inside. You know, one of the divs, but the idea is that you have full control over the markup and, you create the markup however you want by dragging and dropping. And there’s no limits to, you know, what markup you can add that you can put any valid tags in. So what that does is create the editor view and then the next screen is the front end view.

So you have the option of building the output that your block will generate when it gets saved to the database, and what you see when the block is viewed on the front end, when you view a page. However, that screen is actually completely optional. You can skip that step. And if you do then plugin will use the markup and everything that you set up on the edit screen, and will use that as the, for the front end view.

That’s one of the ways that saves you time is you don’t actually have to create those two separate views anymore. You can just create the edit view and then the plugin will use that same view for the front end, if you want your block to look and use the same markup on the backend and the front end.

And then next is the sidebar screen and the sidebar screen works similar to the previous two screens. It lets you drag and drop HTML markup and components, but it puts all those things in the block sidebars when the block is selected in the page editor. Yeah, once the blocks selected, then whatever HTML and components you add to the sidebar appear on the block sidebar on the right hand side.

And finally there’s a style screen. And that’s just basically a CSS editor that lets you put in CSS for your block. It’s completely optional. You don’t have to put any CSS there. You can, you know, enqueue CSS like you normally would through your theme or through a plug-in or however you’re most comfortable with it, but it’s there for people who want a really easy way to include CSS for their block.

And that’s kind of the process of building the block and then you hit save. And from there, you should be able to add it to a page.

[00:22:38] Nathan Wrigley: I’m going to, to sort of run over a few of those bits and pieces. And I’m going to draw an analogy for those of you who have used a tool like Advanced Custom Fields or Metabox or something like that. The similarities here are fairly striking to me in that the attributes that the sort of fields that you might create, so for example, you would like an image when you need an image attribute, you might need like a number attribute or a true / false, like you said, and you can set all of these different things up and then you move on to the next area.

And as Vinny was just saying, this is how it’s going to look when you’re user inserts it, what is it going to look like to them as they’re actually creating the block? And then interestingly, you’ve got the front end view. That’s what it will look like once it’s complete and you’ve published it and it’s visible to the world.

And then, like you said, there’s the sidebar so that you can modify all of the settings that may be associated with that. And then obviously the style. So I think if you’ve used Advanced Custom Fields or Metabox or something like that before, you’ll be very quick to the party. You’ll learn how this works really quickly.

I have to say having had the chance to play with it a little bit today, I went through the three step… building your first block tutorial, which I found to be really straightforward. Probably took me about an hour, I would say. And I was able to follow along with the steps and I had a completely functional block, fairly straightforward example. It has an image, it has a title, some text, and then ultimately there’s a button, depending on what text you put in that button appears. It doesn’t do a lot, but it’s a really nice way to get going. So I would say that if you’re confused by any of this, go and look for the support documents that Wicked Blocker Builder guide, and you want the building your first block section.

I think you’ve done a really great job of explaining how it all works there. Well done.

[00:24:31] Vinny McKee: Thank you.

[00:24:32] Nathan Wrigley: So the backend then handles all of that. I’m just curious. Is there any situation that you can imagine where the editor view, what it is that we’re doing in the backend to actually create the block on our website, where you would like that to be radically different from the front end view. Perhaps the editor view is going to be much more basic and stripped back. And then ultimately the view that people see on the website is going to be a bit richer. I’m just trying to figure out why those two sections are separate.

[00:25:01] Vinny McKee: Yeah. So I think part of it could come down to user preference and then another part of it might just depend on block output, starting with user preference.

It’s possible that some users might just have a preference where in the editor view, maybe they want almost more of a forum based approach to inputting the data for the block. So rather than displaying a rich preview of the block, maybe they just want to way for clients to input data. But then on the front end, of course, you know, it needs to be formatted properly or the way that they want to look. And that might be one example where you would create a separate view for the front end versus the editor view. I think another example is where maybe you needed the market to be different. So for example, say you want to create a grid, a block that displays a grid of, logos for example, and you want each logo to be linkable, and this might be a contrived example because there’s probably other ways that you could do it as well. But just as an example, let’s say you wanted to create a block like that, and you could, in the end of their view, add like an image component that would allow you to select an image for the logo. And then you could add a text field that would allow you to enter the link for the logo. But you may not want to wrap the image component within a link in the editor view because you don’t want it to interfere with being able to select an image, and when you’re editing the blocks. So maybe you want to tweak the markup for the front end. So then on the front end, it would actually wrap the image within a link element, if that makes sense. So that’s another example. And especially with the free version, because there’s no conditional logic, that would be one way you could achieve altering the markup.

[00:26:40] Nathan Wrigley: Actually, the more I think about it, the more that I can imagine situations where the two might be really useful to be separated. So I’m just at the minute been looking recently at real estate agent websites, and it might be quite useful if you had a block to do with a house and you were uploading all of the bits and pieces associated with that house, particularly the images. You might want those images to display in a really full on way on the website, large colorful, and what have you, and you may just want the thumbnail on the backend so that you can see that something has been uploaded, but you don’t as the person maintaining that block, you don’t actually need to see them in all their glory. But the person coming to the website, who’s thinking about buying that house would probably wish to see them in all their glory. So yes, I’m making in roads into what you’re thinking there, I think. Is that the right idea there?

[00:27:26] Vinny McKee: Yeah, exactly. That’s a great example. And I think similar to that, something like maybe a slide show or like a hero section where maybe it displays just one image, but changes on page reload or something. So on the front end, you really only see one image, but on the back end, you need to be able to add multiple images, but you might want to way to show which images are selected. So you might display those images in the block, on the back end, but then on the front end, you would only see one image at a time. But yeah, the example that you gave to you, I think is, perfect.

[00:27:54] Nathan Wrigley: Yes. So the tool itself is a very much a drag and drop tool. You’re dragging in components that you wish your block to have, be those images, text fields, buttons, what have you. Imagine you’re building up these Lego bricks to make your block.

There must be a little bit of understanding of various bits and pieces of web technologies. For example, I would imagine you at the very basic you would need to have some understanding of HTML in order for this to work. Is there a bare minimum set of things that you need to be able to understand, to make basic use of the plugin?

[00:28:29] Vinny McKee: Yeah, like you mentioned, I think you have to have a decent understanding of how HTML works and how tags are nested, because you do create the markup yourself in this plugin, it is drag and drop, but yeah, you do have to kind of understand how markup works and then to understand some of the attributes that certain tags support in that case block attributes, but you know, HTML attributes that are added to a tag in case you need to configure those. For example, if you want to add a simple anchor link to your block, you would add an a tag, and then you might add an href attribute. But if you haven’t worked with HTML before and don’t know that’s what’s required to create a link, then yeah, you might be a little lost or that might be a little challenging.

And then too, I think, to get good results, you do have to know some CSS because just adding, you know, most blocks I would imagine that you want to have some styling. And so, you know, in theory, you could just create a block that’s unstyled that allows you to input some content. And then of course it could output it on the front end, but without any styling, you probably wouldn’t get the best results or the results you want.

So I think it does require a little bit CSS knowledge as well, although I think, you know, you can get pretty far with just very basic CSS. So there, I think it just depends on how far you want to take it.

[00:29:45] Nathan Wrigley: Yeah, if you want something functional, which works, you can probably get away with minimal CSS, but if you want it to look nice, then yes, there’s going to be a little bit of a learning curve there. So I guess caveat emptor, if you are going to be looking into this plugin, there is a little bit going on.

Now, as with all tools that make something as straightforward as this does, I’m curious to know what’s going on in the background that you are relieving us the burden of. So for example, I’m adding in my attributes and that literally is a two second job. I basically click a button and add an attribute and then give it a name, an attribute name, something that I can remember and use later. And I can do that, and I could probably put five or six different attributes into my block in the space of just a couple of seconds really. Again, the same would be true with the editor view. I’m able to create all of those bits and pieces and link them up to the attributes that I made. What complexity are you stripping away? What difficult things are going on in the background? Now it may be that there’s too many to talk about, but I’m curious as to some of the challenges that you’ve stripped away.

[00:30:51] Vinny McKee: Yeah. So, I mean I think one challenge is just the whole build process that’s involved with creating blocks from scratch. So, because you’re using a plugin, it’s going to, based on how you build the block, it’s going to generate that block for you. And so you don’t have to worry about, you know, any command line stuff or knowing JavaScript or knowing React any of those things because you’re creating the block to the plugin.

So I think that’s one big thing that it addresses. Things like the attributes, it’s not hard to add attributes to a block when you’re building from scratch, other than takes a little bit of time to just to code them. But it does make it a little bit easier, I think, to be able to do it through an interface.

Something else it does as well is if you’ve created a block from scratch before, you’ve probably run into this where if your block is, let’s say you create your block and then your block is used on some pages and then say, you need to make some changes to the markup of the block. What happens is if you just make those changes to the block, you’ll actually, the next time you go to edit a page, you’ll see an invalid content warning, which is kind of scary because it looks like the block is broken and it doesn’t display correctly in the editor. And so in order to avoid that, you actually have to create a deprecated version of the block and then behind the scenes, what WordPress does, is it migrates the markup from that block that was previously added to the page, to the current blocks version or markup.

What Wicked Block Builder does is behind the scenes. Anytime you make changes to your block, it automatically creates a deprecated version of it. So that in the next time you go to edit a page that already has that block, it won’t display an error. And then there’s some other things too, like I was talking about before, how you can just create the edit view, and if you want to look the same on the front end, you don’t have to worry about that. It’ll just create the front end view based on the edit view that you created, so.

[00:32:45] Nathan Wrigley: Yes, I was quite pleased in the tutorial that you did that, just simply putting the CSS in and missing out the front-end view step altogether. Still the block looked great because, presumably it was working on what you’d put into the edit view and the CSS that was there, which was about 50 lines or something like that, made it look really nice.

Okay. So I guess the offering that things like page builders brought to the table is that it makes things much easier. Some people are critical of things like page builders. I’m sure there’s many other things that we could point the finger at, but you get the idea, because they say that the code that is output on the front end of the website might not always be the most optimal. And I guess this is one of the features that Gutenberg has, one of the poster features is that it creates lean code. I’m just asking the same question of you. The way that your building blocks, do you have anything to say about, does it create a block that is streamlined and optimally built or have you had to make concessions in order to achieve the sort of GUI aspect of it? In other words, if I knew everything there was to know about building blocks and I did the same block by hand, and then did it through your tool, would there be a noticeable difference in either of them?

[00:34:06] Vinny McKee: Yeah. So I can’t think of a notable difference offhand, other than instead of the block being pre-compiled the block is generated on the fly when it’s used in the editor. It creates a native block, and so yeah, whatever attributes you add, those are all translated to the attributes that you would code by hand. It only outputs markup that you add to the block. The only exception to that is for the components that you add. So if you add like an image component, for example. There’s a little bit of markup that it adds in the editor view to handle being able to select the image and display the image. And then of course, when it’s saved on the front end, if you don’t output or if you don’t specify specifically how you want the output to be for that front end view, then the image component will automatically generate an image tag. But yeah, for the most part, it only puts out whatever markup you define an add to your block, but yeah, as far as how the block functions and works. It’s identical to a native block. It just happens to be generated on the fly when you edit a page as opposed to something that’s compiled ahead of time.

[00:35:17] Nathan Wrigley: Yeah. Thank you. That’s a good answer. In terms of where this is all stored, one thing that’s coming to my mind is if I am an agency owner say, and I have a niche, let’s go for real estate, as we were talking about that a moment ago, and I’m building several websites every month. And I put a lot of work into creating a block with your tool. Is there a way that I can use these on a multitude of websites? Is there an option to export a block and then import it onto a variety of different sites? How does all that side of it work?

[00:35:51] Vinny McKee: Yeah. So that’s actually a really good question. At the moment in the plugin itself, there is no way to export and import blocks. However, those blocks are stored as a custom post type. And then the data for the block itself is saved in a post meta field and a json object. And so you can actually because it’s just another post type you can use WordPress’s default export functionality and export them that way, and then import them using the WordPress importer tool. Of course, important export is something that we have in the roadmap and something that I plan to add to the plugin. But yeah, right now it doesn’t have that functionality built in, but you can achieve it through the WordPress tools.

[00:36:31] Nathan Wrigley: That’s great. We’ll come back to the sort of roadmap, cause there’s a few items which I think are worthy of discussion and we’ll do that in a few minutes time. Staying with the actual plugin and how it works currently. I’m interested, you mentioned about things like conditional logic. I know this is getting into the territory, I think of the pro version, but nevertheless, would you just describe what that enables you to do? What kind of conditions are we able to display our blocks on?

[00:36:57] Vinny McKee: Yeah. So if you’ve ever used a form builder and wanted to, you know, only show a certain field, if another condition is true, that’s essentially what conditional logic allows you to do.

And you can apply these conditions to all sorts of things. So the way it works is when you add, for example, an HTML tag to your block, it’s actually, all of the parts of the tag are broken up. So you can add like classes in line styles, attributes to that tag. And because they’re split up that way, you can actually add conditions to each of those things.

And so what that means is say, for example, you want to add, conditionally add a class to a block, say for example, you have a block where maybe you want to give an option of you have an image on one side and then text on the other side and you want to provide the option to swap them. So by default the images on the left, text on the right, but you have an option to flip them. So that text is on the left and then the image is on the right. Yep. Let’s say you add it. You create a class that changes that layout. So what you can do is you can add that class to the block. It says image on, right, but instead of always outputting it to the block, you can add a condition that says, okay, only add this class if the option display image on right is checked.

And so, so that’s an example, and then you can also use it to conditionally output tags. So what I was talking about before, where maybe you, you don’t want to output an image wrapped in a link tag on the back end, but you do on the front end. You could add some conditional logic to the tag itself and say, okay, only I’ll put this tag, you know, if this is true, or, and then there’s also conditional logic to show or hide things based on whether or not the block is selected in the editor. So things like that.

[00:38:41] Nathan Wrigley: The brain is ticking over all the different possibilities there. That sounds really ingenious. One of the things that I always thought would be nice if I were a plugin developer, which I am not, is it would be nice to see my plugin out in the wild being used by people and the curious and interesting ways that they can implement the plugin. And I’m wondering if you have any little anecdotal tales of people who’ve used your plugin and remarkable things that they may have done with it that perhaps you didn’t anticipate.

[00:39:10] Vinny McKee: Yeah. That’s a good question. I don’t know that I have any yet, because I just released the plugin in November. And so it really, yeah, I don’t know that I’ve had anyone reach out with any particular ways that they’ve used it. I guess I’ve had maybe some questions about how to do some things that I hadn’t thought of before. And so it made me realize that, oh, okay here’s another way that people might want to approach things.

[00:39:35] Nathan Wrigley: To be fair, I didn’t realize it was as new as that. So yeah, that’s absolutely fine. Like I said, right at the top of the show, there is a different pro version. The pro version, we won’t get into the actual pricing because it may be subject to change who knows, but there are three options. You can go for single site license, a 10 site license and the unlimited site license. So three different options. Of course you can. If you’d like stay on the free wordpress dot org repository version. That’s absolutely fine.

The last little bit, just before we tie this off is the roadmap. And obviously you’ve had some feedback. You’ve just described some of the things that have come back to you from your customers. Apart from the import and export which we talked about already, what are you hoping to be adding in the near term?

[00:40:20] Vinny McKee: Yeah. So in the near term, one thing that’s been requested multiple times or quite a bit is the ability to assign an icon to the block. I’m planning to add that in as well as, there’s also been requests to add more options as far as, so blocks what’s called these support features or these support flags where you can say, okay, this block supports something like an anchor so that you can in the block sidebar, you can add like an anchor and that’s something that’s kind of WordPress adds automatically, if the block says that, okay, I support this or things like topography, you can have font size and line height support, or you can add spacing support for things like padding and margins. So just adding some more settings so that you can enable those things for your block. And then of course adding more component types. So right now there’s all the basic ones you would expect, but then adding some more, like for just more component types. So you have more options of how you build your block. And then I would also like to add an ability to save the blocks as a json. So to like a folder within your theme or wherever you decide. The blocks when you create them in the interface, they would get saved to the database like they do now, but they would also get saved to a local json file. And so that way developers could commit their blocks to version control so that they kind of have so that they can version control their blocks. And that’s kind of what I’m hoping to add in the near term.

[00:41:43] Nathan Wrigley: Just something which has occured to me just as you were saying those things, there’s an increasing commercial marketplace for blocks, not as is the case with yours, the block builder, but the blocks themselves. There might be a marketplace for relatively inexpensive blocks, which do a single thing and do it really well.

And I was wondering if there’s any possibility from your plugin to commercialize the blocks that you make? I don’t know if that’s possible, even something you’re giving any thought to, but if I spend a lot of time creating a block that’s incredibly complicated and it has some value, with your tool, would there at any point ever be options to pull that out and make it available commercially.

[00:42:27] Vinny McKee: So I think the challenge right now is it in order for it to work, you do have to have the plugin to generate the blocks. So if you create the block and then export it and import it on another site, it’s only going to work if you have the plugin installed. I do think it would be really cool is if there was a way to actually export the block code. So that you could just import the block without having to have the block builder plugin installed. But I also think that’s a fairly complicated feature to build. So probably not something that I’ll be able to add soon, but I think if that were available, then yeah, there would be a way then that you could create blocks using the tool and then publish them and be able to distribute them without having to have the plugin in order to use the block.

[00:43:13] Nathan Wrigley: Well, thank you very much for joining us today and talking about your fabulous tool, Wicked Block Builder. As I mentioned, there will be links in the show notes down below to the repository version, as well as the Wicked Block Builder website as well. But Vinny really appreciate you coming on today.

Just prior to ending, if people are curious about what you’ve talked about today and wish to reach out to you, what are some of the best ways to do that?

[00:43:40] Vinny McKee: So, you can find me on Twitter @wickedplugins, or you can also contact us through our site at wickedplugins dot com.

[00:43:48] Nathan Wrigley: Thank you very much. I appreciate you joining us today.

[00:43:50] Vinny McKee: Thanks for having me, Nathan.