Techniques To Simplify Sign-Ups and Log-Ins • Hacker News Board

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

#151

Post by tcarnell » Fri, May 06, 2011, 8:59 AM UTC

tcarnell wrote: post #150

From my experience of building web applications only two pieces of information are EVER required at registration time: 1). Email address - unlikely to be forgotten and is useful, ie you can then contact the user 2). Password - so the user can access the site. And I agree, dont ask twice for this, as long as you have a password reset feature. Any further information can be obtained once the user is inside the system -…

...so really what I am saying is that I can not think of a reason to ask for address, city, security questions, usernames etc at registration time.

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

#152

Post by ArtasBartas » Fri, May 06, 2011, 9:06 AM UTC

brimpa wrote: post #47

desigooner wrote: post #45

Earlier quoted context omitted.

The problem with the likes of friend.ly is that it forces me to use the email address associated with Facebook and it's PITA if you use multiple email accounts / filters for multiple purposes

The problem is nothing is editable (full name, birthday, location, email -- ok, they can have gender). If I'm signing up for some brand-new, unknown service, I'm usually not inclined to divulge anything more than an email address with an alias (+newsite@gmail.com).

You might want try out our service (Spockly.com) to tackle this problem: it allows you to limit your sign up form to email (& password) and get the basic info like age, gender, location from us. So sign up is straightforward, but you still get some insight about your users. Of course, it only works with people who have public profiles on social networks.

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

#153

Post by ma2rten » Fri, May 06, 2011, 9:23 AM UTC

In my option there is a lot of bad advise in there:

  Require Users to Type Their Password Only Once

At least I am very likely to overlook a typo, but less so to make the same typo twice.

  Allow Users to Auto-Fill Their Payment Address From the Shipping Address

Why not make a check box "same as billing address"? That way if people make a mistake they only have to correct it once.

  Don’t Check the Newsletter Option by Default. Offer a Preview Instead

And how many people will click on that preview ?

  Spambots can’t fill in the field because they can’t interact with objects in client-side JavaScript

sure

  Allow Users to Unmask Their Password

If I saw this I really would have no idea what the checkbox "check password" does.

  Make the “Submit” Button as Wide as the Text Fields

Never had problems with being insecure which action I was about to take when I logged into facebook.

  Allow Users to Log in Via Facebook, Twitter or OpenID

I don't have twitter, OpenID confuses me and I hate websites where I have to login with facebook.

But don't get me wrong I still think it's good to think about this stuff and don't take everything for granted, just because everyone does it. From that perspective it is a great post.

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

#154

Post by bluesmoon » Fri, May 06, 2011, 9:52 AM UTC

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…

better to send a single-use capability URL.

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

#155

Post by hessenwolf » Fri, May 06, 2011, 10:36 AM UTC

p4bl0 wrote: post #77

bjonathan wrote: post #24

the best signup flow I have seen recently is http://friend.ly perfect integration of facebook .

The best signup flow is no flow at all. I liked a lot what Posterous did.

I don't remember signing up to posterous, so it must be pretty on the money.

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

#156

Post by ZoFreX » Fri, May 06, 2011, 11:44 AM UTC

plasma wrote: post #120

ZoFreX wrote: post #101

> use a hidden and required text field generated with client-side Javascript So now only users with Javascript enabled can use your website. I'm sure that will increase conversion. > Spambots can’t fill in the field because they can’t interact with objects in client-side JavaScript; only users can. Not true anymore. > you can create a honeypot form field that should be left blank and then use CSS to hide it from huma…

Is not having JavaScript really a problem? I never even consider it anymore.

It varies from website to website, there's no firm rule on it. Different market sectors will have different Javascript support, for example people on HN are (probably, I haven't checked the stats) more likely to be running NoScript, or to be browsing from something like Lynx.

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

#157

Post by mooism2 » Fri, May 06, 2011, 11:51 AM UTC

mekoka wrote: post #73

Another thing that I'll start to experiment with is delayed confirmations. The confirmation step via emails is one of those things that has been copied over and over, without knowing, in many cases, what problem it addresses in the first place and if it's crucial to one's particular situations. I think having to interrupt your visit to log into your email, is another speed bump to a smooth registration process. A bet…

A danger here is that a new user makes a typo in their e-mail address when signing up, puts a fair amount of effort into their new profile/account/whatever, and is then locked out forever. They won't realise they made a typo and will blame the site instead.

But I agree that new users having to leave the site to check their e-mail is a hurdle to get over.

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

#158

Post by jules » Fri, May 06, 2011, 2:06 PM UTC

lukifer wrote: post #147

redstripe wrote: post #110

Earlier quoted context omitted.

If someone has access to your email client you're hooped anyway. There is nothing stopping an extra security conscious user from deleting the email and changing their password right away. What it does is to give a convenience to users that want to treat your service as a trial. Picking unique user names and password is too far down the developing a relationship path for me personally.

Against knowledgeable techies, sure, you're hosed either way. I'm talking about more casual security threats: a mischievous child, a bad breakup, a sneaky Best Buy bench tech. It's the difference between leaving your front door unlocked, versus leaving it wide open.

Don't most sites offer password recovery via email?

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

#159

Post by jtheory » Fri, May 06, 2011, 2:14 PM UTC

pbz wrote: post #109

skx wrote: post #87

Earlier quoted context omitted.

The way that I've always handled this is to only show the "Forgot Password" link after a login attempt fails. Maybe that's unfair; expecting a user to attempt to login even if they're not sure of their details, but it always seemed reasonable enough to me.

That's not intuitive. When I go to a site I know if I remember the password or not. If I have no clue what the password could be I won't even attempt to login. If I don't see the "forgot password" link I would assume the site doesn't have that feature and leave.

Agreed -- particularly because the site may have some kind of lockout feature if I fail too many attempts, there's no chance I'll waste one just to see if there's a forgot password link on the failure screen.

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

#160

Post by jtheory » Fri, May 06, 2011, 2:20 PM UTC

pamelafox wrote: post #117

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…

We did that for an app, and let people pick from Google, Twitter, or Yahoo. They'd sometimes forget which one they'd chosen (like after being away from a bit or clearing the cache), and then login with a different one and get confused as to why their data was missing. Do you encounter that at all with your users?

That's what kills me about these flexible sign-ins -- I was locked out of stack overflow for months because I have accounts on all of these providers, sometimes more than one, and I had no clue what I'd used initially.

No idea what the solution to this problem is, but I suspect it isn't going away.