Blocks: Update default block categories

[aduth]

Closes #11406

This pull request seeks to propose to replace the existing set of default block categories with a new set of categories as proposed in #11406.

The updated set of block categories are:

• Text
• Media
• Design
• Tools Edit: Widgets (Unchanged)
• Embeds (Unchanged)
• Reusable (Unchanged)

Implementation Notes:

There is an attempt to preserve some backwards-compatibility here, based on the summarized findings at #11406 (comment) .

Blocks which register to one of the existing categories will transparently map to one of the updated categories. As implemented, that mapping is proposed as follows:

Before	After
Common	Text
Formatting	Text
	Media
Layout	Design
Widgets	Widgets
Embeds	Embeds
Reusable blocks	Reusable blocks

Click to expand outdated notes from early iterations

Before	After
Common	Text
Formatting	Text
Layout	Design
Widgets	Tools

(Suggested improvements to this are welcomed)

Notably, I have not yet updated existing blocks to use an appropriate new category name, for the explicit purpose to effectively test the sensibility of this mapping arrangement, considering that this is expected to impact third-party blocks which register to one of the existing categories, at least until those plugins opt to update to a more appropriate updated category.

Prior to merge, we can consider to update the default set of core blocks to a more appropriate block category.

As a follow-up task, I would like to explore improvements around allowing blocks to be registered without a category, or without a valid category. Such blocks should be shown in an "Uncategorized" block grouping. This could also be used to support usage where there are no default categories, and the inserter would show all blocks without any groupings. This could also be used to improve support for hypothetical future revisions to block categories, in order to better handle block registrations for plugins which support multiple older versions of WordPress. Edit (2020-05-29): This was implemented separately in #22280.

Testing Instructions:

Verify block categories are updated to new values, seen in the block inserter.

Verify there are no errors of block registration in your browsers Developer Tools console (i.e. all blocks should still be registered, with an appropriate category).

Optionally, verify you can change a block registration to use one of the new block category names, or a legacy category name. Legacy category usage should appear as categorized based on the mapping above.

[ZebulanStanphill]

I think "Tools" is an unclear category name. I have no idea what kind of block would be a "tool". I think it should be replaced with an "Uncategorized" category for blocks that don't fit anywhere else.

[mapk]

As we're re-labeling these categories, and making minor modifications (global functions), it's also important to keep in mind that we're looking to add Block Patterns to the Inserter too. This will likely include a new set of categories that apply to patterns. Reusing this code for that makes a lot of sense.

[shaunandrews]

Works well in my testing. 👍

[mapk]

In relation to #19409, it's apparent that "Tools" may not work here. It's seem to be our goto word lately and is being used a bit too much.

In the Tools/Modes popover

In the Options popover

And also here in the Inserter (if we make this change)

It looks like "Tools" includes
Latest Posts, Search, Read More, Calendar, Archives, Categories, Shortcode, Page Break, Classic.

There was a suggestion from @mtias to possibly call it "Blog" but "Tools" had felt better at the time. Now I'm rethinking Blog.

[ZebulanStanphill]

Why not just call it "Other" or "Uncategorized"? There's going to be a need for an "other"-type category anyway, so why not just use that instead of a contrived but still ambiguous name like "Tools"?

[karmatosed]

I agree with not using 'tools' as that is becoming a repeating word that I suspect will confuse. I'd lean away from creating buckets before they are needed so 'uncategorized' or 'other' to me wouldn't be ideal. Blog seems to work as does 'element' maybe?

[shaunandrews]

Latest Posts, Search, Read More, Calendar, Archives, Categories, Shortcode, Page Break, Classic.

Everything (but Classic) makes sense under "Blog" to me.

Maybe the Classic block fits better under Text?

[ZebulanStanphill]

Neither Search nor Shortcode are really related to the concept of "blog" in my opinion. Classic belongs wherever Custom HTML belongs, in my opinion.

[pyronaur]

Everything (but Classic) makes sense under "Blog" to me.

It makes sense to me too. However, does it make sense to someone who's not familiar with blogging/WordPress - is Calendar really a part from a blog? For example, if their day-to-day vocabulary is mobile and desktop software - Calendar is an app, not a part of "Blog Blocks" or even Components.

I'd lean away from creating buckets before they are needed so 'uncategorized' or 'other' to me wouldn't be ideal

I think this might already be a good time for a creating that bucket. Especially considering custom blocks.

