Stop the Presses: Gutenberg is What WordPress Needs, but It Doesn’t Go Nearly Far Enough

Update December 5, 2017: We have published a new look at Gutenberg, reflecting the plugin’s state several months after these impressions.

“Everyone’s a critic,” as the saying goes, and nowhere more so than around Gutenberg, the upcoming content editor overhaul slated for WordPress 5.0. Gutenberg has been the subject of soaring vision statements, angst-filled comments sections, and dozens (hundreds?) of cautiously-optimistic-to-mixed-to-confused-to-skeptical-to-concerned reviews.

It’s been a lot, and in entering the conversation I’m conscious of the need to say something new, and not just pile on the noise and (especially) the negativity. I have an approach that I think can help.

What Do WordPress Users Want? (And Is Gutenberg That Thing?)

I think something that could be extremely helpful in such a crowded space is to return the focus to where it needs to be. In my mind, that’s the users: What do WordPress’s users want?

I’m a WordPress user myself: very much so. I’m a developer too, but I’m also someone who kind of wandered into technology by way of an interest in writing and spirituality, and who’s written maybe a million words using the WordPress post editor (including 4,700 today, see below!).

WordPress users have been very clearly signaling what they want for years. So far, there’s little indication that Gutenberg will deliver it to them.

As a result, I generally feel that I don’t have to wonder or imagine how a user thinks. (On the contrary: I usually have to wonder or imagine how a developer thinks.) And so in my opinion, the question “What do WordPress’s users want?” is neither complex nor multifaceted nor ambiguous. WordPress users are very clearly signaling what they want, and have been doing so for years.

So far, there’s little indication that Gutenberg will deliver it to them, and that’s the main topic of this article.

Users, not Insiders

By users I mean not professional WordPress developers, professional WordPress implementers, Gutenberg early testers, theme and plugin developers, hosting companies, and so on. I mean people who pay to have WordPress sites created so that they can offer something into the world online.

Below are three things I believe users undeniably want in a content editing experience. As currently planned, Gutenberg won’t deliver any of them.

Below are three statements that I believe are undeniable about what users want in a content editing experience. As it’s currently planned, Gutenberg won’t deliver on any of the three.

I’ll first outline what I believe users want and why, and where Gutenberg currently sits with respect to those wants. Further on in the article, I offer analysis and suggestions for the Gutenberg project.

1. Users Want Front-End Editing

What are the “builder” experiences with which Gutenberg competes? Inside WordPress, the major builders that developers find palatable include:

  • Beaver Builder
  • Elementor

Major WordPress builders that developers don’t find palatable include:

  • Visual Composer
  • The Divi Builder
  • The X Theme’s Cornerstone Builder
  • Avada’s Fusion Builder

Major solutions outside WordPress include:

  • Squarespace
  • Wix

Unlike all market-leading page builders, Gutenberg includes no plan for a front-end editor.

The above solutions are very different in most ways—theme add-on, standalone plugin, hosted solution; well-built, sort-of-well-built, badly built; free, freemium, paid. What’s one thing they have in common? They’re all front-end builders—except the Fusion builder, which is working feverishly on becoming one.

I’ve confirmed directly with the Core Editor team that, unlike all these market leaders, Gutenberg includes no plan for a front-end editor.

“100% FRONTEND”: How Commercial Builders Sell Themselves

I’ve written about the appeal of front-end builders a few times before. Good front-end editing completely transforms my writing experience: I’m not filling out a text window, I’m creating a webpage in real-time.

But that’s just one person’s anecdotal experience. It might be helpful to hear how the market-leading content editor solutions in WordPress describe front-end editing to their millions of buyers:

No programming knowledge required – create stunning and beautiful pages with award winning drag and drop WordPress front end editor. Experience the true “What You See Is What You Get” and forget about “blind designing”. –Visual Composer promo copy

100% FRONTEND. Gone are the days of having to work on the backend of your site builder only to have to guess how it looks on the frontend. With Cornerstone, all edits you make are happening while you view your exact site as it looks on the frontend! –Cornerstone promo copy

Divi 3.0 introduces a completely new visual interface that will forever change the way you build websites. This front end editor allows you to make changes to your website…on your actual website! […] No page refreshes, little to no ajax loading bars and absolutely no need to “preview” your changes because everything is happening in real time on your page. –Divi promo copy

I mentioned the Fusion builder isn’t on the front end, and that they’re frantically working on it. Here’s how they describe that:

