🪟 🧪 [Experiment] Simplify signup left side

[letiescanciano]

We want to experiment if simplifying the left side on the sign up page and dividing the signup methods, increase conversion of corporate emails on the page. How?

• Making Oauth the default method
• Email/password method is still available but user will see an error for personal emails. They can still sign up though.

Airtable details:
https://airtable.com/appIuY0uKPVnk8TWT/tbl2SxXnUwf6fVCWS/viw9frYvld7ks7aNo/recnFzE4HBB8RP1uY?blocks=hide
Demo: https://www.loom.com/share/9b706682d89845b1bf2455a1f3e1520d

[timroes]

🤔 Is this icon used somewhere? I can't find any reference to this in your PR?

[letiescanciano]

Leftover sorry!

[timroes]

Overall looks good. I've left some code cleanup and wording suggestions to discuss.

[timroes]

🧹 Once we clean this up, it would be nicer to manage this via an URL route instead. Currently when switching between those the back button of your browser won't go back, since we only manage this state in JS, which already got me multiple times. I think for the final implementation this shoudl be separate routes, so your back button works as expected when switching between them.

[letiescanciano]

I'm curious, if it's the same action (signup) but just two different flows, in which cases do you think it make more sense to have two routes?
I didn't think about the back button to be honest, as you can just use the elements in the page to navigate, but I'm talking from my ignorance in this matter!

[timroes]

I think my main decision driver would be: "Does the user think those are different 'pages' and she'd expect the back button to go back to the previous one?" If so, I usually would try to make it different routes in most cases, since it's easier than manually mess with the history state, to achieve the same without adding different routes.

Just for technical completion: The way you can hack around that without using routes is doing something (pseudo code, I'm not sure if the navigate is actually the right method by heart to push to the history without actually causing the browser to navigate in react router v6):

const location = useLocation();
const navigate = useNavigate();
const [showOauth, setShowOAuthState] = useState(location.state?.data.showOAuth);

const setShowOAuth = () => {
  navigate("/signup", { state: { showOauth: true }});
  setShowOAuthState(true);
};

[timroes]

Code LGTM, tested locally seems to work (despite the "navigating back" issue, which we can fix once we end the experiment).

[timroes]

I think my main decision driver would be: "Does the user think those are different 'pages' and she'd expect the back button to go back to the previous one?" If so, I usually would try to make it different routes in most cases, since it's easier than manually mess with the history state, to achieve the same without adding different routes.

Just for technical completion: The way you can hack around that without using routes is doing something (pseudo code, I'm not sure if the navigate is actually the right method by heart to push to the history without actually causing the browser to navigate in react router v6):

const location = useLocation();
const navigate = useNavigate();
const [showOauth, setShowOAuthState] = useState(location.state?.data.showOAuth);

const setShowOAuth = () => {
  navigate("/signup", { state: { showOauth: true }});
  setShowOAuthState(true);
};