Introduce a better and more compact login action button

[gtsiolis]

Problem to solve

Currently, the login flow includes selecting on of the three providers (GitLab, GitHub, Bitbucket) on the login page. However, buttons are using a secondary weight to avoid having multiple primary buttons, does not allow flexible solutions in cases like #6826, etc.

Proposal

Introduce a dropdown button for selecting one of the available providers with a single-click action to allow having a single prmary action button with proper button weight.

Benefits among others include:

1. Better user experience with a clear and single action button.
2. Allowing better and more flexible UX for cases like Customize the Login page for unauthenticated users arriving from an "Open in Gitpod" context  #6826.
3. Support more providers without making the interface crowded. For example, see Gitea support #80.

PROPOSAL

BEFORE	AFTER	AFTER (Hover)	AFTER (Active)

See design specs. 🖍️

[shaal]

I might be missing something here.
My experience with that page, is that the repo is hosted in 1 specific git provider.

That provider, is the ONLY provider you can choose in order to open that Gitpod workspace.
Why are there multiple options on that page?

Example: If a user is not logged-in to Gitpod, and trying to open this URL (which is hosted in Github)
https://gitpod.io/#https://github.com/shaal/DrupalPod

The Only way the user can open that workspace would be authorizing Github.

A common issue we experienced with the current interface, was users who try to open DrupalPod (hosted on Github), and log-in to Gitpod through Gitlab, then getting a frustrating error.

See #4696

[gtsiolis]

Hey @shaal! Thanks for sharing this feedback. 🙏

My experience with that page, is that the repo is hosted in 1 specific git provider.

Correct!

That provider, is the ONLY provider you can choose in order to open that Gitpod workspace.

You can create an account on Gitpod using one of the three provider options regardless if the repository exists in one of these three providers options. Currently, when you pick a different provider from where the repository exists there are two possible flows:

1. You are redirected to the authorization required page which you linked above which looks a bit like an error, see Show helpful explanation when opening a workspace and the git provider integration is missing #4696. Reminder, this is not a blocking or error page. Authorizing will add the provider /integrations and successfully open the workspace.
2. When you've already created an account in Gitpod using an alternate provider and you haven't linked repository's provider to that account you'll see an error that prompts the user to continue with a different provider before requsting provider authorization as described above. Currently, we handle this with some feedback, see [dashboard] Improve email address already in use #6484.

The Only way the user can open that workspace would be authorizing Github.

That's not true, see point [2] above. However, we're changing this in #6826, see #7046. Cc @laushinka @jldec

[shaal]

@gtsiolis I have 1 more question.
If a user is logged in to Gitpod through Gitlab, but trying to open a public repo hosted in Github, why does the user need to add it as integration in Gitpod?
It is possible to git clone the repo with no password.

[AlexTugarev]

If a user is logged in to Gitpod through Gitlab, but trying to open a public repo hosted in Github, why does the user need to add it as integration in Gitpod?
It is possible to git clone the repo with no password.

@shaal, because git clone will work only for public repos, other features that require REST/GraphQL API won't last long due to rate limitation, and git push won't work at all.

[shaal]

@AlexTugarev Thank you.
That is aligned with WHY I asked that question.
I am assuming that most public repos are opened in Gitpod in read-only mode, just like you would do locally on your machine.
We could let people open any public repo without asking for git provider integration, and deal with permissions once in Gitpod/VScode interface. This would be similar clone a public repo to my local machine, if I want to make changes, I'll create a fork, and push changes to my fork and not to the public repo.

[AlexTugarev]

@shaal, you are right about the pure git access to public repos, which would not require to authorize requests. the downside of this would be that shiny IDE extensions would not work without a token. but even without those IDE features, as of now, GItpod requires a token to be able to extract context information from the git hoster on workspace start.

also, it's a good question whether we want to exclude private repos from the hot path.

[kotx]

I think this would be good, but IMHO it would be better if it kept the last selected provider active. So if I last logged in with GitHub on this browser, the button would default to GitHub rather than GitLab.

[akosyakov]

Could be similar button applied to other screens, for instance we have more actions... when workspace is started with the desktop ide. Could it be replaced with a drop down instead next to Open in Intellij button? I cannot find an issue unfortunately.

[trumbitta]

I find the current implementation to be the most obvious and I'm not sure users would immediately understand they have options and they need to click on the caret to see them (but that can be measured and validated).

My suggestion is to also add a help text below the split button, with a link that will open the dropdown.

Something like:

Looking for more options? Choose another login method.

[gtsiolis]

Thanks @trumbitta! Yeah, separating sign in and sign up pages and also using a help text like described above is also something we're considering. See also relevant comment in #7087 (comment). Cc @jldec

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.