The possibilities are endless and the most exciting part is yet to come … both design and code is already being created to produce the best front end editing experience the market has ever seen in a page builder. –Fusion promo copy

I’m writing this part of the article in the WordPress default editor, and I’m having to “preview” the draft constantly, to make sure the blockquotes above look decent. I’m minimizing the time it takes to do this by keeping the post open in two tabs, and I’m so used to the inconvenience that I barely notice it… until something like Squarespace or the old front-end editor project comes along and completely redefines my authoring experience. Gutenberg has no plan to join in that redefining process, or even to catch up with the other solutions that have already made the leap. Not exactly revolutionary.

2. Users Don’t Distinguish Between “Blog” and “CMS”: They Want Both

One idea I’ve seen mentioned (most directly by the excellent Morten Rand-Hendriksen) is that WordPress needs to choose between being a blogging platform and what I might call “a full CMS,” or what Morten calls a “platform for managing views”: software that lets you lay out your pages as you want. Morten thinks Gutenberg represents a final choice of one type of software over the other, especially as he believes Gutenberg is likely to make the “type-and-publish” experience in WordPress so complex that actual bloggers will migrate away from the platform entirely.

With respect, I don’t know how clear that distinction is to users—or even to me. For variety, I’m writing this piece of the article in the “blog” section of a Squarespace site, using Squarespace’s excellent and intuitive front-end editor. And after this paragraph, I’d like to place two images side-by-side, because that’s what I want for this blog post.

WordPress vs. Squarespace

Click to enlarge

“Two images side-by-side” is exactly what I’ve wanted numerous times in the past while I was writing WordPress posts. Thank goodness I know CSS, because the non-page-builder options for doing that in WordPress are difficult and fragile: the Galleries API, “column shortcodes,” and so on. And thank goodness I know the CSS (and HTML, and how to use the Text editor) required to create blockquotes that don’t take up the whole width of the content area, like WPShout’s pullquotes generally don’t.

I sure wish I could create layouts in my post content. (In the meantime, thank goodness I know the CSS to create pullquotes like this one.)

In other words, I sure wish I could create layouts in my post content. In Squarespace, your page builder is your post editor, and life is wonderful: if your blog post is text-only (or uses only basic image layouts), you simply don’t use the advanced layout features that the page builder comes with.

“Which Do I Want: Layouts, or Post Authoring?” (Said No User Ever)

Stepping outside of blog content specifically: when people start a self-hosted website, they want things to be easy. What they don’t ask is the following question:

“Let’s see… for my new website, do I want to be able to control layouts, or to create post content?”

They want both. I’m a professional developer and I want both. Our agency site, Press Up, is a bunch of pages—with layouts we painstakingly built ourselves (because this was before respectable page builders)—plus a blog. Even on a “pure” blog like WPShout, we’re seeing a need to build complex layouts for a set of landing pages we’ll be creating in the next few months.

“Blog or CMS” may be an identity crisis for developers, but users just think they’re getting “a website”—and they want it to be easy.

WordPress is a solution for self-hosted websites. “Blog or CMS” may be an identity crisis for developers, but users just think they’re getting “a website”—and they want it to be easy. If that means building a fancy-looking homepage, make it easy. If that means publishing simple blog posts, make it easy. If that means publishing blog posts with complex layouts, make it easy. Squarespace and other tools are proof that users don’t have to choose between these possibilities, and users’ own purchasing behavior within WordPress is proof that they don’t intend to—and, in fact, that they don’t even conceptualize “easy post creation or easy layout creation” as a choice. They want both.

3. Users Want Layouts, Meaning Columns

There’s been a great deal of excitement about Gutenberg’s use of “blocks”:

Users will finally be able to build the sites they see in their imaginations. […] They’ll start manipulating their sites in ways that would have taken a developer. They’ll be able to move from blogging to using WordPress as a CMS without missing a beat. Editing posts will just work; they’ll write more. They’ll learn blocks once, and then be able to instantly use and understand 90%+ of plugins. –Matt Mullenweg, “We Called it Gutenberg for a Reason”

Here’s the thing about Gutenberg’s blocks, though: you can’t place them next to one another. They vertically stack. In Gutenberg at present, only “text blocks” have even a basic sense of horizontal layout.

Gutenberg is supposed to help users “build the sites they see in their imaginations,” but the imagination of every user I’ve ever met included things that were next to one another. That’s where columns come in. As Brian Jackson says beautifully in an August review, Gutenberg:

