Tbh I don't really see any use for the "forgot password" button/link, unless the user put in a wrong password before.
Let me try to paint a picture to explain why the comment above is a huge oversight.
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 account ...
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.
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 ...
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 ...
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 ...
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 ...
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 ...
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 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.
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 ...
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 ...
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 (...
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?
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
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.
There are a number of reasons:
It prevents someone causing someone elses account to be locked maliciously (if I know your email address and you bank with Barclays I can lock you out of your account by repeatedly attempting wrong passwords).
As @AlexFritz indicated it makes it harder to try hacked username and password combinations from other sites on the ...
I think the strongest argument against this sort of pattern is simply, "How does the user know?"
How does the user know that they can register simply by attempting to log in. If they know they have never signed up for this site, they know they do not have login credentials. Thus they will actively look for a sign up option.
The sign up option is a ...
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 ...
Both sites are preparing new login features.
Google has made an announcement explaining the reasons behind the 2 steps login process
Today, you sign in to Google on a page that includes both the ‘email’
and ‘password’ fields on the same page. We’ll be gradually splitting
those two fields into separate pages in the coming days; the sign-in
The color of the login button should match the primary color of your style theme.
Apparently, you're using material design. If your theme, for example, uses blue (#2196F3) as a primary color, your primary action buttons should also be blue so they are contrasting the rest of the page and are easily distinguishable.
The "Register" button which is the ...