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.
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
- Finalize the list of categories.
- Alter the code to associate each block with its category.
User interface changes
Category names will change.
API changes
None.
Related Issues
#2060859: Make Block plugin's "category" a translatable string
Original report by @jessebeach
Comment | File | Size | Author |
---|---|---|---|
#33 | block-2085201-33.patch | 12.73 KB | tim.plunkett |
#33 | interdiff.txt | 2.56 KB | tim.plunkett |
#32 | Block_layout___Drupal_D8_Dev.png | 7.21 KB | jessebeach |
#32 | Block_layout___Drupal_D8_Dev.png | 7.33 KB | jessebeach |
#30 | block_category.png | 17.59 KB | dawehner |
Comments
Comment #1
Bojhan CreditAttribution: Bojhan commentedIt'd be nice to get some other reviews on it, before I put mine in.
Comment #2
yoroy CreditAttribution: yoroy commented- "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
Comment #3
jessebeach CreditAttribution: jessebeach commentedComment #4
dealancer CreditAttribution: dealancer commentedStructure 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:
Comment #5
longwaveI guess Widgets would include contrib things like shopping cart blocks, social sharing links, etc.
Comment #6
tkoleary CreditAttribution: tkoleary commented@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.)
Comment #7
Bojhan CreditAttribution: Bojhan commentedFixing it so I can find it
Comment #8
yoroy CreditAttribution: yoroy commentedBojhan + 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.
Comment #9
tkoleary CreditAttribution: tkoleary commented@yoroy
I agree. In general though, I think this is a pretty good list for now.
Comment #10
jessebeach CreditAttribution: jessebeach commentedIf 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
Comment #11
tim.plunkettAfter 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).
Comment #12
jessebeach CreditAttribution: jessebeach commentedWhat 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
Comment #13
Bojhan CreditAttribution: Bojhan commentedI 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
Comment #14
yoroy CreditAttribution: yoroy commentedyes, I arrived at the same 'system' label for making that split.
Comment #15
jessebeach CreditAttribution: jessebeach commentedGreat, let's get the labels in #13 into the code!
Comment #16
tkoleary CreditAttribution: tkoleary commented@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 :)
Comment #17
tim.plunkettHere's a patch for the rest, it can serve as an example of how to do this.
Comment #18
yoroy CreditAttribution: yoroy commented"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.
Comment #19
jessebeach CreditAttribution: jessebeach commentedIt 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.
Comment #20
yoroy CreditAttribution: yoroy commentedWelcome to the wonderful world of information architecture for the know unknowns :)
Comment #21
tkoleary CreditAttribution: tkoleary commented@Tim Plunkett
They may not be views but they are lists. Why don't we call them that? :)
Comment #22
tim.plunkettThe 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.
Comment #23
Bojhan CreditAttribution: Bojhan commented@tim I understand however they should be views. You feel like that won't happen?
Comment #24
jessebeach CreditAttribution: jessebeach commented- 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
Comment #25
yoroy CreditAttribution: yoroy commentedLooks 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.
Comment #26
jessebeach CreditAttribution: jessebeach commentedContrib blocks can reuse current categories or introduce their own. It's a loose system.
Comment #27
Bojhan CreditAttribution: Bojhan commentedIs it possible for this to be documented in our UI standards?
Comment #28
tkoleary CreditAttribution: tkoleary commented@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.
Comment #29
jessebeach CreditAttribution: jessebeach commentedThis 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.
Comment #30
dawehnerThis sets Lists (Views) as default value for the block category.
Comment #31
dawehner.
Comment #32
jessebeach CreditAttribution: jessebeach commentedThis small change turns the "Custom block" category to simply "Custom". There is no reason to repeat "block" here.
Before:
After:
Comment #33
tim.plunkettWe have to remove the special base table logic for views, or the new default will never take effect.
Comment #34
jessebeach CreditAttribution: jessebeach commentedManually tested timplunkett's changes. This patch looks great. It's ready to go.
Comment #35
yoroy CreditAttribution: yoroy commentedYay! Go for it.
Comment #36
klonosComment #37
benjy CreditAttribution: benjy commentedCould we fix the indentation on these at the same time?
Comment #38
webchickMuch better!
Committed and pushed to 8.x (with the indentation fix). Thanks!
Comment #39
webchickActually, 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.
Comment #40
tim.plunkettIn #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.
Comment #51
Chris Charlton+1 (bump)
Comment #56
quietone CreditAttribution: quietone at PreviousNext commentedThis 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.
Comment #57
quietone CreditAttribution: quietone at PreviousNext commentedThe follow up is #3280350: Document sensible block categories.