firebaseui-web
firebaseui-web copied to clipboard
firebase
[Feature request] New UX Flow for email and password signup
Wiki says:
FirebaseUI includes the following flows:
Interaction with Identity Providers such as Google and Facebook Sign-up and sign-in with email accounts . .
I was expecting sing up with email and password button somewhere in the page but I see none. I use the following code same with the example:
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Sample FirebaseUI App</title>
<script src="https://www.gstatic.com/firebasejs/ui/live/0.4/firebase-ui-auth.js"></script>
<script src="https://www.gstatic.com/firebasejs/3.1.0/firebase.js"></script>
<link type="text/css" rel="stylesheet" href="https://www.gstatic.com/firebasejs/ui/live/0.4/firebase-ui-auth.css" />
<script type="text/javascript">
// FirebaseUI config.
var config = {
apiKey: "****",
authDomain: "****",
databaseURL: "****",
storageBucket: "****",
};
firebase.initializeApp(config);
var uiConfig = {
// Query parameter name for mode.
'queryParameterForWidgetMode': 'mode',
// Query parameter name for sign in success url.
'queryParameterForSignInSuccessUrl': 'signInSuccessUrl',
'signInSuccessUrl': 'http://local.host:9000/',
'signInOptions': [
// Leave the lines as is for the providers you want to offer your users.
firebase.auth.EmailAuthProvider.PROVIDER_ID,
firebase.auth.GoogleAuthProvider.PROVIDER_ID,
firebase.auth.FacebookAuthProvider.PROVIDER_ID,
firebase.auth.TwitterAuthProvider.PROVIDER_ID,
],
// Terms of service url.
'tosUrl': '<your-tos-url>',
'callbacks': {
'signInSuccess': function(currentUser, credential, redirectUrl) {
// Do something.
// Return type determines whether we continue the redirect automatically
// or whether we leave that to developer to handle.
return true;
}
}
};
var ui = new firebaseui.auth.AuthUI(firebase.auth());
// The start method will wait until the DOM is loaded.
ui.start('#firebaseui-auth-container', uiConfig);
</script>
</head>
<body>
<!-- The surrounding HTML is left untouched by FirebaseUI.
Your app may use that space for branding, controls and other customizations.-->
<h1>Welcome to My Awesome App</h1>
<div id="firebaseui-auth-container"></div>
</body>
</html>
Hey @endertunc the red "Sign in With Email" button is effectively a sign up button too. It will first ask you to provide the email to sign in with. If the email account is not an already registered firebase account, it will display the password sign up screen instead of just asking you for the existing account password to complete the sign in.
@bojeil-google thank you for you quick and clear answer. I think it should be documented on wiki.
Also, It is a bit out of context but do not you think that it is a bad user experience? I mean, I know how things work on the Internet more than an average user and I could not think the way it works.
You are Google and what you do is always 'per-calculated' in many perspectives but I just wonder that you do really think that it is the way how it should be.
Just gonna chime in that I and several other devs on the app we're developing have all had the same issue when using the email sign-in. I couldn't figure out that I'd get a sign-up page when I submitted an email that was not yet registered until I read this github issue.
An easy solution would be to allow some external way for the library to change the text on the various provider buttons from "Sign Up" to "Sign In," or even arbitrary text besides that. Then I could put a separate UI element (something like "Not a user yet? Register now!") that, when clicked, would trigger the switch (or potentially just reload a firebaseui instance with these new settings).
I think the simplest implemenation of the above would be to add a new callback to the uiConfig, something like uiConfig.callbacks.getButtonText(<string> providerName), which would return a string to populate each button. Then I could easily add this to my config:
const uiConfig = {
callbacks: {
getButtonText(providerName) {
return `Sign Up with ${providerName}`;
}
/* OTHER CALLBACKS */
},
/* OTHER CONFIG STUFF */
};
I'm happy to make a pull request if this is a direction y'all feel you want to go.
Any updates on this?
Another situation where the UX becomes unclear is when the EmailProvider is the only provider. In that case the the user is just prompted for their email with no clear indication of what is going on...
Hey @siegerts and others, we have a bunch of features in the request pipeline that are higher priority. At the moment, I don't see this as blocking. There are many ways the flow can be tweaked or customized. This is one of many. It is hard to accommodate every one of them. Our UX designers recommended our current flow during the design stage. I will relay this request and your supporting arguments to the relevant parties and update this thread on this.
As of v4.6.1, you can customize the button labels:
signInOptions: [
{
provider: firebase.auth.GoogleAuthProvider.PROVIDER_ID,
fullLabel: "Sign up with Google"
},
What I ended up doing was having separate /signin and /signup pages with the two different sets of button labels, with links on each page to the other. It also worked out in my case since I have a "sign up step 2" where I ask for more info (first name, phone, time zone, etc), and this flow works perfectly for that use case.
From a developer point of view, it's a bit redundant, but from the user's perspective, this kind of flow is the norm.
