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.

“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…

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 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.

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.

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.

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?