The list of available blocks in Layout Builder is overwhelming to users

The default listing should definitely be better.

I heard people using https://www.drupal.org/project/layout_builder_restrictions to limit available layouts and available blocks to aid users. (This is not a replacement for making the default list better, just an addendum :)

For anyone not familiar with Layout Builder Restrictions, here's the result of what using it looks like...

This is the entirety of the Choose a Block sidebar in Lightning, for the Landing Page content type:

This is the UI that Layout Builder Restrictions provides for configuring that:

Note that it makes no changes to the category labels or which category any given block is in. It just lets you reduce which blocks are available to something "manageable", but that only works if your content editors truly don't need all those other ones. Which is different than the approach in #2977587: Improve block listing in Layout Builder by hiding uncommon block plugins, which retains all of the blocks, but hides the less common ones behind a "More" link.

Here's a thought about what we might want to do. It's just a starting point, please feel free to shoot part or all of it down and suggest something else...

1. Come up with more logical categories and human-friendly names for them. Use them for core, and encourage contrib to use them too.
2. Add the functionality of Layout Builder Restrictions to core.
3. When configuring Layout Builder Restrictions, in addition to choosing which blocks to display at all, for the ones that are displayed, also choose whether it's a commonly needed block, or whether to hide it behind a "More" link.
4. By default, configure all blocks to be available (don't restrict any), but pick good defaults for which ones to hide behind a More link. #2977587: Improve block listing in Layout Builder by hiding uncommon block plugins might be a good starting point for determining that default.

Alternatively, we could just do item 1 in core, keep item 2 out of core, and do items 3 and 4 as feature requests to Layout Builder Restrictions or as a new contrib module that depends on it.

I think the issue Angie linked above is a great place to start. It collapses the fieldsets to reduce the overwhelming list, and then this serves to highlight the "search/filter" function. Having LB restrictions in core is certainly interesting, but at least having it in contrib is helpful. I'm not sold on the "more" link idea, but that too is another approach.

I think the issue Angie linked above is a great place to start. It collapses the fieldsets to reduce the overwhelming list

As far as I can tell, neither the proposed resolution in #3069446: Layout builder's "Add Block" sidebar menu UX improvements, nor its latest patch, collapses the categories. The screenshot in the issue summary shows them collapsed, but is that from having some other patch applied or module installed? If we don't have an issue already open for collapsing all the categories, let's open one?

At the risk of going off on a tangent, It seems to me that the user intent is different when using layout builder on a content type (when placing fields is likely the primary goal) vs. an individual node (where creating inline blocks and placing views and other blocks is more typical). I know there's a danger of confusion if the same interface is organized differently in two different places, but should we consider optimizing for the different primary goals in each use case?

Thanks @mandclu! I don't think it's off tangent at all. I agree that the intent is different between content type layouts and individual content layouts, and that's something that bugs me about the proposal in #3069446: Layout builder's "Add Block" sidebar menu UX improvements, because it would imply that the recommended action is to click the big blue button, but that should not be the primary call to action on content type layouts; as you said, the primary call to action on content type layouts should be to place fields.

I've been thinking about this some more for the past few days, and here's some ideas I came up with...

1. For both content type layouts and individual content layouts, remove the "Create custom block" link. See #3.3 below for what to replace it with.
2. Change the expand/collapse pattern to a vertical accordion. In other words, only one category can be expanded at a time. Clicking on a collapsed category expands it and collapses the one that was previously expanded. The benefit of this is that it keeps the list from becoming so visually overwhelming, similar to the comments in #2 and #8 above. However, we always start with one category expanded: the one that is most likely to be relevant for the type of layout being edited (see #4 below). The downside of this, however, is that core does not yet use a vertical accordion pattern anywhere else, so this would be a new UI pattern for core, though one that's very common elsewhere.
3. Reorganize the categories to the following:
   • @content_type Fields. E.g., if you're editing something for "Basic Page", it would be Basic Page Fields. Per the proposal in #2977587: Improve block listing in Layout Builder by hiding uncommon block plugins, this would only contain the list of fields that appear on the "Manage Display" tab of the content type, not all of the node base fields.
   • @content_type Metadata. E.g., if you're editing something for "Basic Page", it would be Basic Page Metadata. This would contain all the other fields (the base fields that do not appear on the "Manage Display" tab). Things like "Authored By", "Authored On", etc.
   • Add new content. This would contain an item for each Custom Block type. This replaces the functionality of the current "Create custom block" link.
   • Embed Existing Content. This would contain an item for each reusable custom block (e.g., if you had previously added some via /admin/structure/block/block-content). I would recommend that the Entity Embed module assign its blocks to this category as well. Maybe the Entity View blocks from Chaos Tools should be in this category as well.
   • Lists. Same as what is currently "Lists (Views)". Except perhaps we should move "Who's New" back into this category as well (I don't know why it was moved to "User" to begin with). Potentially non-Views lists could go here too, such as the blocks from the Entity Browser module, which lets you place one or more entities that you pick from browsing, the result of which seems a lot like a List to me.
   • Navigation. This can combine Menus (currently its own category) as well as "Primary admin actions" and "Tabs" (currently in the "core" category) and "Breadcrumbs" (currently in the "System" category).
   • Forms. Same as what we already have.
   • User Data. Just a rename of what's currently named "User Fields".
   • Other. For everything else, such as Help, everything in System that isn't moved to one of the above, and things from contrib modules that don't fit into any of the above.
4. When on a content type layout, expand the first category by default. When on an individual content layout, expand the 3rd category by default. Hopefully, this would solve the goal of #3069446: Layout builder's "Add Block" sidebar menu UX improvements of making "Add new content" impossible to miss.

I really like the idea of including some competitive analysis here. Should we also consider the approach of some landing page builders like Unbounce or Instapage? Also, if we're going to do additional user testing, could we test how similar users perform the same tasks on the other platforms? It would be good to understand the degree to which these other approaches are actually measurably better for end users, and where a different approach could have its own pitfalls.

I think it's also worth mentioning that AFAIK none of these other platforms have use case equivalent to laying out the fields for a content type. I do still think that the typical nature of what a user is trying to accomplish will be significantly different for this use case (where placing existing fields is the most common use case) vs. laying out a single node (where placing new or existing content is most common, or lists of content).

Finally, there is promising work underway at #3029830: Provide single field values from multivalue fields as layout builder-friendly blocks. I think the idea of making the node add/edit form a place to make a multimedia copydeck could be a game changer, as a place to assemble all the stuff you want in your layout, and then in a separate step move it all around. That said, it could definitely have implications on what we're discussing here.

Following @webchick's guidance, I'd like to propose the next iteration. I've also taken some elements of @effulgentsia's suggestions.

A few principles that I'm following:

• There are a max of 3 hierarchical levels. 1. Category. 2. Subcategory. 3. Item.
• The category label is novice-friendly. No Drupalisms allowed.
• I've used the common Drupal term in a "subtitle" field where appropriate so that Drupalists don't lose their way.

My methodology:

1. I created a list of all Drupal core blocks and *most* of the Gutenberg and Squarespace blocks
2. I created a Notion board (basically a Trello board) with columns for each category, a card for each sub category, and a bullet point description for contained items.
3. I juggled things around fitting the cards into the fewest number of logical columns.

Right now I have 8 top level categories and a few orphaned blocks. Screenshot attached.

It can also be viewed as a board (which you can duplicate and modify) or a table. I'm continuing to iterate on these so it may be updated since the attached screenshot was taken.

CSV Attached too.

Possible improvements:

• Combine "Content" and "Uploaded Media" since it's all just entity references.
• Create a catch all category like "Widgets" for orphaned blocks like Help Status Messages. Gutenberg does this. Given that there are only 2 core forms, it may be best to add them to this category (Search and User Login).

Thanks for the feedback. I intend to revise based on your comments and repost today.

> "entity reference" is also pretty technical

I think it would be nice to have a novice-friendly title with a drupalist-friendly subtitle. So, we would show "Entity reference" in small gray text or in a tooltip. But, I understand if we'd prefer to use a pattern where we _never_ expose niche language like that at all. What do you think?

> I would make "Uploaded Media" just "Media" personally.

Done. What do you think about just putting Media under the Content category? They're similar in that you're referencing Drupal entities. Conceptually, "Content" would reference Drupal data and "Embed" would reference remote data.

> "Tabs" are under both Navigation and Layout. Is the idea that Tabs under layout is the "Vertical Tabs" UX pattern?

Yes that's the idea. There's a "Tabs, Local Tasks" which shows Drupal links (no custom links allowed) and a "Tabs, Vertical Links" which would let you create your own tabs. Maybe that's too complicated. I think we could just remove the vertical tabs option for now. Thoughts?

> I'd rather not introduce a new term "Widgets" here... even "Miscellaneous" or "Other" would be better for this category label, IMO.

Another option is to label it "System."

I'm posting a revision. One notable change: I've removed the "Layout" column. I _do_ think we will need the ability to add "nestable layout elements" like divs, columns, vertical tabs, etc., but it's to mixed up it the section vs block distinction in layout builder. We should separate consider what to do about that.

It can also be viewed as a board (which you can duplicate and modify) or a table.

If I can add in. This may or may not be the right place, but I thought it might be relevant. I've just started on 8, from four or so yrs with 7. Love the layout builder, and the thoughts above. Agree with the Acquia tests.

I'll add to the managing custom blocks is really hard theme. If I add a basic block in the builder, I cannot see it in my custom blocks library. And also cannot see it in the custom blocks section of the builder's config space. If I try and add a custom block via structure>block layout > custom block library > add block > basic block, and use the same title in the description, I'm told it is already there. Of course it is, I just cannot see it.

One more, the builder is adding "style=height: fixed px" attributes to my blocks in the builder. This is pretty unresponsive when I resize the browser window making my content collide with other content, regardless of whether the I have multiple blocks/section or one block/section. I do not know why styles are being added in this fashion, but they interfere.

OK one last one, I found a block (content) in the layout builder. I added the page that I was on. It went into a "spin" never loaded. So, cleared caches ... I can view the page, but when I click the layout tab, just get the equivalent of a spinning ball. So the page is no longer editable. Need to toss and rebuild. I likely triggered something recursive, that is now stuck, I get gateway timeouts. "The gateway did not receive a timely response from the upstream server or application."

As my use case, I'm more of a web builder than coder. I use asset injector (css) to override setting and make my site specific. This model has been working great for me, several sites now. I know I can use lots of !mportant(s) in my class attributes, but is that the best way? Every height?

Thanks

PS. for the items above, please direct me to the proper issues and I'll cross post. Having a hard time finding where those might be too.

This seems like it was proposed in #11, but I'd like to highlight it a bit more.

What does everyone think about reversing what was done in #2968500: Change inline blocks workflow in Layout Builder to match mocks as part of this effort? It would essentially "mix in" the custom blocks into the main list instead of separating them with a "create custom block" button. I'll paste in what I wrote in #3069446: Layout builder's "Add Block" sidebar menu UX improvements about this:

One thing our editors have been confused about is why there's seemingly two separate lists of blocks.

There's the main list you see when you click "Add block", and then there's this secondary list that's only revealed when you click "Create custom block". Why is this separation needed? Yes, behind the scenes, these "custom" blocks are distinct because they represent the creation of BlockContent entities, but to a site builder, all blocks are layout building components.

It seems that when content blocks were first added to layout builder, they were shuffled in with the main list of blocks, but it was changed in #2968500: Change inline blocks workflow in Layout Builder to match mocks to separate them.

Interesting discussion. Just a tiny comment from me.

Users shouldn’t need to speak Drupal to use Drupal!

I agree with this.
On the other hand, i think a subset of the Drupal architecture should be visible, so that users can form a mental model, and connect the dots if they recognize a concept in more than one place:
- A "field" is something that is configured on a "Manage fields" page. A "view" is something that can be managed in "Structure > Views".
- Some elements are coming from the entity being viewed, some are "global", some are "local" to this layout (which means to this specific node, if it is a single-node layout).

#22 - What does everyone think about reversing what was done in #2968500: Change inline blocks workflow in Layout Builder to match mocks as part of this effort? It would essentially "mix in" the custom blocks into the main list instead of separating them with a "create custom block" button.

I agree there should be no difference between inline blocks and other blocks for an editor. An editor does not care what happens under the hood. Reversing the separation is a first step, however I think using a structure as shown in the screenshots of #12 will improve the UX a lot. (with a default icon for blocks which do not have one specified)

I agree with the others. Custom blocks need to be moved back to where they were. I will repeat my comments from the other issue here:

I agree that custom blocks need to be moved back to the main blocks list. I have read through the issue that caused this change and still do not see a good reason for said change, but it seems like really, really bad UX. It is confusing to users and unnecessary, as to them, there is no meaningful difference between custom blocks and other types. Also, if you click on "Create custom block" and you want to then go back to the main block list, you can't. The only option is to close the panel and start over. Plus, the search box does not work for custom block types in the current configuration. Please move it back, or provide a simple means for us to do so.

Found this while working on the dashboard initiative, where we face a similar problem (#3351705).

So hopefully in the future the scenarios that need to be solvable are:

1. Editing the layout for a given content type.
2. Editing the layout for a specific entity.
3. Editing the layout for a dashboard.

We considered creating our own block specialization, so we could define specific plugin blocks that are designed specificly for a dashboard. But at the end we should expect people to create views blocks, or reuse their blocks for the dashboards. So that specialization is not the first option, at least for now.

If dashboards get traction, I'd expect more blocks being added to core/contrib/custom with the dashboard in mind, which might make this experience of editing the layout for a given content type or an specific entity even worse.

A major problem here is #3043330-95: Reduce the number of field blocks created for entities (possibly to zero).

I looked at this at the DrupalCon usability review event and I don't think there has been an agreed upon solution even if everyone recognizes that this is a usability issue with Layout Builder.

My suggestion would be to differentiate between Content Fields and Content Metadata Fields

This seems like a cleaner distinction than hiding certain fields under "More" which was rejected as a solution.

I think if we differentiated them into Content Fields and Content Metadata Fields
Content Fields
Body
Image
Title
Content Metadata Fields
Authored by
Authored on
Changed
Comments
Comments
Content type
Default revision
Default translation
ID
Language
Links
Menu link
Promoted to front page
Published
Revision create time
Revision ID
Revision log message
Revision translation affected
Revision user
Sticky at top of lists
Tags

Maybe Tags and Comments and Links could be considered Content fields vs. Metadata but certainly most of these aren't typical things that someone would want add to a layout display and so hiding them would reduce cognitive load and overwhelm that was identified by testing.

I think we're are very close to an agreed solution to reduce the sheer number of blocks in #3365551: Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points. Once that issue is done, there could still end up being lots of blocks to choose from but it would be from a much lower starting point.