2

Our application currently allows users to sign in using an email/password combination, Facebook or Google. In the update we're working on, we will also add the ability to sign in with a Microsoft account.

Currently, the applications have a "native" login for email/password and uses a browser workflow for Facebook and Google. At the moment we're considering whether the benefits of moving the entire workflow to a normal single sign on model - similar to Google/Facebook - whereby the app would have a single "sign in" button which would launch a (nicely styled) webpage, then giving the user the option to sign in with email/password, Facebook etc. One app I think does this quite well is Skype on Windows Phone.

From a technical standpoint, moving the entire workflow to the cloud would allow us to fix bugs much easier and faster, whilst also giving the benefit of changing the sign in / up process in the future.

The update in question also introduces 2 account types - making "native" oauth login much trickier and time consuming to handle on from the mobile app. From a UX and therefore user's perspective, are we likely to see a higher number of "drop outs" (users downloading the app and not bothering to sign up)?

I can think of 3 possible solutions...

Option 1

Everything native. The sign in, the single sign on, the registration form and any setup involved in choosing account type etc.

Option 2

Semi-native. Native sign in, native registration form and single sign on. If any further steps are required (choosing account type, additional fields), the app shows a web page within a web browser control.

Option 3

Everything in the browser. The app has a single sign on button which shows a web browser control giving the option to sign in / up. The page / control will be styled to match the app and device's UI as much as possible.

Improve this question
3
  • 2
    I'd suggest option 3. If done well (ie, good responsive solution) it shouldn't be too drastic of a departure from the app itself and not a big deal. Also, lots of apps do this these days (link off to web sites to handle some functionality) so isn't an out-of-the-ordinary experience, either.
    – DA01
    Mar 31, 2014 at 19:32
  • Are you going to allow a persistent session or will this be done all the time. I've seen 3 done well on a few apps but they always allow the login to remain valid for a number of days at least without re-prompting minimising the impact.
    – Andy Boura
    Aug 8, 2014 at 16:38
  • Hello @Jamie our team is in the similar confusion, which approach you have used for your app?
    – prasad
    Jan 25, 2020 at 15:08

3 Answers 3

Reset to default
1

The best option is to separate the logic from the UI, the UI should be native wherever it exists while the logic should be system based preferably by API. The logic can always be tweaked while the UI just exists. You must take care to handle error handling in logic with UI simply displaying the error passed to it. Barring that display of a web view within the application with the app UI construct around it makes it look seamless to the user. The drawback is you're making a call to a website to get everything the user needs to display the sign on rather than embedding within the application.

Improve this answer
1

Just my take, use 3rd party apps for "registering" and use your own app for "Login".

I personally think allowing people to login with different 3rd party services make your own app confusing, users tend to forget which app they have used before to login to your app. However, using 3rd party apps during registration and account creation process is perfectly fine, since it makes it easier for users to auto fill the form fields.

Improve this answer
1

1 or 3.

Why?

You don't want to break your users out of the sign-up/sign-in workflow if you can help it. Several apps today have this problem, where you are sign up for an app, chose a Google sign in, and it breaks you out of the App. This can cause the users to forget they were signing up in the first place. Now, Google mandates you going to their site for sign on, especially if the user has 2 factor auth, so keeping multiple logins and option 1 is not possible. Some apps don't have multiple sign on because it insures they have maximum control over data and a seamless app UI. Option 3 is similar in purpose, you can have it all on a webpage, and oversee the process without breaking out your users.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.