Gutenberg 12.2 focuses on user experience improvements – WP Tavern
Some versions of Gutenberg plugins look like heavyweights with new features aimed at users. Others, like today’s version 12.2 update, fix issues and create a more complete experience.
Switching between the site editor and the templates is smoother. The color picker is no longer a hot mess. Additionally, border controls now use the tool panel approach allowing users to enable or disable options they want.
Contributors have made progress on updating the Comments Query Loop block, which will eventually be the backbone of displaying comments in block themes. One of the biggest hurdles was getting nested comments to work. With that now fixed, moving forward with other commenting-related components should be less of a problem. The latest version also introduced the Comment Paging Numbers block for managing paginated comment lists.
View models without page reloading
When Gutenberg 12.1 launched two weeks ago, I was happy to see the new and significantly improved sliding panel in the Site Editor for showing templates. My main complaint: it was slow. Switching between editor view and model view required a page reload.
In the latest version 12.2, everything has changed. With client-side routing in the site editor, the transition between the editor and models is quick and smooth.
Changes like this are one of the reasons I welcomed the postponement of WordPress 5.9 until the end of January. Some of those little wrinkles needed ironing out before showing the site editor to the world.
Improved color picker
Gutenberg 12.2 introduces a much improved color picker. The previous iteration was heavy, cumbersome to the point of being a nuisance. Users would have to scroll and scroll and scroll a bit more just to switch from changing the color of a block’s text to the color of its link. This was especially true if the theme showed both its colors and those of the core.
The latest iteration strengthens the user interface to the point where users can see text, background, and link color options at the same time. If they want to customize any of them, they can click on any of them to bring up the color picker pop-up.
Maybe this change will open the door to other color options in the future, like one for hover / focus links. It would have been way too complicated in the old user interface. However, the new minimalist design leaves enough room.
I would love to see border color control receive the same treatment. However, there is a separate ticket that offers more precise control.
Changing the font size
The font size control for supported blocks is quite different. It displays a list of numbered buttons for themes with five or less custom sizes. The name of the font size appears when selected. Otherwise, it is just a list of numbers without context.
I generally liked the progress made towards updating the block options UI. But I’m not a fan of this change. As a user, what do these numbers mean? Is size “1” small or medium? There is no way to find out without testing it. In addition, the context will change from one theme to another. A UI change like this might have been acceptable on the back of a standardized naming scheme. However, this will be difficult to implement after three years of use.
In general, clicking a single button seems like a better experience than clicking a drop-down list, followed by a second click to make a selection. I’m not sure it works here. However, I’m open to seeing where that leads to at a later iteration.
There is also no visible way to clear the current selection and revert to the default size. If the theme supports custom sizes, users can switch to the “Custom” field and clear it. It’s not obvious unless you stumble upon it. Users can also click the âReset Allâ button, but this resets all typography options.
The easiest way to avoid this UI change is for theme authors to save at least six custom font sizes. The option will automatically revert to its old drop-down selection field. Luckily I have 13 in the theme I’m primarily working on, so that’s not a problem for me.
Block Pattern Piece Hooks
Theme and plugin developers now have additional action hooks around the block model part system. These should come in handy for debugging or other complex use cases.
render_block_core_template_part_postfires when a part is found in the database.
render_block_core_template_part_filefires when a part comes from a theme file.
render_block_core_template_part_noneis triggered when no part is located.