Doesn’t support responsive columns yet. We really hope this is coming. A lot of times this is a reason people install visual builder plugins or shortcode plugins, is to get the column feature alone. It is definitely time for columns to be in core!Kinsta Gutenberg review

Ignoring columns is ignoring perhaps the primary raison d’être for page builders themselves: layouts, things in a spatial relationship to one another other than the default “on top of.”

The Make Editor team tells me that Gutenberg will not ship with columns in 5.0, but that that’s the first planned release afterward. I hope so, but columns should not be an afterthought to a page builder—they’re something like 50% of the point of a page builder, and it’s not clear to me conceptually how you build them in later.

If WordPress simply added a Bootstrap-style 12-column responsive grid into its core CSS, Gutenberg would start to get much more exciting. It could even be an almost-universally-adopted suggestion, like its alignleft/alignright/alignnone/etc. CSS classes: you don’t have to use the grid in your theme, but post content will behave weirdly without it, just like the media modal will if your theme doesn’t include the alignright CSS for some reason.

Squarespace’s front-end content blocks snap delightfully to a foolproof 12-column responsive grid. Elementor’s content blocks make the regrettable decision to allow dynamic resizing, giving users the freedom to create widths like “53.7%.” At least both solutions handle layouts. Gutenberg doesn’t, and it’s not clear what that will look like when it does.

Imagining Gutenberg’s Future

To sum up the three points above:

  • Gutenberg is what WordPress needs. The content editing experience absolutely does need an overhaul, and now’s the time to do it. On the other hand, as currently planned…
  • Gutenberg doesn’t go nearly far enough. It won’t make WordPress’s core content editor competitive with hosted builder solutions, or even with WordPress’s own themes and plugins (including badly built, bad-for-the-community solutions like Visual Composer).

In the rest of this article, we’ll discuss the overall environment, opportunities, and constraints facing the Gutenberg project, and try to make some predictions and recommendations.

What Gutenberg Should Be

Let’s say concisely what Gutenberg should be: what the Gutenberg project should push toward.

People like acroynms, so I’ll be referring to what I believe Gutenberg should be as Gutenberg-but-it’s-an-actual-front-end-page-builder, or GBIAAFEPB. 

gbiaafepb

GBIAAFEPB means a feature-rich, developer-friendly front-end page builder and content editor, at the level of Elementor or Beaver Builder, built into WordPress core. At a minimum, that would include two elements not currently planned for Gutenberg in WordPress 5.0:

  • Front-end, drag-and-drop post and page editing by default (with back-end editing, either drag-and-drop or TinyMCE-style, also available).
  • Layouts built along a smart twelve-column grid system standard in core, or else strongly suggested like alignright.

Numerous small teams have implemented these technologies in WordPress, but the team developing Gutenberg for core faces special constraints and challenges, as we’ll discuss. For now, let’s look at what might be the result if a full-featured Gutenberg hits WordPress core.

What Happens if Gutenberg Succeeds?

By “succeeds,” I mean “becomes what it should be,” by my own definition above. In other words, GBIAAFEPB.

gbiaafepb

If GBIAAFEPB lands in core, I can see a lot of things happening all at once.

Standardization of WordPress Website Creation

If Gutenberg succeeds, WordPress website development could start to coalesce, rather than continuing to fragment.

First, the theme marketplace should contract radically, as there will no longer be a need to manually build dozens of page layout options per theme, or to create and bundle proprietary builders. This contraction will hurt some theme vendors, but it should also cut down dramatically on the hyper-redundancy of the current theme ecosystem, dramatically reduce theme creep, and provide a much less siloed development experience.

Second, if WordPress’s core solution manages to outcompete the largest premium builders like Visual Composer, the result would be a much more effectively standardized set of WordPress development practices, growing in proportion to the market share those badly architected solutions lose. The experience of developing in a “Divi site” or a “Visual Composer site” is like trying to repair a spaceship while attempting to ignore a large, hostile alien that is siphoning half the power from the main engine—an alien that was invited in by the crew because it knows how to cook. If the spaceship’s chefs get their act together, we don’t need to invite in the alien, and that means a ship that can actually fly places and do things, in the way that spaceships are supposed to.

To sum up these two points: if Gutenberg succeeds, WordPress website development could start to coalesce, rather than continuing to fragment into hundreds of (predominately low-quality) proprietary framework/builder/deployment solutions—an ongoing trend that I think a WP Tavern commenter named well as “third-party user experience fragmentation.”

Continued Relevance of WordPress for Small Site Projects

