Skip to content
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

Track if users has dismissed a version warning banner for a given version. #1763

Merged
merged 4 commits into from
May 24, 2024

Conversation

Carreau
Copy link
Collaborator

@Carreau Carreau commented Apr 10, 2024

See #1384

If a user dismiss the banner it should apply to all pages.
One remaining questions is :

  • does it apply to all versions ?

This implement a dismiss button and store in local storage which version and when the user has dismissed it.

This is enough informations to refine the logic later with what/when we want to show.

This also has a rough implementation of not showing banner for current dismissed version for the next 14 days following any banner dismissal.

@drammock
Copy link
Collaborator

thanks for tackling this! My feelings:

  1. close button should not be the letter "x", should be 🗙 (U+1f5d9, "cancellation X") or https://fontawesome.com/icons/xmark?f=classic&s=solid. Not sure about horizontal alignment; I was envisioning it right-aligned (near the viewport edge) but no strong feeling there
  2. I'm not sure how to choose the duration of the dismissal. 1 month feels too long to me, and really anything other than "the duration of this browsing session" feels arbitrary. So I lean toward not doing any calendar-time-based memory.
  3. Generally I think it's a good idea to "dismiss for all versions". E.g. for version warning banners, if someone's on an old version and then goes to a different old version we can probably assume they did it on purpose / are specifically seeking info about older APIs, so we probably don't need to warn them again. For general announcement banners, I think it's even clearer that it's OK to dismiss once for all versions.

@Carreau
Copy link
Collaborator Author

Carreau commented Apr 10, 2024

  1. close button should not be the letter "x", should be 🗙 (U+1f5d9, "cancellation X") or https://fontawesome.com/icons/xmark?f=classic&s=solid. Not sure about horizontal alignment; I was envisioning it right-aligned (near the viewport edge) but no strong feeling there

Same feeling here, just did not had time/skills to do that.

2. I'm not sure how to choose the duration of the dismissal. 1 month feels too long to me, and really anything other than "the duration of this browsing session" feels arbitrary. So I lean toward not doing any calendar-time-based memory.

This is why I store the date of dismissal instead of storing (date+1month), so that we (as developers) can refine that later. The date could be treated as a boolean, or we can include a footer to reset or change the duration per user. I'm not attached to a particular logic. I just think it's good to give us the option of ignoring a previous dismissal.

3. Generally I think it's a good idea to "dismiss for all versions". E.g. for version warning banners, if someone's on an old version and then goes to a different old version we can probably assume they did it on purpose / are specifically seeking info about older APIs, so we probably don't need to warn them again. For general announcement banners, I think it's even clearer that it's OK to dismiss once for all versions.

I agree, I think there is basically 3 groups of versions:

  • devs/unreleased
  • stable(s?) – this one should have no waring anyway
  • older

The main question is do we want to separate devs from older or treat both same.

@Carreau
Copy link
Collaborator Author

Carreau commented Apr 12, 2024

  1. close button should not be the letter "x", should be 🗙

does not seem to show properly on my machine, so I went for the fa-icon.

I'm not sure how to make the close button go on the right edge of the page without sending the test of the banner on the left or adding a bunch of intermediate divs (would that be ok ? )

The way the annoucement banner are done is completely different, and is in the Jinja templates.

Should the two kind of banner creating logic be unified ?

@drammock
Copy link
Collaborator

The main question is do we want to separate devs from older or treat both same.

I think ideally they would be treated differently (?) but I'm content with either way if one of them is much harder to do.

I'm not sure how to make the close button go on the right edge

putting classes ms-auto me-auto on the bd-header-announcement__content div (plus maybe class me-3 or so on the close button) sort of works, but it aligns the X to the container (which is not the full viewport width on large screens). But maybe that's good enough for now?

The way the annoucement banner are done is completely different, and is in the Jinja templates.
Should the two kind of banner creating logic be unified ?

Ideally yes. But that could be another PR.

@Carreau
Copy link
Collaborator Author

Carreau commented Apr 15, 2024

Oh, yes, the ms- and me- work great. I haven't added the me-3 to the button as the css inspector says it is ignore/does not apply.

I think the "wrong" position of the close button is because the banner use custom margin/padding. I think it probably could use the same css values/classes as the nav bar with .bd-page-width, but that will requires a bit of refactor and extra divs I belive.

Maybe let's leave the for refactor that consolidate the various banners code.

Copy link
Collaborator

@drammock drammock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Carreau I rebased to remove merge conflict, and pushed a few extra commits to tweak the JS (most notably I changed the timeout from 1 month to 14 days). Commit msgs are fairly descriptive of what else I did.

Copy link

github-actions bot commented May 21, 2024

Coverage report

This PR does not seem to contain any modification to coverable code.

@Carreau
Copy link
Collaborator Author

Carreau commented May 22, 2024

All seem good to me, I was just wondering why let instead of const, but it does not matter much.

@Carreau
Copy link
Collaborator Author

Carreau commented May 22, 2024

No, getDate() is wrong, it returns the day of the month, if you dismiss anytime past the second half of the month, it will never com back

@Carreau
Copy link
Collaborator Author

Carreau commented May 22, 2024

I fixed the .getDate() that was wrong by actually calculating the . I think 14 days is a bit short, but we can still change later.

The setMonth(getMonth() -1) (or setDay(getDay() -14)) works as it does the wrap around and decrement the year (resp Month). But computing the delta was not ok because it's bound in 1-12 (1-31).

@Carreau Carreau requested a review from drammock May 22, 2024 13:52
Copy link
Collaborator

@drammock drammock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The setMonth(getMonth() -1) (or setDay(getDay() -14)) works as it does the wrap around and decrement the year (resp Month). But computing the delta was not ok because it's bound in 1-12 (1-31).

Thanks for catching that, I didn't test carefully enough

@Carreau
Copy link
Collaborator Author

Carreau commented May 23, 2024

This picked up conflicts... :-(

…sion.

See pydata#1384

I think we all agree that if a user dismiss the banner it should apply
to all pages. One remaining questions is :
 - does it apply to all versions ?

This implement a  rough dismiss button and store in local storage
which version and **when** the user has dismissed it.

I think this is enough informations to refine the logic later with
what/when we want to show.

This also has a rough implementation of not showing banner for current
version for the next month following any banner dismissal.

We could do the same for announcement (not implemented here), but also
keep a hash of the announcement to re-show on new-announcement, but
that's for another PR.

CSS/HTML to refine, but I'll need help for that.
@Carreau Carreau force-pushed the dismiss branch 2 times, most recently from 07a6379 to 1799382 Compare May 23, 2024 09:00
@Carreau
Copy link
Collaborator Author

Carreau commented May 23, 2024

Rebased ( and squashed for simplicity) and a few extra changes in second commit, in particular bd-header-version-warning is now an ID as it is supposed to be only one.

Copy link
Collaborator

@drammock drammock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just a few last tweaks; if you're happy I think it's time to merge

@Carreau
Copy link
Collaborator Author

Carreau commented May 24, 2024

Ok, let's try.

@Carreau Carreau merged commit 7cc72f6 into pydata:main May 24, 2024
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants