Should we restrict signup for a service to Facebook accounts only?

Question

There are obvious advantages to limiting sign-ups to a service like Facebook connect - getting a name, age, avatar, etc. without the annoyance to your customers of asking them to fill it all in.

We are currently considering this, but there are some good arguments for using other services as well - such as Twitter, LinkedIn, Google, etc. I can even think of some very good reasons (privacy being chief amongst them) to still keep our own sign-in.

The issue then is that giving people too many options is not a good UX.

Our target audience is subject specific (architecture, language learning, etc.) so we can't predict our customer audience very well yet.

What would you use for sign-ups and why?

Edit: I need to add that our application is targeted at mobile use, so screen real estate is also a consideration in showing many options.

Answer 1

Facebook only? Don't do it! I would always give people the option for maximum chance of sign up. Sign up forms that allow for your own sign in and using another account don't have to be complex, although many do seem to be for some reason. Digg is a good example of one that keeps it pretty simple.

You already said you don't know your customer audience that well - so why throttle it with such apparent inflexibility from first sight.

Answer 2

I'm going to be blunt. Any site that only allows me to sign up using FaceBook is a site I will not use. And I'm not alone in that - if you check out any of the debates on Spotify's decision to do likewise, you'll see a lot of negativity about the idea.

If you want to use a third party provider, give a choice. Limiting it to one provider only is not a good idea for customer growth, particularly if the provider is divisive. It also ties your fortunes to that one provider which is not a good idea either.

Answer 3

While I agree that having "too many options is not a good UX", I would not say that having 4 or 5 options is too many.

Your question also somehow suggests that you need to have your own sign-in procedure, or a standard one. I don't see why you could not have a combination of both.

Look at how this very website does it:

You have a clear choice between a number of well known sign-in methods or you can choose their own sign-in method. ther is even an option "show more login option" for the less known possibilities.

I do not consider this to be bad UX, in fact there are very few websites that let me log in this easily.

to answer you "why" question: - quick sign-in procedure possible with well know, easily recognizable external accounts - still the possibility to create an own login, separate from you other accounts if you don't trust this. - All this is offered in a clear and nice manner.

Answer 4

If you want to restrict the type of services they can login from, at least provide a "signup with my email" fallback for people who don't have an account for any of these service, otherwise they would have to signup to two services instead of one.

Answer 5

The question you might need to answer yourself is what benefit are you offering by only allowing Facebook? Does it integrate with Facebook in some way? In doing this, who are you (either intentionally or unintentionally) excluding?

Have you done research that shows that your target audience are happy to share their Facebook credentials with a third-party site? Or that they all use Facebook?

Apart from a benefit of not needing to remember another username/password combination, be mindful of the fact that some individuals may want to keep things separate. Given the choice, I'd always let them decide between using an existing account, or creating an entirely separate account.

Answer 6

If you know that all of your users will have a facebook account that they are happy to use to sign up for this, then just using facebook is probably OK. However, even though I have a facebook account, I do not normally use it to sign up to things with, so for me, it would be offputting.

Answer 7

Absolutely not. You lose so much more than you gain with Facebook sign-on: control of the sign-on experience, the ability to chart your own course with your service, the first point of contact with members. Moreover, you'll cast your members into a realm of uncertainty about what will and will not be shared about their activity. Should Facebook sign-in be unavailable at any time, you're stuck until they fix it.

As an option, sure. But relying exclusively on a 3rd party, especially one known to make sudden and controversial moves around member privacy, is anti-experience.

Answer 8

You need to brainstorm and ask yourself the question: "What would I do differently with the product if I knew that all of my users were on Facebook?"

The answer could be "not much", in which case you should allow other logins.

If, however, in five minutes you can come up with killer features that you can implement with the assumption that everyone is on Facebook, then going Facebook-only is worth considering. Also, being able to make such assumptions in your code may speed up your development.

Another consideration: Depending on your target users, it's likely that the vast majority of users are on at least one social network, and there are various ways that social network users can spread news of your application virally. So you might require (or at least highly encourage) that people log in with credentials that are most likely to allow them to distribute your application virally (likely those with popular Like/+1/share buttons) at the expense of some users that are not as likely to help you grow your user base.

