Re-grouping Editor Inserter Menu

[shinyabw]

Describe the bug

Hi. I am one of translation contributors for ja. I was originally troubled by how Most Used Blocks and Common Blocks mean very similar in Japanese.


Even in English-English dictionary, it says:

Most = greatest in amount.
Common = occurring, found, or done often.

I thought about requesting to re-name Common Blocks to Essential Blocks or Standard Blocks. However, I realized the issue was more to do with grouping of Editor Inserter Menu.

I realized that I am having hard time navigating through Editor Inserter Menu as a user because the menu is not grouped by “attribution”.

Editor Inserter Menu Right now grouped this way:

Group Name	Blocks
Most Used	(Most Used Blocks)
Common Blocks	Paragraph, List, Image, Heading, Gallery, Quote, Audio, Cover, File, Video
Formatting	Code, Preformatted, Classic, Custom HTML, Pullquote, Table, Verse
Layout Elements	Separator, Button, Columns, Media & Text, More, Page break, Spacer
Widgets	Latest Posts, Shortcode, Archives, Categories, Latest Comments
Embeds	Embed, WordPress, Twitter, YouTue, Facebook, Instagram, etc.

My suggestion, grouping by attribution.

Group Name	Blocks
Most Used	(Most Used Blocks)
Text	Paragraph, List, Heading, Quote, Pullquote, Verse, Button, Preformatted
Media	Image, Gallery, Audio, Video, Cover, Media & Text, File
Layout	Table, Separator, Columns, More, Page break, Spacer
Embed	Embed, WordPress, Twitter, YouTue, Facebook, Instagram, etc.
Widget	Latest Posts, Shortcode, Archives, Categories, Latest Commetns
Code	Code, Custom HTML, Classic

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Editor Inserter Menu'
2. Plese use it

Expected behavior
In order to find blocks easily, Editor Inserter Menu needs to be contextualized.

Screenshots

Desktop (please complete the following information):

• OS: [Mac 10.13.6]
• Browser [Firefox]
• Version [63.0.1]

Additional context

• 4.2.0-rc.1
• WP.org shinyab

[brandonpeat]

Agree 100% both with the naming of Most Used / Common and the assessment of how to restructure the blocks by attribution/context.

[mtias]

Thanks for the thoughtful proposal. I agree with your overview and that "Common" blocks can be a bit opaque. I like having a group for "Media" but there's some overlaps with "Text" that need a bit more thinking (is "Media & Text" media or text? What about "Cover" used without a bg image and only a color and some overlay text?). Likewise "Button" feels a bit off placed in "Text", but these are just a matter of placement.

The next phases are going to be bringing a lot more blocks into the picture, so it might be helpful to revise at the same time.

[mapk]

Really great proposal, @shinyabw! I've often fumbled through the groupings in the Inserter as well. They just don't map to my mental model. I like how you've presented this and would like to get some more feedback on this before making any changes. cc @melchoyce @kjellr @jasmussen.

