This Changes Everything: Gutenberg is Good Now

WordPress Gutenberg

At WordCamp US, it became clear that the Gutenberg editor is a tangible improvement to WordPress—and, more importantly, is really going to happen.

We’ve just returned from this year’s WordCamp US. In addition to the wonderful opportunity to catch up with the community, we also got to be there for one piece of colossal news: Gutenberg is actually good now.

In two tech demos (by Morten Rand-Hendriksen, and then by Matt Mullenweg at the State of the Word), Gutenberg live-demoed as a feature-rich content editor that has made astonishing progress since I last looked closely at it several months ago.

At that time, along with much of the community, I was very skeptical about what Gutenberg was going to be, and whether it would be a meaningful improvement over doing nothing. At WordCamp US, it became very clear that Gutenberg is a Real Thing that is a tangible improvement to WordPress—and, more importantly, is really going to happen.

This article takes a look at what Gutenberg is, what it aims to be, and its vast implications for WordPress as a software ecosystem.

How Gutenberg is Right Now

As of early December 2017, Gutenberg is okay.

As of early December 2017, Gutenberg is okay. It’s probably better overall than the current TinyMCE editor, but it’s also got numerous rough edges and missing features that will need to be smoothed out before launch—which, according to Matt, is currently targeted for April 2018.

No Columns, Yet

Gutenberg may eventually be many things, but right now it competes most directly with WordPress’s plugin- and theme-based layout builders. To me, the simplest definition of “layout builder” is: Columns. The default layout for any document—the one you don’t need a builder for—is “everything stacks vertically.” A layout builder earns its name by providing columns, which allow you to build layouts other than the default.

Gutenberg doesn’t have columns yet, but it will soon. As of early December 2017, it debuted a “Text Columns” block, partly to verify that columns in general will work. Soon—once nested columns are implemented—true Gutenberg layouts will be a possibility.

All Gutenberg gifs in this post are from the Gutenberg handbook.

Because I’m so interested in this topic, I had a chance to talk to Matías Ventura, who demoed Gutenberg at the State of the Word. He explained how Gutenberg column layouts will work: they’ll use the CSS Grid layout paradigm to avoid the nested markup that other CSS grid systems (like the Bootstrap Grid) require. Really cool.

Awkward Editing

The actual authoring—text editing—experience is awkward at present. Here are just a few ways I’ve experienced that in using Gutenberg to write this article:

  • Creating header elements–<h2>s, <h3>s, and so on—takes forever. It’s a select within a dropdown, all mouse-based. I found myself dreading it.
  • Relatedly, you can highlight a “header” text block, paste it elsewhere, and the text pastes in as regular text, not header text. So creating a new <h2> or <h3> never gets easier: it’s always the same three or four clicks.
  • Also relatedly: “Duplicate Block” should be a thing. Let’s say I’ve got an <h2> block called “What I Love About Home Alone 2” and I also want a second <h2> block called “What I Dislike About Home Alone 2“: if I could duplicate the first block and change “Love” to “Dislike,” creating the second block would take about a second. At present, it takes maybe five times that long.
  • Okay, last one on headings: <h2>s and <h3>s are so similarly sized that they’re hard to tell apart at a glance.
  • I wrote this article over two days. On day two, I hit “Update,” and then checked the output on the front end. It hadn’t changed. I tried this several more times, then noticed a barely perceptible pink “Updating failed” bar. What to do next would not have been apparent to an average user: if I weren’t trained in WordPress tricks to recover text off a page that won’t save, I could easily have lost several thousand words of content. This is probably some sort of nonce issue, and is a very important one in terms of user rage.
  • As you write, if you move your mouse, Gutenberg’s options come up. These options for the current paragraph often partially obscure the content of the previous paragraph.
  • Italicized and bolded passages of text stay awkwardly and distractingly highlighted in blue for some reason.
  • A certain kind of Ctrl+Z undo can destroy an ordered list, rendering its list items into paragraphs.
  • You can’t reorder text blocks by clicking and dragging them where you want. The mouse-based solution for this is a very primitive clickable “Up Arrow/Down Arrow” position switcher.
  • Things seem to take more clicks than they used to. Where “Update” used to be an inviting single-click save, it’s now an annoying two-step flow. Clicking “Update” drops down a menu that asks you “All ready to go?” Which is like a taxi driver dropping you off at a nightclub and then asking, through the window, “Headed out for the night?” The menu then presents options for changing post visibility, changing post publish date, or reverting to a draft. I’ve done each of those things maybe ten times in five years of making my living in WordPress, so not the most useful menu there. In the bottom right corner (and last in tabindex), the menu also has a second button titled “Update”—I guess as in “actually do it this time.”
  • Lots of other little improvements over TinyMCE seem possible but aren’t implemented. I wish Gutenberg had Microsoft Word’s Ctrl+'+i for í, for example. Writing “Matías” in Gutenberg is just as unreasonably bad—search Google for í! or boot up Word! then copy-paste a single letter!—as it used to be in TinyMCE.
  • A huge pet peeve dating back to the old Front-End Editor feature project: Gutenberg outputs all kinds of &nbsp; characters into its markup. These are gross and they break things.

