There are already good answers on optimizing the existing success page. I want to add an alternative.
Skip the success page and log the user in immediately. There are a lot of examples of web applications, which allow access before verifying your email address. The user may browse the content, configure his profile, ... but public content ...
Age check tests
Leisure Suit Larry was probably the first application to do this, and considering that I played it when I was about 11 years old, I would call it ineffective.
Making some sort of test to make sure that you are old enough, simply encourages younger users as it makes them feel more 'adult'. Additionally, the test was designed for a typical ...
I'm pretty sure that they are completely ineffective at detering younger audience members (source: myself when I was younger)
The purpose of them seems to be more about the content owner covering themselves against getting in trouble for showing inappropriate content to minors
CAPTCHA is an example of forcing a customer to deal with a business/technical problem - an exchange of great effort for little return on their behalf. "Are you human?" often accompanies these all too common patterns.
You can do better than CAPTCHA by not questioning your customers' humanity, and instead build honey-pots to catch the bots. Honey-pots are ...
Make a two-step process: First, ask for the birth date. Then in a second and separate step, ask for the age.
Often when the age is faked, the birth date is completely random, so entering your age afterwards (without being able to look back) is pretty hard.
From English.Stackexchange: https://english.stackexchange.com/questions/5789/whats-the-difference-between-to-confirm-and-to-verify
Verification requires external evidence.
Confirmation requires a re-issuance of a believed statement.
To use your example: 'Confirm user account' is asking the user from their perspective. 'Would you like to do this?'. '...
We have spent the last months battling with what to do with email confirmation/verification - prior the user had to give all their details at sign up (way too many actually!) but couldn't actually login until they had confirmed their email address by clicking a link.
We stood back and looked at why we did this - three reasons really, one being we wanted ...
These are completely ineffective, just as ineffective as "I'm over 18".
However, they do effectively protect the website from COPPA. If the fact that a certain website has an underage user on it is brought to the attention of the courts, the site can expose its logs, and say that "the user claimed that s/he was over 13, so we didn't know".
It's a legal ...
Disclaimer: This is no means by an original idea of mine, but for the love of me, I can't remember where I came across it. I will post an update when I discover its source.
The basic idea for age verification revolves around asking the user an era-related pictorial question. Anybody who's lived through that era should be able to immediately relate to it, ...
First, I'd suggest reading my answer from a few years ago which explains the importance of the wording.
Secondly, if you can eliminate the delay that'd be ideal. Even with changing the instructions, you're still going to get some complaints with a 5 minute delay.
But assuming the delay is here to stay, here's how I'd write it...
There's only one way to verify a person's age, and that is to have that person go to your head office in person and present their certified birth certificate plus official photo ID. And even then, they could have hired someone else to do it for them and issued them with false documents (but you might be able in some countries to verify the validity of such ...
If you do a search for age verification best practices on alcohol related sites, you will see that there is a general consensus that these age verification splash pages rarely work but are often required as a part of company policy. To quote this smashing magazine article
During my research, I wondered if there were any laws in Canada or the
You can add a hidden field -- that is hidden to the UI, but not the code. The Spam-bots will fill out that field, while real people will not.
It solves the spam problem without annoying real people.
See Spamicide for example https://drupal.org/project/spamicide
The primary issue here is that people do not know and nor do they care that email is not an instant technology. Albeit very rare, email has been known to get caught up in retry cycles and delivered weeks or months after it was initially sent.
Since you have zero control over what happens when the message leaves your server such as routing, spam filters, and ...
Essentially, what it comes down to... is are you dealing with USERS or PEOPLE on your site.
Most companies prefer to have a relationship with a person. Exceptions would be reddit and other sites which are designed with anonymity in mind and are almost purely online communities.
A verified email is a verified person behind the email. Prevents some simple ...
I absolutely hate 'text' orientated/based captcha's, they are inconvenient, often too difficult, annoying, time consuming etc etc.
There are hundreds of alternatives though that don't make the user have to attempt at getting every letter of a ridiculously difficult captcha correct before being able to complete the what should have been a 2 second task.
If you're fine with not having a verified communication channel with your user. Then sure.
But I can't really think of an application where I wouldn't want that. Because not having that verified email means that a forgotten password is the end of the account.
Further there's few things I'd allow that type of unverified user to do that I couldn't just do ...
The checkmark is misleading, it makes it seem like something has already taken place. I don't think I'd use a checkmark if there is as much as a 5 minute delay. I'd just put some messaging up that indicates the user will receive an email shortly.
For starters, I strongly recommend against using captchas as they are not user friendly and have significant usability issues and make it harder for users to complete the form. To quote this article
Firstly, it is worth pointing out that captchas are nowhere near as
secure as you’d like to believe. Back in 2005, the W3C pointed out
that third party ...
This is a fun problem (:
It might be worth offering multiple approaches, or split testing multiple approaches to see which process users tend to prefer. If you've got the resources, it might be worth looking into:
Upload a picture of your ID (70% mobile signup? Use the phone's camera as part of the submission process)
Have the child "request" parent ...
Alan George covered the main reasons you should verify emails but I just wanted to touch on this point in your question.
If the real owner of that email wanted to create an account and see that the email is already used then that person can always request a password reset link, so there should not be a problem.
That is a HUGE problem. Under no ...
Sadly the only effective way is to make a verification based on an official document, a passport or a visa.
This is in no means waterproof (as the person in question can get that information from someone else, mom or dad comes to mind)
In short there is no real or practical solution for age verification. Everything can be bypassed one way or another.
What about using some kind of proof-of-work concept?
The thing is your sentence says the verification link has been sent and some users may understand it as "has been received". If not they're frustrated.
I'll change the title sentence with something like "Check your email account in a few minute"
And then "You'll receive a verification link you'll have to click to confirm your subscription".
But I guess the ...
There are a variety of ways to verify a person on a site, and almost none of them are foolproof.
For example, the Zoosk method can be circumvented because a user could simply submit someone else's photos for approval.
So the real question is, what level of verification is suitable the specific needs of your site? Here are some design questions to as ...
You have to balance how much you are interested in having their email confirmed. Until the user confirms the email the consequences could be:
Not using the app at all
Use only part of the app. Enough to be interesting but hide some features that will make the user want to confirm the email
No app features restriction. Probably not relevant for your case, ...
Yes there is a noticable difference.
The user should Confirm they want to make the change but Verify that the email they entered is correct.
Verify : to ascertain the truth or correctness of, as by examination, research, or comparison
Confirm : to acknowledge with definite assurance
There are several reasons why it's beneficial, from both a UX and a business point of view.
The main UX reason being - not all email clients can handle HTML emails. This is less of an issue these days but it's still a fact. There are hundreds of email clients out there, on loads of different devices. Some browser-based, some OS based, some 3rd-party client ...
This decision can be made by analyzing design constraints
I (and I'll bet many other designers) have worked through this exact decision several times. I'll lay out a typical set of pros/cons:
1. Type in a one-time code (OTC)
Pros: If your app is global/international and needs to address markets where some users may not have smartphones (e.g. developing ...