Problem/Motivation

The default category of a block is currently the name of the module that provides it. For some blocks, the category name has semantic value. One example is a block provided by the menu module. For a block provided by the system module, the category name 'system' adds little additional information to an end user trying to find a block or seeking to understand what a particular block might do. As the number of modules increases with an installation, so too will the number of categories on the block placement page.

Screenshot of the block placement page. The block category labels (e.g. system, menu, comment, node, search) are highlighted to make them more salient

In order to avoid a fragmentation of block categories and to provide more meaningful semantic grouping of blocks, we should group them in core into more use-based categories. The pattern we set up in core will do much to shape the patterns that evolve in contrib from it.

Proposed resolution

Initial discussion of the proposed categories began in this google doc: https://docs.google.com/a/acquia.com/document/d/1YHbJ_2iGOsUsrC0FPVJLcWk...

That conversation is now moving to this issue. The proposed categories include:

Collapsed

  • Menus
  • Content blocks (Custom)
  • Content lists (views)
  • Forms
  • RSS feeds (hidden, no default blocks)
  • Widgets (hidden, no default blocks)`

Expanded

  • Menus
    • Admin
    • Main Navigation
    • User account
    • Secondary
    • Tools
    • Breadcrumbs
    • Shortcuts
    • Footer
  • Content blocks (Custom)
    • Site logo
    • Site Slogan
    • Main page content
    • Copyright
    • Powered by Drupal
    • System help
    • Syndicate
  • Content lists (views)
    • Recent content
    • Recent comments
    • Who’s new?
    • Who’s online?
  • Forms
    • Search
    • Contact
    • User login
    • Content language
    • Admin language
  • RSS feeds
  • Widgets

Note: The following heuristic was used to determine if the category name has sufficient “link scent” to prevent the user from checking multiple categories.

Heuristic: Fill in the blanks in the following sentence:

“[block name], is a [category] used to display the [verb form of the category + block name] [optional modifier + pronoun] your site”

Examples:
“‘Secondary’ is a Navigation menu used to navigate the Secondary sections of your site”
“‘Copyright’ is a content block used to contain the copyright information in your site”
“‘Recent comments’ is a content list used to list the recent comments in your site”
“‘Content language’ is a language switcher used to switch the content language in your site”
“‘User login’ is an entry form used to enter the user login information on your site”

Remaining tasks

  1. Finalize the list of categories.
  2. Alter the code to associate each block with its category.

User interface changes

Category names will change.

API changes

None.

#2060859: Make Block plugin's "category" a translatable string

Original report by @jessebeach

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Bojhan’s picture

Issue tags: +Usability

It'd be nice to get some other reviews on it, before I put mine in.

yoroy’s picture

- "Menus" is not very strange, but still a bit of a Drupalism. "Navigation" is more specific and less ambiguous.
- Having 2 categories start with the word 'Content' is a weakness. If anything, condering what's in the Content blocks (custom), those are elements that I suspect are furthest away from being percieved as content. Would all my own new custom blocks show up in here as well? Logo, slogan, copyright, help are all mostly one-time setup elements, making them part of the second bucket of this list seems too prominent.
- Content lists. This will be a tough choice. Lists is not ideal, but I agree with not using views itself. Content collections?
- Forms: good
- Rss feeds: what kind of blocks would live here? Lets come up with some examples. Is RSS necessary to add of is Feeds enough?
- Widgets: some examples would be good here as well. For now, this sounds like 'thingies', or even a 'misc.' in disguise

jessebeach’s picture

dealancer’s picture

Structure looks nice however the name 'Content blocks (custom)' sounds a bit confusing to me. First, I though that it was blocks, that user have generated, but in fact it wasn't.

Here is an alternative structure, where we separate custom blocks from content blocks:

  • Menus
    • Admin
    • Main Navigation
    • User account
    • Secondary
    • Tools
    • Breadcrumbs
    • Shortcuts
    • Footer
  • Content blocks
    • Site logo
    • Site Slogan
    • Main page content
    • Copyright
    • Powered by Drupal
    • System help
    • Syndicate
  • Content lists (views)
    • Recent content
    • Recent comments
    • Who’s new?
    • Who’s online?
  • Forms
    • Search
    • Contact
    • User login
    • Content language
    • Admin language
  • Custom blocks
  • Widgets
  • RSS feeds
longwave’s picture

I guess Widgets would include contrib things like shopping cart blocks, social sharing links, etc.

tkoleary’s picture

@jessebeach, @longwave, @yoroy, @Bojhan

Let's see if we can come to consensus on this in UX happy hour today (IRC #Drupal-usability 5:00pm EST.)

Bojhan’s picture

Title: Use descriptive categories rather than module-name categories to group blocks on the block placement page » Use sensible block categories (rather than module-name categories)

Fixing it so I can find it

yoroy’s picture

Bojhan + yoroy review:

We don't see issues with which items are in each category, so we're focussing on the amount, naming and ordering of the categories themselves:

Menus: it's a bit of a drupalism (as opposed to 'navigation') but using it for the category means we don't have to use that for each individual item ("tools" instead of "tools menu") so lets go with Menus.

Custom blocks is a mixed bag of core-provided page elements, two important system blocks (main content, help) and any new custom blocks you will create yourself. We also expect most blocks exposed by contrib modules will show up here (when they are not views). Since everything is blocks, we can drop 'blocks' from the category label and just use 'Custom'.

Content lists: renaming views to be content lists may be a good idea but this may not be the best place to start doing that. It needs more discussion wether we want to do that because then we'd have to be consistent in its usage. So, lets stay with Views for now.

Remove the RSS category, because those would mostly be Views blocks anyway.

Widgets: As a label it's misleading: widget can mean many things depending on previous experience with other CMS. As a thought experiment, what kind of block would be in here that doesn't fit into one of the other categories? Also, with the custom blocks category already being bucket for many different items it's not a good idea to provide a second bucket.

Forms: no-brainer.

--

So, lets try and order these on frequency of use. We're assuming (!) that views and custom blocks will contain the items you create/return to most. Menus and forms are basically the other 5%.

BLOCKS

- Views
- Custom
- Menus
- Forms

---

It would still be good to stress-test these categories a bit better and have some concrete examples with contrib-provided blocks.

tkoleary’s picture

@yoroy

It would still be good to stress-test these categories a bit better and have some concrete examples with contrib-provided blocks.

I agree. In general though, I think this is a pretty good list for now.

jessebeach’s picture

If I slot the standard default blocks into these categories, this is what I get. Most of them seem to not have a home.

- Views

Recent comments
Recent content

- Custom
- Menus

Administration
Main navigation
Footer
User account menu

- Forms

Search form

Where do these go?

Tools
Syndicate
Shortcuts
Breadcrumbs
Main page content
Powered by Drupal
System Help
User login
Who's new
Who's online

tim.plunkett’s picture

After discussing more with @Bojhan, those miscellaneous module-provided blocks would be under "Custom", which is only okay if #1920862: Rename custom_block.module to block_content.module happens (they would then not be called "custom blocks" anymore).

jessebeach’s picture

What about something like this?

Content

Recent comments
Recent content
Main page content
Breadcrumbs
Shortcuts
Syndicate

Custom

-- empty until custom block instances are created --

Menus

Administration
Main navigation
Footer
User account menu

Forms

Search form

Users

User login
Who's new
Who's online
System Help

Site

Tools
Powered by Drupal

Bojhan’s picture

I agree that we want to differentiate between module provided and user provided blocks. I spoke this over with timplunkett and jesse and they felt similar. The custom category is where user created blocks go and system is where all module provided blocks go (sadly the label isn't ideal, but I think the concept is).

- Views
Recent comments
Recent content

- Custom
"IF I make a "hello to my website block" it would fit here.

- System
Who's new
Who's online
System Help
Main page content
Breadcrumbs
Syndicate
Powered by Drupal

- Menus
Administration
Main navigation
Footer
User account menu
Tools
Shortcuts

- Forms
User login
Search form

yoroy’s picture

yes, I arrived at the same 'system' label for making that split.

jessebeach’s picture

Status: Active » Needs work

Great, let's get the labels in #13 into the code!

tkoleary’s picture

@yoroy

Looks good to me.

We can (and will) revisit the global nomenclature issues with data from the IA study, but that's another issue :)

tim.plunkett’s picture

Status: Needs work » Needs review
FileSize
1.84 KB
  • Neither of those recent comment/content blocks are actually views yet
  • In #2071019: Allow the block category for Views block displays to be edited we just did a bunch of work to help *avoid* using "Views" as the category, and instead grouping them by the kind of thing they display
  • It's a bit odd to move Node's "Syndicate" block and User's "Who's Online" and "Who's New" to System when they are not provided by that module

Here's a patch for the rest, it can serve as an example of how to do this.

yoroy’s picture

"System" is our best stab at a label that covers "All core/contrib blocks provided out of box", so not confined to System, the module but encompassing anything you get automatically when installing modules.

Re: #2071019: Allow the block category for Views block displays to be edited, need to look into that further. We do expect that it may become useful that the views category in blocks would benefit from subcategories, then we should probably re-use the ones from there.

I think grouping by kinds of content is useful within a views context but when having to incorporate other kinds of elements like we have to here it becomes less so.

jessebeach’s picture

It could simply be true that there is no set of category names that has (a) few enough categories to be useful and (b) categories with labels descriptive enough to be useful.

yoroy’s picture

Welcome to the wonderful world of information architecture for the know unknowns :)

tkoleary’s picture

@Tim Plunkett

Neither of those recent comment/content blocks are actually views yet

They may not be views but they are lists. Why don't we call them that? :)

tim.plunkett’s picture

The suggestion was not to name the category "Lists". I wouldn't have said anything if that was the case. But the suggestion was to make these non-Views-based blocks have a category of "Views". That's (one of) the thing(s) I disagree with here.

Bojhan’s picture

@tim I understand however they should be views. You feel like that won't happen?

jessebeach’s picture

- Lists (Views)
Recent comments
Recent content
Who's new
Who's online

- Custom
"IF I make a "hello to my website block" it would fit here.

- System
System Help
Main page content
Breadcrumbs
Syndicate
Powered by Drupal

- Menus
Administration
Main navigation
Footer
User account menu
Tools
Shortcuts

- Forms
User login
Search form

yoroy’s picture

Looks very good to me, I like it.

For clarity maybe add a similar line to the 'system category': "Blocks exposed by contrib (that are not views?) would show up here."

Regardless, this looks like what we should move forward with.

jessebeach’s picture

For clarity maybe add a similar line to the 'system category': "Blocks exposed by contrib (that are not views?) would show up here."

Contrib blocks can reuse current categories or introduce their own. It's a loose system.

Bojhan’s picture

Is it possible for this to be documented in our UI standards?

tkoleary’s picture

@Bojhan @jessebeach

it is a loose system but we should use the standards to discourage blocks from creating their own top level categories because that is what they will tend to do. For good DX here we should figure out a way to gather all block categories from contrib modules and store them in a table which can be presented as a list on D.O. I would even suggest that new categories need to be submitted for approval and name-spaced like projects but maybe that's too draconian.

Perhaps:

For module developers:

If your module creates a block please use an existing category if there is one appropriate to your block eg: if your block displays a view put it in "Lists (Views)", if it is a custom block put it in "Custom blocks". If your block does not fit in a default category please use a category from the contributed categories list [link to list]. If there is absolutely no default or contributed category into which your block fits and your block is a special snowflake then feel free to create a new category for it.

jessebeach’s picture

Status: Needs review » Needs work
FileSize
9.05 KB
9.05 KB

This brings us in line with the block categories listed in #24.

I haven't altered the Views blocks categories. I'm not sure how to do this. timplunkett, can you address Views blocks?

I also categorized non-standard blocks from Book, Forum and Aggregator. I turned on all the core modules and categorized all the blocks.

dawehner’s picture

Status: Needs work » Needs review
FileSize
825 bytes
9.85 KB
17.59 KB

This sets Lists (Views) as default value for the block category.
block_category.png

dawehner’s picture

Issue tags: +VDC

.

jessebeach’s picture

This small change turns the "Custom block" category to simply "Custom". There is no reason to repeat "block" here.

Before:

Block_layout___Drupal_D8_Dev.png

After:

Block_layout___Drupal_D8_Dev.png

tim.plunkett’s picture

Issue summary: View changes
FileSize
2.56 KB
12.73 KB

We have to remove the special base table logic for views, or the new default will never take effect.

jessebeach’s picture

Status: Needs review » Reviewed & tested by the community

Manually tested timplunkett's changes. This patch looks great. It's ready to go.

yoroy’s picture

Yay! Go for it.

klonos’s picture

benjy’s picture

+++ b/core/modules/comment/lib/Drupal/comment/Plugin/Block/RecentCommentsBlock.php
@@ -17,7 +17,8 @@
  *  id = "recent_comments",
- *  admin_label = @Translation("Recent comments")
+ *  admin_label = @Translation("Recent comments"),

Could we fix the indentation on these at the same time?

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Much better!

Committed and pushed to 8.x (with the indentation fix). Thanks!

webchick’s picture

Title: Use sensible block categories (rather than module-name categories) » Needs documentation: Use sensible block categories (rather than module-name categories)
Priority: Normal » Major
Status: Fixed » Active
Issue tags: +Needs documentation

Actually, we need a documentation page in the handbook for this, under UX best practices. People don't know to use these categories right now and so we're starting to regress them in issues like #2020399: Convert "Who's online" block to a View.

tim.plunkett’s picture

In #2256355: Make block plugins usable outside the block entity context, Dries asked for more in-code documentation surrounding categories, I think we can do that here as well.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

  • webchick committed 8469376 on 8.3.x
    Issue #2085201 by jessebeach, tim.plunkett, dawehner, yoroy: Use...

  • webchick committed 8469376 on 8.3.x
    Issue #2085201 by jessebeach, tim.plunkett, dawehner, yoroy: Use...

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

  • webchick committed 8469376 on 8.4.x
    Issue #2085201 by jessebeach, tim.plunkett, dawehner, yoroy: Use...

  • webchick committed 8469376 on 8.4.x
    Issue #2085201 by jessebeach, tim.plunkett, dawehner, yoroy: Use...

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Chris Charlton’s picture

+1 (bump)

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev
quietone’s picture

Title: Needs documentation: Use sensible block categories (rather than module-name categories) » Use sensible block categories (rather than module-name categories)
Version: 9.3.x-dev » 8.0.x-dev
Status: Active » Fixed
Issue tags: -Needs documentation

This issue was committed in November 2013 (#38) and re-opened for an update to documentation. While this is not a bug the Bugsmash Initiative has found that issues that have been committed and re-opened tend to linger and that making a followup so the issue can be closed improves the chances it will be resolved.

So, restoring the fixed status of this, at the time it was fixed, and opening a new issue to look into the documentation.

quietone’s picture

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.