The first time I heard about Gutenberg was in early summer of 2017 when Matt Mullenweg announced the project at WordCamp Europe. Moving beyond the WYSIWYG editor, this new content editing experience would break content into blocks and allow for modular building out of website content. Essentially, it would give more power to those working with content and allow them to have much more flexibility while still requiring zero coding.
What was wrong with the old system?
One of the biggest complaints we hear about working with WordPress is how difficult it is to affect layout if coding isn’t your strength. The old core experience with WordPress was indeed quite limiting in terms of what could be done. If there isn’t a “simple” option for changing aspects of the layout then clients have to call their friendly web agency to help.
Seeing as our approach to web design is modular we’ve worked around those limitations to give our clients a content editing experience that did allow them to craft content in a much more flexible way using custom meta fields. Of course, this meant that each website we worked on would get its own, customized set of content blocks and shortcodes to work with (shortcodes… that’s a whole ‘nother discussion), along with building out any layout options that made sense for a specific project. All of this reflected in our projects’ price tags.
From this perspective, I was definitely happy to hear that WordPress was listening to its users’ needs and working on a more flexible and modern editing experience. Of course, this did bring up questions about maintaining design quality and those questions seemed to have been considered by the Gutenberg team – we would be able to have control over how much users could customize individual blocks and which blocks would be available to them. Glorious!
How is the new system measuring up?
On 6 December 2018 WordPress 5.0 was released and Gutenberg became part of the core WordPress experience. Those using the old experience have a few years to figure out and implement strategy for migrating to the new system while using the Classic Editor plugin to continue using the old WYSIWYG editor.
Fast forward to 6 March 2019 – how have the first three months of using Gutenberg in production changed our website design and development process?
Design & Development
From a design standpoint, we’ve been creating modular work for quite some time now. Using Gutenberg gives us an out-of-the-box way to implement many building blocks that are common to online content. For example, blockquotes finally have a citation field, we can easily create multi-column content. For many of the blocks that now come standard with WordPress (core blocks) all we have to do is adjust the CSS to match our mockups.
For creating custom, more complex blocks, we love using Ahmad Awais’ developer toolkit and would recommend it to anyone who learns best by being hands-on.
One approach that we’ve really taken advantage of is nesting blocks. For example, if you’d like to create a “highlight box” block, not only can you create it but also allow users to use specific blocks inside of it. This also comes in handy in situations where we might have used a repeater custom field approach in the past. Setting templates by post type is another Gutenberg feature that we’re big fans of.
Let’s talk about things that we wish were a bit different or just better implemented. For one, the promise of having lots of control over block settings has definitely fallen short. While there are some simple ways to, for example, limit or remove custom colour settings for blocks that use them not all settings are as easy to control.
For example, each paragraph comes with a drop cap option – turn it on and the first letter of your paragraph turns into a drop cap. Now, I could see that this might a fun feature for an average blogger to play around with but when we create carefully crafted designs for a client – if they don’t use the drop cap feature we don’t want to confuse the client by offering that feature to them. Nor do we want to spend our time (and the client’s budget) on implementing workarounds. It would be much more preferred to be able to just turn it off with the same ease as some of the other block settings.
Having been in the WordPress ecosystem for over a decade means that we’re used to having to create workarounds, our own custom solutions for implementing complex and non-standard features. We’re also used to a phase-based rollout system. So it’s not really something new to have to deal with a certain amount of limitations. We would, however, love to have better documentation. Yes, there’s a handbook with a few working examples of complete block code, but it’s not a pleasure to navigate and it could use many more complete examples.
Here’s really the biggest problem we see with Gutenberg because we can build out all the things but if the folks working with the editor aren’t enjoying the experience then it’s really not worth the hassle. The good news is that if all you’re adding are paragraphs, links, and lists – then the system works great and you shouldn’t have any unpleasant experiences. However, get a little more complex for example, add a columns block and try to change the number of columns in said block, and things get significantly more frustrating. Another example is trying to highlight all the text in one block vs. all the blocks in your page/post. What actually gets selected when you hold down cmd/ctrl+a isn’t consistent.
In terms of accessibility, plenty has been written about a11y concerns and Gutenberg ( this article by Andy Bell is a great place to learn more) but the gist is that there is much more work to be done before this new editing experience is actually a feasible option for all.
The bottom line… for now
Gutenberg is a work in progress, there definitely bugs to be worked out and improvements to be made. But it’s already very promising addition and improvement to how we are building sites for our clients. We’re able to devote less time to building out basic content blocks through adjusting their style via CSS but we’d love to see more straightforward control of block settings and more complete examples in the handbook.
Creating custom blocks definitely comes with a bit of a learning curve and, again, would be great to have up-to-date, complete examples to work from. There’s also lots more work to be done in coming up with best practices for structuring and organizing block code. For now, our approach is a mixture of custom blocks and custom meta fields for easier maintenance.
What we’re really excited about is how easy it will be for those maintaining the content of sites using Gutenberg to be creative while weaving a story. The operative word here is “will” because for now, there are still lots of usability and accessibility issues.
Our prerogative is to be cautiously optimistic, the promise of Gutenberg is a great visual experience for content editors and a way for those of us with coding skills to customize that experience – it will take time to fully implement all the features required to make that promise a reality. For now, we’re working with our clients to make sure that we fill in the gaps while taking advantage of the opportunities Gutenberg already offers to make life easier for everyone involved.