In my view, if WordPress got content creation right, it would have very few key weaknesses as a website development tool for small-to-medium-sized clients.

With GBIAAFEPB in core, WordPress would be a much more attractive competitor to something like Squarespace or Wix. It will always be more expensive than those solutions (factoring in hosting and, especially, developer costs), but it’s also vastly more powerful and flexible because of the theme and plugin ecosystems.

The major argument in favor of hosted builders is ease of use: in registration (since you pay a single entity a well-established price), but also very much in page and post creation. In my view, if WordPress got content creation right, it would have very few key weaknesses as a website development tool for small-to-medium-sized clients.

Claiming back market share from Divi, X, Avada, Visual Composer, and so on should also direct more WordPress users to sensibly-built themes and competent developers, increasing the proportion of small clients who have a good experience with the software.

More Consistent Themeing and Much Deeper Plugin Layout Integrations

An unfortunate, but rarely mentioned, attribute of WordPress is that you have absolutely no idea what the markup is going to look like site-to-site. The resulting ambiguity is so deep that I barely notice it anymore, but it does mean that plugin developers can’t assume anything about how the site they drop into is going to look. Plugins with a front-end component often look out-of-place by default, and this is why.

WordPress-plus-GBIAAFEPB would have, at the very least, a sensible twelve-column grid, and an API to hook layout elements onto. That means that “one-third-width right-aligned pullquote” could be a defined thing across WordPress sites—a block like any other—without needing to drag in its own breakpoint-insensitive-and-possibly-other-problem-having set of CSS styles. That’s not a very glamorous example, but that’s partly because an ecosystem where plugin developers know something about the possible layout(s) of the environment they’re developing for is such an alien idea in WordPress that its usefulness is hard to imagine.

If Gutenberg were to offer a sufficiently powerful set of layout tools, theme and plugin developers could build on that base.

Relatedly, one hopes that themes would start to be built on the notion of a responsive grid, if that’s how content worked by default. That would be a very welcome bit of standardization that wouldn’t need to introduce back-compat concerns for themes already on the market.

Again, the theme is “defragmentation”: if Gutenberg were to offer a sufficiently powerful set of layout tools, other people could build on that base. The Customizer (another much-argued-about addition to Core) tamed, to an extent, the wild proliferation of hideous roll-your-own theme options panels. GBIAAFEPB would do something similar, but on a much larger scale: it would help standardize the work of anyone who builds front-end-visible elements in WordPress.

Will Gutenberg Succeed?

At present, I don’t predict that Gutenberg will be able to compete with existing WordPress builders or with other platforms.

After taking in not only the current reality of Gutenberg, but what its designers appear to envision, I feel pessimistic that it will yield the kinds of content-editing improvements necessary to make it competitive with existing WordPress builders or with other software platforms.

I see two main sources of drag on the project:

Insiders-Only WordPress Identity Debates Diverting Focus from User Needs

If WordPress exists to “democratize publishing,” it should be helping users publish what they want to publish: websites, with custom layouts as needed.

Is WordPress a blogging platform? A CMS? An app platform? Do we create posts, or views? Are we PHP- or JavaScript-based? Do we target small businesses? Do we need to target small businesses? Does market share really matter, and what market share should we be aiming for? Do we need to be all things to all people? What’s our endgame? Is WordPress so big and so diverse that the next logical step is to fork into subcommunities? Is this whole project on its way to becoming a front for Automattic, WordPress’s moneymaking cousin? Loud and dramatic philosophical statements from developers on questions such as these are clogging up the debate around Gutenberg’s feature set.

None of these questions, of course, matter to users, who just want to build websites using the best—easiest, most intuitive, most powerful, cheapest—tools available.

Software definitely needs a clear philosophy and purpose; but that purpose needs to start with users. If WordPress exists to “democratize publishing,” it should be helping users publish what they want to publish. The largest commercial entities in WordPress development—Avada, Divi, Visual Composer—are abundant proof that users want to publish websites, with complex custom layouts as needed, and are willing to pay in huge numbers for software that lets them do so.

The default WordPress publishing experience—publishing whatever—is quickly being left behind.

I am pessimistic that all the philosophical noise around Gutenberg will obscure a significantly more important truth: that the default WordPress publishing experience—publishing whatever—is quickly being left behind. WordPress’s ideological purity doesn’t matter if it’s among the worst ways to write blog posts or create page layouts; and without either leaning heavily on third-party tools or incorporating something like GBIAAFEPB into core, it’s headed that way.

