Modify Layout Builder's use of the off-canvas tray to improve UX of larger block forms

You can easily pass width in dialog options to make the off-canvas dialog wider. Right now it defaults to 300px unless the page is narrow and then covers the whole page.

Another option would be to create another off-canvas render like off_canvas_wide that would set a wider width automatically. That way it would more likely that core and contrib would have the same width when needed the "wider" dialog.

On thing to think about though with layout is that having wider dialog will also more likely invoke a breakpoint that will shift the layout. Maybe this isn't a concern but thought I would mention it.

Another option would be to have a off_canvas_full render which always take up the full width of the page. But then is there benefit of using dialog vs a another page?

Can we just check what systems like Adobe Experience Manager do and inspire ourselves there?

You can easily pass width in dialog options to make the off-canvas dialog wider.

Can we also make sure that this is easily done without having to override various parts with custom controllers or use JavaScript from a contrib. perspective?
For instance if #2916781: Allow off-canvas dialog to be rendered at the top of the page lands there are more options on where you want the canvas to be, and even if Layout Builder has sensible defaults it would be nice to override.

Another field affected by this is a multi-image field. The remove button is pushed completely off the screen. Have to modify the CSS to 800px wide to get it wide enough to appear.

Can we also make sure that this is easily done without having to override various parts with custom controllers or use JavaScript from a contrib. perspective?

I think this would be a great place to start, that way there are options for an integration point for people to experiment. How about we follow the lead of what node does and do something like \Drupal\node\Controller\NodeController::addPage, provide a theme definition for the list of blocks a user can add. That way, there is a template that can be overriden and a list of links that can be preprocessed.

Here is an implementation of #8. It would be cool to actually do the same with selecting the section to add. That would satisfy the needs of contributed modules like layout_builder_restrictions which currently uses some non-api tactics to alter the list.

#9 Nice! 👏 This is much better. And works!

Top of my mind:

• We can still use the details theme definition within our block list for the default implementation.
• At the point where the developer can change the link attributions (which I suppose are the most interesting to change), they are already nested. Which means they have to implement a double foreach loop to change them. Wondering if we can fix that?

I like the idea of being able to edit these links.

I tried to use the preprocess hook to change links for inline blocks to be modals

function tester_preprocess_layout_builder_choose_block_list(&$variables, $element) {
  if (!empty($variables['categories']['Inline blocks']['links'])) {
    foreach ($variables['categories']['Inline blocks']['links']['#links'] as &$link) {
      $link['attributes']['data-dialog-type'] = ['modal'];
      $link['attributes']['data-dialog-options'] = Json::encode(['width' => '500px']);
      unset($link['attributes']['data-dialog-renderer']);
    }
  }
}

but ran into couple problems

1. The off-canvas still remains open #2983120: OffCanvas dialog doesn't close when opening a standard Dialog. existing problem to figure out
2. new issue #3012044: Off-canvas dialog resize doesn't work if modal is open
3. After you submit the form the modal does not close because \Drupal\layout_builder\Controller\LayoutRebuildTrait::rebuildAndClose() has $response->addCommand(new CloseDialogCommand('#drupal-off-canvas'));

   We could somehow change or extend \Drupal\Core\Ajax\CloseDialogCommand to have CloseCurrentDailogCommand. This would use \Drupal\Core\Ajax\AjaxHelperTrait::getRequestWrapperFormat() to close the current dialog.

Of course if we just expect people change the width of the off-canvas then the above won't be a problem but I think will sometimes want to use the modal dialog.

Just changing this

$link['attributes']['data-dialog-options'] = Json::encode(['width' => '500px']);

Actually does work.

Settings to needs work because we either need to document that you shouldn't use the modal or figure out how you can.

If we want modules and themes to be able control the dialog that is used for the block forms they will also have to edit the contextual links used for update forms.

I guess this is possible via hook_contextual_links_view_alter but the DX is not great there I think for determining what type of block is being updated.

