7 Comments

  1. Cathy Tibbles
    · Reply

    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!

    Report

    • Justin Tadlock
      · Reply

      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.

      Report

  2. TS
    · Reply

    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…

    Report

  3. Tung Do
    · Reply

    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.

    Report

  4. Matías
    · Reply

    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!

    Report

    • Justin Tadlock
      · Reply

      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.

      Report

  5. Carla Chalmers
    · Reply

    I agree with Tung Do, I’ve been in this game forever and the use of the word “patterns” confuses the heck out of me.

    Report

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: