[Breakpoints] Events pagination - 320 & 481 breakpoints

[laflannery]

Description

At the smaller breakpoints, the pagination component has some display issues:

1. at 320, you can't see the beginning or ending pages. I was on Washington DC past events and this has 11 pages:
2. at 418, you can see all the pages but the page 1 and page 11 elements are getting slightly cut off:

Other examples

I was struggling to find examples with enough pages but I did find 2:

1. Global search results: However maybe the entire layout of the page is different which is why it works and this is actually a DST component issue not an us issue
2. Washington DC Stories: This does cut off but not as badly as the original example above

Acceptance Criteria

• [ ] Pagination should display all pages at all breakpoints
• [ ] Paging elements should not be cut off in any breakpoints
• [ ] Requires design review
• [ ] Requires accessibility review

[jilladams]

Unassigning Josh, as he's out today for good, waa. We will need to get a look from @randimays or @chriskim2311 when PR is ready to take next steps. Assigning both for now, so it stays visible. We can discuss next week to sort out owner.

[laflannery]

I reviewed and commented on the PR

After folks have a chance to catch up on what I'm seeing, if we do decide to ask DST about this and folks would prefer me to do this just let me know

[jilladams]

@laflannery if you could follow up with DST, I'd be grateful. Josh is gone now, and he did flag that this is happening on Global search as well, which makes me think it's likely a component issue.

[chriskim2311]

@laflannery Left you a comment on the PR but did you follow up with DST yet? I can file an issue if you hadn't already. Thanks!

[laflannery]

Hey @chriskim2311 I just got out of their office hours, I actually think that we might want to keep this as is (meaning don't actually merge in Josh's pr) but I'm going to summarize everything and then we can decide:

• Yes, the fact that the paging doesn't fit on the smaller breakpoint is a DST issue. They are aware but said this probably won't get looked at for at least 2 or 3 more sprints
• Consequences of keeping not merging in this PR and keeping the Events paging the way it is now:
  • At the 320px breakpoint, any events list with more than 7 pages will have at least 1 page completely not visible/available in the pagination list of items
  • At the 481px breakpoint, all page items will be visible just slightly cut off
• Consequences of merging in this PR:
  • At the 320px & the 481px breakpoint, when there are more than 7 pages in an Events listing, at page 4 and above, the user will only be able to access the first page and the last page.

Scenario 2 seems like a worse user experience to me than scenario 1, even though scenario 2 is already on Prod. I think we should potentially discuss this at scrum tomorrow, Jordan is still out but @aklausmeier perhaps has an opinion

There is a 3rd option - we use the unbounded prop but this would remove the last page from displaying. If we wanted to use this, at least for the time being, here are some screen shots:

Small screens

Large screens

[aklausmeier]

@laflannery With option 3, is the user able to navigate to next page up through the last page by clicking right three dots? And would this option require us to revisit the DST solution in a few sprints?

[laflannery]

@aklausmeier No, the ellipsis are not actionable, they are a visual indicator only. So the user can only go to the next page and the first page in the screen shots above. I would also think that Option 1 (keeping everything as is) might possibly be the only option where we might not need to revisit this after the DST update but because we don't know for sure how it's going to work we can't guarantee that.

[laflannery]

Talked about this in scrum - we are going to keep this as is as this is the best of the not great options, which means we wouldn't need this PR anymore. @chriskim2311 are you able to remove/delete this?

[chriskim2311]

@laflannery Thanks for clarifying this! I think this is the best option too, I can close the PR.

[jilladams]

@laflannery @chriskim2311 @FranECross since we didn't ship this PR, as far as this ticket goes, are we:

• Keeping this open to verify when the DST ships their fix? or
• Closing as a no-op since DST owns the issue?

I don't think there's a wrong answer, just wanna make sure I know what to expect on the reporting side.

[laflannery]

I vote close - and maybe we open a new ticket to review and verify all paging for both teams when DST solves this.

[FranECross]

I vote close, too.