Usability: Even better password strength experience

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

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.

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.

@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.

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.

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 ;)

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?

We don't need a gradient, it doesn't add meaning because:
- the SIZE of the bar indicates the password strength.
- the COLOR green indicates that both passwords match.

Changes made:

* Back to green for the password indicator (see #40)
* The check against the username now compares against the username edit box if it exists on the page. If not, it fallbacks to the username in the database.

To check the contents of the 'username' edit box I had to add a class="username" attribute to the edit box for username because the existing id is not consistent. Sometimes it is 'edit-name' and sometimes 'edit-account-name' depending on whether the fapi #tree is set. This is not ideal because using the class is a slight performance hit (though the emphasis is on 'slight' and this is client side), and it is just looks a little messy to me. The other option would be to standardise the system so #tree was always used; meaning the id would always be 'edit-account-name'. I started to do that, but I smelt dragon breath and fled. In any case #111719: FAPI fails to check auto-generated IDs for uniqueness - XHTML validation fails. looks like it is related, so I'm leaving at 'needs work' until I've read through that issue. Comments welcome in the meantime, though.

This changes the selector to $("input.username") rather than just $(".username") which makes the performance issue all but disappear. Also reading through the thread mentioned above, it seems that class is the more robust element to select on anyway so this is probably the right approach.

Can you provide demo + image?

Subscribing. No time to test patch at the moment. I'll come back to it.

I was initially thinking it would be good for the strength bar to go from red to green. I see that Yahoo uses green all the way across. But, I really think it would be good to say that this really isn't a good password. If you are interested in preserving red for unmatched passwords how about a yellow to green transition. Green = OK to a lot of people and insecure passwords really aren't ok.

Bojhan: See #18.

There are warnings on that demo site at the moment, but it basically still works. I'll correct that later tonight.

I've also just spotted a bug with the upper/lowercase check, so setting back to needs work.

Playing with the demo site, I think that this patch is a long way to making the password validation 'not confusing'. However I do recommend using red/amber/green for the strength bar. This should be admin configurable in the following way:

• Allow admins to enter a minimum percentage for an acceptable password strength. Anything below this would lead to a red partially filled strength bar.
• Allow admins to enter a minimum percentage for a good password strength. Anything below this would lead to an amber partially filled strength bar. Anything above this would lead to a green partially (or fully) filled strength bar.

In this way, setting both of these values to zero (which should probably be the default) any password is acceptable and the strength bar reverts to green-only as in the current demo at #18.

Okay problem fixed.

@49:

1. What is still confusing?

2. I tried implementing the transition from red/amber/green. What I coded jumps from colour to colour abruptly which I think is too distracting. Perhaps it would work if we could figure out how to do a smooth transition, but IMO this is just complicating something that doesn't need to be more complicated than it is already. We already have two visual cues that the password strength could be improved (i. the length of the bar and ii. the text giving advice for improving it.) I struggle to imagine anyone typing one character, seeing a tiny nugget of green and thinking to themselves 'ah ha, green, that is a good password'. We could of course have a bike shed discussion over this for a long time, but ultimately it is how users behave that matters, so I don't think we will get a definite answer until this is tested. In the meantime, I would like to go with the simplest solution.

3. I think the configurable bit is out of scope for this issue; although I agree it would be nice to have the ability for a contrib module to make these things configurable.

@51:

1. Sorry that was inappropriate wording just copied from the title of this issue. I don't think the demo is confusing. I do think that inexperienced users may be unsure what is required.

2. The purpose of the colour changes is to show users when their password has met the minimum requirement and then to show users when their password is considered good enough. Without the colours a user might ask 'is my password good or is it just ok?' or 'should I be aiming for a 50% full strength bar or do I need to get 100%?'. See Google accounts for an example of the colour changing. I think the current patch is actually better than the google one, but the addition of colour changing to the strength bar would IMHO be the icing. I agree that the only real way to test this is with a proper usability test.

3. You're right that the configurable bit is out of scope for this issue if we keep the current patch. But, if we want to implement colour changing, it would need be in scope for D7 core (unless we want to ship D7 with minimum password strength requirements... which we definitely should not!).

You should use "description" class for the password-description division. Text color fuses better with the theme. Just to be more consistent with other themes instead of fixed styling for it.

A picky thing: the correct width for password-description division should be 38.5em if you want to make it exactly of the width of the two password fields. Tested with Safari and FF3 on Mac. Even otherwise you can just fuse the password-description into the field's description.

"To make your password stronger:" would look better and consistent with the term "Password strength:".

Would be even better if themers get option to set colors for various strength level for the bar, not much necessary though. :D

also, color should never be used as the only way to convey a message, think about the disabled!

@54:

I agree entirely. My suggestions were not for a red coloured strength bar, but for a configurable strength bar where red does indicate an error (eg. your password is too weak and will not be accepted). If this functionality is going to be left to a contrib module, then the current demo of an all green strength bar is the best solution for core.

@50:

I've tested the demo (not the patch) with IE6 and FF3 and it works perfectly in both. Great work alpritt!

Tested this locally, a couple of things which need work:

1. When the password field is focused, it immediately changes to the 'To make your password more secure:' text - but I've only tabbed to the field, not typed anything yet. Should probably be on key press rather than focus.
2. If I ctrl-refresh then immediately tab to the password field, I get a tiny bit of green bar, despite there being an empty password. If the username and e-mail field have anything in them, then I don't get any green bar.

No code review yet. Let's please deal with colours etc. in a followup issue, or contrib. This is a massive improvement over the big scary red block of text.

Let me address Catch's first point from comment #57.

While it is true that the text 'To make your password more secure' does not quite represent the state prior to entering any text into the password edit box, there is a reason for the suggestions to appear at this time. Perhaps, however, the text can be improved.

The reason for displaying the suggestions at this point is so that the user receives the advice at the point when they need it; just prior to thinking up a password. If we wait until the first character is entered we will be inviting the following scenario:

- user tabs to the first password box. At this point no suggestions of what a good password consists of are given.
- the user thinks of password.
- as soon as they begin typing the password, the suggestions pop up and interrupt them.
- the user must now choose to either ignore the interruption, decide that their original idea fits with the suggestions, or think up something entirely different.

So to avoid this backtracking it is necessary to present the suggestions upfront.

It was suggested in IRC that we display the suggestions as soon as the page is loaded. My reason for waiting until the edit box receives focus was so that the page is less overwhelmed with information that is irrelevant until they actually go to enter a new password. This is particularly the case when the user may not want to edit their password, but instead just change their email address, for example. I don't think it is an issue to make it appear at this point because it will receive focus at exactly the point where the user is moving from one part of the page and into the edit box. At this point we can count of the fact that the user is making the mental shift to the next task, so presenting something new won't be an interruption.

I will return to the other issues shortly.

Alright, I'm not sure I agree, but that makes sense anyway. In that case, could we maybe add a slideDown or something so it's a slightly less abrupt appearance? It's minor, but some kind of transition would be nice there. Should say that apart from these two niggles I think this is pretty much ready to go

Okay changes in this patch:

@#53:
- The password description is now a child of the description tag.
- Changed the width to 38.5em
- I made the suggested text change from 'more secure' to 'stronger'.

I think there is not enough contrast now between the the text for the suggestions and the background, making it less readable. However, since it inherits that from the description class, I think this is another issue.

@#57:
1. We've covered this above. I've not added animation either. In my opinion the animation makes the appearance of the suggestion box more jarring. It is quite possible I would think differently about this matter if javascript animation was smooth, but it isn't there yet. Personally, I think it is fine without the animation. So I've left this for now.
2. Fixed.

@IRC comment
I've gone through the JS coding standards and corrected some white space issues and a couple of other things I missed.

@general
The 'suggestions' box is now only updated if the HTML is actually going to be different. This is a big improvement in performance.

Some screen shots:

Weak password, no match:

Strong password, match:

All tips covered, match:

Re: animation: We should not decide on using animation on a per case basis. Let's not add it here now.

If you try out the demo site linked in #18, remember to actually try and create a strong password and see how the tips list gets shorter.
I talked with alpritt about maybe hiding the tips again if both email txtfields lose focus. But let's not do that either, keep them visible, a little nagging seems appropriate here.

The disappearing tips as you build a stronger password is some excellent carrot dangling. If you cover all tips in your password the tip box disappears completely. Nice work this.

The latest demo in IE6 has the description offset to the right. See screenshot.

Edit: It moves back beneath the tips once the password field has focus.

subscribing, this looks very interesting

I can confirm the IE6 bug reported by ff1. It's pretty minor, but would be nice to fix. Other than that this looks RTBC to me.

is the IE6 bug a template bug or a code bug?

why wasn't this issue critical????

this was one of the biggest issues from the usability tests.

A template bug. This should have fixed it.

heh cross post.

Looks much better in IE6 now. However, I can't get it to show up, at all, in Opera (neither the current checker either). Is that just my machine or a general bug. If the old one doesn't show up either, then I think we can happily set this to RTBC and open a followup issue for that. But leaving at needs review for another set of eyes.

hmm. It's working on my copy of Opera, but I remember there being a bug with the old checker and yet everything seems fine now, so not sure what is going on. What exactly are you seeing? Is it as if javascript is disabled? Or is just a part of it not showing?

It's as if javascript is disabled. Caveat, I never use opera except when reviewing patches, so it might be me.

The demo site works fine for me in Opera, I believe this is the current release version:

Version 9.60
Build 10447
Platform Win32
System Windows XP

with, as far as I know, anything related to JavaScript left at the installation defaults.
--
Joe Kyle
--jjkd--

I think we can take that as meaning my Opera install has some issues. I tested this again, and all my previous concerns are dealt with (apart from the hints showing up as soon as you tab to the password field, but I'm not going to argue about that). I also took another look through the code, and couldn't see any obvious issues. So marking RTBC.

hum.

No need to pass in all the t'd strings to javascript, just use Drupal.t().

Awesome. Committed to CVS HEAD. Good job, alpritt.