Cancel

Justin Tadlock

Addressing the Theme Design Problem With Gutenberg’s New Block-Based Widgets System

I could hardly sleep last night. Once in a blue moon, I have an idea I want to try out. While my day job as a writer means I spend far less time breaking sites through the rigorous trials and errors of building plugins and themes, some problems bug me with WordPress, the sort that keeps me from dozing into restful and peaceful dreams.

Last week, Gutenberg 8.9 dropped the experimental flag from its block-based widgets system. Overall, it was a solid first outing for a feature that should land in WordPress 5.6 this December. However, the largest problem centered on how theme authors would be able to style widgets in traditional fashion. Because actual widgets are being phased out and replaced with blocks, theme authors will no longer have access to the standard widget and widget title classes. This is problematic because there is no predictable way to style all widgets of a particular sidebar to look the same.

The classic example is of the boxed widget design. Many themes, such as the popular Colibri, employ such a design for their sidebars as shown in the following screenshot.

Screenshot of the Colibri WordPress theme with a boxed widget design.
Boxed widget design in right sidebar of Colibri theme.

In its current state, there is no reliable way for theme authors to create such a sidebar design via the block-based widgets system. Because there is no way to exert any sort of control over the structure of whatever content users will drop into a sidebar, it would be easy to look at this situation and think that theme designers are losing control.

Based on a recent GitHub ticket and a related Slack discussion from earlier this week, it does not appear that the Gutenberg development team intends to create parity between the old and new widgets systems, at least as far as theme design is concerned.

It bears repeating. I am a fervent supporter of handing over this type of ultimate control to the user. However, we need to balance that with helping them to make smart choices.

Theme authors must begin thinking about how this impacts the work they do and come up with creative solutions for sidebars, widgets, and other areas that will be affected by full-site editing in the future.

A Potential Solution

That thing that kept me up last night was an idea of combining block patterns, one of my favorite features, with widgets. The trouble was that the block-based widgets system does not currently support block patterns. And, until a quick discussion with Mark Uraine, one of Gutenberg’s designers, on a GitHub ticket, the idea did not seem to even be on the table.

For theme authors, the traditional sidebar and widget system of the past was nothing more than a pattern. WordPress provided theme devs with the ability to set a wrapping HTML element for the entire widget and the widget title. It was a rigid and inflexible system, but it was a reliable standard.

Block-based widgets are the complete opposite. They are essentially a free-for-all where users can drop arbitrary content into a “block area.”

What happens when we combine the structure of patterns with the flexibility of blocks inside of sidebars?

That was the idea that got me out of bed and behind the computer screen early this morning after my restless night. It was such a simple concept. Theme authors could provide a “widget” pattern to their end-users. This would provide users with a choice between what the theme author thinks best and forging their own path — the best of both worlds.

Example of using patterns for block-based widgets.
Simple example of recreating a boxed “widget” pattern.

And, here is where the beauty of the block system really comes in. Theme authors can create any number of patterns. This provides even more options for users.

Regardless of whether the Gutenberg plugin currently supports patterns for the block-based widget system, the idea was simple to test. In a sidebar on the new widgets screen, I merely needed to add a new Group block with the widget class. Then, I added an H3 Heading block with the widget__title class. Those classes may even be unnecessary in the context of patterns unless theme authors want to directly target them. Outside of the custom classes, I added a simple background to the Group block and changed the text color of the Heading. I also inserted an empty paragraph where the user’s custom content would go.

Afterward, it was a simple matter of testing it with various blocks.

Using a block pattern to encapsulate a widget.
Faux block pattern in the widgets block editor.

I would love to know what theme authors and the Gutenberg team think of the idea. I think it has some merit while soothing some of the transitional pains between traditional widgets and block-based widgets.

The biggest issue I see is the discoverability aspect. Will end-users know these “widget/block patterns” exist if theme authors went this route?

Category:
Tags: , ,
7