What if someone is creating a plugin with a single block that does something that's not a component or interface? If they find no "Other" category where to place their block in - they might resort to creating the other category themselves anyway, and at that point - it might be even more confusing for what really is "Blog" or "Component" and what is "Other"/"Misc".

Also, considering naming - "Other/Misc/Miscellaneous/Not a Block/Uncategorized" - if there's no standardized bucket for this - someone might end up with a blog where they have both "Other" and "Misc" categories because different developers decided to use different naming conventions.

[boemedia]

If we’re discussing ‘blog’, i’d avoid it in this context. It will be confusing if blocks are used on other types of websites or in general in pages.

[MichaelArestad]

Howdy! It looks like we're stuck on renaming Widgets.

It seems to me we could do one of a few things:

1. Make a few more categories instead of trying to make blocks fit where they don't. This feels like the most logical and scalable solution to me. It also encourages meaningful categorization. Here's a pass at this:

Text
Media
Layout (assuming we don't call Templates Layouts)
Post - Latest posts, Latest comments
Sharing - Sharing buttons, RSS
Navigation - Navigation, Search, Archives, Categories, Tag Cloud
Embeds
Reusable

2. Use Blog - While it fits okay, it seems to me if I wasn't making a blog, I'd never even open that category. I don't want those poor little blocks to feel left out.
3. Use Widgets, Tools, Elements, or Uncategorized - These are all identical to me. They represent a junk drawer. I don't recommend any of them. Instead, let's encourage developers to put their blocks in a category, even if they have to make a special category just for their cool block. If we create a miscellaneous category, it will fill up pretty quickly.
4. Leave it as Widgets for now while debating the verbiage in a follow-up PR.

Phew! Having said all that, these need further exploration. @melchoyce mentioned that a card sorting exercise might be valuable here. Would anyone care to take a shot at it?

[karmatosed]

This is all very tricky to find a grouping that works across so deeply appreciate everyone working together here to get there. I do find the 'Navigation' grouping a little surprising as I don't know if I feel that categories and tag cloud to me are navigation, I wonder if it could be 'elements'?

[pyronaur]

@karmatosed What are the downsides to creating the "Other" bucket? Just curious about the hesitance there.

[boemedia]

What are the downsides to creating the "Other" bucket? Just curious about the hesitance there.

@pyronaur It can easily become a trash can of too many blocks.

[boemedia]

This is all very tricky to find a grouping that works across so deeply appreciate everyone working together here to get there. I do find the 'Navigation' grouping a little surprising as I don't know if I feel that categories and tag cloud to me are navigation, I wonder if it could be 'elements'?

Aren't all blocks 'elements' in a way? It's confusing what's behind this label.

[boemedia]

Would it be an idea to step away from category names for now and look at the blocks from a purpose perspective? Maybe this approach helps categorising them better and, eventually, come up with a good name per block category.

So: The ______ block is for _______

or

With the ______ block you can ________

Is there a document with a list of all current native blocks?

[pyronaur]

It can easily become a trash can of too many blocks.

Totally can see that happening. But perhaps they can then be gradually categorized out of there as the need crops up naturally?

It seems to me that, currently, we're trying to figure out a word for "Other" that doesn't say "Other" anyway.

[pyronaur]

Is there a document with a list of all current native blocks?

I'm not sure if there's a document with a list, but you can view the list as directories here:
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src

[gziolo]

Nice work. I have a related question. I see that @wordpress/create-block was updated already. I'm wondering how it should be tackled in the CHANGELOG there to make it clear that those categories will work only with WordPress 5.5 or with Gutenberg plugin enabled. An alternative is to temporarily add this mapping on the PHP side that is listed in the Dev Note.

Edit: Filed at #22848.

[shinyabw]

Hi everyone. I really appreciate seeing my proposal became a reality. I'm speechless. Thank you very much.

@mtias , for the record, I would like to note that I really liked your proposal using "create, build, share." I did spend time with your idea. I contemplated with "draw, build, share," and "ink, map, let," however, sadly I have gotten busy with COVID-19 situation (I am currently a university prof and admin).

I feel that your proposal deserves revisiting in the future.

Once again, everyone, thank you very much. I hope I get a chance to meet you someday. If you ever come to Tokyo, please let me know.

With warm regards from Tokyo.

[mtias]

Oh, thank you @shinyabw for contributing and making things better. I agree there's something to the verb-groupings that'd be worth exploring in the future. Hope you are doing well over there. Have never been to Tokyo but would love to visit some day. Stay safe.