Practically speaking, if you are going to use multiple logins, you might decide start with two (just to make sure your code is factored appropriately) and then add more as you have time.

[disclaimers: I work on Facebook Platform, although these are my personal opinions.]

Answer 9

If you're going to pick one "must-have" for logins (as far as social networking goes), go with Twitter. Twitter doesn't shut down your profile after the investigation team finds out your using (gasp!) a handle!

That way you've got the auto-sign in, plus the (relative) anonymity. The "Facebook factor" is usually a deal-breaker for me when choosing my registration.

Answer 10

Is being on Facebook a requirement for all of your users. Does your site depend on the tools available through a Facebook association? Is your site important enough to make me create a FB account (i do not have one).

Personally, I would advocate the use of multiple (openID) logins for only specific type of sites. Leaving comments on blogs are a good example.

If the user expects to find some soft of history, such as past orders or reputation, offering multiple options can result to confusion. It took me few months to remember that i did not create a StackOverflow account, but used the Google login instead. If that happens on an e-commerce site, users might start disputing charges, or place duplicate orders.

Answer 11

I don't think you should limit only to Facebook logins, unless you are doing a Facebook app. And I think we are now well into an era of open authentication schemes that we shouldn't even be asking that question anymore. Users should expect you to support any of the major credentials they bring to the table.

Fortunately, we've also moved beyond the days when this all meant complex custom integration and coding.

For the past couple of years I've been using janrain engage (previously RPX) to add authentication whenever I need it for public sites.

• You don't need to hum and har about which services to support; they can handle pretty much every auth scheme you have heard of (but you can choose to use only some of them if you want)
• they have done a great job of making the sign-in screens simple, easy to use, and they plugin nicely to your site. I think they have done a great job with the ux, so you don't have to do much more other than decide the various ways to fit into your design. It is very easy for users to select the login service, and when they return it will remember which
• you don't need to pay programmers to develop and maintain every security option (and it is always changing).. That's what janrain have to do.
• they normalize all the attributes they might get from different services into a common profile, so you get access without needing do all that mapping and maintenance yourself. There is even user mapping (i.e. So the user can be the same person/account from your perspective, whether they login with twitter, fb etc)
• there is a free version, but even the paid versions are very reasonably priced (especially when you count the real cost of integrating yourself and maintaining it over time)

I recommend you check them out. It certainly beats reinventing the wheel (and paying programmers to do it also). It does impose some design constraints which I think in most cases are so minor compared to the benefits, but you would need to make your own judgements.

PS: I should add that janrain is not the only option out there for this - but it is the one I know best and have the most experience with.

Answer 12

Like others have mentioned, I wouldn't rely solely on a single service. I'd combine a conventional email/password registration method with something like Facebook or Google.

In 2009 I did the StackExchange thing and created a login screen for Regex Hero using the OpenID selector included in the DotNetOpenAuth project. The problem is that the user can be paralyzed by choice. For awhile I had some instructions in place telling the user to go to MyOpenID to register if they don't have an account with any of these providers. As a result there was an unusually high number of users signing up with MyOpenID. I think the problem is that people weren't actually reading the instructions and clicked the link because that's what it looked like they had to do to register. I've actually removed these instructions completely and that has helped somewhat. But I think it's still a culture shock for some people to see so many choices in front of them.

But there's one profound statistic from Regex Hero that has helped me -- 72% use Google. Granted, I don't have an option to log in with Facebook so I can't make that comparison. But Google is obviously a very popular option.

So I used that knowledge to design my login/registration pages at SilverlightXAP.com...

As you can see, there are only two options. Either use an email and password, or use your Google login. This keeps the UI simple and easy to understand. And it's working well with 39% using Google in this case.

Answer 13

There is an aspect of security here as well.

By limiting registration opportunities, a malicious user can acquire access to all services by stealing control of the registration site solely.

Answer 14

Can you analyse your existing user base to see which of Facebook, Twitter, Google+ etc. they use?

If you can then you could just target the ones that will cover 90% (as a figure picked out of the air) of them to include on the main page and the rest can be made available via an "other" link.

If you keep this information up to date then you can modify the sign in page to reflect the most current information.