Firebaseui-ios: Differentiate between logging in and signing up

[ldetmer]

Hi,

I would like to put in a feature request to differentiate between signing in and signing up. Right now the buttons always say "Sign In". It would be really nice to pass in a parameter that allowed us to set the language to "Log in" or "Sign up".

This request is based off of user feedback, people have come to our sign up screen and asked where do I Sign Up?

Thank you!
Laura

[drishi94]

This is something we are looking into with our UX team to determine the best practice moving forward.

[cohenadair]

@ldetmer As a temporary workaround, you may be able to use custom strings. The documentation doesn't specifically mention buttons, but I don't see why they wouldn't be included.

[yorgosg]

I posted a question on stackoverflow on using custom strings:

http://stackoverflow.com/questions/41829364/use-different-bundles-to-load-strings-from-on-runtime-in-ios

Please have a look and let me know if you have any ideas on this.

[yorgosg]

@mcdonamp , @drishi94 could you please provide an estimation as to when this task will be implemented? I see that on Sep 12 a priority:p3 tag was added to the issue, but I don't understand how priorities work, since there are almost 4 months past since then and I see that some p:2 tasks are not done also. I think this is an important issue, because otherwise users will be asked to "sign in" to an app that they haven't yet signed up. I assume it is also easy to fix, because all it needs is changing some labels.

Please let me know, thanks.

[morganchen12]

@yorgosg it's unlikely either of them will have time to work on this soon.

Until then, PRs to expose more customizability would be good--FirebaseUI Auth is intended to expose a good auth flow by default, but our framework shouldn't be hostile toward developers who want to do extra work to add onto that.

[najdanovicivan]

What about adding the boolean flat autoDetectSignup to FUAuth defaulted to YES;

if parameter is set to NO FUI FUIEmailEntryViewController will not be displayed. Instead it will directly show FUIPasswordSignUpViewController

In such case if email field is blank right navigation button will be "Sign Up" once the user add any character to the email field it will switch to "Sign-In"

Additionally we can implement boolean flag disableSignUp which will completely disable signup

If mentioned functionality is good to go I can implement the feature snd submit a PR

[najdanovicivan]

@morganchen12 any thoughts on my suggestion ?

[morganchen12]

This mostly sounds good to me but the changing text seems potentially confusing. I don't have a better UX approach though.

@samtstern WDYT?

[samtstern]

@morganchen12 how does the iOS flow differ from the Android flow? On android we have:

• A first screen that only has an email box and a "next" button
• Three cases:
  
  
  
  • Never seen the email --> sign up screen
  
  
  • Email has a password already --> sign in screen
  
  
  • Email is linked to some social account --> move to that social flow
  
  

[morganchen12]

It's the exact same thing, but the issue we're trying to solve is before any of the three cases when entering the email we show "Sign In". In cases where the user doesn't have an account yet this led to confusion because there was no "Sign Up" text input.

[samtstern]

Oh I see. On Android we just say Next and it seems to satisfy both cases.

Oh but now that I look at it, the title of the screen is Sign in so I can see we have the same problem.

[morganchen12]

@najdanovicivan let's do this in two parts. We can implement the flag for disabling sign-up and only allowing sign-in since that's a separate issue.

[samtstern]

@morganchen12 FWIW we have the 'allow new email accounts' boolean flag on android.

[najdanovicivan]

@samtstern can you provide complete explanation how does 'allow new email accounts' work on Android so that we can have similar functionality on iOS

[morganchen12]

allowNewEmailAccounts set to NO would only allow login from accounts with emails that already exist in the auth database. This is useful for invite-only services that don't allow direct sign-up, but still want to allow for people to use third-party providers.

So instead of going to the "register new user" flow, the Auth flow would always go to login.

[najdanovicivan]

@morganchen12 in such case if only email and password method is enabled should FUIEmailEntryViewController be displayed or should we immediately display FUIPasswordSignInViewController ?

I understand that FUIEmailEntryViewController will be needed in case when social login methods are ebabled