7 responses to “Addressing the Theme Design Problem With Gutenberg’s New Block-Based Widgets System”

  1. For theme developers, would you address best practices for blocks?
    Specifically, custom blocks – function plugin or style/theme? Which is faster – creating our own blocks or loading a block library?

    Will we – as custom theme builders – be expected to keep up with custom function plugins? Creating one to be used on all our themes (that we can then upgrade) defeats the purpose of a small custom plugin doesn’t it? I would love your thoughts on how we best integrate custom blocks and styles and patterns!

    Thx!

    Create forum topic from comment

    • It’ll probably change depending on the situation. Personally, I would probably build individual block plugins. For example, if I have a custom testimonial block I want to use with one or more of my themes, I would make that a single block plugin. Of course, in development, you could create all your block plugins in a monorepo if you prefer everything in one place.

      Another route would be to create a big block library/collection plugin with all your blocks. It’s easier to maintain and market that, I suppose. However, you might be stuck supporting/styling all those blocks with every theme.

      For block styles and patterns, those should generally be specific to the theme. There may be some that you reuse in different themes though. You might consider separate repos for those and pull them in via Composer. If you’re building very generic patterns (e.g., three columns, two buttons next to each other, etc.), it might be worth considering a pattern library plugin.

      Ultimately, what I think the lead Gutenberg/WordPress devs want to see is the community move toward single block plugins. At some point, we’ll have a block management screen in the admin, which will cater toward that.

      Create forum topic from comment

  2. In the beginning, I was very sceptical of the new block paradigm, particularly for data driven sites, which are, by my estimation, most “industry sites” that use custom theming. But now it reminds me more of the old movie industry tactic of selling people the same content on new packages, starting with vinyl, then tape, CD, blue-ray, and now streaming…

    Create forum topic from comment

  3. From an outsider perspective, it feels like even the Gutenberg team doesn’t know where the goal line is. Stumbling toward an unknown can be exciting, but not for the rest of us enduring this work-in-progress. With that said, designing a new system for millions of people is hard. I wish the team the best of luck.

    The idea that blocks can be universal—usable in content, widget areas, headers, and footers—is exciting. However, I would’ve loved to see a more laid back strategy to begin with. Enable blocks, make the API available, then let theme authors duke it out for the best approach. Once there’s a clear winner, absorb that approach into core. Let theme authors and the community figure out all the ways to not do it right first. At the moment, Gutenberg is too opinionated when it should in the phase of collecting data and ideas instead. As far as I know, there’s still a long way to go until completion. Maybe it’s not too late to roll back and adopt the strategy I’m suggesting? (They didn’t have to replace the classic editor that quickly.)

    It seems like the Gutenberg team doesn’t have direction because they’re dealing with the same problems commercial plugin developers have been dealing with in drag and drop page builders.

    Problem #1
    Pushing everything toward front-end editing, live editing, or in-page editing is not always a good thing. Hundreds of options are required to perfect CSS properties. This is why hidden sidebars and floating modals are used in all page builders. There’s simply not enough room to display all the settings users would find useful, while trying to display the actual web page too.

    #2
    The front-end editing approach leads to overuse of tiny sidebars and floating modals. It’s like every team on the market (including Gutenberg) is trying to take away as much work-related interface as possible.

    Designers and developers usually have at least 3 views opened at any one time, one view for the actual page being edited, one for php/html/js, and one for CSS. With page builders and now Gutenberg, everything is in tiny little sidebars and sub-panes.

    I understand Gutenberg is supposed to make it easier for normal users, not designers and developers. BUT, how about making it easier by giving people more space to work with? Find ways to replicate the designer/developer work environment for normal users. Don’t get me wrong. I’m not suggesting we make CodePen the new WP editor and force normal users to code.

    For example, instead of jumping straight to page building with an invisible interface, why not attempt something like the backend interfaces of most page builders first and then tack on front-end editing later? Like I mentioned in problem #1, front-end or live editing is not the answer to everything. It’s really useful for quick content, font size, and color edits, but it’s far from and end all, be all solution.

    #3
    Abuse of sidebar and sub pane settings. Theme authors and even WP core will inevitably stuff everything into these little sidebars, toggles, and pop ups. We’ve already seen it happened in Customizer API. It’s inevitable because designing a new interface for each unique setting to improve usability is just NOT cost effective. Why waste time designing and coding a new user experience when you can stuff one more thing into the sidebar or into the hidden toggles? It’s just one more!

    #4
    Another space saving, often abused tactic is overusing icons even when icons are unnecessary. Every design/dev team act as if everyone universally understand what all these icons mean. We don’t. The hamburger icon took a long time for people to adopt and that was thanks to the entire internet, not just WordPress. Think about how much effort it went into adopting just one single icon. How many icons does Gutenberg use?

    Icons are great when used sparingly. They can be visual cues or markers to let you know what you can do or where you are on a very long page. But when tens of them are displayed back-to-back, uniformly, they lose their usefulness.

    One benefit of front-end editing is you immediately know what you’re about to edit. You know because front-end elements are rarely uniformed. For example, headings are bigger and bolder than paragraph texts. You can quickly scan the page for the heading then click on it to edit. On the back-end it takes more effort to find the right element. Icons work the same way. When there’s just a few of them, they’re useful because they will immediately help your eyes scan the page. But, display a bunch of them together at the same size and you’ll accomplish pretty much the opposite of what you’ve set out to do.

    #4
    Too many entry points and at the same time not enough context. Currently, Gutenberg uses right sidebar for settings, left sidebar for blocks library, and top toolbar for modifiers and again accessing the library, plus some hidden features like design pattern, reusable blocks, etc. Instead of one system, it feels like multiple systems patched on top of each other without any context to make sense of them and make sense of how the entire thing flow.

    I’ve been a WP user and theme author for a long time, even I don’t know what half these things are. In my experience of using Gutenberg, I have a hard time finding things. When I stumble across something interesting, I have hard time understanding what it is and what it does. The most frustrating problem is following edit actions into something unexpected. What I mean is I would click on something expecting one specific follow up to my action only to end up looking at multiple options to edit with no interface to make sense of what I’m looking at.

    Here’s a smaller nitpick. I don’t understand the need to introduce new terms. Instead of “design pattern”, why not “partial template”? Even tho it would sound more like developer lingo, it’s been around for a long time already and it’s not like “design pattern” is more helpful to normal users. Yes, I can design, code, and understand tech lingo but I’m also being introduced to Gutenberg as a first time user just like millions of other people. I don’t understand where “design pattern” begins and ends. What is in a design pattern? Using “partial template” will confuse people half the people. Using “design pattern” confuses all the people :D

    Some of the criticisms Gutenberg received is deserved because it chose to stumble down a new path instead of re-using and building on top of what people already know. Going back to my “partial template” vs “design pattern” nitpick, it took a long time for theme companies and affiliate bloggers to teach normal users what a “template” is. Now that WP core is ready to enter the page builder market with Gutenberg, it should build on top of that instead of adopting new stuff and forcing people to rewire their brains.

    The idea and potential is exciting, but it seems the execution is extremely rushed and lacking in many areas. Also, there’s no master vision for how to tie everything together. It looks like they’re stumbling down a path they don’t understand because the editor is exhibiting the same problems other companies have been dealing with in commercial editors/page-builders.

    Sorry to hijack your article. I didn’t plan on writing such a long response.

    Create forum topic from comment

  4. And, until a quick discussion with Mark Uraine, one of Gutenberg’s designers, on a GitHub ticket, the idea did not seem to even be on the table

    I’d say patterns should be present anywhere blocks can be inserted! Specific categories of patterns might be more relevant for some specific areas, but for widgets it should likely just show all patterns.

    Another thing that should be attempted soon in the plugin is augmenting block rendering server-side with the default widget classes to see if theme compatibility can be increased out of the box. Thanks for the thoughts!

    Create forum topic from comment

    • Was there not already an attempt to “augment” this on the server side earlier? I may be misremembering this. Nevertheless, I do wonder if that is an ideal approach. I suppose you could check for a heading and following content and wrap them. However, that seems tough to get right and full of edge cases.

      I’m a fan of wiping the slate clean and starting over by having an opt-in “block areas” feature for theme authors that is independent of the old sidebars/widgets system. Right now, if I am reading the code correctly, Gutenberg is essentially creating a widget that houses blocks and outputs them on the front end — literally square peg, round hole. This should be so much simpler and not create technical debt for a brand new feature. Do not try to fit the new block area system into the old sidebar system.

      The new system will seem forced, particularly because (at least right now) it requires that theme authors opt out if they are not ready. Let them start using a new and exciting feature at their own pace.

      I am guessing the idea is that the team wants to ship new features to as many users as possible. This requires putting a new thing inside of an old thing. But, I think you can lean on the plugin/theme development community to do this right.

      Also, thanks for the feedback on making patterns available to the “widgets” area. That will be helpful.

      Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.