That’s a big list, but based on the progress they’ve made in the past three months, I’m confident the Gutenberg team can address it and all the other cleanup issues they’re facing ahead of launch.

Blocks are Cool

“Blocks” act like live-updating widgets that you can drag freely around your content area.

One of the coolest things about both tech demos was that the “Blocks” concept on which Gutenberg is based came to feel less like a generic noun from Matt’s imagination (hi Widgets!), and more like something actual and cool.

In terms of the user experience, “Blocks” act a lot like live-updating widgets that you can drag freely around your content area. (The eventual plan seems to be to extend Blocks to sidebars, headers, footers, and everywhere else, but one thing at a time.) They have special features, one being that you can save them into Block Templates: Block combinations, such as “image, text, image, blockquote” that you can reproduce endlessly across your site.

Blocks are not new to anyone who’s used a page builder; they’re often called “Modules” in that context. But having them in WordPress core—and seeing that this is now the best way to add everything from a blockquote to a video embed—feels really good. I’m also really excited about the plan to combine widgets, shortcodes, and custom HTML (known, in Gutenberg’s documentation, by the gratuitous phrase “Mystery Meat”) into the unified, live-updating interface that Blocks provide.

Even more than that, I’m excited that Blocks can be the design element that finally unifies and defragments WordPress theme and plugin development. More on that in the next section.

80% Done, Just 75% Left to Go

One thing that feels important to acknowledge, as an element of context, is the set of absolutely enormous challenges that the Gutenberg project has successfully navigated to get to this point. Those include a pretty-much-universally-disliked beta release (the plugin still has a cool 2.5 stars in the repo), sharp and ongoing controversy over everything from the proper placement of meta boxes to the essential nature of WodPress itself, a game of software licensing chicken that bent the wills of the—of the Facebook legal team? Is this real life?

Matt said he believed, and hoped, that the hardest parts of the Gutenberg project were behind him. Looking at the challenges the project has already faced and overcome on the way to becoming the almost-good editor it is today, that’s getting harder to doubt. That sense of “this is happening” is as important as any individual feature that Gutenberg has today.

Gutenberg’s Effect on Plugins and Themes: Change is Coming

WordPress is asking two major things of theme and plugin developers, and they are both very big asks:

  1. Do free work to get compatible with Gutenberg.
  2. Be replaced by Gutenberg.

So there’s going to be a lot of disruption in the plugin and theme space. Nevertheless, I think this is a development that the WordPress community has badly needed. I’ll explain why.

Gutenberg and Existing Plugins

Thousands of plugins will have to change to align with Gutenberg, with big benefits for the ones that do.

Plugins from WooCommerce to Yoast—to say nothing of the thousands of smaller plugins that register widgets or shortcodes or metaboxes—will have to change in not-yet-fully-specified ways to bring their UIs into alignment with Gutenberg Blocks. The benefits of having done this will be awesome: for example, WooCommerce has mocked up how a “Recent Products” Block might look under Gutenberg, and it’s a vastly better user experience than the ugly shortcode we have at present.

So there’s a lot to be excited about here. But the transition will be messy and time-consuming, especially for smaller developers and free plugins.

Obviously, there are legacy systems for plugins that register widgets or shortcodes. For example, there’s already a Shortcode Block that let’s you paste shortcodes in just as you would in the current editor, and I’ve confirmed that it renders a Contact Form 7 form just fine on the front end.

