WordPress Gutenberg Review

I think it’s important to know the history of my experience with WordPress in order to understand the basis for opinions, so this is where I will begin my WordPress Gutenberg review. I had my first real introduction to WordPress in 2012 when I made a site for a client that needed an easy to use CMS. My overall impression with WordPress at the time was overwhelmingly positive, however there was one point of contention – the editor. It wasn’t necessarily the fault of the editor as much as it was CMS’s in general, but I was surprised that there wasn’t an easy way to arrange and layout content in anything other than vertically linear. I ended up needing to place some custom HTML markup in the editor as part of the page content, which didn’t meet my goal of all content being easily editable by the site owner.

A little over a year later I once again found myself in the same situation, only this time the goal of all content being easily editable by the site editor(s) and owner(s) was now a requirement as I was working in a distributed environment with many content editors, most of which having no web development experience. I began researching the various ways to extend the editing experience and found it quite lacking – needing to cobble together various plugins, shortcodes, menus, widgets, custom post types, post meta and metaboxes, and custom page templates to make it all work. It did work, however even after training content editors they still struggled to understand how to edit site content and where it all lived within the WordPress admin.

The Rise of Page Builders

A little over a year later I began hearing about new WordPress plugins called Page Builders, such as Visual Composer, Divi, and Beaver Builder. In the end I decided on Beaver Builder and haven’t looked back since. With Beaver Builder, in many cases, I no longer needed other plugins (aside from the core list used on all sites), shortcodes, widgets, custom post types, post meta or metaboxes, or even custom page templates. It allowed me to style the site using brand guidelines and then turn it over to the site content editors where they were able to edit their content on one place, right on the page and on the front-end. It allowed me to separate concerns considerably between the responsibilities of developers and content editors, while still providing the editors with a huge amount of flexibility.

There were those in the WordPress community that looked down on page builders, seeing them as inferior to the custom code ways of the past. I can’t say that I blame them either; many of us had poor experiences with tools like DreamWeaver (or Microsoft FrontPage) and had lost trust in visual editors to build our HTML markup. Despite that, plugins like Beaver Builder worked incredibly well and output clean markup, and from my perspective page builders were obviously the future of website creation and editing in WordPress. There were simply too many benefits to Page Builders for them to not become mainstream.

Finally A New Editor Arrives: Gutenberg

With the rise in popularity of page builder plugins and a plethora of site building services such as Wix, Weebly, and Squarespace, among many others, WordPress needed to do something to stay competitive. The answer to this was: Gutenberg. Now, without any further introduction, here is my review of the Gutenberg editor, organized by role and broken down into pro/con lists.

From The Perspective of a Content Editor

Pros

• User Interface Design: Though it is completely new, the design of the user interface fits very well with the rest of the WordPress admin and should help users to feel comfortable using the new editor.
• User Interface Responsiveness: Since the entire Gutenberg interface is built using JavaScript it feel quick and responsive, even with dynamic elements.
• User Interface Standardization: Prior to Gutenberg users may need to work with several different interfaces in order to edit their site, such as menus, widgets, metaboxes, settings pages, etc. With Gutenberg everything can now use the same interface: the block. This isn’t fully implemented yet, as of WordPress 5.0, but it’s already in the works and will drop in the next few major releases.
• Design and Layout Abilities: Gutenberg offers page-builder-like features for content layout and style. Though relatively limited as of WordPress 5.0 I expect this to expand in the future as the next phase(s) of Gutenberg are implemented and third-party plugins are created.
• Editor Tools: In order to assist users in crafting higher quality content there are at least two new tools available in Gutenberg. The first is Content Structure, which includes general information about the post and a Document Outline, which helps ensure headings are used properly. The second is a subtle accessibility notice when the color contrast between a block text color and background/cover color isn’t high enough to meet WCAG 2.0 AA or AAA specifications.

All of these things help to bring WordPress at least up to par with competitors, while also preparing it for the future.

Cons

• User Experience:
  • On first impression I was quickly left feeling that it’s rather clunky and requires a lot of clicks to accomplish tasks. This will be explained in further detail below.
  • User Interface elements are hidden until hover/focus/save/etc. There needs to be a balance between keeping the interface simple and clean and showing users what they need, Gutenberg goes a little too far by hiding elements.
    • The block positioning controls (the drag handle) is only visible when hovering on the left 25% of a block. This should always be visible when a block has focus or is being hovered over (regardless of mouse position).
    • The block insert button (small + at the top center of a block) will only show if a block doesn’t presently have focus and if the mouse is hovered along the top edge of the block. The block already doesn’t have focus so the BlockControls will be hidden (and thus won’t interfere with the insert button) so the insert button should be visible regardless of mouse position.
  • When repositioning a block by dragging it up or down the drop-zone isn’t inline with the handle (on the left) so you actually have to move the mouse inward (closer to the center of the blocks), despite the fact that blocks (for the most part) stack vertically (which implies vertical repositioning), which makes the experience feel broken if you simply drag a block straight up and release (as it won’t work).
