Have you ever filled out a web form and been asked to enter the exact same piece of information twice?
This is “double entry” — also known as “re-entry” or “confirm” — and you’ve probably encountered it as it is part of the sign-up forms for a number of popular websites, including Google (double entry for password) and Facebook (double entry for email address, see Figure 1).
Figure 1: The Facebook sign-up form asks users to double enter their email address.
Why collect the exact same information twice?
Every additional field on a form means additional work for the filler, which in turn means increased risk of errors and a potential reduction in completion rates. So why on earth would we add a field that simply repeats the work done by another field on the same form?
Double entry aims to prevent errors
The primary reason is error prevention. If we ask the form-filler to re-enter their email address or password, we can check that the two versions match. If they don’t match, we may have picked up a typographical mistake. See Figure 2 for a screenshot of this in the Google account sign-up.
Figure 2: Google sign-up form highlights when re-entry password doesn’t match original entry password.
(May is important, because it could be the re-entry field that has the typo, not the original field. In such cases, we will be asking the form-filler to re-type into both fields, when in fact the single-field version would have been right.)
As well as preventing them, double entry causes problems
By having double entry for one or more fields on a web form, we are asking the entire user population to do more work, for the sake of preventing what could be a very small number of errors. Before implementing double entry, you should try to identify the extent of the problem that you’re aiming to prevent, and decide whether it is worth the potential barrier to completion that double entry represents.
Even if you do implement double entry, people are smart and will do what they can to minimise their own workload. One common behaviour is copying and pasting the email address or password from the original field into the re-entry field. This obviously negates the benefit of double entry.
You can program the form so that copying and pasting between double entry fields is prevented. But this is likely to frustrate some users and confuse others, who may not understand why paste is not working. It also doesn’t prevent users from copying and pasting their information from another source (e.g. a password manager).
Some people use automated tools to fill out forms. These tools may be native to the browser, or an add-on. For such users, double entry — on the email address field, at least — provides no benefit.
Finally, some users find double entry patronising. The existence of double entry suggests that the form-filler cannot be trusted to enter information accurately. As such, requiring double entry may compromise the establishment of trust between the form-owner and the form-filler, trust that is important for maximising conversion.
Why is double entry mostly just for email addresses and passwords?
With all these disadvantages, you may wonder why anyone ever bothers including double entry on their web forms. Indeed, these disadvantages are probably the reason why double entry is rare, and is usually only seen on email address and password fields. Why these fields? For many online systems, your email address and/or password are ‘keys’ that give you access. Therefore, a mistake in one of these fields can have greater implications than choosing the wrong title or even mistyping your name.
Some may argue that there are other equally important fields on web forms, such as a credit card number. However, credit card numbers are often validated at the point of entry. Moreover, credit card numbers are not contact information: if the credit card number is wrong we can contact the user to get the right one, but if contact information is incorrect, there is no way to rectify the situation.
The astute logicians out there will note that this argument suggests double entry would be warranted on phone numbers. Indeed, if a phone number is the only (or primary) means of contacting a user, double entry might be appropriate. Alternatively, if the contact number is a mobile phone, it can instead be authenticated by sending a text message that requires action from the user, to complete the process.
Other methods for ensuring the email address is correct
The method mentioned above, for authenticating mobile phone numbers, can also be used for email addresses. To confirm that the email address is not only valid, but also that the form-filler has the authority to access that email address, we can send an “activation link” to the email address. The sign-up, service or sale will not be completed until the emailed link — which is unique — has been visited in the browser.
If a user’s email address is their username, then this authentication approach is probably a better choice than double entry. Double entry only ensures the two versions of the email address are the same; authentication goes further an ensures the email is correct and usable.
Of course, such authentication takes the user away from the form, and relies on the email being received and acted upon. All of these things are potential points of abandonment or failure. To minimise the negative impact of authentication, it must be carefully designed and built (e.g. warn the user that it will be necessary and give them sufficient time to activate the link). If the email address really must be right, however, the advantages of authentication outweigh the disadvantages.
It is interesting to note that a 2008 Smashing Magazine study of the top 100 websites found that only 18% of sites required users to do double entry of their email address. This compares to 72% of sites requiring double entry of passwords.
Why is double entry more common for passwords than email addresses?
There are good reasons why the number of sites requiring double entry of passwords is much higher than the number of sites requiring double entry of email addresses.
One key difference between the two fields is that by default — provided they have been coded correctly — passwords are hidden, or “masked”, when being entered (e.g. by bullets or asterisks in place of whatever is typed, as per Figure 3). Email addresses are not masked in this way. Masking aims to prevent someone seeing a form-filler’s password by looking over their shoulder.
Figure 3: Ebay password masking. The word “Testing” has been typed, but seven bullets are shown instead.
Because the user can’t see the characters they are typing, there is a greater chance they will make a mistake, hence more reason for double entry.
Also, passwords can often be more ‘random’ than email addresses. Email addresses often contain the user’s name and perhaps the name of an organisation, web mail provider or internet service provider: all things that are fairly easy for the user to remember. Conversely, passwords can be as complex as a random string of characters and digits (although this is not necessarily the best choice from a security point of view, a lengthy and seemingly obscure passphrase generally being a more secure choice).
Alternatives to double entry for passwords
One alternative to double entry is, of course, single entry. This can work well, provided the user is given a quick and simple way to reset, or be reminded of, their password. Such functionality should be provided anyway, for returning users that have forgotten their password. Interestingly, the sign-up forms for Facebook, LinkedIn and Twitter all only ask users to enter their chosen password once.
Figure 4: The sign-up form for LinkedIn doesn’t use double entry for password or email address.
Another alternative to double entry is to allow the user to switch off masking of the password field. This puts control in the hands of the user: if they feel comfortable to expose the password, then they can do so.
There are a few different ways this can be implemented, but our recommended approach is shown in Figure 5. We prefer this approach because it provides a button — rather than a single checkbox or a pair of radio buttons — to toggle the masking on and off.
Figure 5: An illustration of “show password” facility, to toggle masking off and on.
Single checkboxes can be hard for users to interpret, and a pair of radio buttons can be hard to position effectively. Present the radio buttons vertically and they will often take up more space than the question itself; present the radio buttons horizontally and you’ll likely have problems using proximity to make it clear which answer goes with which control. It’s also harder to semantically associate a password field with a single checkbox or a pair of radio buttons, than with a button. Therefore the button represents a more usable and accessible approach.
Think carefully about double entry
The desire to prevent errors on forms is a good one. But given that double entry…
- increases the workload for every single user;
- can be bypassed by copying and pasting, or automatic form-filling tools;
- only ensures the two fields match, not that they contain the valid information; and
- may be seen as belittling the user;
…it is important to establish a real need before implementing double entry. If the email address is the only method of contacting the user, or is their username for your system, then double entry may be warranted. Similarly, if you don’t want to provide the functionality to unmask passwords, then double entry might be appropriate for that field.
Even in these cases, however, alternatives to double entry are worth serious consideration. These alternatives include authentication and/or simple methods of reset or recovery.