Quantcast
Channel: Issues for Drupal core
Viewing all articles
Browse latest Browse all 298216

[meta] Improve the "Expose all fields as blocks to Layout Builder" feature

$
0
0

Problem/Motivation

We've reviewed #3043330: Reduce the number of field blocks created for entities (possibly to zero) at #3426532: Drupal Usability Meeting 2024-03-15. The meeting issue will have a link to a recording soon. For the record, the attendees at the usability meeting were @AaronMcHale, @blackbamboo, @rkoller, @simohell, @SKAUGHT, and @worldlinemine.

The functionality committed in #3043330: Reduce the number of field blocks created for entities (possibly to zero) will be available for the first time with Drupal 10.3.0. Existing sites upgrading to 10.3.0 will default to the checkbox ticked, thus sticking to the current pre-10.3.0 behavior, which has significant performance implications as soon as a certain number of field block plugins is reached. New installations will default to the checkbox unticked instead.

In our discussion we've identified three areas that might pose potential problems to the user:

Discoverability

The new configuration page can be found at /admin/config/content/layout-builder which is under Configuration -> Content authoring -> Layout Builder. Aside that page there is no indication or notice anywhere else within the Drupal admin ui. Therefore the odds are rather high that this functionality might go unnoticed, since not everyone is reading the changelog closely.
We've also asked ourselves if Content authoring in general is the right place to sort this page under. On one hand that feature influences the amount of field blocks exposed available to the site builder, but on the other hand that setting is not only a measure to hone the selection in the content authoring but also more of a way to improve the overall performance.

Troubleshooting

Closely related to the area of discoverability is the aspect of troubleshooting. There are currently no clues for someone, in-house or external, trying to debug the root cause of a problem unknowingly related to this configuration. The person troubleshooting has to know that this configuration page exists and also understand the underlaying concepts and their consequences.

Comprehension

The main and direct way learning about the functionality and it's underlaying concepts is the label and description on /admin/config/content/layout-builder. @quiteone already raised a concern in #3043330-113: Reduce the number of field blocks created for entities (possibly to zero) about the description being confusing. That sentiment was shared by one attendee during the meeting. He explained when first reading the label and description he had a hard time understanding the setting and its implications. After following along the demo and going through all the potential cases only then he slowly started wrap his head around everything.

The checkbox component only has the label and the corresponding description available to communicate all the necessary information; thus, the cognitive load is rather high to grasp the implications of the setting made on this configuration page. First the label explains what should be enabled, exposing all fields as blocks to Layout builder. A user might even assume the unticked state means no fields are exposed at all just reading the label and ignoring the description. In the first sentence of the description it then is explained more in detail what actually happens when the checkbox is ticked, all fields for all entity view displays are exposed. In the second sentence it is explained what are the effects when the checkbox is unticked, so that only entity type bundles that have layout builder enabled having their fields exposed. In the third and last sentence it is warned about the significant decrease in performance with a large number of entity types and bundles with the checkbox ticked. Depending on the situation a person always has to jump in-between the pieces of information aka the different lines to piece together the necessary information to figure things out in the current context. The checkbox component has its downside for cases like this where each of the states need some explanation as well as the concept in general.

In addition the terms used, like entity type and in particular bundle, might induce linguistic insecurity. People might be insecure about their meaning, those are challenging terms and concepts and in particular the term bundle isn't used that regularly within the admin ui.

In addition to that the description is missing a few important details so the user might not necessarily be clear about all the consequences. First the detail mentioned in: https://www.drupal.org/node/3416592

While it is recommended to turn this off, please note that this may remove blocks that are already being used in existing site configurations.For example, if you have Layout Builder enabled on a Node bundle (Content type), and that bundle's display is using field blocks for the User entity (e.g the Author's name), but Layout Builder is not enabled for the User bundle, then that field block would no longer exist after disabling this setting.

is not communicated on the configuration page, so the user might be unaware of that fact and the consequences of removed blocks be unexpected. Second in cases the layout for example for a node bundle (for example article content type) is edited, no fields of any other node bundle (for example basic page content type) are exposed no matter if the checkbox is ticked or not?

Steps to reproduce

Proposed resolution

In the following a few steps that might be taken to improve the problems identified in the Problem/Motivation section:

  1. To improve discoverability there was a clear consensus across the group to recommend adding a new entry to the status reports page about this configuration. Which state is set, and in case the feature is enabled and a certain number of field block plugins is reached and those might become a performance hog for the site move the status report entry to the warnings section (in case the number of field block plugins could be assessed fast and easy).
  2. In the context of discoverability there was also the idea to add an information next to each Use Layout Builder setting pointing to /admin/config/content/layout-builder. But that was just an idea and suggestion no strong recommendation. That addition might be probably a too redundant and induce an information overload across entities. The recommended addition to the status reports page might be already enough.
  3. To add a clue for people troubleshooting there was the suggestion to add a log message when the setting on this configuration page is changed. That way someone debugging can check the log file for a change in that regard.
  4. To improve the comprehension of the configuration page in general there was the clear consensus to recommend changing the ui component from a checkbox to radio buttons, a pattern we've recommended on a few issues over the last few months. In cases like this it is the way more clear interface pattern. The label is setting the overall context of the configuration page. The two radio button option labels explain what each option is actually setting/doing. The description underneath can explain the performance implications as well as the missing details listed in the problem/motivation section. And in general there was the consensus improve the microcopy on the configuration page. But that step can only be taken after there is a clear agreement about the other points in the proposed resolution section.
  5. Another idea and suggestion that was raised is adding a confirmation step when saving the configuration page. To make sure that the user making the change is fully aware about the implications. That confirmation step would mitigate the case illustrated with the blockquote from the linked change record in the problem/motivation section. @simohell had the idea in one of the followup discussions in the #ux channel on Slack to also add the fields and/or layouts to that confirmation step. That way user would be more in control and aware which fields and layouts are affected by such a setting change.

Remaining tasks

The idea making this issue a meta issue was as soon as there is a consensus on this issue about one or more steps in the proposed resolution section create child issues for each of those.

User interface changes

API changes

Data model changes

Release notes snippet


Viewing all articles
Browse latest Browse all 298216

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>