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).

Wireframes

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.

CommentFileSizeAuthor
#22 wix-css.jpg37.62 KBjuc1
#22 component-libraries.jpg89.52 KBjuc1

Comments

lauriii created an issue. See original summary.

lauriii’s picture

Issue summary: View changes
damienmckenna’s picture

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.

larowlan’s picture

lauriii’s picture

Issue summary: View changes

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

carlitus’s picture

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.
https://www.drupal.org/project/mercury_editor
https://www.youtube.com/watch?v=OVCPu4_ZtzE&ab_channel=AtenDesign
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:
https://www.drupal.org/project/dxpr_builder
They have also dedicated a lot of effort to make it usable, with many customization options.
It is paid with subscription.

chris matthews’s picture

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: https://try.dxpr.com/

Edit: there is also a free tier plan.

johnpitcairn’s picture

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

Related to that: #3204494: Content Not reverting in Layout builder section

catch’s picture

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 existing core issues for this, which have been getting closer to a solution recently:

#3387154: [PP-1] Move away from derivatives for FieldBlock and instead use block settings
#3365551: Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points
#2940755: block_content block derivatives do not scale to thousands of block_content entities.

dalemoore’s picture

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 😅

larowlan’s picture

@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.

dalemoore’s picture

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!

ressa’s picture

Issue summary: View changes

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

crzdev’s picture

Including Visual Layout Suite (VLSuite) https://www.drupal.org/project/vlsuite for ambitious site builders approach ready to use right now, in which 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
  • Applicable to any entity display using layout builder
  • No usage or extensibility cost

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

lauriii’s picture

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.

ressa’s picture

Issue tags: +Ambitious Site Builder

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

juc1’s picture

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...

https://www.o8.agency/blog/state-drupal-layout-building-compared-wordpress

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

juc1’s picture

@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?

larowlan’s picture

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

user654’s picture

.

fabianx’s picture

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:

https://www.drupal.org/project/lb_plus

Here is a quick GIF to show how it works in action:

Layout Builder + in action


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 which adds a whole new block builder functionality

Click here to see LB+ in action!

juc1’s picture

StatusFileSize
new37.62 KB
new89.52 KB

@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:

wix

browsable component libraries in the page builder UI:

components

juc1’s picture

@larowlan did the core team reply to you about your Pitchburgh work https://www.previousnext.com.au/blog/pitchburgh-diaries-decoupled-layout... such as they will / will not adopt it?

dalemoore’s picture

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.

larowlan’s picture

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

juc1’s picture

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

larowlan’s picture

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

juc1’s picture

@larowlan ok thanks, no reply from @lauriii yet but this recent blog post https://www.thedroptimes.com/38267/drupal-page-builders-part-1-paragraph... 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.

dmezquia’s picture

@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 Drupal has not put as much effort into this part because it has been seen by clients for more advanced solutions, not to release quick MVPs.

I think that if a solution could be reached between (Recipes + Single Directory Component SDC + "Better" Layout 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.

effulgentsia’s picture

I opened #3440578: [PP-2] JSON-based data storage proposal for component-based page building which I think is general enough to be able to support any UI we might end up wanting for this.

jmolivas’s picture

The off-canvas UX is challenging for sure. There are some work happening at the modules

Decoupled Preview Iframe
https://www.drupal.org/project/decoupled_preview_iframe

Visual Editor
https://www.drupal.org/project/visual_editor

Adding some screenshots related to the OffCanvas
Visual Editor

Visual Editor

And a link to short demo video
https://www.youtube.com/watch?v=OElix4t3gCQ

quietone’s picture

Title: Improve the page building experience » [meta] Improve the page building experience
Project: Drupal core ideas » Drupal core
Version: » 11.x-dev
Component: Idea » other

The Ideas project is being deprecated. This issue is moved to the Drupal project. Check that the selected component is correct. Also, add the relevant tags, especially any 'needs manager review' tags.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

bkosborne’s picture

Seems like this can be closed since Canvas has emerged?