Innovative Techniques To Simplify Sign-Ups and Log-Ins

Advertisement

There are many ways to design sign-up and log-in forms. Most designers are familiar with the conventional ways. But understanding and applying a few innovative techniques could make your forms simpler and more efficient to fill out. In this article, we’d like to present a couple of new ideas that might be useful for your next designs. Please notice that before using these techniques, you should make sure that they make sense in the context in which you are going to use them. We’d love to hear about your case-studies and usability tests that affirm or dismiss the suggestions proposed below.

Simplifying Sign-Ups

The purpose of every sign-up form is for users to complete it successfully and send it in. However, if the form is long and complicated, then the user’s excitement for your website could turn to displeasure. Here are a few innovative techniques that will make your forms faster and easier to fill out.

Ask for a User Name After The User Has Signed Up

Sign-up forms typically ask users to create a name that is unique to the website. However, coming up with a unique user name that’s not taken could take trial and error and, thus, time. Instead of hassling people for a user name when they sign up, you might want to consider asking afterwards. This way, you won’t lose sign-ups from frustrated users, and you’ll prevent users from creating random and forgettable names just to satisfy the form’s requirements.

1

Require Users to Type Their Password Only Once

Many sign-up forms ask users to type their password in two different fields. The reason is understandable. Forms mask passwords for security reasons, so that snoopers can’t see them. And to cut down on typographical mistakes and increase the chances of correct input, two separate entries are required.

In reality, though, this allows for greater error, because it forces users to type more. They can’t see the characters they’re inputting, making it difficult to know whether they’re typing the right password each time.

2

A more efficient approach would be to ask users to type their password in once, but then include a box they can check to unmask the password, so that they can check it. This option could reduce the number of text fields and decrease the work that users have to do to sign up.

Auto-Fill City and State Fields Based on User’s ZIP Code

If you require the user’s home address, then consider auto-filling the city and state fields based on the ZIP code. The form will be faster to fill out because users won’t have to waste time and energy manually selecting their city and state from drop-down lists.

5

Auto-Complete the Country Field

The conventional way for users to specify their country is to select it from a drop-down list. A more efficient way would be to use an auto-complete text field. Instead of making users scroll through an alphabetical list of every country in the world, the text field would allow users to select their country from a small subset of countries that match the letters they type. The user needs only to type a few letters to see their country in the menu.

7

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

If a user is buying a product, they’ll have to submit payment and shipping information. Most of the time, the addresses will be the same, so let them auto-fill one from the other. You could include a link saying “Same as shipping information” in the payment section, and when clicked, it would repeat the shipping data in the payment fields.

10

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

Most website owners pre-check the newsletter box, hoping to get more subscribers. Chances are, it will work. But a subscription is meaningless if the user has done so only because they have overlooked or misunderstood the option. If they’re not interested, they’ll unsubscribe sooner or later. Forcing them to subscribe won’t help you in the long run. And receiving a newsletter without having explicitly asked for it can turn users off.

A more effective approach would be to make users want to subscribe by showing them a preview or excerpt of the newsletter. This way, they’ll know what they’re missing if they don’t subscribe. You’ll also sleep well knowing that users who subscribe have done so because they’re genuinely interested in your content.

11

Combat Spam by Hiding a Text Field With JavaScript, Instead of Using CAPTCHA

If you get a lot of spam, then putting a CAPTCHA on your form may be necessary. What’s not necessary is making the CAPTCHA an obstacle that turns users away. Traditional CAPTCHAs that ask users to retype distorted letters have been proven to hurt conversion rates. With the extra hassle they force on users, it’s no wonder.

A simpler approach that won’t lower your conversion rate is to use a hidden and required text field generated with client-side Javascript. Spambots can’t fill in the field because they can’t interact with objects in client-side JavaScript; only users can. This method is simpler and less intrusive and so will reduce spam without hurting your conversion rate. The only problem is that it relies on JavaScript to work which might be suboptimal in some cases. You could also use Honeypot Captcha approach14: 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. If it isn’t, then you can safely ignore the submission because it was submitted by a spam bot.

15

Simplifying Log-Ins

The purpose of every log-in form is to get the user into their account. Some log-in forms do this better than others. Here are a few innovative techniques that will help your users log in more efficiently.

Allow Users to Log in With Their Email Address

Remembering an email address is easier than remembering a user name. User names can be unwieldy, and people remember their email address because they use email all the time. Give users the option to log in with their email address as well as a user name. The flexibility could save them the time and headache of recovering the user name if they forget it.

16

Log Users in Without Leaving the Page

Logging in is a common task, and users will want to be able to log in from anywhere on your website. So, as soon as they do it, redirect them back to the current page. This will make logging in faster and allow users to get right back to their task.

There are a couple of ways to make this happen: a drop-down box or a modal window.

The drop-down box will open without taking users off the page. It takes up only a small part of the page, making it a fast and lightweight option.

19

A modal window also keeps users on the current page, but it opens up at the center of the window, putting the focus entirely on the log-in form. This option gives you room to add supplemental information to the form.

22

Auto-Focus the First Text Field

Once the user sees the log-in form, they’ll be ready to log in. Make the process more efficient by automatically focusing on the first field. This saves them the time and effort of hovering and clicking. The user can keep their hands on the keyboard and start typing away. The auto-focus should also clearly highlight the text field so that the user knows they can start typing.

23

Allow Users to Unmask Their Password

This option is almost as useful for logging in as it is for signing up. If users can’t see the characters in the field, they could easily mistype the password. If their input is rejected, they’ll know that they mistyped something and will have to re-enter their password until they get it right.

The problem is that users don’t know which character was mistyped and so can’t fix the mistake before submitting the form on the first attempt. This creates more work than necessary and makes users slow down their typing. Avoid this by adding a checkbox that allows users to unmask their password before submitting it.

25

Use a Question Mark Icon for the Password Recovery Link

Users should have no trouble finding the password recovery link on your form. Instead of using a “Forgot your password” link, consider using a simple question mark button, which won’t take up a lot of room or get lost among other links. Because the question mark is a universal symbol for help, users will not wonder where to go when they’re having password trouble.

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

The log-in button isn’t just for taking action: it also lets users know what action they’re about to take. A small log-in button has weak affordance and can make users feel uncertain about logging in.

A wide button gives users more confidence and is hard to miss. The button’s label also becomes more visible, so that users are clearer about the action they’re taking.

26

Allow Users to Log in Via Facebook, Twitter or OpenID

Nearly everyone has a Facebook, Twitter or OpenID account, and letting them log in with it brings big benefits. They can use your website almost instantly, without having to go through the sign-up process. Also, they won’t have to manage multiple user names and passwords across different websites.

27

Of course, you could even go further and use Facebook Connect to actually prefill data that your users might have to type; in the example below, on Friend.ly28, a Facebook application, the only thing that the user needs to do before starting using the service is just click on the “Register” button. The information about the user is loaded automatically which raises a huge privacy concern. You might not want to use this approach in practice.

Screenshot29

Conclusion

Your sign-up and log-in forms shouldn’t make the user’s life difficult. Spending time filling out a form is no one’s idea of a party. These innovative techniques will make your forms simple and efficient, so that users can sign up and log in quickly and start enjoying your content. For further ideas and examples, you might want to consider taking a look at Joshua Johnson’s article 20 Great Sign Up Form Examples to Learn From30.
(vf) (ik) (al)