Irreducible Complexity

WordPress is an open and endlessly extensible ecosystem, with millions of pieces of third-party code hooking into its core software. Long ago, WordPress also made the revolutionary decision to be accountable to its ecosystem through strong backwards compatibility—meaning that things that used to work, even in third-party code, should continue working as the core software grows and changes.

These are two of the most wonderful things about WordPress as a software project—perhaps the two most wonderful—but they’re also constraints. Because it is headed for core, Gutenberg faces these constraints. None of its competitors do.

And so, in addition to the baseline complexity of creating a good page builder in WordPress (solvable by small, motivated teams, such as Beaver Builder or Elementor), creating this page builder in WordPress core exposes layers of frightening complexity, some of which I’ll list:

  • Since Gutenberg is supposed to replace meta boxes, how will it preserve legacy support for all the PHP-based meta box solutions out there? A “breaking change” on something like meta boxes would be unprecedented in WordPress.
  • Gutenberg uses HTML comments to create its layout elements, presumably for a more perfect fallback experience than other page builders have attempted or accomplished. Will this have side effects? Is building layouts based on HTML comments the right way forward for the future of the web?
  • Will Facebook’s “open-source (with caveats)” ReactJS library be a sufficiently friendly partner for WordPress from a licensing standpoint?
  • If Gutenberg replaces the default post editing experience on every WordPress site, how can it hope to handle all the possible edge cases? Does Gutenberg try to support sites whose whole editing flow is built around some obscure feature of TinyMCE Advanced? Does it simply expose a checkbox to re-enable the default post editor? Where does the Gutenberg project draw the line with backwards-compatibility?

In my view, the complexity of the WordPress ecosystem is pushing Gutenberg toward being a relatively small, timid piece of software, that stirs up a lot of dust in the community but doesn’t go very far toward meeting users’ actual needs.

These are the real, very hard-to-solve problems that the Gutenberg team is trying to face—which is a major reason why features like “backend tool to let you drag and drop two text fields next to each other” are taking so much time and so much debate.

In my view, this complexity is already pushing Gutenberg in the direction described throughout this article: toward being a relatively small, timid piece of software, that stirs up a lot of dust in the community but doesn’t go very far toward meeting users’ actual needs, or toward paving a future in which WordPress continues to thrive without an ever-growing dependence on a proliferation of third-party builders.

What Happens if Gutenberg Is Underwhelming?

At this point, it seems unlikely that the WordPress core team will summon the clarity of purpose and collective willpower to deliver the tool that users’ behavior indicates they want. So if Gutenberg never becomes GBIAAFEPB (or, if you like analogies, if the historical Gutenberg had just started a handwriting class at his house), then what happens to WordPress?

I doubt that the Gutenberg we get will actually damage people’s experience of WordPress. Rather, it just won’t make much of a difference.

What we get is the status quo. Given WordPress core’s slow development cycles for major, paradigm-shifting releases (such as the REST API), and given the core developers’ wonderfully consistent commitment to delivering polished, backwards-compatible software into core, I very much doubt that the Gutenberg we get will actually damage people’s experience of WordPress. Rather, it just won’t make much of a difference.

That leaves us with the status quo, which it may be helpful to describe a bit:

The Status Quo

If Gutenberg is small and limited enough that it doesn’t alter WordPress’s overall trajectory, here is what that trajectory looks like:

  • Disruption from below. In my view, Squarespace is already better than WordPress for very simple sites. I’m a full-time developer, but when a friend wants a simple site, I build it in Squarespace, and I enjoy the heck out of the process. The status quo is that simple informational site projects will continue to migrate to hosted solutions. The bloated theme marketplace will hollow out as small, B2C WordPress projects become less numerous. WordPress implementers will be squeezed heavily, and will become Squarespace or Wix implementers or change fields.
  • Fragmentation overall; further consolidation around various commercial solutions. For a long time, WordPress was the best way to build almost any website. That’s becoming less true very rapidly, and, naturally, the marketplace is responding much more quickly than is WordPress core development. Semi-autonomous communities formed around commercial technologies like Divi, Beaver Builder, and BoldGrid will continue both to proliferate and to consolidate themselves (including expanding vertically into hosting, domain registration, custom development, etc.), because they restore the premise that WordPress is the best way to create a website for the vast numbers of users with limited budgets and limited technical ability.
  • Reversing market share trends; “peak WordPress.” WordPress’s market share numbers cannot continue to increase indefinitely if WordPress becomes a suboptimal (slow, expensive, and clunky) solution relative to hosted builders. As new consensus builds in the market over the next several years, WordPress will become an increasingly tenuous choice as a solution for “just websites,” and will start to contract into more and more tightly defined niches (“large corporate sites,” “established online publications,” “multisites,” “e-commerce sites making less than $2M in annual sales,” and so on).

