Node form: address chasm between main form and meta

To keep a consistent experience with Umami, we would max width everything (content and header area) to 1200px at the 1280px breakpoint.

I think that makes sense, and would keep all of the elements close for pointer travel and eye movement.

There was a similar discussion in the Seven issue queue which might be worth checking for some of the arguments for both sides: #2486453: Set maximum width on Seven.

On first glance this max-width + centering appears to be the most elegant approach. I remember that Cristina wanted to look at this more closely as well, I hope she can chime in here.

Thanks for linking the similar issue for Seven Lauriii, there's good arguments for and against. Also:

- We might also consider this as an optimisation for this specific page?
- Who would like to do a bit of competitor benchmarking and collect some screenshots for how other systems approach this?
- Contrib modules that extend this page should be taking into account. It was an important factor in *not* limiting width on this page: https://www.drupal.org/project/drupal/issues/2486453#comment-10627774

Tested patch from #4 and result is following:

1. Edit node page is OK now Screenshot
2. Content on all pages is centered now Screenshot
3. Popin takes whole width (i am not sure this is related to changes here, but need to be be checked)

+1 on the idea to max-width and center the content.

Basically the next thing which is a far outcry to implement layers at some point 😉
That's also basically what Gin uses currently (including the layers to better distinguish the regions).
The end result at a later stage should look more like this:

(As an example, ignore the sidebar nav approach and fixed header for now).

I did a bit of analysis on what our competitors are doing. I tested Wordpress, Contentful, Prismic and Strapi. I have following remarks from that:

1. None of these applications had a max width for the whole layout
2. All of these applications had a slightly different layout for the content edit form compared to the rest of the application
3. All applications except Strapi had a content edit form layout where a static width meta column is on the right side of the page, and the main form has a max width that is centered on the rest of the space. Strapi uses similar pattern, with the exception that there's a layer behind the form that is full width and the max width is only defined for the form elements.

If we wanted to implement something similar to what most of the competitors are doing, we could implement this layout for the content edit form:



This would allow users with large monitors to take advantage of the horizontal space on Views UI as well as pages that have large tables.

All applications except Strapi had a content edit form layout where a static width meta column is on the right side of the page, and the main form has a max width that is centered on the rest of the space. Strapi uses similar pattern, with the exception that there's a layer behind the form that is full width and the max width is only defined for the form elements.

@lauriii this is basically exactly what Gin is already doing 😉🙂

Here's patch for the approach proposed in #11 for further testing.

Discussed this with @ckrina, @bnjmnm, @katherined, @shaal, @yoroy, @saschaeggi and @nod_ as part of the Claro call today. We agreed that while the solution proposed in #11 isn't perfect, we think it's improvement to the status quo. Main concern on the solution was that it could create disconnect between the title and the content on wide screens. The group thought unanimously that the benefits outweigh the downsides and we should move forward with this, and try to come up with a better solution as part of #3076820: [META] Layout redesign.

As part of testing #13, could someone upload a screenshot of what it ends up looking like if you're using Paragraphs, including nested paragraphs?

Also, what happens (and what do we want to happen) when you switch between the "Edit", "Translations", and "Layout" tabs? Any other local tasks (from popular contrib modules) that we should also consider?

Some clean up on top of #13 which was mainly created for demonstration purposes.

#15: +1 to testing with Paragraphs. We should also test with Metatag module because it is commonly used contrib project that is adding form elements to the meta column.

#16: I think the assumption right now is that they shouldn't be impacted by this change since this change is only about the Node edit form layout. I think it's good idea to check that this change doesn't have impact on those pages.

Applied patch #17 successfully.

The chasm issue is better now. Space between primary form and meta area is reduced considerably. Also the width of meta section is also reduced.

The comparison is made by applying Claro theme (for administration also) in a Drupal 9.1.x-dev instance with the "Umami" demonstration site. The same recipe shown in the issue screenshot is chosen for better understanding.

Before patch

After patch

I've tested patch #17 with Paragraphs and Metatag and think this looks good to go. I initially worried that the misalignment with the header and the form might be jarring, but after comparing a couple other large CMS projects, I think this pattern is closer to the expected norm right now.

Paragraphs

Metatag

Rerolled as it did not apply anymore to the info file (as per testbot result as well). Keeping RTBC awaiting testbot.

Reviewing the comments above #16 was not yet answered. What is the experience for this case?

Also, what happens (and what do we want to happen) when you switch between the "Edit", "Translations", and "Layout" tabs? Any other local tasks (from popular contrib modules) that we should also consider?

Any local tasks would still use the full-width layout. In my opinion it makes sense because they are using a single column layout. We might make changes to that layout in #3076820: [META] Layout redesign. I believe that was also the consensus that was documented in #14.

Here's a screenshot of how paragraphs look with the new layout. I don't know how many levels we should be testing, but form elements have around 550px width left when nested 3 times. The layout width is similar to what user with a 1300px wide viewport would width. 1366x768 is the most popular screen resolution based on https://gs.statcounter.com/screen-resolution-stats so it's a screenwidth that Claro and all contrib modules should be able to accommodate any way.

We agreed as part of discussion mentioned in #14 that the solution here is no means perfect, but that it would be a great next step. We also agreed that we would be willing to adjust this based on feedback from users.

Yeah I think @alex.bronstein was referring to the jumping around of the left side of the page between different admin tabs even on the node page. Eg. Revisions or Translate would be differently positioned and the centering only applies to the node editing form and even then only to the left side of it. I'll try this out for myself.

Here are comparison screenshots with Seven:

It may be strangeness of the new experience, and jumping from the node list does not feel like a problem. But coming from the translation table from the same admin list feels odd:

https://www.drupal.org/files/issues/2020-10-16/Screen%20Recording%202020-10-16%20at%2014.59.07.mov

For reference, here are nested paragraphs with a CK Editor long text field, similar to the test in #31.

Crediting reviewers mentioned in #14.

I asked @Gábor Hojtsy if he thinks #33 should block commit, and he said no, and I agree.

All my other concerns earlier in this issue have been addressed as well (thank you for #34).

Therefore, pushed to 9.2.x and 9.1.x. I'm happy to see this make it into the 9.1 alpha, and I'm curious what the feedback will be from people who test it.