There’s also been a very long and contentious debate about how and where Gutenberg will place metaboxes: the options panels that plugins often register. (The Yoast panel, or WooCommerce’s product settings panel, which currently live below the TinyMCE editor, are both examples of very complex collections of metaboxes.) I don’t know how this got worked out, and I won’t pretend I do; but my understanding is that there’s Something Planned. Certainly I know that Gutenberg has promised not to break (“legacy”) metabox support.

Plugins shouldn’t break when Gutenberg ships, but if you want to keep your plugin up-to-date you will have to adopt its conventions.

So most plugins shouldn’t break the moment Gutenberg ships. The issue is more that shortcodes won’t preview properly while other things will, that fewer and fewer people will be used to embedding content in the old ways, that metaboxes will be stuck somewhere off to the side, that the alternatives that are Gutenberg-compatible will be more attractive and user-friendly, and so on. In other words, if you want to keep your plugin “up-to-date”—in a general sense that will vary plugin-to-plugin—then you’ll have to work through Gutenberg.

Direct Competitors: Page Builders

Gutenberg is looking very scary for existing WordPress commercial page builders.

Gutenberg is looking very scary for one class of plugins: commercial page builders. As Matt himself mentioned in the State of the Word, the 20+ commercial page builders in WordPress exist because there’s a massive need that the core software isn’t meeting. Gutenberg will go a long way (although not all the way; see below) toward meeting it, and it’s hard to imagine Gutenblocks ever being compatible with Beaver Builder Modules or Visual Composer Horrors or whatever they call them.

There’s a philosophical question here: if WordPress doesn’t have something important, so a lot of people build it, so WordPress takes notice and puts all those people out of business, is that a good thing? It seems a bit like a mama crocodile eating her babies—certainly that’s how I’d feel right about now if I’d worked hard on a page builder. Matt’s answer was simply that previous WordPress features haven’t put commercial plugins out of business, but I’m not so sure in this case.

That’s a good segue to where the real craziness is going to be: themes!

Gutenberg and Existing Themes

dinosaurs asteroid | gutenberg wordpress themes

The theme marketplace is about to get really crazy.

Matt compared Gutenberg to the Customizer: something to standardize the bad roll-your-own alternatives (theme options panels) that were proliferating in the absence of a strong choice from core.

But Gutenberg is different. To a large extent, a WordPress theme, as currently designed, is the bad roll-your-own alternatives to the custom layouts you build with Gutenblocks. Gutenberg takes themes and absolutely eats their lunch.

Why would you want a theme’s “Hero Image” widget, if you can have a “Cover Image” Block that embeds anywhere and live-previews?

Why would you want a theme’s “Call-to-Action Button” shortcode, if you can have a “Button” Block that embeds anywhere and live-previews?

Why would you want a theme’s “Our Team” page template, if you can have (or create) a “Team” Block Template that embeds anywhere and live-previews?

There is a massive amount of theme code that is written in ways that Gutenberg makes obsolete.

The point is that there is a massive amount of theme code that is written in ways that Gutenberg makes obsolete. Fixing all your randomly architected theme features to be in line with Gutenberg (that is, to register them as Gutenblocks) means a massive rewrite on every theme you sell.

What About Page Builder Themes?

Over the past few years, many theme developers have realized that hard-coding layouts and layout elements isn’t the best way to do theme design. Instead, the user should be able to take elements that are specific to the theme (like a custom-designed “Team Member” module) and put it wherever she wants on the page.

These theme developers have bundled their themes with commercial page builders—specifically, with the market-leading builder and Shortcode Death Star known as Visual Composer. Rather than register custom layouts (through, for example, widgetized homepages), these developers registered custom Visual Composer Modules, and made their themes essentially thin wrappers for Visual Composer itself.

If anything, these theme developers are worse off than the ones that don’t embed a page builder. They’ve made the right choice in creating all their layout elements in the language of a drag-and-drop page builder—but it’s a page builder with which the page builder in WordPress’s core software will soon openly compete.

These developers will have to decide whether to pull partnership with VC (which may be legally complex in ways I don’t understand) and rearchitect absolutely everything they do into Gutenblocks; or stay the course with a layout solution that, if there is a benevolent force in the universe, will start to shrivel come April.

Gutenberg, Themes, and Plugins: Why This is All a Good Thing

