With its growing list of features and blocks, it’s difficult to know where to begin in preparing an existing WordPress plugin for Gutenberg. That’s why we’re going back to the start to focus on the one change that has kept us most excited about Gutenberg since day one—the block and its ability to unify the content creation interface.
Unifying Content Creation in WordPress
Before reimagining how our Give plugin will integrate with Gutenberg, it’s important to first understand the focus of the new editor and the problems it aims to solve. Like most of the WordPress community, we got our first glimpse of the Gutenberg vision through Matt Mullenweg’s early description of the project:
“The editor will create a new page- and post-building experience that makes writing rich posts effortless, and has ‘blocks’ to make it easy what today might take shortcodes, custom HTML, or ‘mystery meat’ embed discovery.” —Matt Mullenweg
For all of their quirks, the shortcodes and “mystery meat” that Mullenweg mentions represent some of the most powerful and relied upon functionality of Give and thousands of other plugins over the past decade. The ability to insert a donation form via shortcode or embed a YouTube video simply by pasting a URL was a big deal—assuming you knew where to look, which knobs to turn, and how to turn them.
In this respect, the true value of Gutenberg is not in the new tech it brings to the table, but rather in the surfacing of existing functionality that is too often out of sight and out of reach for the average user. With this focus in mind, let’s explore some of the opportunities within our own Give plugin that stand to benefit from a Gutenberg upgrade.
Step 1: Define the Plugin’s Purpose
In his Single Purpose Philosophy, our Head of Support Matt Cromwell writes, “Excellent plugins excel at one thing, no matter how simple or complex it is.” Identifying that one thing provides a North Star that guides every decision made by our team and keeps us focused amidst the bells and whistles that could otherwise become distractions.
Give’s sole purpose is to help you effectively collect donations on your WordPress website. Just as this purpose guides our day-to-day plugin development, it also determines which areas of our plugin we choose to prepare for Gutenberg and the order in which we approach them.
Step 2: Plan for a Split User Base
While we’re optimistic about the eventual success and widespread adoption of Gutenberg, we also know this process will take time. Some users may choose not to upgrade past WordPress 4.9 in order to preserve their existing workflow, while others may do so with the Classic Editor plugin installed.
Gutenberg’s adoption rate will grow over the months and years ahead, but a significant portion of users will remain in the Classic Editor for quite some time.
In the transitional period that follows Gutenberg’s release, we expect to serve a user base that is made up of a mix of early adopters and legacy users that is likely to be the case for months, if not years, into the future.
With this mix of users in mind, we are practicing a policy of progressive enhancement that allows us to take advantage of what Gutenberg does best without compromising the core needs of our audience as a whole.
Step 3: Survey Opportunities
With our singular purpose and our users’ needs in mind, it’s time to survey opportunities to improve the user experience with Gutenberg. Let’s start by examining a common Give user flow:
- Install the plugin.
- Build a donation form.
- Embed the donation form via shortcode.
- Manage donations, donors, and reports over time.
Examining a plugin’s user flow can reveal which areas of the plugin are ripe for Gutenberg integration.
Given what we know about Gutenberg’s focus on creating, previewing, and publishing content, the obvious candidates for integrating Give with Gutenberg are form building and embedding. Both of these user experiences stand to benefit from the strengths of Gutenberg, but which one makes the most sense to pursue first?
Step 4: Prioritize Pragmatically
It’s tempting to rethink what our entire user interface might look like if it was built with blocks from the ground up. It can even be helpful to record that thought process and dream big without constraint before coming back to reality.
The video below shows exactly such an exercise in which we explored the idea of introducing blocks into the Give donation form builder.
While this exploration was an important step in the auditing process, we ultimately decided against incorporating Gutenberg into our form builder for several reasons:
- Too much, too soon. Form-building represents a major chunk of functionality within the Give plugin. Everything from form fields to the configuration of payment gateways is affected by our form builder. To overhaul that experience as our first foray into Gutenberg territory would be a dive into the deep end that poses unnecessary risks to our business, our product, and most importantly, our users.
- We recognize what works. While we have major plans to improve Give’s form-building experience in the months ahead, we’re also keenly aware that our existing approach has a long track record of success. It would be foolish to replace such a critical piece of our plugin with a different approach that has yet to earn the full confidence of the WordPress community.
- We control our own destiny. Our team is fortunate that so much of Give’s functionality resides within our own custom post types that we control independent from Gutenberg. That gives us the luxury of providing a plugin that is fully compatible with both Classic and Gutenberg editors while gradually introducing new functionality at our own pace.
Overhauling the core functionality of our plugin clearly isn’t the most pragmatic first step, but surely some parts of the user experience within Give stand to benefit from Gutenberg. Let’s keep digging.
Step 5: Identify Low-hanging Fruit
Today’s WordPress content editor is littered with “shortcode generator” buttons.
With no built-in method of shortcode discovery, WordPress developers have long been forced to come up with their own solutions to the lack of shortcode visibility in the editor. As a result, the existing TinyMCE editor has become peppered with buttons and dropdowns that launch “shortcode generators” in an attempt to ease the frustration associated with shortcode configuration. While this is a small portion of the overall user experience within Give, it’s a major pain point for users which stands to benefit from a block-based approach.
The migration of shortcodes to Gutenberg blocks will finally place plugin-generated content as a first-class citizen in a consistent UI shared by its WordPress core counterparts.
WordPress Shortcodes vs. Blocks
By comparing these two paradigms, it is clear that Gutenberg blocks solve many of the problems that have long frustrated WordPress users regarding shortcodes.
- Require front-end visit in order to preview
- Require multiple rounds of “guess and check” between editor and front end
- Require prior knowledge of their existence
- Require prior knowledge of their attributes
- Render previews immediately in editor
- Reflect real time changes in editor
- Discoverable via the block inserter
- Display attributes in visual interface
Whereas changing up our form-building experience involved a mix of pros and cons, the decision to migrate our existing shortcodes to blocks is a no-brainer. Doing so will immediately improve the experience for Gutenberg users with zero impact on our legacy user base.
With that, we’ve found our Gutenberg starting point.
The Road Ahead
For all of the twists and turns throughout Gutenberg’s development, it’s reassuring that our team’s decision to begin by migrating shortcodes to blocks reflects the same motivation that sparked the concept of the block-based editor in the first place. The lofty goal of unifying content creation in WordPress is one in which core, theme, and plugin developers must all do their part.
The new Give donation form block reveals controls and attributes that previously relied on the user’s knowledge of shortcode attributes.
With our starting point established, we’re ready to move into the design language and development of a Gutenberg block later in the series. See you there!