In other words, the pressure is ratcheting up on WordPress. It will always be amazing software for some things, even lots of things; but the status quo is that, in five years, it won’t be the first choice for people looking to get online, unless they’re drawn in through Divi or another one of the highly market-savvy solutions that use it.

Summing Up

Again, I really hope that Gutenberg can become the builder experience that WordPress very obviously needs, but at present the shape of the conversation, and the software itself, makes me “cautiously pessimistic” that that will happen anytime soon.

That spells a somewhat troubling future for WordPress, although the third-party commercial solutions that already exist—and that lack the constraints of core-bound projects—may prove sufficient to keep WordPress relevant for website development even in a non-GBIAAFEPB world.

The main issue with Gutenberg being underwhelming is that WordPress then misses the opportunity to bring a sprawling, hyper-redundant ecosystem together around one set of very good choices.

The main issue with Gutenberg being underwhelming is that WordPress then misses the opportunity to bring a sprawling, fragmenting, hyper-redundant theme/plugin/framework/builder ecosystem together around one baseline set of very good choices, and that’s troubling for the long term.

To wrap up, I thought I’d point to a couple other WordPress writers who I feel are making good sense among the thousand Gutenberg “first impressions” reviews out there (this article is the 1,001st).

I found Matt Cromwell’s review cogent. It covers all the major user-facing concerns I outlined here while remaining optimistic about the project as a whole.

I’d also like to point to, and excerpt at some length, Chris Lema’s June article on Gutenberg, which, beneath a wide-eyed “Who, me?” tone, has a laserlike focus on user needs:

The target, that I thought I heard, was the other players. The folks that were spending gobs of marketing money on ads and were taking market share from the WordPress ecosystem. […]

I thought that WordPress does more than just blogs? And if we’re going after something different, like pages and sites, then we’re far away from the things that Wix, Weebly & Squarespace are advertising. […]

If we’re going to solve a problem with this plugin, shouldn’t it be the cognitive dissonance that people have when they edit in one interface and see their work product appear in a different interface that doesn’t look like they thought it would?

What do we want? On page, what-you-see-is-what-you-get (WYSIWYG), content creation. When do we want it? Now.

Yes, that is what I want; and yes, I do want it now. (In fact, I already have it now, just not in core.) It’s a good chant, and one that, from the evidence, most of the internet is chanting along with us. Unfortunately, I’m not sure if the Gutenberg project’s going to hear us, or respond accordingly if it does.

So, those are my two cents/4,700 words (I need a raise) on what Gutenberg needs to be. What do you think? What is it that users need, and what can we do to help Gutenberg become that thing?


17 Responses

