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.

[jldec]

Related issue #4696 brought up 2 edge-cases

1. user with integrations for 2 providers, arrives at login for prefixed repo on provider1, chooses provider2 in login UI
2. user with integration for provider1, arrive at login for prefixed repo on provider2

[laushinka]

/assign

[jldec]

edge case 1: mitigated by only showing the button for matching provider

edge case 2: this is problematic, because with the change as proposed by this issue, you'll be encouraged to create a new account with the matching provider2 - which will lead to an error if you use the same email, or 2 Gitpod accounts if you use a different email.

[jldec]

Let's proceed with the design as shown, and try to mitigate edge case 2 in #4696

[laushinka]

@jldec Is there a case where we would still show this image?

[jldec]

We show the login with this left-pane for any action on the dashboard when unauthed and missing cookies.
E.g. I was able to bring it up by deleting all browser history/cookies and then going to any of the following
https://gitpod.io/login
https://gitpod.io/new
https://gitpod.io/projects

This change should only apply when landing unauthed at gitpod.io/#<git-repo-URL> to start a workspace on that repo.

[loujaybee]

Hey folks 👋 Firstly, I love the collaboration going on with these changes 😍 ! I don't have direct feedback, as I agree with much of what has already been said, and do not think more chefs will help 👩‍🍳

But I wanted to make a few remarks based on findings from usability testing, as I think it's important to keep the user and specifically, the users frame of mind front-and-center when we make decisions about this page.

This is not just an exercise in making an optimal login (from a clicks/design perspective) 👇

1. Gitpod terminology. We should consider that users might not yet know what terminology such as a "workspace" is. A question that came up a few times in usability testing from users was: "what's the difference between a project and a workspace", for instance.
2. Gitpod concepts. We should be careful making assumptions that it's transparent to a user some assumptions about how Gitpod works, e.g. that a repository, workspace and project are all 1<>1. Let's try and lean on any existing mental models the user might have, or terminology the user might be most familiar with... and on the flip side, be judicious with new, or gitpod-specific terminology, such as "workspace", "project", etc.
3. At this stage, we're dealing with a users sensitive data (code) - The user should here be assumed to have no idea who (Gitpod) are, and we should treat this interface with the same level of skepticism that a user would when being asked to login and hand over sensitive data to a third party. It's important that we build trust here. Any signals we can give the user that we're trustworthy, and transparent about what is going to happen after they click the login button could help.

A user coming to Gitpod for the first time is likely to be cautious/skeptical about logging in with us, and giving us their data. This is not just a functional journey (i.e login as quickly as possible) but also an emotional one. If we find that more "clicks" or "screens" to guide the user a little and build trust here works, let's also consider that. 🙏 🙏🙏

Caveat/warning: If I've found anything to be true in UI design, it's that we cannot safely assume that users will read things. So incorporating the above ideas might require subtlety, branding, iconography, etc.

As with @jankeromnes's comments above, take what's useful from my feedback, and discard the rest. You have all the context to make the decisions. If we want to re-run any usability testing over mock-ups or designs before we cast this in code, let's also consider that if needs be, I can help you here 🙏 .

[loujaybee]

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

Separate note: A pragmatic option here could be to roll out the change out (for a week or so) measure the impact, and then be prepared to roll back if changes are seen to be detrimental, if they're positive, then we roll forward! 🚀

[gtsiolis]

Thanks @jankeromnes and @loujaybee for your feedback! 🙏

@jankeromnes you're right about the orange element being particularly overwhelming. I've added #7061 to improve the login action buttons, etc.

What do you think of the following drafts? Cc @laushinka @AlexTugarev @geropl @jldec @svenefftinge

Early draft for the long run	Early draft for this iteration

[svenefftinge]

The point of this change was to reduce the noise and just tell people what is going to happen next. No side-tracking explaining Gitpod concepts or providing confusing choices. I think we have discussed that at length already.
So could we please just put in what @jldec proposed in #6826 (comment) and see how it moves the needle?

[jldec]

Thanks for all the feedback everyone - This page is an important step in our onboarding experience so the thoughtful comments and suggestions are appreciated.

In an effort tilt the bias toward action and simplicity, let move forward with proposal (screenshot below)

NOTE We recognize that reducing the auth-button choices does mean a slightly higher possibility of existing (already-signed-up) users creating another Gitpod account, but it also stops erroneoous signup with one git provider when opening a workspace for a different git provider.

I will put additional comments in PR #7046 .

[gtsiolis]

Thanks everyone and sorry for sidetracking the discussion with more designs in #6826 (comment) and #6826 (comment). 🙏

💭 thought: The proposed design from @jldec in #6826 (comment) is certainly an improvement we can ship[1].

❗ issue: The only caveat that comes with the proposal in #6826 (comment) is the small risk of blocking users. Cross-posting from the relevant discussion (internal):

For example, GitLab only users would be blocked from logging in for a GitHub repository. Currently, we handle this with proper feedback.

suggestion: However, let's not worry for problem that may not exist. This can be resolved with #7061 or by simply listing back all provider options. Maybe we could cross-check with data if this is an issue. Otherwise, this will probably surface as an issue from the community.

🍊 🍊 🍊 🍊

To help make consensus and actions needed more visible, I'd suggest to:

1. Use the issue description as the single source of truth (SSOT) for any consensus or design decisions when possible
2. Remove labels like "~needs visual design 💄" when needed

[jldec]

Reminder to prioritize #4696 -
Show helpful explanation when opening a workspace and the git provider integration is missing

[laushinka]

In order to have better analytics and a data-driven decision-making, after a discussion in the Meta team, we will enable A/B testing for this page with a 50:50 ratio for each group once #7081 is merged. This will be the first time we try A/B testing for the Dashboard.