Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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.

share|improve this question
1  
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 at 19:32

2 Answers 2

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 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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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