Share this:

With respect to providing type controls, to not provide responsive control it gets in the way of the underlying theme (provided the theme accounts for mobile – most now do). I think a good implementation would be to allow the user to use the customizer’s tablet/mobile controls and simply adjust the slider and the tool automatically differentiates the stored value. This would most flexible with how the customizer core also allows custom media queries to be defined by a theme or a plugin.

Originally posted my thoughts on Twitter but it would be more constructive and helpful to do so here.

First off… I like the overall direction of Gutenberg. Not a hater or critic of it by any means. I also liked the settings related to the Cover Text block in this release. With that in mind my thoughts when trying out the latest v0.9.0 release are below:

I have to wonder if there are simply too many text oriented content blocks than necessary when sometimes less is more.

For example here is what the Gutenberg editor looks like with 4 different types of text related blocks on it. There are 5 blocks total but 2 of them are actually the same type, although not in sequence:

At first glance you can’t tell what type of block they are. Which is probably fine for a visual editor. Posts aren’t typically going to contain the same text over and over again like in this example.

But it’s also not readily apparent when you hover each of them individually. There is nothing that makes you aware of the block type which would be very handy when hovering over a block without having to drill down to double check. See this screenshot:

Taking it a step further it’s also not currently obviously even when you click on a block to edit it. Unless you know the differences in the available editor icons simply by glancing at them. But the number of different types of text blocks means it’s unlikely average users are going to do so.

It’s not until you click on the gear icon to view the inspector (which may be too much of a developer term for average users but of less importance) that you can start to distinguish them based on the available settings. I say based on the settings because there isn’t a standard place where the UI explicitly says exactly what type of block it is even when inspecting it.

Also, on the subject of the “Cover Text” block… why a new block instead of adding the functionality to one of the other text oriented blocks? Cover Text by definition is a text that encodes a message. Text in a clear language that hides cipher text within it. The name may not be the best as it wasn’t clear to me what it was trying to accomplish had I not seen the v0.9.0 release announcement and knew it was a new type of text block that incorporated some visual tools for size and color.

Which brings me to my final thought on the latest release as it relates to the Cover Text block… which I like from a functionality and direction standpoint… but shouldn’t Gutenberg decide if it wants to be a post editor or a page builder? A page builder can make a good post editor but I don’t necessarily think a post editor can make a good page builder.

In fact we share lines of thinking the whole way through, with a bunch of overlap between your thoughts and this ticket: https://github.com/WordPress/gutenberg/issues/2448 — that is, no-one should have to ever use the cog to configure advanced block settings to get their blogging done. A block should be functional without that, it’s a core value.

carlhancock
2:32 pm on August 22, 2017

Good to hear. One thing I am curious about is why require clicking on the gear icon to get to the block settings is required at all when the screen real estate is available? Why not have the block settings automatically appear when a block has focus and is actively being edited?

I understand that you don’t want to require clicking on the advanced block settings to “get their blogging done…” but remember that WordPress isn’t just about blogging.

This Gutenberg UI is going to be used for far more than blogging. Which means there will most definitely be themes and plugins that add all kinds of new block functionality to the Gutenberg UI, many of which will most definitely require making use of the advanced block settings UI.

From a UX standpoint having the advanced block settings automatically appear in the sidebar when a block has focus and is being edited just makes sense and makes the advanced settings instantly more accessible and readily apparent. Attempting to cram everything into the inline block editor won’t be realistic for the vast number of uses cases that WordPress is used for well beyond simple blogging.

With the Save/Publish button moved out of the sidebar the document sidebar settings becomes something that won’t have to be utilized as often… which means that screen real estate could be put to better use by becoming contextual and showing settings related to what has focus by default vs. always displaying the document sidebar settings persistently by default.