What the WordPress plugin and theme ecosystems need, above all else, is consolidation around a clear set of choices.

If you’re a theme or plugin developer, I sympathize with your position. I would not want to be in either market myself right now, particularly as one of the perennially vulnerable and overwhelmed small players who are often doing the highest-quality work in the space.

However, as I’ve written a couple times, what the WordPress plugin and theme ecosystems need, above all else, is consolidation around a clear set of choices—specifically, for layout creation. When I last evaluated Gutenberg’s potential to become this set of choices, I was discouraged. Now it seems almost inevitable.

Consolidation means the removal of redundancies, and the plugin and—especially—theme marketplaces are massively redundant. Let’s examine what reducing redundancy in each case looks like.

The Plugin Ecosystem Should See a Gutenblock Gold Rush

Right now, we have 50 WordPress form plugins. (At least; I stopped counting.) None of them look good on your theme. Why is that?

It’s because none of them know anything about the environment they’re being dropped into. They don’t know how wide your content area is, or if they’re full-width or in a column layout—or even if they’re in your content area or a sidebar. They also have no idea what style decisions the theme has made. They can sometimes use clever tricks to inherit some of the theme’s CSS; but they act, fundamentally, without any knowledge of what the theme’s overarching layout, color, and typography choices may be.

As a result, form plugins look a little drab in WordPress—or perhaps safe, like the way you’d introduce yourself to someone whom you may or may not have met, who may or may not speak your language, who may or may not be a child.

Gutenberg is the solution to this issue. It makes strong, specific choices about several very important design elements, such as:

  1. How the theme identifies its primary color scheme.
  2. What column layouts look like.
  3. How a particular Block embed can know what it’s next to and surrounded by.

As these standardized choices propagate across WordPress, there should be a rush to create plugins—form plugins, gallery plugins, author bio plugins, social follow plugins, and so on—that make use of them.

For example, a Gutenblocked social follow plugin would have icons that used the theme’s “accent colors” by default, could smoothly accommodate being placed next to other layout elements, and would live-update as the user added and removed social media links.

The eventual result should also be that the current players who move most quickly and effectively to Gutenblock their elements will become strong first choices that themes build around. A theme might list its Block compatibilities—the Gravity Forms Block, the Easy Social Share Block, the Modern Tribe Events Calendar Block, and so on—which it knows exactly how to style elegantly by default.

Once there’s a single shared language that almost all themes and plugins use to describe their layout and design choices, much stronger integrations become possible and likely.

These theme-plugin integrations are less common now because all form plugins, all event calendar plugins, and so on embed more or less equally well (that is, equally badly) into any WordPress site they’re dropped onto. But once there’s a single shared language that almost all themes and plugins use to describe their layout and design choices, much stronger integrations become possible and likely.

Conversely, the more obscure players, especially the ones that (because of neglect, resource constraints, or whatever) don’t make the transition to Gutenberg, are likely to be strained out over time.

So where we have 50+ about-equally-okay-looking form plugins right now, in three years we may have ten—and one or two “winners” whose Blocks most themes customize themselves to. While the consolidation will be painful in a lot of individual cases, the end result should be much more like a unified software community where things can actually talk to each other, and that’s something very much to look forward to.

Themes Need to Change

There’s no way we need 50 form plugins, but there’s really no way we need 11,000 ThemeForest themes, a huge bulk of which are virtually identical, arbitrarily and badly coded, and overstuffed in the “It Does Everything!! No Coding Required, Time for Your Website to Take Off Into the Sky” manner that the free market has tended to encourage.

In fact, I can state my position a bit more strongly:

Themes Need to Not Really Be a Thing

Once the WordPress community is unified around a layout builder that works in Blocks, themes should do three things:

  1. Make attractive default choices outside the content area: header, footer, navigation.
  2. Offer a basic default visual language: widths, colors, typography.
  3. Offer custom “skins” for Blocks—both Gutenberg’s core blocks and plugin-based Block extensions—that integrate with the theme’s overall visual language.

This is what Squarespace templates do, and the user experience is immensely better for it. A Squarespace template is basically some default colors and fonts, a menu layout, a max-width on the content area—and a default way that Squarespace’s standard blocks, like its contact form, appear when dragged onto the front-end.

