Improve the page building experience

Created on 18 July 2023, 9 months ago
Updated 12 April 2024, 7 days ago

What is the problem to solve?

Site builders find it challenging to configure Drupal's page building experience in a way that meets the requirements of content editors, who are accustomed to using flexible and easy-to-navigate tools. In many cases, this means site builders or other more technical users remain responsible for building pages.

Specific issues:

  • Dependency on multiple contributed modules: Site builders currently have to rely on a large number of contributed modules to make the Layout Builder experience good in a production environment. This complicates the setup process, introduces compatibility issues, and increases the maintenance overhead.
    • Key challenges site builders try to address
      • Several challenges with the current off-canvas UX, most notably users are not aware that the dialog can be resized and numerous bugs in styling of elements inside the dialog.
      • List of available blocks is overwhelming, need to restrict available options
        • Scalability issues when the site has a large number of fields / blocks on the site
      • Block configuration is not well understood by editors. Some options are too granular, and should be configured on a site level. Site builders want to be able to provide pre-configured blocks.
      • Translation support.
      • Not enough flexibility to use existing content as a starting point.
      • Editing capabilities, e.g. nested sections or section reordering are missing.
  • Subpar user experience for content editors: In usability tests, users who are otherwise familiar with Drupal fail to accomplish basic tasks in Layout Builder. Even after configuration of numerous contributed modules, the content editing experience does not meet the expectations of editors.
    • Key challenges related to the user experience that are not solved by the above contributed modules:
      • Editing happens on multiple pages (Edit vs Layout)
      • Copy-pasting content from page to another is not possible
      • The UI is clunky and there are limited options for editing content.
        • In order to change from single column to two column layout, a new section needs to be created and content needs to be moved over manually.
        • It is not clear through the UI, what some of the content is.
      • Reverting incremental changes is not easy, especially when the taken action isn't well understood.

Result: what will be the outcome?

Page building experience that:

  • Combines the strengths of structured content with modern page building tools.
  • Has a user experience that is intuitive and empowers content editors to easily create, modify and manage content.
  • Supports common scenarios needed in production sites without requiring contributed modules.

Proposed resolution

  1. Allow editing structured data as part of the page building experience
    1. Site builders lock sections that are not being editable by editors, e.g. a pre-defined hero section.
    2. The pre-configured sections can contain unstructured and structured content
      1. "Unstructured data" is edited using a powerful block based text editor.
      2. Editing both types of content can be done on a single page, while keeping site builders able to leverage the power of structured data, like being able to customize several display modes.
  2. Introduce new concepts for pre-configured blocks and sections
    1. The available building blocks are configurable by the site builder. This ensures that what is visible for the editor is intended to be used on the site.
    2. Editors do not need to configure settings that are irrelevant to them, e.g. selecting a date format should be done by a site builder, not by an editor.
    3. Enable editors and site builders to store pre-configured sections to make creating new content faster and easier
  3. User experience that is more in line with text editors. This is an approach that is being used by the majority of the competing page building experiences and has become the industry standard.
    1. Think of copy and paste, drag and drop, and keyboard shortcuts instead of clicking through an UI.
    2. More interactive interface that enables content editors to build pages without a significant onboarding effort.
    3. Undo/redo for actions taken through the UI.
    4. Fast, visually appealing, and joyous to use.
  4. Provide more flexibility to change sections after they have been created
    1. Either allow changing from a section type to another, or replace the simple default section types with a new section that enables editors and site builders to configure the number of columns while editing content.
    2. Allow reordering sections.
  5. Both types of Layout Builder translations supported out-of-the-box with Drupal
    1. Allow selecting per-content type whether translation is asymmetric (separate layout per language) or symmetric (same layout but translated).


Note: these wireframes are intended to be used for describing the vision, not to be considered as the final UX.

Figma wireframes

Video mockup from DrupalCon Lille 2023 Keynote

How can we know the desired result is achieved?

  • System Usability Scale (SUS) and task-level satisfaction measurements
  • Reduce the number of required contributed modules
  • Increase adoption of the core page building solution

Process and where to find it

Work is happening on several tracks:

You can join us in Drupal Slack #layouts channel.

๐Ÿ“Œ Task




Created by

๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @lauriii
  • ๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States DamienMcKenna NH, USA

    It might be useful to get a list of the 15 modules identified so that then we can itemize the functionality they provide and possibly look to recreate that functionality in core.

  • ๐Ÿ‡ฆ๐Ÿ‡บAustralia larowlan ๐Ÿ‡ฆ๐Ÿ‡บ๐Ÿ.au GMT+10

    We've kind of done that in ๐ŸŒฑ [META] Layout builder editorial improvements Active ๐Ÿ‘

  • ๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

    Updating the issue summary with more details and a proposed solution.

  • ๐Ÿ‡ช๐Ÿ‡ธSpain Carlitus

    In case it helps you I comment some alternatives to the layout builder to have a page builder that I believe that they have very interesting points.

    Mercury Editor:
    This is what we are currently using. It is very intuitive and usable. Our customers have seen a big jump compared to layout builder.
    It doesn't use layout builder, but layout paragraphs. โ†’
    It uses style options which allows to specify in a single yml file properties like Layout Options. Very useful to be able to pass this configuration to other sites, for example new developments.

    DXPR: โ†’
    They have also dedicated a lot of effort to make it usable, with many customization options.
    It is paid with subscription.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States Chris Matthews

    FWIW, I've been using DXPR Builder โ†’ (and theme โ†’ ) for a while now and it's a really polished, fully Drupal integrated page builder. Demo here:

  • ๐Ÿ‡ณ๐Ÿ‡ฟNew Zealand John Pitcairn

    Reverting incremental changes is not easy, especially when the taken action isn't well understood.

    Related to that: ๐Ÿ› Content Not reverting in Layout builder section Active

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    List of available blocks is overwhelming, need to restrict available options
    Scalability issues when the site has a large number of fields / blocks on the site

    Linking some core existing issues for this, which have been getting closer to a solution recently:

    ๐Ÿ“Œ [PP-1] Move away from derivatives for FieldBlock and instead use block settings Postponed
    โœจ Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points Active
    ๐Ÿ› block_content block derivatives do not scale to thousands of block_content entities Needs work .

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States dalemoore

    Is the Decoupled Layout Builder intended to replace the current Layout Builder, or is it its own separate thing and there would be no upgrade path for it or anything like that (basically those of us creating sites with LB must start over)? Where does recently created things like SDC fit into it? Since SDC relies on Twig templates. Is this new DLB abandoning Twig in favor of React? I have questions ๐Ÿ˜…

  • ๐Ÿ‡ฆ๐Ÿ‡บAustralia larowlan ๐Ÿ‡ฆ๐Ÿ‡บ๐Ÿ.au GMT+10

    @dalemoore the decoupled layout builder is an experimental project as part of the Pitchburgh innovation contest. It is only replacing the editing of layouts and its data-model is compatible with the existing layout builder data-model. It doesn't do anything for the display of the content, only for editing. So if you're using Twig etc for the presentation, it will still do so. If the markup from the decoupled LB in edit mode doesn't match that of your twig templates, you will be able to swap in a different React component so it looks closer to the final product. There is no intention of ditching Twig for react that I'm aware of.

    There are other proposed approaches to this idea as well, i.e. the decoupled react one is just one option. The others are improving the existing one (see #9 for some links), using Gutenburg (another pitchburgh project) and other contrib options like LB Plus.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States dalemoore

    Thanks @larowlan. That gives me some sense of relief. I was afraid we were really just getting started with LB in my org only to have to change to something else.

    I can say whatever gets us closer to whatโ€™s possible in Gutenberg/Block Editor in WordPress Iโ€™m ๐Ÿ’ฏ in favor for!

  • ๐Ÿ‡ฉ๐Ÿ‡ฐDenmark ressa Copenhagen

    Adding link to @lauriii's Layout builder mockup at DrupalCon Lille 2023 Keynote in Issue Summary. It looks awesome.

  • Including Visual Layout Suite (VLSuite) โ†’ for ambitious site builders approach ready to use right now, in witch we put much effort, please take a look, recently out 1.1.1 stable with many improvements from 1.0.x, thanks!

    Keypoints are:

    • What You See is What You Get experience at the layout and content level, including appearance variants.
    • Appearance modificators with live preview
    • Built on top of layout builder with drag & drop UI
    • Completly Drupal way approach
    • Use any theme default/admin of your choice (no hard dependency)
    • Many others, please read project description carefully

    Demo & related conferences (1.1.x & 1.0.x):

  • ๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

    The problem itself has been validated and Dries announced building a solution for this as a strategic initiative for Drupal in his keynote at DrupalCon.

    During DrupalCon, several people worked on documenting pro's and con's of the existing solutions. There's also a list of contributed modules, and module setups that could be used as an inspiration. There's also a list of prioritized user stories for the page building tool.

    The next step is to find initiative coordinators and to start defining a plan for this.

    In the meanwhile, we are doing deeper analysis on some of the available open source projects like GrapeJS, Gutenberg, and puck to understand if there are anything we can reuse or learn from them.

    There's lots of prior art to improving Layout Builder, and we are hoping to find a way to let the broader community leverage some of these in the short term. One idea was to build a community "recipe" that installs targeted contributed modules on top of Layout Builder, to have a more opinionated starting point.

  • ๐Ÿ‡ฉ๐Ÿ‡ฐDenmark ressa Copenhagen

    I think this would fit under a "Ambitious Site Builder" tag?

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom Juc1

    I agree that the current Layout Builder UX is horrible, for example the URL separation between field content = /node/50/edit and layout = /node/50/layout, and that Drupal needs a modern page builder.

    Here is this problem mentioned in an old blog post from 2020:

    Our take is that Drupal, as of late 2020, is not there yet, not even half the way there, compared with WordPress-based page builders when it comes to the ability to create truly flexible, custom landing pages for marketing campaigns and one-off uses by non-technical people...

    We believe this will hurt the Drupal community... in the long-run if more effort isn't put into creating a flexible, open source landing page builder. It will further the perception and PR problem Drupal has of being a difficult-to-use platform...

    I wish that the wheels at Drupal HQ turned more quickly but it is great to see some progress.

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom Juc1

    @larowlan thanks for the detailed Pitchburgh updates on your blog. So is it possible that your Pitchburgh work could be adopted by the core team? Or if not could it become a contrib module?

  • ๐Ÿ‡ฆ๐Ÿ‡บAustralia larowlan ๐Ÿ‡ฆ๐Ÿ‡บ๐Ÿ.au GMT+10

    Yep the Drupal bits are in decoupled_lb_api and the npm bits in decoupled_lb projects

  • ๐Ÿ‡ฌ๐Ÿ‡ทGreece pinkonomy

    My two cents:I think Page Manager should be included in Drupal core alongside with Layout Manager
    Now,when you need to create the Homepage,you need to write some code.When you also need to add blocks,view etc,you need more code.
    Page Manager has a GUI for all of these.

  • ๐Ÿ‡ฉ๐Ÿ‡ชGermany Fabianx

    Hello there!

    At Tag1 we have been hard at work to create a drop-in replacement for the Layout Builder UI, which is fully compatible with all existing contrib modules and used by our Enterprise clients already for a while in production.

    It essentially changes the experience in three key points:

    - a) 1 drag instead of 5 clicks (with full best-effort configurable auto-completion of blocks using sample images and lorem ipsum ...)
    - b) Create your layout automatically -> Just drag your blocks and then change the auto generated layout to fit your needs
    - c) BETA: Nested layouts including the ability to drag blocks into a sub-layout (think of it as Layout UI for blocks itself)

    It's called lb_plus and can be found here including a small GIF to show the awesomeness: โ†’

    Some more detailed description by Tim Bozeman, who wrote the second version of lb_plus follows:

    Like larowlan said, we've been working on a drop in replacement for the Layout Builder UI that addresses many of these issues. There has been interest in adding LB+ to core also.

    lauriii said:

    One idea was to build a community "recipe" that installs targeted contributed modules on top of Layout Builder, to have a more opinionated starting point.

    I think LB+ can help fill the gap.

    Features include:

    • Drag and drop block placement
    • See what blocks do at a glance with block icons
    • Place blocks quickly with Promoted Blocks
    • Sortable sections
    • Change a sections layout
    • Duplicate blocks
    • A cleaner UI that looks more like the published content while editing
    • Soon to be released: Nested layouts โœจ Support Inline Layout Blocks Fixed which adds a whole new block builder functionality

    Click here to see LB+ in action!

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom Juc1

    @lauriii is there any progress to report since your first post 7 months ago?

    Two things I am hoping for =

    live CSS on the edit page:

    browsable component libraries in the page builder UI:

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom Juc1

    @larowlan did the core team reply to you about your Pitchburgh work, such as they will / will not adopt it?

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States dalemoore

    I would be interested in where this is headed too. I'm about to embark on redesigning our "flagship" website and picking something, whether it's Layout Builder, Layout Paragraphs, or some new thing that we can be sure will be around for a while would be helpful. WordPress has mostly moved to the Block Editor/Gutenberg, if we could standardize on something (while still allowing others to go their own way) it would help a lot of us on small (or, er, mostly one person >_>) teams.

  • ๐Ÿ‡ฆ๐Ÿ‡บAustralia larowlan ๐Ÿ‡ฆ๐Ÿ‡บ๐Ÿ.au GMT+10

    @Juc1 @lauriii has been doing evaluation of options and decoupled LB was in the mix.

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom Juc1

    @larowlan yeah I was just wondering if there was any progress yet, with Drupal 11 approaching.

  • ๐Ÿ‡ฆ๐Ÿ‡บAustralia larowlan ๐Ÿ‡ฆ๐Ÿ‡บ๐Ÿ.au GMT+10

    Not at this stage. For what it's worth, we don't have to wait until major releases to add new features

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom Juc1

    @larowlan ok thanks, no reply from @lauriii yet but this recent blog post says it could be another year before page builder improvements get into core. it is depressing to me that Drupal core can move so slowly, like a snail, and I have lost some Drupal clients to Wordpress because they have seen modern page builders with features such as live CSS on other platforms, and I can't explain why Drupal can't do this in 2024.

  • ๐Ÿ‡ช๐Ÿ‡จEcuador dmezquia UTC-5

    @Juc1 Many entrepreneurs and companies, rather than starting to develop a full application with "Drupal", prefer to launch an MVP and that is where Drupal does not fit, they want to create websites quickly, pages, sections... like no-code apps do.

    I think that Drupal has not put as much effort into this part because it has been selling itself for more advanced solutions, not to launch quick MVPs.

    I think that if a solution could be reached between (Recipes + Single Directory Component SDC + Better and fast pages builder) Drupal would be used much more in other communities that only want to launch Web/MPV quickly to the market.

    To reach clients into Drupal to create a quick MVP and then stay in Drupal for a more personalized solution.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States effulgentsia

    I opened โœจ JSON-based data storage proposal for component-based page building Active which I think is general enough to be able to support any UI we might end up wanting for this.

Production build 0.62.1