Thoughts on Gutenberg

Several people have already posted their thoughts and impressions about the new Gutenberg editor for WordPress, to highlight pros, cons and everything in between. Here is my perspective on it.

What I love about Gutenberg

  • I love that it’s a solid take on introducing a much improved version of shortcodes. Shortcodes have terrible UX, especially without the Shortcake plugin (and the requirement that each plugin adding a shortcode needs to support it). Blocks require all that UI to be there out-of-the-box. Furthermore in most cases the block content will still show properly even if a specific block type is not available anymore, for example when the plugin registering it has been deactivated. There will still be some cases though where blocks require some PHP to run (for example the “Latest Posts” block), and for those blocks the problem will still persist in a way. There need to be clever “pure-HTML” fallbacks for those to still show useful content (if possible).
  • I love that everything is stored in the post content, so the frontend will just work out of the box without querying lots of data from other database tables (except in custom PHP blocks possibly, but that’s unavoidable). There is a downside to this which I highlight in the second part of this post.
  • I love that it finally allows me to create page builder-like layouts without all the bloat every page builder adds. I consider everything bloat that does not deal with the actual content – to me there shouldn’t be any page builders, but content builders. A site’s layout and design should be determined by the theme. That may be a strict view, but opening up endless possibilities is quickly gonna make a great theme look terrible. And eventually slow as well. Gutenberg allows me to focus on the content, and only the content.
  • I love that the controls are contextual to each block type and are displayed right where you need them.
  • I love that there is now a fixed toolbar at the top that allows me to tweak critical settings, save, publish and more without needing to scroll back to the top.

What I’d love for Gutenberg to support

  • I’d love for Gutenberg to support Markdown. The current WordPress editor supports a tiny subset of Markdown, and Gutenberg does not even support this. But I personally don’t care about that subset, I would love for Gutenberg to support the entire Markdown specification. If you only want to write a regular post that consists of text, it would be awesome if that was achievable without even using the mouse. I just wanna type ## and make that a heading. More complex interactions like inserting custom blocks require a mouse (or more complex keyboard navigation), but the simple stuff should all work streamlined, with Markdown.
  • I’d love for Gutenberg to have some kind of (redundant, at least kind of redundant) storage system for block data that one would wanna query by. Currently any custom content for a post is stored in post meta, and that can be queried. Yeah I know that meta queries suck, but it still can be queried. If you input some block data though, you can’t specifically query for it as it’s just somewhere in the content. To be clear, not everything should be stored. Just very very few things. But it would be nice for a block type to somehow register a specific field so that its value would be stored as post meta under a specific key. Especially as Gutenberg is diminishing the priority of custom meta boxes, I still wanna be able to handle the essential meta.

What I’m worried about with Gutenberg

  • I’m worried about Gutenberg’s accessibility. It’s quite terrible. While I haven’t tested it myself, there are numerous posts by accessibility experts who I know know their area incredibly well. A few members of the accessibility team are helping out there now, but as far as I heard from them, the project is at a stage far too advanced for accessibility to become a priority. At this point, it is just about fixing whatever small things can be fixed, but a generally accessibility-driven development would have certainly given a better result. I really hope that the a11y team is able to rescue the project for that matter, otherwise I’m afraid that Gutenberg is locking people out, which is a scary thought considering the importance and philosophies of the WordPress project.
  • I’m worried about that writing a simple post without special blocks or layout becomes harder. Gutenberg is no longer the Office-like editor everyone is used to from their day-to-day software. It is much more powerful, but also more complex especially for people who are not very tech-savvy. At least for those who are, adding support for Markdown (see above) would help a whole lot – but that’s obviously the minority.
  • I’m worried about Gutenberg feeling like a foreign object in the WordPress admin to me, although I honestly like its UI. I don’t think there is anything we can do about it, but I think there should be efforts starting soon to look at how we can use similar UI patterns for completely different screens. Not a problem specific to Gutenberg, but a result of introducing something completely new as it is.
  • I’m worried about that a lot of the Gutenberg project does not seem to care about backward-compatibility. I’m not opposed to the idea of ditching the necessity for it in cases where the benefits would be crucial enough, but several factors that have always been critical for WordPress core development have been overlooked so far. Custom meta boxes are heavily used by thousands of plugins and themes. They’re usually bad UX, but I’m afraid blocks are not the proper solution for everything either. It’s also unclear at this point what the migration path is going to look like. Another open question: How is Gutenberg gonna integrate with custom post types? Many custom post types do not even support an editor, so what is the edit screen with Gutenberg in there going to look like? Or will it just fall back to the old one (inconsistent)?
  • I’m worried about user expectations. With Gutenberg becoming the new editor and without any way of disabling it I can see millions of users wondering where their beloved editor went. Not because it’s better, but because they’re used to it. And I think there will not be a way to disable it. Note that you can currently disable the visual editor, so I’m not sure what the benefits of dropping that control would even be (“Decisions, not Options”, right, but at some point a decision might just be too big to not be an option).
  • I’m worried about the project being too rushed. Rumors are that it might go into WordPress 5.0, which is probably going to be released within the second half of the year. I’ve also heard there are plans to merge it into trunk in August already. Given all the issues there are, both major and minor ones, I think that is way too early. It’s great that it is available as a plugin now, and I’m happy there are plans to nag WordPress users to try it out (hopefully coming in 4.8.1), at least to get used to it. The new editor must be announced big, way ahead of its actual release so that people know what’s coming. Probably also good for marketing to get them excited. Or scared.
  • I’m worried about the Gutenberg ecosystem being too small at the time of its release. For it to be beneficial, we need thousands of plugins to write custom block types for their functionality. I hope at least the most popular ones manage to get theirs out in time. On another note, the list of block types might get very large over time which will make it cluttered. Maybe there is a better way of listing all the available block types, to give a better overview. The current way works pretty well for core now, but there will be many, many more block types at some point. Oh, and we probably need several themes to adapt new CSS classes for their stylesheets as well.
  • I’m worried about how Gutenberg exactly helps WordPress users. It is unclear in how far the project is based on user research. Has Automattic run surveys, tests or other research? Have they looked at the popularity of page builders and thought WordPress needs something in that direction, just in a much better way? Is it just about WordPress.com competitors? I don’t know the response to any of this, and that is why I worry about it.