Footnotes

  1. 1 http://www.smashingmagazine.com/wp-content/uploads/2011/03/usernameafter.png
  2. 2 http://www.smashingmagazine.com/wp-content/uploads/2011/03/signup2.png
  3. 3 http://www.prothemer.com/blog/research-and-development/new-jquery-plugin-targeting-usability-for-password-masking-on-forms/
  4. 4 http://forumsblogswikis.com/2007/08/15/using-ajax-to-get-city-and-state-from-zip-code/
  5. 5 http://www.smashingmagazine.com/wp-content/uploads/2011/03/signup3.png
  6. 6 http://www.devbridge.com/projects/autocomplete/jquery/
  7. 7 http://www.smashingmagazine.com/wp-content/uploads/2011/03/signup4.png
  8. 8 http://www.encaffeinated.com/articles/view/copying_billing_and_shipping_address_information_with_jquery/
  9. 9 http://jivstudio.com/2009/02/05/copy-form-input-data-to-another-input-field-with-jquery/
  10. 10 http://www.smashingmagazine.com/wp-content/uploads/2011/03/signup5.png
  11. 11 http://www.smashingmagazine.com/wp-content/uploads/2011/03/simplify6.png
  12. 12 http://www.seomoz.org/blog/captchas-affect-on-conversion-rates
  13. 13 http://www.90percentofeverything.com/2011/03/25/fk-captcha/
  14. 14 http://haacked.com/archive/2007/09/11/honeypot-captcha.aspx
  15. 15 http://www.smashingmagazine.com/wp-content/uploads/2011/04/javascript-captcha.png
  16. 16 http://www.smashingmagazine.com/wp-content/uploads/2011/03/email_login.png
  17. 17 http://thefinishedbox.com/freebies/scripts/jquery-dropdown-login/
  18. 18 http://www.jqeasy.com/jquery-drop-down-ajax-sign-in-form/
  19. 19 http://www.wsj.com
  20. 20 http://www.bitrepository.com/ajax-login-modal-box.html
  21. 21 http://www.queness.com/post/77/simple-jquery-modal-window-tutorial
  22. 22 http://www.cnn.com
  23. 23 http://www.smashingmagazine.com/wp-content/uploads/2011/03/Picture-1.png
  24. 24 http://www.useit.com/alertbox/passwords.html
  25. 25 http://www.smashingmagazine.com/wp-content/uploads/2011/03/login4.png
  26. 26 http://www.smashingmagazine.com/wp-content/uploads/2011/03/account_login.png
  27. 27 http://www.smashingmagazine.com/wp-content/uploads/2011/03/social_logins.png
  28. 28 http://www.friend.ly/
  29. 29 http://www.friend.ly/
  30. 30 http://designshack.co.uk/articles/inspiration/20-great-sign-up-form-examples-to-learn-from

↑ Back to topShare on Twitter

Creator of UX Movement, a treasure trove of user experience design articles he wrote. Creator of Interface Libraries, a professional wireframing toolkit, Interface Styles, a visual interface tool and Productivity Papers, a system for reaching your goals and becoming an expert.

