-
Notifications
You must be signed in to change notification settings - Fork 641
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
Add banner to all pages #8579
Add banner to all pages #8579
Conversation
Do we want it on all pages? How did we pick this specific set? |
yes, we want to it on all pages if this possible. the reason why pick those pages is it has high traffic to thoses pages, especially display package details pages. it has traffic from PMUI or google. |
@@ -3,6 +3,7 @@ | |||
@{ | |||
ViewBag.Title = "Manage My Package"; | |||
ViewBag.Tab = "Packages"; | |||
ViewBag.DisplayBanner = Model.DisplayBannerFeatureEnabled; |
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.
Can we do this in the Layout.cshtml + NuGetViewBase?
https://github.com/NuGet/NuGetGallery/blob/main/src/NuGetGallery/Views/Shared/Gallery/Layout.cshtml
https://github.com/NuGet/NuGetGallery/blob/main/src/NuGetGallery/Views/NuGetViewBase.cs
This would hit every page.
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 am not sure about this approach. if we include in NuGetViewBase, which means flag for banner will be in the configure file instead of feature flag json file. let me know if my thinking is in right track?
Can we make this banner dismissible? It is very annoying to see it constantly for folks who don't care. It was tolerable when it was only on the home page but the user experience is terrible once we enable this on all pages. When asking for survey we should only ask it once when the page is opened after that allow it to be dismissible or it should auto-dismiss i.e. hide it after sometime if the user doesn't click on it, or say user logs in. Even if the user decides to respond to a survey why would we want to show the banner again. |
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 would avoid putting this on all pages, or at least redesign the banner to be dismissible.
The reason why we want add to most of pages is because that we are getting small amount of customers' responses this time comparing last time. We want to get more feedback with more banner visible in more pages |
@shishirx34 Some more context to not letting the banner be dismissed - the main reason why we decided to sidestep that functionality (for now) is because 1) saving the dismissed state for future sessions from the users would require additional engineering work that given the 2) relatively short windows - usually a week or two - during which the survey is out, might not be worth it. Completely agree though that as we have surveys that are out for longer or are more visually distracting, we should allow the banner to be dismissed and/or not show on all pages. |
@jcjiang - I disagree. Even the period of 1-2 weeks is too long of a period to showcase this anti-pattern. We get millions of views every week on the gallery. I've had personal experience with some users being annoyed when asked to give feedback for not using 2FA after login and this was a one time pop-up. I am certain lots of users will find this annoying. Being persistent and annoying at showing this banner to users just to get the feedback is not a good way to get the data, moreover, it disinclines the users to actually follow through. I remember that we had some form of survey (HATS?) where we had a "feedback" side rollout pop-up which was a much better way of getting feedback (and this was designed by ux team). This banner is pretty loud with a color scheme that doesn't really go with the site for continuous view and at the top of the page, designed by us with no ux lead or user research. Let's say a user does provide you with the feedback, we still continue to show this banner to that user which isn't a good user experience. I believe this banner was introduced for BLM support and now we are extending, probably misusing, it for survey purpose. We should either find a different way to get feedback, or at the very least invest engineering effort on making this dismissible so that it is reusable in the future. We should have a discussion offline if you still disagree. /cc: @skofman1 |
After discussion, we decide to display banner to all pages now due to reasons following:
We will add dismissible button for next NuGet.org survey to improve customer experience. Thanks for all input and all considerations! |
cookieExpirationService.Setup(e => e.ExpireAnalyticsCookies(It.IsAny<HttpContextBase>())); | ||
featureFlagsService.Setup(e => e.IsDisplayBannerEnabled()).Returns(false); |
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.
It's better to have a separate test for the banner flag.
InvokeOnActionExecutedMethod(controller.ControllerContext, httpContext.Object, controller); | ||
|
||
// Assert | ||
Assert.False(controller.ViewBag.CanWriteAnalyticsCookies); |
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 assert on analytics cookies? There is already a UT up there to do the same.
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.
Please limit UT assertions to only describe the UT name, i.e. the name of the "fact".
cookieExpirationService.Setup(e => e.ExpireAnalyticsCookies(It.IsAny<HttpContextBase>())); | ||
featureFlagsService.Setup(e => e.IsDisplayBannerEnabled()).Returns(false); |
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.
There is no need to verify the banner flag in these two tests for cookies, if we have another test to cover it.
// Arrange | ||
var cookieExpirationService = GetMock<ICookieExpirationService>(); | ||
var featureFlagsService = GetMock<IFeatureFlagService>(); | ||
cookieExpirationService.Setup(e => e.ExpireAnalyticsCookies(It.IsAny<HttpContextBase>())); |
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.
You can also remove this setup and verification because we test the banner flag here.
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.
it's private method. I don't think we could remove the set up. let me know if I am wrong.
Summary of the changes (in less than 80 characters):
before: banner only show on the home page
after: banner show on all pages
package details page:
Upload package page:
Addresses #8525