The State of the Gutenberg Project: A WPBlockTalk 2020 Reflection

Pile of blue Lego bricks
Photo by Iker Urteaga on Unsplash

Last week was the first ever WPBlockTalk, an online event for the Gutenberg project and everything Blocks in WordPress. It was a terrific exploration of the possibilities and direction of Blocks, Full-Site Editing, Global Styles and how WordPress will look in the future.

When Gutenberg was still a nascent project, I was working on the CMS team at Time Inc., seeing Gutenberg through the needs of enterprise publishing. Today, I work at Bluehost, looking at Gutenberg through the needs of individual bloggers and small organizations. In the past two years I’ve gone out into the WordPress Community to teach Gutenberg to hundreds of beginners in workshops and one-on-one settings.

The Gutenberg project has come a long way, no matter which lens I look at it through. Many APIs have solidified, patterns have clarified and simplified and performance is tangibly better. There are of course still pain points for beginners and enterprise users — interactions that leave something to be desired, unaddressed bugs and omissions that feel glaring — as well as the feeling that despite accelerating maturity, we’ve yet to see “Gutenberg’s Uber or Instagram” or realize the impact those kind of community-shifting products can have on the ecosystem.

In WPBlockTalk, there were some really spectacular sessions touching on where we are now, how to bring legacy content into the present, how people have extended Gutenberg as well as where we’re going. These are my four key takeaways from the event.

The success of Blocks will look very different than the success of Plugins & Themes

One of the key advantages of WordPress is the sheer quantity of free Plugins and Themes available. But often strengths are also weaknesses.

There are dozens of Plugins just for the specific need of adding social media buttons and automated social sharing to WordPress. Similar to buying a car, Plugins and Themes are marketplaces saturated with brands and choices. On one hand, you have plenty of options, a healthy amount of competition often helps drive innovation and you can find the best fit for a particular project. However, with plenty of choices can come choice paralysis, an exhaustive research process and time-intensive undertaking to feel confident you’ve selected the best balance of quality, features, safety and value the marketplace offers.

Eventually, we just need to make a choice and often live with that choice for multiple years.

I used to think this same calculus would apply to Blocks.

Both that the quantity of Custom Blocks would indicate the health of the Block ecosystem and that we’d inherit a variation of these same advantages and disadvantages.

WPBlockTalk helped me dismiss this idea.

We will always need hundreds, perhaps a few thousand Blocks. But frankly, if we see 25,000 or 50,000 Blocks, that won’t be a sign of success. If a few years from now there are dozens of Button Blocks instead of a few, that will be a sign of failure — that Core Blocks were too inflexible to be implemented and extended for most common uses.

Right now, there are a number of popular suites of Custom Blocks including CoBlocks, Atomic Blocks and Stackable. To be clear, I think it’s a good thing that today many of these Plugins have a duplicate of a Core Block. Many of them also provide some Custom Blocks that are effectively just a prescribed assembly of Inner Blocks — something like a Call-to-Action Block that has Inner Blocks like a Heading, Paragraph and Button — that will in some ways be made irrelevant by Block Patterns. However, these suites can move much faster than WordPress Core, push the boundaries of what’s possible through innovation and iteration. They can empower people to build today while Core Blocks mature. Already, Core has successfully borrowed ideas from these suites.

But in time, WordPress should bake enough features and extensibility into Core that a Custom Block, one that stores data in a custom structure and data keys, should be frowned upon if there’s an equivalent in Core. We are not there yet.

That is not to say these suites should or will entirely disappear, either. Perhaps they will evolve to be closer to EditorsKit — a Plugin that extends Core, providing new Block Styles and extends the available options of Core Blocks. Perhaps the real value of these custom suites today and in the future is not necessarily the Custom Blocks they add, but the prescribed aesthetics, design thinking, workflows and their unique blends of custom controls.

Baked into the Gutenberg Project are a number of concepts that lend themselves to this future. The Block Transforms API and @wordpress/deprecated will allow content to gracefully upgrade and transition from custom solutions to Core. Block Styles will allow developers to put their own unique spin on Core Blocks. Block Patterns will allow developers to create recipes of blocks that can be used anywhere. Block Templates will allow developers to predefine assemblies of blocks for a specific Post Type.

But the Block Directory, ideally, should never achieve the volume of either the Plugin Directory or Theme Directory on WordPress.org. Short of a huge WordPress Plugin renaissance where unique Custom Blocks are necessary, a Block Directory with tens of thousands of Blocks will be a sign that Gutenberg APIs failed to be flexible enough or that documentation and examples to leverage those APIs were far too lacking.

Yes, there will be Custom Blocks to connect and embed other services. Yes, there will be Blocks that never belong in WordPress Core. Yes, many WordPress Plugins will still need their own Custom Block. Yes, extension on top of Core Blocks presents its’ own set of challenges. But I think the calculus of fewer, much more flexible Blocks is a much better recipe for WordPress’ long-term success.

Perhaps the most critical and essential missing feature for the current and next phase of Gutenberg is granular permissions and restrictions

With Full-Site Editing and Block-Based Themes come a host questions about how developers can check user permissions and provide restrictions such as:

  • Does the current user have permission to modify the Site Header?
  • Is there a way to prevent users from assembling their entire site in the Site Header or simply adding an undesirable number of Blocks to a section of a site?
  • Can a developer fine-tune block quantities, order and availability on a document-level, per-Pattern or per-Template basis?
  • Can a developer contextually limit options available based on a variety of factors ranging from the state of the current document, Post Type, use in Inner Blocks, Global Styles and Site Settings?

These are restrictions WordPress has often created in other ways or were inherent due to the limitations of the Theme or a built-in feature.

Block-based sites will free us from many restrictions, which again will be both an advantage and disadvantage. Users will have more freedom to create to their vision, while also perhaps lacking helpful “decisions not options” that guided them with best practices and baked-in design expertise.

One of the greatest advantages of Gutenberg is that it’s contextual in presentation. Instead of a mile-long edit screen of scrolling through options, options present themselves as-needed or when a user deliberately requests those options like the Document Sidebar.

But to grow beyond content editing to site editing, Gutenberg is going to need new, granular controls for developers and site owners to contextually pair-down and remove options to avoid the default Block Editor experience providing choice paralysis and an overwhelming number of options.

Sometimes the value of Block Patterns will be as a starting foundation to make significant tweaks and modifications, where other times providing limitations and guardrails will be the true value of Patterns. Long-term I expect we’ll see lots of confusing duplication between Patterns and Custom Blocks, unless we find a way for developers and users to optionally attach limits (even overridable ones) to inserted Patterns.

Templates have a good start on this, allowing developers to lock inserting new blocks and lock the order of Blocks. But other restrictions such as providing a minimum and maximum number of Blocks in a Document, limiting which Inner Blocks are available in a specific instance of a Block inside a specific Template, limiting which alignments, colors and options are available based on other context and settings will be crucial to avoid recreating the overwhelming mile-long options screen, simply nested and requiring multiple clicks.

Sometimes it’s not even about limits, it’s using context to make smart decisions. Right now, Blocks often require a lot of manual color selection on an advanced layout. Registering not only custom colors, but the relationships in-between them could go a long way in reducing repetitive work so the editor can use these relationships as defaults that can be overridden by users.

During the impromptu Themes panel in WPBlockTalk, the biggest takeaway I had was that freedom of choice is a great and necessary default, but in reality the value many developers provide users is guidance via restriction and their design expertise by prescription. Rules can be a catalyst that empowers users to faster achieve goals and better maintain uniformity across a site.

The river-bridging moment for the Gutenberg project will be the delicate blend of Full-Site Editing, mixed with Block-Based Themes and Global Styles

For anyone who has followed the Gutenberg project, it’s a bit of an understatement to say when the first phase launched in WordPress 5.0 some worried about the direction of WordPress, whether we were crossing a bridge onto stable, fertile ground or to a mirage over quicksand. In hindsight, I still look back on that moment as the wrong way to do the right thing. The best possible outcome, that nothing went cataclysmically wrong, doesn’t validate the chaotic change management of WordPress 5.0’s launch.

In that moment, the transition to Gutenberg felt like the “river-bridging moment.” The moment where we would go from a bank of comfort and familiarity to an unexplored new reality.

