usability: dynamic password validation is confusing

The idea is decent, the place you posted to ... not so much.
This is not a bug, but more like a feature request.

Entering a password that according to the Drupal developers is not strong enough is not an error. If the password would not be accepted at all it would be an error. *

So I consider this a (usability) bug.

(*) But then minimum password strength should be admin configurable.

Lets do it the way gaele proposes:

• Make both 'minimum password strength' and 'recommended password strength' admin configurable
• Throw a warning if the password should be stronger but would be accepted
• Throw an error if the password would not be accepted

Think that's still within the borders of a usability bug and not yet a new feature.
If you don't, I'll come up with a solution within the next days.

The problem is, that the colors represent the levels "Low" (red) "Medium" (yellow) and "High" (green), which is pretty intuitive. If we wanted to change colors, we'd lose that.

Also, I changed my mind about whether this is a bug or a feature request. I think it's the latter, so we need to work on this for D7. But then we would probably want to merge in the additional features of the backported module http://drupal.org/project/password_strength.

Agree with Pancho, this is not a bug, and should be pushed to D7.

The strength validation messages are also very disorienting. The messages flash on and off, causing the user to re-read messages as they improve their password. The time delay is also problematic, as it can cause the warnings to become misaligned with what the user has input for brief moments.

I'm working on simplifying the design.

Alpritt, please take a look at how yahoo does this.

I agree with the yellow message, a weak password doesn't block registration, therefor shoudn't be red!
a non-matching password should be red, as it blocks registration!

