Replay Index: Make the Page Filters More Contextually Aware

jas-kas commented 1 year ago

Problem

When our users go to the Replay Index page, it is often on a backend project due to existing Page Filters logic, despite the user having replay installed on one of their FE projects. Each time, they must change their project selection to the applicable FE project. Moreover, a backend project selected today will always result in an empty Index page. Our customers have reported that this Page Filters behaviour is a nuisance.

Solution Brainstorm

The Page Filters should be more contextually aware and pick the eligible projects and/or already-set-up FE projects by default. This can also work hand-in-hand with the initial onboarding experience because we will be presenting an eligible project as soon as someone lands on Replay Index.
Show toast message communicating what is happening to the user
[Other solutions welcome]

Examples

(Internal Only) Example cases from users

Note: We cannot rely on the "lock" feature in Page Filters as that will likely be deprecated.

eliashussary commented 1 year ago

Were we looking to change the actual UI behavior of the list? Or just the default selected project?

jas-kas commented 1 year ago

Were we looking to change the actual UI behavior of the list? Or just the default selected project?

Only the default selected project behaviour should change.~

billyvg commented 1 year ago

I think it'd be ok to auto select a project if: 1) no multiproject available, 2) there is only a single project that has replays -- otherwise it'd be a bit frustrating to auto select a project because it's a tossup if we ever select what they want to be selected.

I think instead, we should list projects that have replays in a separate UI component that they can instead quick select. This would avoid any unexpected behaviors with the page filters.

eliashussary commented 1 year ago

I think instead, we should list projects that have replays in a separate UI component that they can instead quick select. This would avoid any unexpected behaviors with the page filters.

+1 to this

i think its worth trying

ryan953 commented 1 year ago

+1 on the separate list, in the onboarding case, where we show supported projects & the 'new project button' front and centre

also +1 on the 'auto-select a FE project & toast' when one is already setup.

eliashussary commented 1 year ago

I've played around with this a bit.

Auto Switch This is the most jarring experience. Going to your dropdown, clicking sentry and the app simply unselects your selection makes it feel like the website is broken.

Auto Switch followed by Toast I've also experimented with toasting with an "undo" after a project switch. This is also a bit crummy. The toast is in the bottom right hand corner, I don't think we toast in other places. Regardless of the place, a toast is pretty subtle so it may not always be obvious enough thus also creating a UX that may feel broken. We could make it an alert that has a delayed dismiss, but i feel like that's something very in your face.

Countdown followed by Switch The most recent thing I've done is experiment with a countdown. I think it has the best balance of not creating an experience that feels broken, but also switches a project without user intervention.

https://user-images.githubusercontent.com/7349258/233139212-3937f28e-2c45-4916-bee2-7d780fe29591.mov

jas-kas commented 1 year ago

@eliashussary

I don't think we should be auto-selecting a project after someone intentionally selects a different project inside our Page Filters. We should respect their selection and present the onboarding blue banners if it's an in-eligible project or a project that does not have Replay set up (but can have Replay such as a Vue project).

The intention of this ticket was to correct the initial state of the page when someone clicks the Replay tab. Many times, the Page Filters is already on a backend project when clicking the Replay tab, which is a poor pattern if we already know another project has Replay set up. We should be auto-selecting the project that has replays set up (I also agree a toast message would be helpful here to communicate this change). And if that is not available, then picking the a frontend/JS project.

Ideally, this work would make the Replay tab experience so seamless, that no one has to think about selecting another project in the Page Filters. If we select the project that Replay set up, I (as a user) am not thinking about going and selecting a new project most likely.

eliashussary commented 1 year ago

Here's a quasi-transcript from front-end tsc: https://www.notion.so/sentry/7b81901e4fd54f32b42f2a707b9f4280?pvs=4#8520fff9332544c08e546b646c191d01

The overall consensus was to not auto-select, but replace onboarding state when all projects are unsupported and present a short project list of projects that are prioritized by hasReplays > supported

it can be something super simple like:

Your selected project does not support Replays. 
Select a supported project from the list below.

- javascript-fizz-bizz
- nextjs-foo-bar

the big problem with auto-selection is that project page filters are global across sentry, so if we change it we create unexpected behviours when switching between skus. its better to put the onus on the user so the side effect of project selection feels natural.

as an outcome of the TSC, we can implement this inline project selection while continuing to socialize this project selector pattern.

the project page filter selection is currently under a revamp so we don't want to disrupt a bunch of this work at the moment. longer term we can look into priority sorted projects in the project dropdown, and possibly somewhere in the future we can have project select on a per-sku basis if it makes sense

ryan953 commented 7 months ago

Closing this because we don't really want to mess with the behavior of the global project selector. And in the intervening time we've expanded docs to help with onboarding of more platforms, so seeing your backend app in the picker isn't always a dead end for folks.

We can re-open if we're actively revisiting this idea of course

getsentry / sentry