Again in hindsight, few WordPress sites drastically changed in the months following. Yes there was a new editor, but the end products still appeared mostly the same — by design and a nod to the quality of WordPress 5.0. Most block suites — particularly the Core blocks — weren’t yet robust enough to build sites, nor were many Themes designed with Blocks in mind, even if they were compatible.

However, the bridge from WordPress 4.9 to WordPress 5.0 is a short, unmemorable road connection in comparison to the epic suspension bridge we have ahead.

With Full-Site Editing, Block-Based Themes and Global Styles, WordPress will be shedding (or beginning to shed) much more of the familiar parts, interactions and norms we know to almost become an entirely new product. Everything from code norms, to data storage norms, to interfaces and workflows will be reborn. Not everything will change, but it will arguably be the largest step WordPress has ever taken.

There will still be backwards-compatibility and if your Theme doesn’t opt-in to some of the new features it may not even feel like a big change. The Customizer, Widgets, Menus and other tools will quickly become legacy WordPress, even if they aren’t going anywhere anytime soon. On new sites, users who cross that suspension bridge to New WordPress, will be pioneering a new world with new rules, new ways of thinking and new opportunity.

Maybe you haven’t learned JavaScript deeply. Maybe you haven’t built a Custom Block. Maybe you’re using third-party tools like Divi, Beaver Builder or Elementor and haven’t spent much time in Gutenberg. Maybe you’ll stay in the historied, old-world norms of WordPress.

But unlike content editing in phase one, where it was designed to produce sites that largely looked the same, the emergence of Block-Based Themes, Full-Site Editing and Global Styles will be much more visible both to site owners and their visitors.

Long-term, the most exciting parts of Gutenberg aren’t blocks, it’s all of the tools, guidance and automation that are adjacent to them

Blocks are undoubtedly exciting and important to the future of WordPress. Blocks are still new-car shiny, but many Core Blocks have already gone through multiple iterations, as well as the Block Editor around them. There will be other blocks added to Core, particularly to support Block-Based Themes such as the Query Block… but in general there aren’t tons Core Blocks to be added. The blocks we have now are the vast majority of what we’ll have in a few years, even if we’ll iterate on global block options, per-block options, Block Styles and Block Patterns.

The most exciting part of Gutenberg, at least to me, is the user experience around and adjacent to Blocks. Can we suggest users use semantic headings instead of short, bold paragraphs? Can we recommend a user use three columns instead of three bullets right before publishing for better use of screen real estate? Can we provide valuable color, typography and visual rhythm advice without being Clippy in Microsoft Word? Can we warn users about the responsibility of capturing personal information and creating long forms without breaks?

Also, WordPress isn’t the only part of a site owner’s online presence. Can updating a WordPress “Hours Block” update business hours on Google, Yelp and other services? Can creating a new Gallery in WordPress create a Flickr gallery or Instagram Post with the included photos? Or in reverse? Can an external A/B testing system programmatically edit WooCommerce blocks based on a test result?

The Block Editor is great, but perhaps some of the biggest potential for the Gutenberg project exists in the relationship Blocks can have with the external, web ecosystem — both how edits in the Block Editor can be pushed to other services and how external systems can automate content creation and edits on the WordPress side.

In Summary

WPBlockTalk was a great event that gave me a lot to think about. I’m really excited about the future of Blocks, the Gutenberg project and how they’ll shape the future of WordPress and expression on the web.

I think it was really valuable to pull information sharing and discussion out of the mountain of GitHub issues and Slack channels. Those environments can be quite noisy. Whether you work on Gutenberg full-time or casually check in every few months, getting even a partial picture of what’s happening can be extremely difficult.

Noisy environments flooded with overwhelming amounts of information can unintentionally suppress speech. In our project’s case, this can have bidirectional effects between people in charge and the greater community they’re serving. It can become difficult for leaders to share decisions, project kickoffs and foster discussions, while also difficult for a larger community to participate in discussions, provide feedback and share ideas earlier in the process.

There is little helping the rapid pace and large quantity of information in our collaboration tools, but taking regular, deliberate moments to step outside noisy environments, outside the limitations of text-based communication for virtual events, in-person events and other mediums like screencasts, is a great way to humanize and provide greater clarity to the Gutenberg project for everyone. I really hope we’ll see more Gutenberg-focused events like WPBlockTalk in the future!