Conclusions

While I have listed more negative than positive bullet points, I generally am fully behind the project. A WordPress editor supporting creation of more complex layouts (finally in a user-friendly and more stable manner) will greatly reduce the requirement of some kind of page builder for several people – of course not for all, but those people probably do not care about separation between content and design, or are stuck for legacy reasons.

I am however worried about some of the decisions that have been made early in the development process. The major workforce behind Gutenberg are mostly people who are not (or at least have not been) contributing much to WordPress core, so chances are they are not as aware of some of the philosophies and processes involved (they’re great developers and designers though, to be clear!). At this point, several core people have jumped in to help out and align the project more with the requirements and best practices we have had for feature projects, but communication between the Automatticians behind the project and interested core people should have started a lot earlier in my opinion. Now people need to fix what has been done in a wrong way instead of doing it right from the start.

But I wanna stop moaning now. I’m excited for Gutenberg, and I hope the team and everyone else involved in the project will succeed in fixing all the still-unsolved problems with it. But those who directly contribute code to Gutenberg are not the only ones who need to do something. You can help too! If you haven’t tested it, I encourage you to do so. If you find a bug, I encourage you to file it or even fix it. If you have access to a lot of possible testers, I encourage you to spread the word, and even better, start a survey and publish results. If you are a plugin developer, I encourage you to start creating a branch for implementing block types for your plugins. If you are a theme developer, I encourage you to follow up for which CSS rules and other things themes may need to implement.

If you have some news that contradict with anything I said above, please let me know. I’m happy to review my opinion. I’m also curious what you think about Gutenberg, so I’d be happy to read a post with your thoughts on it. Let’s all do what we can to make it a success. I’m sure we can make it happen.

3 thoughts on “Thoughts on Gutenberg

  1. Hey!

    You touch on it a bit, but I think we should not underestimate the amount of custom post types that are not “post-like-ish”.
    Therefore meta-boxes are the way this post types get a user interface in the first place. Some plugins put bad interfaces in this but they are very important if WordPress want to be a CMS. Structured data are important to many projects, so user should not put data randomly into blocks on a page.

    I love the concept of blocks. I love the shortcake-UI-plugin for the same reasons. But there is more then one column of blocks. As long as the editor don’t lives in the frontend some users will still struggle with the two (or three) different views (edit, view (customize)). “Why does my image on the website doesn’t show in fill width. In the editor I made it do that.” and so on …

    The current status on the Gutenberg project is very blogging, single-column or even WordPress.com focused and maybe it should stay as a plugin.

    Greetings
    derRALF

  2. But it would be nice for a block type to somehow register a specific field so that its value would be stored as post meta under a specific key.

    This is planned for. Sourcing block attributes from meta is simply just not implemented yet. One core block where it would make sense is a Featured Image block (which one also be useOnce).

    How is Gutenberg gonna integrate with custom post types? Many custom post types do not even support an editor, so what is the edit screen with Gutenberg in there going to look like? Or will it just fall back to the old one (inconsistent)?

    Custom post types, as well as page templates, could essentially be set configurations of blocks. A product post type, for example, could require a product-variations block and product-pricing block. If “content” is not supported by a post type, then the inserter could essentially be disabled with only placeholder blocks displayed, prompting users to provide the missing details. The blocks could be displayed in the same editor area as when content is supported by a post type, however.

Leave a Reply

Your email address will not be published. Required fields are marked *