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

Files: 
CommentFileSizeAuthor
#33 block-2085201-33.patch12.73 KBtim.plunkett
PASSED: [[SimpleTest]]: [MySQL] 59,379 pass(es).
[ View ]
#33 interdiff.txt2.56 KBtim.plunkett
#32 Block_layout___Drupal_D8_Dev.png7.21 KBjessebeach
#32 Block_layout___Drupal_D8_Dev.png7.33 KBjessebeach
#30 block_category.png17.59 KBdawehner
#30 block-categories-2085201-30.patch9.85 KBdawehner
PASSED: [[SimpleTest]]: [MySQL] 59,511 pass(es).
[ View ]
#30 interdiff.txt825 bytesdawehner
#29 block-categories-2085201-29.patch9.05 KBjessebeach
PASSED: [[SimpleTest]]: [MySQL] 59,039 pass(es).
[ View ]
#29 interdiff.txt9.05 KBjessebeach
#17 block-categories-17.patch1.84 KBtim.plunkett
PASSED: [[SimpleTest]]: [MySQL] 59,105 pass(es).
[ View ]
Block_layout___Drupal_D8_Dev.png133.72 KBjessebeach

Comments

Issue tags:+Usability

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

- "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

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

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

@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.)

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

Fixing it so I can find it

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.

@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.

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

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).

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

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

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

Status:Active» Needs work

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

@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 :)

Status:Needs work» Needs review
StatusFileSize
new1.84 KB
PASSED: [[SimpleTest]]: [MySQL] 59,105 pass(es).
[ View ]
  • 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.

"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.

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.

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

@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? :)

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.

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

- 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

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.

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.

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

@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.

Status:Needs review» Needs work
StatusFileSize
new9.05 KB
new9.05 KB
PASSED: [[SimpleTest]]: [MySQL] 59,039 pass(es).
[ View ]

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.

Status:Needs work» Needs review
StatusFileSize
new825 bytes
new9.85 KB
PASSED: [[SimpleTest]]: [MySQL] 59,511 pass(es).
[ View ]
new17.59 KB

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

Issue tags:+VDC

.

StatusFileSize
new10.48 KB
PASSED: [[SimpleTest]]: [MySQL] 59,454 pass(es).
[ View ]
new643 bytes
new7.33 KB
new7.21 KB

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

Issue summary:View changes
StatusFileSize
new2.56 KB
new12.73 KB
PASSED: [[SimpleTest]]: [MySQL] 59,379 pass(es).
[ View ]

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

Status:Needs review» Reviewed & tested by the community

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

Yay! Go for it.

+++ 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?

Status:Reviewed & tested by the community» Fixed

Much better!

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

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.