Learn how to add a podcast to your WordPress blog.

A podcast is a combination of iPod and broadcasting. It is a medium that allows individuals to distribute audio content to a wide range of listeners. This innovative form of communication has gained immense popularity in recent years. It provides a unique platform for individuals to share their thoughts, ideas, and stories through captivating audio […]

400: Hiatus

Marie and I jump on the show to tell y’all we’re taking a little break! It feels like years since we’ve been eluding to the fact that we’re working on a new major upgrade to CodePen. Rather than keep dancing around it, we’re going to minimize or remove working on anything that isn’t working on that. We can’t wait to come back for episode 401 and tell you all about it.

Time Jumps

  • 00:14 Welcome
  • 00:56 What’s happening with CodePen Radio?
  • 02:13 Early days of CodePen Radio
  • 04:43 Sponsorship simplified
  • 07:20 Sponsor: Split.io
  • 08:06 Documenting the history of CodePen through the podcast
  • 10:35 Funny stories from past episodes
  • 13:34 The next phase of CodePen
  • 15:19 Thanks for listening

Sponsor: Split

This podcast is powered by Split. The Feature Management & Experimentation Platform that reimagines software delivery. By attaching insightful data to feature flags, Split frees you to quickly deploy, measure, and learn the impact of every feature you release. So you can safely deliver features up to 50 times faster and exhale. What a Release.

Start raising feature flags (and lowering stress). Visit Split.io/CodePen for a free trial.

The post 400: Hiatus appeared first on CodePen Blog.

399: Data Munging

There was a small problem in our database. Some JSON data we kept in a column would sometimes have a string instead of an integer. Like {"tabSize": "5"} instead of {"tabSize": 5} of the like. Investigation on how that happened was just silly stuff like not calling parseInt on a value as it came off a <select> element in the DOM. This problem never surfaced because our Rails app just papered over it. But we’re moving our code to Go in when you parse JSON in Go, the struct type that you parse it out into needs to match those types perfectly, or else it panics. We had found that our Go code was working around this in all sorts of ways that felt sloppy and inconsistent.

One way to fix this? Fix any bad data going into the DB, then write a script to fix all the data in the DB. This is exactly the approach I took at first, and it would have absolutely fixed this problem.

But Alex took a step back and looked at the problem a bit wider, and we ended up building some tools that helped us solve this problem, and solve future problems related to this. For one, we built a more permission JSON parser that would not panic on something as easy to fix as a string-as-int problem. This worked by way of some Go reflection that could tell what types the data was supposed to be and coerce them if possible. But what should the value fall back to if it’s not savable? That was another tool we built to set the default values of Go structs to be potentially other values than what the defaults for their types are. And since this is all in the realm of data validation, we built another tool to validate the data in Go structs against constraints, so we can always keep the data they contain good.

Once all these tools were in place, the new script to fix the data was much easier to write. Just call the safe JSON function to fix the data and put it back. And the result is a cleaned up code base and tools we can use for data safety for the long term.

Time Jumps

  • 00:29 How can we fix the problem forever?
  • 03:53 Chris becomes a Go-pher
  • 15:04 Building rules that will work for anything, not just this situation
  • 18:54 Setting up proper testing is huge
  • 20:19 Sponsor: Intelligent Demand
  • 21:06 Testing for pointers
  • 25:18 Using GORM
  • 27:08 Supabase postgresDB

Sponsor: Split

This podcast is powered by Split. The Feature Management & Experimentation Platform that reimagines software delivery. By attaching insightful data to feature flags, Split frees you to quickly deploy, measure, and learn the impact of every feature you release. So you can safely deliver features up to 50 times faster and exhale. What a Release.

Start raising feature flags (and lowering stress). Visit Split.io/CodePen for a free trial.

The post 399: Data Munging appeared first on CodePen Blog.

398: DevOops

Stephen and I hop on the podcast to chat about some of our recent tooling, local development, and DevOps work. A little while back, we cleaned up our entire monorepo’s circular dependency problems using Madge and elbow grease. That kind of thing usually isn’t the biggest of deals and the kind of thing a super mature bundler like webpack deals with, but other bundlers might choke on. Later, we learned that we had more dependency issues like inter-package circular dependencies (nothing like production deployments to keep you honest) and used more tooling (shout out npx depcheck) to clean more of it up. Workspaces in a monorepo can also paper over missing dependencies — blech.

Another change was moving off using a .dev domain for local development, which oddly actually caused some strange and hard-to-diagnose DNS issues sometimes. We’re on .test now, which should never be a public TLD.

Time Jumps

  • 00:26 Dev ops spring cleaning
  • 01:25 Local dev with .dev, wait, no, .test
  • 06:58 Sponsor: Notion
  • 07:54 Circular dependency
  • 11:41 Monorepo update
  • 13:35 Interpackage and unused packages
  • 16:25 TypeScript
  • 17:54 Upgrading packages
  • 20:35 Hierarchy of packages

Sponsor: Notion

Notion is an amazing collaborative tool that not only helps organize your company’s information but helps with project management as well. We know that all too well here at CodePen, as we use Notion for countless business tasks. Learn more and get started for free at notion.com. Take your first step toward an organized, happier team, today.

The post 398: DevOops appeared first on CodePen Blog.

397: User-Generated Content Saftey

I was asked about the paradoxical nature of CodePen itself recently. CodePen needs to be safe and secure, yet we accept and gleefully execute user-authored code, which is like don’t-do-that 101 in web security. Marie and I hop on the show to talk this through as an update from quite a long time ago. It’s wonderfully-terribly complicated. Part of what complicates it is that there are many different kinds of worrisome code, from malicious, to distasteful, to spam, and they all need different treatment. This is a daily and never-ending war.

Time Jumps

  • 00:27 Listener question
  • 04:09 Browsers have gotten safer
  • 06:18 Sandboxing
  • 09:31 Sound in the browser
  • 11:19 Sponsor: Notion
  • 12:21 It’s not always bad actors, but sometimes it is
  • 15:35 SEO spam
  • 19:27 The threat of Google blocking
  • 20:31 Tooling to stop bad behaviour

Sponsor: Notion

Notion is an amazing collaborative tool that not only helps organize your company’s information but helps with project management as well. We know that all too well here at CodePen, as we use Notion for countless business tasks. Learn more and get started for free at notion.com. Take your first step toward an organized, happier team, today.

The post 397: User-Generated Content Saftey appeared first on CodePen Blog.

396: Open Source

Robert and I jump on the podcast to have a little chat about open source generally and what we do with open source at CodePen. CodePen itself is not open source, aside from the small bits we’ve made public and the open-source things we include within it. But all Public Pens on CodePen are open source, so we certainly handle a lot of it! Enough that I felt comfortable making our Mastodon presence on Fosstodon, which is an open-source-focused instance.

Time Jumps

  • 00:40 Open source as a topic
  • 03:09 CodePen and open source
  • 10:05 Sponsor: Split
  • 10:46 Contributing to projects and maintaining projects
  • 16:07 Next 13 open source issue
  • 22:27 Open source outside of GitHub on to Discord

Sponsor: Split

This podcast is powered by Split. The Feature Management & Experimentation Platform that reimagines software delivery. By attaching insightful data to feature flags, Split frees you to quickly deploy, measure, and learn the impact of every feature you release. So you can safely deliver features up to 50 times faster and exhale. What a Release.

Start raising feature flags (and lowering stress). Visit Split.io/CodePen for a free trial.

The post 396: Open Source appeared first on CodePen Blog.

395: The Most Hearted of 2022

Marie and I hop on the show to discuss our recently released Most Hearted of 2022 Pens. We only did the calculations the day before, so this is more of a first reaction than a deep dive.

  • Congrats to Hyperplexed for #1 and a massive year on CodePen. Last one entry on the Top 100, and this year, nine. “Full layouts” like this appeared a number of times, including Aysenur Turk, last year’s winner, at #13 with Liquid Transition Effect, and there were two NFT-themed landing pages (1, 2) in the Top 100.
  • A lot of Pens attract attention when they have that “I could use this” feel to them, demonstrated by Ryan Mulligan’s Logo Wall at #2!
  • High five to Greensock for taking #3 with a re-creation of Brian Cross’ lovely Pen. The tag “gsap” was used a ton in the Top 100.
  • Jon Kantner took #4 and 10 other spots making this the most appearances on the Top 100 list ever, and also took a spot with a Pen made on December 13th! Aaron Iker and Yoav Kadosh both had 4 spots.
  • Perhaps my favorite because of the deep CSS trickery involved was Scott Kellum’s Apple inspired pride clock. Scott has the oldest account of anyone in the list, over 10 years old! Huge fan of Steve Gardener’s joke, though as well.
  • 11 of the Top 100 were created for CodePen Challenges.

Time Jumps

  • 00:23 The rules of the game
  • 05:13 Grinch style hearting reminder
  • 06:34 Number one on the list
  • 10:24 Sponsor: Notion
  • 11:12 Logo wall
  • 12:52 Greensock scrolling site pen
  • 14:40 NFT landing pages
  • 16:25 11 appearances by John
  • 17:30 Shaw made the list
  • 19:09 Challenge pens made the list
  • 22:16 New CodePen members on the list
  • 23:25 Longest CodePen member on the list
  • 25:09 Elements that are popular
  • 27:44 Spider pens
  • 29:37 Snowball pen

Sponsor: Notion

Notion is an amazing collaborative tool that not only helps organize your company’s information but helps with project management as well. We know that all too well here at CodePen, as we use Notion for countless business tasks. Learn more and get started for free at notion.com. Take your first step toward an organized, happier team, today.

The post 395: The Most Hearted of 2022 appeared first on CodePen Blog.

394: Very Remote Work

Rach lives in Australia, so for our otherwise U.S.-based team, that’s about as remote as it gets. We’ve always been remote at CodePen, so we have it built-in to our culture already, but that doesn’t mean we don’t have to plan for it, think about it, and adjust things to make sure we’re all doing the best we can. Writing is a fundamental aspect of it all, but even that is funny sometimes because you have to choose where those words will go that make the most sense. Right now, it’s a balance between Notion, GitHub, Slack, and even our codebase itself.

Time Jumps

  • 00:27 The Rachel Smith
  • 01:09 CodePen is all remote
  • 02:32 Timezone and physically remote
  • 07:42 Unblocking yourself remotely
  • 12:53 Sponsor: Intelligent Demand
  • 13:42 Communication
  • 21:01 Pull request issues
  • 22:30 Meetings
  • 27:12 Flexible work hours

Sponsor: Split

This podcast is powered by Split. The Feature Management & Experimentation Platform that reimagines software delivery. By attaching insightful data to feature flags, Split frees you to quickly deploy, measure, and learn the impact of every feature you release. So you can safely deliver features up to 50 times faster and exhale. What a Release.

Start raising feature flags (and lowering stress). Visit Split.io/CodePen for a free trial.

The post 394: Very Remote Work appeared first on CodePen Blog.

393: Challenges in 2022

Marie and Chris talk about the year in CodePen Challenges. If you participate, this might be an interesting look into how we think about them. If you don’t, it might help you understand what they are and how they might just tickle your fancy.

Time Jumps

  • 00:22 Challenges explained
  • 02:53 Challenges are growing
  • 04:02 Types of challenges
  • 07:47 Discovering people through challenges
  • 10:07 Sponsor: Split
  • 10:54 Fixer Upper challenge
  • 14:07 Wide and generic vs specific and niche
  • 18:11 Using collections
  • 21:12 Behind the scenes of challenges

Sponsor: Split

This podcast is powered by Split. The Feature Management & Experimentation Platform that reimagines software delivery. By attaching insightful data to feature flags, Split frees you to quickly deploy, measure, and learn the impact of every feature you release. So you can safely deliver features up to 50 times faster and exhale. What a Release.

Start raising feature flags (and lowering stress). Visit Split.io/CodePen for a free trial.

The post 393: Challenges in 2022 appeared first on CodePen Blog.

392: Project Management Refresh

Dee and Chris chat about our latest take on Project Management (PM), a somewhat tricky topic for us with such a small team where literally everyone is an individual contributor (IC) with a lot on their shoulders aside from PM.

We’re attempting a project of large scale, so part of what has helped us so far is scoping the project into phases releases. That way work that we know is in a later release can be put off until we’re literally working on that release. Without at least that prioritization, things would take much longer. The releases are also chunked into sub-projects with a no-too-little and not-too-big quality, and within those projects is where the kan-baning happens. If we can keep the whole team on one project (or at least a group of 2-3), it limits the context switching which also helps speed and productivity.

We use Notion for most of this work, and it’s been nice to keep literally all of it (all the way up through all the phases) in one big database, then we scope the views down to phases and projects and cards. Each card we make sure has a very actionable tone to it and includes everything one might need to finish the task, including decisions, previous conversations, relevant other tickets, etc. Each card has things you might expect like who is working on it, the current status, whether it’s blocked or not, and several other useful bits of metadata. It also contains time estimates, so we can, at a glance, see how far we’ve come and what’s left on any given project. We know things like time estimates can change quite a bit, but everyone is well aware of that and isn’t beholden to the numbers. It just gives us some idea of what is going on other than feeling like we’re entirely driving blind. Each week we take a look at the progress together as a team.

Time Jumps

  • 00:21 API follow up
  • 02:10 The topic: Project Management
  • 04:05 Why we need to manage our project(s)
  • 05:06 What did we do with Notion?
  • 11:03 Beta means database is safe
  • 11:55 How do we organize around projects?
  • 15:54 Sponsor: Split
  • 16:41 Alpha vs beta vs final
  • 22:43 What are the fields inside Notion we’re using?
  • 32:21 Connecting to GitHub as well

Sponsor: Split

This podcast is powered by Split. The Feature Management & Experimentation Platform that reimagines software delivery. By attaching insightful data to feature flags, Split frees you to quickly deploy, measure, and learn the impact of every feature you release. So you can safely deliver features up to 50 times faster and exhale. What a Release.

Start raising feature flags (and lowering stress). Visit Split.io/CodePen for a free trial.

The post 392: Project Management Refresh appeared first on CodePen Blog.

391: Early TypeScript at CodePen

TypeScript ain’t exactly new, but it’s a bit new to us. Robert was the most knowledgeable about TypeScript on the team and felt like it could be valuable for us. What does that mean though? Where would we use TypeScript? What blockers were there? What does it actually help with? The implementation hasn’t been trivial, so has it been worth it? Will it be worth it? Robert, Chris, and Stephen discuss.

Time Jumps

  • 00:29 TypeScript in production
  • 02:47 Why TypeScript?
  • 08:51 Baby steps into TypeScript
  • 15:57 How it’s worked out
  • 20:00 Type vs Prop Types
  • 25:43 GraphQL, Go, and TypeScript
  • 28:37 Getting used to TypeScript