On another note, we now have a Block Manager merged (#14224) into the code. I'd like to include the ability to rename the categories in the Inserter, or create your own, and move blocks between each category as you like. But that's a ways off.

[melchoyce]

I generally like the regrouping, but we'll need to address @mtias' feedback about the blocks that intersect between categories, like Cover and Media & Text.

Some ideas:

1. Combine Text and Media into one larger category, perhaps still called Common elements
2. Cross-list overlapping blocks in both categories
3. Find a new category to list the more art-directed blocks

If someone has the time and resources, this would make for a good card-sorting exercise. Maybe at WCEU, if we have a Gutenberg table?

[kjellr]

I like this regrouping, and also agree with Mel that it might make sense to merge the "Text" and "Media" together into one.

[mapk]

I like having a group for "Media" but there's some overlaps with "Text" that need a bit more thinking

@mtias maybe any block that can incorporate "media" should fall into the "Media" grouping (ie. Media+Text block and Cover block), unless that block's primary focus is text.

As for the Button block, that's a bit more tricky. I don't mind leaving it under "Layout" since that's where it exists today.

The Classic block also might need a better group than "Code." It doesn't feel like a code-related block necessarily.

Should Preformatted block move to the "Code" group? I left it under "Text" for now.

Group Name	Blocks
Most Used	(Most Used Blocks)
Text	Paragraph, List, Heading, Quote, Pullquote, Verse, Preformatted
Media	Image, Gallery, Audio, Video, Cover, Media & Text, File
Layout	Table, Separator, Columns, Section, Button, More, Page break, Spacer, Classic
Embed	Embed, WordPress, Twitter, YouTue, Facebook, Instagram, etc.
Widget	Latest Posts, Shortcode, Archives, Categories, Latest Comments, Search, etc.
Code	Code, Custom HTML

[melchoyce]

@mtias Want to chime in on this one?

[davewhitley]

"Text & Media" sounds like a good group name, but here is already a block with that name.

[earnjam]

One thing to keep in mind here when it comes time to actually build this change is how it will affect any plugins that have built blocks that are assigned to categories from the current list that will no longer exist.

Some of them map nicely 1:1 so we could account for that and handle it automatically (embed, widget, layout). But others will be less clear. Example: Should a block in the formatting category be moved to text or to code?

[boemedia]

Thanks for bringing this up @shinyabw. +1 for regrouping into something that makes more sense. I like what @mapk , but would also love to see that card sorting session happening at WCEU. Maybe as part of the user test table? Are the blocks as mentioned above all the current core blocks?

Btw I'm also mostly confused that embedded video's require a different block than video. I also wonder how we are going to deal with third party blocks. Can the developer choose to place them in one of the standard groups, or will third party groups be added as a different section by default?

I know we cannot influence the behaviour of third party's, but I think we should take them into consideration as we think about the way the inserter menu is organised, to prevent the same plugin mess as in the WP-Admin from happening here too.

[earnjam]

@boemedia Third party blocks must be assigned to a category when registered. They can either be placed into one of the existing core block categories, or a plugin can register its own block categories and place blocks into those.

What I'd be concerned about is a third party block that has been registered for a category that goes away after this change, such as Formatting.

We'd probably need to automatically filter/remap those to a different/new category and maybe also throw some kind of console warning to notify the developer that they are using a deprecated block category.

[mapk]

I also wonder how we are going to deal with third party blocks. Can the developer choose to place them in one of the standard groups, or will third party groups be added as a different section by default?

Great feedback, @boemedia! Thanks. As for 3rd party blocks, developers can create their own Block Category in the Inserter similar to Jetpack.

OR just add their blocks to one of the other categories.

[melchoyce]

Love the idea of card sorting at WCEU, @boemedia

[boemedia]

Uh uh it was your idea in the first place ;) Op di 11 jun. 2019 om 22:44 schreef Mel Choyce <[email protected]>

Love the idea of card sorting at WCEU, @boemedia <https://github.com/boemedia> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11406?email_source=notifications&email_token=AHDD7FS72UQUF46FAHOLXVTP2AFDDA5CNFSM4GBOO6B2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXOOIIQ#issuecomment-501015586>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHDD7FUFV5VDGY6DGZIZJG3P2AFDDANCNFSM4GBOO6BQ> .

-- Hartelijke groet, Monique Dubbelman BOE!media [email protected] +31624500428 Mooi rood is niet lelijk: 7 tips voor het kiezen van de juiste kleuren voor je website of app <https://www.boemedia.nl/mooi-rood-is-niet-lelijk-7-tips-voor-het-kiezen-van-de-juiste-kleuren-voor-je-website-of-app/>

[MariusKauer]

I am toying with the idea that one of the groups should be called "interactive" or something similar that would combine - for example - the button, interactive media blocks (eg. a 3rd party Slider block or the form selector for Gravity Forms) and maybe even embeds like Instagram. I am a bit torn about the last part, because I generally like the "Embed" category and it makes perfect sense.

Just a thought I wanted to get out there :) Even though there aren't many Core blocks that would fall into this category, I see many 3rd party blocks that would perfectly fit into "Interactive".

[ellenbauer]

I think it's a great idea to only use "Most used blocks" and put the other blocks into other categories.

In my opinion the "Preformatted" block should go into the "Code" category.

I think the "Button" block is not perfectly located in the Layout categories, but I don't know if the "Text" category is a better fit. Do you plan a further new category at any time? Maybe "Interactive" for buttons, forms would be interesting in the future.

[rralian]

I offered some fly-by comments and @mtias asked me to share them here. I haven't been involved in development so forgive me if I'm missing context. Although I do use Gutenberg almost every day and I know and hear about the plans. So I should have more context than the average user.

