I didn’t plan to write this post.

Before it, I was working on a different one addressed to my clients about the upcoming changes to WordPress: In version 5.0, a brand new editing page design—code-named “Gutenberg”—will replace the Edit screen where site editors spend most of their time. I want them to know what’s coming, how it will affect them, and how I will support them through the change. Naturally, I wrote it in the new editor using WordPress 5.0-beta1.

It did not go well.

We always say that first impressions on the web matter, and WordPress is only going to get one new first impression with each site owner. As it stands, too many people will have a negative first impression.

tl;dr: WordPress 5.0 can and should be a positive change to WordPress, but if it is released in late November as planned, it won’t be. There are simply too many bugs in the editor, and the experience is not polished enough. This is because the rate of development has prevented systematic quality assurance (QA) and user testing. Both types of testing are required to ensure the editor is ready and to increase the community’s confidence in the update.

Big Problems. Small Problems.

I want this to be a constructive post, so here are some of the issues that lead me to this point.

Overall, it’s still hard to “just write.” Things pop up and flash and make it hard to focus. I’m not the only one who thinks so. John James Jacoby posted a great review of his first-impressions of the new editor:

There are grey and blue hover/focus outlines on blocks, toolbars pop-up, the buttons in them have tooltips that pop-up, and there’s a grabber UI [User Interface] for relocating blocks that comes and goes – it’s just… a lot going on.

John James Jacoby, “WordPress 5.0 Beta 1”

The overall experience of writing, editing, and saving still needs testing and polish to avoid first reactions like this. Specifically, I think more “progressive disclosure” will benefit users by giving more prominence to commons tasks and less to infrequent ones.

Looking closer, when you really start writing with this new editor, there are simply too many bugs that affect frequent everyday writing tasks. While writing this post and the previous one, I found a number of bugs just for making bulleted lists. In one extreme case that happened repeatedly, the editor deleted most of a bullet’s text. Some problems have been fixed already, but these types of bugs simply shouldn’t be popping up 3 weeks before launching a tool to 32% of the internet. And that’s not to mention the list of 10 or so bugs I still need to report.

I’m doing my best to give feedback, but it’s exhausting and there are so many little bugs that I struggle to isolate and replicate the one I’m reporting without running into another. How is it possible for me to find so many bugs without trying from just writing 1.5 blog posts?

One doesn’t realize how many small interactions are involved in writing a blog post until they suddenly stop working. Gutenberg has been eye-opening in this regard, as many of my subconscious clicks and key presses don’t do what I expect them to. For example, I find my assumptions for the behavior of ENTER, BACKSPACE, DELETE, and arrow keys are frequently violated. My cursor gets stuck in some blocks and I’m unsure of what combination of TAB, ENTER, or arrow keys will get me out.

Thinking about the useful concept of interaction costs—each decision, click, and keystroke is a “cost” to the user for using the interface—the editor is much more “expensive” to the user in WordPress 5.0. Some of that increased cost is worth it as a trade-off to gain more powerful features, but much of it feels unnecessary and maybe even erroneous.

What Needs to Come Next: Testing & Polish

At this point, I’m over my initial “it’s different” fears of these features. What’s more, I want them to succeed! My entire business is built on WordPress’s success. I even think that this next version of WordPress will be an improvement. BUT. IT’S. NOT. READY. YET.

The pace of development has been blistering. That speed has been great for developing a lot of features and iterating on those features quickly, but it hasn’t allowed for sufficient testing. What’s needed now is more time for people to find and report bugs with the editor features in their proposed final state.

In particular:

• We need real-world published user testing—especially for accessibility—that validates the usability of key writing tasks and the overall user experience for focused writing. Simply stating how many sites have the plugin installed or how many posts have been written (less than one per site Update 13 Nov 2018: Thanks to Miguel for pointing out that the stats I link to are quite unclear. The count of posts created is only from a subset of the total sites with Gutenberg installed. It would be very useful if they could clarify how many sites the post count comes from as I do think the posts/site stat is interesting.) is insufficient evidence of readiness. After completing a draft of this post, I learned of this excellent testing work from Sarah James [wordpress.slack.com account required]. (PDF Summary of one test. Update 13 Nov 2018: 10up published Sarah’s recent testing today!) This is what we need more of! It should be publicly celebrated when it confirms successes and publicly addressed when it shows failures.
• I would like to see the core writing blocks (headings, paragraphs, lists) “blocky-ness” de-emphasized to allow for better focus and flow when “just writing.” For instance, the “Paragraph” label that hovers over a paragraph block seems completely unnecessary.
• Rather than making a solid experience for everyone, additional “modes” (Spotlight, Fullscreen, Block Navigation…sort of) were added, seemingly to satisfy specific complaints. Let’s take that feedback and improve the default experience instead! Any modes that remain need testing to confirm it achieves its stated purpose.
• There also needs to be more QA testing of keyboarding sequences (the source of most of the bugs I’ve found recently), in browsers other than Chrome, for accessibility, for performance, and when paired with popular plugins.

Complete the Abandoned Audits!

As best I can tell, there has been no formal, exhaustive QA work done. This is a necessary step to ensure the editor features will work as intended for everyone. An effort like that has never been done in WordPress before, but WordPress has never released such a massive technical and UI change in a single release either.

One of the ways to facilitate this work is to complete the “audits” of each block type in addition to audits of other major features like the different “modes” and general formatting options. These audits seem to have started this summer but haven’t seen any work since early September, so they are now both out-of-date and incomplete.

