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

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.

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.

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.

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.