Adjust the block terminology in Layout Builder to align with block and block_content changes

I've created a mockup by adjusting the titles and labels like suggested in the proposed resolution section in the issue summary.

The changes i've applied were:

block administration page -> block layout page
+Add block button -> + Add component (the idea was as a preliminary draft to use something broader that encloses blocks and fields)
Choose a block title -> Choose a component
+ Create custom block -> + Create content block
List (Views) (block added to each block category)-> List (Views) blocks

I've then went ahead and presented the current plan for moving and untwining the block related pages in Core at the Drupal Dojo Austin to yesterdays attendees @rocketeerbkw and @arcticcheetah. The plan was as agreed in https://drupal.slack.com/archives/C1AFW2ZPD/p1666965008595329 to get some general feedback about the plan by a diverse number of users.

In addition to the general thumbs up for the different steps there were the following comments specific to the layoutbuilder screenshot:

• Using the more generic term component for the sidebar title (choose a block -> choose a component) as well as the add button in the main layout builder screen (add block -> add component removes potential confusion. it basically says now not only blocks can go here.
• To back that one of the attendees provided an anecdote. when being new to drupal and visiting the layout builder page for the first time it was hard to grasp. when scanning the sidebar the first time the attendee passed the content fields category because he was looking for block. he hadn't realized that you are able to place these fields like blocks. so everything is a block and could be placed like a block even if it is called content field. content fields are technically not blocks but they are placed like blocks therefore a generic term like components is considered helpful.
• There should be extra caution about the label for the + create custom block button in the layout builder sidebar. just changing it to + create content block is still misleading. it creates the impression the block would go into the custom block library but instead those blocks are only available for the particular layout builder layout one attendee pointed out. they are layout builder blocks not core content blocks.

I've presented the current plan for moving and untwining the block related pages in Core at the weekly Lean Coffee Table at the Drupal User group in Munich to @drubb, @franz-m, @it-cru, @jurgenhaas, @martin-mayer as well as to the Fox Valley Computer Professionals attendees Anthony E. Scandora, @bsnodgrass, Sally Gradle, @TBone242.

The term component which i've used for the side bar title and the + add button-button was considered too generic. the critique component is a term that is mainly found and is associated with front end development context. But there was an agreement that finding a more broad term than the current over-specific and imprecise term button is a good thing. One suggestion was to perhaps think about the term element.

The idea of appending the term block for the block related categories titles illustrated in the screenshot was well received.

The button label + create content block surfaced again the main problem people not fully understanding the the different types of block available and their implications laied out in https://www.drupal.org/project/drupal/issues/2862564#comment-14789469. We also have to keep in mind #2999491: Add reusable option to inline block creation which introduces a checkbox enabling the user switching the standard not reusable block to a reusable one. https://www.drupal.org/project/drupal/issues/2999491#comment-14601739 also provides a few alternative suggestions in regards of how to name that button. but without the aforementioned issue fixed the naming of the button has a few implications the user HAS to be aware that the blocks created within the layout are only available in that particular context. most of the attendees in both meetings were not really aware about that fact to the full extent until the day of the discussion.

At the end an idea i've voiced in one of the comments already that gained a bit of traction and positive resonance during both discussions. it deals with a similar problem like the custom block library https://www.drupal.org/project/drupal/issues/2862564#comment-14789469 problem. currently there is no way to know if a website has layouts or not. you have to go into each content type to see if use layout builder is checked. in case allow each content item to have its layout customized is checked you then have to go into each of the nodes of that content type. there is no way on huge content heavy sites to know each individual node. even worse if you get into a new huge project there is no way to know how many layouts are there nor is some sort of overview. as a user you are not really in control. if i understand it correctly there is already an open issue #3143007: Make it possible to create views listing content with layout overrides that enable to create list views of nodes that have layout and or layout overrides. such list view page could be added to the appearance page. nothing for this issue but perhaps for a followup or everything could already done in #3143007: Make it possible to create views listing content with layout overrides. but the proposed changes by the attendees for the custom block library as well as the addition of a list view page of layout was considered useful and helpful by the attendees. it would help to keep them in control.

The sole blocking issue #3318549: Rename Custom Block terminology in the admin UI got committed to 10.1.x-dev today, therefore this issue can become active now. To get the discussion started again, the current proposed resolution is the following:

1. Rephrase the overall title Choose a block to something else. Because strictly speaking the user is able to choose between blocks and fields. The sidebar title should reflect that. The + Add block button should be changed accordingly since you are able to add blocks and fields there as well. (*There is no idea and no consensus about a suggestion yet)
2. Append block to every block category. Then you have Content fields , Content blocks, User fields, User blocks, Devel blocks, Help blocks and so on. It would be clearer to the user without any ambiguity.
3. Since there are cases with only a single item in a category it might be considered to add a singular and plural form to the category titles so based on the count it would be User block with one item and User blocks for several items (for the english singular/plural example)
4. One nitpick, the category title core is written in lowercase but all other terms are upper case at the beginning of each category title.

going through the aforementioned points:

1. in that case it might be a good thing to try something we've touched in the last usability meeting. to create a one-two punch questionnaire. a google form providing in the first question a quantitative question (multiple choice) about the "what" followed by an open ended question to get qualitative feedback about the "why" the previous choice was made.
Currently the off-screen sidebar header (Choose a block) as well as the button in layout builder (add block) refer to the element to add as block. but as noted the sidebar lists content blocks, blocks, fields, as well as inline blocks. therefore blocks is "sort of imprecise". but the question is what would be the clearest reference? with the "one-two punch" you could explain the scenario in the first question to the participants and provide the following options for the multiple choice question with options like:

• block
• element
• component
• not sure
• other (the other option if chosen would provide an input field for a suggestion)

and in the second question you could ask the participants in the open ended question why they made the decision. the form could be quickly set up and if we get a good number of replies quickly it would be helpful feedback in case the distribution of answers looks fine and the qualitative answers have no hard blockers in. cuz overall you don't necessarily need statistical significance to be pointed in the right direction in regards of a term choice
2. i am still in line with the proposed resolution for 2
3. i am still in line with the proposed resolution for 3
4. i am still in line with the proposed resolution for 4
5. and there is one last tricky detail. as already mentioned in #2 and #3 the label Add content block wasn't clear at all to the users that the content block created in layout builder differs from those created for example on /block/add. the former are not reusable inline blocks while the latter are reusable content blocks. the label Add content block might create misleading assumptions as well as expectations. the outcome of this choice also directly affects #3352550: Hook help for block content module is out of date after new permissions since it would be a reasonable step to name the distinction between reusable and not reusable blocks there.

Usability review

We discussed this issue at #3414129: Drupal Usability Meeting 2024-01-19. That issue will have a link to a recording of the meeting.

For the record, the attendees at the usability meeting were @benjifisher, @rkoller, @simohell, @shaal, and @worldlinemine.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

We’ve discussed the four open points listed in #6 - this comment will refer to those points. It has to be noted that none of the following is considered a strong recommendation.

#6.1
There was sort of a consensus that the mental model for the Layout Builder page shouldn’t be changed at this point and the terms Section and Block should be kept. In consequence + Add block should be kept as well.
It has to be noted that the suggestion to go with the suggestion of something like + Add component raised in #6 was based on the observation that the user has to pick from a list of content blocks and fields in the offscreen tray and fields are actually no blocks. But I’ve learned that technically, under the hood, fields are wrapped in blocks in the context of Layout Builder. Therefore changing + Add block to something more generic like Component would be sort of counter productive and potentially confusing to the user. The same applies to the title of the offscreen tray and Choose a block could be kept.

But on the other hand the label + Create content block in the offscreen tray is semantically wrong. Content block implies that you have a “reusable” block but the user actually creates a none-reusable inline block here. Problem is this button is the only touch point of a user with the concept of a none reusable inline block. We went through the help topics and neither on the help pages for blocks /admin/help/topic/block.overview, /admin/help/block_content nor on the help pages for layout builder admin/help/layout_builder was any word or explanation about the concept of re-usuable content blocks vs none reusable inline blocks, only content blocks are mentioned.
One option might be to make additions to those help pages. Aside making additions to the help pages another option might be to add more touch points with those concepts in the admin ui, as proposed in #3325029: Improve the overview of the list of available blocks:

• Show re-usuable AND none re-usable blocks on /admin/content/block
• Add a reports page similar to Backdrop providing an overview of all created blocks

About the actual label for the + Create content block button, the group came up with the following suggestions:

Create block for this pageor New block for this page
On the plus side that label makes it clear that the block is only created for this page but on the other hand the label is lengthy and what type of block is actually being created is not communicated with this label.

Add inline block
On the plus side inline block is the most accurate and one of the shortest labels but as mentioned before due to the fact that this offscreen tray is currently the only touchpoint with this concept inline block would also be one of the most confusing choices at this point.

Create block
On the plus side, in contrast to the other too specific and potential confusing suggestions, Add block is very simple and brief and through experience users will learn what this means. But on the downside going with just “block” might be too generic and again the underlaying concept of reusable and none reusable blocks isn’t touched with that variant.

Add exclusive block
The last suggestion that was brought up during ideation was Add exclusive block. But the consensus was that there are too many potential meanings of the word "exclusive" and it is unclear what it acutally means and refers to .

It was also noted to keep in mind that an option to convert an inline block to a reusable content block is on the horizon as well which will complicate things even further: #2999491: Add reusable option to inline block creation

#6.2
Appending the term Block would add a redundancy, but it would be an acceptable downside since the details of interest are front loaded. But that way it would help to clarify the point of confusion why fields are listed under the overall headline Choose a block

#6.3
There was sort of an agreement that based on the number of blocks it might make sense to distinguish between singular and plural form for the appended term block in the category title.

Yes "Create content block" is "technically" correct but imprecise.

At the moment if you click the "Create content block" button and create a block, that block shows up in the chosen section in the main content area, but at the same time you have the "Content block" section in the sidebar, the second section underneath the "Create content block" button. But the content block you've just created isn't showing up there as well. Identical labels but completely different behavior. With the current micro copy a certain knowledge about the technical backgrounds is taken for granted. And as I've noted before this sidebar is the sole direct touch point for the user with the concept of none reusable blocks in the ui.