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

Created on 8 August 2019, over 5 years ago
Updated 13 June 2023, over 1 year ago

Acquia performed a series of user tests around Layout Builder (I'm still working out how to make as much of those results as we can generally available to the community). But universally, this was a huge barrier to folks.

Excerpts from the findings:

Users had difficulty navigating among the many block types available to them. It was unclear how the categories were constructed. One user wanted meta-data versus media types (etc), but saw these types mixed within categories. Users wanted to sort (e.g., alphabetically, chronologically) among block types rather than use the categories provided.

Additionally, this sidebar is basically a never-ending barf of "Drupally words" to an audience of people (content authors) who shouldn't need to know/care that Drupal (or views or blocks or CTools or whatever) is what's powering the interface. Another key quote from the findings:

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

Indeed. ;)

#2977587: Improve block listing in Layout Builder by hiding uncommon block plugins β†’ attempts to solve this so by simply hiding some of the clutter behind a "more" link (not sure this is a great solution; it was more of a quick-and-dirty stop-gap back when we were advocating for this problem to be a stable release blocker for Layout Builder)

I think what we should do in this issue (or maybe sub-issues, but let's try to get a "vision" together here first) is:

- Brainstorm some solutions for this general problem (maybe also investigating into how other CMSes have solved this problem in their page building tools)
- If we stick with categories, come up with a sensible, "human readable" list of categories for blocks to be placed in (bearing in mind contrib will need to put things here too)
- Come up with an "MVP" we can try and get done in relatively short order, so we can ideally try and get something into 8.8 before October.

Thoughts/sketches welcome!

πŸ“Œ Task
Status

Active

Version

11.0 πŸ”₯

Component
Layout builderΒ  β†’

Last updated about 24 hours ago

Created by

πŸ‡¨πŸ‡¦Canada webchick Vancouver πŸ‡¨πŸ‡¦

Live updates comments and jobs are added and updated live.
  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

  • Needs usability review

    Used to alert the usability topic maintainer(s) that an issue significantly affects (or has the potential to affect) the usability of Drupal, and their signoff is needed. When adding this tag, make it easy to review the issue. Make sure the issue summary describes the problem and the proposed solution. Screenshots usually help a lot! To get sign-off on issues with the "Needs usability review" tag, post about them in the #ux channel on Drupal Slack, and/or attend a UX meeting to demo the patch and get direct feedback from designers/UX folks/product management on next steps. If an issue represents a significant new feature, UI change, or change to the general "user experience" of Drupal, use Needs product manager review instead. See the scope of responsibilities for product managers.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ͺπŸ‡ΈSpain penyaskito Seville πŸ’ƒ, Spain πŸ‡ͺπŸ‡Έ, UTC+2 πŸ‡ͺπŸ‡Ί

    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.

  • πŸ‡ΊπŸ‡ΈUnited States robbt

    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.

  • πŸ‡¬πŸ‡§United Kingdom catch

    I think we're are very close to an agreed solution to reduce the sheer number of blocks in ✨ Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points Active . 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.

Production build 0.71.5 2024