As the audits are conducted, I would also hope for final reconsideration of each feature to determine if it’s truly necessary for a simple, easy-to-use editor that facilitates good web publishing. There are a number of tools and block types that are certainly useful for someone, but every feature and option competes for attention. I think there are some easy candidates for removal*, and doing so would increase confidence in the project by demonstrating that hard decisions are being made to streamline the interface and reduce its complexity.

Without working through a systematic review of what’s been built, I don’t know how anyone can be sure that the editor is ready for release. (If you know how that decision is being made, I’m eager to hear it!) Worse, there hasn’t even been a public explanation for why these new features are ready. For the past 3-4 years, WordPress has required a “merge proposal” blog post for every major new feature added to the software. While I’m sure many people fear the negative comments that will accompany a merge proposal or feel it’s not perfectly suited to the job, this is also the wrong moment to make an exception to a precedent that’s intended to publicly establish a feature’s readiness for inclusion in WordPress.

Why Delaying the Release of WordPress 5.0 is Reasonable

My guess is that in the last two years, I’ve spent 40 hours on this project providing early conceptual feedback, closely following development, testing, reporting bugs, and even organizing testing at WordCamp Seattle 2017. And yet, I still feel like I’ve barely been able to keep up, much less to do meaningful testing and delivering feedback. I suspect this has been the same for many.

In its current state, WordPress 5.0 (Beta 3 at the time of writing) has features that don’t really work and small but obvious bugs. It’s not accessible nor a unified experience for anyone. Given the timeline so far, it’s impossible that enough testing has been done to confirm the overall experience is ready or that the features included are the ones that should be in the final product.

And that’s to say nothing of the broader WordPress ecosystem. Plugin developers need more time to ensure compatibility. Themers need time to wrap their heads around the final featureset to determine the best way to support it. Bloggers and trainers need time to update and create accurate materials to support the first users of Gutenberg.

If Gutenberg is released on it’s currently planned schedule, I will block it with the Classic Editor plugin from the ~30 sites I manage for my clients. I will block it not because I don’t like it, but because I’m not convinced I can promise my clients it will work as intended. That’s an important distinction.

Why 5.0.1 is Not the Solution

One likely response to the ideas in this post is that subsequent biweekly bug fix releases to WordPress 5.0 can address these issues. I disagree.

I suspect that if the above plan is completed, “breaking changes” to code and notable interface changes are likely. If my assessment of the issues with bugs and experience are even half-right, then there should be notable changes made to the user interface, and some features should even be pulled and released later. These changes must be done before WordPress 5.0 goes live.

Current users of the “beta” editor are tolerant to change in a way other users won’t be. So until 5.0 is released, there’s still time to fix mistakes and remove features without causing an uproar. The saying goes, “measure twice and cut once.” It’s not “cut once and measure ten times,” which is what a series of minor-point releases would be.

This is What WordPress Should Stand For

WordPress wants to “democratize publishing” by making the best CMS in the world that anyone can use. Its mission states, “WordPress is software designed for everyone, emphasizing accessibility, performance, security, and ease of use.” If all those things aren’t true yet for this landmark feature, we shouldn’t release it.

I don’t think Gutenberg should be trashed or radically changed. I just think that a clearly defined plan for testing and validating the final proposed featureset is necessary to increase confidence in the project and ensure the editor is actually ready for release. That requires more time than the current schedule allows.

Let’s just wait a few more months (how about February or March?) to test, fix, and let people better prepare for the change. I think the editor can be drastically better by then and ready to live up to WordPress’s grand stated ambitions.

* Appendix: A list of features that I think are  unnecessary for a solid core editor

Like I said, I think there are a number of features that are candidates for removal. Removing even a few features will help users focus better on fundamentals, reduce the amount of code requiring support, and streamline the overall experience.

• Tables block – It’s begging for abuse. Using tables for layouts is a 10+-year-old bad practice, and in my experience, if you give users tables, they will use them for design.
• Paragraph Background Colors – As highlighted in Jacoby’s review, paragraph backgrounds are a niche feature and also probably don’t meet everyone’s needs anyway. Waiting until Gutenberg has more robust support for nested blocks and then introducing a “Box” block that can contain multiple blocks feels like a much better long-term solution. This is a feature people won’t miss if it’s not there, but will complain about if it only half-meets their needs.
• Spotlight & Fullscreen mode – I’m sure some people may like these…and they should be free to install them with a plugin.
• Dropcap – A very prominent option for a very niche text formatting effect.
• Verse Block – A block specifically for poetry was a nice proof of concept in the early phases of development, but we have since passed that moment.
• Pixel-based font sizing – The developer-defined font sizes are sufficient for almost everyone and protect users from inconsistent font-sizing across their website. Further, pixel sizing requires inline CSS styles, something that should be avoided at all costs.
• Columns – While I think columns are an important feature for eventual inclusion, they are still incredibly buggy and hard to use. If they can’t be drastically improved in time, they shouldn’t be in Version 1 of the editor.

I want to be really clear that this post isn’t targeted at any specific person or in response to any specific experience. I appreciate the truly incredible effort that has gone into developing Gutenberg. That effort hasn’t been wasted and I think the project is in its final stretches. But frustration sensed is real and stems from a lack of clarity around planning, testing, and a clear vision of how to know when the editor is complete.

A big thanks to Joshua Wold, Larry Swanson, Alfredo Rodriguez, and my partner, Emily, for providing feedback on drafts of this post.