That means that everything else that WordPress themes do is overkill. “Home 1” through “Home 8” custom page templates: overkill. A three-column “Our Services” layout registered as a set of Customizer options: overkill, just register a Gutenberg Block Template and let the user decide the number of columns. A custom “Album Player” widget: overkill, there should be a Gutenberg-compatible plugin that registers a Block for that, which the theme then skins. A custom “Pullquote” shortcode: overkill, just skin the Gutenberg one.

When layouts are completely custom, all the heavy lifting is in plugins, and themes themselves are customizable, do we really need that many themes?

In the world that I believe—and hope—is coming, themes will need to sell themselves on design: great initial design choices, great-looking Block integrations, and not a lot of new functionality that isn’t available in Gutenberg or its plugin-based extensions.

And the theme marketplace shouldn’t be that big. Squarespace has maybe 100 templates and gets by fine. In my opinion, 1,000 very good WordPress themes would be plenty. Layouts are completely custom, all the heavy lifting is in plugins, and themes themselves are infinitely customizable in terms of colors and typography. Do we really need more than 1,000 default ways for that to look?

Once Gutenberg is fully adopted, themes shouldn’t do that much. They should no longer be the central purchase you make in setting up a WordPress site.

Whatever the number, the main point is that themes shouldn’t do that much. They should no longer be the central purchase you make in setting up a WordPress site, and the vast proliferation of “All-In-One/Builder/Parallax/etc.” themes on ThemeForest should transition, over the next few years, from “shaky, low-quality, and oversaturated” to “full-retreat.”

Whew

Summing up: in the WordPress theme and plugin ecosystems, Gutenberg seems poised to be a bit of a cleansing fire. I don’t like to predict the future in tech matters, so don’t get mad if everything I just wrote turns out to be totally wrong. The big takeaway is that a massive consolidation—but also improvement—of the plugin and (especially) theme marketplaces is something that I believe Gutenberg’s arrival in core will provoke. More to the point, I hope it does.

My Kingdom for a Front-End Editor

The worst thing about Gutenberg is that it’s a back-end editor, not a front-end editor.

The worst thing about Gutenberg is that it’s a back-end editor, and not a front-end editor. In other words, you use Gutenberg in the back end of your site—the WordPress admin—as opposed to on the front end, the website that your visitors see. With Gutenberg, you only see what your content will actually look like once you Update (on the back end) and refresh (in a second tab, on the front end). Thus it has always been with back-end editors.

(Guys, Gutenberg Isn’t a Front-End Editor)

That Gutenberg is a back-end editor is also, bizarrely, the subject of some controversy. In the State of the Word, Matt called the experience of editing in Gutenberg with some theme styles applied “true front-end editing,” which thoroughly breaks the definition not only of “front-end” but also, perversely, of “true.” I had a chance to push back on that terminology in the Q&A, and he clarified that Gutenberg is what it in fact is: a back-end editor that tries, as much as possible, to give people a sense what the front end will look like.

This isn’t some sort of minor technicality. Writing this article, I felt—as usual in WordPress—frustrated and confined to be writing in a dim, gray WordPad-like editor, not writing a webpage.

“Writing a webpage” is what Squarespace and Beaver Builder give you with their front-end editors, or what the old Front-End Editor (note the name!) feature plugin was aiming for. It means that my editing flow is as follows: I add content onto my webpage, I hit “Save,” and my changes stick where I put them for me and my visitors to view.

That, literally, is what-you-see-is-what-you-get: WYSIWYG. Everything else that uses that term—including Gutenberg—is lying, precisely like the people selling those “barefoot shoes.”

barefoot shoes | wordpress wysiwyg

Nope.

My understanding is that the next step, after Gutenberg launches into Core, is to put it into the Customizer. That will be front-end-like: you’ll make changes in one view on the front end, and save them, and see the final product on the same front-end page.

But it won’t be actual front-end editing like Squarespace, Beaver Builder, and even Visual Composer have been doing for years now. And as I’ve written before, it’s pretty obvious that front-end editing is what the market wants: any large paid solution (inside or outside WordPress) either starts out with it or adds it ASAP.

Why Gutenberg Won’t Do Front-End Editing: It’s Too Hard

Gutenberg won’t ship a front-end editor, because writing one into core is too hard.

So why is Gutenberg not going in the direction of a front-end editor? I haven’t confirmed this with anyone else, but I’m fairly sure the answer is simply: It’s too hard!

