Now that Gutenberg has been released with WordPress 5.0 and has been out in the world for a couple of months, these are my thoughts about where we are now and what I expect in the future.
As a web manager and developer, I think that it is worthwhile to look back at the evolution of the feature and what it means for me and to the broader WordPress community.
Removing a Dependency
For many years WordPress has used TinyMCE as its WYSIWYG editor of choice. In fact, many web developers have used this for rolling their own CMS or just a more robust way to enter text to a web application. The standard line for clients was that adding or editing content was “just like Word”, which it wasn’t really, but it was close enough.
At some point, block editors started appearing. I first used one with the new version of Google Sites. Squarespace also has a block editor, giving it one of its early key differentiators from WordPress.
By building its own editing experience, WordPress has removed the dependency on this third, but friendly, party WYSIWYG editor. Not to say that Tiny MCE is entirely removed from WordPress, as it still exists in the Classic Editor block, but the future will be WordPress native… sort of. More about that later.
Like WordPress, Gutenberg is open source so that other systems, like Drupal can use it. Making this editor available to a broader audience was a canny move which may help speed it’s adoption and movement toward to becoming a standard.
Gutenberg as a Problem Solver
Anyone who has used Post Format in the past knows that they didn’t live up to their promise. Constraining the entire post to a single format was not useful, save perhaps for create a link blog. Over time, its appearance in the post edit user interface diminished.
Adding style formats to the editor allows the user a means of flexible styling of elements without having to edit source code. While this is helpful, it is really an ad hoc approach that requires theme customization.
Gutenberg blocks, however, can be built to do things like Post Formats and style formats and lots more. They could be used for a single purpose like adding a “call to action” button, and accordion menu or a person’s biography using structured data. They are a blank canvas for all types of page content in an era when the straight black and white page of text has largely gone the way of the dodo.
How many hours have we all spent unraveling source code in a WordPress post because some amateur developer has tried their hand at editing raw code, or cut and paste some example they’d found on the web? The promise of Gutenberg is to eliminate some of that pain by giving editors a richer set of tools with which to create and style content.
In that regard, Gutenberg is a new platform that opens up page-level content creation far beyond what was available in core before.
Keeping Up with The Joneses
The gradual influx of very good, hosted content management systems like Squarespace, Contentful, Medium and Wix has put some pressure on WordPress.com to compete. Additionally, front end editors like BeaverBuilder and Divi have shown what can be done when page editing is re-imagined.
For Automattics’s commercial entity, WordPress.com to remain competitive Gutenberg can be thought of as a product feature. In fact, 2018 was the first year that WordPress advertising started to appear with regularity.
Whether this move will pay off remains to be seen, but it is certainly a credible challenge to the competition.
Solving a Problem That No One Had
When you present Gutenberg to a writer, you’ll get questions. Why did they change the editor? What was wrong with the previous version? In effect, who moved my cheese?
This is the rare case where I am not in favor of evolving the tools that we use on the web. While working with content blocks, I am much more sympathetic to the user, whom I cannot present a strong case that this new way of adding content is faster or better.
The best they can hope for, in the nominal state of Gutenberg anyway, is to get to a point that they can enter content with more or less the same level of friction they experienced before. That’s not progress.
While from a rich content perspective Gutenberg has the potential to be an improvement, from the perspective of a person trying to tell a story or share an idea, Gutenberg is a mass of controls, boxes, choices, animations and other user interface distraction. The kicker being that not all of them work well in everyone’s environment, though that will improve.
Adding More Dependencies
Experienced WordPress administrators, or those onto whom that role was cast, know that one of the predominant reasons that a WordPress installation is not working on one way or another (or at all in extreme cases) is that there is a plugin conflict or a bad plugin. Best practice in this regard is to limit the number of plugins.
While too many plugins is a bad idea for the obvious reasons of reduced speed and increased security exposure, for me the overarching reason is dependencies. Every plugin that you install on your site needs to be managed and monitored for changes in functionality. Each has a different author, a different website, a different support forum and, if you are paying for a premium plugin, a different schedule of renewal. All of these rob time and attention away from more important, user facing tasks.
When this concept of third party Gutenberg blocks appeared, I was taken aback. Of course, the emergence of them should have been obvious to me, since plugins like Yoast will need blocks to work in this new editor. What I didn’t foresee were blocks just for block’s sake – plugins that are just collections of blocks.
So here we have another set of dependencies simply to extend the back end editor, with many of the negatives I’ve detailed above.
It is the developer’s job to always be learning, but typically we have a choice of timeline for those efforts. The release of Gutenberg has stepped on our autonomy in that regard.
We are put in the position of having this new way of extending the editor in a way that does not use common tools simply to enhance the back end editing experience. In my opinion this is not a good use of resources and a difficult case for managers to make to their superiors.
Imagine the conversation.
“We need to take a couple of weeks to learn a library so that we can add functionality to the WordPress editor that 30 people use.”
Cracks in the Process
For the latter part of 2018, the inclusion of the Gutenberg editor into WordPress core and subsequent release became a looming concern for website owners.
While the Gutenberg plugin was available for testing, it was not yet part of WordPress core, Further, the Classic Editor, which bypasses Gutenberg in favor of a traditional editor, could not be properly tested until Gutenberg was in core.
This event, despite conversation about delay to the beginning of next year, was then accelerated, generating lots of comment, much of it negative.
Site owners had very little time to test their sites prior to release. I found it comical to read and hear conversation about “people’s websites” as if we were talking about a bunch of 20 page hobbyist websites. No, we are talking about hundreds of thousands of websites many with as many pages. This is no longer a minor platform, this is 30% of the web!
The acceleration of the release was done, in my opinion, for the worst of reasons, the ability to announce it at the annual WordCamp US. The act of the CEO to walking out onstage at an annual conference and announce a new product is the trope of big corporations, not open source projects. I think it was a bad look.
These decisions by a few that have impact on the many have caused the community to look at the project in a different light and start to question the processes and power structure that guide WordPress. That questioning is manifest in a newly launched effort to create a project governance model, briefly with, then without, the cooperation of WordPress leadership.
A casualty of this accelerated development process was accessibility. The head of the accessibility team stepped down, citing the cracks in the process to which I allude in this section’s title.
Post-release, WPCampus jumped in and started the process of conducting an audit of the accessibility of Gutenberg. This was done to fill the gap that was left by the “move fast and break things” nature of Gutenberg development.
While I don’t think that the Gutenberg editor is a terrible thing, I think its emergence exposed some real weaknesses in the open source project that is WordPress.
More importantly, I think that the consequences of pushing out the editor have the potential to be injurious in the exact ways that WordPress hoped it to be helpful – that the intended use and benefits of editing blocks will, in the final analysis, be a net negative. Will the audience that they hoped to gain come on board? Will existing site owners and WordPress.com account holders flee for greener pastures?
I see Gutenberg as a page design tool, not a content editing tool; a mechanism conceived by developers that doesn’t give enough attention to writers and how they work. WordPress staff and pundits even now prefix their posts with “Written using the new Gutenberg editor” on a post that is a collection of paragraphs without, apparently, any sense of irony.
Maybe the web is changing in a way that Gutenberg will accommodate quite well. After all, we are in the age of the one or two paragraph news story, where the content itself is subservient to the clicks and ad impressions.
But for those of us with plain vanilla websites, the path to victory is not so clear.
What about you?
I’ve been doing a lot of talking here. What do you think?