The future of WordPress is coming, and it’s called Gutenberg.

What is it? It’s a brand new editor being developed by a huge group of people who seeks to enable “rich formatting” options in WordPress. Think: more complex layouts (columns, text over image, etc.), easier content embeds (e.g. a YouTube video), and including dynamic content (e.g. list of Recent Posts) in any page you make.

It’s ambitious and many view it as necessary to keep up with Squarespace, Wix, Medium, and other popular hosted publishing tools. I prefer to think of as an overhaul of the editor that can address the shortcomings that people face with the current one.

I’ve followed the project closely since it’s conception, and it has progressed quite quickly in the last six months. With the newly-released plugin version that anyone can install to test—though it’s not intended for use on a live site!!!—I’m writing this post in the current version (0.2.0) and publishing some first thoughts. ((Note: Once written, I had to convert it back into the standard WordPress editor for publication here.))

Things To Help You Understand Gutenberg

• As noted above, this is a super-early stage public release. It’s so early that you can’t even save posts and come back to them. Seriously, don’t use it on your live site right now.
• The editor works with the paradigm of “blocks”. A paragraph is a block. An image is a block. A list of posts, a gallery, a pullquote, or some custom HTML are all blocks.
• Blocks can be rearranged, converted to other block types (in some circumstances) or deleted.

Reactions to Gutenberg v0.2.0

1. It’s very powerful already but clearly unpolished and so it’s hard to know what’s incomplete or a bug.
2. My #1 complaint so far is the behavior of the ENTER key. It’s driving me up the wall. ENTER now creates a single line break rather than a “hard” line break that starts a new paragraph. But it’s inconsistent. Using ENTER in a list like this one creates a new list item. Two ENTERs also creates a new paragraph which heads off the worst possible problems but still adds another keystroke.
3. Another keyboard issue: Hitting TAB gets you to a new paragraph, but hitting SHIFT + TAB (which should take you backwards) pulls you up into the formatting buttons. This is likely just a bug, but I’m calling it out here.
4. About those formatting buttons… They appear at the top of whatever “block” you’re editing. That’s fine when you want them, but it also means they show up when you don’t like when you move your cursor inside a block, select text, or first hit SHIFT + ENTER or TAB to start a new block. That leads to lots of flashes of buttons and feels disruptive. Worse, by overlapping with the previous section of content, they can cover up the words you just wrote. As I write this post, I find the flashing distracting and it breaks my train of thought. To what degree will I get used to that as I use the editor more?
5. I really miss my shortcuts. I believe some are planned, but the ability to quickly make a Heading (ALT + SHIFT + {1-6}) or blockquote ALT + SHIFT + Q are things that really speed me up.
6. I can’t figure out exactly why, but I keep ending up with a lot of empty blocks at the end of this post.
7. The Imgur embed didn’t work in the Gutenberg editor (foreshadowing for below!), but I’d love to see an option for captions on all embeds.

Some Changes I’d at Least Like to Try

Standardize ENTER Behavior

As I mentioned, the behavior of ENTER and SHIFT + ENTER right now is inconsistent and confusing. While in the abstract, I can see how easy single line breaks in a paragraph are useful, the same cannot be said for single line breaks in a Heading—a horrible idea—that is a side-effect of using this behavior. It’s also telling that ENTER still creates a new list item when making a list. People hit ENTER in paragraphs most frequently to create a new paragraph, just like they hit ENTER in a list most frequently to create a new list.

Let’s assign the simplest keystroke the most common behavior in each context: creating a new item of that type or a paragraph in the case of headings.

Experiment with a Fixed Toolbars

The floating toolbars popping up and overlapping are really getting to me still. In some early iterations of the editor, this problem was even worse, but I question how it’s possible to make sure the tools are available when you need them but more unobtrusive otherwise.

What I’d like to see is some experiments with a fixed-position toolbar. At least on large screens, there’s plenty of space for one above the editor, and I’m guessing that the floating toolbar is even harder to use on mobile screens given that it may pop up when you don’t expect it to and suddenly be right under your finder.

Let’s Try Some Dragging and Dropping

Right now, blocks can be reordered with little arrow buttons, but many people are clamoring for a drag & drop option. I’ve caught myself trying to do it, and it feels like it will be useful.

Big Questions

I also have a few big-picture questions and concerns.

What Level of Control Will Developers Have?

I’ve got a particular horse in this race as well as the developer of a plugin that customizes the existing WordPress editor.

That plugin is the result of years spent watching clients use default WordPress editor features like right alignment to make pages that are harder to read and inconsistent with other pages on the site to the detriment of the site visitor.

It’s also not just about removing things. My plugin makes it easier to add some seriously useful ways to customize text specific to a theme. Rather than having my clients edit HTML to make relatively simple designs like button links or pull quotes, the current WordPress editor can be given a drop-down menu with these “inline” styles.

There still is no word on what degree of “feature” parity will exist with the old editor, but I’m certainly concerned right now. I really hope I’ll be able to quickly remove things like the alignment buttons and be given a way to implement easy inline CSS classes again in a v2 of my plugin.

What’s Going on With Accessibility?

There are some really smart folks with great web accessibility chops involved in this project, but I am a bit concerned about accessibility. The first review of the editor by a screen reader user I’ve seen is certainly a bit worrying:

Right now I’m thinking of what it would be like to write one of the WordPress with a Screen Reader posts in this and I want to just crawl under my desk and never write again.

I also heard Matt Mullenweg—WordPress co-founder and current project lead—say something recently that really raised an eyebrow on an interview with the apply_filters podcast. In a conversation about executive decisions made for the good of the project, he said: ((I’ve adjusted the transcript punctuation for clarity and fixed a typo. The linked transcript reads “WCAT”.))

…we need to throw out our rule book and just talk about when doing that is appropriate. We—for often very good reasons—do things like say WordPress is WCAG compliant and no new code should come in that is not. That’s a tradeoff, and that’s a tradeoff that we’ve enshrined. We should readdress it if we think that that tradeoff—whether for a particular feature, a particular user experience, or a particular benefit—is worth it.

The “WCAG” guidelines mentioned above are the Web Content Accessibility Guidelines which were officially adopted by WordPress just last year. A lot of people fought for this change hard and for good reason. If WordPress isn’t considering accessible coding as a first class concern up front it will get ignored. I’m reading way into that comment, but I don’t think one can express that sentiment about accessible coding standards casually. WordPress is supposed to “democratize publishing.” Switching to an editor—the central feature of a publishing tool—that is accessible to fewer people than the previous version is directly counter to that goal. To use the language of that interview: accessibility is #worthit. The new editor must:

1. Be accessible to WordPress users who rely on assistive technology.
2. Encourage the creation of accessible content.

What Will My Clients Do With These Tools?

This is a bold and maybe hyperbolic statement: but I think Gutenberg will make the web worse before (if?) it makes it better.

To be clear, I think big changes to the editor are necessary, but I worry about how prominent some new features are (everything from alignment to some complex layout ideas).

More powerful formatting options will definitely lead to more interesting designs and layouts, but I use “interesting” in both meanings of the word. Some will be eye-catching presentations of information that efficiently communicate with visitors. Others will just be… in-ter-est-ing… https://imgur.com/Be6wVgk/

Testers Needed

Just before hitting publish on this, the project put out a call for a new round of testing of this plugin. Here’s the guide for testing. If you’ve got a copy of WordPress you can try this with, please do and publish your own thoughts.

---

Let me know what you think of my observations below in the comments.