Obviously, writing a front-end content editor is not that hard; dozens of commercial solutions have done it. But there’s a difference.

If you buy a commercial front-end builder, and it doesn’t work on your site, you can just ask for a refund, move on to the next builder, and everything is fine.

WordPress core is different: there’s no “refund” when WordPress’s default editing experience is broken on your site. That instead becomes a black eye for the software itself, and a support ticket for someone (who is not being paid for her time) to try to help you with.

In other words, a front-end builder for WordPress core wouldn’t just have to work, it would have to work everywhere. That means rich, drag-and-drop JavaScript interactions on the front end of any WordPress site,

  1. On any random, potentially awful hosting;
  2. With the settings, markup, and styling of any random, potentially awful theme;
  3. With any combination of random, potentially awful plugins changing and adding to the front end however they want.

I love Beaver Builder, but it doesn’t work everywhere. I’ve had projects where it wouldn’t cooperate with the theme and plugins around it. That was fine: I just tried something else. If the software was in WordPress core—with the implicit promise that it would just work on my WordPress site—then those same issues would have been a fiery Trac ticket, or even a sharply critical tell-all editorial here on WPShout.

Gutenberg has to be a back-end editor, to keep the controlled environment of the editor separate from the chaos that users may see on the front end.

So a front-end editor in core is simply too hard: too much can go wrong. Gutenberg has to be a back-end editor so that it can preserve a separation between the controlled environment of the editor, and the potentially (depending on the theme and plugins) wild-and-wacky markup that users actually see on the front end.

As a sidenote, this also explains the non-adoption of the Front-End Editor plugin, which (if it worked) could have been Gutenberg but better several years ago. What happened was that the brick wall of complexity that I’ve described here became obvious, and the promise of front-end editing in core simply became a known dead end.

Sounds Like a Job for the Free Market

The race is on for a commercial plugin that puts Gutenberg on the front end.

In my opinion, the race is on for a commercial plugin that puts Gutenberg on the front end. By that I mean: an actually WYSIWYG page builder (see above for what that means) that lets the user manipulate content directly in the content area of the page, and which—rather than registering its own JavaScript and CSS frameworks—uses Gutenberg’s Blocks system.

I have no idea how this would need to work technically, but I know it’s possible. The people marketing this plugin wouldn’t be solving a technical challenge no one else could solve; rather they’d be liberating a Gutenberg-based front-end editing experience in two ways:

  1. It doesn’t have to work everywhere.
  2. Paid support.

Essentially, this plugin would just be an extension of the existing technical work on Gutenberg that leverages the lower expectations—and the for-profit nature—of commercial plugins relative to WordPress core software. It’s a slam dunk!

So if you’re a WordPress up-and-comer, figure out how to get Gutenberg on the front end. The world is yours for the taking.

I Guess they Called it Gutenberg for a Reason

From what I saw this weekend, the name “Gutenberg,” and Matt’s perhaps slightly self-satisfied defense of that name, now feel justified. The default publishing experience in WordPress is about to be not merely different, but much better. There’s also good reason to believe—and certainly to hope—that Gutenberg will also truly unify the WordPress technical landscape, so that things can actually begin to talk to each other rather than endlessly reinventing the wheel.

What do you believe Gutenberg’s effect will be on WordPress? Please, print up your thoughts below, and publish them for all the world to see. We have the technology.


25 Responses