• Specific Block Issues:
  • Columns: they’re are incredibly cumbersome to work with (clicking around in just the right spot to finally select the column itself to change its settings is a joke), and blocks within the columns block lose their drag handle so once a block is in a column it’s there for good (or until you delete it and make it again somewhere else). Also, during my time testing the columns block I also experienced a hard crash when I attempted to drag the column block into a drop-zone of the column block that I was moving and my browser tab closed and ended up losing a bit of work that was unsaved. All of this is inexcusable as the columns block is one of the few blocks that give Gutenberg any sort of real flexibility with layout, and will be instrumental in Gutenberg being capable of taking the place of page-builders.
  • List: They don’t allow you to press Tab or Shift+Tab to indent/outdent a list item. This is just a personal frustration that I ran into while creating this list for this review and several times found myself jumping down to the next block (when pressing Tab) when all I wanted to do was indent a list item. Really?
• Gutenberg on mobile:
  • The Inspector Controls sidebar is full-width, even on something like an iPad (with ample screen space), and covers the page content so changes that are made cannot be previewed until the Inspector Controls are closed. This breaks the user experience, and defeats the whole purpose of having the editor UI built in JS where you can see changes live.

From the Perspective of a Developer, Extending the Editor and Creating Blocks

Pros

• Standardization for development:
  • In the past there was no standardized way of extending the editor, which meant that it was almost entirely up to developers. Though this allows for a more broad spectrum of developers, ranging in skill from beginner to expert, to create extensions it also leads to fragmentation in implementation and severely limits the ability to share code. Conversely, developing for Gutenberg is largely standardized around blocks.

Cons

• High barrier of entry:
  • Getting started developing for Gutenberg can be a fairly daunting task. Though Gutenberg blocks can be created with minimal PHP and ES5 JavaScript the expected standard is to be ES6+ with JSX, which requires some knowledge of React and build tools (Webpack and Babel). If simply creating a series of blocks this can be relatively straight forward, especially if using somethings like create-guten-block, however it can quickly become complicated if the plugin is doing more than creating new, simple/static, blocks.
• Documentation:
  • Overall, the documentation is well written and fairly thorough, but the way that it’s organized left me not knowing what I didn’t know. Meaning, I didn’t know what to search for within the handbook because I was new to the terminology and the order of the handbook is such that the intermediate/advanced topics are buried within the chapters, coming after the massive list of Packages and Components. This initially left me with the impression that I had gone through all guided documentation that was available, which sent me to Google to fill in the gaps (which has a lot of outdated information as Gutenberg changed so much over its development cycle). There are also some challenges with the docs and examples where some examples are provided in ES5 and ESNext while others are only in ESNext (ES6+ and JSX). The Gutenberg examples provided by WordPress are also a great starting point, but don’t cover things such as the InspectorControls or ServerSideRender. Lastly, looking through the Gutenberg source on Github isn’t as helpful as it could be since that code needs to be built/transpiled so the code isn’t directly usable within your own project, and completely irrelevant if writing it in ES5.
• Migrating existing projects to Gutenberg:
  • Existing plugin code bases that use PHP to render user input controls (such as for meta boxes, widgets, or shortcodes) must be rewritten in JavaScript, and whatever rendering/template system you’re using will now need to be built in JavaScript as well. Also, if those inputs used dynamic data it now also needs to be piped to the front-end so it can be used in JavaScript, likely via the REST API.

In closing, I think WordPress was in a position where it needed to make a big, bold, change or risk moving towards irrelevance as other more modern competitors eroded away at its market share. There seemed to be some internal confusion, at least early on, about what Gutenberg actually was: whether it was simply a replacement editor or a full site builder that merely begins with the replacing the editor. As the development cycle continued that messaging became more clear, and we now know that Gutenberg, phase 1, is just the first step towards being a full site builder. In my opinion I think it was largely a success, and the majority of the issues that I’ve outlined in this review can be resolved in future releases or by third-parties via plugins. The only exception to that is the development complexity challenges, but this appears to be the direction the web development industry is heading.

That said, I think Gutenberg still has a long ways to go in order for it to be a complete success. It will need to continue to evolve and grow in what it can do, with more and more advanced layout and styling features being added. For instance, as much of a giant leap forward Gutenberg is compared to the classic editor it still pales in comparison to something like the Wix editor.

All of this is a risk and gigantic opportunity for WordPress, and with the foundation in place I’m both hopeful and excited to see where things go from here.