This is a great question and it may take a few more attempts to get it right. As a rule, people don't read, so a short description is key. I'd try:
Preferred Full Name
Nicknames are fine, titles are discouraged
Hope this helps
You can't send "forgotten password" links to a single account if you have the same e-mail address, unless the user specifies a unique username. But what happens if the user forgets the username as well? Then you need to reset password on all accounts associated with the e-mail address.
Answering your question, which doesn't involve specific motivation behind it. Yes, people don't like to register on sites, people don't like giving information all the time, people don't like remembering passwords and user names.
This behaviour is common to everyone, but some groups are more annoyed than others and some are more radical than others; for ...
So basically you want someone who signs up for a new account and enters already existing credentials, to log in as the owner of these credentials?
I wouldn't recommend this:
The chance that the person signing up is not the owner of the existing account may be small, it is still possible.
The difference between signing up and logging in should be clear.
Like Roger says, ideally you can reset your password easily and securely, but there are certain times that's not an option.
If you're not validating email addresses it's more important that their login credentials are correct; if they lose their password it might be game over if they entered fake email information.
Assuming you have to have a password and ...
There are no security problems. If two people share an email account, and one of them has an account on your site, either of them can reset the password on the account (since they both have access to the place where the "forgot username" and "forgot password" emails get sent). Both people have the ability to take control of the account, and that's ...
In the general case, the fewer forms you have the higher the conversion rate. However, if the form lacks important information for the users, like trust signals or other specific info, your completion rate will drop.
One thing at a time is much easier for the brain to process.
"Two stimuli therfore achieve worse results than just one. It ...
Yes, log the user in
There are several ways an existing user might end up on a sign-up page:
User clicks sign up by mistake
User recently signed up for an account and the browser URL autocomplete takes user back to that URL (most recent)
User forgot they signed up previously and is attempting to sign up again (and, like many users, ill-advisedly uses the ...
All of them except "e-mail" and "Password".
This is the minimum information you need to uniquely identify a user and allow them secure access to your site. The only other piece of vital information would be their address if you were shipping them something - but you can ask for that when they actually order something and not before.
All of the other ones ...
Overall, I think taking users where they came from can be better. Usually, users register to continue their path to a certain goal. For example, Kate was reading comments to a news article, she thought that she has something good to say and clicked "Comment" (Kate's goal is to comment). Now the system asks Kate to register and takes Kate straight to the ...
Don't give instructions. Give clear, concise, impossible-to-ignore examples.
(e.g., Bob Jones, Liz Johnson)
The example names that you choose, like the ones here, need to communicate that users are encouraged to enter their "daily use" first/last names, without having to actually type out that direction, which users may glaze over.
A system should not store the user's password in retrievable mode. This could be done adding salt (a meaningless string of letters and numbers, which doesn't change) and then hashing the whole string before saving to a persistent storage.
When the user signs into the system, the same route is taken to make sure that the password is correct. (password + salt)...
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?'. '...
Yes - underhanded, but this is not a problem reserved for the web - it's long been an issue for print too.
A couple of years ago, the EU banned pre-ticked boxes on shopping websites in order to prevent such issues as unintentional purchase of insurance or optional extras when purchasing plane tickets, for example.
The legislation does appear to revolve ...
There are chances that user might have no idea about their registration status on the site. And start a fresh registration.
In such a case, best solution would be to OFFER a way to login by inline validation. Before the user reaches the password field, the validation should suggest ways to login as the email is present in database. But, since its not ...
Hiding information behind logins is really bad from the usability standpoint. Imagine you are a user who googles for a certain piece of information.
Workflow on website without registration-wall:
enter search-term into search-engine
click on first result
read question to confirm it's really relevant
Workflow with registration-wall
Where is the best place to ask the user their ethnicity?
Honestly -- in the doctors office.
Unless the benefit to the user is clear then don't ask for it. You wanting to keep track for your own records isn't clear benefit to the user. If it turns out that a user sees value in telling you their ethnicity (like in a doctor's office due to ethnic related ...
It's better to use a special one-time login url.
Reasoning: You want to make the process as easy as possible to have the lowest drop-off rate. Sending someone a temporary password requires them to either retype a password that they haven't chosen, or copy and paste it. It also provides no additional security benefits.
I disagree with the other answers, and say yes, it may make sense (with a couple of caveats).
There is an increasing prevalence of the combined login/sign up form pattern on some sites, where the whole sign up form is simply email address and password, and all more substantive profile questions become an optional step after registration. This pattern ...
I like the way Microsoft handles this in Windows 8. There is a single password field, and a button that displays the password while it is held down. That way, the user can check for typos. If the user enters their password with great confidence, then there is no need to enter it twice or look at it, but people who want to see if they typed it correctly can, ...
If the form was rejected by Server-Side validation, the password should be blanked out since it shouldn't be sent back to the client.
This problem is easily solved with inline validation though, you simply shouldn't be able to submit a form until it won't be rejected, and then no form data will be lost.
Passwords should only be lost in the rare situation ...
Does your system allow users to control their own display name at a later point in time? E.g., once hired, can Robert V. Jones go into some settings panel somewhere and change their own display name to show "Rob Jones" or "R.V. Jones"? (If not, what happens if they change their name legally and want to be subsequently addressed by "R.V. Smith"?)
If so, I'd ...
I'm not sure we can we specifically answer the question with the information given, but below are some ideas of what to do and what not to do that may help you determine the best course of action in your own scenario.
Automate the sign-in after sign-up. I really dislike those sign-ups that gather all the site needs to use an account then redirect users to a ...
Let's say the user just cannot receive email on their mobile device - for example those that deliberately do not want to be contacted by email - those on a limited data plan - or those without the inclination or technical know-how to setup email.
For whatever reason, there are going to be people who fit that category. So ask yourself if you want to ...
Sadly there is no standard for the name of such an email - all your suggestions are used. But consider the following:
Verification Email - used when you can still access services, but need to verify your email in the meantime.
Activation Email - used when services (account) are not accessible until email activation takes place. You can argue that there is ...
The second time you are asked to enter your email you may notice it says "confirmation." That's all it is really, just confirmation that you are entering the correct email.
In some instances, asking for an email twice is crucial. Consider signing up for an email list for example. If the user makes a mistake and enters their email incorrectly, they may leave ...
Stripe.com (a payments processor) offers an even more "immediate" sign-up process - they allow you to skip it all together. Any guest can begin using their dashboard and begin customising settings, testing mock transactions and making customer profiles before entering any sign-up information. No username, password or email. It's only when you want to go live ...