If a module/theme wanted to update all update links regardless of type it wouldn't be too hard.

/**
 * Implements hook_contextual_links_view_alter().
 */
function tester_contextual_links_view_alter(&$element, $items) {
  if (isset($element['#links']['layout-builder-block-update']['url'])) {
    /** @var \Drupal\Core\Url $url */
    $url = $element['#links']['layout-builder-block-update']['url'];
    $attributes = $url->getOption('attributes');
    if (isset($attributes['data-dialog-options'])) {
      $dialog_options = Json::decode($attributes['data-dialog-option']);
    }
    else {
      $dialog_options = [];
    }
    $dialog_options['width'] = '500px';
    $attributes['data-dialog-options'] = Json::encode($dialog_options);
    $url->setOption('attributes', $attributes);
  }
}

Hm, all good points. Changing the whole approach from the outside is still a tricky endeavour, perhaps this issue should instead just focus on making the canvas wider from within layout builder.

I'd still be interested in #9 to clean up modules like layout_builder_restrictions though.

I think we should just include a comment for now stating we're only supporting dialog/off-canvas , and make the modal proposal a follow-up which by the way could be a pretty nice contrib. module.

Btw it could be configurable, at least it makes sense to allow core to override dialog type

re #13

I'd still be interested in #9 to clean up modules like layout_builder_restrictions though.

I think this refers to

That would satisfy the needs of contributed modules like layout_builder_restrictions which currently uses some non-api tactics to alter the list.

But actually I don't think that code is need any more. layout_builder_restrictions_plugin_filter_layout__layout_builder_alter mentions // Invoke deprecated API hook for restricting layouts. @todo: remove.

Though I am not positive I think the new hook hook_plugin_filter_TYPE__CONSUMER_alter should be the only thing you need to remove layouts or plugins from the list.

But actually I don't think that code is needed any more. layout_builder_restrictions_plugin_filter_layout__layout_builder_alter mentions

Confirming that layout_builder_restrictions does not use the EventSubscriber any longer; that was in place for legacy sites prior to the introduction of hook_plugin_filter_TYPE__CONSUMER_alter().

Rerolled the patch and added a comment about not changing the dialog type. Added the comment in the template. Not sure if there is better place.

Hi everyone,

I think the patches on this issues don't provide a solution to improve UX of larger block forms how the title says.

Using hook_preprocess_layout_builder_choose_block_list doesn't work for inline blocks creation because they don't come in $variables['categories'] .

I think a real solution for this issue is to make the links for inline blocks creation to open in a modal window, but I understand it depends on #2983120: OffCanvas dialog doesn't close when opening a standard Dialog.

@jidrone good catch. this because #2968500: Change inline blocks workflow in Layout Builder to match mocks was committed and inline blocks are no longer in the main list.

But since \Drupal\layout_builder\Controller\ChooseBlockController::getBlockLinks() is used in both the case of the main block list and the inline block links we could simply allow modules to use a preprocess on this links if they want to change the width of the dialog.

Technically a module could do this now with mymodule_preprocess_links but this would be invoked for all links. If change #theme though to links__layout_builder_blocks they could implement mymodule_preprocess_links__layout_builder_blocks. This would allow edit the link attributes in the same way I was suggesting in #18 expect you would not need a new template.

The only problem is #2968500: Change inline blocks workflow in Layout Builder to match mocks introduced the "Create Custom Block" link which if there is only one type of custom block link directly to the custom block form. So in that would not be able to alter the link that opens up the inline block form.

Here is a fix for the "Create custom block" link. It also uses '#theme' => 'links__layout_builder_blocks', for the 1 link.

We should probably descope this issue or use this patch for a new issue "Allow easier altering of block configuration links". But want to leave this here for discussion.

Hi @tedbow,

Would be great to send a variable to know the category of links to make easier to alter only the links of Inline block creation for example.

NW for #22

