Set maximum width on Seven

I'm working on this.

Basic patch that sets a width based on the wide breakpoint from seven.breakpoints.yml. The navigation is now outside this container, so that needs work. Also, lets discuss if we need more breakpoints or not.

I could only find one issue which is the border along the tabs.

I tweaked the media query so we don't lose the padding when the viewport becomes narrower than the max width. I changed the position of the tabs border so it always spans the width of the viewport.

I think this is a good idea. Even a complex UI like Views will benefit from keeping the screen components together, keeping things cohesive.

Would be great to see some screenshots from very large screens, we're all on our laptops here at drupalcon :-)

Can we fix the tabs in #1999182: Dream mark up for tabs

Here are a few screenshots with the patch applied (working on this at the mentored sprint at DrupalCon LA).

Thanks! Did you maybe screenshot only a part of the screen? I think we want to see it with the black toolbar so that we can see how that looks in relation to the centered content.

reviewed and tested at DrupalConLA

Also here at DrupalCon LA. Attached are a few screencaps from this 2880x1800 MBP Retina Display per the request in comment #14

Thanks for screenshots everyone! As of #18, we can't RTBC unless we fix the tabs. So I'm changing the status to Needs work again.

If anyone one to jump in and fix the tabs … feel free. :)

Thanks for additional screenshots. I'm not sure why the line for the tabs does not extend to full width there. I tested the latest patch on simplytest.me and there it looks ok.

Strange. simplytest.me uses beta10. Can we provide screenshots from the patch applied against the latest 8.0.x branch? If that done, if feel like we can set this RTBC.

+++ b/core/themes/seven/css/components/tabs.css
@@ -21,8 +21,8 @@
 .content-header .is-collapse-enabled .tabs:before {
-  left: -2.5em;
-  right: -2.5em;
+  left: -99em;
+  right: -99em;
 }

I'm sorry. Lewis fixed this. Marking as RTBC now.

Committed a70a74f and pushed to 8.0.x. Thanks!

Thanks for adding the beta evaluation to the issue summary.

Wow, awesome work everyone!

This doesn't play nicely with the vertical toolbar.
Take for example the views listing. There used to be a nice margin around it, it's now gone (maybe it needs padding instead)?

See https://www.drupal.org/files/issues/screencast-2015-05-20.mp4

And within the views UI, it now forces it into a much smaller space than before. And now after #2489884: Give the views modal window a larger width, the modals are often bigger than the underlying UI!

Drat -- I think we need to fix those regressions in the patch here, so reverted for now. Thanks @tim.plunkett for catching the regressions (and of course for everyone who's worked on this already).

So when we update this patch, we should test manually with both the Views UI and the vertical-mode toolbar, on narrow windows and adjusting the window size I think. Adding tags as well because I've now rendered the summary out of date.

I'll try to improve this later today. Thanks for reporting this!

Tweaked #8 patch to fix the vertical toolbar layout issue. Patch and interdiff attached. Attaching a video adjusting window size on Views-UI and admin configuration pages shortly.

Screencast attached showing the window re-sizing with vertical toolbar.

Or not :)

I'd just like to extend some kudos for these mp4s.

admin/structure/menu have still a scroll at 615px

Please find attached.

admin/structure/menu have still a scroll at 615px

This isn't a problem that is introduced in this issue, this is a problem being dealt with in #2280035: Add another responsive tables solution that doesn't hide content

I tested the latest patch for the spacing issue reported in #30 and it appears to be fixed.

The modal can be fixed to have the same max width as the rest of the UI in Seven's dialog.theme.css, so setting to needs work.

Patch to set max-width of modal to 1170px.

Before: Modal at 75% of screen width

After: Modal set to max-width of 1170px

The most recent patch is missing the changes from the previous patch

Does not look that good on 27" screen ---- worst offender is when editing views ( looks very compressed ).

merging changes in both #46 and #35. @lewis Please review.

Thanks. I manually tested this patch and I confirm that all the reported issues have been fixed. This will take a little bit of getting used to but I think it's for the best.

What about the horizontal toolbar - this seems to assume that as a screen gets bigger that the it should be left aligned. I guess the problem here is that this needs to look good in both front and back end so moving around is not an option. Toolbar is special.

For me the biggest issue with this change are pages like admin/structure/views on large resolutions because there is no edge so the left alignment looks really really odd. See screenshot attached.

@alexpott I remember discussing this in person at Drupalcon. Ultimately it's more important for the toolbar to be consistent across front and back rather than changing. #2539992: Move theme toolbar CSS to the Seven theme Will help with this.

For me the biggest issue with this change are pages like admin/structure/views on large resolutions because there is no edge so the left alignment looks really really odd.

It does feel odd, but it's hard to tell if this is just because we're used to the previous layout. I don't imagine that we would add a wrapper around the container, it doesn't fit with the Seven guidelines.

Breaking my d.o hiatus while on vacation to says: please don't commit this patch, please just mark it works as designed, because it does.

The last time this was committed I needed to revert it to get any work done on my 27" monitor. There is no justification given in the issue for why we would every want this. Please just leave the width well enough alone.

The issue summary literally says,

On a high level we have three arguments for this change:

This issue fixes basic usability problems on every other admin page.

I disagree with all three points.

Looks like this needs a product manager perspective.