The post 391: Early TypeScript at CodePen appeared first on CodePen Blog.

390: The Social Media Zeitgiest

Marie and I talk about what’s going on in the world of social media, and what that might mean for CodePen and front-end developers. Twitter doesn’t feel particularly healthy at the moment, but has been the biggest player for front-end developers for a lot of years. Are we moving? Not? Where?

Time Jumps

  • 00:14 Zeitgeist
  • 01:55 WTTwitter
  • 04:11 Frustration with Twitter
  • 06:55 Twitter is where you find out what’s happening
  • 09:34 Why are we talking about Twitter?
  • 12:58 Mastodon
  • 24:30 Going to Reddit
  • 27:37 RSS and blogging
  • 35:15 CodePen is social, but not a new Twitter

The post 390: The Social Media Zeitgiest appeared first on CodePen Blog.

#50 – Fränk Klein on How Gutenberg and Full Site Editing Are Bringing New Opportunities for WordPress Developers

Transcript

[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 future looks like for WordPress developers.

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 forward slash feed forward slash 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, well I’m keen to hear from you and hopefully get you, or your idea featured on the show. Head over to WPTavern.com forward slash contact forward slash jukebox, and use the form.

So on the podcast today we have Fränk Klein. Fränk is a self-taught developer. He started out learning PHP in 2011, and from there found his way to WordPress. Over the years he’s worked for Automattic at wordpress.com, and WordPress VIP, and is now a principal developer at Human Made, an enterprise WordPress agency.

Today on the podcast we talk about how Fränk decided early on that he was going to start developing with blocks and, more recently, with the full site editing capabilities now built into WordPress Core.

We talk about the four phases of the Gutenberg project, content editing, site customization, collaborative editing and multi-lingual, and where full site editing fits into this.

Fränk explains how he sees the adoption of Gutenberg as inevitable. WordPress is moving away from the classic approach of content creation, to a more visual, block based experience. He thinks that it’s important to become an expert at building websites and custom solutions for clients, and for taking the time to learn the new tools that this future will require.

He’s not suggesting that the journey towards expertise in React and JavaScript will be easy, but he does see it as essential for those wishing to continue to use WordPress as their CMS of choice. He also makes the point that now is a great time to invest in yourself as there are more resources than ever, which can assist you in this learning path.

As you’ll hear, Fränk is all in on WordPress, and is very optimistic about the future for experienced WordPress developers.

If you’re interested in finding out more, you can find all of the links in the show notes by heading over to WPTavern.com forward slash podcast, and you’ll find the other episodes there as well.

And so, without further delay, I bring you, Fränk Klein.

I am joined on the podcast today by Fränk Klein. Hello Fränk.

[00:03:34] Fränk Klein: Hey there. How you doing?

[00:03:35] Nathan Wrigley: I’m very well, thank you. It’s very nice to have you on the podcast. We typically at the beginning of the podcast orientate the listeners by asking a very basic and simple question just to tell us who you are, what your relationship is with WordPress, how long you’ve been working in the space, possibly the company that you now work for, and all of that goodness. So, Fränk, it’s over to you.

[00:03:54] Fränk Klein: So my name is Fränk Klein. I live in Luxembourg in the heart of Europe, and I got started with WordPress in 2011. So that’s when I started programming. So the background is that I’m actually a print designer, which at that time, wasn’t really that much of a bright career path. So I switched to programming, bought myself a PHP book, and then discover WordPress, and that’s been my passion ever since.

And, I kind of have a varied background because I was in a small agency, still in Luxembourg. Worked for Automattic as part of the wordpress.com theme team. I worked at WordPress VIP, and then now I’m at Human Made, which is an enterprise WordPress agency where I’m a principal engineer. And so as part of that is my passion has been WordPress, but I also have a big interest in the wider web ecosystem, and so that’s why there is my interest in everything block related.

[00:04:51] Nathan Wrigley: Okay, and that’s going to be the basis of our conversation today. So Fränk’s here to talk about Gutenberg in general, but more specifically about full site editing. And I think probably a good way to begin the conversation to, again, provide a bit of orientation, is just to run through the history of the Gutenberg project and now full site editing. So I don’t know if you are willing to do that. Run through the history of when it all began and what the phases are and so on.

[00:05:17] Fränk Klein: Yeah, so, I think when we talk about full site editing, we cannot forget the wider picture, and that is that full site editing is part of the Gutenberg project, which Matt Mullenweg, the WordPress lead started back in 2017. And the idea behind Gutenberg was really that WordPress ran its course in the way that it was at that time, in that there needed to be a ground up reimagining of a lot of the core components that make up WordPress.

So therefore, there are four phases. The first one is content editing. So that was in 2018 when WordPress 5.0 introduced the block editor, or the content editor how I prefer to call it. Then the next step is site customization. Part of it was in 5.8, but most people will know it from 5.9 when full site editing was introduced.

Then the next phase, which they are starting right now is collaborative editing. So Google Doc style editing of different people on the same content. And then there will be multilingual. So that’s the big picture of the Gutenberg project. And so, full site editing is just part of this. And so the thing about these phases is that the content editing phase that was, by now four years ago, but it’s not really finished because the content editing experience still gets upgrades. It gets stuff added to it. And so that’s how this project is laid out. And even if we now roll into the collaboration full site editing isn’t done, and they will continue to work on it for the future.

[00:06:43] Nathan Wrigley: If we were to roll back the clock prior to Gutenberg, so let’s say, 2015 or something like that, and there were people at that point who were using just the classic editor, they were maybe putting just content in or short codes and page builders and so on, came along. What do you think was the point of having all of this in core?

In other words, it could be left to third parties, it could be plugins or it could be themes that took on the job of the way that your site was presented. What is the promise? Deep down, what’s the sort of kernel of Gutenberg? What is it offering? Where are we headed with it?

[00:07:18] Fränk Klein: This is kind of where the, the bigger picture comes in because, when we just talk about full site editing, it’s called the site customization phase. It’s not called page building phase. It’s not called theme building phase. Those are all things that you can do with full site editing. But really the idea behind full site editing is, there was the customizer, right? So that was the way that you interact with your theme, and that didn’t work out. I think the promise that the customizer had in the beginning didn’t pan out to be what people wanted to be. And so then the idea was that we have something better, which is built up on this concept of blocks.

And so the thing that makes full site editing and then, the customizer very different is that, the customizer, the idea was there was this tool and there are only minimal controls available, and if you want to have your own, there are just APIs and a builder. And so the problem was that everybody built their own controls, and then there was other confusion for users, and themes weren’t compatible with each other.

And then the site editor, or just say the Gutenberg project in general takes a very different approach, in that it says, we’re going to give you a lot of customization options, controlling fonts, controlling colors. And beyond those options, this is like the full menu of everything you can do, we give you the APIs to preset these things, to remove them, to customize them. And so the bigger context here is that this is a customers replacement for the moment, but it also allows you to build new templates.

And the idea is that many of the menus that we have in the WordPress admin are going to be rolled into the site editor. So for example, reading, settings, things like that. There are definitely concepts already exploring how that could be part of the site editor. So really, when we talk about even collaborative editing, that’s going to require changes.

Multilingual is going to require changes. That all is just wrote into this Gutenberg project, of which full site editing is one part. The promise is kind of that based on this concept of blocks, we are going to be able to reimagine how people interact with WordPress, both as users and also as developers. And it’s going to be done much more through visual interfaces that are a lot easier to understand and to work with.

And that way really we’re going from the old word of WordPress to the new WordPress, which is then going to be able to be around for a decade or more. So that’s the big picture vision behind the whole project.

[00:09:48] Nathan Wrigley: Yeah, sort of future proofing if you like. Given all of that, let’s just put the conversation about blocks to one side and about what they offer, we can come back to that in a few moments. I want to talk just for a moment about how it is that such a large proportion of the community, and when I say large proportion I don’t really have any figures. Not claiming it’s 10, 20, 50, 70, whatever. Percent, but there’s been a certain amount of people within the WordPress community who have not got such an optimistic approach to full site editing and the Gutenberg project more broadly. In many cases, they don’t really want to have much to do with it.

They’re happy with the tools that they’ve got, and they’re happy with the systems that they’ve got in place, whether that be a page builder or whatever it is. I’m just wondering if you have any thoughts on how the communication went, introducing Gutenberg and full site editing. Do you think that the promise was explained from the beginning? Maybe the promise wasn’t fully realized. Or do you think that there were some PR missteps along the way.

[00:10:49] Fränk Klein: Well, yeah. There’s several parts of it. I think that when Matt introduced it, he wrote this post called we called it Gutenberg for a reason, and that very much painted a broad picture. In my opinion it went a little bit overboard comparing it to the invention of the printing press. It’s just my personal sentiment about it, that’s maybe overdoing it by a lot. But he definitely had this vision where he explained what problems this project was trying to solve.

And that was around for a bit. And then we went right into the details. So the block editor was introduced, all these APIs, and so at that point we just focus very much on the what, and not the why. Why is this there? And instead of just saying, hey, here’s this paragraph block, and it works this way. There never was really a step taken back in where there was an exploration of, here are these tools and these are all the possibilities that you now have with these tools.

And to adapt that to the different profiles that we have in the WordPress space, because we have end users, we have power users, we have theme developers, plugin developers. And kind of this translation from the nitty gritty to the bigger picture and also let’s say the potential that is there, because there definitely is a lot of potential. That was missed, unfortunately, and I think that’s why, if all you just see is a bunch of stuff getting thrown in your face and nobody really explains to you what you’re supposed to do with it, and why they’re adding all it. Then unfortunately that’s, I think the situation where we were in where just a large part of the community didn’t see the point. And so the project is doing a lot more of trying to fix these mistakes. So they are a lot better about showcasing the things that you can do. So I’m very hopeful in that, that we’ll get to those bigger picture conversations.

[00:12:37] Nathan Wrigley: I guess, for me at least, when Gutenberg rolled into Core, it came with some default blocks, which you could use. But they very much were the kind of things that you could have done and could have achieved in all the previous versions of WordPress. So you could put in a paragraph and whilst you could move that paragraph independently, it was still a paragraph. And so not tremendously exciting. And the same with images. You’ve always been able to do something similar to that. I’m just wondering if there was a wow moment that got missed there.

In other words, when that came into Core, right at the beginning, if some bizarre, let’s use that word, some bizarre, extraordinarily clever block could have been shipped, just to give everybody that aha moment. But it didn’t happen that way. We just got a fairly ordinary pallet of blocks to choose from. And so people perhaps got disinterested and never came back. And now we’re in the process of trying to show people what those aha moments are.

And certainly from my point of view, I’ve. Implementation’s left, right and center of really incredibly difficult and complicated things built inside a really small, tiny UI in the block editor, and it is amazing. But I, I do wonder if that moment was missed and it’ll be difficult to ever get that excitement back?

[00:13:52] Fränk Klein: Well, I think there are two parts with it. I think that one might discuss the point at which the block editor was introduced. So for sure, in the beginning it was a bit rough. And so if already having trouble to have the time to find polish, to polish this product, they probably didn’t have the time to build a lot of showcasing tools because they were just trying to get this done to include it into Core.

Okay, this was the situation and it is how it is. They could at least showcase the potential of in, blog posts after the release. But I think the big opportunity that was lost is just to look at the ecosystem and just to go out to agencies, product companies, whatever, that were using blocks and to take the things that these people were building and then to show it.

I think that’s a big missed opportunity. Just a case study. This was the problem and this is the solution that was developed, and this is the reason why it was developed. And these are the outcomes. Right, so talking much more in business language, not really in they used this API and that API, which might change and which is really not interesting.

There was a lot missed on that. I know we have the state of the world and then there is a maybe three second slide for some project which was super impressive. But all it gets is this three seconds in the presentation. Frankly speaking all people don’t even watch. So I think that was a big opportunity which got missed.

[00:15:12] Nathan Wrigley: In your learning about the construction of blocks and all of the different technological pieces that you had to acquire along that road. How difficult has that journey been for you? So, Let’s say, for example, there’s somebody listening to this, and by the end of this they are indeed convinced that this is the way to go. What’s the learning path like? Did you find that to be a fairly difficult experience? Was there a lot to learn that meant that you couldn’t progress until you’d got over several hums? Was it easy, was it hard? What was it like?

[00:15:39] Fränk Klein: Well, I was lucky enough to already know, let’s say modern JavaScript in quotes and React, before I start with blocks. So that’s definitely a big hump to get over if you are coming from a traditional PHP background and you, you know, maybe write jQuery, some of it, but, uh, you don’t really have a lot of JavaScript affinity. That’s actually one big issue.

Just building the blocks was rough when I did it, because it was so early. I think the first project that I did, it was still with the Gutenberg plugin, like it was before 5.0. But I think that at this point it’s a lot easier. It’s just that the documentation has got a lot better. There are tons of material for people to learn this. But over time my thinking has shifted on that, because if you would know how to build a block, like technically speaking, that’s good, but this is really just the base level. The challenge really is to, how do I design all the experiences for my users, my end users, so that they fit into this paradigm.

So you can have a custom blocks that works, that’s entirely PHP rendered. You might have JavaScript run in the editor. You might add a plugin to the editor. You might have a custom control. You might have customizations of core blocks. And that’s really knowing all of these tools that are available and when to use them, how to use them. That’s really the difficult part.

That being said, I think that, for me it’s always, even when it’s difficult, I kind of have the opinion of this is why I get paid. I get paid to solve the hard issues. And so if there is a hump to get over, I am, I’m ready to do it. But I think just in the wider picture, you need to just start doing it, and just keep doing it, even if it’s frustrating, because that’s just how it is with anything. If you try and learn the guitar, I’m going to tell you it’s not going to be easy. But you just need to keep with it. And then over time this will just become second nature.

Because that’s also the question, you know, it’s the chicken and egg problem somewhat, is well, how do I become a JavaScript developer? Well you write a lot of JavaScript. You know, honestly, that’s how easy it is. It’s just like doing pushups. You wanna be good at doing pushups, you need to do a lot of pushups. That’s pretty much the solution. And once you accept that there is no magic solution that will just come down and allow you to continue to write PHP, and take advantage of all of these new opportunities. That doesn’t exist.

I know a few projects out there say that you can write PHP and you will have will all of the capabilities to build blocks, but that’s definitely not the case. So it’s just a matter of taking the decision to learn it and then sticking with it. But I have a actually a tutoring program for building blocks. All it takes is six weeks, but it’s going to be intense, six weeks. But after that you know the basics. Then we can move on to the more important things, which are the experiences that you should build for your end users.

[00:18:27] Nathan Wrigley: I will definitely link in the show notes to your WPdevelopment.courses website, where you can go and check out what Fränk’s got on offer there and, the six week program. I think there’s a couple different things on the website, but we’ll definitely link to that. But do you feel sanguine now that there’s more information out there that, it is now possible? And in the day when you were doing it, it was probably more of a slog than it is now. Where do you turn to when you’ve got problems? Is it colleagues? Do you turn to friends, relations? Who are you looking towards when you are trying to solve the problems in your own work?

[00:19:00] Fränk Klein: Colleagues, so I’m very lucky to have a lot of colleagues that are a lot better than I am in different things. And that’s really the magic of being in a larger company. I know that if I struggle with this piece, I go to this person. If I struggle with that thing, I go to this other person.

So I’m very lucky with that. That being said a lot of the problems that I encounter very much also React or JavaScript problems, so there’s always the wider ecosystem for that. I do think though that even if you are alone and all you have is just the official documentation, it is entirely possible to learn this. And I’m very upfront with, when I have a program or a course, I’m just selling you a time saver. I’m saving you time and frustration, but you definitely could do it with just the default stuff that is out there.

And I think that the WordPress learn website, they’re adding more and more stuff to it. Of course, it’s not as polished as something which is really starting to end a learning path. That’s just the downside of this being free documentation. But it is definitely possible to learn. And especially when we talk about just the people that want to get maybe deeper into JavaScript and React. There’s a ton of courses out there where people teach you that stuff, which are great and not very expensive.

So I think the difference between, when we got started, 5.0 and now, it’s night and day. It’s not even comparable how much easier it is to learn blocks right now. And, we mustn’t forget that. I see it every day, inside of Human Made and also in community. There are people learning it from all kinds of backgrounds.

Even people that would say that they aren’t really developers. So it’s not like there is some secret source or something that you need to be born with to learn. This is very achievable. But again, you need to put in the work and the time to achieve it.

[00:20:41] Nathan Wrigley: Yeah, achievable, but there will be some element of struggle along the way. But it’s nice to know that there are options out there. And you mentioned Learn, and like I said, we’ll link to the bits and pieces that you provide as well. You are clearly very into all of this. This is something that you’ve staked your future on, I guess to some extent. You’ve learned all of these skills and how do you feel about the broader picture for people in the future?

So agencies, freelancers, and what have you, who have yet to embark on this journey and are still doing things in the way that they have been doing. Do you see that the future for them is going to be more difficult in the work that you do? Do you see that the potential is paying off? Are clients coming to you and you are able to build things more quickly, potentially have a user interface which they like more, and so on? I just wondered what your thoughts were about the future for freelancers, agencies, and and so on.

[00:21:33] Fränk Klein: I think that when we talk about the work that I do, we have the chance to work with bigger budgets, so that gives us a lot more, let’s say free space to build out certain things. But, the thing inside Human Made is that Human Made hasn’t built a website without blocks ever since the block editor got introduced.

That was just the default, because we saw the problems that this was solving. Because the classic editor, for our clients, even the clients in the publishing industry, like it didn’t work. We were having solutions to deal with certain issues, the workarounds that we all knew, but these were just not up to the task. And so when we saw the block editor, not only what was there in terms of the starting blocks, which is paragraph and image, which wasn’t very exciting, but the whole framework surrounding it to build a custom blocks we said, okay, these and these, and these are going to be the problems that we can solve with this.

And it’s going to take us a lot less time. It’s going to be more efficient because we can reuse certain things a lot easier. And also it’s going to be a lot better experience for the end users. And the thing that we need to understand is that, as I alluded to in the beginning, full site editing is just one part of the bigger picture.

So you can say, maybe I don’t want to use this part of full site editing, or I don’t want to use that part. And that is fine because we are in a transitionary phase, where we are transitioning really from a very classic theme development approach to this new paradigm of building themes. But if it just flat out say, I don’t want to use blocks at all, never ever, then probably, at least as I see it, then you’re going to need to stop using WebPress at one point or another. Which is fine because I think a lot of the careers in WordPress are incidental in that people just found WordPress and then they started using it, but there was, for most, not a point where they said, this is really WordPress and this is why I use it.

And so WordPress is just a tool, if at a certain point a tool doesn’t work for you, then choose something else. I think that’s just something where you need to be honest with yourself. The other part is that when we think about what an agency is, if you choose WordPress because you say this is the best solution for us, then you need to be all in with it.

You can’t really say, I’m going to choose WordPress, but not these and these parts of WordPress, which I don’t like, which are just key to experience. And how content is edited and how themes are built, that’s a very key part of the CMS. So you can’t just ignore those. But the difficulty is, what I alluded to before, is that you need to really understand how a block theme works, how the site editor works, how I guess the end goal works.

And then once you have understood what that experience is, then you can come back and say, well at this point, for this project, I don’t want to have full on block templates. I’m going to use more hybrid approach where maybe the users can change this part or that part to the editor. And that’s all fine because you are making a very conscious decision of choosing features that fit best with that specific project.

But you know what the possibilities are, and you know what to pick next, once you get over that initial phase where we just build partial websites. For example, landing pages are something which you can already build now with blocks and you could for a while. Now it’s just a lot easier to do. So it really depends a lot on your specific use case.

And for that, if your work is building websites with WordPress, you need to have the experience of making the right choices. So if you’re just pushing the point at which you do the switch in the future and into the future, into the future, there’s going to be a time at which somebody comes in an agency that says, well we have been building with this since 2018, and you only started in 2024 for some reason.

That’s a lot of time and a lot of experience that you’re missing out on. So it’s just like with building blocks. You have to jump into the pool, and wobble around with your legs and arms and try to swim. And you will see, it gets easier and easier. But, I think what we need to just understand that, WordPress has been the same for so long, and we think that’s normal, but it’s definitely not. Because the wider web development space has changed so dramatically just in the last five years.

And so we cannot expect to keep the same solutions that we’ve built always with meta boxes and what have you, and then expect this to be a solution which is competitive in two years, in five years. It’s not going to be the case. The world is moving on whether we want it or not, and we just need to get onto the train if we want to be a part of that.

[00:26:03] Nathan Wrigley: Couple of questions from that. The first one is you mentioned that there’s a competitive edge to be had here. I’m just wondering if you can give us some sort of insight into that. I realize you can’t talk about particular clients or anything like that, but what do you feel the advantage is that you can offer to clients? Are there conversations that you can have where the full site editing picture, the Gutenberg picture, the blocks picture, you can explain that promise to the clients, and you believe that they are persuaded by that?

[00:26:31] Fränk Klein: Well, I think that there are a couple of things. You need to start somewhere. I started early when it was still in the plugin and my colleagues at Human Made weren’t far behind. And so the thing is always that when the first project, we kind of had to convince the client, but not really, because we showed them the editor and it was like miles better what they had.

They say, Oh yeah, you know, we definitely like this with visual previews, because I mean it wasn’t even up to the classic editor, what they had before. So that was an easy win to be honest. And maybe that was luck, but. Then when the next client comes around and they ask what’s with this new editor thing? And we’re like, oh yeah, we did this project for this client and these are the custom blocks that we built, these are the problems which we solved. That’s an easier conversation because it doesn’t feel super outlandish to them anymore because, well this client did it, then, it seems a good solution, then why shouldn’t we do it?

And so you need to build up that repertoire of just social proof to be honest. And so when a new client comes around and we having these sales talk, and they are explaining a problem to you. I can always say, we had this client, they had this problem, we built this solution. And so, when you just not only explain it to them, also show it to them, which we like, you know, we like to demo stuff. Then they definitely see it.

And we are not even talking about this is a block and this is an extension of this default control because the client doesn’t care. They don’t know what is in Core and what isn’t. If it’s custom not. If it takes you an hour to do all week, you know, in a sense, they don’t care. They just want to have a solution that fits their needs. That’s just the competitive advantage of really knowing this thing very well. Which is why I said, if you don’t understand what full site editing is trying to do, you cannot really apply pieces of it.

The other part is of course, that maybe you are reluctant to learn JavaScript and React, but honestly it’s a very good thing to know, because if you ever were to get out of WordPress, a JavaScript developer, React developer, tons of jobs available. That’s also for me, when I look at my personal career, I always need to prepare for the case when WordPress might disappear overnight, for whatever freakish reasons. Then I’ll be fine. I just go and do a JavaScript, which I also enjoy. But I think that’s something which maybe a lot of people are missing it or they don’t want to think about it that much.

But the run of the mill WordPress developer with just a non WordPress development skills, is quite far behind the larger web development ecosystem. And that is fine if you say well, I’m not really a developer, just, maybe I’m a marketer, salesperson and I just build websites because I need one. But that’s not really what my core skill is.

If you say well, I’m a developer and I build custom solutions for my clients, that’s really, my core skill is what I sell to my clients, and you are not able to work with what has been in WordPress for by now four years, custom blocks and this whole system that has been introduced. That’s not a great situation to be in.

So unless you want to be tied to a specific page builder, theme, and you want your stake, your fortune to the fortune of that company, then this is something which you just have to get with because, it’s very important for your own career and it’s very important for your own business. If you want to stay around for the next couple of years, this is not something that you should be sleeping on.

[00:29:39] Nathan Wrigley: Yeah, it’s interesting. I feel that there’s probably quite a lot of people who are fearful of some of the things that you mentioned. Learning React and learning JavaScript deeply, and they’re struggling just to use the time that they’ve got to output the work that they need to output to make ends meet. And so all of this extra, that they’ve suddenly got to learn becomes a little bit daunting. But it’s nice to hear that you feel at least that there’s opportunities there and perhaps in your imagination at least anyway, the window of opportunity is bigger, looking forwards with full site editing. And it’s closing with the old way that things have been done with PHP and themes and all of that kind of stuff. So that’s interesting.

You kept saying the word custom solutions which I found curious. I’m guessing that on the enterprise level, the kind of clients that you are dealing with, that is the kind of work that you are involved with. You know, they come to you with websites which have a heavy burden of, it needs to be very custom. It’s got to be exactly what we want. The budget can accommodate that, and so you can really spend time drilling down. And so your knowledge of what’s possible with blocks and so on and so forth can really assist them.

You know, you might have a block for some very specific task within the broader website, that you can build and there’s time and what have you for all of that. Whereas, I would imagine quite a lot of people listening to this, they really aren’t going to be doing that. It’s just a simple website. It’s a brochure website, four or five pages and that’s kind of it. And maybe they feel that they still don’t need it. But, anyway the custom solution piece I think is interesting. Can you talk to us about that?

[00:31:09] Fränk Klein: Ah, yeah, sure. I just wanna take the opportunity to circle back a bit to finding the time. And this comes from Brian Gardner, so thank you, Brian. He said there’s is five for the future, which WordPress says you should invest this time into the project so that it can sustain itself. And he proposes these five for your future, which just means well take 5% of your time and invest it into learning because that’s going to make it possible for you to have a sustainable future.

So I think that’s a very important concept. Cause I definitely do understand the need to make money and stay up to date on all of these things, and it’s not different when you are in an enterprise agency as when you are in a small agency. I mean, the struggle is always the same. I mean, everybody needs to make money, and the way to make money is to produce work for your clients.

But I think just if you are aware of the fact that you need to stay up to date, and you make it a priority. It’s the same as with any other thing in your business. It’s like accounting, everybody needs accounting and you can just not do it. And at some, you’re going to be screwed or you say, yes, I need to do my accounting and I need to take the time it takes to do it right.

I mean, everybody needs time to write their invoices. And so people make time for that. And if you make this the same level of urgency and importance as writing invoice so you get paid, then learning is just going to be a natural part of that.

There’s a piece of learning where you just need to get the basics, but then there’s a lot of learning on the job where you run into an issue and you figure it out and then you work some more, you run into another issue. So a lot of learning that you’re going to do is pretty much on the job. So that’s how it was for me. And to come back to the question of custom solutions. In general, when we talk about a website project where they cost $5,000 or $500,000, the challenge is always the same. There are certain pieces in the website that you need to have, so there needs to be navigation, there needs to be a list of content, posts. All these things are there, and it’s the same whether it’s small budget or big budget.

The challenge is what do you focus your energy on in that budget? And so that’s a conversation which we have with our clients where, for example, it’s a stupid thing, but we get the mock up, right? And there is this pagination on the bottom. And this pagination kind of looks tricky. I would say, look, that pagination, if we build it that way, it’s going to take us like a day to build it.

And honestly, nobody cares what your pagination look like. We can switch it out with just the full pagination. We got all the functionality. It doesn’t look the same, but who cares about the pagination? And most clients, if we don’t say it that way, if they say little bit more nicely, most clients will be like, yeah, okay, understand, the pagination. because for them, they didn’t even see the pagination, right? It just slipped their mind. And so there’s this negotiation where you need to take all of the pieces which you can simplify and use something which is pre-done, that you do this way. And then you really have the time to focus on the pieces that are important to your client.

Because I always talk the language of money. What makes you money? How do you make money? How can we help you make money? And that is the point where you’re going to invest a lot of your energy, and that is where the custom solutions come in. So we had a client that problem was that. They had a CMS, and it took their editors 25 minutes to just enter the content into the CMS because it was so complicated. They need to manually resize images, all of that. So we just took WordPress. We did some custom work, not a lot to be honest, just for that specific piece. And we brought it down to five minutes. At top, takes them five minutes to get an article entered into the system, published on the website, has all of the metadata for social media and everything like that.

And that’s a case where you can present to a client how you make them a lot of money by saving them time, because they still have the same editors, but the output is a lot bigger. The important thing is to not be tied to things that you think should be custom, because let’s say a menu, a main navigation. Do you need a custom menu with all this and that, or can it just be dropdowns? Normal dropdowns. It’s a question. Maybe the answer is no, because you have, I don’t know, an e-commerce website and you need to have a more complicated menu. Or the answer is just yes. Just a menu, as we all know, is going to be fine.

And so that’s really the struggle that you find the things that you can standardize and WordPress is going to help you with that. Because a lot of the things that we needed custom solutions before now are standardized, or at least the way that you build it is standardized. So custom blocks are really difficult to build.

You know, a bunch of stuff is already there. A lot of components are there. And the challenge is that when we talk about the smaller budgets, the $5,000 project’s not going to go away, what you need to deliver for that amount, that’s going to go up. And so here, when we talk about full site editing, since a lot of the pieces already predone for you, you can assemble these pieces, you can customize them, and that will allow you to build a solution which corresponds to the needs of your clients. And it doesn’t take you a lot of time to do it.

So that’s the big idea behind is that, previously WordPress was very much, I give you these APIs, but there wasn’t really much in there. So now it’s completely different way. There’s a ton of stuff in there, but you need to really curate the experience that fits for your client and then you add the stuff that is not by default in there onto that. If it’s a plugin that you can use, great. We use tons of plugins at Human Made that just do things that we always do. And if it’s really a custom piece, then that’s where you write the custom code. And so through combinations of these factors, you’re going to be able to achieve the results for your clients.

[00:36:42] Nathan Wrigley: Yeah, I do like the piece that you mentioned there about having the client suddenly realized, that must have been a real aha moment. Something previously took 25 minutes. So if you did that twice, you’re approaching an hour to do, whatever that task was twice. And with the custom solution that you built, perhaps that was a block with the fields arranged differently, I don’t know. But the principle that could enter the same amount of data, you could do that twice in 10 minutes, you really have sold it I think at that point.

Nobody’s going to deny that’s a better experience. And if it can, in the background, be doing things like creating the images and creating all of the metadata that goes with those images for the different social networks and so on and so forth. All of that stuff can be built inside of this custom solution. Yeah that’s fabulous. Like you said, the budget may not allow for it, in which case there’s still going to be a, the $5,000 website.

I do think you are right as well that the expectation for what that $5,000 will buy you is only going to go up. It’s going to continue to be, $5,000 this year will get you this amount of functionality. And now that people are building with custom blocks and what have you, I imagine customers are going to be able to determine for themselves that, well, actually, no, for my $5,000 I’m expecting there to be a lot more on the back end that I can play with and for it to be customized just for my use case exactly.

[00:37:56] Fränk Klein: Right, and I think that, when we think about a traditional website project, there’s this waterfall model where development is at the very end. And if you approach it this way, you’re kind of ready, all of these decisions have been pre-made for you because, there is this custom pagination, I don’t know, but pagination is one of my pet peeves, so there’s this super expensive pagination, this weird menu, like stuff is all over the place. But those are the mockups that the client said, we’re going to build this, and now you are having to deal with the task of, okay, how I’m going to build this, in this amount of time? And then we just are at the same starting point where everybody else is, like, we have a website that pretty much looks like all other websites, because usually, unless the design is very expensive, it’s pretty much going to look like a lot of other stuff, obviously.

And so If you think of yourself as an engineer, you know, maybe that’s your title, but that’s not really what you are. You need to come in very early in the process and then already talk to the client in the very beginning, in the discovery phase, and find out what the pain points are and then try and make a note of these and also come out with a few possible solutions that you might deploy to do this.

And then you go in and you need to collaborate with the graphic designers. I need to collaborate with the client on how you put this website together. So since we now have a framework, which is WordPress, where we have all of those pieces to build a website. We need to be involved a lot earlier and also explain to designers what these pieces are. How far it can be customized and all of this. Because the approach as we did, by now maybe 15 years ago, where really we sold websites by the . Page and it was this mockup and that mockup, and that was how websites were sold, right, by the page. You paid this much per page. That is just gone. Now we need to build up these small pieces and we assemble them into bigger pieces and bigger pieces, and that’s how we build out the whole website from the small components.

That is both the case in terms of the design. So we start with the button, which is done part of a larger pattern, which is then part of the whole page design, or a call out box, whatever. You build up the design out this way, but it’s also the functionality. And a lot of the functionality that you build out, you’re going to have to deal with the data.

How do I model the data? How is it stored in the database? How does it get accessed? How do I store it in way that is all performant? And so, you as an engineer, you kind of need to talk the language, both of the client and the designers. And still know all of the background of what you need to do when it comes time to write code.

Cause let’s not kid ourselves, at a certain moment, you’re going to need to open that editor and start writing out code. Even when you’re dealing with, you know, full site editing. Then at that point you have everything lined up in the way that you can deliver the results that the client wants, within the time, and then also the budget that they have.

So that’s really the big challenge, and it’s going to require us to step away from a lot of that old waterfall thinking because, really when you have projects that I tend to do tend to be quite long. You know, sometimes three months, six months, a year. So if you have a project that runs a year, you’re not going to come in with a list of all the stuff that you’re going to do in a year.

So it’s a constant, discovery, negotiation, building stuff. But at each point you are building something which already has value. And so if at the end of the project the budget runs out, and maybe we missed a few nice to haves, the client’s not going to, they’re not going to care, because they’ve got everything which they wanted and which is producing the results for them.

So that’s really the idea that we need to take forward. And to be honest, I don’t have all the answers on that. It’s just, I think that a more iterative approach where you build out pieces one by one in order of priority, and we have something which is working, which is going to produce results at any point. That’s the way that we’re going to do it, and it’s a lot easier to do that, just assemble pieces and then you add your little custom stuff to it. If you just start everything from scratch and it already takes you three days to come up with, you know, the basic site layout, I think that’s just outdated.

[00:41:58] Nathan Wrigley: Interesting. So it almost feels like you are using bricks to build a wall. You might substitute the word bricks for blocks, which is a nice metaphor. Just before we end, it sounds like you’ve decided that this is the way that you’re going to do things in the future. You’re fully into this. The promise with new technology is always, we’re going to make your life easier. I do wonder, and maybe you can speak to this, have you simply swapped a bunch of problems that you used to have, for a new set of problems that you now have? So whilst in the past you were wrangling with different things, templates and themes and so on and so forth, you’re now just wrangling with a different set of problems.

What I’m trying to say is, is your job easier now, harder, or just the same?

[00:42:42] Fränk Klein: It’s the same, but it’s not. I think that we shouldn’t be, how can I say that, we shouldn’t look back on the past and, oh, imagine when we didn’t have to do this and didn’t do that and paint the pretty picture of how it was. Because the past, it wasn’t great. I’ve been in web development for a while now, and there never was this super bliss that somehow got destroyed with everything that is here.

But the thing is that it’s been the same. But for me, the way I look at it, it’s that you are always going to have problems, but I want to have bigger problems and better problems. So there’s a myth that, oh, a thousand dollar client is going to bicker and then a $10,000 client just going to wire the money.

And I don’t know where these people come from, but that’s definitely not the case. All clients are difficult at all price ranges. That’s just how it is. You’re trying to build this thing together. And there’s going to be a few confrontations, and that’s just normal. But the thing is more is that, how can I say that? If I have to write one more stupid post list, I’m just going to be out of this. Who wants to go into an editor and be like, oh, this is going to be a list, and then I will get the title. I have zero interest in that, doesn’t interest me at all. It’s just I don’t want to do the same thing over and over.

If I can abstract that away, great. And that’s really the idea behind is that I want to go to the things, just in terms of my career, I want to get closer to where I can produce outcomes for the client and rewriting a list of posts, how much of an outcome are you producing? I’m not really sure.

And so everything that I take, all of these tools is just, I want to deal with bigger problems, better problems, and that way I’m going to be able to make more money, frankly speaking. And so if you just get bogged down into this small, kind of, small thinking where we need to say, oh, I need to write everything from scratch. No you don’t. there are huge parts of projects that I didn’t write myself, but I know which solutions are out there. And so, I don’t come up with an SEO framework. I use a plugin for that. I don’t come up with a bunch of things. But because I have solved all these problems, I can then have better problems.

That’s the idea that I want to take. I want to get to the really hard stuff and yeah, definitely full site editing helps with all of that. It abstracts away a lot of the theming stuff that’s very repetitive. Blocks are a lot more portable. Even if we do write custom code, there’s a way to make it more abstract so that we can pull in libraries and things like that.

So that way you are kind of building up, project by project and not only building up experience, but you’re also building up your toolbox so that when you come to a problem, you’ll reach in to the toolbox, you pull it out, you can solve the issue, and then you’re onto the next one. Which hopefully is going to be more interesting than how does the pagination look.

[00:45:20] Nathan Wrigley: Nice answer. Fränk, I’m afraid we’re probably just going to have to knock it on the head because of the time. But just before we do, just before we call a close to the podcast episode. I’m wondering if people have listened to this and have been inspired and would like to get in touch with you, what other best ways or way to do that?

[00:45:36] Fränk Klein: First, it is my website, so WP Development Courses. So check that out. Feel free to email me like there’s a contact tab. I like to hear from people. I don’t have all the answers for sure, and I like to hear from people and understand all the different backgrounds.

And then I’m on the WordPress.org Slack. If you wanna DM me. And of course you can find me on Twitter. So if you have a question, if you have a problem, if you have a viewpoint, if you disagree, let me hear it. I’m very interested in hearing all of your perspectives and your struggles.

[00:46:04] Nathan Wrigley: Fränk Klein, thank you very much for chatting to us on the podcast today. I really appreciate it.

[00:46:09] Fränk Klein: Thank you. It was a pleasure.

On the podcast today we have Fränk Klein.

Fränk is a self-taught developer. He started out learning PHP in 2011 and from there found his way to WordPress. Over the years he’s worked for Automattic at WordPress.com and WordPress VIP, and is now a principal developer at Human Made, an enterprise WordPress agency.

Today on the podcast we talk about how Fränk decided early on that he was going to start developing with blocks and, more recently, with the full site editing capabilities now built into WordPress Core.

We talk about the four phases of the Gutenberg project: content editing, site customisation, collaborative editing and multilingual, and where full site editing fits into this.

Fränk explains how he sees the adoption of Gutenberg as inevitable. WordPress is moving away from the classic approach of content creation to a more visual, block-based experience. He thinks that it’s important to become an expert at building websites and custom solutions for clients, and for taking the time to learn the new tools that this future will require.

He’s not suggesting that the journey towards expertise in React and JavaScript will be easy, but he sees it as essential for those wishing to continue to use WordPress as their CMS of choice.

He also makes the point that now is a great time to invest in yourself as there are more resources than ever which can assist you in this learning path.

As you’ll hear, Fränk is all-in on WordPress and is very optimistic about the future for experienced WordPress developers.

Useful links.

Fränk’s WP Development Courses

#49 – Matt Cromwell on the Effectiveness of the WordPress.org Repository for Promoting New Plugins

Transcript

[00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My 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 effectiveness of the wordpress.org repository for promoting new plugins.

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 forward slash feed forward slash 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. Do that by heading over to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

So on the podcast today, we have Matt Cromwell. Matt is Senior Director of Operations and Marketing at StellarWP, where he provides marketing and business insights and coaching to burgeoning WordPress product owners. He’s also one of the founders of GiveWP, a donation plugin, which uses the freemium model. Having a free version on wordpress.org’s repository as well as a paid premium offering.

The wordpress.org repository is where you find yourself when you click the add new button in the WP admin. It’s a place where plugin developers can, if they follow the guidelines, hosts to their plugins. It provides a direct line of access to all WordPress websites, and is therefore a convenient, free place to host your plugin.

In return, the plugins in the repository must be freely available by the plugin authors. In the past few weeks, the repository has been in the news. Some statistics were unexpectedly removed, and this has led to a conversation about the governance of the repository, as well as questions about whether or not the repository is still a worthwhile place to offer your free plugins, if you have a premium tier.

Alex Denning wrote a post entitled, “WordPress.org is ineffective for plugin distribution in 2022”, in which he lays out his thoughts as to why he no longer recommends the WordPress repository. The battle against already successful plugins, low conversion rates, and the difficulty in gaining visibility are amongst the arguments that he puts forward.

Shortly after Alex’s post was published, Matt Cromwell posted a rebuttal entitled, “The case for the WordPress freemium model”. And this is the basis of the podcast today.

We talk about Matt’s history in WordPress as a premium plugin owner and how his experience leads him to conclude differently. That the WordPress repository can be successful, given the right expectations and approach. He’s found using the repository to be an effective channel to drive the plugins premium tier, as well as a way of offering a useful free donation tool to the community.

It’s a fascinating chat and is sure to be of interest to anyone thinking about starting a freemium plugin.

If you’re interested in finding out more, you can find all of the links in the show notes by heading over to WPTavern.com forward slash podcast. Where you’ll find all of the other episodes as well. And so, without further delay, I bring you Matt Cromwell.

I am joined on the podcast today by Matt Cromwell. Hello, Matt.

[00:04:19] Matt Cromwell: Hi, thanks for having me.

[00:04:20] Nathan Wrigley: You’re very welcome. We’ve got a, an interesting subject today, all about the wordpress.org ecosystem and whether or not it would be sensible or otherwise to put your free plugin over there. Before we get stuck into that debate, though properly, anybody that is unfamiliar with Matt, let’s give him an opportunity to introduce himself. So, Matt, just give us a few moments of your time to tell us who you are, what your relationship is with WordPress, what you’ve done in the past in the WordPress space.

[00:04:47] Matt Cromwell: Sure. I’ve been in WordPress for a while. I would say about 2012 or so. Jumped in and started building websites with WordPress, mostly helping non-profit organizations, churches, educational institutions. Then ended up partnering up with my longtime business partner, Devin Walker, and he and I decided to tackle a big problem in WordPress, which at that time was how to take online donations.

And so we created a plugin called GiveWP, and that was launched in 2015. That has catapulted us into our career, and has done really well and we’re really proud of it. So much so that we sold it last year to uh, Liquid Web, which is where we are now in the StellarWP brands. There, we have also just recently been asked to uh, take on a bit more. And so now Devin and I are both managing GiveWP as well as iThemes, Iconic and Kadence WP. So things keep getting more and more exciting.

[00:05:44] Nathan Wrigley: Thank you very much. Yeah, really broad and rich history there. We could have spent the podcast talking about those products, but we’re not going to. Well, I think we might do tangentially as a way of demonstrating different things. But we’re on the podcast today to talk about a couple of pieces which came out.

I will link correctly to both of the pieces that we’re in discussions about today. But I’ll mention them both in turn so that those listening to the podcast could possibly have a quick read of them before they pursue any further. So the first one was produced on the 18th of October by Alex Denning over at getellipsis.com, and that piece was called wordpress.org is ineffective for plugin distribution in 2022.

And then a few days after that, you, Matt Cromwell, wrote a piece and that was at mattcromwell.com and it was called the case for the WordPress plugin freemium model. And in effect, your piece coming a little bit later was a rebuttal about what Alex was saying. Now, if you’d like to outline what Alex is saying, you are welcome to do that. Alternatively, I could try and outline what Alex was saying, which would you prefer?

[00:06:54] Matt Cromwell: I think you are much more fair than I.

[00:06:56] Nathan Wrigley: Okay, that’s very kind of you. The long and the short of Alex’s piece is that he believes that by the year 2022, we’ve got to a point where, if you are going to be releasing a plugin, a free plugin, into the WordPress space, he believes that it’s now no longer effective to do that on wordpress.org. The article is probably about a 10 or 15 minute read, and as always with Alex’s pieces, there’s lots and lots of data and so on to back it up. But essentially he believes it’s ineffective for a variety of reasons.

One of them is that the marketplace seems to be dominated, in his view, by some giant incumbents. We’ve all seen those plugins before. If you’ve tried to add a new plugin through the WordPress repository, you’ll probably know the plugins that we’re talking about. They always rise to the top. And that’s largely because, Alex thinks, because of the install base that they’ve already got. Once they’ve got over a certain amount, the hump of a 100,000, 500,000 or 1,000,000 installs, then it becomes more likely that they’re going to be surfaced.

There’s also the idea that, in the recent past, especially since 2016, he makes the point, it’s much more difficult for new plugins to breach that number. So getting past a hundred thousand and so on is more difficult, which is compounding the problem.

And then if you add on to that, the fact that the search functionality within the WordPress repository also doesn’t give the opportunity for new plugins to be discovered. If you go there and you search for particular keywords, his contention would be that it’s much more likely that the ones with the greater install base are going to be surfaced first. In other words, it’s a bit of a, an echo chamber, I suppose, in a sense is what he’s saying.

Given all of that, he contends that you would be better off spending your time, and I guess for time you could read money as well, elsewhere. It might be better to have social campaigns or Google ads or some other channel of distribution, outside of wordpress.org, and so your endeavors would be better served elsewhere.

Alex I hope that I’ve summed that up correctly. If I’ve not, pleased do get in touch and let me know where I’ve mistaken things and I will gladly amend the show notes as such. But that, broadly speaking, is Alex’s contention. And, a day or so later compelled you to write a rebuttal. Just tell us what your thoughts are.

[00:09:26] Matt Cromwell: Yeah. Generally speaking I gave some good caveats in my piece that Alex does know what he’s talking about, and he has a lot of data to back up his conclusions, and I still believe that strongly um, he has reasons for saying what he says. What compelled me to write a rebuttal were essentially a couple claims that I felt were potentially not as helpful for the WordPress ecosystem.

In particular, one thing I think that’s important of what he’s saying is that, he says essentially that if you’re serious about your business and you want to build plugins then you should do premium only, and not a freemium model. Like basically do not build a free plugin, build a premium only plugin. And I really do believe that is damaging to the WordPress ecosystem overall.

If we start to see an influx of premium only offerings it can be really harder for the common user because, we all know it doesn’t take one plugin to build your website. It often takes a dozen, or several dozen plugins to build your website. And if you have to go, and be purchasing them across the web all over the place, it suddenly makes WordPress not as optimal to deal with.

So that’s one of the big downsides of his argument that makes me say, ah, I think this needs a lot more context and I think it needs somebody to say, no, the freemium model still works. And then I spend the rest of the article really talking about how I do see that the freemium model does still work and specifically that .org, while the active install count is significant, it’s not the only factor, and it is still possible for newer plugins to get adoption on wordpress.org. It just takes some savvy for sure. It’s not as easy as it used to be. I’ll give him that for sure. It’s not a situation anymore where if you build it, they will come. So yeah, the long and the short of it.

[00:11:18] Nathan Wrigley: So, one of your contentions is that it’s damaging to the WordPress ecosystem, if in effect there was only paid for plugins and everything that you wished to have on your website was a paid for plugin. I’m guessing that over the years you’ve built websites in which you have utilized free plugins? And some of them may be broad in scope, but some of them may just achieve a couple of smaller things.

And, there’s something to be said about that, isn’t there? I guess there is something about the community and about the ecosystem, about the expectations of what you are getting into when you install WordPress, which has this free model to it. I guess that’s an important component of the community and it would in a sense be a shame if the only things that you could have were paid for.

I remember the day, probably going back about 15 or so years ago, when I was looking around for different models for CMSs that I was going to begin using, and there were a variety of them. And there was Drupal and there was Joomla. But if memory serves, there was one called Expression Engine. I could have got the name wrong there. And it seemed to have a very low install base.

And my perception of that was that was because it took that model, it had the model of, you had to pay for not only the CMS but I think all of the different component parts that you could bolt onto the top of it, AKA plugins, and perhaps that was something that stifled its growth. And if we look back at WordPress, perhaps the free plugin model is one of the big factors of its success?

[00:12:47] Matt Cromwell: For sure. Absolutely. I mean, for us with GiveWP and I think many people could think, whenever I say GiveWP, you can also think similarly of WooCommerce, quite honestly. It’s really important to us that GiveWP is free, because a lot of non, all non-profits basically start from zero in many ways. And they are always very conscious about their expenses. And they’re in the fundraising space. There are so many dozens and dozens of paid fundraising platforms and they are oftentimes very expensive. So having a free option for folks to be able to start fundraising with, and do it successfully and effectively is really important.

And I say similar to WooCommerce because it is similar, like a lot of small businesses start from zero, and they can’t afford to be paying for a whole bunch of different plugins, just in order to sell their stuff online. I do worry a little bit on the WooCommerce side that their plugin ecosystem has gotten so large that sometimes it feels like it’s harder to start a shop with just WooCommerce free. And I wish they might put a little bit more features into the free plugin. But that’s a whole nother podcast.

[00:13:59] Nathan Wrigley: Okay. Let’s take a couple of different pieces of the wordpress.org repo. One of the first things that Alex talks about is the opportunity is quite low according to his data for converting people over. So let’s say in the case of GiveWP, he doesn’t cite GiveWP, let’s be clear. He talks about other different plugins and you can verify that by looking at the article. His contention is that really the conversion rate from the free plugin, if people install your free plugin, it’s somewhere between one and 3% of those people will be interested enough to go and explore and look for your, your website or whatever channel it is that you’ve got for getting the paid version.

So, between one and 3% of your users, and therefore that’s seems like a fairly small figure. And so the cost in terms of the support that you’d have to give on .org, and also the fact that you’re having to update it and maintain two different versions with different features. If it’s only one or two or 3% that are converting, that does seem to be relatively small, but your experience is clearly different.

[00:15:04] Matt Cromwell: Yeah, for sure. Now Alex definitely when he was trying to say which plugins have the benefit of being preferred on the plugin directory search. I do think that he would put Give in the category of kind of an elite plugin. Because he did say plugins with a hundred thousand installs or more that have been there for a long time have this elite status, and it’s hard to compete with them. And we do have over a hundred thousand installs. We’ve been there for seven years now. So I think he doesn’t put us in the same category. But nevertheless, I can say authoritatively that we are converting closer to 28% of our install count to paid customers.

I also gave some data on a newer plugin called Orderable that I’m also involved with on the Stellar side that just launched last summer. And honestly, it’s a low estimation honestly. If I really look at everyone who’s paid for anything with Orderable, it is closer to the 30%. But right now, in terms of active customers, it’s around 18%. So it’s converting much higher than one to 2%, or one to 3%. But even if you take that one to 3%, and you think about these large plugins like Elementor or whatnot that have 5 million active installs that’s 50,000 customers. And that’s significant regardless.

[00:16:21] Nathan Wrigley: Yeah, I wonder what could account for the difference there, because Alex is one, two or 3% which may very well be the case in certain given niches, or given the data that he was talking about. I wonder how we account for the big ocean really between your 28, 30%, whatever it may be, and that much smaller percentage? Perhaps it’s something to do with the nature of the plugin itself, what it’s doing, what problem it’s trying to solve, and whether it’s more desirable. I don’t really know. It’s interesting.

[00:16:52] Matt Cromwell: Yeah, it is interesting and I, I do want to get some data from Alex on the specific freemium plugins that he’s worked on, on that, in that way. I do believe that Vova at Freemius probably has additional data that he might share about this subject as well. I believe that on average plugins that use Freemius convert higher than that 3% as well.

And that one I think is another significant data point to keep in mind. But I know from, I, I know Alex and I adore him, he’s great. And if I’m thinking the most optimistically about his perspective, I think it’s more that he would really expect conversion rates to be at least 5% or higher because that’s what he can get with organic results. That’s what he can get with CPC ads most likely. He just knows marketing from a larger perspective and really is expecting a lot more. So, if I’m trying to be generous that’s what I would think.

[00:17:44] Nathan Wrigley: I wonder if there is something in that, maybe your company Give, in this case that we’re talking about is unusually effective. So your 27%, 28%, whatever it may be is not the normal. Which is obviously very good for the way that you’ve done marketing and way that you’ve pitched yourself into the repo.

I’m curious, and it may be something that you don’t know the answer to, what would have been the rate? Given the install base that you’ve got. So you mentioned that there’s over a hundred thousand and you may not wish to share the numbers, which is fine. What percentage would have been effective to you? In other words, if it had have been at one or 2%, could you have made the plugin viable or did it need to creep into the 10 and 15% kind of area?

[00:18:30] Matt Cromwell: Mm-hmm. Well, we did have other plugins at the time, freemium plugins. And truth be told, I was not analyzing their conversion rates very specifically at that time. We had a bunch of business reviews plugins. We had a really fun plugin called Maps Builder that had a free and a pro version. And my guess would be that the conversion rates at that time for those plugins were probably also a lot lower than the 27%.

But they were viable. So I would just be guessing, I don’t want to just guess, but I do feel like they would probably be in the single digits in terms of conversion numbers. And at the end of the day, yeah, we did retire those for the most part. The business reviews ones are still out there, but we’ve made a premium product to kind of replace those. And it’s because of the success of GiveWP. So even if I look at our own plugins that we’ve built, we did make choices to sunset products because they weren’t converting as well. So it’s not as if I don’t hear Alex, on his side of things because I have some of that same experience. I just don’t think the conclusion is that means that .org is not viable. I do think it’s more of a product fit type of conversation, a marketing conversation, and things like that.

[00:19:38] Nathan Wrigley: Just taking a bit of an aside here for a moment. Everything that goes into the .org repository is by nature, it’s free. You can download it and anybody can access it at any time. I’m curious, you may have opinions on this, you may not. If you have a commercial variant of the plugin, so you’ve got two sides of the coin. You’ve got the free .org side, and the paid for, wherever you may put that, but you’ve got a paid for version somewhere else. What is the true intent of the free version? Because I could look at it cynically and say, okay, the free version is basically a channel for trying to sweep people towards the paid version.

And then with a less cynical hat, I could be, it’s offering the kind of functionality that we can support for free. In other words, we’re doing an altruistic thing, for the community for free, completely for free, with no expectation. Maybe it’s one side or the other, or maybe it’s a little bit of both. You’re being altruistic. You’re giving away certain set of features and range of options with the hope that some of them will come across. But no expectation, you know, it’s fine if you want to use the free version forever. As a plugin developer who’s been in the game for a long time, I wonder which side of the fence you sit on, or perhaps you literally do sit on the fence there.

[00:20:54] Matt Cromwell: Yeah, I mean the way that things like this work is essentially that at a certain stage, once you start to get enough users, it’s going to incur costs, just to have users. So specifically when you’re doing a plugin, like GiveWP or like WooCommerce that is so foundational to the functionality of a website and so important to that website, it’s going to start to incur costs. And that is human costs. That’s in the form of technical support for the most part. And account services. Because the users are going to need support. They’re gonna want support. And in order to fund that support, we do have to have some sort of funding in one way or another.

So doing the free plugin specifically is in order to serve that niche, in order to serve that functionality with the intention then that we’re gonna need to fund this in one way or another, and we’re gonna do that with premium features essentially. But it, it’s always been our strong conviction that the free plugin needs to be very full featured. That you need to be able to do effective fundraising with it out of the box. Or else folks don’t know what they’re getting into when they go to pay for something. So essentially it’s not just a funnel, which in some ways I think that’s a little bit of the take that Alex is leaning on, is that is looking at .org as one of your marketing funnels.

Which it is, of course. But it also represents your best foot forward of what your product is supposed to be, and what it’s supposed to offer. And in business there’s very often this idea of try before you buy, or there’s a free trial type of thing. With plugins we can’t do try before you buy really, and you can’t do free trials really, so your best option is to provide a free product that then leads to paid products. Am I answering your question?

[00:22:41] Nathan Wrigley: Yeah. That’s good. I know it’s a difficult tight rope to walk that one because, there isn’t really a correct answer, is there? It clearly has to be a little bit of a marketing channel. You are offering something in the hope of sweeping up a few of them. But equally, you are offering something in the hope that they’ll enjoy it and experience it and in many cases the functionality that’s there is sufficient. But should you wish more functionality, here’s the option.

It’s an interesting thing as well that in the community, the whole promotional piece on the .org side is, I think, widely viewed with disdain. That is to say it doesn’t take much for a plugin author to completely derail their plugin if they abuse the UI that they’ve got for their plugin. I’m thinking here of examples in the past where companies have taken the opportunity to fill up portions of the screen with advertising for the paid version and so on.

So, we can see that the community really do feel quite strongly about this. From the plugin side, obviously, the author’s side, you wish to promote your own products because you want to stay in business. From the user’s side, there seems to be a groundswell of people who think that the repository version needs to be completely without any upsell features. It’s just, if it’s good enough, we’ll figure that out for ourselves and we’ll go and discover it for ourselves.

In terms of discovery, let’s just move back to the piece that you wrote. One of the contentions that Alex has was that being discovered inside of the repository is increasingly difficult. The big incumbents of which you’ve described GiveWP perhaps is one of them, but we know the names of all the other ones. They dominate the search because of their active install counts, and Alex maintains that that’s a very important metric. In other words, if you go into the repository and begin a search, it’s quite likely that the results will skew towards the larger active install count plugins. Therefore, it’s going to be difficult to break through the ceiling of that, no matter how unique and brilliant your plugin is, just because it’s difficult to launch something and it takes a lot of time. You have, specifically on that point, your rebuttal is interesting. What did you say there?

[00:24:52] Matt Cromwell: Yeah, the active install count is a factor, and the plugin directory has gotten larger. But the active install count is one factor of many of the way in which the plugin search works. And luckily when you’re working with a open source platform like WordPress, all of the code that creates that search is open source as well.

So folks can take a look at it and see exactly the way that the algorithm works, in complete contrast to Google, for example, where it’s a big black box and nobody really knows how it works exactly. But .org is actually pretty straightforward and relatively simple. But there are a lot of metrics that they take into account when they create that search. And honestly the title of the plugin is actually one of the more significant ones.

Now that being said, if you are, if in your title of your plugin you wanna say something like Wrigley page builder. Page builder is a very flooded field. Things like Elementor and Beaver Builder and others do have a lot more installs already and they’re going to show up higher if they also have page builder in their title than Wrigley will.

But that doesn’t mean that you aren’t found or aren’t discovered. You might not be first. You might not be second, but you still have a really good chance of being on page one. Because there’s really not that many page builders on .org currently. So there’s still a lot of room overall. That’s kind of my biggest contention, is simply that the way the search works is more complicated than just simply the active install count. It’s also these specific tags that you use. It’s also the way in which you describe the type of functionality you have. Whether or not you have good support is even a factor. Like answering all of your .org tickets and things like that. Those all factor in. How recently you’ve updated the plugin factors in. There’s a lot of factors involved.

[00:26:38] Nathan Wrigley: So you specifically mentioned the following things, which are thrown into the mix when you do a search. So it would be the title of the plugin, the excerpt, the description, the tags, the slug author name, contributor names, last time it was updated, compatibility with core versions, number of active installs, percentage of support tickets resolved, which is really an interesting one, and the average star rating as well.

So there are quite a few things in there. I guess in a sense, having that knowledge could lead you to be quite sophisticated in gaming that system, and it’s no different really than something like Google where people spend, I would imagine very large amounts of money in some cases, really manicuring their SEO, but without that insight.

And they may succeed one day, they may succeed another day. The point being, they still need to jump through hoops. It’s not You go over to Google and suddenly you are a winner. You would still have to spend large amounts of time and money organically to break through the surface against, say, for example, other page builders. I presume the problem would be equal over there than it would be on .org.

[00:27:49] Matt Cromwell: Yeah, absolutely. And in this way I think what Alex is speaking to a bit is that, in the past with the plugin directory, it really was easier. It really was a lot easier to simply launch your plugin on .org and you would get found in the WP admin relatively easily. And those days are definitely not there anymore. It’s not quite as easy as it used to be at all. But I don’t believe that it means that .org is now no longer viable as a distribution option, or even as a marketing or business option.

[00:28:21] Nathan Wrigley: Do you believe that the search algorithm in .org, despite the fact that it’s going through these whole slew of different things, and I’m guessing that if you read the code, you can see how the waiting would be and so on and so forth. But, do you believe that the search functionality does need a tweak?

Are there other metrics which you would like to see thrown in? Or, indeed just different areas of the UI which may give a small but potentially important boost to newcomers, in a way that perhaps the current search wouldn’t? And, I think Alex mentions something like rising stars as an option. The idea that plugins, which are new, potentially, they’ve gone from zero to 50 in a matter of days. That’s, on WordPress, that’s a big leap if you go from nothing to 50 or a hundred in a short period of time, that’s really quite something. And so maybe there’s parts of the UI where compliments of that nature could improve visibility.

[00:29:14] Matt Cromwell: Absolutely, there’s always room for improvement when it comes to search algorithms, because they are highly complex systems, and they are so significant. In some ways though, I think, just even if the search algorithm itself didn’t change, but we were able to add things like categorization, being able to navigate down the directory through categories first and then search. That might be a big advantage right away.

Especially if one of those categories was, new. Something that was recently launched. There’s actually a really fun free plugin, I think it’s just called New Plugins, I’ll have to look it up. I’ll send you the link. But you can install this plugin in your website, and what it does is it adds, when you go to plugins, add new, there’s tabs in there that says featured and things like that. It’ll add a new tab, and it’ll just show you the newest plugins on the directory. And I think that’s really cool and I’d love to see that on .org directly.

[00:30:09] Nathan Wrigley: Yeah, that’s really interesting. You also point out that the, gaming is the wrong word, but you make the point that it is still possible given the way that the search is carried out and the results that are shown, that, as an example, some of your competitors, they seem to have optimized with use of their plugin name or the other things that we mentioned, you know, excerpts and description, tags and so on. They’ve managed to vault over you in the .org search results, because they’ve optimized for words, which are well, really important to you, but you haven’t specifically optimized for those.

So for example, nobody could deny that your plugin GiveWP is to do with fundraising, and yet fundraise as a particular word, you are outcompeted on the marketplace there. And also crowdfunding, which again would be an important part of what it is that you do. Both of those words, you quickly discovered you were not winning, and in some cases you didn’t even appear in the search results on the first page, despite the fact that GiveWP is really, that is inside your wheelhouse without a doubt.

And so there is opportunity, I guess it’s more of a sort of long tail search. You’ve just got to find what those opportunities are. Unfortunately, I guess we don’t have the sort of metrics that we have with things like Google Ads and so on and so forth, where you can see what people have been searching for over, over a period of time, in a particular geography, given different demographics and so on. You just have to do the grunt work of figuring all this stuff out.

[00:31:35] Matt Cromwell: Yeah. One other point related to that, that I pointed out is that your presence on .org isn’t only about the .org plugin search. It’s also about Google search because those pages all get found on Google as well. And so because we do have insights from search console and Google Ads and things like that, that does influence the terms that we want to be found with as well.

So it’s not only about figuring out how .org prioritizes plugins, but also what is going to get found on Google as well, because it’s really hard for any WordPress plugin to beat the domain authority of wordpress.org. If you build a plugin they most likely are going to be on the first page of Google before you are.

[00:32:17] Nathan Wrigley: So the contention there is that the .org repo is kind of doing double duty. It’s obviously offering your plugin up, should it be found, to people trying to add a new plugin. But also Google itself is scraping the.org repo and surfacing in its own search results. So if people are looking for the same kind of thing over on Google, they may very well be pointed towards your .org page. Have I summarised that correctly?

[00:32:43] Matt Cromwell: Yep, absolutely. In this way .org is just a marketplace in many ways. It’s a public marketplace for folks to find free plugins.

[00:32:50] Nathan Wrigley: I do wonder if the algorithm which is running behind Google, obviously complex and probably, took billions of dollars over time to be put together and is very sophisticated. But it’s not quite such a blunt instrument, is it? It’s not just taking data from a series of tags and descriptions and metatags and so on. There’s a lot going on. So for example, if I search for fundraise, Google is probably clever enough to figure out hang on a minute, fundraise is a sort of synonym for crowdfunding. It’s a synonym for donations and so on. So, we’ll highlight those results as well. So in, in many ways, it’s a little bit more sophisticated, and maybe the .org search could have some of that goodness thrown into it in the future. Albeit not with the same budget that Google clearly has.

[00:33:36] Matt Cromwell: Yeah, absolutely. That’s also a real reason why if you do have a free plugin on .org, it’s really good to make sure that you have folks who actually link to that plugin on .org. Not only linking to your website itself but to your free plugin on .org. Because then Google will pick up, oh, when folks are looking for fundraise plugin, they actually are looking for this Give thing, that might not rank as well on .org, but it is gonna rank great on Google, because Google does figure that out.

[00:34:04] Nathan Wrigley: We haven’t really strayed into this subject, but I’m wondering if you’ve had any experience with alternative marketplaces. The only one that really comes into my mind is Envato. Where for many years they’ve had a kind of rival plugin marketplace. I really haven’t been looking at how successful that’s been going, many years since I last visited it. But the option for plugin developers to sort of, corral together and have a completely different space. But it feels to me that in the end, potentially you just end up with the same problem, but in a third party marketplace.

[00:34:36] Matt Cromwell: Yeah, and that third party marketplace has very strong priorities around the way it wants to be paid, and the types of products it wants to be highlighting. They are far more opinionated about the way all of the products there are found and discovered. And it is really for the, the bottom line of Envato.

And I think, honestly, that’s one thing that’s a bit of an untapped conversation is the significance of having what is essentially a marketplace being owned by a non-profit organization, like the WP Foundation. I do think that’s a significant conversation and the more folks need to be having and recognize that we’re not just really all fighting for attention from a LLC or some giant corporation. We’re really trying to contribute together on a public project that should be primarily influenced by a non-profit organization instead.

[00:35:29] Nathan Wrigley: I guess the long and the short of this episode would be, from your perspective, is the Word Press repository perfect? No. Is it useful? Yes. And that perhaps is enough for now. Could it be improved? Another yes, but for now that seems to be, at least for you and your experience, good enough

[00:35:47] Matt Cromwell: Absolutely. I think it’s viable. I think it can be very helpful and beneficial. It doesn’t have to be your, it shouldn’t be your only tactic. But it also shouldn’t be easily ignored either.

[00:35:58] Nathan Wrigley: So just to round off the conversation, one final question. How do you view your efforts on the WordPress repository as against all of the other things that you do outside of WordPress. So for example, Google and so on? You may have data to hand, you may not, I don’t know. But I’m just wondering if, one is equal to another or if the .org side definitely comes in second place, or perhaps it is the primary channel of your sales funnel.

[00:36:23] Matt Cromwell: Because there are different types of freemium models, that answer will be different based on the product owner and the route that they chose. If it’s a free plugin with a pro version, meaning you have to uninstall the free one in order to install the pro one, their priorities are probably gonna be very different.

But in our case, similar to Woo Commerce, it’s a core free plugin, and any of the paid add-ons require the free version to be installed. And because of that setup that we have, and WooCommerce has as well, the free plugin is foundational to everything we do. We’re always improving the free plugin in order for it to be more powerful, more streamlined, and for it to be able to enable us to do more things in the pro add-ons as well.

So being able to really parse it between priorities, it’s almost impossible. Because for us, the free plugin really encompasses the whole ecosystem of what Give actually does and means for us as a business, and as a product for the users.

[00:37:21] Nathan Wrigley: I’m sure that this will be something which resonates with a lot of people. I don’t really know which side of the fence the audience will be sitting on, but no doubt there will be some commentary. There’ll be people wishing to explain their reasoning behind this, one way or another. Please feel free to go to the post on WP Tavern, and leave us some comments there. But for now, thank you so much Matt Cromwell for explaining your position about the WordPress.org repo. I appreciate it.

[00:37:47] Matt Cromwell: Absolutely. Thank you so much.

On the podcast today we have Matt Cromwell.

Matt is Senior Director of Operations and Marketing at StellarWP, where he provides marketing and business insights and coaching to burgeoning WordPress product owners. He’s also one of the founders of GiveWP, a donations plugin which uses the freemium model, having a free version on the WordPress.org repository as well as a paid premium offering.

The WordPress.org repository is where you find yourself when you click the ‘add new’ button in the WP admin. It’s a place where plugin developers can, if they follow the guidelines, host their plugins. It provides a direct line of access to all WordPress websites, and is therefore a convenient, free place to host your plugin. In return, the plugins in the repository must be freely available by the plugin authors.

In the past few weeks, the repository has been in the news. Some statistics were unexpectedly removed, and this has led to conversation about the governance of the repository, as well as questions about whether the repository is still a worthwhile place to offer your free plugins, if you have a premium tier.

Alex Denning wrote a post entitled “WordPress.org is ineffective for plugin distribution in 2022”, in which he lays out his thoughts as to why he no longer recommends the WordPress repository. The battle against already successful plugins, low conversation rates and the difficulty in gaining visibility are amongst the arguments that he puts forward.

Shortly after Alex’s post was published, Matt Cromwell posted a rebuttal entitled “The Case for the WordPress Freemium Model”, and this is the basis of the podcast today.

We talk about Matt’s history in WordPress as a premium plugin owner, and how his experience leads him to conclude differently; that the WordPress repository can be successful, given the right expectations and approach. He’s found using the repository to be an effective channel to drive the plugin’s premium tier, as well as a way of offering a useful free donation tool to the community.

It’s a fascinating chat and is sure to interest anyone thinking about starting a freemium plugin.

Useful links.

WordPress.org is ineffective for plugin distribution in 2022

The case for the WordPress freemium model

GiveWP

Orderable

StellarWP

Cubecolour New Plugins

389: Migrating a Ruby on Rails GraphQL API to a Go GraphQL API

One thing that’s been keeping us very busy at CodePen is moving our main API. We decided on GraphQL long ago and it’s served us pretty well. We originally built it in Ruby on Rails alongside a lot of the rest of our app. But while Rails served us well, we’ve been moving off of it. We like our React architecture and we’re better served leaning into that, with frameworks like Next, than staying on Rails. We proved out this combination of technologies for ourselves, building a whole set of admin tools with it. Now we’re ready to keep that train going as we build out more of CodePen with the same stack. But removing Rails means moving off of our Rails-based GraphQL implementation. This means re-writing that API in Go, another bit of tech we’ve had a lot of luck with.

Turns out that re-writing an API is more time-consuming than writing it to begin with, especially as we need to run them side-by-side and behave identically. No refactoring allowed! Unless of course we want to refactor it on both sides and take even more time.

Dee joined me this week in talking about all this. It’s a huge job! But we’ve been doing well at it, building our own tooling, doing lots of testing, and ultimately proving that it works by releasing it in small areas on the production site. It’s all working out how we hoped it would: fast, cheap, and easier to reason about.

Time Jumps

  • 00:39 Welcome back Dee
  • 02:02 Rewriting an API in Go
  • 04:22 Having two APIs
  • 06:16 Why would we make the API in Go?
  • 10:48 The plan for updating the API
  • 16:46 Sponsor: Equinix Metal
  • 17:22 Using this stack elsewhere on CodePen
  • 21:59 What was it like to do this work?
  • 29:36 Databases are typed

Sponsor: Equinix Metal’s Startup Partner Program

Equinix Metal’s Startup Partner Program helps early stage companies level up. Their experts work with startups like Koord and INVISV to build their competitive edge with infrastructure. Equinix Metal provides real time guidance and support to help startups grow faster. With up to $100,000 in infrastructure credit, access to Equinix’s global ecosystem of over 10,000 customers and 1,800 networks, they might just be what you need to take your startup global.

Visit metal.equinix.com/startups to take your startup to the next level.

The post 389: Migrating a Ruby on Rails GraphQL API to a Go GraphQL API appeared first on CodePen Blog.

#48 – Christina Deemer on Making Digital Content Usable for People With Cognitive Disabilities

Transcript

Christina Deemer

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

Jukebox is a a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case making digital content usable for people with cognitive disabilities.

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 forward slash feed forward slash 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 show, I’m keen to hear from you and hopefully get you all your idea featured soon. Head over to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

So, on the podcast today, we have Christina Deemer. Christina is a senior UX developer at Lede, a company of the Alley Group, where she champions accessibility and headless WordPress in her work with publishers and nonprofits. She’s passionate about inclusivity and community and has spoken at a variety of events about the subject.

Christina is autistic and brings her personal experience with neurodivergence and disability to bear in her work.

At the recent WordCamp US, Christina gave a presentation called “embracing minds of all kinds, making digital content usable for people with cognitive disabilities”. And it’s this talk, which is the foundation of the podcast today.

In her description of the presentation, Christina wrote, “cognitive disabilities are among the most prevalent types of disabilities, yet experts have struggled to provide web accessibility best practices around this area due to cognitive disabilities being such a broad category. However recent work by standards groups has begun to address this deficiency”.

In past episodes, we’ve covered website accessibility from some different angles, and today we focus on how the web might be experienced by people with cognitive disabilities.

First, Christina talks about what the term cognitive disabilities actually means, and what it encompasses. It’s a wide range of things, and so we talk about how people may differ in the way that they access the web. Memory, over complicated interfaces and readability are a few of the areas that we touch upon.

We also discuss what legislation there is in place to offer guidance to those wishing to make their sites more accessible, and as you’ll hear, it’s a changing landscape.

Towards the end, Christina talks about her own late diagnosis of autism and how this shapes her experience of the web, particularly with auto-play content and when web design includes elements which flash or flicker.

Typically when we record the podcast there’s not a lot of background noise, but that’s not always the case. This is the last of the live recordings from WordCamp US 2022, and you may notice that the recordings have a little echo or other strange audio artifacts. Whilst the podcasts are more than listenable, I do hope that you understand that the vagaries of the real world were at play.

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

And so, without further I bring you Christina Deemer.

I am joined on the podcast today by Christina Deemer. Hello.

[00:04:14] Christina Deemer: Hello Nathan.

[00:04:16] Nathan Wrigley: It’s very nice to have you on. We are at WordCamp US 2022. We’re upstairs in the media room, and we’ve got Christina on the show today because she did a presentation. Have you actually done the presentation yet?

[00:04:27] Christina Deemer: Yes, I did it yesterday morning. I was lucky in that I got to get it over with early and then enjoy the rest of the conference.

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

[00:04:35] Christina Deemer: It went really well. It was a lot of fun. I had a really great audience.

[00:04:39] Nathan Wrigley: That’s nice to hear. That’s good. The subject, I’m just gonna give everybody the title. That’s probably a quick way to introduce what we’re gonna talk about. The subject title was embracing minds of all kinds, making digital content usable for people with cognitive disabilities. So we’ll dive into that in a moment. Just before then, though, just paint a little bit of a picture about who you are and how come it is that you’re speaking at a WordPress conference particularly about this topic.

[00:05:04] Christina Deemer: Okay. I am a career changer. I spent the first 12 years or so of my career working in arts management. Then I decided I wanted to do something very different, and I became a developer. And one of my early mentors introduced me to WordPress. So, the first projects that I worked on were WordPress sites. I wrote my first WordPress theme when I was 35, and just really enjoyed getting involved in the WordPress community.

And from the beginning of my career, I’ve been very interested in accessibility for a wide variety of reasons. And it’s become a passion of mine. I really enjoy sharing knowledge about accessibility with people. I enjoy hearing people’s stories about accessibility. And recently there’s been a lot of work done on the standards around cognitive accessibility or accessibility for people with cognitive disabilities, and that work has been really fascinating and I’ve wanted to share it with people. And that was how, the reason that I pitched this talk for WordCamp US.

[00:06:13] Nathan Wrigley: Thank you. That’s great. The words cognitive disabilities, it probably makes a great deal of sense to you because you’ve parsed and you’ve said it many times. You fully understand it. Would you just run over a brief definition of what it encompasses? And I’m sure it’s not just one thing, maybe it’s a multitude of things.

[00:06:28] Christina Deemer: So it’s a very nebulous term, and it acts as a sort of umbrella for neurological disorders as well as behavioral and mental health disorders that may or may not be neurological. It covers a wide variety of things from autism, ADHD, aphasia, dementia, dyslexia, dyscalculia, tourette syndrome, traumatic brain injury.

It covers a real wide variety of things, which is one of the reasons actually why it’s taken so long to develop some standards around how to make websites more accessible to people with those diagnoses. But just to take a little further step back with things. When I talk about this I really try to make a point to not focus on some of these sort of diagnostic labels, but to rather focus on underlying cognitive skills.

Because a lot of people with cognitive disabilities don’t even realize they have a disability, for a number of reasons. There are a lot of systemic barriers to getting a diagnosis, and a lot of things come into play there. But really what we’re talking about is some underlying cognitive skills, like memory issues, focus issues, ability to concentrate, reading, math and language comprehension, decision making, executive function, which has to do with the processes involved in following instructions and planning things and processing a bunch of things at once.

So, when I talk about cognitive accessibility, I really like to focus less on those diagnostic labels and more on the underlying cognitive skills that are involved.

[00:08:13] Nathan Wrigley: So from that, I take it that cognitive disabilities, as you described it, was a long list. There was a really large amount of things that you’re covering here, which is really interesting. So let’s unpack that a little bit. Just before we clicked record, I mentioned that we may get into the weeds of what it is like for people who have some of these things. And maybe we could cherry pick some examples.

What I’m intending to do here is for you to paint a picture of what the web looks like for some of these different things. So in my case, when I approach the computer and open it up and get it started, I can see the screen, I can hear the video when it’s played. I just don’t really have a window into what that might look like. So if you have a moment to just broadly paint a picture of what some of these things feel like and look like.

[00:09:01] Christina Deemer: Sure, and even people who are somewhat familiar with general accessibility and maybe more accustomed to thinking about what the web is like for people who use screen readers. So they think about, they’ve maybe done some testing and they know how things are read. They think about reading order, and how a screen reader works. And when they’re thinking about making sites accessible for people who are deaf, they are thinking about making sure that there are captions on videos.

So when we’re thinking about cognitive accessibility, we’re thinking about some other issues. So in my talk yesterday, I had a couple of examples of sites that are pages that had weak cognitive accessibility. And one of them was a desktop screen of an interface of eBay, like buying a shirt on eBay. And in the middle of the page, there were four calls to action, with three different designs. So it wasn’t clear what the user was supposed to push. There was no clear call to action. There was very little white space on the page.

So this isn’t great for users with cognitive disability. Somebody who has an issue with focus is not going to know really where to look on the page. Could get distracted by all of the various details. All of the sidebars on the left, little small text below an image. People who struggle with decision making haven’t helped them with those four CTAs in the middle of the page.

Anybody with memory issues, it’s not going to be clear, like, if they bought something on eBay previously. They won’t remember what they did last time because it’s a little confusing. So a lot of users may abandon their task on a page like that. So that’s an example of a page that maybe has complex or overwhelming interface.

And another barrier that users face is if a site has very complex text or unusual words. So I mention Wikipedia page on the planet Saturn, that included words like perihelion, and a word like eccentricity, but people may not be accustomed to understanding what Saturn’s eccentricity is. Like, what does that even mean?

So, readability is often analyzed through a, a system called the Flesh Reading E Score. And I went to a website that measures the readability of, particularly of, Wikipedia pages. And it indicated that this page had a reading level of 10 to 12th grade. So it was very, very difficult to read. And for most adults we say that the reading level of content should be at about a seventh or eighth grade level. So if you want to make your content accessible for people who have reading or language comprehension issues, you’re going to want to go with even simpler content. A readability of about sixth grade or less. So those are of a couple of examples of some barriers that users with cognitive disabilities face on the web.

[00:11:57] Nathan Wrigley: So the accessibility piece, the bit that you mentioned earlier, about potentially some of the WCAG guidelines and things like that. That now is being drawn into the domain of, it’s illegal if you don’t perform some of these things. Is there anything surrounding that with the cognitive disability side. Is there any mandated things that you must do?

[00:12:17] Christina Deemer: Okay, so that’s where things are evolving, a lot and some really interesting things are happening. In WCAG 2.1, there’s already a couple of things, a couple of success criteria that address cognitive accessibility. Things around space around text, stuff like that. Auto filling in or making it possible to auto complete form fields. Those things are great for people with language or reading comprehension issues, people who have issues with focus.

In April, 2021, the W3C came out with a working group note on guidelines for making content more usable for people with cognitive disabilities. And this was a non-normative document, which meant that it was supplementary to WCAG and you don’t need to conform, follow these guidelines in order to meet WCAG compliance. So they came out with all of these really great framework, with eight objectives, dozens of design patterns, and none of that is necessary to comply with WCAG. So, yeah, that was April 2021.

So now we’re in September 2022. We now have WCAG 2.2 is in candidate recommendation, I think. And there are two new success criteria that feel like they’ve come directly out of that working group note. One is on accessible authentication, which is where you need to supply at least one method for logging in that doesn’t rely on cognitive skills. So you need to have at least one option where somebody doesn’t have to, by memory, type in their password. They can use a password manager or there’s an option for magic links, QR codes, single sign on, something like that. So that’s a new one.

And there’s also a new success criteria on consistent help. Oftentimes the quickest way for somebody to solve a challenge online is to get help from a real person that can support users. And it’s important that this information on like how to get help from a real person isn’t hidden. You don’t have to scroll and click through a bunch of non obvious links to find out how to get help from a real person. That information is accessible in the same place on consistent pages. And that’s just even having an email address for help, or a number to get help via text, or social, or a chatbot or something that’s not a chat, that’s a real person or something. Just making it possible for somebody to get help from a real person

So we’re seeing some of these things that were in that working group note come into the standard, which is very exciting. And part of the reason there were all of these design patterns in the working group note in the April, 2021 working group note, that are not included in the standard, in 2.2. And I think that’s for a variety of reasons. Like one of them is that so much of it is it’s hard to figure out a way to test it. To like design it so that you can have some sort of measurable test of yes, you are conforming with this or you aren’t.

A lot of it, with cognitive disabilities is very contextual and subjective, and it depends on your product and it depends on so many different things that they haven’t figured out a way to create testable success criteria yet. But it’s exciting to me that we at . Least have these two new success criteria.

[00:15:43] Nathan Wrigley: Is one of the things that makes this difficult to pin down, is it because unlike, let’s take the example of somebody who is blind, it’s binary in that case. I don’t mean you, your heart of sight, I mean you are literally blind. You know what to do with that because the outcome is obvious. You can’t see the screen. So there’s remedies for that, and you can create those remedies with screen readers and so on. But it sounds like the description of cognitive disabilities, there’s such a broad spectrum. It’s hard to pin it down, so it’s hard to create the solution because each person may be slightly different.

[00:16:15] Christina Deemer: Absolutely. And there’s a saying in the autism community that when you’ve met one autistic person, you’ve met one autistic person. So a lot of times with these things, you can have an interface that works for one person who has a lot of trouble with memory, may not work for another person. Or even that same person when they’re having a good day versus having a bad day.

So, it is very hard to pin down. It comes down then not to an argument about we have to do this to legally comply with the standard, to not get into trouble. It comes down to, you have to do this or you should do this because you want to do the right thing for your users. And sometimes, I talk about this in my talk, that there can be sometimes tension between like business goals and accessibility goals or something like that.

And there are a lot of ways to find the like win . Win. You know we’re improving things for users, for disabled users also improves things for your business goals. But you really have to get out of more of a checklist, we’re doing this because it’s legal, because we need to legally comply with the standard, to like having a more accessibility mindset about it all.

[00:17:24] Nathan Wrigley: Yeah, that makes sense. I don’t know if you’re American, but we’re in America. I’m from the UK. So, completely different sides of the world really. And obviously you take in every other country on the planet, there’s gonna be a different complexion there. Is there broad consensus of how important it is across the world? Or is it very much a case that America’s doing one thing and the UK is doing another, and Australia and all the other countries that we could mention.

[00:17:47] Christina Deemer: I can speak more about that in terms of accessibility in general. So there are different laws in different places, which sounds like a really obvious thing when I say it that way. But what’s really great about WCAG is that it is a sort of internationally recognized standard, and a lot of countries use WCAG as a standard, and they’ll refer to it because it is kept up to date, because it is all testable.

So there are like slightly different laws in different places, but a lot of places do fall back to WCAG, usually the double A standard. Depends on the places and everything, but a lot of times a law may apply only to like government websites, or sites that serve the public interest or something like that.

And I think there’s still a lot of debate around whether or not websites fall under the Americans with Disability Act. There’s still some argument about that. I mentored a developer out of the UK on accessibility at the end of 2021, in the beginning of 2022, and we talked a little bit about some of the laws there and they’re, yeah, slightly different than they are in America, but everything falls back to WCAG.

[00:19:00] Nathan Wrigley: Okay. Thank you. You mentioned in the notes that we exchanged prior to recording this, that there are some, some ways that you can make this job easier for yourself. And you talk particularly about some design patterns that you feel will be able to assist people who, perhaps having listened to this podcast, think, okay, this is something I need to be mindful of. Just run us through what these design patterns are. That may take a long time, I don’t know. You might have a quick version or it may be a long version. I don’t know.

[00:19:25] Christina Deemer: Yeah, in the April 2021 working group note, it mentions dozens of different design patterns. And um, I really encourage people to check that out. Of course, read this spec and look at the working group node and understand all of the different things. But a couple of sort of top things for me are making your content as clear as possible. And a lot of times people think of content as post content.

But content is everything that’s on your site. So it includes button text, it includes how the content in a menu, it includes instructions, it includes headings, and it’s important that all of that is as clear as possible. So if you have multiple CTAs on a page, if you have a CTA for subscribing, what does subscribing mean? What are you subscribing to? Versus registering for a newsletter. You need to make sure that the CTA for registering for the newsletter, versus subscribing to a publication, that they have a separate CTA. That it’s clear that you’re doing two different actions here.

And we talked about readability a minute ago, making sure that you’re using short sentences with simple common words. That is helpful. And that you’re using punctuation intentionally, which sounds like a small thing but using punctuation intentionally, like a period when you mean to use a period and using commas. That’s helpful for, clear content is important for SEO as well. And it helps with users who use screen readers, which includes people with cognitive disabilities who are more comfortable hearing the text, the content, than reading it.

And while a blind person who does not have a cognitive disability may be able to work out the meaning of something that’s not formatted correctly. Somebody who has communication issues may not be able to work out what the meaning of the content is, if it’s not formatted correctly. So the clear content is one. Using clear step by step instructions for something is important. A lot of times we give users feedback only when they’re making a mistake.

But it’s important to give them a little help before they’ve made a mistake in a form. Give them an example of how you want a telephone number formatted. Or like where they can find if a username is actually a user’s email address, make that clear to the user before they’ve tried to submit the form and they’ve made a mistake. Those little bits of instructions sometimes can seem unnecessary or they’re cluttering up the site. If you feel like they’re cluttering up the site, you can hide the instructions round like a little eye icon or something like that.

One of the things that I think is particularly important is not making the user have to remember. If a user wants to upgrade their subscription or change their service plan. They should know what their current plan is, how much it costs, when it is set to expire. They shouldn’t have to remember that when they’re being asked to upgrade to another plan. So that’s another one.

And you see that with a number of cases where, you are asked to upgrade and you’re like what plan am I even on right now? Am I on a particularly high plan? How much money am I, how much extra am I spending to upgrade my plan? And it can be confusing to users. So like, just give them everything that they need on every single screen. That’s a lot better for them.

So those are some more concrete things. And then there are some more sort of conceptual design patterns around things like making sure that a user’s most important tasks are featured prominently on a site. What are a user’s most important tasks? Do you even know what a user’s most important tasks are on your site?

The example I give in my talk is that, you know if you have a library and the team thinks that the most important thing is getting users to sign up for an event, and it takes two clicks for the users to sign up for the event at the library. But, if you look at the usage data, or focus groups, or user testing, like a user’s most important tasks may be figuring out what the library hours are. Signing up for a library card. But maybe to do that you have to click on a bunch of different links and maybe even have to search or something to find out what the library hours are.

So you may have to sort of reconcile what the user’s most important tasks are versus what the team considers the most important. But that’s only possible when you actually know what your users want to do.

[00:23:56] Nathan Wrigley: It feels like there’s a whole subset, and I’m, I’m not saying that this is the norm, but I think there’s a subset of people out there who quite deliberately go out of their way to make things as confusing as possible. So an example that just comes to mind recently is I purchased a flight, and the process of completing the flight purchase was extraordinarily challenging. In that I couldn’t get to the end of it without declining hundreds of different things. I simply wanted a flight, but then came the insurance and the, do you want the hotel at the other end? And do you want the car and all of this? I was just completely overloaded by the whole thing. Getting really frustrated.

[00:24:37] Christina Deemer: Yes.

[00:24:38] Nathan Wrigley: And I thought, but this is intentional. This has been designed to, in a sense, trip me up. Because the button that I wanted to press, which was continue.

[00:24:47] Christina Deemer: Yes.

[00:24:48] Nathan Wrigley: Was masked, and the button which was going to sell me the insurance was large and colorful and obvious. And I feel that there’s a sort of subset of the internet where they’re trying to do exactly the opposite of what you’re describing, because, maybe it’s profit, maybe that’s all it is. It’s as simple as that. So that must be frustrating, shall we say.

[00:25:05] Christina Deemer: Yes, a design pattern, an accessible design pattern, is to make critical paths as short as possible. Anything that can be optional, buying the insurance, upgrading your seat, should be something that happens after you’ve completed the initial purchase. Because it’s so easy for users to get distracted. It’s so easy for users to get confused about what button to push. And again there’s that tension between accessibility needs and business needs. And I really wonder like, I would want to look at the data. Is this really effective for them?

Do they know? Would it be more effective for users if they were allowed to choose whether or not to buy the insurance or upgrade their seat, after they’ve completed their purchase and feel good about that, and then have the option to like do all of these other things. And then you know that the user isn’t going to, is less likely to abandon their task, and then they haven’t even purchased the ticket.

[00:26:00] Nathan Wrigley: I feel also that the language often is deliberately obfuscating what it is that is intended. So you know you get like double negatives, and if you do not wish to achieve such a thing, tick this box. And actually just have to spend a moment thinking about it. Hang on, what does that even mean? Do I want to tick that box or not? And give it a moment’s thought and it comes to you. But I guess those trip wires are just really frustrating.

[00:26:25] Christina Deemer: Yeah. And imagine like a user who struggles with reading comprehension issues, managing a sentence with double negatives. Maybe it’s hard enough for them to just parse the content in the first place, let alone battle that double negative. And maybe they think they’ve done the right thing and have said that they don’t want the insurance, but then they find out that they’ve actually purchased it.

And then they feel exhausted. They feel embarrassed and frustrated. And maybe reluctant to say anything because they don’t want to admit that they made a mistake and didn’t understand the content. It personally makes me feel very frustrated and angry that people maybe intentionally like praying upon people who are disabled. It is, for a lot of people, it may be just a matter of okay, I’ve gotta take a moment, figure this out. What do I wanna do? And it may just be an inconvenience or a nuisance. But for some people those kinds of barriers, it really can take a toll on people.

[00:27:28] Nathan Wrigley: Yeah, and I feel the flight example, albeit was easy to understand, it’s not an essential part of my life. But if I was acquiring something which was utterly critical, trying to access healthcare or something and wasn’t thought through, and I really need to get this form finished yesterday. Those things do matter and so putting the time in to make it as straightforward as possible. It feels like, the word that’s coming into my head here is, clarity, simplicity, those kind of things. Just keep it as straightforward and as easy to understand as possible.

[00:27:58] Christina Deemer: Absolutely.

[00:27:59] Nathan Wrigley: You mentioned that you wanted to talk about in this podcast interview, that you have autism and how this actually impacts you. I don’t wanna lead you off in any particular direction, so I’m just gonna ask you if you want to just describe the experience.

[00:28:14] Christina Deemer: Sure. So I am late diagnosed autistic person. I was diagnosed in March of 2020. So like right as the pandemic started. It was a turbulent time for me. But I also have, I have multiple family members who are autistic and the more I learned about autism, the more I found myself relating to a lot of the things that were talked about. And things like having trouble reading social cues, having some very rigid routines, getting really involved in some special interests and a number of other things, but those are some top things.

And a sort of funny thing is that people have told me, they’re like, hey, you don’t look autistic. And I’m like, what does that even mean? Does that mean that I’m not, I don’t look like the sort of stereotype for an autistic person as a young white boy who likes trains? And granted, trains are awesome, I do like trains. And I do love Star Trek, especially like the autistic coded characters like Spock and Data and Seven Of Nine. But like, autistic people look like people. There are women who are autistic, there are black people who are autistic.

And I think the other thing is that I’m good at masking, and masking is where autistic people sort of adopt neurotypical traits to fit in. And that is something that a lot of people, especially people who are socialized as girls, get accustomed to doing. So like there’s that. But I am autistic. Autistic people look a bunch of different ways. I wanted to take advantage of this platform, this opportunity to address that misconception about what autistic people look like.

And earlier we were talking about my experience on the web. What that looks like and how my autism can inform that or what barriers I experience. And a couple of things came to mind, and one is that definitely like any autoplay content, like autoplay media, or auto play video auto play audio, animations that are not functional, it can feel to me like I’m intending to step into a library and I’ve, and I walk into a rave. That is how it feels. It feels very loud and bright. And that is no knock on raves, everybody likes a good rave sometimes. But you wanna give people the opportunity to like turn off the music, and turn off the flashing lights.

So a thing that I really hope people can do is, if you have some auto play thing. A, don’t auto play anything in the first place, it’s very inaccessible, but like always give users the opportunity to personalize, and turn those things off.

So the other one is like very similar in that it’s flashing and flickering content. And that can feel like looking at the sun. I can feel pain in my eyes, from flashing and flickering content. And it doesn’t have to be that super fast flash that can trigger seizures in photosensitive people. It can just be like, a little too much flash. I can feel it in my eyes and I can have even that like startled physical reaction to it. And that’s just me personally.

I think there are a lot of other people who may have different responses to things on the web and, and I’m fortunate enough that I can, on my team, and this is why it’s great to have diverse teams, is like when we’re building content, when we’re building websites, I can help guide us and say, or help give that feedback about auto playing things and put my foot down and say we are not going to build this in a way that is inaccessible. We are not going to build this animation that seems cute, doesn’t have any functionality or whatever, but I know is going to like ruin somebody’s day or whatever, just because they accidentally like encountered this webpage.

[00:31:53] Nathan Wrigley: Really fascinating. You are educating me in an area that I genuinely don’t have much contact with. So it’s really fascinating. Given everything that you’ve just said, I’m sure there’s gonna be a proportion of people who have woken up to this, during the listening of this, and thinking to themselves, okay, how do I find out more? So just for those of us who are starting on this journey, just give us some idea of where the resources might lie. Where might we go? Who might we speak to? Which organizations? So that could be online, or a book, or an organization, whatever you like.

[00:32:22] Christina Deemer: I think if you’re interested in learning more about accessibility, there are a few organizations that do a pretty good job with providing accessibility education. The first is the company Deque, they make an accessibility testing extension, but they also offer really great courses and training and have a lot of just general resources on their website. They even have a great resource library of accessible components.

There’s Knowbility, which is spelled k n o w b i l i t y. Also has a number of great webinars and they have a conference, so a great place to go for resources. There’s a really great community on Twitter, on accessibility, Twitter. There are a number of experts there, and I’m always a big fan of if you really want to understand accessibility, you’ve gotta read the specs.

And actually, it’s ironic but when some of the April, 2021 working group note that I keep referencing, when that came out, some folks criticized it online saying, this document itself isn’t very accessible. It’s very, very extensive, very thorough, very meaty. And so they went back, God bless them, they went back and they made the document itself more accessible. They added some icons which help with scanning the document. They added some more use cases and examples, so people could better understand how these things work in real life. So it’s a lot. I think it’s actually the working group note on cognitive accessibility, I think is actually sometimes easier to parse than WCAG itself, in terms of the content.

And I also want people to understand that there are probably some accessibility champions in your network. You may have somebody on your team or in your company who has a good understanding of maybe how accessibility intersects with your product or your sector. And talk to those people. I learned a lot about accessibility from the agency I work for called Alley. Shout out to Kevin and Owen, who both really mentored me and helped me really level up my accessibility knowledge. So like use the people that you have in your network. They really want to talk to you about these things. So I hope that’s helpful.

[00:34:34] Nathan Wrigley: Yeah, that’s really helpful. But also just to know that this is an area where there are actual jobs. There are people who do this, who would like to assist you. There’s probably somebody in your local area who takes this all very seriously, and would be willing to speak to you on the phone. It’s not just, okay, I heard a podcast, I can forget about it now. There are calls to be made and people to meet who will help you with this.

[00:34:54] Christina Deemer: Absolutely, and so I don’t do accessibility full time at my job. I’m a developer. So there may be accessibility champions who are developers in your organization. There may be people who are designers who work in content, who work in strategy. The awesome thing about accessibility is that it touches all areas of the product. And, there are also people, yes professionals who focus exclusively on accessibility and who can do things like perform an audit of your product.

And if you are starting from zero on this, a lot of times those people can be the best people to reach out to because they are going to give you that comprehensive look that includes content design, you know development, all strategy, like all aspects of accessibility.

[00:35:41] Nathan Wrigley: You mentioned that you work for . A company called Alley. I’ll link in the show notes. Your agency isn’t uniquely focusing on this area?

[00:35:48] Christina Deemer: No.

[00:35:49] Nathan Wrigley: It’s a web design agency?

[00:35:51] Christina Deemer: Yeah. So the Alley Group is an agency that works with a lot of enterprise level publishers. And I work for a company within the Alley group called Lead, and we’re a platform for mid and small size independent publishers. But accessibility is something that the Alley group takes very seriously.

We work with a lot of very large publications. So we have to make sure that we get this right for them, and the millions of people who visit those websites. And we are hiring. If you’re interested in joining a group that takes accessibility very seriously, please visit alley.co/careers. We are always hiring software developers and have a number of other positions available.

[00:36:33] Nathan Wrigley: This is such an interesting subject. I feel that we could go on for hours more. But Christina Deemer, thank you so much. Is there a place where you are comfortable people connecting directly with you? It may be Twitter or email?

[00:36:44] Christina Deemer: Yeah, you can find me on twitter at c a h d e e m e r. And this was so much fun. It went by so fast.

[00:36:52] Nathan Wrigley: Thank you so much for joining us. I’m really hoping that it’s gonna have opened some people’s eyes to something, which seems to be incredibly important. Thank you.

[00:37:00] Christina Deemer: Thank you.

On the podcast today we have Christina Deemer. Christina is a senior UX developer at Lede, a company of the Alley Group, where she champions accessibility and headless WordPress in her work with publishers and nonprofits. She’s passionate about inclusivity and community and has spoken at a variety of events about the subject.

Christina is autistic and brings her personal experience with neurodivergence and disability to bear in her work.

At the recent WordCamp US, Christina gave a presentation called “embracing minds of all kinds, making digital content usable for people with cognitive disabilities”. And it’s this talk which is the foundation of the podcast today.

In her description of the presentation, Christina wrote, “cognitive disabilities are among the most prevalent types of disabilities, yet experts have struggled to provide web accessibility best practices around this area due to cognitive disabilities being such a broad category. However recent work by standards groups has begun to address this deficiency”.

In past episodes, we’ve covered website accessibility from some different angles, and today we focus on how the web might be experienced by people with cognitive disabilities.

First, Christina talks about what the term cognitive disabilities actually means, and what it encompasses. It’s a wide range of things, and so we talk about how people may differ in the way that they access the web. Memory, over complicated interfaces and readability are a few of the areas that we touch upon.

We also discuss what legislation there is in place to offer guidance to those wishing to make their sites more accessible, and as you’ll hear, it’s a changing landscape.

Towards the end, Christina talks about her own late diagnosis of autism and how this shapes her experience of the web, particularly with auto-play content and when web design includes elements which flash or flicker.

Typically, when we record the podcast, there’s not a lot of background noise, but that’s not always the case. This is the last of the live recordings from WordCamp US 2022, and you may notice that the recordings have a little echo or other strange audio artifacts. Whilst the podcasts are more than listenable, I do hope that you understand that the vagaries of the real world were at play.

Useful links.

Deque

Knowbility

WCAG

W3C Working Group Note 29 April 2021

388: Durable Objects

Robert and I jump on to chat about Cloudflare’s product Durable Objects. It’s part of their Workers platform, which we already use at CodePen a good bit, but with Durable Objects…

Global Uniqueness guarantees that there will be a single instance of a Durable Object class with a given ID running at once, across the world. Requests for a Durable Object ID are routed by the Workers runtime to the Cloudflare data center that owns the Durable Object.

In their intro blog post a few years back, they call the “killer app” real-time collaborative document editing, which is obviously of interest to us. So we’ve been tinkering and playing with how that might work with CodePen’s future technology.

Time Jumps

  • 00:25 What Robert’s been up to
  • 01:08 What is a durable object?
  • 02:52 Using Workers with durable objects?
  • 08:13 Sponsor: Equinix Metal
  • 08:51 How does clientside work with Workers?
  • 15:58 What if the durable object dies?
  • 19:47 Cost of durable objects

Sponsor: Equinix Metal’s Startup Partner Program

Equinix Metal’s Startup Partner Program helps early stage companies level up. Their experts work with startups like Koord and INVISV to build their competitive edge with infrastructure. Equinix Metal provides real time guidance and support to help startups grow faster. With up to $100,000 in infrastructure credit, access to Equinix’s global ecosystem of over 10,000 customers and 1,800 networks, they might just be what you need to take your startup global.

Visit metal.equinix.com/startups to take your startup to the next level.

The post 388: Durable Objects appeared first on CodePen Blog.