Advertising
  1. 1

    Thank you, this was some very useful information!

    5
  2. 2

    Nice read ;) Thx for sharing!

    1
  3. 3

    Excellent article. Also adding to this, account activation via email is also one more thing which affects users interest on the website

    The hassle of going thru email and switching back to website has often let me ignore many websites.

    2
    • 4

      But if you don’t send an activation e-mail with the goal to validate the e-mail address how do you know the e-mail address is valid?

      6
      • 5

        In many cases it’s not important to know if the e-mail address actually exists. It may prevent some spam and unmotivated users because you’re adding s small hurdle.

        As a user, I hate having to confirm my e-mail address. It’s even worse when an activation e-mail doesn’t immediately arrive because some mail server is slow.

        3
        • 6

          The activation mail is a good thing not only to filter out bad email addresses but more importantly to make people use their OWN address. Otherwise they could just login with someone elses and that person would not be the wiser.

          9
          • 7

            As a user, I love to get my confirmation emails…and I somehow feel uneasy, if I don’t get any.
            IMO, that’s a huge step towards trust between a site and users.

            5
  4. 8

    cancel bubble

    May 5, 2011 6:14 am

    “Use a Question Mark Icon for the Password Recovery Link…Because the question mark is a universal symbol for help, users will not wonder where to go when they’re having password trouble.”

    I disagree with this (a ? icon alone). We’ve done pretty extensive user testing where I work with many different people (I’m talking a wide range from the general public in different cities) and most just don’t get ? icons. It actually constantly amazes me what most people just don’t get and I’m often left wondering how the hell they even use the web.

    You are far better off, IMO, using the traditional text link, i.e., exposing what’s behind the ? icon.

    If you combine the ? icon with text, that’s different because people aren’t left wondering.

    “Allow Users to Unmask Their Password”

    I’ve so far, only implemented this once for a Cisco project back in ’08 – and it was by their request. I’ve tried on other projects but it is a tough sell, IMO.

    The bigger problem with this I see is if someone enters a typo in their password and doesn’t unmask it to check it’s spelled correctly. Then they’ve registered with a misspelled password.

    Another option, and granted I can’t say this is very good, either, is to have the password revealed in plain text as the user enters it and when they blur the field, it changes to a password field? So when it’s focused it’s a plain text field, when not focused it’s ********

    28
    • 9

      The question mark icon was the only thing that left me wondering as well. To me that doesn’t make any sense and I think if someone needs a reminder of their password, make it very clear – I’ve left sites where I’ve been unable to remember an old password and it’s not been made easy to request a new one and I’m sure I’m not alone there.

      Otherwise a very enjoyable and informative article with some good tips :)

      J.

      5
      • 10

        Jennifer Fleming

        May 5, 2011 12:27 pm

        I agree, why would a small icon be more desirable than a readable blue link right near the form field that says “Forgot Password?”

        Also, the Check Password seems misleading. It sounds like it will check the validity of the entered password.

        3
        • 11

          Agreed — I’d phrase it “display password”, or perhaps “hide password” and check it by default.

          3
          • 12

            I think ‘check password’ is very task driven. It gives users a reason to do so. If its rephrased to ‘display password’ or ‘show password’, people may not see a reason to do that.

            Just a note, a way round the confirm e-mail field is to have the call to action at the bottom of the page to say ‘Confirm with rico@ricochow.com‘. I haven’t user tested this but it seems like a good way to make sure they check the e-mail before they submit. I guess it wouldn’t work the same way with passwords though…

            0
      • 13

        Koen Hachmang

        May 9, 2011 4:24 am

        Yes, I agree. I believe the main issue with this, is the context of the question mark. When placed behind text, people will read it as “what is this?” and expect an explanation of the term (password in this case)

        6
      • 15

        I totally agree.

        -1
    • 16

      You make some interesting points. Instead of your second option where the password is revealed then changed on blur, why not go the mobile route? Have the latest letter you enter revealed and all previous ones masked. That, coupled with the unmask checkbox could definitely work IMO.

      5
      • 17

        you're not thinking like a user

        May 5, 2011 7:24 pm

        You’re not thinking like the normal user who is going to look at the keyboard while typing in their password, defeating the purpose of the latest letter being revealed. It’s a good idea, just not necessarily useful for the majority of users.

        4
        • 18

          Ah, that’s a good point. I suppose it’s in our best interest to keep the end user in mind while designing ;)

          0
          • 19

            I don’t see the point of masking passwords in the first place. I’ve always hated it, as a user.

            It seems to assume there is somebody looking over the user’s shoulder, somebody sinister. Does it protect the user from spyware or something?

            If not, then I’d ditch it – or maybe I would ditch it anyway as users’ computers should be protected from spyware and users should, IMO, be treated like adults if they’re not.

            Or – offer ‘Mask your password’ as an option, rather than *unmask*!

            1
    • 20

      I agree with you comment about the question mark icon. While it’s visually more pleasing. I think this would affect usability. I agree, we (as web experts) would easily understand this icon, however many people aren’t as tech savvy and really need things spelled out for them. An icon (as a visual cue) and a forgot password text link seems like it would be the most usable option for all audiences.

      1
    • 21

      I agree with the “?” issue. But I don’t agree with the “password” issue. I think we should focus on the normal users. They will look on the keyboard while typing their password in the password field. Typing experts are good enough to type what they want without a mistake.

      Regards,
      Ramzy

      0
    • 22

      Masking the password is preferred upon logins ’cause there is more chance someone is watching over your shoulder.
      But when registering I would consider to show the plain text by default. The option to show the password textfield would be checked and could be unchecked if user wants it.

      In general, I believe email registration is the way to go.
      With email validation, you can let the user register with only requesting an email. Upon validation, the user is asked to fill in an username and password.

      For completeness you can send an ‘account details’ email to the user for reference.

      0
    • 23

      Well for password we can show actual character for few seconds and then convert that in to “*”. If we do this user will know what he/she has entered.

      0
    • 24

      We only use a single password entry field during registration for most of the apps we’ve designed lately and haven’t found any issues with it. In fact, since the password recovery link is right at the bottom of the sign in form, that handles the case were a user mistypes their password.

      So, we’re making a more elegant signup process for everyone and giving the less than 1% who mistype their password an easy way to fix it. It’s a much better approach.

      0
    • 25

      IMO, the main thing is verifying the accuracy of the password:

      - Removing the retype of the password assumes that all your keypress are correct. But its not foolproof, what if you have a failing keypress. Not all have the same keypress sensitivity.

      - Show password check box may not enforce true correctness for verification. What if the letters used are closely similar like the letter i, l or 1. Not all have 20/20 vision. And its seems awkward to show the password in big sizes just to verify them.

      Re-typing allows the user to:
      - test if the new chosen letters/symbols are correct.
      - verify their confidence that their entered password is correct

      Maybe, a combination of both is good: re-typing and optional show password for double checking.

      What is more important: Accuracy or convenience ?

      0
  5. 26

    Pretty good article, except the check-box that says “Check Password” is meaningless to me.

    Maybe it’d be better to call it “Unmask Password” or “Show me what I typed in the password field” or something a little more clear.

    The issue with a box to “Check Password” is that it seems to imply that the SERVICE or WEBPAGE will check the password, not the user. (Like you are instructing the system to check or verify the password). Check boxes are usually instructions from the user to the system. For example, on this same page, you have a check box that says “Remember Me”. Surely this is not an instruction to the user saying to remember himself!

    You also have a check box to Subscribe, and link to a site that talks about a check box to Copy Shipping Address to Billing Address. These, also, are instructions to the system, not to the user.

    8
    • 27

      I think you’re right. “Show Password” is a lot clearer. I was subliminally influenced by the checkbox and checkmark in the graphic and went check crazy.

      -1
    • 28

      I understand that it is a good idea to let the user verify his password, but making it visible is in my opinion a very bad idea. There is a reason why passwords are hidden, if you don’t care about your users security you can add this functionality but else its probably a very bad idea.

      -2
      • 29

        The only reason this is done is to thwart someone from snagging your password while they watch over your should while you register. How often does that really happen?

        Since it’s a user controlled action, it’s really not an issue. Additionally, the model used in iOS, which shows a letter and then masks it as subsequent letters are typed, or based on a timeout function is very effective and still secure enough.

        0
      • 30

        The only reason this is done is to thwart someone from snagging your password while they watch over your should while you register. How often does that really happen?

        Since it’s a user controlled action, it’s really not an issue. Additionally, the model used in iOS, which shows a letter and then masks it as subsequent letters are typed, or based on a timeout function is very effective and still secure enough.

        2
    • 31

      “Reveal Password” ?

      -1
    • 32

      Yes, I totally agree. It’s too ambiguous.

      0
    • 33

      I’d go with “Review Password”

      0
  6. 34

    Just a fair warning to a situation thank I dont think has been addressed yet:

    Facebook instant logins or “connects” can be a little dangerous. For instance, I was logged into a Facebook Page account for my work, and then tried to register with MacWorld.com via the Facebook Connect option. I think that because I was an account as a Page, and not a User, it ended up looping me into this weird 404 error, that would automatically pop up even when I tried to revisit the homepage, logout, or re-sign in with a different account.

    I had to clear my cache in order to fix the issue, however, I also had to be completed logged out of Facebook as well, or else it would automatically try to reconnect again.

    It was a pain. Other than issues like that, I typically enjoy not having to create tons of new accounts with websites now, if I can simply login via Facebook.

    Just my two cents. :D

    0
    • 35

      The one problem I’ve run into as more and more sites support “sign in as” using FB, Twitter, OpenID, etc.., is that I lose track of what I used to register. I have all of these accounts, sometimes more than one (for work vs. personal), so for stackoverflow (for example) I went a few months unable to sign in because I couldn’t remember which of the dozen or so options was the one I picked originally.

      It’s no longer a question of knowing the email address you would have used — now I also have to remember what login service, and which account with that service.

      Since the poor experience with stackoverflow I’ve simply been avoiding these options entirely, and sometimes avoiding webapps that don’t have the standard email/password option.

      5
      • 36

        Rob,

        You make a good point. I have only been part of a few websites that have required Facebook login, and so far it hasn’t been to confusing, but I can understand that after continued use, it could get a little overwhelming to remember all of the details! I understand what you mean when you say you can’t remember which account you may have used; I have a similar issue with email. I have a personal email (one from back in highschool, with a username I don’t personally like anymore, but has the bulk of my accounts associated with it), one for freelance work, and one for my job. It gets annoying! I’ve had to create a Google doc just to store basic login information for all of these accounts.

        Typically I use the Facebook login for websites that I may never, or may hardly ever visit again. For instance, if I wanted to grab a coupon for an event I may be going to, I would use a Facebook login, and then probably forget about it afterwards.

        Sometimes I just wish my google account would do EVERYTHING. But on the other hand, that could be dangerous if it got into the wrong hands…

        0
  7. 37

    “Auto-Focus the First Text Field”
    Only if you want to annoy keyboard users like me. We need to be able to choose focus for ourselves in a logical order; not in the order that a designer thinks is right.

    “Combat Spam by Hiding a Text Field With JavaScript”
    It’s excellent that you should support the avoidance of the hell that is squiggly symbols, but why this? If you want a human to use it, why hide it? Secondly, if you rely on JS to sort humans from bots, I might be picked out as a bot just because I have to use a text browser. Thanks.

    Remember that every form must degrade to a basically functional state if JS is not supported.

    “Use a Question Mark Icon for the Password Recovery Link”
    If I was able to see such a symbol in my browser, I would not expect it to be a link. What is wrong with anchor text?

    “Ask for a User Name After The User Has Signed Up”
    Excellent suggestion.

    “Auto-Fill City and State Fields Based on User’s ZIP Code”
    That would be OK if it ever worked, but I know folk who would happily tell you that it never works for them.

    By the way: I had to copy/paste this comment because your textarea is virtually unusable: its HTML column value is set at 0, which is just plain dumb.

    -1
    • 38

      If you’re using a text browser, you’re an edge case and probably used to subpar experiences anyway. Design for the 80%.

      The scenario that someone is coming to your site w/JavaScript turned off is also an edge case. Critical features should work w/o JavaScript, but realistically, it’s perfectly okay to design expecting JavaScript to work. That’s the real world, not some theoretical lab setting, or edge case design.

      Design for reality, not edge cases.

      4
  8. 39

    Egg Zuh Lend!

    I hope a lot of designers and developers read this article and have that lightbulb moment finally and implement signing up and logging in the way it should be.

    -1
  9. 40

    “Combat Spam by Hiding a Text Field With JavaScript”. Great article but hiding a text field with JavaScript will not combat spam at all… the spammer will still be able to access the URL where the request is being made, giving him open access to spamming capabilities.

    1
  10. 41

    Fantastic post on some really great techniques! I’ll definitely be using this soon. Thank you.

    0
  11. 42

    oAuth is the way forward. 5 second sign-up and it would stop people from being able to passwords too! I just with that facebook, twitter, etc. would become OpenID consumers as well as providers.

    Note lastpass today http://blog.lastpass.com/2011/05/lastpass-security-notification.html

    2
  12. 43

    We have been using the Facebook registation for a few months, one big plus is that you can ask for extra data. You don’t get complete access to the persons information, just there name and e-mail adress. Anything else requires the user to request further permissions from facebook.

    You can see it in action here.. http://www.rightrental.com and an overview of it on slideshare. http://www.slideshare.net/rightrental/the-facebook-experience

    -4
  13. 44

    Thanks for sharing!
    Just wondering “…in Via Facebook, Twitter or OpenID….Nearly everyone has a Facebook, Twitter or OpenID account…”

    But the social login graphic that shows below does not follow the order but rather Twitter, Facebook, OpenID. Regardless its clear enough.

    Thanks

    -1
  14. 46

    @Luca Yes it will. Most Spambots fill out all fields of a form with their gibberish. So if a field that is not visible to the visitor (either hidden by CSS or JS) contains any data, you can almost certainly throw that submit away. (because only bots – not humans) see the field.

    @Smashers nice read! bookmarked.

    -1
    • 47

      Personally I really don’t like the hiding box by JS idea and that’s simply because you CANNOT assume that just because it has data a spammer did it.

      I know I filled out a form once and used Google Chrome’s autofill feature, tried submitting and the site kicked me out with a message that their system detected I was a bot. I went back in and hand-typed everything and it worked fine… I’m sure the autofill filled in the spam-catcher box. If I didn’t have any idea what was happening (ie: if I wasn’t aware of this Captcha alternative) I wouldn’t have had any idea how to fix it and probably would have left.

      4
      • 48

        Good point. I think to make use of that technique one needs to completely understand these annoying pre-filling mechanisms (are they based on field names? then that’s not too hard to fix using some generate-id() mehod. or do they simply fill previous selections, than that can be fixed the same way). Actually, the proposed technique in the above article is a bit different that what I assumed it to be (without properly reading the article). A required field that simply doesn’t exist in the non-JS version.

        0
        • 49

          Hi Erik,

          A field that only gets added by JavaScript… I know some users with accessibility needs who don’t have JavaScript enabled. What will happen to them? I hope they won’t get detected as spam-bots!

          Steve

          2
          • 50

            Right, both of those suggestions to avoid captchas are seriously flawed, particularly if you assume that failing the test means you have a bot (and you can ignore the submission).

            For one thing, it’s trivial for a bot to work around if it is targeting your site specifically — it takes two minutes for a human being to check what a real request looks like (including the JavaScript secret field, or with the honeypot field empty…), and tweak the bot based on that.

            Second, there will be a not-insignificant percentage of your users that will be caught — some people have JavaScript off intentionally, some corporate firewalls strip out scripts, some have older mobile devices with poor or no JavaScript implementations. The honeypot fields will be filled out by auto-form fillers… I have a honeypot field that worked perfectly for many years, then Chrome went up a version and started filling in the botsOnly field with email addresses.

            Fortunately, if the honeypot trap is tripped, I give the user’s other options to prove they are real… do not ever put in this kind of check and simply discard the request (or give some other opaque response) to what you think is a bot! If it’s a user, they won’t be happy.

            2
  15. 51

    Entering the password once, without a mask (or with the option to remove the mask), compromises users security for usability. Users tend to reuse the same password (with the same username) in several sites, so with a sneak peak of the password you’ll make possible for a ill intentioned person to access every account.

    I can also see the upside of having to enter the password once – not having to rerun the registration if the user makes a mistake can increase conversion – but designers should take users security into account also.

    1
    • 52

      > Entering the password once, without a mask (or with the option to remove the mask), compromises users security for usability. Users tend to reuse the same password (with the same username) in several sites, so with a sneak peak of the password you’ll make possible for a ill intentioned person to access every account.

      Who do think is taking these ‘sneak peeks’? I think the assumption that users have miscreants looking over their shoulder all the time is crazy. It’s nought to do with security. It’s paranoia at best and patronising nonsense at worst. Usability trumps both:
      http://www.useit.com/alertbox/passwords.html

      I don’t see any point to masking passwords.

      0
    • 53

      How often is someone sitting over your shoulder snooping? Make it possible? Sure. Likely? Hardly.

      Security shouldn’t be ignored, but usability shouldn’t be abandoned for security.

      1
  16. 54

    This is great. Keeps these types of informative posts coming. We’re currently developing a new ecommerce store and the smashingmagazine articles are invaluable.

    0
  17. 55

    Something important I’ve noticed with the “Log in with Facebook, Twitter, Google, etc” sites is that a lot of websites absolutely miss the point. Major news outlets, for example, have the “Log in with…” buttons, but then when you try to use them, all you’ve done is ADD a step to the signup process to associate your Facebook/Twitter account with the new account they want you to create. It doesn’t shorten the signup process at all. Presumably it would change the login process from username/password to the signon model of whatever site you used, but that doesn’t help me any.

    Principle of Least Surprise applies here equally with limiting what’s required of the user. “Sign in with” should be exactly that, not a step to account creation.

    0
    • 56

      Totally agree. Also, I’ve found that by logging in with Facebook or Twitter these websites then have access to all your info and sometimes, quite annoyingly, end up auto-posting stuff to your feed.

      1
      • 57

        This is not possible, a website can’t post stuff on your facebook wall if you don’t approve. You have to give the website the right to do so. You can also remove those rights for any website in your facebook privacy policy settings.

        2
  18. 58

    interesting article.

    The only thing I really don’t like is the Login via external services like Facebook because your site login is service dependent.

    1
  19. 59

    “Ask for a User Name After The User Has Signed Up”
    This is actually a good suggestion, but what if the user has to enter username first to sign up? Just like when you sign up your first email account? So, in my advice, use this suggestion appropriately.

    “Require Users to Type Their Password Only Once”
    I think I kinda disagree with this. Hey, your friend could peek on you if you unmask the password… I think trying to make your users typing password twice helps the user thinks twice before confirming their password. By inputting the password twice, we make sure the user is inputting the password properly. Personally, I think typing password twice is actually a good design.

    “Use a Question Mark Icon for the Password Recovery Link”
    Err… I think they will click it because they were curious about it, not because they want to recover their password. You could add a tooltip when you hover the icon to explain to the users. But, personally i prefer displaying anchor text instead. It’s just simple, informative, and elegant.

    “Make the “Submit” Button as Wide as the Text Fields”
    This is good. I think everybody agrees…

    “Auto-Fill City and State Fields Based on User’s ZIP Code”
    I think most casual people prefer to use the dropdown instead having to remember undescriptive ZIPcode. But it is a good idea. Another approach is to use a searchable dropdown, or autocomplete text field.

    “Log Users in Without Leaving the Page”
    Yeah, this is great!

    “Auto-Focus the First Text Field”
    @Adam32
    Actually, I’m a keyboard user too…

    Anyway, i agree that your article is very innovative…
    Thank you for sharing…

    2
    • 60

      Hi Maul

      RE: “This is actually a good suggestion, but what if the user has to enter username first to sign up? Just like when you sign up your first email account? So, in my advice, use this suggestion appropriately.”

      Have you noticed though that if you try and register for a service and your selected user name is already taken, it kinda makes you give up – especially if you try a couple of variations and they aren’t available too. This means you could lose a lot of conversions. By moving the step to AFTER sign up, they are already joined and just need to choose a user name as a post-sign-up process. It does depend on the circumstances.

      Everything else you mention, especially the password stuff, I agree with!

      0
    • 61

      You could also do username == email address, and a person can choose any display name he/she likes.

      2
    • 62

      > …your friend could peek on you if you unmask the password…

      I think this fear is over-rated. How often do users have someone looking over their shoulder when they’re online, much less when they’re signing up to a site for the first time (not something most people do every *week*), being snooped on by some “friend” they can’t trust?

      If this is the only reason for the nearly ubiquitous practice of masking passwords, it’s all pain and no gain for site visitors.

      -2
      • 63

        I absolutely agree. Not so many people have such rude and dumb friends for masking and entering passwords twice to be justified. On the other hand, 99% of people who are typing passwords without idiot friends staring over their shoulders (including myself) find that solution to be totally counterintuitive.

        0
    • 64

      @maul “Require Users to Type Their Password Only Once… I think I kinda disagree with this. Hey, your friend could peek on you if you unmask the password… I think trying to make your users typing password twice helps the user thinks twice before confirming their password. By inputting the password twice, we make sure the user is inputting the password properly. Personally, I think typing password twice is actually a good design.”

      Then he’s probably not a very good friend. And if he’s sitting next to you, simply ask him to look away.

      A better model is to either show each letter, then mask it on a timeout, or next character is typed, or to have one password field and make it easy to reset by sending a reset link to the email address on account.

      1
  20. 65

    “Combat Spam by Hiding a Text Field With JavaScript, Instead of Using CAPTCHA”
    I understand CAPTCHA can be an obstacle but the solution you propose is less secure as a CAPTCHA.

    “Spambots can’t fill in the field because they can’t interact with objects in client-side JavaScript”.
    If spambots don’t have the capability to do this today, it is not technically challenging to add such feature.

    1
  21. 68

    I always preferred the idea of using email address as the username, there is no need to ask for both unless a user can have different profiles, which doesn’t make much sense for most cases.

    0
    • 69

      I have tried this, but it got confusing when people would change their email address and the username doesn’t change as well.

      0
  22. 71

    Don’t really agree with most of this, but the first thing that stands out is:

    Change:
    “Check Password”

    to:
    “Show Password”

    3
  23. 72

    Great article. Very clear and simplistic examples.

    -1
  24. 73

    It frightens me that you’re suggesting “Log Users in Without Leaving the Page” without also mentioning that the page from which you’re logging in users must be HTTPS. Even if you submit the form securely, the form itself can be changed and redirected in a man-in-the-middle attack, which allows the MITM to steal your users’ login credentials. There’s a good article on the Redfin Developer’s Blog (http://blog.redfin.com/devblog/category/security) which explains this in more detail. (I’m not associated with them in any way.)

    3
  25. 74

    A caution on auto-focusing on the first field, especially if its the ‘username’ field of a login.

    The client-side javascript will not run until the page has finished loading. If the page, for whatever reason, has any slowdown in loading (or running other javascript code) then it may be possible for the user to begin typing in the field while the page is still completing its rendering and client-side work.

    So, for example, the user may tab to the ‘password’ field and, while they’re typing, the page finishes loading and they suddenly find themselves in that first auto-focused field, typing their password into the wrong box.

    I’ve seen that behavior on major banking sites, and its always disconcerting.

    Only auto-focus if its a guaranteed quick-loading page. If anything on it has the potential for slow down, then I wouldn’t do it.

    4
    • 75

      “Only auto-focus if its a guaranteed quick-loading page.”
      Think of low spec computers or relative fast ones running some RAM intensive application, and this also applies (rendering the page, that is).

      It happens a lot with my low-spec PC running some video game or youtube 720p vids. The browser won’t be much responsive having f.e. your graphics card memory at it’s limit, and rendering the website takes some time which may result in the above statet issue.

      1
      • 76

        I’m glad someone brought this up – there are tons of techniques for auto-focussing “if they aren’t already typing”, so you can use it on any page as long as you bear in mind that you need to avoid hopping them back to the plain text field just as they start typing their secret password!

        -1
    • 77

      I think I’m right in saying that if you use jQuery with document.ready (not correct syntax) then the focus can kick in when the *document* has loaded rather than the images etc?

      So as soon as that closing comes over the wire you’re good to go.

      Correct me if that’s incorrect.

      1
      • 78

        That’s meant to say as soon as the closing /html comes over the wire. Use htmlentities Smashing Mag!

        1
  26. 79

    Hey, this is a great article, lots of valuable hints here. One thing I would like to add – when you allow Users to Log in via Facebook, Twitter or OpenID, make it as user-friendly as possible. There are many users out there that have no idea that they already have an OpenID account (e.g. Google, Yahoo, AOL can all act as an OpenID Identity Provider). For more details and a read-made implementation have a look at my blog post: http://doppnet.com/2011/03/a-decent-federated-login-implementation/

    5
  27. 80

    I defer with Zipcode. It’s always not possible to find exact “City” from a zipcode.

    2
  28. 81

    We haven’t launched yet ( so don’t have #’s on the success of our sign-in form) but have used some of the techniques mentioned in this article. The auto-focus the first text-field should be a given! The unmask password tip sounds very handy as well. I remember seeing this same technique in the Mac form to add a wireless password.

    I’d like to add two techniques:

    -use a simple message to direct the user on each input (“Enter your email.”, etc…)
    -Only show the inputs that are required at that time (Show email input only, than show the password input). This point makes a lot of sense for us since we’re not open to the public so we validate the email and show a diff set of forms if you’re not an existing user. If you’re not you’ll see an invite code input.

    We currently have a ‘Detect Location’ button which blocks the user from getting in based on if their city is unlocked. We’ll probably be moving that to after the user signs in since we don’t want any hick-ups and keep users locked out.

    Let us know your thoughts:

    http://www.weshouldbe.com/

    1
  29. 82

    Great article, learned a couple things. One importnat thing you forgot was to clarify the rules for the password upfront with the user. Min of 7 and a max of 25 characters and no symbols? Great, just tell me ahead of time. If I use a password string that doesn’t conform, I usually get a generic error message and it is very rare for a site to specifically spell out the PW rules.

    1
  30. 83

    this is an awesome post. Lots of good stuff that I never even thought about.

    1. Username after sign up – it is really hard to think of something!
    2. Don’t make the user type their password in twice
    3. Submit button as wide as the text field

    1
  31. 84

    Excellent article,
    I believe all your points are valid and I’m planning to implement them in my future sites.

    0
  32. 85

    I think the check option to remember password on log-ins is meaningless nowadays, since our browsers can do that anyway. Also please do not use captcha, It feels like solving the davinci code to sign up.

    3
  33. 86

    Philip Tellis

    May 5, 2011 1:17 pm

    Great article for the most part. Good advice. Others have commented on some of the problems I see (the question mark, JavaScript to combat spam, etc.). Another point I’d like to bring up is “Log Users in Without Leaving the Page”.

    Unfortunately, this trains users to get phished. What you really should be doing is training users to type their passwords into one and only one page, with a standard URL. For example, at Yahoo!, regardless of which part of the site you visit, if you need to login, you will be sent to https://login.yahoo.com/ and that page will have your sign-in seal on it. This way users are trained not to enter their password onto any other site.

    Sites that allow users to enter their passwords anywhere are essentially training their users that it’s okay to give your password to any page that asks for it. This is also true of third party sites that ask users for their Yahoo!/Google/Hotmail passwords so that they can get the user’s addressbook.

    5
    • 87

      If this can’t be done securely on a given site, then I agree it’s not good practice.

      But if you’re saying it’s every site designer’s and site owner’s job to “train users” to be safe and secure online, I think that’s patronising to users and total rubbish.

      0
  34. 88

    Using a drop down box or modal window to have users log in without leaving the page is a bad idea from a security perspective. On most websites, pages are delivered over an insecure (http) connection. But a website should protect the user’s password by submitting it over a secure (https) connection. Even though you can design a drop down / modal login form that does use a secure connection to submit the data, there are two problems with that approach:

    1) The user doesn’t know that the login form will be submitted over the secure connection. The way users should check for secure connections is to look for the presence of a lock icon and https in the location bar. If the page with the login form is delivered over http and the form is submitted over https, the lock and https won’t be present in the location bar until *after* the user has logged in. So a security-savvy user ought not enter their password in your drop down / modal login form.

    2) Since the login form is delivered over an insecure connection, it is susceptible to sophisticated man-in-the-middle attacks. Even though you as the website designer set the form action to “https://…”, a malicious proxy, router, or oanother wireless user could rewrite the form action so that it’s submitted to the attacker.

    While provided a login form on every page via a drop down box / modal login form makes logging in easier, it also makes it much less secure, and should be avoided unless every page is delivered over a secure connection (https).

    4
  35. 89

    Spammers sometimes use humans to sign up accounts initially and those invisible boxes are pretty well known.

    Rather than a one-size fits all approach of “use X technique”, I suggest you make your site use a *unique* approach and iterate until you get spam under control. That way, you’ll be safe until your site is worth targeting on an individual basis.

    Also, if you use a common software program that takes user input (forums, comments, etc.), I strongly suggest that you try to modify it enough so that it can’t easily be found by people searching for places to spam. They look for things like “mediawiki” or common links found in the default configuration of such programs.

    1
  36. 90

    I disagree with linking to the newsletter if the signup form is built into the checkout, which it quite often is these days. Once in the checkout you should probably not direct them elsewhere..

    0
  37. 91

    This, coming from a site that doesn’t use Disqus. Also,

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

    They can if they’re using well-written scrapers that emulate browsers and DOM.

    Also, I think the question mark thing for “forgot password” is non-obvious and lame. It’s premature optimization. Just put a small “forgot password” link below the password box because that’s what people are used to.

    1
    • 92

      Or don’t put one at all and offer the option if the login attempt fails.

      -1
      • 93

        No, that’s a bad idea. You should never give an indication why a login attempt failed – it should be impossible to tell whether it’s because the username is wrong, the password is wrong, or the DB server is down (ok, maybe that last one can be unique). From a security perspective, a brute force attacker should never be able to confirm they have a valid account (invalid password or no) without foreknowledge. Offering a forgot password for even invalid emails is just asking to confuse users.

        1
        • 94

          I used to believe in this philosophy too, that you shouldn’t tell the user why the login failed—whether due to unknown username or simply a bad password. However, I feel this is a moot concern and leads down a wrong path, since there is also a “I forgot my password” page which should (in my opinion) not hide such a reason.

          If I say I have forgotten my password, and I enter my email address, … I would like to be told “email not on file” which reveals the true failure reason. The only other result that could exist is “we have sent you your password reset email”, which means my email address is on file. If I truly think that I registered somewhere, and try to reset my password, I would like to be told this fact, rather than (worst-case) for the website to *pretend* that it sent me the reset email, even though my email was clearly not recognized. That would drive me nuts, waiting for an email that will never come.

          2
  38. 95

    Anthony,

    Great techniques! I think one about Newsletter preview is very valuable.

    What do you think about a user’s perceived security concerns when shown unmasked password? We are so used to seeing **** for the password that actual password shown in the field may appear as less secure to some users. I wonder if there is any study/usability test around it?

    0
    • 96

      The technique in the article is NOT suggesting to unmask the password by default. The default is showing the password MASKED. But the beauty of it is the checkbox option to see your password unmasked in case you make a mistake. That way you can diagnose the problem immediately.
      - Did I mistype my password?
      - Am I entering the wrong password altogether?

      You can distinguish between these two cases easily with the unmask option. By the way, it’s key to note that this is OPTIONAL. Users don’t have to use if they don’t need it. But it’s there if you’re having password trouble. When you do it this way, there are no security concerns here.

      Nielson has done some usability testing on this matter. The link is below the paragraph. Check that out. That’s what it’s there for.

      0
  39. 97

    This is an outstanding collection of actionable form items. I’m particularly fond of gleaming more user information after they have signed up and a single password field. So simple but very effective.

    0
  40. 98

    Please, do NOT auto-focus on the first input. This is only suitable for pages where the sole purpose is to submit that field set’s input (a search page like google, or a clean login page).

    If you do that anywhere else, you completely break accessibility and usability:
    1. Keyboard navigation doesn’t work anymore (arrows, shortcuts)
    2. Screen readers are thrown into the middle of the page without notice
    3. funny: if you do it on a select you lose the ability to scroll

    As a guideline, avoid stealing focus at any moment.

    0
    • 99

      The auto-focus technique is supposed to be used on pages where a login form is present. Facebook does this right. When you enter facebook, it auto-focuses on the email textfield, so that you can immediately start typing your login information without having to find, target and click the textfield (which takes time and effort). This should be the standard for all login forms, but not every login form does this.

      0
    • 100

      I don’t even like it when Google does it, personally. I always use my browser’s search bar and have this compulsion to clear it out after I’ve submitted my search. Google always steals the focus, though, and I invariably end up deleting the last letter of my search in Google’s field (which then triggers its new auto-search feature), instead of my browser’s search bar.

      0
  41. 101

    Sagar S. Ranpise

    May 5, 2011 9:10 pm

    Some really great points. We can really make the user experience great by this points!
    Thanks for sharing!

    0
  42. 102

    Adam32 is right.
    When sometimes the connection is slow, when we are typing the password the auto focus create problems by giving focus to the email/username field. Ends up revealing our passwords in the browser history.

    0
  43. 103

    “Check password,” is ambiguous and confusing. Check has many meanings, and it’s next to a checkbox. “Display password,” “reveal password,” or “un-hide password,” would all be better. Given that it’s pretty common practice to require re-entry of certain items, just going with the standard approach is probably best.

    Also, “Spambots can’t fill in the field because they can’t interact with objects in client-side JavaScript; only users can,” isn’t really true.

    2
  44. 104

    A few decent suggestions, and a few suggestions which will negatively impact the user experience. You need to remember users are preconditioned to use forms a certain way, because pretty much every website complies to the same formula. I’m not saying the standard way of doing things is right, but mixing things up will decrease conversions.

    “Spambots can’t fill in the field because they can’t interact with objects in client-side JavaScript; only users can” – this just isn’t true, sure it takes a slightly more sophisticated spam bot, but “can’t” isn’t the right word.

    0
  45. 105

    Lee | You The Designer

    May 5, 2011 10:57 pm

    Worthwhile read, I think the most unique among the feature is the unmask password. It’s really helpful.

    0
  46. 106

    Liam Gallagher

    May 5, 2011 11:32 pm

    Plenty of little things which I tend to overlook have been brought to precedence, brilliant post!

    0
    • 107

      hi how can I upload my pic in thumbnails? Its showing no image right now. I just post my comment on it. Can you please help me out?

      0
  47. 108
  48. 109

    People are used to typing a password twice. I’d feel very uncomfortable signing up and typing a password in plaintext. In fact, I may not sign up at all if that was the interface. I can see what you’re trying to achieve, but I there’s something to be said for fulfilling user’s expectations, even if it means a little bit more work for them.

    I also don’t like the question mark for password recovery, and I’m a big fan of using a honeypot field in a contact form.

    0
  49. 110

    “Ask for a User Name After The User Has Signed Up” – user reaction: “what, I’m not finished yet? unbelievable!!!” How about don’t ask the user for a username at all if possible? Just use the email, less crap to remember for the poor user (I have a google doc with useless usernames because I keep forgetting them and some sites don’t offer a way of recovering the username).

    Question mark icon for forgotten passwords (isn’t that convention for helpful hints? I would be insulted if someone told me why a password is good :P)? An emoticon scratching it’s head would be more suggestive if you wanted to break the convention (which I would advise against).

    0
  50. 111

    You may also want to set :focus states on text fields and add a border or change the color so it’s clear what text field the user is on. Especially if they are using tab.

    0
  51. 112

    Great article! Excellent ideas for an important topic

    1
  52. 113

    The question mark symbol next to the password (use for forgot password) is a nice idea and very useful. It avoid the clutter of the form.

    Nice article..

    0
  53. 114

    Great post, and a lot of these are simple to implement. Is there a reason passwords ever need to be masked? The only thing I can think is if someone is looking over your shoulder while you type it in.

    0
  54. 115

    The provided link to Honeybot has a comment that screen readers will see the CAPTCHA on employing honeybot. Therefore, I suggest using two types of CAPTCHA – default image based for Desktop browsers and text-based questions for mobile/tablet visitors. In addition, we can use JavaScript + XML to detect browser UA and decide which one to use.

    0
  55. 116

    Great post and wonderful examples. Populating a form using Facebook Connect is a balancing act though. The Facebook Developer guide explains it as the following:

    “There is a strong inverse correlation between the number of permissions your app requests and the number of users that will allow those permissions. The greater the number of permissions you ask for, the lower the number of users that will grant them; so we recommend that you only request the permissions you absolutely need for your app.”
    Reference: http://bit.ly/cjEOKB

    0
  56. 117

    Log Users in Without Leaving the Page…

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

    One place its okay to leave the page. The next place its not okay to leave the page. Don’t use pop ups, use a preview pop up.

    LOL

    I enjoy following this feed just for the consistent contradictions. Go back two months and you will get totally different advice.

    -1
  57. 118

    Good Stuff. Do you have any advice on email activation?

    0
  58. 119

    Lovely article! It will help me a lot to design. Thanks

    0
  59. 120

    While I do like and agree with most techniques mentioned here, I do not think that showing the password to the user (mentioned twice) is a good idea.
    Most people type their passwords in masked fields and aren’t used to seeing their passwords so they won’t recognize their passwords when they see them. As a result, when you show them the password they have to check it character by character to make sure it’s correct which is inconvenient to say the least.

    0
  60. 121

    I found this post very useful as i am currently doing research on best pratices for web forms. I think these ideas are a good starting point when designing sign up forms. I would be interested in the research behind these ideas.

    0
  61. 122

    very good! x)

    0
  62. 123

    Fantastic article, and a really smooth read. I totally agree with everything here Anthony. This is a great “start-up” guide for someone who may be trying to “startup” their shopping cart/online store business, or something of the sort. Well written, bookmarked for future reference just in case :-). Nice Anthony, thanks again.

    Jeremiah R.

    0
  63. 124

    murtaza bhatti

    May 7, 2011 2:06 am

    these are some very handy techniques. Doesn’t facebook or twitter login give the user a sense of insecurity. It happens to most of people i have interacted with, regarding this point. They have to think that their information is being shared with another website… We are confused on the decision if we should put up a facebook login on our portal. I’d like to ask about the cross-browser functionality issue, do these techniques work on all browsers.

    1
  64. 125

    thank you, but i’m not quite sure about that -
    “Require Users to Type Their Password Only Once”

    1
  65. 126

    Great article!
    The only problem using most of these methods is:
    - what if user has JS turned off? –
    Personally, I prefer the server side validation (including captcha image) due obvious sercurity reasons.

    0
  66. 127

    Arun Krishnan

    May 8, 2011 8:51 pm

    very informative article. very nice :)

    0
  67. 128

    Typing password twice is useless security feature, I always just copied password from previous field. And I hate masked passwords, so I use plugin to unmask it. By the way, I always use type=”text” instead of type=”password” for password field on sites I make.

    -3
  68. 129

    Great article! Thanks!

    0
  69. 130

    Agree with many points. Disagree with the help icon for passwords like many on here. I think testing would be important on this point, but also, I’m not sure how saving a small “forgot password” link and replacing with an icon is any kind of advantage. Many programmers also want you to retype your email at sign up. There are some good ideas at luke w’s site and another link to some ideas here. We’ve implemented one with good success.

    http://www.lukew.com/ff/entry.asp?941

    http://infinityplusone.com/experiments/email-repeat/version1

    1
  70. 131

    Adham Dannaway

    May 9, 2011 3:31 pm

    I think that hiding the top navigation to decrease confusion is also a good idea with sign up pages.

    0
  71. 132

    Neil Renicker

    May 9, 2011 5:19 pm

    good stuff – thanks! a little unconvinced about the question mark being sufficient for password recovery, but otherwise a great post!

    0
  72. 133

    OK article. I like the idea of offering a demo of a newsletter alongside the call to action.

    I think it’s well worth reading the comments before implementing any of the recommendations.

    From our own experience, it’s best to keep things simple and leave the password field alone. We trialled a snazzy jQuery iPhone password effect on our Webmail login and it only confused and concerned users.

    Rich.

    0
  73. 134

    Here’s an idea… Don’t force people to sign up to use your website.

    I mean sometimes you have to be really dedicated to leave a comment, or even see the final price with taxes and shipping on an order.

    Other than that… good article…

    1
  74. 135

    Hello, nice tips and thank you for them, but I must strongly advise against “Allow Users to Unmask Their Password” in login form.

    You know, each browser allows you to store your login name + password and this is potential security hazard – you know, when someone (family, friend) gets to computer they usually don’t use, you’re practically offering him to reveal user’s password when browser automatically fills it (and keep in mind that a lot of users actually have only one or two passwords for all their accounts).

    I know he could retrieve it from browser by some different method, but that would be much harder and user still can protect himself from that (master password in FF or Chrome etc.). Only way to fight this controversial feature that you automatically offer him is to stop using browser password memory.

    So my recommendation is simple: it sure does make sanse in register/change password forms, but don’t add it into log-in forms, it could be very harmful.

    0
  75. 136

    Great article! Thank you!! :D

    0
  76. 137

    this is very useful for me also.
    zapakdesign.com/

    0
  77. 138

    Thanks for this review. Great resources for those who would like to build a modern registration/login page.

    0
  78. 139

    My 5c worth:

    #1. Protecting the users password is important. Most users would use a common password when registering, and the last thing they would want is somebody at work looking at it while they are typing it in.

    #2. An alternative way to validating an email is to simply log the person in immediately upon signup, and then issue them with a password via email. So the next time they use the service (after their cookie has gone) they would need to enter their password (which they would get from their email), thus confirming their email address. You could also check if the password was the one you auto generated them and force them to change it when they first login n their own. Accounts which have not logged in on their own after a period of time may be deleted.

    @Damir_says

    0
  79. 140

    The “show password” plugin recommended in the article doesn’t work with jquery 1.6 and implements a checkbox automatically. There are also other problems you can check out on the comments section of the developer site.
    I find this plugin http://unwrongest.com/projects/show-password/ much better.

    0
  80. 141

    Spot on.

    Password masking is a major stress factor for users, having an option to display is big help.

    Reading text takes more time than recognizing an icon, so I like the question mark for the password field. It can be supported with some small font text for further clarification though.

    0
  81. 142

    Nice very nice and informatic

    0
  82. 143

    This article gets the simple stuff, but not the complicated stuff.

    1) The confirm password is there to prove that the user can enter their password without seeing the characters, which is exactly how they will need to get into their account the next time they visit. Showing them the characters does not help this.

    2) The techniques for avoiding the captia do nothing to stop a bot that was designed to target your site.

    3) The username and email issue was not properly thought out. Use email for login because it is already unique. If your application provides or gives the user some sort of site-unique name, (typically forums do this so that each user is uniquely identified on the site to other users, but don’t display emails) then let them choose their avatar, name, logo, whatever, after they get in. In other words, there’s no excuse for using the unique site name for both login and display purposes.

    1
  83. 144

    Thank you. Reminds us that UX is associated with attention to detail.

    0
  84. 145

    Relly good article and informative.

    0
  85. 146

    Excellent article except : “Nearly everyone has a Facebook” Not have half of the internet users. Not to speak of the fake stats that FB PR staffs churn out.
    No everyone does not have it, and a growing number of users value a site that is independent and free (rather than bring a slave site to FB) from certain 3rd party sites.

    Does Facebook allow you to log in with your smashmagazine credentials? No! So, why smashmagazine (if it does so, that is) will sport FB icons? Actually, much more users are lost if you are forcing FB stuffs and FB comments etc.

    And if FB is there, you need to include Google Plus and Myspace atleast.

    0
  86. 147

    Vicente Vandenburgh

    November 15, 2011 9:48 pm

    There is really a strange factor going on together with your site design and the persona within this post that you just made. I love it I hope to read a lot much more in depth thoughts and also randoms in your mind from the coming future entry.

    0
  87. 148

    One that isn’t listed here is the use of inline field labels using the HTML5 placeholder attribute. For older browsers that don’t support the placeholder attribute, there are several jQuery plug-ins to fix that.
    This model works really well for repetitive or familiar forms (e.g. sign in), because the user is familiar with the standard form fields, can predict what they are, and muscle memory often kicks in. Additionally, the model works well for short forms that only have to be done once (e.g. registration).

    It’s not as effective for forms that are complicated, infrequently used, or contain unusual, unpredictable data (e.g. filling out a bunch of fields on a healthcare form).

    The biggest downside to this approach is that once the field gains focus, the placeholder text no longer shows up and the “label” is missing. This is easily addressed by displaying inline helper text nearby the focused field. This still keeps the form super clean, removing half the noise on the screen by getting rid of static labels, and improves the experience by displaying additional helper content only on the element the user is currently focused on.

    0
  88. 149

    Hi there. Your article is extremely helpful. I discovered your blog by way of Google while searching. I am really thankfull to you for sharing informations. I enjoyed to read such an interesting post, i’ll bookmark your blog and check again here regularly.
    Keep going with fantastic work.

    0
  89. 150

    I dont like the check password option for the reason that, while filling out forms I like to hit the ‘TAB’ key to go to the next field. With a checkbox in between it forces me to use the mouse. That I feel is not a great design..

    0
  90. 151

    Great Stuff!

    0
  91. 152

    Excellent piece of documentation and an unplugged bunch of knowledge covered. It will be very helpful to my friend for building his website.

    0
  92. 153

    I thought many of the ideas were good. Except the zip code one. It’s a great idea, but poorly executed in the example link (put a copy of every zip code in the country into a database with the city/state they are in!!! Really? And what if you want to do that for many countries? And what about data integrity? It’s a free list, do you want to check it twice?

    Why not just use a map API like Google. Let Google figure out where the zip code is.

    0
  93. 154

    Good post. I learn something totally new and challenging on blogs I stumbleupon everyday. It’s always useful to read through articles from other writers and practice something from other sites. | Bill Z Walton 23test.com

    0

↑ Back to top