Add maximum width constraint to the dashboard and settings screens

[techanvil]

Feature Description

This is largely due to the dashboard and settings areas not being constrained to a max-width (which we should do and I believe was planned at some point but we haven't gotten to it). We should probably solve this on the larger level rather than trying to address it on individual components like this, but it looks odd to have components stretch so wide, especially those with a small amount of content. @sigal-teller

Similar notifications in module setup only stretch ~980 to 1024px IIRC

As raised by @aaemnnosttv, see the related Asana task.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

Maximum width content areas

• The dashboard and settings screens should have a maximum width of 1366px for the main content area (that is to say, Site Kit's content excluding headers and footers).
• The max-width content should be centered horizontally within the plugin's content area.
• Overlay notifications and surveys should be aligned so their right edges are flush with the right edge of the max-width content area.

Full width content areas

• The headers and footers (where one exists, i.e. the Key Metrics questionnaire screen) should remain full width.
• Notifications in the header should remain full width.
• Selection panels should remain aligned to the right-hand edge of the screen.

Implementation Brief

PoC PR here for reference

Set Max Width on the plugin and settings page content

• Update assets/sass/config/_variables.scss, add a page content max-width variable such as $page-content-max-width and set it to 1366px.

• Update assets/js/components/DashboardMainApp.js:

  • Wrap the OverlayNotificationsRenderer, all WidgetContextRenderer components in a new div <div className="googlesitekit-page-content"> - ensure the header, and selection panel components are not wrapped in this container.

Update the location of Overlay Notifications and Surveys

• Remove assets/js/components/surveys/CurrentSurveyPortal.js, as the layout of the survey is related to the page container a portal is no longer needed.

• Update assets/js/components/DashboardMainApp.js:

  • Remove the use of CurrentSurveyPortal to directly render CurrentSurvey if showSurveyPortal and currentSurvey are true:
    • Copy the following logic from the deleted CurrentSurveyPortal component into this component:

    • site-kit-wp/assets/js/components/surveys/CurrentSurveyPortal.js

      Lines 29 to 34 in 7d1c3bb

      	const currentSurvey = useSelect( ( select ) =>
      	select( CORE_SITE ).isUsingProxy() &&
      	select( CORE_USER ).areSurveysOnCooldown() === false
      	? select( CORE_USER ).getCurrentSurvey()
      	: null
      	);

• Update assets/sass/components/global/_googlesitekit-page.scss, setting the max-width for both of the classes googlesitekit-page-content and googlesitekit-module-page to variable created above, set the margin to 0 auto to center the page content column.

• Update assets/sass/components/overlay-notification/_googlesitekit-overlay-notification.scss:

  • Create a media query at the min-width of the variable created above.
  • When this breakpoint is reached, update the right value, using calc using (100vw - #{$page-content-max-width}) / 2)
    • This statement calculate the size of the margins around the page content dynamically and uses this to position the notification.
  • Adjust this value to account for the collapsed state of the WordPress menu using this approach.

• Update assets/sass/components/surveys/_googlesitekit-surveys-modal.scss:

  • Rename googlesitekit-portal-survey to googlesitekit-survey as we have removed the portal.
  • Create a media query at the min-width of the variable created above.
  • When this breakpoint is reached, update the right value, using calc using (100vw - #{$page-content-max-width}) / 2)
  • Adjust this value to account for the collapsed state of the WordPress menu using this approach.

Test Coverage

• No additional test coverage required, ensure there are no VRT failures due to these changes.

QA Brief

Changelog entry

[techanvil]

It's worth noting we've introduced a similar notification for Key Metrics:

[techanvil]

Hi @sigal-teller, as @aaemnnosttv has pointed out and can be seen in the screenshots above, the new notifications can look a bit odd in wider viewports.

We do constrain the width of existing/old-style notices for example here in the AdSense setup flow:

And, here's the same component being used with a CTA on the dashboard (this one looks a bit odd anyway in such a wide viewport):

As Evan has mentioned, it would be good to address this sort of thing in a holistic manner and adding a maximum width to the entire page would be well worth exploring. In fact it can be very easy to implement and I've mocked it up for illustration. I did a quick search for common maximum page widths and used this top-hit article as a reference.

Here's how the dashboard could look with a 1920px max-width:

And here's the Settings screen:

By comparison here's the dashboard at 1280px (I'd say 1920px is better):

And for reference, here are both the dashboard and Settings screen at the current unconstrained width:

I'm interested to get your thoughts on this, do you think we should add a maximum width to the pages as above and/or consider a more granular approach?

[sigal-teller]

Hi @techanvil Thank you for all your work here, it's very helpful. Yes, I think we should add a maximum width limit. In wide viewports the content stretches in a way that sometimes the CTA in the right is placed so far from the content and I'm not it can be missed. I think that we can improve the view by adding the navigation to the left of the content, like a vertical bar or something but that will require some effort both on the design side and the engineering side. I know that it was previously planned at some point but it was paused.

I think that for now we can settle for a simpler solution which will be an improvement to what we currently have. What you suggested sounds great. However I'm not about the center alignment since in the page there is a left bar (the WP bar). We can also align everything to the left, but that means we will need to align the nav bar as well.

I'm adding and example here of how it could look. I created a mock for wider viewport and a narrower one, just so it will be clear. I would love to hear your thoughts on this.

[techanvil]

Thanks @sigal-teller!

Your point about the admin menu is a good one, and the suggested layout is logical. However, to be totally honest I must admit I find it a little odd. To try to analyse my reaction, I suppose that with a wide screen the page feels a bit unbalanced, and aligning the nav to the left makes it a bit less prominent.

I thought I'd try retaining the centre-alignment for the nav but constrained to the max width, but I'm not sure if it improves it:

Coming back to your proposed layout; I am sure I'd get used to it, and it's only relevant for very wide viewports, so it's unlikely I'd see it that often anyway. Nevertheless, it does seem a bit unusual and it's hard to find examples of high traffic sites which have a similar layout, all of the ones I've tried have either a centred layout or unconstrained width. I feel like the left-aligned max width layout is something I've seen more of a few years ago, although there are bound to be plenty of current examples if you know where to look. I suppose it's also worth bearing in mind this is the admin section of a WordPress site so it can be expected to be a more "functional" layout.

Ultimately though, if we want to add a maximum width to the main content then it does seem a better fit when considering the position of the left hand menu. We could move the menu itself, adding a left-hand margin to bring the menu to the centred content but I don't seriously think we should, it would look odd switching between the other admin pages if we did that and the menu isn't really styled well for it either.

One thing I noticed while considering this is that the rest of the WordPress admin interface doesn't have a max width, it's unconstrained across all the standard pages, for example:

However, it's clear Site Kit would benefit from a constraint to the maximum width, so unless we have other alternatives to consider I'd be happy enough taking the left-aligned approach. Sorry, I know it's not the most wholehearted endorsement but that's my feedback, hope that it's helpful and interested to see what you think.

[sigal-teller]

Thanks @techanvil I agree that this is far from optimal solution. ideally we could have used the entire width while adapting the layout but this will require a whole new separate epic of design work which I don't think is currently planned. While doing a quick research I've seen various solutions to the wide viewports stretching issue. From the ones who limit the site width, some align to center and some align to left. Some WP plugins do align to center which is something to consider. Analytics for example align the content to the left (they also use left navigation bar). I'm not sure there is one single obvious choice here.
I can research it a little more when I have some time (there are some other things on my plate right now), or we can go with the center alignment which is more common in the WP space.

[techanvil]

Hi @sigal-teller, sorry for the delay replying, I had to prioritise FPM issues, and let this one slip a bit. I hear you on the other things on the plate front!

It strikes me this is such a substantial change to the layout, and without an obvious choice to make, it's not something we need to rush into and would benefit from taking a more considered approach with some additional research as time allows.

I'd also be interested in getting @aaemnnosttv's thoughts, as this stems from an issue he raised during the Audience Segmentation bug bash. We should of course also run this past @marrrmarrr to get her input and approval. I'll tag Evan on Slack in the first instance and we can take it from there.

[aaemnnosttv]

Thanks for all the thought you've all put into this so far – my thoughts are as follows:

I think we need not look much farther than the Google Analytics front-end "Home" and Search Console dashboard views as the closest parallels to the SK dashboard for guidance that is reasonable to follow (perhaps with more weight on GA since that's where most of the dashboard data comes from.

These interfaces share these common traits:

• Full-width header
• Centered max-width content that does not grow at larger screen resolutions

GA

SC

GA has a content width of 1280px where SC has only 912

---

In my experience, using a 1920w viewport, having things full-width is too wide (which is where this conversation started a while back). On the dashboard currently when the admin menu is open, the dashboard's content stretches to 1677px

IMO, if we matched the content width of GA (also centered), it looks much more comfortable. Matching SC would be too narrow I think.

It's worth noting that I think we should keep a max-width on text elements, such as text in notifications (as we do now?) to maintain good readability (see example from GA below). Together with a limited max width, I think we can have a more cohesive experience.

[sigal-teller]

@aaemnnosttv SGTM. I think that we can use this approach. There are still some elements we'll need to define, like the behavior of the lower right corner floating banners that we started to use, which might feel detached when placed outside the content area.

[techanvil]

Thanks @aaemnnosttv & @sigal-teller. Using the Analytics home page as a reference is a good shout.

My only concern is how a 1280px max width would impact the Key Metrics and Audience tiles.

For Key Metrics, there's more chance of content being truncated, and it would limit our ability to add other view types e.g. graphs in the tiles.

For the Audience tiles, it prevents the ability to show the full three tile view without truncating one of them:

I would suggest we choose a common viewport width that's a little higher than 1280px, e.g. 1366 or 1440. Here's how the Audience tiles would look:

1366px:

1440px:

WDYT?

[sigal-teller]

Thank you @techanvil I think that 1366px can work well as it's pretty close to the original designs width, if we're taking into account the additional width of the WP nav bar.

[techanvil]

Thanks @sigal-teller, that SGTM.

What do you think about the next steps here? You made a good point that we need to consider some other elements e.g. the lower right corner floating banners. It seems to me these should be addressed at the same time that we add the max width, whereas it might be sensible to address the maximum width text elements that @aaemnnosttv mentioned separately so as to allow us to take an iterative approach. Or, do you think we should prepare the design for all of these aspects up front so we can consider it holistically? Also, are there any other elements that spring to mind that we should address?

[sigal-teller]

Thanks @techanvil I'm not sure how this should be handled in terms of splitting this into several tasks, I guess this depends on engineering considerations as well. As for the elements that we need to take into account, I can't think of any other floating components besides the introduction banners, which we'll need to decide whether we should place them relative to the content or page boundaries. We also have the call out for banners dismissal that point on the settings in the left nav bar but shouls remain pointing at the right place so it won't change.
Can you think of anything else?

[techanvil]

Thanks @sigal-teller. Splitting the development into multiple issues is indeed more of an engineering concern. I was more thinking about things from a design perspective, whether some aspects might impact others when considering the changes as a whole, implying we should get the full design ready before starting engineering, or if we're comfortable defining and building it in iterative cycles.

On a related note, we should consider how we want to release the changes - if we'd be happy to for it to be potentially iterated on over multiple releases or if it should be released in one go (implying it should be behind a feature flag until it's ready for release).

Realistically, it's not going to be a huge body of work, so it shouldn't take too long to implement and can probably be tackled in a single sprint anyway, but we should allow for it being worked on over multiple sprints to be on the safe side; even if it's a relatively small amount of work, other deliverables may be prioritised over it.

I've taken a look through the plugin for components that we should consider when making the changes and have identified the following.

Notifications in the header:

Alignment of selection panels:

Footer navigation in the questionnaire screens:

Overlay notifications and surveys:

[jimmymadon]

@aaemnnosttv @techanvil When discussing the redesign of our Banner Notifications, @sigal-teller mentioned this issue. The newly designed Banner Notifications have been re-designed in a way that assumes that we will have a max-width for Site Kit content which is the aim of this issue. So ideally, this issue / set of issues need to be prioritised and worked on sooner than later.

What are the next steps here in terms of finalising the ACs / updating the scope and issue title here?

c.c. @binnieshah @ivonac4

[techanvil]

Hi @jimmymadon, I think the next steps here are:

• @sigal-teller to take a look at the related components that I've identified in my previous comment, and determine the UX approach (and maybe put a Figma design together). This will inform the overall scope of the issue(s).
• On the engineering side, we can then determine whether the changes can be addressed in a single issue, or if we need multiple issues. We can draft the AC for this issue and create others as needed.
• If we're tackling this over multiple issues we may want to introduce a feature flag to ensure the changes are released together.

[sigal-teller]

Hi @techanvil I think that the only component that requires attention would be the overlay banners/survey. I did address it in the banner notification epic while addressing this type of banner appearance in wider viewports. You can see it here. So basically we should place it within the content area to avoid detached placement in cases of extremely wide viewports.
Is there anything else that requires definition that is blocking from moving forward with this issue?

[techanvil]

Thanks @sigal-teller.

So, just to be clear:

• We can leave the selection panels at the right-hand side of the screen, and the footer navigation in the questionnaire screens can be full-width.
• We should however update the placement of the overlay banners & surveys as you've described.

How about the notifications in the header that I've identified in the screenshots above - are they taken care of in the banner notification designs? If so, how should we manage them in conjunction with the other maximum width work - it could look a bit jarring if we release the initial max-width changes without addressing the notifications, so maybe it needs to stay behind a feature flag until the notifications are ready too. WDYT?

[jimmymadon]

@techanvil

How about the notifications in the header that I've identified in the screenshots above - are they taken care of in the banner notification designs?

Yes, these are going to be redesigned as part of BNR3. The Setup CTAs will follow the pattern of widgets (only stretch to the content width and will have a margin all around them with rounder corners). As for the remaining Banner Notifications, their content will fit to the max content width but their background colour will stretch to the full width of the viewport.

If so, how should we manage them in conjunction with the other maximum width work - it could look a bit jarring if we release the initial max-width changes without addressing the notifications

I think the ACs for these issues here will be to do the bare minimum so that the white background in the Banner in your screenshot stretches the full-width of the viewport with everything else remaining the same.

[techanvil]

Thanks @jimmymadon - that sounds good.

I've updated the AC and moved the issue to IB. This will give us a good foundation to work on for BNR3 and also further refining maximum width content (e.g. text content that would benefit from a max width to make it easier to read).

[benbowler]

I tried a few approaches here and have found an effective approach captured in this draft PR. Some additional work is required such as accounting for the menu, however the behaviour in the AC appears well covered.

IB updated and I've set the estimate to 11 to allow for time for QA smoke testing across the many plugin and settings screens and flows.

[benbowler]

One addition not covered by the AC which could be is the module setup flow which still shows full width in this PR. Let me know if we should add this to the AC and IB.