[morganchen12]

In this case I think we can just immediately display FUIPasswordSignInViewController.

[najdanovicivan]

Ok. I'll start working on it.

[najdanovicivan]

I've submitted pull request for allowNewEmailAccounts. However I've noticed some additional things that have to be taken care off

1. Left bar button for closing the signup view 'cancelBarButton' is added in viewWillAppear method. It will be good to add hideCancelButton parameter for FUIAuth. Does something similar exist on android ?

2. There is an issue in FUIAccountSettingsOperation line 183 completion block. It breaks the compilation. It should be changed to ^(FIRAuthDataResult * _Nullable authResult, NSError *_Nullable reauthError) { ... I can submit separate PR for this

3. I don't know how this works on android but allowNewEmailAccounts does not impact social logins. So if any additional providers are enabled user will still be able to create the account. We can check newUser property from FIRAdditionalUserInfo and delete account in such case. but it won't make much sense. The only case It may have use is if signups are enabled only on specific dates or incorporate the use of Firebase Remote Config for enabling/disabling signup. Otherwise user will have no way to create account at all. More info how android implementation takes care of this will be useful

[morganchen12]

1. You can go ahead and implement this, and we can just hold off its release if it's not in Android (cc @samtstern)

2. Fixed in bdd3c05. Tests on Auth are still broken due to a duplicate symbols issue; I'm currently working on a fix.

3. @samtstern can you advise here?

[najdanovicivan]

@morganchen12 I've done the changes you've requested

About hideCancelButton should I wait for this to be merged first and then start a new branch from master. Or should I do another branch from my branch since this PR adds close button to FUIPasswordSignInViewController as it will be the root view controller when allowNewEmailAccounts is set to NO ?

[samtstern]

@morganchen12

• I'd be OK if iOS was ahead of Android on this feature.
• Social logins are much harder to handle here since there's no separate "sign in" versus "sign up" API call. I guess you could use the "get providers for email" method after successful social sign in and then check if the account is pre-existing but we didn't do that as it's pretty complex.

[morganchen12]

@najdanovicivan, go ahead and make that as a separate PR.

[najdanovicivan]

@morganchen12 should we open a new issue for this or should I reference this one ?

[najdanovicivan]

@morganchen12 I've created the issue #451 and submitted PR #452

[morganchen12]

Let's open a new issue.

[najdanovicivan]

@morganchen12 now the discussed features are implemented, but we haven't touch the subject hare. The issue is about differentiating between signup and login @samtstern said that Android use "Next" as the button title why don't we do the same on iOS in FUIEmailEntryViewController ?

We already have kStr_Next defined so it will be an easy task to change the button title.

[morganchen12]

That sounds good. The distinction still isn't immediately clear, but it's an improvement over what we currently have.

[najdanovicivan]

I'see that button ins FUIEmailEntryViewController has had title "Next" from the beginning. The issue I see is in the title which is "Sign in with email". Maybe good idea will be to change this title to "Enter your email" or something similar to exclude the reference to sing in action.

[morganchen12]

Sounds good to me.

[najdanovicivan]

@samtstern how is this done on Android. I can make a PR to change the title but I want to make sure that we have same things on both platforms

[samtstern]

@najdanovicivan on Android the title is always "Sign in" on that screen, which I don't think is ideal. So iOS can take the lead on improving that.

[morganchen12]

The most basic improvement would be to just change it from "Sign in" to "Sign in or Register".

As Sam said, we can make the changes in this repo before porting to Android.

[najdanovicivan]

@morganchen12 i was just looking at localization files and found this

/* Title for email entry screen, email text field placeholder. Use short/abbreviated translation for 'email' which is less than 15 chars. */
"EnterYourEmail" = "Enter your email";

Why don't we put kStr_EnterYourEmail as title since there is already localization for it. If we decide to use "Sign in or Register". we'll need translations for all supported languages.

[morganchen12]

Let's do this for the time being.