Comments

  • It is a bit of stretch calling Gutenberg good lol.

  • Vinny O'Hare says:

    I have 38 websites all on WordPress and all in Genesis themes. Each one is fully developed with no issues. Why in the world would I have to switch/learn to blocks. I would switch to hand coding html again and not use wordpress at all

    I won’t be updating wordpress anytime soon when this comes out and I feel like I won’t be the only one.

  • Guy says:

    The entire future of whether or not Gutenberg is a success rests on Meta Boxes. The one thing that there is no clear direction on. No leadership from the Ivory Tower. WP self hosted is useless without meta boxes. No matter what anyone says, or how positive the talking is, unless this aspect is solved properly before this Gutenberg is forced upon the world of WordPress, it is doomed.

  • Kristin says:

    Fred, thank you for a great article and especially for kindly pushing back on the idea of Gutenburg as front-end editing during the Q & A.

    And I agree – we still need real front-end editing and I’m hopeful we’ll get it via a paid plugin. You make a good point that the premium world is the better place for that. Thanks for giving me hope on that one.

  • Hashim Warren says:

    I’ve been using Squarespace for two years. It powers my job’s website.

    “Blocks” are a good metaphor and something that should be copied.

    But that’s about it. Squarespace themes are very hard to customize. And built-in features like the form and calendar are super frustrating because of the lack of choice.

    You know what is a good experience? A client filling out three custom fields in a custom post type for “staff”, and suddenly the staff page and all archives are updated.

    WordPress should be making that process easier. Instead we’re chasing Squarespace and Wix, two buggy projects that most likely have yet to turn a profit.

  • Hi Fred,

    Can you put some links where we can learn more about Gutenberg and it’s development. If you can provide us with some of the best references on Gutenberg, it will be very helpful to me.

  • Thank you so much for sharing, Fred—I really appreciate the details about the new WP direction and Gutenberg!

  • Good one.

    BTW Customizer will be the front end editor of Gutenberg. ?

  • Nick says:

    I still can’t believe after so many months of reviews, opinions, hype by some, and total disgust at Gutenberg from others, nobody looks at the big picture. And the big picture is this, something a CEO of a company analyzes, if this was the case, but with Automattic, it is clearly a selfish decision to mainly benefit them and very few in the WordPress community, especially the developer’s community that for years made WordPress the number 1 CMS.

    Is Gutenberg, which does not even have front end editing like Divi, Visual Composer etc… worth breaking thousands of plugins and themes, forcing thousands of developers to throw away their code that took millions of hours to put together, and start all over again for this? Is angering and putting off the developers and in some cases putting them out of business, the best idea to move WordPress forward? Is Automattic ready to be the Microsoft of the CMS – from one of the most loved to the one of most hated by professionals? Because Matt is bent over backwards to put many people out of work, is he really ready to walk around with bodyguards and wearing bullet proof vests, because Gutenberg DOES NOT solve anything that the marketplace has not solved! Gutenberg is not solving anything new, they are reinventing the wheel, in the process making simple processes more time consuming by opening and closing a million boxes to do simple tasks.

    Really, what is Gutenberg solving that justifies all the misery that will bring along with it?

    • Esteban Rocha says:

      Well that’s one side of the coin, I myself and many developers I know we think for sure that if Gutenberg it’s gonna take out disgusting things like Visual Composer and these so called page builders which only add mass of spaghetti code and issues, I can’t wait to have it released.

      That is the problem that it and hopefully will solve, to eradicate extremely bad implementations like Visual Composer, seriously have you seen what that does to the code of a WP site? it’s almost a crime.

  • Mitchell says:

    Hello Fred:
    Thank you for detailed look at Gutenberg and its potential effect on WP themes / plugins.

    Essentially, as you said, “it’s too hard.”

    Gutenberg is also useless for touch typists.

    I cannot imagine going to an office and training 75 wpm typists to use it.

    Best wishes,
    Mitchell

  • Patrick Boehner says:

    So much grumbling and conspiratorial thinking. The panacea that was is about to be destroyed… Are those with the most complaints involving themselves in testing Gutenberg out, reporting problems, suggesting ideas and improvements?

    Any who, thanks for the write up. i agree for a large part. I am honestly less concerned with front end editing. I am not my clients so my perspective is limited. I just don’t seeing it solving any major issue and will introduce issues with context switching.

    From my perspective I am most interested and excited in the guided page layout opportunities and greater flexibility in moving some content out of custom metaboxes and into blocks where they make sense. I will be interested in seeing how complex these boxes can be and how much control i will have over limiting options and controlling placement. As they say, decisions not options.

    I’ve also appreciated the recent documentation both by the team and other authors on how to get started building blocks. JS is not my comfort zone, but after looking through the information it looks more manageable.

  • AnyDog says:

    AutoMATTic realized that because of their “opensourceness” much of the cake has gone to other players in market, so they want their cake pieces back. So, yeah this is arm twisting and applying it’s power to force profit go their way.
    Question is – is this a good time to fork WP take it other (Gutenberg-less) direction, and who will do it ? And make it good as it once has been (well WP is still good, but …).
    Another question – is Automattic still powerful enough to force the market their way, or is it a beginning of fast WP death … ?

  • Matt says:

    Gutenberg requires a mouse like pointing device now more than ever which seems rather limiting and hardly modern. In this age where we interact and provide input in so many ways other than the mouse, this approach seems like a step backwards and a short-sighted approach. This is not progress.

    Has anyone seen any public discussion about how then intend to make Gutenberg accessible to those who only have a touchscreen (no mouse / fine pointing device)? Is it because not enough people has thought about / realized this? Perhaps the majority is just very tolerant and / or indifferent to these issues? Please point me in the direction of such talks if there are any.

    I suppose it’s possible that Gutenberg just was not designed using a mobile first approach? If it had been, touchscreen compatible design decisions and elements would likely have been used (more). As it is now, the sheer number of hovers required to reveal the UI makes the UX on a mobile tablets or even larger devices like the Microsoft Surface Studio terrible. What were they thinking if they were thinking about this at all?

    Modern UIs shouldn’t dictate what input device we use. That’s a construct of the past. TinyMCE alone supported the choice of Keyboard, Mouse, Voice, Touchscreen, etc. Gutenberg not so much. It is too mouse centric and I don’t see that changing that radically now that it has been shown off at the Word.

    • Matt says:

      Oh, I forgot to add that while I’m aware of the availability of the slash shortcut which reduces reliance on the mouse. It is not enough though. It’s an inelegant/ ugly hack that merely sidesteps works around the larger issue(s).

  • Really interesting analysis thanks, a definitely a time of major change is definitely coming up.

    I agree that it would be nice for themes to stop taking over everything and become the ‘skins’ that you get with other platforms, I don’t think it still go this far. That’s because not everyone will ever have the eye for design that is needed to arrange Gutenblocks in a way that creates a professional result. Theme authors can stay in business by finding a way to provide suggested combinations of blocks that achieve a particular layout for the homepage, portfolio page or whatever. That will bring a better end result than expecting everyone to create their own layouts from scratch, and will save people time too.

    This means that themes still have an important role in helping people to create professionally designed and laid out websites. Gutenberg adds flexibility but won’t remove the need for this.

  • LOL. There is good criticism for Gutenberg, but all the naysayers in the comments thread remind me of the old-timer developer I worked with when I first got into web development who insisted on using tables to layout content and said, “Why would I learn about DIVs when a table will do?”

  • Alessio says:

    Hi guys,
    nice post! Reading the comments I think this is the right place to share a good plugin about Gutenberg.
    I would like to present you a free plugin that allows you to manage the Gutenberg editor.
    It’s called Gutenberg Manager and allows you to enable / disable the editor in the various post types (pages and posts included). It has more features but I leave them to you.

    We have read tons of posts of people complaining about the future implementation of Gutenberg within the core in WP 5.0 and this has led us to find a simple solution.

    Gutenberg Manager solves this problem and allows for example to continue using Elementor, Visual Composer, Siteorigin Builder or Cornerstone without any problem even after WP 5.0.
    From the first user feedback on WP.org the plugin seems to be apreciated 🙂

    For this reason I would like to introduce you to Gutenberg Manager -> https://wordpress.org/plugins/manager-for-gutenberg/

    The plugin can be used by developers in their own themes and plugins thanks to some useful hooks. There is an hook to HIDE the plugin option panel so the final user will not see it in WP backend (great feature for the devs that want to include Gutenberg Manager in their projects).

    We are also making arrangements with the teams of most famous Builders to activate partnerships and collaborations. In this way we hope to make the transition to Gutenberg a little less traumatic!

    Thank you all for your attention,
    Good job.

  • Yes, manager-for-gutenberg seems a nice plugin for Gutenberg.

  • Danis says:

    Well that’s one side of the coin, I myself and many developers I know we think for sure that if Gutenberg it’s gonna take out disgusting things like Visual Composer and these so called page builders which only add mass of spaghetti code and issues, I can’t wait to have it released.

    That is the problem that it and hopefully will solve, to eradicate extremely bad implementations like Visual Composer, seriously have you seen what that does to the code of a WP site? it’s almost a crime.
    https://goo.gl/t9X1bh

  • I have built on average, 3 sites a month with WordPress for the last 8 years, all on a custom theme that I have built and added features to over the years. Today, I completed my second (and last) website using the Gutenberg editor. Tomorrow, I am going to spend time researching a WordPress alternative.