Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blocks: Update default block categories #19279

Merged
merged 7 commits into from
Jun 2, 2020
Merged

Conversation

aduth
Copy link
Member

@aduth aduth commented Dec 20, 2019

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)

image

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.

@aduth aduth added [Feature] Block API API that allows to express the block paradigm. [Feature] Inserter The main way to insert blocks using the + button in the editing interface labels Dec 20, 2019
@ZebulanStanphill
Copy link
Member

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
Copy link
Contributor

mapk commented Jan 15, 2020

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
Copy link
Contributor

Works well in my testing. 👍

@mapk
Copy link
Contributor

mapk commented Jan 16, 2020

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

Screen Shot 2020-01-16 at 8 30 38 AM

In the Options popover

Screen Shot 2020-01-16 at 8 30 46 AM

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

Screen Shot 2020-01-16 at 8 32 24 AM

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
Copy link
Member

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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
  1. 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.
  2. 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.
  3. 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
Copy link
Member

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
Copy link
Contributor

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

@boemedia
Copy link

boemedia commented Jan 27, 2020

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
Copy link

boemedia commented Jan 27, 2020

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
Copy link

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
Copy link
Contributor

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
Copy link
Contributor

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

@WordPress WordPress deleted a comment from github-actions bot Jun 2, 2020
@WordPress WordPress deleted a comment from github-actions bot Jun 2, 2020
@github-actions github-actions bot added this to the Gutenberg 8.3 milestone Jun 2, 2020
@gziolo
Copy link
Member

gziolo commented Jun 3, 2020

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
Copy link
Contributor

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
Copy link
Member

mtias commented Jun 11, 2020

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.

@ellatrix ellatrix mentioned this pull request Jun 16, 2020
12 tasks
@gziolo gziolo added the Backport to WP 6.7 Beta/RC Pull request that needs to be backported to the WordPress major release that's currently in beta label Jun 22, 2020
nylen pushed a commit to nylen/wordpress-develop-svn that referenced this pull request Jun 22, 2020
See WordPress/gutenberg#19279.

Props aduth, gziolo.
Fixes #50278.


git-svn-id: https://develop.svn.wordpress.org/trunk@48119 602fd350-edb4-49c9-b593-d223f7449a82
pento pushed a commit to WordPress/wordpress-develop that referenced this pull request Jun 22, 2020
See WordPress/gutenberg#19279.

Props aduth, gziolo.
Fixes #50278.


git-svn-id: https://develop.svn.wordpress.org/trunk@48119 602fd350-edb4-49c9-b593-d223f7449a82
markjaquith pushed a commit to markjaquith/WordPress that referenced this pull request Jun 22, 2020
See WordPress/gutenberg#19279.

Props aduth, gziolo.
Fixes #50278.

Built from https://develop.svn.wordpress.org/trunk@48119


git-svn-id: http://core.svn.wordpress.org/trunk@47888 1a063a9b-81f0-0310-95a4-ce76da25c4cd
gMagicScott pushed a commit to gMagicScott/core.wordpress-mirror that referenced this pull request Jun 22, 2020
See WordPress/gutenberg#19279.

Props aduth, gziolo.
Fixes #50278.

Built from https://develop.svn.wordpress.org/trunk@48119


git-svn-id: https://core.svn.wordpress.org/trunk@47888 1a063a9b-81f0-0310-95a4-ce76da25c4cd
donmhico pushed a commit to donmhico/wordpress-develop that referenced this pull request Jun 26, 2020
See WordPress/gutenberg#19279.

Props aduth, gziolo.
Fixes #50278.


git-svn-id: https://develop.svn.wordpress.org/trunk@48119 602fd350-edb4-49c9-b593-d223f7449a82
@ellatrix ellatrix mentioned this pull request Jul 3, 2020
12 tasks
@gziolo gziolo removed the Backport to WP 6.7 Beta/RC Pull request that needs to be backported to the WordPress major release that's currently in beta label Jul 8, 2020
@cguntur cguntur mentioned this pull request Oct 14, 2020
17 tasks
@youknowriad youknowriad removed the Needs Dev Note Requires a developer note for a major WordPress release cycle label Oct 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Block API API that allows to express the block paradigm. [Feature] Inserter The main way to insert blocks using the + button in the editing interface [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Re-grouping Editor Inserter Menu