1815592 - Allow both sign in button and dismiss button to fit on the same screen together for cramped window sizes

Status: NEW

(Firefox :: Messaging System, enhancement, P3)

Description

[Shane Hughes [:aminomancer]]

While working on bug 1809722, Punam and I encountered an issue with our multistage spotlight/about:welcome layout. Currently, no message has both a top-positioned secondary button and a dismiss button, but we intend to support this for future window modal new user dialog experiments.

In bug 1792535, an issue was reported where the Sign in button (which normally sits outside the screen dimensions, in the top right of the window) was lost behind the screen, because the window was too small (or too zoomed in) for anything to fit outside the screen. Basically, if the screen (the card area where most content appears) dimensions approach the size of the window, the Sign in button would disappear.

We resolved this by making the Sign in button move inside the screen when these problematic window dimensions arise. If the Sign in button can't fit outside of the screen, we simply move it inside the screen. Since it normally goes in the top right corner of the window, under these conditions it moves to the top right corner of the main section of the screen.

But now we're adding a dismiss button, which is designed to go in the same spot — the top right corner of the main section of the screen. In "responsive layout" mode (window of height < 650px, width < 590px), adding a dismiss button is not a problem, because in those situations, the Sign in button goes in the main section (the bottom section) while the dismiss button goes in the secondary section (the top "header" section where the image is). So they don't overlap.

But in the regular layout, when the window's height is less than 650px, width is less than 990px, but greater than 800px, the sections are still aligned side-by-side, but the Sign in button still can't fit outside the screen. So it needs to move inside the screen, but the top right corner of the main section is occupied — that's where the dismiss button goes in the normal (non-responsive) layout.

Currently, in bug 1809722 we're resolving this issue by simply hiding the Sign in button for that specific window size range. It will appear in responsive layout mode, and it will appear if height is greater than 650px or width is greater than 990px. But in that specific range (height < 650px; 800px < width < 990px) where the Sign in button wants to overlap with the dismiss button, we simply hide the Sign in button.

This is unfortunate of course, we'd like to keep the Sign in button around. And there will be many messages that have no dismiss button, but we're still affecting them nonetheless, because we haven't added logic for distinguishing between those cases. There are lots of potential solutions. Some require extra JS logic, while others can be pure CSS, but may not match the current design.

So, because this requires a design decision, we're filing a new bug and posting some of the ideas in here for UX to review.

Comment 1

[Shane Hughes [:aminomancer]]

Attachment: Sign-in button aligned to top left corner

1. Move the Sign in button to the top left corner of the main section, rather than the top right. This makes the y position the same as the dismiss button's, and looks visually nice IMO, but it has an added cost. It requires us to either: A) add new JS logic to identify when a dismiss button is present, and produce this special layout, so the Sign in button will move out of the dismiss button's way; or B) apply this special layout whether the screen has a dismiss button or not, so the Sign in button will appear on the left for these cramped window sizes, even when there's no dismiss button.

Comment 2

[Shane Hughes [:aminomancer]]

Attachment: Sign-in button aligned to top right corner, but underneath the dismiss button

2. Keep the Sign in button in the top right corner of the main section, but move it down by 48px so it doesn't overlap the dismiss button. As with solution #1, applying this new position only when there's a dismiss button present will also require additional JS logic.

Comment 3

[Shane Hughes [:aminomancer]]

Attachment: Sign-in button aligned to top right corner, but there's no dismiss button on this screen, so there's some empty space above the Sign in button

Otherwise, we can apply this special position even when there's no dismiss button (pictured here). That doesn't require any extra JS, but it does mean there will be 48px of extra space above the Sign in button.

Comment 4

[Shane Hughes [:aminomancer]]

These are just the 2 options that occurred to us immediately, but other positions could work too, e.g. positioning the Sign in button on the bottom left. We're open to any suggestions. Thanks!

Comment 5

[Punam Dahiya [:pdahiya]]

Currently, in bug 1809722 we're resolving this issue by simply hiding the Sign in button for that specific window size range. It will appear in responsive layout mode, and it will appear if height is greater than 650px or width is greater than 990px. But in that specific range (height < 650px; 800px < height < 990px) where the Sign in button wants to overlap with the dismiss button, we simply hide the Sign in button.

Looks like there is typo, it should be 800px < width < 990px. Will be great if we can attach screenshot of this edge case as fixed in bug 1809722. Thanks

Comment 6

[Shane Hughes [:aminomancer]]

Attachment: Overlapping dismiss and Sign in buttons

(In reply to Punam Dahiya [:pdahiya] from comment #5)

Currently, in bug 1809722 we're resolving this issue by simply hiding the Sign in button for that specific window size range. It will appear in responsive layout mode, and it will appear if height is greater than 650px or width is greater than 990px. But in that specific range (height < 650px; 800px < height < 990px) where the Sign in button wants to overlap with the dismiss button, we simply hide the Sign in button.

Looks like there is typo, it should be 800px < width < 990px. Will be great if we can attach screenshot of this edge case as fixed in bug 1809722. Thanks

Nice catch, thanks!

Here's a screenshot of the issue we're hoping to resolve (currently this doesn't happen because we hide the Sign in button when this would happen, but we'd like to keep both buttons visible)