Signup: Pressing browser "Back" button before confirming choice of plan takes you to empty /sites
Context and steps to reproduce
- Visit the logged out homepage.
- Click "Get Started".
- Sign up with email, add an email, press next.
- Search for a domain.
- Click the free option. Note: don't press continue!
- Click the browser "back" button.
Result: instead of being taken to the email signup screen, you're taken to an empty "my-sites" screen.
GIF of this flow:
This is disruptive to the flow, as you lose your place.
Site owner impact
Fewer than 20% of the total website/platform users
Severity
Moderate
What other impact(s) does this issue have?
Platform revenue
If a workaround is available, please outline it here.
Don't press the back button!
If you do, you can click "Add site", and you're back in the flow.
Platform
Simple
OpenAI suggested the following labels for this issue:
- [Feature Group] Signup & Site Onboarding: The issue pertains directly to the signup process and user onboarding flow when new users are registering on the platform.
- [Feature] Signup & Account Creation: This label is relevant as the problem affects the initial account creation experience for new users.
- [Feature] Plans & Upgrades: The issue indirectly affects users' choices regarding plans, as it disrupts the flow during the signup process.
This issue could use some more labels, to help prioritize and categorize our work. Could you please add at least a [Type], a [Feature], and a [Pri] label?
cc @alshakero was looking at these issues recently I believe.
See:
- https://github.com/Automattic/wp-calypso/pull/97786
Happy to close this one in favor of any other issues? Others should feel free to close it as well!
Click "Get Started". Sign up with email, add an email, press next.
I only get the sign up as the first step when proxied. If I turn off the proxy, the first step is goals, then design, and then the signup, so when I click back I go to the design step:
https://github.com/user-attachments/assets/9a143c6e-4997-45b1-9352-58c669504508
So maybe this issue doesn't affect real/production users?
I can still reproduce while unproxied:
However thank you for noting the proxy difference, I'll be sure to test more thoroughly in the future.
I only get the sign up as the first step when proxied.
Oh, it's probably because of the "Goals first" flow experiment (pbxNRc-4GM-p2).
Due to ExPlat limitations (PCYsg-SwK-p2), when the proxy is on, we assign 100% of folks to control (i.e. sign up is the first step). When the proxy is off, we assign 50% of folks to treatment (i.e. goals is the first step) and the rest 50% to control.
Said that, if the experiment is finally rolled out to everyone, it will automatically solve this issue.
cc @Automattic/vertex @Automattic/quake
I have a fix here https://github.com/Automattic/wp-calypso/pull/98808. It does the job but will need some CSS love and testing. I will clean it up early next week.
Noting that I can still reproduce this issue, and it makes for a supremely broken experience. Even if this is complex to address, I've tentatively added it to Code Blue v0. CC: @Automattic/dotcom-design
To recap: sign up for a site, but on the domains picker press "Back" instead of picking a plan. You'll see an empty site list with no idea what to do.
Thank you, @jasmussen 🙏
We can't prevent people from clicking the Back button, but we should definitely handle routing better. @alshakero I see the fix you shared above is a draft: https://github.com/Automattic/wp-calypso/pull/98808. What can we do to solve this?
I'm not exactly sure how to prevent this. As Cris said, the button is there and is clickable. What should happen then? Surely we don't want to redirect them to signup again?
I believe we can use the native modal so we can communicate that some changes are not being saved. Do you think it's feasible?
Another option is that we can improve the empty state of the site list so we can communicate that they didn't finish or need to start again.
One more idea, once users land on the site list, we can display a modal with some information regarding what just happened.
A "confirm" feels like a useful safetynet, if possible, good instincts Lucas.
Just to note, instead of using the custom Modal, which you can, there's also a dedicated confirm component for this exact thing.
Thanks for sharing this, Joen. We can use the dedicated confirm component as well.