Customize the Login page for unauthenticated users arriving from an "Open in Gitpod" context

[jldec]

@jldec - update Dec 8, 2021
Final design below. Removes mention of Log In / Sign up.

Note local storage value of gitpod-ui-experiments: {"login-from-context-6826":true}
When this is false (50% of cases at the time of release) the original 3-button login with welcome is rendered.

---

original description

This only applies to the login/signup page presented to unauthenticated users, landing at gitpod.io with a #-prefixed git repo context. Using the repo context we should present those users with a simpler, less-generic Login page to improve the conversion rate for new signups arriving from this source.

• Remove the welcome section on the left
• Show the Gitpod logo and name
• Change "Log in" to "Log in / Sign up"
• Customized message: Open a cloud based development environment for <repo XXX>
• Single Continue button leading to the git provider matching repo ☝️, usable with the Enter key.

If possible, we would like to implement this in way that will allow us to present either the existing OR the new design, and measure the aggregate signup rates for both versions.

For further background see Notion RFC (internal)

[svenefftinge]

💯 Three small suggestions:

1. Can we remove the "Log in / Sign up" headline? I don't think it adds any value, as the main action is to "Continue" and it tones down the "what" (i.e. "Open a cloud based development environment for ..."
2. The repo URL should be shortened to the usual group/name pattern.
3. Let's keep the "Continue with GitHub" resp. "Continue with GitLab" buttons, as they not only look nicer but also prepare users for the upcoming oauth.

[jldec]

Thanks @svenefftinge - good suggestions - How about this (see screenshot below)?

• We could make the user/repo name link back to github
• We could also shorten for the repository <user/repo> to just for <user/repo>

[jakobhero]

Great suggestions! In order to attribute events to their respective groups in A/B testing, it would be sufficient to pass a property for those users that are shown the new change, e.g. test_group: 'A'. The events itself should be captured in the same way as they currently are, i.e. page call for a first time visitor, path_changed call for a visitor who has been redirected from the dashboard internally (which might never happen if the user is not signed up in the first place) and a dashboard_clicked call when the user clicks on Continue with ... (the call is made automatically). We just need to make sure that the test group property is attached to both, the call when the user enters this screen (page / path_changed) and when she converts to the next (dashboard_clicked). Let me know how I can help in the implementation and testing:)

[svenefftinge]

Do we need to roll this out in A/B mode? FWIW I'm super confident it is an improvement over the current situation.

[jldec]

/schedule

[roboquat]

@jldec: Issue scheduled in the meta team (WIP: 0)

In response to this:

/schedule

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.