Let me try to paint a picture to explain why your comment below is a huge oversight.
Tbh I don't really see any use for the "forgot password" button/link, unless the user put in a wrong password before.
Imagine a scenario where the users come to your application after a while and they don't remember the password. It means, they already know that an ...
One reason why this might not be a good idea is that you would have to enforce unique passwords. This does not seem like a big issue to user experience at first, but from a security point of view, this is critical, here is why:
Enforcing unique passwords means that when a user picks a password there is a chance they accidentally (or with malicious intent) ...
A compromise is that when a user returns to the site after 6 months (or whatever period) then you might helpfully recommend that they think about changing their password - along with a link to why this can be a good thing for them.
This also allows you to put in a framework where you might want to bring forward the date at which this happens to a specific ...
On the second page, either display "user found" and ask for password, or "user not found" and ask for e-mail again.
One compelling argument against the two step approach is that the proposed design would allow for any unauthenticated person to determine if an email account has registered with that site.
This is a problem both for security and for privacy.
There are a few reasons not to allow spaces in usernames...
...most of which can be resolved with proper implementation:
They need to be tested with 3rd party software. Even if your software allows spaces in usernames, if you are using 3rd party software libraries to handle usernames they may disallow spaces so you will have to at minimum test compliance ...
Log in / out is more technical sounding than sign in / out. That said, I don't think there is any confusion with either one of them. The last time I looked at major sites using log v. sign it was a pretty even split between them. I would opt for sign in / out simply because it is more human speak.
Regarding Join, Register and Sign up. They each have ...
I would recommend against an auto-correct as domain name extensions are about to change drastically, to the point where an email ending with "sitename.anything" will be valid.
Consider an inline check, which means it doesn't cause the frustration of the usual
ENTRY > SUBMIT > ERROR MESSAGE > RE-ENTRY > SUBMIT
[!] Did you mean .com?
Some compact keyboard layouts don't have a numpad, so those keys are mapped to the right-hand side of the letter section:
If NumLock is on, then a user typing the password kill, will actually type 2533. Turning NumLock off will prevent this problem, but of course - it will cause another one for those who do rely on the numpad. Keeping it on or off by ...
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.
If you want something compelling that your boss can grasp then I suggest you speak to him in the universal language known as money, dinero, ducats, dolla-dolla-bill-y'all
Your current situation
Your suggested design will create a security flaw and your system is bound to get scraped for valid usernames
Do what I say and tell the magic ...
I can think of three possible solutions for you and none involve an icon, which I think is a poor idea. Instead, consider one of these solutions:
1. Push all failed login attempts to a separate login page.
Instead of trying to shoehorn error and failed login attempt messaging in a top bar, push users over to a login page with the form filled out with the ...
It's a very bad idea to not show the link. You should always give the user the option, even if they are likely to try a few passwords first.
How about an example - what if you have a password manager, and your credentials for this site is somehow lost/missing from your password manager?
You have no idea what the password is, as it will likely be some ...
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 ...
All you're doing is pushing the security requirement into the domain of the user when really it's your concern if the data you are protecting is serious. In this case it doesn't matter what you do with passwords, you must employ secondary measures, such as two-step verification (GMail, Github), session deletion (GMail, Github, Facebook), unusual account ...
If you think about it, clearly, and logically the default value must be "off". This can be proven if you look at the use cases of the sign in life cycle.
Let me explain, by comparing the browsing behavior of two different types of users. User #A will be one who likes remember me disabled, and User #B likes to have it enabled. Let's compare what happens to ...
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 ...
If you choose to have a password only log in, you will run into many problems.
If you only require a password, you have no way of knowing who it is that you are logging in unless you enforce unique passwords. In that case, if I were to sign up and tried to use a common password (say "Password") and your system told me that it was not allowed, ...
No. While it seems to be annoying, I see four problems with not having to enter the login information again:
I will remember my new password better if I have to type it once more. (I keep forgetting my new e-banking password because I don't have to re-enter it, and I of course don't store it in the browser.)
If I want to store the password, the browser PW ...
If the users use the email address to log in into your application, you shouldn't use the word "Username" at all, in any place of your application.
In the registration page, they should fill out the "Email" (with a help message to inform they that it will be used to login) and there shouldn't be any "Username" field.
From a security perspective, make sure you're only showing messages if the user has provided their password, even if they're banned.
I would recommend a ban notifcation (including time), when the user attempts login, show them the reason they were banned and the length of time they were banned for.
if there is an appeals process, this would also be the ...
The products these days are intelligent enough to predict their visitor intent of coming on the website based on past their past behavior. For example, If I have logged out of a website, then the next time I open it - it will know that I am a returning user (through various technical means, e.g. browser cookies) and can present a message, "Returning user? ...
If you are providing a valuable service/product there will always be people trying to "cheat" the system and get in. Providing a free trial period is an industry norm and over time users may sign up for more than one trial but that will get old fast.
I would worry less about ensuring authentic users and focus more on providing that great content. If you're ...
There are a number of variations of the the "unmasking eye" icon but they mostly have the same issue, below are some examples:
I have done some usability testing on this specific problem and many users I have tested with didn't even notice the "unmasking eye" there is also some issues with how to best convey the state of the password (masked/unmasked) and ...
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 ...
In my opinion: YES.
The authentication has been done when the password is reset, so the user could be logged in. And it annoys the hell out of me when after password reset I'm not logged in.
I can't think of any case I wouldn't want to be logged in after resetting password, why would I even ask for password reset if I don't want to log in?
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
In your current version the contrast between the color you use for your error message and the background color is low.
Try either a brighter error color or a lighter background color. Here are some examples;
Check out this tool to measure color contrast.