@Tim, disagreement is fine, but please make counter arguments to the points listed. I have no strong opinion, but considering that this issue was initiated, and worked on, by both UX maintainers and the Seven maintainer, simply saying you disagree is not a compelling argument. And I'm confident you can do so in a more respectful manner than telling people you'll deal with the mess they make later.

All of the points in the issue summary seem completely valid, but for a front end theme.
Restricting the admin theme like this is Seven telling me that it thinks it knows what's best.

If I find the UI to be too stretched out on my 27" monitor, I can RESIZE MY BROWSER. I have the power!
Conversely, if this is committed, I need to write a subtheme or a module to override the CSS to make Seven sane again.

Won't fix, please!

+1 for tim.plunkett comments above --- on a large screen restricting seven width does not look good.

Why not use sane breakpoints then? Why blindly restrict widths after a certain point?

The patch essentially codifies that screen sizes above 1170px are unimportant, and hampers the administration of Drupal 8 on external monitors.

Once again, this makes sense for a front-end theme. It makes no sense for an admin theme, and can be considered a regression.

It does seem a bit odd in the age of "right content on the right device at the right time" that we would intentionally ignore widths > 1170px.

That said, I've read before and am familiar with the standards / best practices in the first two bullets of the issue summary, and those best practices were developed after thousands of websites and thousands of users over years of time. So simply ignoring them and saying we know better doesn't really make sense to me, esp. when it's all design-y people in here saying we should do this.

That said (again), Tim does raise an interesting point that because Seven is an *admin* theme, generally aimed at doing specific, complex tasks, it may make sense for it to be exempt. The studies upon which the UX guidelines are based are generally-speaking around front-end websites (I think).

I need more info here to make a call. Specifically:

• More evidence (one way or the other) that the guidelines around scannability and web typography either do or do not extend to complex admin interfaces (or that we don't know).
• Links to some updated standards (if such exist) on what to do with huge-sized displays. For example, I could see us introducing a "huge" breakpoint in Seven (afaik mdrummond has suggested such in relation to responsive images) that upped the font size / margins / whatever so that it addressed the legitimate scannability / typography issues in a way that simply made a 27" monitor look/feel closer to a 14" monitor, just at scale.

Feel free to re-assign once that information is gathered.

Anyone has tested how Seven looks on ultra wide monitors like this one? I suppose Seven is quite inconvenient there because of extended form elements. Why not to introduce a max-width setting to please anybody? I just did it for Seventeen theme.

I would agree with Tim on this being a usability regression. Because Seven is an administrative theme, is a wide variety of information displayed under it. Much of that information would be dense administrative content, such table displays of content containing many fields. For example, the default content list could be modified with Views Bulk Operations to display title, created date, updated date, author, edit/delete links, image thumbnails, and any other number of fields. The permissions page in particular can become a very wide table once you've added 6+ or more roles, which isn't an uncommon need for client sites. By restricting the main display to 1700px or some arbitrary amount, this could easily reduce the usability of the admin interface for a variety of use cases. Ultimately, there isn't a huge payoff in adding a max-width either, because the user can resize their browser to whatever size is most comfortable for them.

An alternative solution would be to try and resolve the specific issues mentioned in the original description. For example, if fieldset wrappers and descriptive paragraphs are excessively wide, then perhaps those elements should have a maximum width and font-size increase applied. This is already happening to a degree, such as with size attributes on text inputs.

Overall, I think setting a maximum width on Seven would only serve to restrict the administrative interface for the very users that are likely to use it beyond that restriction. As of today, the average user would not likely have a monitor larger than 1920px wide due to a prohibitive cost. Meanwhile, power users and professionals with large monitors who would be able to take advantage of the interface at that size would be restricted from doing so.

I'm glad we didn't ship with this, as there's loads of UI instances in contrib that we haven't accounted for. The node edit page is a good example of a situation where there is limited space due to a new design and contrib modules like inline entity form commonly run out of horizontal space even without the max-width.

Maybe we should allow modules to override the max width on specific pages? It's better to acknowledge the exceptions.

Removing the Novice task as this issue is now in a state where it needs clear direction and decisions before any more work can take place.

Many valid points here, and also uncovering an often-overlooked detail:
Admin UX is of considerable importance. Many of us contributing here have years of experience working with Drupal, and have become accustomed to its quirks. In doing so, we may have forgotten how challenging some processes can look for someone unfamiliar with platform (even if skilled with other CMFs).

Good interface guidelines can help greatly in making things more coherent, and convey vital points more quickly. Sadly, admin UX is often left out of this discussion. Sure, there are some opinions that need to be set, but can be confirmed valid if tested in solid UX research.

As others have noted above, there are edge cases where a design decision may need to be overridden, but a general improvement to the admin UX could help greatly in everyday use for site editors and admins.

Patch #49 failed to apply to 9.1.x.
Review the patch attached screenshot for the reference.

Applied patch #86 working fine sharing screenshot ....

Patch #86 applied and working as accepted, i just changed layout-container width 95% to 100%. and rolling up patch with interdiff.

Please review.

Fix for custom command fail.

Re uploading patch with interdiff as patch #89 is Custom Commands Failed.

Max-width is set to 1170 for screen sizes above 1200px.

Adding an after-patch screenshot for reference.

This change is potentially disruptive to modules and themes extending Seven. Seven is internal so technically we would be allowed to introduce changes like this. Since this issue has potential side effects that would require work to address, and we are moving focus to working on Claro, I think it would be better to close this issue.