Techniques To Simplify Sign-Ups and Log-Ins(smashingmagazine.com)
smashingmagazine.com
Techniques To Simplify Sign-Ups and Log-Ins
http://www.smashingmagazine.com/2011/05/05/innovative-techniques-to-simplify-signups-and-logins/
177 comments
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 - and full explainations can be given as to why particular information is required.
And never use captcha! There are a millions tricks that you can employ to avoid bots.
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 - and full explainations can be given as to why particular information is required.
And never use captcha! There are a millions tricks that you can employ to avoid bots.
...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.
> Log Users in Without Leaving the Page
As someone who uses LastPass, don't do this. It (usually?) won't let LastPass log you in to the site nor save the log-in details for a new site - a huge pain in the ass.
On another note, if I fail to enter the right details or check the right boxes, don't let me start all over again! Opera is great in how it lets you go back and retain all entered data, but other browsers are not as good at this.
As someone who uses LastPass, don't do this. It (usually?) won't let LastPass log you in to the site nor save the log-in details for a new site - a huge pain in the ass.
On another note, if I fail to enter the right details or check the right boxes, don't let me start all over again! Opera is great in how it lets you go back and retain all entered data, but other browsers are not as good at this.
Regarding auto-completing the country field, most modern web browsers allow you to enter text in a drop-down field, and they will auto-complete for you. (Although last I checked, IE had the annoying tendency to simply choose an entry starting with each character you typed.)
But how many users know that? Also you have to know exactly how they spelled the your country name which isn't always known, such as USA versus United States, and UK versus Great Britain.
Any ideas for speeding up birthdate entry? Lots of sites need it to comply with COPPA.
A single button or checkbox labelled "I am 13 or more years old."
Been a fan of this login (http://www.janrain.com/products/engage) service by janrain for some time. Use it where I can on apps.
OpenID, or email address -> confirmation.
been looking for good writeups on sign-up best practices. thanks for this!
A lot of these seem to be, "do this really nonstandard thing because it suites my tastes." I'm all for streamlining, but if you change a common way of doing things, and you're not targeting a technical crowd, your new way had better be crystal clear.
As someone who talks to non-native English speakers, "check password," is triggering a burning rage within me. There is so much potential for misunderstanding.
As someone who talks to non-native English speakers, "check password," is triggering a burning rage within me. There is so much potential for misunderstanding.
Thats a great article. The first two points inbound the most interesting... Let the user choose a username after they sign up - I wonder what sites do that now, it's a good way of removing a barrier to entry.
The second I'm not so sure about... Having the user enter their password once and showing it to them - I'd be worried that you might lose users to simple typos.
Most of the rest is kind of common sense but a great reminder that the login/signup system is probably the _most_ important feature of a web site, since it's the one users interact with most often.
I believe StackExchange allows you to create a username after you've created an account, you start off with something like "user12345" if you don't specify one.
"Use a Question Mark Icon for the Password Recovery Link"
Am I the only one who thinks that is really unintuitive? I don't even think clicking on that icon would cross my mind as a user, and I would spend my time trying to find the "Forgot Password" link.
Am I the only one who thinks that is really unintuitive? I don't even think clicking on that icon would cross my mind as a user, and I would spend my time trying to find the "Forgot Password" link.
I would have expected that to be a tooltip that describes what a password is, not a reset link.
You're right. In fact, the number one lesson I've learned designing websites is that any time you're sure that users will understand what you mean, they absolutely will not. That's the one tip from this article that I completely disagree with.
Agreed. So much of making things easy for the user is sticking to convention and giving them what they expect to see.
I think most places use the "Forgot Password" link now so I think most people come to expect it. I know I would.
I think most places use the "Forgot Password" link now so I think most people come to expect it. I know I would.
Yeah, I think at the very least this would be in addition to a "Forgot Password" link instead of replacing it. My favorite software seems to read my mind by supporting multiple ways of doing things, including whichever way I expect. But I like the idea of putting an extra link close to the field itself. Maybe "Password: (_Forgot?_)"
Agreed, that was an odd one (I've never even seen a site that does that). Other than that everything looked good though.
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.
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.
I like sites that make the "Forgot Password" link much more visible after a failed login.
One of the issues with a "forgot password" link is that it's visual clutter. Could only have the link show if the user has moused over the form area?
CAPTCHA's are always annoying, no matter what. So why not make some money. Lots of new companies out there offering CAPTCHA ads.
While you're right that all CAPTCHAs are annoying, the CAPTCHA ads are a whole different level of annoying. I think you'd lose more goodwill than you'd gain in money from doing this.
depends, I believe it will depend on what the user has to type.
I disagree. I'd find an ad in my CAPTCHA to be sleazy regardless of what I had to type. It's a bad idea, full stop.
Using OpenID makes the rest of the techniques moot (except for OpenID providers), right?
I think OpenID has proven to be uneffective, some (HN popular) sites have removed it again (37signals? not sure).
I have problems with OpenID, too, because I tend to be unable to remember which OpenID login I used for a site.
I have problems with OpenID, too, because I tend to be unable to remember which OpenID login I used for a site.
Why do you use more than one? I thought the point was that you could sign in once with your OpenID and be signed in everywhere.
It just happened, I was a little bit careless and used both Yahoo and Google. I don't remember the exact problems anymore - I think also if the web site does not link directly to the OpenID provider it is hard to fill in the details.
Or maybe it was that Yahoo creates several OpenID logins?
Or maybe it was that Yahoo creates several OpenID logins?
Unfortunately, the prevailing sentiment right now seems to be that OpenID is not a good idea.
Why, exactly? I'm about 100x more likely to sign up for your site if you let me press a button and log in with my Google account. It's also really easy to implement with Django middleware.
Google turns up a Quora thing which, frankly, is full of handwaving bullshit.
Are there actual technical reasons why OpenID is bad?
Google turns up a Quora thing which, frankly, is full of handwaving bullshit.
Are there actual technical reasons why OpenID is bad?
I wasn't talking about whether I thought it was good or bad, just that it seems to me like most people on HN usually look down on it.
And the reasons are mostly ones of user-friendliness (not technical reasons). I've heard of plenty of people who still never signed up for StackOverflow because it requires OpenID.
And the reasons are mostly ones of user-friendliness (not technical reasons). I've heard of plenty of people who still never signed up for StackOverflow because it requires OpenID.
As far as I understand it, OpenID is still used, for letting people login with Google or even Yahoo accounts, but no longer with full flexibility in OpenID providers.
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.
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.
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.
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.
And giving a preview makes the newsletter sound like something you're offering to the customer, not something undesirable you're trying to inflict on the customer.
What I really want to see in newsletter sign up forms is how often and what type of messages I will receive.
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 users' interest but as an advertizement. It might make for good UX for the user for it to be unchecked, but thats kind of the point, the entire concept of the newsletter relies on bad UX to gain subscribers.
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 users' interest but as an advertizement. It might make for good UX for the user for it to be unchecked, but thats kind of the point, the entire concept of the newsletter relies on bad UX to gain subscribers.
I've signed up for a few newsletters on purpose before, if (a) the product and/or content was compelling enough, and (b) the checkbox told me unambiguously what the newsletter would contain, and most importantly, how often it is sent (monthly is ideal).
Assuming your newsletter might be something your users would actually want to read (crazy, I know), the newsletter preview link is a fantastic idea.
Assuming your newsletter might be something your users would actually want to read (crazy, I know), the newsletter preview link is a fantastic idea.
Opt-out newsletters are illegal in the EU, as per EU Directive 2002/58/EC.
Article 13.5 means that only article 13.2 applies to non-natural persons (ie businesses, very weird) and hence "provided that customers clearly and distinctly are given the opportunity to object, free of charge" to receipt of messages then it appears a company can spam you if you first gave them contact info in some way.
Indeed the Article only says they have to allow you to object, nothing about the company not sending you repeated emails when you do object.
Looks badly drafted and without teeth IMO.
--- http://en.wikipedia.org/wiki/Directive_on_Privacy_and_Electr... http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:... - full current text
Indeed the Article only says they have to allow you to object, nothing about the company not sending you repeated emails when you do object.
Looks badly drafted and without teeth IMO.
--- http://en.wikipedia.org/wiki/Directive_on_Privacy_and_Electr... http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:... - full current text
Directives don't really have teeth, per se. They don't take direct effect, but need to be passed into each member's country law separately.
AFAIK most made opt-out illegal, even if the directive didn't necessarily require it well.
AFAIK most made opt-out illegal, even if the directive didn't necessarily require it well.
Do you know of any quick reference to the individual laws created as a result of ratification of these articles?
It's still unethical IMHO.
Admittedly I hadn't heard of using a client-side JS input box as an alternative to a Captcha. Does that sort of thing actually work, or can spammers get around it? Is there any anecdotal data to suggest that that's a better method? (not snarking; actually curious)
I guess the problem is that it stops working when you start being big enough to attract the spammers' attention and get bots tailored to your registration system. In the meantime, I guess this is just to avoid problems with general stupid bots which just fill out all the forms they can't find without trying anything fancy.
No client-side method can ever work against a sufficiently motivated spammer.
For example... 1) Start capturing packets via wireshark. 2) Fill out the form. 3) Replay the captured packets, altering the username.
Presto, now you can sign up as fast as you want.
For example... 1) Start capturing packets via wireshark. 2) Fill out the form. 3) Replay the captured packets, altering the username.
Presto, now you can sign up as fast as you want.
The strategy you suggest, capturing packets, won't work against any reasonably modern codebase that has XSRF prevention. I agree with your initial statement, but I highly recommend Seleinum scripts instead of wireshark for your spamming needs. It is slower, but much more likely to actually work.
I like the other suggestion about the hidden form a little better, it doesn't really sound bulletproof to me but anything is better than a Captcha.
I'd be very careful when considering and implementing most of these ideas. While the sentiment is correct (make users' experience easier), many of these approaches have pitfalls or require fallbacks.
Your signup and login pages MUST be bulletproof.
Autofilling city/state from zip, for example, requires an updated database of postal codes, but users will often consider your autofill city as "wrong", since they use a different district/locale name. Make sure users can override your guesses.
Your signup and login pages MUST be bulletproof.
Autofilling city/state from zip, for example, requires an updated database of postal codes, but users will often consider your autofill city as "wrong", since they use a different district/locale name. Make sure users can override your guesses.
Does anybody else think unmasking the password field is a terrible idea?
It's terrible in the biggest way you can fuck up your UI: doing the opposite of what every user expects
Billions of people are all used to typing into masked (or unechoed) password fields, having done so in a wide range of UIs a shitload of times. Typing into a password field and seeing it reflected back feels like a slap in the face, the security context is irrelevant, it's just a massive discourtesy.
Your website is not going to be the very first thing the user has ever logged into. It is not your place to try to reinvent such fundamental things, changing this on your site is on the same level of jackass hubris as reversing the tab order or mouse coordinate system with javascript. All you're going to do is infuriate people.
Billions of people are all used to typing into masked (or unechoed) password fields, having done so in a wide range of UIs a shitload of times. Typing into a password field and seeing it reflected back feels like a slap in the face, the security context is irrelevant, it's just a massive discourtesy.
Your website is not going to be the very first thing the user has ever logged into. It is not your place to try to reinvent such fundamental things, changing this on your site is on the same level of jackass hubris as reversing the tab order or mouse coordinate system with javascript. All you're going to do is infuriate people.
No. It is something of a sham. It protects you from one use case: people watching the screen over your shoulder. It does not guard against people watching your fingers on the keyboard. It does provide a sense of security. I have no problem shielding the password with a hand over the screen, clicking the box, checking, and unclicking.
It also prevents copy/pasting out of that field by most browsers.
If someone gets access to your computer because you walked away for a second, goes to your bank page and it autofills, they can access the site, but they can't know your password (which is generally shared between many sites), and so they can only do damage there locally for a (hopefully) brief period of time.
If it just displayed in a textbox, game over...
If it just displayed in a textbox, game over...
Sure, copy-paste, but if you monitor the outgoing query via Firebug, you can get the raw password. (This is confirmed with the gmail password input.) I have also in the past used various Windows tools for finding the value of a text box or for toggling the hiddenness of the text. Basically, if someone has access to the machine where your password is stored in any form, all bets are off.
I think it depends of the sensitivity of the material in the website. e.g. I would never do this for a financial service website, just in case I get sued later. If your website doesn't require https for logins, then unmasking the password at registration time is the least of your worries.
It should nonetheless be noted that many browsers cache values entered in non-password fields, so if someone is using a shared computer to register, the next person might only have to double-click on the non-hidden password field to see a list of previously entered passwords. Not so good.
It should nonetheless be noted that many browsers cache values entered in non-password fields, so if someone is using a shared computer to register, the next person might only have to double-click on the non-hidden password field to see a list of previously entered passwords. Not so good.
Does the value in a field that gets toggled between password and plaintext get cached when the field is a password at the time the form is submitted? We could always ensure the field was in password mode at that instant.
The same can be said for credit card information, thats why autocomplete="off" exists.
A lot of the time I use a computer outside of work, I am alone in a house into which no one can see or I am alone in a house with my partner with whom I share all of my passwords. As such, I'd rather have the option of unmasking my password because it makes things easier for me. I use long passwords and so it's not rare (though neither common) for me to type it wrong so I end up typing my 'password' 4 or 6 times.
There are probably purpose-built plugins to show passwords, but you can also use the very popular Web Developer plugin if you use Firefox -- to make password fields visible, in the context menu hit:
> Web Developer > Forms > Show Passwords
You can also type your password into the username field first, then cut & paste it into the password field before entering your actual username.
Some years back while traveling and using dubious internet cafes I used to (I imagined) defeat keyloggers and at the same time navigate foreign keyboard layouts by typing my password mixed-up into the username field, then copy/pasting it a piece at a time into the correct order in the password field.
> Web Developer > Forms > Show Passwords
You can also type your password into the username field first, then cut & paste it into the password field before entering your actual username.
Some years back while traveling and using dubious internet cafes I used to (I imagined) defeat keyloggers and at the same time navigate foreign keyboard layouts by typing my password mixed-up into the username field, then copy/pasting it a piece at a time into the correct order in the password field.
One that gets missed almost everywhere is: if I type the wrong username or password, keep my username in the field (so many erase the forms when returning the error). That way I can tell if the mistake was in my username or my password and if it was in my password I don't have to retype everything.
i think its done to prevent brute force attacks on passwords. If someone knows that username was correct and password wasn't, he knows something! That's why the message 'username or password does not match' and that's why both the fields needs to be empty when page loads with error.
Depends on whether the login username is public or not.
If you're on a community based site where others can see your username, there's no reason to hide it. Anybody trying to brute force your password is probably specifically targeting your account.
On the other hand, if you're on a service where other people cannot see your username, it would indeed be better to return a 'username or password does not match' error.
If you're on a community based site where others can see your username, there's no reason to hide it. Anybody trying to brute force your password is probably specifically targeting your account.
On the other hand, if you're on a service where other people cannot see your username, it would indeed be better to return a 'username or password does not match' error.
I don't think the idea is to indicate whether or not the username is correct. No matter what the user enters for the username, when you spit back "username or password incorrect," fill the username with what they typed. A brute force attacker gets no more information than he would with an empty username field because what comes out is identically what he put in, but a real user who mistyped his password knows this immediately by checking the username field and verifying it's correct.
Makes sense.
You're correct about the message, but actually you don't fill out the password field because you should never return the password to the client. It is OK to return the username to the client, and does not imply that the username was correct as long as the messaging is as you said.
why would you want to show something to user that's wrong or does not exist? Most usernames are anyways smaller and its not painful to enter it again. If you want to serve people with very long usernames by filling in the username field, you are focusing on a very small fraction of users.
Because it's easier to correct something that's almost correct than to start over, and because it would help you determine if the username or the password was at fault.
Is it, though? I find it far easier and faster to click on field, type username vs. look at field, see username is incorrect, click on the field, highlight/backspace to select, re-type part of the username.
If I've gotten my username wrong, it's usually because I made a typo, in which case, re-typing it will solve the issue, or because I simply don't remember it, in which case, seeing what I typed previously isn't really going to help with that.
If I've gotten my username wrong, it's usually because I made a typo, in which case, re-typing it will solve the issue, or because I simply don't remember it, in which case, seeing what I typed previously isn't really going to help with that.
And how do you know if someone was playing around with usernames or genuinely trying to login? I agree with 'dvdhsu' comment that if its a public service where others can see username its fine to load error form with username but if its a service where other users couldn't see your username its not a good idea to load error form with username irrespective of whether it was right or wrong.
Why does it matter? You assume the best and help the good guy, and in the worst case you don't help the bad guy.
You shouldn't be thinking about security in your validation anyway.
You shouldn't be thinking about security in your validation anyway.
We should always be thinking about security, particularly when validating security credentials. (But remember that security is a trade-off.)
But I don't see the security cost in populating the username box with what the user previously typed there. We're just echoing back what the user typed. The only extra information we've provided is that the potential attacker can't login with that username+password --- we don't say whether this is because the username is invalid or because the password is incorrect for that username.
But I don't see the security cost in populating the username box with what the user previously typed there. We're just echoing back what the user typed. The only extra information we've provided is that the potential attacker can't login with that username+password --- we don't say whether this is because the username is invalid or because the password is incorrect for that username.
I have never understood why I need to type my password twice. Inevitably I just copy what I wrote in the first box into the second.
I'm also interested in the elimination of the post sign-up confirmation email. I'd rather get a "Welcome! If you didn't sign up for this service, click here" email, but I can imagine that if I didn't actually sign up for the service, I'd never want to "click here" for fear of spam. There has to be another option, though. Anyone have any bright ideas?
I'm also interested in the elimination of the post sign-up confirmation email. I'd rather get a "Welcome! If you didn't sign up for this service, click here" email, but I can imagine that if I didn't actually sign up for the service, I'd never want to "click here" for fear of spam. There has to be another option, though. Anyone have any bright ideas?
> I have never understood why I need to type my password twice. Inevitably I just copy what I wrote in the first box into the second.
You have to type it twice, because you don't see what you typed the first time -- it's a validation.
You don't see what you typed the first one, because that's "standard practice" for passwords, so that no one looking over your shoulder will see the password you typed.
That makes sense sometimes -- e.g., when you register for your new gmail at a starbucks. For me, 99.9% of the time, that's not an issue -- I'd much rather have a checkbox that says "press here to hide password".
But that's the standard practice.
You have to type it twice, because you don't see what you typed the first time -- it's a validation.
You don't see what you typed the first one, because that's "standard practice" for passwords, so that no one looking over your shoulder will see the password you typed.
That makes sense sometimes -- e.g., when you register for your new gmail at a starbucks. For me, 99.9% of the time, that's not an issue -- I'd much rather have a checkbox that says "press here to hide password".
But that's the standard practice.
Having to type your password twice is a perfect UI affordance -- it makes it obvious that you're signing up for a new account and not just logging in to an existing one.
It's especially important because a streamlined workflow will have both forms on the same page. It's infuriating to try to log in and get an "account already exists" error. HN is one of the very few sites that make this mistake.
It's especially important because a streamlined workflow will have both forms on the same page. It's infuriating to try to log in and get an "account already exists" error. HN is one of the very few sites that make this mistake.
You type your password twice because you might make a mistake. Also, you can't copy anything from passwords fields.
Sorry I misspoke -- I copy/paste from email confirmation fields. And I understand why password confirmations exist, but I think the option posed in this article is a much more elegant solution to that issue.
The post sign-up confirmation email is proof to the service that you indeed opted-in to their service and agree to receive future emails. Without a confirmation, the service is at risk of being blacklisted for spam.
Yeah, I understand. The email confirmation link just seems like such a barrier to entry. Do you get annoyed every time you have to go confirm your email address? I do.
the best signup flow I have seen recently is http://friend.ly perfect integration of facebook .
I am reallllyyyy not comfortable with revealing my real identity on sign-up to a new website. It admits me to consequence in a lawless zone, full of wankers, that never forgets.
Also, I google everybody, whether because I am reviewing your cv, or because you are a friend of a friend. Facebook connect is a definite no-no.
Also, I google everybody, whether because I am reviewing your cv, or because you are a friend of a friend. Facebook connect is a definite no-no.
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 ([email protected]).
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.
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.
Personally, I'd like the option of using another signup provider other than FaceBook.
> Spambots can’t fill in the field because they can’t interact with objects in client-side JavaScript; only users can.
Not true anymore. What you could do is add a hidden field with value=encrypt(timestamp+salt) and only accept the form if the decrypted timestamp is at most x hours old. If you want to further restrict it, you could also add the IP to the encrypted value. This will fail if a user gets a new IP between loading the form and submitting it (laptop user moving around, VPN gateway changes etc).
Not true anymore. What you could do is add a hidden field with value=encrypt(timestamp+salt) and only accept the form if the decrypted timestamp is at most x hours old. If you want to further restrict it, you could also add the IP to the encrypted value. This will fail if a user gets a new IP between loading the form and submitting it (laptop user moving around, VPN gateway changes etc).
Another technique against spambots that I've used along the line of "hidden fields" is to have a textfield that should NOT contain anything at submission time.
You hide the textfield (margin: -10000px) and give it a name unique enough, that browsers with autofills won't have a record of a value ever entered there.
Spambots usually fill every fields, so if you see a value in the field when you process the registration, you know that it's highly likely that a non-human is registering. You now have the option of rejecting it, or accept it but put the account in a "monitor" queue.
One pitfall is that this scheme expects everyone registering to uses css. You can however give various hints to non-css users, to keep the textbox empty.
You hide the textfield (margin: -10000px) and give it a name unique enough, that browsers with autofills won't have a record of a value ever entered there.
Spambots usually fill every fields, so if you see a value in the field when you process the registration, you know that it's highly likely that a non-human is registering. You now have the option of rejecting it, or accept it but put the account in a "monitor" queue.
One pitfall is that this scheme expects everyone registering to uses css. You can however give various hints to non-css users, to keep the textbox empty.
That's wasted effort. The bots are usually built by humans, and the humans can detect that and build the bot to ignore text fields with margin < -1000 or the unique name or something.
I think it depends on if you are trying to avoid automated attacks or targeted attacks. There seem to be a lot of bots scanning for vulnerable sites - this would potentially work for those.
If you get targeted specifically, then, yeah, the human in charge can figure it out in short order.
If you get targeted specifically, then, yeah, the human in charge can figure it out in short order.
I agree. I think this method is a great idea and is much more foolproof:
"You could also use Honeypot Captcha approach: you can create a honeypot form field that should be left blank and then use CSS to hide it from human users, but not bots. When the form is submitted, you check to make sure the value of that form field is blank."
http://haacked.com/archive/2007/09/11/honeypot-captcha.aspx
"You could also use Honeypot Captcha approach: you can create a honeypot form field that should be left blank and then use CSS to hide it from human users, but not bots. When the form is submitted, you check to make sure the value of that form field is blank."
http://haacked.com/archive/2007/09/11/honeypot-captcha.aspx
Fails the same test. I build what can be considered bots for a living, though they have nothing to do with spamming or otherwise shady reasons.
Part of the process in building the bot is to send exactly what a browser would send, and we do this by actually making the requests in a browser and viewing the raw request. If my browser doesn't send a honeypot captcha, neither does my bot.
Part of the process in building the bot is to send exactly what a browser would send, and we do this by actually making the requests in a browser and viewing the raw request. If my browser doesn't send a honeypot captcha, neither does my bot.
Say you have a field hidden with a div on a low profile, minimum traffic site (100 visitors a week). It's incredibly unlikely and pretty dumb for a bot to be made specifically for that site -- in this case, how could a bot determine whether that field should contain a value or not?
I use honeypot fields, but you have to be really careful with them, and certainly do NOT just discard requests with the honeypot field filled, as the article suggests.
About 6 months ago, the new version of Chrome started auto-filling email addresses into my honeypot field, so it was a good thing I returned a friendly message (explaining that some auto form-fillers might cause this error, and needed to be temporarily disabled) rather than just assuming "bot".. but I still had some pissed-off people who had been trying to give me money and couldn't.
It's also worth noting that honeypot fields are only useful on a small site that is unlikely to be specifically targeted. A custom-tweaked bot can very easily bypass a honeypot field, of course.
About 6 months ago, the new version of Chrome started auto-filling email addresses into my honeypot field, so it was a good thing I returned a friendly message (explaining that some auto form-fillers might cause this error, and needed to be temporarily disabled) rather than just assuming "bot".. but I still had some pissed-off people who had been trying to give me money and couldn't.
It's also worth noting that honeypot fields are only useful on a small site that is unlikely to be specifically targeted. A custom-tweaked bot can very easily bypass a honeypot field, of course.
I don't understand your suggestions. If the spammer can run javascript (e.g. Selenium), how would your timestamps / ip stuff help? Seems like it would just add complexity without any benefit.
The behavior being stopped is repeated POSTs to create new accounts - a spammer would instead have to GET the form every couple of hours (or if they don't realize the trick, possibly each time), something they'd hopefully do from the same IP = easier to see and ban.
Granted, if they have a huge network of distributed bots, it probably won't help. But, if they do try to register a bunch of accounts using the same timestamp hash, it'd be easier to nuke all of them at once when you discover what's going on.
Granted, if they have a huge network of distributed bots, it probably won't help. But, if they do try to register a bunch of accounts using the same timestamp hash, it'd be easier to nuke all of them at once when you discover what's going on.
How do you handle users coming through corporate proxies that hide their internal addresses?
Autofocusing the login field is a bad idea. Sometimes the javascript take some times to load and the user already filled the login field and is already typing is password when the javascript focus the login field: then the password is written in clear on the screen, and that's not pleasant for the users.
That's why you should use HTML5 autofocus attribute (perhaps with a JS fallback).
http://www.whatwg.org/specs/web-apps/current-work/multipage/...
http://www.whatwg.org/specs/web-apps/current-work/multipage/...
I always embedded the focus javascript immediately after the username, so that as soon as that part of the DOM is loaded, the user's input is focused there.
You could get around this by first checking if another field has input.
I hate being forced to login with my email address. My username is the same or similar for most sites I use but I use a site specific email (with gmails + feature) for almost every sign up.
to counter this, i prefer using my email. it's always unique and i don't need to make something up if my goto username is already taken.
Do you hate it because you end up having to type a longer username than you'd prefer? Or what?
i presume you use that to filter spam. you could always have your userid as your email where the email is always
[email protected]
however, i have noticed some sites dont like the + which sucks because the spam model breaks down
however, i have noticed some sites dont like the + which sucks because the spam model breaks down
right, I have that problem, remembering whether or not the site accepts the + as well as an issue with sites with long or weird to spell domain names.
I feel that asking a user for the right username after they sign up wastes even more time when they can settle it all at once at the sign up page... The tips mostly reduce hassle and why cause them more trouble by alerting them that their username is already taken when they felt they're already set to use the site.
But asking for the username after sign-up gets you the user's email address. If they don't create a username, you can now provide direct support and ask if they need help with the next step in the sign-up process, etc.
I'm skeptical of such articles, but this one had a lot of good advice.
I so hate country selection popups that have 200 countries in them, and United States is near the bottom even though 95% of their customers are in the US, or perhaps they don't even ship outside the US. So many sites do that and it is infuriating.
I so hate country selection popups that have 200 countries in them, and United States is near the bottom even though 95% of their customers are in the US, or perhaps they don't even ship outside the US. So many sites do that and it is infuriating.
> I so hate country selection popups that have 200 countries in them, and United States is near the bottom
Another related problem for us Brits is that you sometimes end up doing a hunt up and down the list for one of "United Kingdom" -> "England" -> "Great Britain" -> "Britain" -> "British Isles" -> "The United Kingdom" etc. etc, whilst trying to remember all the different "synonyms".
Another related problem for us Brits is that you sometimes end up doing a hunt up and down the list for one of "United Kingdom" -> "England" -> "Great Britain" -> "Britain" -> "British Isles" -> "The United Kingdom" etc. etc, whilst trying to remember all the different "synonyms".
Even that is unnecesary. Every shady "live chat with girls on Guadalajara" ad knows where I am located. Why is that the stupid registration form can't?
This kind of thing is the curse of using off the shelf e-commerce packages. You can easily avoid these kind of mistakes if you roll your own.
Then why does Skype do it for every out-going phone call? I have to select US from the drop down list every time I make a call even though my Skype number is US based.
Or just dial the full number, starting with a plus. For a Colorado number, for example, +1303..... and it'll correctly select the country and just work. (It'll detect the country as soon as it can. For country code 1, that means 4 digits, to see if it's US, Canada, or one of the many islands using the same area code (NANP).)
I remember reading in the Gnome Human Interface Guidelines (a document that defines consistency standards for gnome (linux gui) applications) that countries should always be alphabetically ordered as to not appear to favor any of them. Interestingly, it doesn't appear to be in the guidelines anymore though.
That makes a lot more sense in Gnome, a world-distributed open source project, than it does on many websites, where it's quite easy to figure out the source of the majority of your traffic.
My skype defaults to the country listed in my profile. Maybe yours does too?
These are all great suggestions. Smashingmagazine is a great resource for developers.
I'm not quite sure about a checkbox to confirm password...maybe I need to see it actually implemented somewhere to know if I like it.
I'm not quite sure about a checkbox to confirm password...maybe I need to see it actually implemented somewhere to know if I like it.
It's basically equivalent to the "show characters" checkbox in your wifi password entry.
That's there in the WiFi dialog for a very specific reason: you're usually typing in someone else's password, which is often being dictated to you as you type, so mistakes are inevitable.
In every other case it's your password that you type all the time (or paste). In the rare instance that you fuck up it's easier to enter it again than it is to fix it.
In every other case it's your password that you type all the time (or paste). In the rare instance that you fuck up it's easier to enter it again than it is to fix it.
The checkbox isn't the confirm your password...it's to make the actual characters show up so you can see that you've typed the right thing.
Not sure I love the idea, because there will be certain situations when a user can't use it, but it's worth considering...
Not sure I love the idea, because there will be certain situations when a user can't use it, but it's worth considering...
Yeah, I'd want to do some experimentation with the label of the checkbox. I would guess something like "Show password" might be clearer as to the purpose of the checkbox than "Check password".
Depending on the security needed for a particular application I have been wondering why not just Email for authentication since its common for password recovery. More here: http://blog.headspin.com/?p=352
Seems like an interesting proposition and makes sense overall. I can think of a few issues however.
1. You always need access to email to get access to a website. This means that for whatever reason you don't have email access, you are locked out of all sites.
2. While it works from a security standpoint, you still add overhead to the users task. Users have to go between website and email and back to website just to log in.
3. slow connections might make the task even more cumbersome since you now add the delay of checking emails just in addition to logging into the website.
1. You always need access to email to get access to a website. This means that for whatever reason you don't have email access, you are locked out of all sites.
2. While it works from a security standpoint, you still add overhead to the users task. Users have to go between website and email and back to website just to log in.
3. slow connections might make the task even more cumbersome since you now add the delay of checking emails just in addition to logging into the website.
Agree on all points. But I still like the idea as an optional way for people to log quickly in without having to give the site owner any password info.
And yeah its a little more tedious if the site doesn't have a long session time.
And yeah its a little more tedious if the site doesn't have a long session time.
That's why I like using it in conjunction with passwords. The forget password link just provides an auto-auth one-time use link that suggests (but doesn't force) the user create their new password.
In theory, you could just continue to click "Forgot password" every time you need to log in, indefinitely. Some sites that offer this sort of functionality, that's what I do.
What I hate is when the forgot password link FORCES you to change your password. If there's a forgot password link that lets me log in easily via email, then I see no reason to be forced to change my password.
In theory, you could just continue to click "Forgot password" every time you need to log in, indefinitely. Some sites that offer this sort of functionality, that's what I do.
What I hate is when the forgot password link FORCES you to change your password. If there's a forgot password link that lets me log in easily via email, then I see no reason to be forced to change my password.
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 that and I just store OAUTH tokens
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 :)
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 better approach, in my opinion, would be to let users just start interacting with your service right away. Give them 5 to 7 days to confirm their account, after which it is automatically suspended. You can let them know the next time they try to login that they never actually clicked the link they received via email a week earlier. The timeframe is long enough that they can actually use the service with no hassle and it's short enough that they won't have forgotten which email and password they gave during registration.
Of course, if the operations they're trying to perform in your site are sensitive enough (e.g. purchase, sale), you should let them know that it requires an immediate confirmation of the email address.
Other unrelated advices:
- if you use the email as a login name, then allow users to have whatever handle they'd like. i.e. don't make the username unique. Also, allow spaces in that field. e.g. StackExchange.
- under no circumstance should you keep an unencrypted record of the password. It's tempting to think that in the name of user friendliness, whenever someone loses their password, you will just send it back to them. As soon as I see my password sent to me in an email, I usually logon to the website, change the password to 12345 and depending of the sensitivity of the data kept by the service (e.g. web hosting), I would consider stopping using it altogether (Ironically, I've had cases of websites telling me that 12345 as a password isn't secure enough for their service, after they'd sent me my password via email).
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 better approach, in my opinion, would be to let users just start interacting with your service right away. Give them 5 to 7 days to confirm their account, after which it is automatically suspended. You can let them know the next time they try to login that they never actually clicked the link they received via email a week earlier. The timeframe is long enough that they can actually use the service with no hassle and it's short enough that they won't have forgotten which email and password they gave during registration.
Of course, if the operations they're trying to perform in your site are sensitive enough (e.g. purchase, sale), you should let them know that it requires an immediate confirmation of the email address.
Other unrelated advices:
- if you use the email as a login name, then allow users to have whatever handle they'd like. i.e. don't make the username unique. Also, allow spaces in that field. e.g. StackExchange.
- under no circumstance should you keep an unencrypted record of the password. It's tempting to think that in the name of user friendliness, whenever someone loses their password, you will just send it back to them. As soon as I see my password sent to me in an email, I usually logon to the website, change the password to 12345 and depending of the sensitivity of the data kept by the service (e.g. web hosting), I would consider stopping using it altogether (Ironically, I've had cases of websites telling me that 12345 as a password isn't secure enough for their service, after they'd sent me my password via email).
I completely agree with delayed confirmations. On the service we're building right now, we're also letting users get started using the site without signing up at all to begin with. Then, if they want to save their data, they'll need to create an account.
On a desktop app, you don't have to enter a filename until you're ready to save...why should you have to do that on the web? (of course, this isn't useful in cases where data is sensitive)
On a desktop app, you don't have to enter a filename until you're ready to save...why should you have to do that on the web? (of course, this isn't useful in cases where data is sensitive)
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.
But I agree that new users having to leave the site to check their e-mail is a hurdle to get over.
Its also worth it to decide if you need user email addresses at all, chances are you don't. For most services the only function of having the email address is to spam the user. Yes, there are password resets but you don't have to force it on them, let the user decide if they want to make that fallback available to them.
For better or worse, email has become the primary way of authenticating identity, with Facebook and Google Id in second and third. Password resets are vital if your service is non-trivial, and I consider having some form of it to be absolutely necessary.
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 and email address from the OAuth information and autopopulate your user profile.
At this point we don't strictly need any more information, and adding more account providers doesn't increase the number of steps. Actually, when we only supported Google accounts we didn't have a step #2.
We may start asking people some more questions, but for now signing up and logging in virtually identical user experiences.
1. Click login
2. Choose account provider
3. Grant us authorization access
4. Done - we pull your name and email address from the OAuth information and autopopulate your user profile.
At this point we don't strictly need any more information, and adding more account providers doesn't increase the number of steps. Actually, when we only supported Google accounts we didn't have a step #2.
We may start asking people some more questions, but for now signing up and logging in virtually identical user experiences.
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 definitely something giving us some heartburn thinking about. We're going to try and avoid it unless we get lots of customer contacts (and our development schedule is empty), since we're probably going to have to come up with a solution that links accounts at some point.
But, at the moment since we support only two providers, and those providers tend to be pretty divisive with little overlap, we haven't noticed any real problems yet.
But, at the moment since we support only two providers, and those providers tend to be pretty divisive with little overlap, we haven't noticed any real problems yet.
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.
No idea what the solution to this problem is, but I suspect it isn't going away.
I have an idea, but I'm not sure if it would be a security risk.
Let the user pick a username to go with the ID provider. When you fill in the username, it'll look up (AJAX) which provider was used and offer/highlight that one?
The question is, is it a security risk if anyone can type in any username to find out which ID provider it is used with?
Let the user pick a username to go with the ID provider. When you fill in the username, it'll look up (AJAX) which provider was used and offer/highlight that one?
The question is, is it a security risk if anyone can type in any username to find out which ID provider it is used with?
That's the kind of sign up I really like. I hate having to make up yet another damn password, then record it somewhere because I know I'll forget it, etc. I much prefer to use just authorize you through Google Sign-in, FaceBook Connect, etc.
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.
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.
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.
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.
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.
And expiring after 10/30/60 days if not used. No reason to keep these useless records in the DB rotting away.
I consider this huge. Aside from the obvious man-in-the-middle network attacks that could capture this easily, it also creates a huge physical security flaw: if you save/archive your emails, I can sit down at your machine, type "password" in the search box of your mail client, and trivially steal a dozen or so of your passwords. If these weren't auto-generated, it's even worse, as most people re-use passwords.
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.
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?
> If someone has access to your email client you're hooped anyway.
I once made the mistake of emailing a friend of mine the password to an ssh account — roughly 6 months later someone logged in with that password and added a spammy link to one of my HTML pages — my friends machine wasn’t hacked, but likely the (university) server storing his email had.
Also, our online shop email the buyers from a generated non-guessable address (to track replies/bounces). Occasionally these receive spam.
So I don’t trust that what I write in an email is only seen by the person it is sent to, unless the content is encrypted.
And just for the records, I disabled password login and installed fail2ban long ago to avoid new server break-ins :)
I once made the mistake of emailing a friend of mine the password to an ssh account — roughly 6 months later someone logged in with that password and added a spammy link to one of my HTML pages — my friends machine wasn’t hacked, but likely the (university) server storing his email had.
Also, our online shop email the buyers from a generated non-guessable address (to track replies/bounces). Occasionally these receive spam.
So I don’t trust that what I write in an email is only seen by the person it is sent to, unless the content is encrypted.
And just for the records, I disabled password login and installed fail2ban long ago to avoid new server break-ins :)
Considering the "forgot password" fallback for virtually every site is your email address, and you can't disable it, most websites are only as secure as your email security.
better to send a single-use capability URL.
> 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 human users, but not bots
Apparently those of us that are blind, browse from the terminal, or use automated form-fillers are bots and not users too?
Some of this advice is good, some of it is very obvious and widely implemented, and some of it is bad. As the author has left determining which are which as an exercise to the reader, I'm not sure they know either.
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 human users, but not bots
Apparently those of us that are blind, browse from the terminal, or use automated form-fillers are bots and not users too?
Some of this advice is good, some of it is very obvious and widely implemented, and some of it is bad. As the author has left determining which are which as an exercise to the reader, I'm not sure they know either.
>> "So now only users with Javascript enabled can use your website."
It's easy to measure what percentage of your users have JavaScript disabled. For a consumer website, it's probably measured in the hundredths of a percent.
If you can make a change that increases the conversion for 99.97% of your users, even at the cost of ZEROING the conversion for 0.03% of your users, then you will still come out ahead.
It's easy to measure what percentage of your users have JavaScript disabled. For a consumer website, it's probably measured in the hundredths of a percent.
If you can make a change that increases the conversion for 99.97% of your users, even at the cost of ZEROING the conversion for 0.03% of your users, then you will still come out ahead.
I would be very, very curious to see hard numbers on this.
Also, it's trivial enough to add a <noscript> tag advising users to turn on Javascript (with a friendly "here's how" link), or you can do the work to degrade gracefully. Your conversion might drop for such users, but there's no reason it should go to zero.
Also, it's trivial enough to add a <noscript> tag advising users to turn on Javascript (with a friendly "here's how" link), or you can do the work to degrade gracefully. Your conversion might drop for such users, but there's no reason it should go to zero.
Or you could add the Captcha in this case.
In which case, are most captchas going to screw blind people anyway?
reCaptcha has highly-accessible captchas, including audio versions.
Have you ever tried entering an audio captcha?
Can't say I have. Is it not as one might imagine?
It's difficult to describe. Go sign up for a new Google account [1] and click the wheelchair symbol to activate the audio captcha.
[1]: https://www.google.com/accounts/NewAccount
[1]: https://www.google.com/accounts/NewAccount
On the off chance someone reads this, I'll try to describe it: over the top of random, unintelligible babbling, a voice reads alphanumeric characters. Parts of it are about as difficult to understand as some captchas are to read recently.
I checked this last week for a site I maintain, 10% of the visitors were still using IE6, and 15% of the visitors had Javascript turned off. I guess that's because that site is aimed at a certain business audience.
Another site I maintain shows numbers like 3% IE6 and 1% non-JS. What a difference!
Of course, for the first site I mentioned, we made it sure the site graciously degrades for non-JS and/or IE6 users. We don't want to lose 15% of our customers.
Another site I maintain shows numbers like 3% IE6 and 1% non-JS. What a difference!
Of course, for the first site I mentioned, we made it sure the site graciously degrades for non-JS and/or IE6 users. We don't want to lose 15% of our customers.
Apparently some hyper-paranoid corporate firewalls block JavaScript... that probably accounts for the oddly-high percentage of no-JS business users you're seeing.
Is not having JavaScript really a problem?
I never even consider it anymore.
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.
I'm surprised they didn't mention what I consider the greatest cardinal sin of sign-ups: if you're not validating email addresses, start the user's session as soon as they register, instead of making them re-enter the same info again into a login box. (Even if you're sending a validation email, you could allow the user to postpone validating, or at the very least, log them in automatically upon clicking the link in their email.)
This is a big one. I threw out the "click the activation link email" process a long time ago, I now just set the session and push the new user straight into the panel.
At least I am very likely to overlook a typo, but less so to make the same typo twice.
Why not make a check box "same as billing address"? That way if people make a mistake they only have to correct it once.
And how many people will click on that preview ?
sure
If I saw this I really would have no idea what the checkbox "check password" does.
Never had problems with being insecure which action I was about to take when I logged into facebook.
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.