Opened #3032456: Allow easier altering of Layout Builder block configuration links

leaving this issue open to discuss other ux problems with large forms

@tedbow, what do you think of resurrecting #18. I have some ideas about alternative ways of displaying lists of blocks in the sidebar, and that approach provides a structured way to approach it.

If #22 has been spun off into another issue, do you still think #18 is valuable, and if so, what are the blockers to getting it done?

@Sam152

what do you think of resurrecting #18.

#18 pretty just provided template for the block listing but I don't think we would need that if we did #3032456: Allow easier altering of Layout Builder block configuration links

or did you want be able to have the specific theme/template for the hole list to be able alter in another module or theme?

Exactly that, altering the whole component would have been nice when implementing: https://www.drupal.org/sandbox/sam/3033243. Something I needed based on expecting many thousands of content blocks.

I think for the large quantity of block content entities problem, just making it alterable might be a great way to go. I could foresee someone implementing a button to open Entity Browser so you could filter/tag/etc to locate the block.

For larger configuration forms and content block edit forms, either a modal/overlay or ability to drag the offset tray with a handle could be a great solution.

One of my modules has a fairly large configuration form for the block, and the space limitation will be more difficult to work around.

This is something that could definitely be solved on my end with a bit of creativity, but we may be more limited with content block edit forms with a large number of field widgets.

Another workaround for edit blocks in full page is to find block id, and open standard block edit form. This can be done via modifying /admin/structure/block/block-content views for show reusable=false blocks. This will show all blocks from Layout Builder, with link to full block edit form. So will be good to add "Edit block" contextual link to each block with link to full edit form.

There's a solution in contrib that addresses this issue: Layout Builder Modal.

(IMHO, this is best addressed in core.)

Being able to expand the system setting tray similar to how Ckeditor maximize works would be nice.

@Murz, good idea! Providing a contextual link to edit the block entity as a full page callback seems like a no-brainer. I feel like this should be available out of the box. Providing quick access to that edit page within the block editing interface within the systems settings tray should be provided as well.

Contextual link to the block edit form with the "use-ajax" class and data properties would be turn key.

There's a couple of things to think about here:

1. The default width of 300 is insufficient for custom blocks and many core blocks as it stands.
2. Not every interface needs the default of 300 for the editor width provided by \Drupal\Core\Ajax\OpenOffCanvasDialogCommand::DEFAULT_DIALOG_WIDTH.
3. Modules modifying layout builder would likely want to customize the display a bit for their specific use only.
4. A theme hook improvement only solves this issue at a theme scale and would introduce theme bloat to many modules while not allowing them to specify enhancements for only their blocks.

I'd like to propose the following solution, and if I don't hear any screeching alarms, we can roll a patch:

1. Layout builder's block configure display is set to 900 via $attributes['data-dialog-options'] = '{"width": 900}'; in core/modules/layout_builder/src/Controller/ChooseBlockController.php:235.
2. Layout builder is enhanced to read optional display (dialog) overrides from Block Plugin Definitions if they are present at core/modules/layout_builder/src/Controller/ChooseBlockController.php:159
   • This would allow custom coded module blocks to do things like present in a modal, display at the top, etc.

Changes layout builder default block configure display width to 900.

Just a quick note that this issue came up during recent UX testing we did on Layout Builder.

FWIW I was able to leverage @cyb.tachyon 's approach using hook_contextual_links_alter() to create a wider tray for our client without needing any core patches.

