Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Techniques To Simplify Sign-Ups and Log-Ins

smashingmagazine.com

Post reply on HN
Print view View original

91–100 of 178 posts

Re: Techniques To Simplify Sign-Ups and Log-Ins

#91

Post by masklinn »

bxr wrote: post #75
MatthewPhillips wrote: post #7

1000x times yes about the newsletter checkbox. Nothing turns me off to a service more than being tricked into receiving a newsletter. I consider those to be spam and mark them as such.

Having the newsletter unchecked by default is effectively the same as not having a newsletter. Personally, I think "don't have a newsletter" is a great idea (it reduces UI cutter too), but people want to send newsletters and the only way to make sending a newsletter worth the time spent to prepare it is by making it opt-out not opt-in. edit: I'm not saying I support this, just that a newsletter is never done in the u…

Opt-out newsletters are illegal in the EU, as per EU Directive 2002/58/EC.

Re: Techniques To Simplify Sign-Ups and Log-Ins

#93

Post by redstripe »

I just ask for an email address. I then email an auto generated password to the user. Their first login with the password I sent creates the account and takes them to their profile page which allows them to change their password or fill in other non essential info.

This system has a few benefits:

* No annoying "username already taken" or "password too short" rejections that make people give up.

* No junk accounts that haven't been verified since I don't create an account until the first login

* Person's email history has a record of their password if they're the type of person that doesn't care to change it.

* Since I'm really lazy, the account creation code is also the password recovery code. It just emails a new password.

I don't see any downsides with my system.

Re: Techniques To Simplify Sign-Ups and Log-Ins

#94

Post by dholowiski »

codenerdz wrote: post #66

Using an Oauth Provider for Signup and Login makes most of these techniques moot. For the service Im working on, im using a wonderful OmniAuth gem that together with Devise allows for easy support of popular OAUTH providers such as Facebook, Twitter, Linked In, Google, you name it. After dealing with forcing users to come up with yet another password to sign up for the service, I prefer that somebody else deals with…

What happens when your oauth provider goes out of business or decides they don't want to offer oath any more and you lose all of your users?

Re: Techniques To Simplify Sign-Ups and Log-Ins

#95

Post by aristidb »

redstripe wrote: post #93

I just ask for an email address. I then email an auto generated password to the user. Their first login with the password I sent creates the account and takes them to their profile page which allows them to change their password or fill in other non essential info. This system has a few benefits: * No annoying "username already taken" or "password too short" rejections that make people give up. * No junk accounts tha…

A downside might be that you send passwords over unencrypted e-mail?

Re: Techniques To Simplify Sign-Ups and Log-Ins

#96

Post by codenerdz »

dholowiski wrote: post #94
codenerdz wrote: post #66

Using an Oauth Provider for Signup and Login makes most of these techniques moot. For the service Im working on, im using a wonderful OmniAuth gem that together with Devise allows for easy support of popular OAUTH providers such as Facebook, Twitter, Linked In, Google, you name it. After dealing with forcing users to come up with yet another password to sign up for the service, I prefer that somebody else deals with…

What happens when your oauth provider goes out of business or decides they don't want to offer oath any more and you lose all of your users?

Ill take the risk of Facebook, Twitter, Linked, Google, etc going out of business before my service does :)

Re: Techniques To Simplify Sign-Ups and Log-Ins

#97

Post by theBobMcCormick »

uriel wrote: post #19
a3nm wrote: post #6

Using OpenID makes the rest of the techniques moot (except for OpenID providers), right?

OpenID is ridiculously complex for what it does (and in any case, complexity is the antithesis of security), and fortunately seems to have failed. The abstract idea was good, the standard itself is awful.

Actually, I would say that for the average user, a well done OpenID login is considerably less complex precisely because they don't need to make up another username/password to memorize or otherwise keep track of.

You need look no further than any of the stackoverflow related sites to see a very successful large scale site using OpenID.

I'd also suggest looking at tripit.com, catch.com, mindmeister.com or springnote.com to see excellent examples of OpenID login done in a way that's very user friendly while also providing the option of a traditional login for people who prefer it.

Re: Techniques To Simplify Sign-Ups and Log-Ins

#98

Post by codenerdz »

bane wrote: post #83

Not sure if it was accidental or not, but we ended up with the single simplest sign-up/login I've ever seen. We've even received a few emails from users alarmed at how simple it is. We're considering adding a few artificial steps (like filling out a profile) so that users feel more like they are creating an account. 1. Click login 2. Choose account provider 3. Grant us authorization access 4. Done - we pull your name…

One problem that I noticed is that not all OAuth providers give you the users emails as part of authentication data. Twitter and LinkedIn for instance dont, whereas Facebook does. How do you handle that?

Re: Techniques To Simplify Sign-Ups and Log-Ins

#99

Post by bane »

codenerdz wrote: post #98
bane wrote: post #83

Not sure if it was accidental or not, but we ended up with the single simplest sign-up/login I've ever seen. We've even received a few emails from users alarmed at how simple it is. We're considering adding a few artificial steps (like filling out a profile) so that users feel more like they are creating an account. 1. Click login 2. Choose account provider 3. Grant us authorization access 4. Done - we pull your name…

One problem that I noticed is that not all OAuth providers give you the users emails as part of authentication data. Twitter and LinkedIn for instance dont, whereas Facebook does. How do you handle that?

That's a good question. We're planning on adding support for all three of those in the near-ish future.

Very likely we're going to have to engineer an additional sign-in step for Twitter and LinkedIn that we don't need from Oauth providers that do provide the info:

1) Click login

2) choose twitter or linkedin

3) if the account is new, ask for name and email address

4) send out confirmation email with account activation link

5) user clicks activation link in the email

6) done

The reason for the activation email is that we really really need to confirm the address for our service to work correctly and to protect ourselves from spam. Otherwise we'd just accept what they enter.

For Twitter, we may decide to provide a slightly modified version of our service for scheduled tweets rather than scheduled email, but that'll be a ways off. In that case, if I remember correctly, we should get all of the relevant info from Oauth anyways.

Re: Techniques To Simplify Sign-Ups and Log-Ins

#100

Post by jrgnsd »

aristidb wrote: post #95
redstripe wrote: post #93

I just ask for an email address. I then email an auto generated password to the user. Their first login with the password I sent creates the account and takes them to their profile page which allows them to change their password or fill in other non essential info. This system has a few benefits: * No annoying "username already taken" or "password too short" rejections that make people give up. * No junk accounts tha…

A downside might be that you send passwords over unencrypted e-mail?

A fix for this can be to use a randomly generated pin or hash to act as a one time password. It will still be going over unencrypted email, but it will only be valid until the user confirms the account and chooses his own password.
Post reply on HN