I also find the current categorization confusing and difficult to navigate. Totally agree with dropping either "most used" or "common blocks" because having the same blocks in these two big categories is very confusing to me. I don't know if "most used" is most used by me, by others, is it algorithm-driven, is it arbitrary? As a user I don't really care. I just get confused seeing the same blocks in different places and it discourages me from looking further.

@shinyabw I wasn't clear what you mean by "attribution" in your original text ... I would have thought that meant by plugin (i.e., attributed to a certain author or plugin) but your example doesn't seem to follow that. Maybe the term has a special meaning for Gutenberg blocks that I'm just not aware of.

But from a user point of view I would prefer grouping by functionality. Widgets and embeds are not really functions, they're the underlying technology. And as a user I don't think I should have to know or care about that. I would like all of the options for a particular function (say image galleries) in a single place so I can compare them. As it stands I think I may possibly see them scattered between "most used", "common", "media", "widgets", "embeds", and any number of other plugin categories. I definitely like the idea of third-party blocks being encouraged to use functional categories (though understand sometimes they'll need their own). I think users shouldn't have to think about the technology/jargon behind it (widgets/embeds), the business relationships (third-party plugins), or other WordPress-isms when they're looking for a block that does a particular thing.

Last bit, which isn't about categorization but I'll mention here, I'd personally like to see the choices presented in a much more compact format. Looking at non-WordPress block selectors I can see many more items and categories at once and I can more easily navigate and find the one I want.

Hope that's useful! :-)

[pablohoneyhoney]

I haven't been involved in the development so excuse me if I don't have all the context. Chatting with @mtias I've explored quickly some options that could help.

Basic principles used in the new alternatives:

• Reduce cognitive load as this appears in a context of lots of decisions and UIs around it.
• Humanize the language as possible using familiar terms to a diverse set of users.
• Align with user expectations from other environments, products and services.
• Clear taxonomy and association of terms and objects.
• Scalable in a growing ecosystem of blocks.
• Extend to other languages. I stretched it in Spanish though some concepts don't even need to be translated, it was just a quick test. Maybe worth to try in different languages.

Here the recommended option

Here side by side

Here other explorations

[kjellr]

This seems like a really positive direction, @pablohoneyhoney. I particularly like:

• The distinction between Text and Media. This seems really natural.
• The "Interface" section for layout and more pure UI elements. (I wonder if "Media & Text" would fit more with this area?)
• The "Blog" section. It makes a lot of sense to separate these blocks out into their own category. Folks with a blog will know where to find them, and folks without a blog will know to safely ignore them.

The only hesitancy I have is placing all of the Embed blocks within the Media category. They technically make sense to be there, however there are a lot of them, and I worry that it'll be tough for people to scroll through all that to get to the Interface blocks.

[mtias]

They technically make sense to be there, however there are a lot of them

This was my worry, too. I wonder if a lot of the niche ones could be hidden by default. Or maybe we move some of the most common ones to media (like YouTube) and still leave others in Embeds?

We still control order for core blocks, so we wouldn't have a very niche embed be presented before "Gallery". However, for 3rd party blocks that can be an issue.

[jasmussen]

Dig that, Pablo, very nice work. Less is more, and this seems like a nice refinement. We can't enforce those simpler labels for 3rd parties, of course, but leading by example is a great step forward.

I would also echo Kjell and Matías concerns about the embeds. For better or worse, by whitelisting and providing embeds for 3rd parties, we effectively choose already. So there's no reason not to sort those embeds by some measure of popularity also, and I do suspect people expect YouTube to be in Media.

Unrelated tangent: this simpler look might actually afford the color that 3rd parties have been putting into their category icons, which was recently made grayscale — perhaps we can let those colors shine through again in this simpler configuration? The primary thing about the grayscale icons that hasn't worked well in practice, is that it's not the same gray — it's just a desaturated icon.

[mtias]

Let's get this moving. I reviewed the different suggestions and made a few tweaks.

Category	Blocks
Text	Paragraph, Heading, List, Quote, Table, HTML, Verse, Code, Preformatted.
Media	Image, Gallery, Cover, Audio, Video, Media & Text, Pullquote, File, {Selected Embeds}.
Interface	Button, Separator, Spacer, Columns, Group.
Tools	Latest Posts, Search, Read More, Calendar, Archives, Categories, Shortcode, Page Break, Classic.

• Interface might be better presented as Design.
• Selected Embeds: YouTube, Twitter, Instagram, Facebook, WordPress, SoundCloud, Spotify, Embed. (These are the ones that are already prioritized.)
• Every other embed could appear if you search for it.
• Tools feels slightly too generic, but there was a problem with Blog absorbing elements that are not necessarily blog related (Latest Posts would be able to be used with any CPT, for example). Open to suggestions here, so far Tools seems the most appropriate.
• Try to order by global frequency of use.
• Finally, we need to make a call on "Most Used". Has this proven useful or a liability? I think a view that changes so much is unreliable and you cannot train your memory to trust it.

[shinyabw]

Everyone, thank you.

@mtias, thank you for leading this issue. @rralian, apology for the confusion. I meant "attribution" as "character". I took out "by attribution" from the title.

For some reason, I thought this issue was discussed at WCEU... Since I could not attend WCEU, I am so glad that I have a chance to keep on contributing.

• I prefer Design over Interface. I believe Design means Patterns (decoration) here, Interface means Connection (between a person and a computer).
• Regarding about Tools, I wonder if we should also consider Misc, meaning “not-text, not-media, not-design”.
• I would like to second for eliminating Most Used. Perhaps, we should try to find out how "slash inserter" can be used.
• I also would like to propose keeping "Text", "Media", "Design", "Tools/Misc" at the top of the inserter menu. I believe this would be helpful to make the menu internationally standardized. Please refer to the image to see how it looks in Japanese now.

[mtias]

I also would like to propose keeping "Text", "Media", "Design", "Tools/Misc" at the top of the inserter menu.

I agree with this.

[shaunandrews]

Finally, we need to make a call on "Most Used". Has this proven useful or a liability? I think a view that changes so much is unreliable and you cannot train your memory to trust it.

I agree. But I do think the concept behind "Most Used" is helpful. Perhaps update the treatment of the section and mimic the empty Paragraph block by showing only the icons for the most recently used blocks.

It could be helpful to separate Core blocks from Installed blocks, and standardize the way plugins can show icons for block groups. When there are no blocks installed, we could advertise the ability to install new blocks with a link to the upcoming Block Directory.

[mapk]

Perhaps update the treatment of the section and mimic the empty Paragraph block by showing only the icons for the most recently used blocks.

I really dig this, @shaunandrews. I'd love to move this forward because I'm seeing people struggle with the terms used currently when searching for a particular block in usability tests.

How about something like this?

• I kept the way in which "Most Used" is styled, but removed the accordion effect and placed the 3 most used block icons as Shaun suggested above.
• I followed the naming convention that we seem to have consensus around right now.
• I kept the "Embed" accordion tab because Gutenberg's claim was to surface the mystery meat, and I believe it does this here.

I'd like to keep the Block Directory integration as it's own PR so this particular issue doesn't get blocked by adding to its purpose.

If this works with everyone, we'll also keep the categorization of the blocks mentioned here: #11406 (comment). Let's move this to development! 🎉

[karmatosed]

Slightly drive-by comment but I am not super convinced about 'design' as a term here. I would expect it to be for many meaning something more aligned to actual colours/typography and styling. I know it doesn't have to mean that but most think that.

[ZebulanStanphill]

@karmatosed Perhaps it is better to stick with "Layout" then?

Also, I'm not convinced that "Tools" really makes sense either. Latest Posts doesn't sound like a "tool" to me. Perhaps we should just have a "Miscellaneous" or "Other" group?

Also, I'm not sure where exactly the Button block should go. Technically, it's not even a real <button>; it's a link. With that in mind, maybe it belongs in the "Text" group? Or perhaps it belongs in the "Tools"/"Other" group. I don't think it belongs in the same group as the Columns and Group blocks.

[getdave]

I took a quick look at this from a dev perspective off the back of a request in WP Core Editor Slack.

It looks like these Block categories are defined in WordPress Core.

Gutenberg has its own defaults but these will be overridden by WP Core defaults.

If someone from the Gutenberg team (@aduth ?) wants to correct me please do.

Also, what is the deprecation strategy for the existing Categories? Are we going to map old categories to new ones? We could alias the old categories to the new ones to ensure Blocks registered to old categories still show up.

[mapk]

The concern about "Design" makes sense. How about "Layout" or "Structure"?

Seeing as this category will include, Button, Separator, Spacer, Columns, Group blocks.

[aduth]

It looks like these Block categories are defined in WordPress Core.

Gutenberg has its own defaults but these will be overridden by WP Core defaults.

[...]

Also, what is the deprecation strategy for the existing Categories? Are we going to map old categories to new ones? We could alias the old categories to the new ones to ensure Blocks registered to old categories still show up.

@mapk and I were looking at this as well. My understanding is that the categories as defined in the blocks modules are intended to serve as a "base" set of defaults, notably for use of these modules outside the context of WordPress. They're redefined server-side to give plugins the opportunity to filter the results (e.g. to add to or remove from the default set).

As you noticed, there's going to be a challenge here in how we decide to update these, given that plugins which register custom blocks will have already assigned one of the existing categories. If there was a direct relationship between each of the previous categories and their new names, we could choose to simply update the labels of the category, but keep the slug values the same.

There's a few downsides to this approach, however:

• Documentation would become confusing, because we'd have to instruct developers to use (for example) a category value of "common" category for their block to appear under the "Text" label
• As proposed, the mappings don't always make sense. For example, "common" -> "text" works okay for some existing common-category blocks like Paragraph, but not for others like Image.
  • Aside: I think it's important to frame ourselves in this mindset of how we expect a transition to occur for third-party developers when we see these inconsistencies in the core blocks.

If we decided to rename the existing categories, there would be some side-effects as well, since those old category slugs effectively disappear. The block editor would treat any third-party block which registers with the old name as an invalid registration, and would refuse to allow it to register.

I think what would need to happen is to rename the categories, and include a fallback mapping of the legacy category names. This would be an imperfect mapping, but blocks could choose to update to a more appropriate category. For example, "common" could map to the "text" category, and we could update the Image block to use "media" in place of "common" so that it shows up in a more appropriate grouping. In the same way, a plugin would update their blocks to the most appropriate of the new category slugs.

This does leave open an unanswered question about plugins which support previous versions of WordPress. If a plugin updates their block to use the "media" category, what happens when that block is registered on a site running WordPress 5.2.0 ? For these cases, we might need to figure out how a plugin that supports multiple versions of WordPress could detect the current running version and register using the most appropriate category for that version. I expect this could be published as a release devnote.

There could be a separate discussion around how we could be more proactive to avoid these difficulties if we choose to rename labels again in the future. One thing I think we could improve upon is to be more graceful in how we treat invalid categories. For example, maybe we could allow a block to be registered without a category, or with an invalid category name, and present those blocks as part of some "Uncategorized" grouping. This would avoid a future hypothetical scenario where a category name becomes invalid because it's become renamed.

[mapk]

Just linking this one here. If we wanted to go with the "Most Used" layout above that shows the top 3 blocks as icons, PR #19045 is planning to remove that component. I'm sure we can get around it just fine, but wanted to note it.

[mtias]

I think we should avoid the "most used" for now. It can be discussed separately.

[getdave]

I think what would need to happen is to rename the categories, and include a fallback mapping of the legacy category names.

@aduth This is exactly what I had in mind so that is good. I was going to take a crack at a POC but given this is also in WP Core I'm going to leave this to someone with a better grasp of the implications 😄

[boemedia]

The concern about "Design" makes sense. How about "Layout" or "Structure"?

Seeing as this category will include, Button, Separator, Spacer, Columns, Group blocks.

I think the group name "Layout" makes sense, but imho, button doesn't belong there, neither does a separator.

From a classical design perspective (read: print), grid, layout and content were separate stages. I see there's some things crossing lines here. But the way I see it:

1. determine a grid
2. layout (these are sections, area's, without designated content, but place holders)
3. add content to layout

It makes sense to separate structure/layout blocks from content blocks. I definitely see a button as a content item. Text or a separate 'call to action' section would make more sense.

I was looking into the way popular page builders like Beaver Builder and Elementor are grouping their elements, but that doesn't make sense at all (separated by basic/pro subscription, third party elements in separate sections...). But at least they have layout and content in different parts of the builder.

[aduth]

I've opened a pull request at #19279 to start exploring the implementation of these block category updates.

[mapk]

Thanks @aduth for starting a PR!

Let's think about moving the Button block into the "Tools" category and then we can relabel the "Design" category to "Structure."

[mtias]

Also #19070 for removing the "most used" category.