When I click Add Section, I have to alternately widen and narrow the window several times to see the whole width of the box (fortunately, I'm using dual monitors, otherwise this would not work without zooming the browser window contents way down in size. This is erratic though, and does not always work. It seems to be related to the viewport.

I'm using Bootstrap theme, Drupal 8.7.9.

Even if I can get the form to where it is visible and usable, it snaps back to a narrow column whenever anything within the form is clicked. Tried in Firefox Developer, Chrome and even IE. Also, the form sometimes disables scrolling of the whole browser window, and even when it doesn't, the form itself won't scroll with the other contents of the window (the page I'm editing).

Happy to provide any other info, but I'm not a coder. I did play around with the css and some of these seemed to help when I applied them in FF Developer, though I did not apply them into my site's stylesheet:

#drupal-off-canvas form { width: 600px; }
.dialog-off-canvas-main-canvas { padding-right: 100px; }

Look forward to trying it when I can get to the settings.

Updated patch that handles the block contextual edit link as well as section links (for sections with configuration forms).

re: #37 - we've found that a strategic preprocess hook can also achieve this. It's not exactly a performant solution, but does avoid a core patch in order to make the 'add block' dialog wider. Thanks for the idea!

/**
 * Implements hook_preprocess_HOOK().
 */
function my_module_or_theme_preprocess_links(&$variables) {
  foreach ($variables['links'] as &$link) {
    if (!isset($link['link']['#url'])) {
      continue;
    }
    $url = $link['link']['#url'];
    if (!$url instanceof Url || $url->getRouteName() !== 'layout_builder.add_block') {
      continue;
    }
    $link['link']['#attributes']['data-dialog-options'] = '{"width": 900}';
  }
}

Updated patch for v9.5.x.
Sets dialog width to 900px for these tasks:
- configure section
- configure block
- move block
- remove block

So, I went the route of making this a piece of configuration. There is no Admin UI yet for changing it. The benefit of this method is that to change the setting for all relevant links, you just need to update the configuration.

I'm sure there's things that I missed and there are no tests for the updates yet, but I set to "Needs review" so that someone can tell me what is missing and what should be tested.

FWIW - Gin LB's approach in letting the content creator resize their own sidebar is pretty nice :-).

@Luke.Leber thanks for pointing that out. I haven't had a chance to dig into the Gin LB implementation yet, but it looks similar to the core's (mostly hidden) off-canvas resizing capabilities. The main difference seems to be that in Gin LB they have the tray on top of the canvas, not next to it.

I've found the sidebar tray solution utterly unworkable for any significant content creation. For folks with the same problems I recommend https://www.drupal.org/project/layout_builder_iframe_modal as it frees up a LOT more space.

Coming in very late here ... I've recently been using Gin LB, and further customizing the off canvas sidebar dialog to:

• Add a visual indicator "handle" so it's more obvious that the left edge is draggable.
• Add a "toggle width" button in the title bar (next to close). Clicking this maximises the width to not quite full screen width. Clicking it again returns the sidebar to its previous width.
• Remember the width that the user has set for the sidebar on a per-dialog-route basis, and restore that when the dialog opens. Stored in browser localstorage. So the block-edit width can be wider than the section-delete width, etc. I may extend this to store per-block-type widths.

I think I'd like to add a way to set the default sidebar width on a per-route and maybe per-block-type basis, then let editors customise their own experience from there as above.

I'm not a fan of any system that always covers the content, ie layout builder modal. I've reverted the Gin LB "feature" that covers content with the sidebar. The content is responsive, right?

For the IS update. Also will have to dig but believe there is another ticket looking to fix the layout builder canvas.

Updated IS

Thanks!

Taking a look at the MR 4412 and see there is a schema change, so most likely will need a post_update hook?

Also the test failures seem legit to the issue.

Fixed failing tests.

Relooking at it I think it will definitely need an upgrade path

Also not sure about the no UI. Essentially someone would have to edit their yml files manually and import that way?

Going to subsystem maintainer thoughts

The proposal in #59 sounds like a good starting point. I don't think this should be something that a site builder should have to configure because essentially the preferred width would depend on the site, and the device the editor is using. 

Also, re: #59

An added bonus of preventing the sidebar from overlaying the content versus "squishing" it is that editors get a more diverse preview of what they're building. It can also help crack down on some use of non-inclusive / directional language (i.e. "The image to the right...") if the editors are more likely to see how that sort of language breaks down on different viewports 👍.

Would a screen capture of this be helpful? It would be gin-based but the concepts are theme-agnostic.

Like this. The sidebar width memory is per-route, which might not be ideal given add-block and configure-block are different routes, the user might expect setting the width in add-block would be remembered when you later edit the block. There is a maximum and minimum width on the sidebar, and a set width beyond which it does overlap content (so the content is never less than say 20rem wide). The toggled full-width state is not remembered. Very much WIP.

[OK, how do I display a video here?]

https://youtu.be/OPNK4zIOmLQ

The width per route was something I wasn't 100% certain because it might make the UX more complex than it needs to be. I've always wondered why does the off-canvas region resize when you click something. Usually the pattern is that the width remains consistent, even if the sidebar contents change.

Given that, maybe we could potentially simplify this by storing a single off-canvas width in the local storage, which is used when the off-canvas command doesn't include a specific width. This way the width would remain consistent when you navigate in the off-canvas, and when the off-canvas is re-opened.

I don't know where the 300px default width comes from, but I think it would also make sense to increase that so that we have a more reasonable starting point.

Gin LB already stores a single preferred width (which I have to fight to make per-route work). We could steal that.

I think I'm likely to try to zero in on 3 narrow/medium/wide default widths, figure out how to specify which one a given dialog should use by default, but still allow the user to override that and remember it. Somehow. It sounds like a good candidate for contrib.

300px is definitely too narrow a lot of the time. I think we are limited to a pixel value by the current ancient ui dialog code? I've been overriding that in the dialog setup to a nominal 400, but overriding that in css with a calculated rem- or vw-based minimum and maximum because frankly pixels suck as a width for practically anything.

The idea on 3 default widths sounds like a good idea to try but maybe we can try to keep this issue as simple as we can and leave testing ideas like this to a follow-up issues.

Changing the default value to 400 would already help a bit, so that might be a good starting point and we could open a follow-up to try to improve it further.

I believe that the next steps are (based on #59 and the discussion following that):

1. Add a visual indicator "handle" so it's more obvious that the left edge is draggable.
2. Add a "toggle width" button in the title bar (next to close). Clicking this maximises the width to not quite full screen width. Clicking it again returns the sidebar to its previous width.
3. Remember the width that the user has set for the sidebar on and restore that when the dialog opens.
4. Change the default width from 300px to 400px.

Updated the issue summary with these steps.

Change the default width from 300px to 400px.

We should modify this on devices narrower than say 480px, and screens where the vertical toolbar is present. We shouldn't ever cover the entire available width?

On mobile, it might be fine to cover the entire screen. There's no way we could provide both, the off-canvas and the page side by side with that little space. It's not an ideal experience but not sure we can do much better with the space that we have available.

My experience is that covering the entire screen has ux issues with some users not realizing they are still on the same page, and pressing "back". Leaving a narrow margin (say 5-10%) with the page visible underneath (layout at full width) mitigates that.

But if this is how the core dialog does things and has ux sign off, fine I guess?

That sounds like a valid UX issue. I'm wondering if we should open a separate issue for that to investigate if we could improve the designs and/or change how the navigating back behaves in this scenario?

Could do. I'll have a little time to work on this issue soon if nobody else jumps in. I have a decent POC without gin_lb now, it just needs working back into 11.x defaults.

I would love to see improvements like those suggested in #59. We had rolled our own version of the visible drag handle and a cookie to store the width for the user. The resize functionality for the off-canvas sidebar was broken in 9.5.x (and is still broken in the latest 10.1.x versions last I checked) and we were investigating reverting back to a static width as part of moving to 9.5. That is why I produced the MR that I did. We ultimately decided to keep our enhancements and just deal with the fact that the resize functionality is wonky. Looking forward to seeing the new version. If I get a chance I can try putting together something based on our custom functionality and/or Gin LB.