Comments

  • Greg says:

    I think that code simplification to make the files smaller and sites load faster would be a large improvement to the overall performance and user experience. It would also help with ranking the site in search. Important is also integration with many plugins. For example, if I could test the plugin in a copy or virtual site, even for few weeks, before actually activating the plugin in the real site. Also features like telling me about the compatibility of the overall plugin with different themes setup in the site to eliminate errors and problems.

  • Piet says:

    The most disturbing thing at the moment is the fear that it will not be possible to turn the thing off once added to Core in 5.0.

    I surely hope it will be(come) possible, but that remains unclear.

    Next time you need to make a simple site, have a look at Grav (https://getgrav.org/), I built a few sites in it already and it is a liberating experience!

  • Thanks, Fred, I couldn’t have said it better.

    Of course, as the single-least-popular-guy in the WordPress galaxy from November 2014 to May 2015, I TRIED to. Among other things The WordPress Helpers ( still live at http://wordpress.answerguy.com ) was my attempt to get the WP ecosystem into a more user-focused, broader, more-capable-of-sustained-growth place.

    WordPress remains the “best” way to do a website, and the themes and plug-ins, despite their bloat, are getter more sophisticated and better. But the problem, and the reason that WP’s market share growth has slowed to near-nothing, remains that it’s a system made for producers—not users—and leadership still doesn’t understand that’s a problem.

    I’m talking about Ma.TT . I’m talking about the louder (not the “better”; Lema is pretty smart) members of the community. I’m CERTAINLY talking about the CORE team.

    Thanks so much for this piece. REALLY great. Now let’s hope it matters.

  • This is really good, Fred. I agree with the vast majority of this. I do think we’ll get to “GBIAAFEPB” (as you so eloquently termed it), that a lot of the technical caveats can be overcome, and I’m excited for the general WordPress user experience to be cleaner and nicer. In the meantime, new Gutenberg-extension plugins (or maybe even plugins like Jetpack) can plug the gaps for people.

    The market share question is key here, because it forces an answer to “who is WordPress for?”. Until now, it’s been everything to all people; it feels like we’re fixing the “choose Squarespace instead of WordPress” problem here, but would be very interested to hear more thoughts on how Gutenberg impacts very big sites and/or sites using complex API integrations using WordPress, if at all.

  • Thank you for this very informative post, Fred. I was truly enlightened about Gutenberg, which I was skeptical of–and even now more so after reading your post–and I love your vision of what Gutenberg could become. I hope those working on Gutenberg will listen to you.

  • Kristin says:

    Fred, I believe you have written the definitive opinion piece about Gutenburg and I desperately hope people listen to you.

    It is just odd that this is happening; like Chris Lema, I first thought Gutenburg would be the long-needed front end editor. Finally! How exciting! After all, that is so obviously what people need that an overhaul of the UX would have to be front end editing. Nothing else would make sense. It is that obvious.

    Yet here we are. I hope you are right that Gutenburg will only be a missed opportunity and the beginning of the end of the all we have enjoyed in and around WP. I’m also worried about it becoming an instant disaster when it drops and breaks not just plugins and therefore sites but all user workflows.

    Thank you for writing all those words. You have said, well, what most needed to be said. May it be heard.

  • Hashim Warren says:

    I wish the Core team would solve the “First Five Minutes After Install” problem.

    There should be a wizard that asks you about your goals and builds out custom post types and fields for you. Marketing site? Here’s you “about”, “contact”, and “services” pages and custom fields.

    WordPress Core should make ACF and Pods unnecessary.

    That one change would expand and keep people in

    • Kristin says:

      Hashim, I agree completely with your belief that goals, etc. should be spelled out before the 5 minute install takes place. However, I do not belief business strategy should be left to a wizard. We have that solutions in the thousands of consultants ready and able to help people set up their sites. That’s not where WP should focus, in my opinion.

      We need a fix not for the weeks/months before the install, or the five minutes after. We need a fix for the 5 years of not wanting to update their site because it is not intuitive. That’s the fix Fred is talking about and I wholeheartedly agree.

      But you are right . . . without that strategy to start . . . none of the rest of this matters.

  • A few thoughts.

    First off, you make Squarespace sound delicious. So much so that I’m checking it out.

    Then, you’re 100 percent correct. Columns are crucial. If Gutenberg doesn’t include this ability, they’re missing, as you say, 50 percent of the point.

    And yes, Elementor would have been better with a 12 column structure.

    But there’s one thing few people touch on, and I can’t understand why it’s not considered important.

    Category and tag pages…

    These pages are super important to me. I can’t understand why they don’t come with better layout options, built into WordPress.

    I think Beaver Builder makes a plugin you can use to manipulate them, and Generatepress gives you a blog layout option, but I’d love to see more layout options out the box.

    Alternatively, one could create a page and use a plugin to display posts, but that’s what category and tag pages are there for.

    So, although WordPress is a fantastic system, it falls short quite a bit.

  • Pete says:

    Idiotic article.

    The future is not good looking websites, its content, and content is different to presentation. Once you mix the two concepts you prevent reuse and create management issues.

    My content is reshared, email, syndicated, screen read, indexed by search engines. Columns are irrelevant to these cases.

    There is no future in page builders and you ruin wordpress if Gutenberg becomes a page builder.

    • I can’t figure out whether you’re trolling, or being serious.

      Where you have control over the presentation of your content, wouldn’t it be wise to make the most of it, in the interest of pleasing the consumer?

      From what the market is showing, the future for page builders is stronger than a Springbok front row. And we all know how strong a Springbok front row is.

      I think it’s WP that needs to shape up.

      Fred mentions Squarespace in his article. He doesn’t even touch on the other builders.

      There’s a myriad. And they do a fine job of doing content WITH presentation.

  • Alain Melsens says:

    What about the free wpblockade plugin, that integrate full visual wysiwyg publishing tools in the tinymce editor…?
    See what you can do with it on the http://www.wpblockade.com website. It’s entirely builded with wpblockade with blocks, columns and many more. That’s what we need, real inner content visual editing.
    I have doubts about Gutenberg…

  • Bernhard says:

    very intresting read – but especially the idea of removing meta boxes is a deal breaker for me as pods user as I like to stucture my content with CPT and Fields, if you go beyond a plain blogging solution I don’t see Gutenberg replacing that. Take a look at Beaver Themer from the Beaver Builder Team – it’s front end “blueprint” creation for everything in the wp-hierarchy. So while it’s nice to have the option to nicely style your “articles” wordpress has gone far beyond that …

  • Matt says:

    Thanks for taking the time to write such a comprehensive article. I agree with you on a lot of points, and there are definitely a few items that have been topics of discussion in Gutenberg chats for a while.

    What many people, including Squarespace, call a front-end editor isn’t actually editing on the front-end, they just do a good job of letting you edit a preview that looks just like the front-end. What’s important is to a user they understand how one thing maps to another. Gutenberg lives in wp-admin, which gives us a lot of space to give a really rich interaction and interface without trying to shrink or squeeze something into the front-end, but the relationship between what you’re creating and what it will look like will be much closer than the current editor and I think people will like it. It will also work much better on mobile than any of the “front-end” editors you mention, which is a key for the next decade of WordPress.

    I think an important thing to remember is that what ships with 5.0 is just the first shipping version, no one has any intention to stop there and in fact the roadmap for WordPress and the customizer extends through 2018 and you’ll see us tackle (and hopefully conquer) many of the things you mention including layouts and columns. Although they are going to be in WP 5.0, Gutenberg has been built with that future extensibility in mind.

    Anyway I hope you continue to try out the new versions as they come out and see the direction we’re headed in, to WP 5.0 and many releases to follow.

    • Fred Meyer Fred Meyer says:

      Thanks for reading it; I know it’s been a busy week.

      With respect to the “front-end builder” conversation, I’d urge you to look through the eyes of a user. Whatever the technical distinction may be between “front-end editor,” as you’re defining it, and Squarespace’s editor, it’s not a consequential one to me as a user. Do you also include Elementor and Beaver Builder in this category of non-“true” front-end editors?

      What those three solutions have in common is that as you author in them, you are seeing precisely—not approximately—what the result of your authoring will be. Exactly how it lays out on the page, exactly how it looks on the site’s background colors, below its headers, above its footers, and next to its sidebars, exactly how the typography will look given theme and other CSS files. When I write to a page in Squarespace, Beaver Builder, or Elementor, I’m looking at the final product the whole time I’m working, and when I hit publish that’s what I get. If there’s a technical sense in which I’m not “really” editing on the front end, it’s a trivial one relative to my user experience.

      If Gutenberg stays in wp-admin, it simply cannot be what the paragraph above describes, and what the behavior of for-profit builders is telling us users want. Gutenberg is shaping up to be a back-end builder: it tries to create an environment like the front end, but we’re simply not on the front end. If we were, we’d be looking at the page we’re working on, not a wp-admin screen, no matter how cleverly that screen inherits things like colors and typography.

      I will (of course!) continue to give Gutenberg a chance as its development process unrolls. My intent is to help advocate for a Gutenberg that revolutionizes the user experience of WordPress and keeps the technology relevant for the next decades—you can check my childlike joy at the old Front-End Editor feature plugin for evidence. 🙂

      But I wonder if the React reset gives you another chance to go back to the drawing board on what Gutenberg will be in its fundamentals. A responsive-grid-based, front-end builder is an absolutely colossal challenge given the things that need to be true for a Core product, but it’s also what users want.

  • I absolutely agree with “builders that developers don’t find palatable”.

    But that’s the biggest problem: That they think the page builders are built for the developers/webdesigners. But they should be built for the end user!

    For the end user every page builder simply sucks!

    Best example with X (but I made the same experience with Divi, Visual Composer and Avada): Within the page builder I can define the border radius of a button – for each corner separately! If I (the webdesigner) want to do that, I’ll do it with CSS. But now my customer (the end user) can’t use the page builder, because it is a complete mess with literally thousands of options and you need a master’s degree in page builder operations management…

    And to edit a simple text box? You have to click 3 times!

    No idea if the Beaver Builder or Elementor handle that better (any insights on that?). Or if maybe Gutenberg is the answer.

    But I agree: We need a really(!) easy to use WYSIWYG editor for end users (bonus points if it’s developer friendly)!

Add a Comment

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