Filling forms should be keyboard friendly.I would argue that re-typing my password is easier than reaching to my mouse and clicking a 'reveal password' icon.
Browsers have begun to implement this behavior, specifically in IE11.
If the implementation is handled by the site's developer, he or she must ensure the 'revealed' input is set to type="password" before submitting the form. Browsers may handle 'text' and 'password' inputs differently (in the case of saving user's credentials, for example).
I don't agree with this at all.
Edit: Due to a reaction from the author of this post, I feel it pertinent to mention this is just my opinion. I don't have any facts or figures to back me up, just my thoughts and feelings.
First things first, I think the title is unnecessarily aggressive. See "Considered Harmful" Essays Considered Harmful by Eric Meyer. And this is even more incendiary than what he mentions there, in my opinion!
Secondly, I think the content is wrong. As someone who runs a handful of projects that process user signups/logins, I'm quite sure that if I removed the confirm password field, my users would be much more annoyed as they would probably incorrectly type their passwords and have to go through a password reset mechanism. I know I'm a pretty crap typer and make lots of mistakes, so I'd probably mess up my password if I wasn't forced to get it right.
This article tries to claim that by forcing users to enter a password twice we lower conversions, but an account that the user can't log in to because they typed their password wrong and can't be bothered to reset is no better, in my opinion.
While I like the idea of just having a "Reveal Password" box, I bet users wouldn't click it. I'd love this to be A/B tested, where one set of users get two password form fields and another set gets just one and number of resets are watched.
I don't know, this really rubs me the wrong way.
The idea is sound, but this article isn't deep enough and the examples (and title) are pretty bad. Here's a more in-depth read on this: http://www.nngroup.com/articles/password-creation/
What do you mean by "deep enough" and "pretty bad"? Being unspecific and lacking justification means your claims have no merit.
i didn't intend to be vague. allow me to elaborate.
the title is overly sensational. the article doesn't feel researched enough. it only vaguely cites one study that explains increased conversion rates. there's no direct mention of how this affects the user's experience.
the examples are very basic and show only the password field on its own; this does not paint a complete picture of the sign up experience. the simple demos led to Edward A's belief that this will annoy users and lead to more uncertainty. yet in reality, this method can be used to great benefit, as detailed in the NNGroup article linked above.
Thanks for your attempt at elaborating, but I'm confused. How does showing the solution with only a password field on its own lead people to believe that this will "annoy users and lead to uncertainty". That makes no sense to me. Does that mean if my example showed a complete sign up form that included other fields people would understand and accept it? I don't understand the reasoning behind that, especially when the NNGROUP article shows many examples of the password field on its own.
What do you mean there is "no direct mention of how this affects user experience"? The article states clearly how confirm password fields negatively affects user experience, as does the study. I don't understand where you're getting all this. I think you should read the article again.
Everyone has an opinion and you stated yours. But there's nothing else there. Your argument is the equivalent of me saying I hate the color red it rubs me the wrong way. As someone who has seen lots of colors before, I'm quite sure red will turn most people off.
There's no reasoning behind your argument. Whereas, the article is full of reasoning. And it's backed with a case study showing that there were less password resets as a result of the "show password" checkbox. So your claim that "show password" will cause more password resets is unfounded and a mere assumption on your part.
If your article is just opinion, it should be phrased as such instead of using declarative language that make it seem factual instead of opinionated.
I don't know if I really think this discussion is particularly productive... We'll agree to disagree here. :)
Edit: edited out a potentially irrelevant section.
Did you even read what I said above? Sounds like you ignored everything by your response. If it's not productive, why even post your comment in the first place?
My article is NOT opinion, your comment is opinion because you have no specifics and no justification. My article does the opposite of this. I'm not just saying junk food is bad. I'm saying you should stop eating junk food and this is why. Then I'm saying you should eat vegetables instead, and this is why.
All you have said about it is "this makes me feel bad, I think it's wrong." There should be a ZERO TOLERANCE policy for comments like that in design discussion. It's ridiculous that you have 3 points for what you said. It should be NEGATIVE 3 points because you're telling people it is wrong, but you're not being accountable to what you're saying. Nor are you giving people an alternative solution to what you condemn.
Should people listen to a guy who has no justification to what he is saying, offers no specifics and doesn't want to accountable to it. Or, should they listen to a guy who writes an article, provides illustrative examples, justifies his position with specifics and is accountable to what he's saying?
Your logic is effectively "you need evidence to back up a good argument". That's not true. To use another example, I do not need to be a chef to know my food sucks.
It's just my opinion, man. Please relax. :)
Also the obvious issue of revealing your password to anyone who can see your screen by being forced to unmask your password as a means of validation.
If a user typed both passwords incorrectly, then a 'show' button could appear and reveal both field as a compromise.
I'm curious as to the preferred implementation of this system of reveal password buttons. On most sites I've worked with the show password button was just a toggle on click that set the input to type text and then back to password when the click ended. Is this the commonly used strategy? I'd also love to see other implementations of the position of the show password button, is it better to have the button inside the input element or seperate, like a button next to it or at the end of the form.
I've put together a quick prototype which just changes the
textwhen the "Reveal" button is toggled. I haven't tested it very extensively, but it seems the browser will send the data the same way so just toggling the
typeattribute seems to be the cleanest way to do this.
My prototype uses a button inside the password field, I felt that putting it inside the password field was the easiest way to explain the context of the "Reveal" button.
Funny, I did exactly this after reading the article. I implented it as a click and hold, so that when the mouse is unclicked the password is obscured again, with a nice covered eye/open eye to indicate what is happening.