- non-focus on password fields, one of them are filled, and the other not. (red message stating you need to fill both)
- non-focus on password fields, one of them are filled, and the other not. (red message stating they're not matching)
- focus on password fields, they're the same, but not strong enough. (yellow strenght message)
- focus on password fields, they're the same, and strong enough. (green confirm message)

meaning red never shows when you're editing the password fields, unless it was already red.

switching conditions have the same requirements.

note that i'm talking about the big box, not the small lines after the input boxes, they're good.

I see this issue going a very wrong path, please reconsider using colour as one or only visual cue to this kind of issue. It's attracting to just think of colours, but there are lot of usability and accessibility considerations to be made then.

Thank you Bojhan. I've been trying to remember where I saw that implementation. I need to make sure I bookmark these things when I do research in the future.

Also, don't worry. I'm 100% behind you on the colour/accessibility issue.

I've been working on this today, by the way, and will be tomorrow too.

Subscribing. Very interested in seeing what you come up with alpritt!

I'm probably 85% done, but sadly I've run out of weekend. But here's a teaser screenshot.

That looks good. It presents the same information in a less confusing and alarming way. But please leave the AHAH warning that the confirmation password doesn't match the other password.

@ #13: It's still there; you just can't see it in the screenshot.

Ok, thanks for your reply. I'll just await the patch :)

This is almost certainly broken in Internet Explorer since I haven't tested it there yet. It does, however, work in Opera (unlike – I just discovered – the current version).

If my code is bad, it's partly because I had to learn JS to do this.

http://webchick.net/visualize-your-patches please. :D Or does it look the same as #12?

Yep, same as the previous screenshot. However, you can't review a movie by looking at the poster, so...

http://testing.humte.co.uk/head-password2/user/

username: demo
password: demo

and go edit the password for that account

Obviously if you actually save the changes with another password that would bugger up the demo for anyone else to review.

YAY!!!! Demo sites!!! :D

Ok, this is awesome. Awesome awesome awesome. A couple small nits from #drupal:

- Not part of the stuff you changed I don't think, but could you change the message from "Use both upper and lowercase letters" to "Add uppercase letters" or "Add lowercase letters" when one or the other exists. This is more consistent with "Add numbers" and "Add punctuation"
- The strength graph is funny. If you start with bB1! then it goes up to 50% or less. And when you fill in two more characters it suddenly leaps to 100%. It'd be nice to have this be more gradual.

- While we're changing messages around, "Add X more characters" (where it counted them down as you typed) would also be cool.

I'll look at the code later, but this interactive example looks great!

FYI: Just had a quick look at the demo and in IE7 I get the message 'Passwords match: Yes' even if the second box is empty

Thank you for the feedback. I'm away for the weekend, so improvements will happen next week.

Sweet! This is really friendly!

Regarding the text:

"To make your password more secure" - "more" sounds funny when you start. I can't come up with a better wording, though.

"Use both upper and lowercase letters" - This wording is correct when you start. I wouldn't change it in place afterwards. (Re: #19)

@gaele: Well, my problem was I started typing in characters and it said "Must be uppercase and lowercase" and I didn't know which I was still missing. Granted, that's kind of an edge case, though. Most people will be entering passwords they can remember. :P

I was thinking of showing that first, then as soon as a letter of some kind if entered, replace it with the "Add XXX letters" message. But if that just makes it more confusing and less usable, then nevermind.

@webchick: the sentence would be replaced (changed in place). I was thinking this would either:
- work
- be confusing
- go unnoticed
If it's important enough we could test it on live human beings.

subscribing

Really, really nice on the demo site, I didn't experience the 'jumping' that webchick got but only tried a few things. Not reviewed patch itself yet.

Password meter now has less jumping.

I've split lowercase and uppercase into two separate suggestions. I was a little reluctant to change an existing line as I'm pretty certain this will cause confusion to the user. At the very least it will cause them to re-read the changed line after they add the first letter. Re-reading was a big problem with the previous design, so I don't want to re-introduce a more subtle version of the problem.

I did not add the countdown for each letter (comment #20) because it felt too much like pulling whiskers. However, the meter now rewards the user with every key press.

Still not cross browser tested.

The demo has been updated (see comment #18 above). Hard browser refresh may be required for some.

The demo works on FF3/Linux, Opera 9.52/Windows.
On IE6, IE7 the problem from #22 seems solved. However the Confirm password box is out of position. See screenshot.

Hmm, it seems a bit funny that a 100 random lower case character password only has 60% strength.

I like this a lot. My only recommendation would be to change the color of the bar. Right now, the bar is green, and even when it is only 20% filled, green still communicates 'good'. There are (at least) two possible solutions:

• Change the color of the bar as the password gets stronger; i.e. go from red (short bar) to orange (medium bar) to green (full bar). This will communicate the user that 'more is better' and further improve usability.
• Change the color of the bar to something neutral; say, change the color of the bar to gray, blue or maybe even yellow.

Other comments:

• It looks slightly cramped but not much. I'd prefer to have a tiny bit more padding above the bar, for example. All in all, I _think_ it is OK to use a tiny bit more space but feel free to disagree.
• Code comments are somewhat lacking, and not always formatted consistently (i.e. we start code comments with a capital letter). Please take another pass over the comments to make sure that other people understand what is going on.
• Add CHANGELOG.txt entry?

Good job. :)

While I'm working on fixing these issues, I'd appreciate comments on whether the strength checker is behaving as we'd want it to. Particularly in relation to comment #31.

I want to point you to the following password strength checker: http://www.phpfreakz.nl/library.php?sid=26313 (dutch site, code in english)

I'm one of the authors of that code... which the idea originally from http://www.alixaxel.com/wordpress/2007/06/09/php-password-strength-algor... but (heavily) adapted to include pattern detection, and discrepant support.

I'm allowed to release our code under the GPL ;)

Following the links from #34 I found these two algorithms:

http://phiras.wordpress.com/2007/04/08/password-strength-meter-a-jquery-...
http://rumkin.com/tools/password/passchk.php

They use a combination of minimum requirements and a score. E.g. the longer the password, the higher the score. A very long lower case password may still lead to a maximum score.

Apart from the algorithm: IMHO alpritt's user interface is far superior! It's almost like a game: trying to fill up the strength bar. So Re #32: I believe a single neutral color would do.

E.g. the longer the password, the higher the score. A very long lower case password may still lead to a maximum score.

yes, a very long lower case (e.g. 40 chars) is still secure, just due to the time it takes to brueteforce that long password...

The only issue I know of right now is that if the account has not yet been created, the checker will consider the username to be an empty string. This means the strength check against having the same username and password doesn't work here. So I need to look into that.

I've also not delved too deeply into enhancing the algorithm for the check. As long as it is as good as the previous checker I think improving the algorithm is probably for another issue (especially implementing pattern recognition). But if it really isn't good enough now, let me know specific changes you'd like me to make and I'll make the changes. Bare in mind that just extending the points for an increase in length could lead to 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' being considered strong; I don't know whether it is or not and I'd prefer to avoid straying into that discussion too far unless I'm making anything worse here.

Other than that this patch should fix:

* compatibility with IE 6 and 7
* Support for RTL
* Improved comments
* Extra padding
* The bar is now blue instead of green
* Added changelog entry

The demo is updated as well, by the way (see comment #18). And here's a screenshot:

looking good, in my opinion... this is what we're looking for....

So almost everything is looking good now, however there is a small detail that has great impact on the user. Currently we display blue, however I don't think anyone would associate that with a "good password" while the colour green rightfully does.

@Dries I disagree, with your notion of using a transition from red to green, as red a strong visual indicator and kind of says "This is BAD" while you want to say "This is not so good". Of course you want people to get as strong password as possible, but I think making it red is to much of a you must, instead of a you should.

We want to preserve the visual emphasis(red) on the password not matching, not necessary on the strength of the password.

I think a little green, to a lot of green will do just fine. We already got there attention, there is no reason to scream.

how about: from blue to green?