Let’s talk Gutenberg
No, not the printing press or the bloke who invented it a few hundred years ago. The new WordPress editor that’s now available WordPress 5, which aims to replace the crumbling old TinyMCE layout with a more modern, block based alternative.
It’s a big project, and it’s one that’s gotten a mixed reception throughout its development cycle. Some people love it and consider it the future of WordPress. Some dislike it to the point they made a fork to get rid of it (ClassicPress).
And some people are either on the fence or simply annoyed by quickly Automattic are rushing it through development.
Hence for my latest site build, I tested it. In that time, I looked at the following three things:
- Whether it’s convenient (or generally better) for the user
- What developing blocks and plugins is like, as well as the status of the add on’s documentation
- As well as whether the system is truly ready to be integrated into the core
The latter’s a bit late given the editor is now in the WordPress core by default, but it’s an important question to raise none the less.
Let’s see how this new editor stacks up!
Is Gutenberg Better for the User?
Starting with the million dollar question that Gutenberg needs to answer to become successful. Namely, does it make editing posts any easier or more convenient for the user?
Because that’s really why it was developed. TinyMCE was neat and all, but it wasn’t great on a smartphone, it didn’t really work with modern tech too well (like in the iPhone/Android app) and it didn’t stack up to the likes of Medium or Squarespace for an editing experience.
It was a relic, and one which Gutenberg could have worked really well with as a replacement.
Alas, that’s not the case. Instead, Gutenberg is honestly a bit of a nightmare to use as an average user.
And that’s because at its core, the system is somewhere between a post editor and a site builder plugin. It’s a series of blocks you can use to build pages, with things like headers and images all being separate entities you can move around the editor as you wish.
But that’s not how people write posts. It just isn’t.
Instead, my experience is that most people who write (on a serious basis) tend to write their posts somewhere else before copying them to their site or service account. That may be Microsoft Word or Google Docs, it may be some other online writing platform. Who knows.
Point is, they don’t sit there with the editor as their primary writing tool. It’s really just a way to clean things up after a quick paste or so.
And Gutenberg kinda kills that flow stone dead. With every element being a block, it’s not convenient to just copy content over from another tool.
Instead, you’ve basically got to rewrite everything in the new editor, or deal with the thing trying to guess what blocks you want to use. It’s annoying, and it doesn’t really work too.
Additionally, it makes you question why a post editor uses blocks at all. Think about it, do you think of writing in terms of content blocks?
Because I sure don’t. I don’t think of paragraphs as separate entities that can be moved around at will, nor do I think of things like images being separated from the text or headings being separated from both. They’re just part of the same entity, and they’re the type of thing you usually add as you go along.
Add to this some glitchiness and accessibility issues, and you’ve got an editor which may feel like utter overkill for your average Joe blogger.
Still, it’s not useless. There are two or three use cases for Gutenberg which feel logical enough, though they’re arguably all ones the development probably didn’t think much about in the planning process.
Use case 1 is the static site with complicated page layouts. In this case, Gutenberg can let the development team create a couple of blocks (with things like left aligned images and right aligned text, pull quotes, etc) and have the content team updated without needing any programming experience.
That works, and in my experience (as someone who’s building a site with exactly that design philosophy for my current employer), could well be Gutenberg’s best use. It just fits as a page builder, and with a bit of tinkering, can work decently enough for a heavily compartmentalised, component based site.
It can also work for large news publishers who like more complicated layouts yet don’t like having to train their staff to work with an unwieldy form based editor. For example, the likes of the BBC or the Guardian or Vice may find a use in Gutenberg, since their articles are often littered with parallax effects and full screen image blocks, and their current editors are… pretty dire to say the least.
Seriously, I know. I’ve worked in a similar organisation, and heard through the grapevine that their story editor was complicated enough that new staff needed days of training to figure it out. Even the data the thing eventually spat out was a JSON array about 100 items long.
In that sense, Gutenberg seems like an ideal fit. At least with blocks you could keep the pointless stuff behind the scenes and give people a visual indication of how their story will look afterwards rather than a ten page list of form fields with tiny labels and hordes of data.
Finally, if you’re the type of person who sets up every single CSS class before you begin work (yes, they exist), I guess Gutenberg may work there too. Build a bunch of blocks, style them as you will, spend less time worrying about whether your 3000 lines of CSS code looks the way you want it to halfway through development.
But it’s not for the everyman, and marketing it is as thus is a bad idea.
2. How is Gutenberg as a Developer?
Still, enough of the user perspective for the moment. What about developing for Gutenberg?
What does that feel like?
Honestly, I’d say it’s a bit confusing all round.
And that’s all because for whatever reason, Gutenberg went through a lot of changes in development at a very rapid pace. To the point that one whole set of documentation was seemingly just kicked to the curb because of it, with the top results for many terms in Google returning a 404 error because WordPress and co decided to replace everything and not redirect diddly squat.
This also means that any older articles about the software (read, anything from before 2 months ago) are now also incorrect as well. So now almost all the top results for Gutenberg tutorials will require you to do additional research simply because the demo code is wrong and will cause errors if copied into your own project.
It’s a pretty bad situation all round really, and means that something that’s actually not too hard to get the hang of (when you do figure out what’s relevant now) is rendered a confusing mess that will inevitably cause no end of problems for newer WordPress developers.
It’s also one that’ll make for quite the agency culture shock in the next months too, since Gutenberg basically tosses everything you know about WordPress development out the window. That’s because Gutenberg is almost entirely JavaScript based, with React being used as the main framework. In itself that’s not too bad, but come on.
You know full well that most WordPress developers are not JavaScript pros, as well as that many of them don’t really know much about programming on a level beyond ‘make use of WordPress built in functions and documentation like a religious Bible’.
For these people, going from basic HTML and CSS (with a bit of basic PHP and JavaScript thrown in) to JavaScript + React framework + Webpack + potentially Redux is gonna be one hell of a shift, and probably one that’ll mean hours of developers pulling their hair out in frustration come January 2019.
And you know what? It genuinely makes us wonder whether that may be the point.
Cause for good or bad, WordPress doesn’t exactly have a great reputation among programmers and software engineers.
In fact, it’s garnered a bit of a reputation as the ‘noob’ solution, the script people use when they’re not particularly good at programming but want a complex site overnight. The type small development companies and contractors who could barely solve a fizzbuzz test use.
So at least part of me wonders whether the JavaScript shift there (and with modern WordPress features in general) is a sneaky way to try and both scare said lower skill developers away and lure over folks from companies with more trendy development stacks like Google, Facebook and Airbnb.
Eh, probably not. But it’s still a shock to the system none the less, and one which will probably be a bridge too far for many developers.
Hence in answer to the question, it’s not that bad to develop for, but the sheer level of differences between core WordPress and Gutenberg block development will put off a lot of beginner devs, and the lack of good documentation will hurt even the more advanced ones.
Still, onto the last question now.
3. Is Gutenberg Ready to be Integrated Into Core?
No
No it is not.
It’s not quite as bad as people have said it is, and it doesn’t really justify forking the software like the folks at ClassicPress believe.
But it’s 100% not ready to go live any time soon. It’s poorly documented, it’s buggy, it has a fair few problems with accessibility and basic UX design and overall, it’s just not right for the majority of WordPress users.
Which is why it’s incredibly disappointing that Matt and the Automattic team have merged it into core already. It’s just not ready yet, and the lack of care put into things like accessibility and decent UX design are going to leave a horrible impression on people new to the software.
But that can all change. So in my opinion, the best thing they can now do is to support the release as well as possible, lay out a clear roadmap for the future, and then ask themselves the following question:
Who is this for?
Because unfortunately for some, it’s not ideal for average Joes writing their blog posts. It’s too complicated for that, and it doesn’t make standard posts any easier or more interesting to write.
But there is an audience in the page builder market, and that’s really when Gutenberg can shine. Focus on it as a static page builder, and enable it only for pages by default. That way, those who want to take advantage of its capabilities for static content can use it in the best possible light, whereas those who don’t can stick to what already works until the bugs are ironed out and the design made more usable for standard blog posts.
Still, those are just my thoughts on the matter. Will Matt agree? Will Automattic agree?
It’s hard to say really, and we can only just sit back and watch what the future holds.
