-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
amp-consent iframe modal UI #29204
amp-consent iframe modal UI #29204
Conversation
background: white; | ||
flex-direction: column; | ||
height: var(--lightbox-height); | ||
width: 90vw; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of curiously, how is the 90vw picked?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Confirmed with Zewen: We wanted a margin on the left and right to clearly show that the consent prompt is appearing above user content, which would be better UX.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have we tested desktop (wide viewports)? This might need a max-width
in pixels.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, Zewen said it is best practice to include a max-width
so that the text isn't too stretched and hard to read. He suggested a value of 760px. Updated the description.
@micajuine-ho Why is the maximum height 80vh? Can this be increased to 90/95vh while additionally hiding the AMP viewer when the lightbox is launched? Currently when we go into fullscreen we'd get 100vh and the AMP viewer would be hidden for maximum space. With this PR as it stands we'd be gaining an extra 20vh for the initial prompt but then losing 20vh from the settings view of our CMP. This is not an ideal compromise. |
Hi @hrkhal Thanks for your feedback.
This is safe height for the consent iframe; it creates a large enough margin on the top and bottom (on all major browsers), to clearly show users that the consent prompt is above their content and that they must interact with it.
While we could increase the VH limit, the more we do so, the less apparent it will become to the user that their content is being blocked by this consent prompt, which would lead to a bad user experience. This problem is similar to issue #26197 (since lightbox mode would trigger without user interaction), and we would like to avoid that type of situation. Additionally, a change from 80vh to say 90vh should not have much impact, unless all the the disclaimers, information, and buttons will be shown in 90vh rather than 80vh.
Thanks for the suggestion! I have edited the PR to include this.
The intent of this feature is to allow a way for more information to be shown immediately on iframe loading, while maintaining a good UX. Can you elaborate on what you mean by "settings view". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
A few things that I'd like the UI team to review
- Since this is a lightbox experience. Is it possible to reuse methods/css from amp lightbox?
- When the consent UI takes the entire screen, does it affect other UI component. For example I found amp-side-bar has a higher z index compared to amp-consent.
@micajuine-ho The settings view would be the second layer of a GDPR TCFv2 prompt where you're able to review your consent status for all of the vendors and purposes. See the below image. Loosing height here makes an already cramped UX worse. We can obviously rejig the UI to make better use of the space but in general more height is preferable. What's the eta for getting this into production? Cheers. |
How would you get to this view? By hitting the manage button after making an initial consent decision?
We are still waiting for review from the UI team (ping @alanorozco). |
In our case the user would hit a
Understood. I'd like to state that the deadline for TCFv2 is fast approaching (15th August 00:00 BST) and as a publisher we'll need a few days to implement this light box change and have it reviewed internally before we could get it to production. Ideally we'll be using this UI on day one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's reconsider how this is done conditionally.
Maybe we can remove a couple of clauses for checking whether it's a lightbox, and use compound CSS selector for the styling props that change instead.
Consider also sharing class names that aren't necessary for either mode, but have no effect to reduce complexity.
@@ -118,17 +118,33 @@ amp-consent.i-amphtml-consent-ui-iframe-active { | |||
transform: translate3d(0px, 100vh, 0px) !important; | |||
} | |||
|
|||
amp-consent.i-amphtml-consent-ui-iframe-active.i-amphtml-consent-ui-enable-border { | |||
amp-consent.i-amphtml-consent-ui-enable-border { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think for customization we should leave these classnames open (without i-amphtml
) and use !important
properties for whatever we find necessary. IMO, border-radius
and box-shadow
should be able to be modified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Customization could be a nice feature for developers. I am down to address these changes in a future PR, since removing !important
could be breaking.
background: white; | ||
flex-direction: column; | ||
height: var(--lightbox-height); | ||
width: 90vw; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have we tested desktop (wide viewports)? This might need a max-width
in pixels.
@@ -362,14 +372,20 @@ export class ConsentUI { | |||
data['initialHeight'].indexOf('vh') >= 0 | |||
) { | |||
const dataHeight = parseInt(data['initialHeight'], 10); | |||
// Set initialHeight to max height fallback if applicable | |||
this.initialHeight_ = | |||
dataHeight >= 80 ? MAX_INITIAL_HEIGHT : this.initialHeight_; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why 80
? Name this number as a constant if arbitrary, for future context.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
80 is the MAX_INITIAL_HEIGHT
agreed upon
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Meaning, maxInitialHeightForModal
or how would you express it? It's just about giving it a name in the code.
if (this.enableBorder_ && !this.lightboxEnabled_) { | ||
classList.add(consentUiClasses.enableBorder); | ||
} else if (this.lightboxEnabled_) { | ||
classList.add(consentUiClasses.enableBorderLightbox); | ||
this.sendViewerMessage_(REQUEST_OVERLAY); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Flip to simplify conditional clause.
if (this.enableBorder_ && !this.lightboxEnabled_) { | |
classList.add(consentUiClasses.enableBorder); | |
} else if (this.lightboxEnabled_) { | |
classList.add(consentUiClasses.enableBorderLightbox); | |
this.sendViewerMessage_(REQUEST_OVERLAY); | |
if (this.lightboxEnabled_) { | |
classList.add(consentUiClasses.enableBorderLightbox); | |
this.sendViewerMessage_(REQUEST_OVERLAY); | |
} else if (this.enableBorder_) { | |
classList.add(consentUiClasses.enableBorder); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
Also, consider flipping
enableBorder_
to matchlightboxEnabled_
, that way you can use a compound selector and only send the message for lightbox. -
In any case, you should use the
Viewport
service for this, don't talk to the viewer directly.
if (this.enableBorder_ && !this.lightboxEnabled_) { | |
classList.add(consentUiClasses.enableBorder); | |
} else if (this.lightboxEnabled_) { | |
classList.add(consentUiClasses.enableBorderLightbox); | |
this.sendViewerMessage_(REQUEST_OVERLAY); | |
if (this.enableBorder_) { | |
// This classname is applied differently by CSS selector | |
classList.add(consentUiClasses.enableBorder); | |
} | |
if (this.lightboxEnabled_) { | |
this.viewport_.enterLightboxMode(); | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In any case, you should use the Viewport service for this, don't talk to the viewer directly.
Following the precedence set here #23491; basically this.viewport_.enterLightboxMode()
does more work than we need.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which work is unnecessary? If it doesn't affect the use case negatively, I'd say it'd be better to consolidate implementations rather than duplicate them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I agree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LG on my side. Please get approval on the UI changes from the UI team.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just nits, I think there are opportunities to simplify but overall LGTM.
* init, no tests * tests * documentation + cleanup * Suggested Changes * Suggested Changes * Lightbox => Modal, housekeeping, clarity * Compound classes
Overview:
modal
rather than abottom sheet
, viapromptUiSrc
modal
mode will always include the overlay and force borders/box shadowready
postMessage sent by the iframe, anyvh
value between (60-80] will trigger the newmodal
UImodal
is enabledChanges:
modalEnabled_
andoverlayEnabled_
.modal
andmodal.enableBorder
.modal
has!important
styles to override someiframeActive
rules--i-amp-modal-height
) set on the element style to be'${initialHeight}vh'
to customize the height of the modalborderEnabled
to round all corners of the modalfullOverlay
from Viewer to hide Viewer header (similar to fullscreen mode)modalEnabled_
, don't allow iframe to enter fullscreenhide()
, remove.modal
&.borderEnabledModal
initialHeight
&enableBorder
Notes:
width: 90vw
is used for the modal. Essentially, a margin of 5 on left and right to clearly show that the consent prompt is appearing above user content.80vh
to show that consent prompt is appearing above user content (giving more room for underlying content to be shown). This was found to be a safe value when tested in all different browsers (no conflicts with navigation bar etc...). Additionally, there is no real difference between80vh
and90vh
unless all of the content will be shown in90vh
vs80vh
and thus no scrolling. Otherwise, user will still have to scroll down to the bottom to reach the consent decision buttons.Normal Ampdoc:
Simulated Viewer:
Widescreen Desktop: