Add colouring (and description) to password checker

Aww, almost got away with it! This has been a highly requested feature in the previous ticket around this. We initially said no to this request for the following reasons :

1. The visual emphasis would be put too strongly on the password, that it would again scream at you - scaring people off.
2. The way we structure the password validator now, should make it clear that as you're filling in the password checker the green bar will full up, assuming people don't use "a" as a password some of the suggestions would disappear and you would be left with a couple - which should trigger the behaviour of filling it up (as filling it in removed some recommendations).
3. We wanted to lay the strong visual emphasis on password matching, which is for the user the more important information (as otherwise he cant complete the form)

The scenario you purposed could very well be true, that people go like "its green" so its good - while you want to trigger "I can make it greener". But so could the scenario "it's not really green at all, lemme fill it up" its kind of something we should test rather then just assume one scenario.

About adding description, it could definitely help for accessibility and maybe also people who don't really take the time to associate colour and just read and click submit. But I am not sure how we could place that in the interface and whether or not it really triggers those folks - to avoid adding even more clutter we should really think about this one)

To many people it sounded as an obvious solution, so it might be weird that we initially decided against it. But you have to consider that sometimes what big other sites do, might not work for people using Drupal.

@webchick:

My point was not that you are a highly experienced user of Drupal, but more that you have been involved in this specific issue. So you fall on the developer rather than user side, and so are more likely to be looking for problems. So, yes, there may be an issue here; but there is not necessarily one. We need to test against naive users to get a proper understanding.

I took a look at a couple of dozen password checkers before designing the current implementation. The current design is a lot closer to the norm, than what we had before. But as for getting closer to it, I'm not sure we can because there is really not a consistent design between them. So, at this more subtle stage, I again think we really need to test. I could argue the merits for the change either way.

Another option may be to go from grey to green.

Rather than red to green, I mean. So at 5% it would be grey and then the colour would gradually become more saturated until at 100% it is a nice intense green.

Hi folks,

Attached is a patch to implement the password strength meter like google's one. It's my first cut, and probably needs some tidy up. I took some liberties by floating things in order to get the layout right in a hurry, and I have completely ignored the drupal translation system for the weak/fair/strong words, just to name two problems :)

Attached is also a screenshot of it in action, in case the patch doesn't apply for some reason. It works for me using latest drupal 7 head, in firefox 3.

I didn't apply or execute the code but on code review this looks fine, except that it needs testing with RTL languages and will probably need some changes to system-rtl.css (or it's equivalent).

tested, its better than before but the colors are a little strong still

I'mna re-roll the patch with the following changes:

* Against latest drupal 7
* Fixes for RTL languages (which at this stage I am assuming will be CSS changes to float stuff the other way)
* Reduce strength of colours
* Hook words into the translation system

The colours are always going to be subjective - I'll throw a drupal up somewhere that people can see it in action and solicit some feedback then.

I think this is a good patch, but it seems like we're not 100% done discussing the colors yet. Bump.

I've been away - will look at it sometime soon.

Since we all agree about the status...

I think Shannon Lucas is on the right track however, it doesn't seem right that with the change of a single character I could go from having a password with 1/3 the right strength to 2/3. Would a percentage be a better indicator? much like that talked about in #6. A full colored bar that starts of with a weak red that turns into a strong green as the password strength gets better? and of course also with text explanation weak|average|strong|awesome|are you gonna remember this?|ridiculous - we could it down maybe

Percentage is a bad indicator, it might be weird to jump so suddenly - but it just colour bars would require less "figuring it out".

Okay, I finally found some time, and have made a new patch. Screenshot attached too. I haven't got time to set up an install with it right now, but if it's necessary I'm sure it can be arranged.

I fixed the issues I said I would fix in #10. Please let me know if there are other things that need fixing.

Personally, I'm not sure about the weaker colours - having washed out colours makes the text harder to read. But it's up to you guys.

This patch is not linked correctly. I noticed it looking at the testing.drupal.org logs.

Indeed. Here it is hosted elsewhere: http://stuff.nigel.mcnie.name/password-strength-meter-2.patch - picture: http://stuff.nigel.mcnie.name/password-strength-meter-2.png

Marked #392320: Password widget strength bar colour as a duplicate of this issue.

subscribe

Subscribing.

This patch changes the colour and label of the strength indicator, while the original layout remains. Colour changes are fluid, label changes occur at 35% and 75%.

.

I find a current problem with the current password checker is that I don't use the mouse to scroll down the install page but just tab my way through it, which means when I get to the password fields, I don't see the meter below, I have no idea how strong or weak my password is. Would it be a better idea to but the password meter/checker thingy on the side or above for accessiblity reasons?

Webchick's comment in #25 suggests that there is a bug. Marking this 'code needs work'. 6 colours seems too much -- how about 3 colors? Red, yellow and green?

@26:

#325877: Password checker breaks if no description deals with this by automatically scrolling the password meter, etc into view if it is off-screen. (Or rather it will when I finally re-roll it.)

tagging

This patch still applies, however in my first test I didn't get the color display. I updated the CVS and got "Fatal error: Class 'DrupalDefaultEntityController' not found" so I'm going to sit on this and hopefully test more later.

Subscribe. Let's try and keep it as simple as possible.

Wondering if this is something that can be worked on after code freeze?

I've re-rolled the patch as it didn't apply. The test now doesn't seem to produce the error I reported in #30 - perhaps it was just my system or perhaps the code's just improved.

I've attached various screenshots of the form. It's looking good!

I do think this is RTBC (I just moved the code around and changed quote types to single quotes), but I'm not in a position to do it.

+1 for this patch. I cannot evaluate the visual effect, but it is critical that the colored password strength bar also has textual representation, which this patch provides.

+++ modules/user/user.js	3 Sep 2009 13:34:07 -0000
@@ -19,7 +19,8 @@ Drupal.behaviors.password = {
+      var passwordMeter = '<div id="password-strength"><div class="password-strength-title">' + translate.strengthTitle + '</div><div id="password-indicator"><div id="indicator"></div><div id="label"</div></div>';

Looks like a broken div in there Mike.

This review is powered by Dreditor.

Thanks. I didn't notice the html error in patch password_colouring_00.patch which I was working from.

It's fixed now (and still works).

We can do the text, but I see no reason at all to do all the colors.

I think we definitely need the text. If we do the colours there should be a easy, and documented, way for themers to override the colours.

Please see #2, drop the colors, and just go with the text.

@Everett #38 that it should be easy, and documented should already be implied in any way we go.

The attached patch adds only the password strength label, and does not modify anything to do with coloring.

Subscribing. Oh, we desperately need more information in the handbook on evaluating color contrast.

@Everett - that patch didn't work for coloring & positioning issues.

I like the red, and would much rather go with #36. However, if folks aren't sure about the red and want to stick with the existing green and add in the text I'd like to offer the following.

The shades of green change, but think it gets the point across nicely without worrying about what the colors mean.

I still prefer the colour option discussed in #11 the best. I changed the js so it would just show the 3 colors. Red for weak passwords, yellow for fair ones and green for strong ones.

The text is there so that if your colour bland this should be fine.

I've also upped the definition of a strong password.

6 characters and one capital is not a strong password! Now you have to hit 85% in order to get a nice green password. So yes, you have to use a number or something like that.

Mike, once again trying to participate in several threads at once has me finishing a post after the discussion has moved on. Gotta stop doing that.

I'm glad that you went back to the color scheme in #11. The "red-yellow-green" metaphor to traffic signals is clean and works well for everyone who can distinguish those colors, regardless of whether they can see the true hues. The text is essential, so it's fantastic that it's there.

Here's my original post, which I won't edit because it makes other strong and valid points:
Reading through this thread, I see that the verdict on color has gone back and forth. I have a lot more confidence in sites that use color and text to encourage me to develop a strong password. I'll bet most other Web users do, too.

The text is essential. The color is an enhancement. One caveat: If color is used, check it with one of the many free color contrast analysis tools available online. If used as a background, make sure it is light enough that it doesn't reduce the contrast ratio with the text below 4.5:1 — preferably closer to 7:1. (In these patches, the text seems to be running small.) And if the color is used for text, be sure that it is dark enough that its contrast ratio to the background is in that same range.

Otherwise, a lot of us will be relying on screen readers to operate this interface. (Oh, by the way — because the color is an enhancement, Everett's idea of making sure it can be turned off is a good one. Ideally, not only any themer but also anyone who manages a site should be able to flip that switch.)

I don't know how to turn off the colors. Right now it's in green. Having a tricolor set is fairly standard. Like the idea of having it be more customizable, but think I'm going to have to leave this to someone else.

I did test to see that this will work in alternate languages. It does.

I had to blow away the old install, but there's an example of this here now http://drupal7.dev.openconcept.ca/

@mgifford

Can you please let me know what exactly wasn't working properly in the patch in comment #40? I hink we need to get this commited with just the label, and then we can work on the coloring issue if people are interested.

@Everett

About 2/3rds of the screen was green with patch #40. It started right below the password strength checker and went down the rest of the page. I also think the position of the text was wrong, but that might have been a result of the big green background colour.

Who were the people who didn't like the colour? I am not sure which concerns we're addressing by not having more than one colour. Could all be grey I suppose, but right now it's solid green. Think for sighted people Red/Yellow/Green is good. For color blind folks there's the text which is pretty clear as well.

For what it's worth, patch #43 is way cooler than this one.

However, if folks like it solid green rather than red, yellow, green there's this patch too.

Strong is now at 85%

+1 The patch in #48 applies well and provides a textual alternative to the green bar for password strength.

@ mgifford: The only resistance to color AFAIK was from Bojhan. For usability for sighted people, I think the traffic signal metaphor is the best. Green means "go," so don't show it to me until you really mean that. As webchick notes in #3, the usability test participants were thrown off by an overwhelming block of color. This patch provides appropriate enhancement, not an overwhelming block. Everything else I have to say, I've said before. Can we mark this RTBC and move forward with the red-yellow-green approach?

Can anyone apply the last patch, to me it doesn't seem to work well. I am not opposing red-yellow-green approach. I just don't feel we should promote jumpy behavior? It takes a second for someone to fill out their password, I don't want a rainbow effect when I fill out my password.

Re: #51, perhaps we should wait till the user stops typing for half a second (or so) to do the magic?

If someone wants to user-test this should I test both #43 and #48?

FYI: This patch added to list of *hot* issues which need user testing.
http://groups.drupal.org/node/26409

I made videos of two of the options. Hard to tell what consensus is built on this issue at this stage (turning into bike shed?). Thought making videos could help others participate in the discussion w/o needing to apply patches.

#43 password_colouring_04.patch
Video: http://vimeo.com/6546823

#48 password_strength_label_02.patch
Vimeo: http://vimeo.com/6546877

I think the 3 colours changing is confusing. However, it doesn't make sense that it is 'green' to go a the start. Would it be possible to go from pale to brighter through the progress bar?

I made a palette to show, just a rough sketch, I didn't work out the values.
http://www.colourlovers.com/palette/954704/Go_green_go

Thanks for the videos, Heather. That's a great idea! This will help our discussion quite a bit.

#43 reflects the consensus as I understand it. From my experience, it seems to be the way true password checkers are being set up.

Ok, I've got a patch for your Go green go palette. I still like #43 the best and don't find it confusing.

One issue of having 4 colors of green is that there are only 3 text labels for those levels of security.

If we want four colors we need better labels than weak, fair & strong.

Right now there are four conditions I've defined here that should go with 4 labels: Under 30%, under 60%, under 85% & everything else.

I'd like some feedback on that.

heh, vimeo said this file was too small

http://www.flickr.com/photos/feather/3920537107/

@mgifford you're right. i wasn't paying close enough attention to the issue when i made a 4 colour palette.

thank you for making this patch.

now we can see the grey/pale option. i agree. the pale green is even too green/positive and misleading. red to yellow to green seems much beter.

another kink: at installation shouldn't the list of recommendations be available? they do not appear at installation. the password check you see in this video is for installation.

Mike, I would make one more suggestion: In the video, the color band gets wider, taking up more of the box, as more characters are entered. I would get rid of that aspect: Just make the whole box red while "weak" is displayed, yellow while "fair" is displayed, and green when "strong" is displayed. Otherwise, I think we're ready to move on.

@heather can you give me a 3 color gray palette to work from? Think that would be easier than 4 unless we want to deal with the weak, fair, strong issue I posted last time. Keeping in mind that it has to be light enough to see the text under it and also hopefully meet a minimum color contrast so that it is visible. Might be good to match the color of the text for weak, fair, strong against against the backgrounds proposed here:
http://www.dasplankton.de/ContrastA/

@cliff It's easy to apply that. Just want to make sure I'm creating patches that help get us closer to getting this RTBC. Can we get a usability comment on whether or not we should get rid of the progressive element (the percentage bar) for this?

@mike, it's hard to be sure what is meant by the changing size of the bar. The metaphor is to traffic lights. Traffic lights typically change color, not size, so the changing size of the bar muddles the metaphor. and weakens the message.

On top of that, what does the changing size mean? Here are a couple of plausible misinterpretations:

• Because a two-character password produces patch of red twice as big as the patch produced by a one-character password, a two-character password is twice as bad as a one-character password.
• At about five characters, the color is yellow. Is a 5-em "caution" more emphatic than a 1-em "stop"?

So the implication of the change in size is the opposite of the implication of the change in color — at least it is until we get to green.

Here's another way of thinking about it:

• Red means "Don't proceed."
• When only one character has been entered, we especially don't want the person to proceed.
• Currently, the signal that person gets is the smallest in our series, so it's possible that they'll miss it.
• If we keep the signal the same size and change only its color, we don't have to worry about whether they will miss it when its message is most urgent.

I see only one drawback to making all signals the same size: The user would not get the idea that a password with a strength factor of 85 is not quite as good as a password with a strength factor of 100. If that troubles you, I suggest we just keep the bar yellow at 85. For it to turn green, the strength factor would have to reach 100 (or whatever other value you consider prudent).

Ok, here's another one for review. Based on @Cliff's suggestion of the bar being 100% full. I still like #43.

Slight changes include actually including 4 states. As soon as someone clicks in the box they shouldn't be getting an error message.

Not actually sure that a big red box is what most folks want to see when they type in their password.

I didn't bold the text. Not actually sure how to do it. The 0th state (before someone types in a password) should probably have the text "none" or something like that but currently it isn't showing up.

The red's too dark and I did try to tone it down a bit to make it easier to read.

A Story About a Bike-shed

• #1 - webchick suggests that password checker "green from start" is confusing. (all green start to finish)
• #4 says go from grey to green
• #7 does it exactly like google's, with the metre to the site
• #8 points out needs testing with RTL
• #9, #10 it gets tested it's OK
• #11 shows microsoft's convention (what was wrong with the google convention??)
• #12 dries said "close, but work on colors"
• #13-19 - discussion of colour, now washes out colours. still google.
• #23 - suddenly it moves to "under" the password checker? no explanation for this change
• #25 webchick overwhelmed by colours. but she is talking about a big, like in #26 (to do with tabbing & colour change when password is deleted/changed, it doesn't go back to red)
• #33- 36 fixes bugs
• #37-39 bojhan doesn't like "all the colours". suggests going back to drop the colours, and just go with text.
• #40, ok, remove colours, just try text.
• #42-43 no, i like the red, but we'll try green again. trying just a change of green. (for readers, this means we are back to the situation at #1, which is why the thread started)
• #48 try solid green. (no progress bar)
• #51 we've gone back, red-yellow-green is good... but... feels "jumpy"
• #53-58 ok, this is my fault, i suggest the light green to green option. (discussed in #4)
• #60 based on #59 - Bar 100% full

Let's re-cap the goals: To encourage the user to create a strong password.

First, look at existing conventions in use in the industry. Over time, more people will become familiar with this functionality as thoughtful developers include password checking. It's good to work within the existing UI conventions and establish a common language for users.

• See someone who attempted as many experiments (full bar, temperature bar, filling bar. but always with colour changes):
  http://subeesh.wordpress.com/2008/02/19/flex-password-strength-meter/ - you can resize the bar and compare as many.
• Some photos of patterns here: http://ui-patterns.com/userset/39/image/553#focus
• Also check a video I made of Google's password checker:
  http://www.flickr.com/photos/feather/3921759419/

You can see those shown are "long"; the text is above the bar, not written on it; the colour bar is a thin strip.

Let's reconfirm our spec:

• 1) We need a progress bar
• 2) Green from start is confusing.
• 3) The colour changes should not be so jarring.
• 4) Text should be legible and transmit same information as colour/visual changes.
• 5) It needs to work in translation so that words can fit into the space in other languages

This indicates text above the bar, not on it, and a thin strip of colour so as not to be over powering.

In fact we were closer in the beginning of this patch to existing conventions

http://drupal.org/files/issues/password-strength-meter.png

Somehow we tried to make the progress bar "small", and fit the text together. This appears to have introduced some problems. We may also run into trouble if translations are not as short and don't fit into the bar.

I recommend we take a step back from making and applying patches, try out this experimentation page:

http://subeesh.wordpress.com/2008/02/19/flex-password-strength-meter/

And come to a consensus to save valuable developer's time.

@heather great post. :)

What do you all think about going the route of the first example at http://subeesh.wordpress.com/2008/02/19/flex-password-strength-meter/ ...you get all the colors but it's not as jarring since it's a gradual fade.

http://drupal.org/files/issues/password-strength-meter.png - first response: YUK! ugly! too wide!

I'd say, use http://drupal.org/files/issues/Picture%209_12.png style, but from grey to green!

@heather - love the history you laid out for this bike shed.

Think the most critical part is that we're adding the password strength label as per #40.

Also, thanks for pointing out that the password changer suddenly went from a Google style password checker to something more unique to Drupal.

I'd like to take it back to the Google style so I started with #17.

I added a reference for Good so that there are now four categories. Google actually has a 5th for too short - http://ui-patterns.com/userset/39/image/150#focus

I wasn't able to do that with the present scoring. It would have taken a lot more adjustments to organize that.

@alexanderpas - the biggest problem I have with the style you prefer is readability. It's something I was struggling with in putting the dark warning behind the text. There's not enough contrast for many people.

@mcrittenden - putting in background images rather than colors would be the easy fix. Would that work for you? Does anyone have any examples of graphics to use for this?

Oh yea, trying to follow @heather's lead here are some videos:

This is for patch in comment #60:
http://screenr.com/fh7

And finally for patch in comment #64 above:
http://screenr.com/Dg7

Would be great to have folks contributing more patches or addressing some of the issues directly. One person's ugly is another person's beautiful some of the time, so suggesting a new stating personal preferences isn't going to get this issue RTBC any time soon.

I definitely understand the importance of using appropriate colors for the password indicator bar.

However, as #521904: Add ARIA live region to password strength and match containers is blocked by not having a text label that describes the password strength, perhaps we could resolve the current issue with two commits.

1. A committed patch to add a text label.

2. A committed patch to modify the coloring of the password indicator bar.

@Mike, both are good. Even though the checker in the video based on #60 was what I asked for, I see the merits of and actually prefer the checker in the video based on #64. I don't think we need a "Too Short" state. (In fact, I'm not sure "Good" is necessary, but I wouldn't call for a recode to get rid of it. People will understand.)

@Everett, both versions have text labels that correspond to specific colors, so I think we are OK there.

@Heather, thanks for the summation. In the frenzy of fixing things, it can be hard to stay focused on the goal. And moving the color bar from behind the text and to the side actually does make it look like a progress meter, not a traffic signal. I can't explain why, but it does. In that light, allowing it to grow is just fine.

I think that anything further is gilding (or perhaps bronzing) the lily. Let's call it done. Fine job, all around!

@Heather: awesome ^^

Just getting back now, will take a look at this soon.

Ok, this might be a bit simpler. It's exactly the same as in #64 (my current favourite is password_colouring_06.patch) except I've removed the colour changes.

This patch has all the positioning & style of the much earlier patch in comment #17. It's got the Weak, Fair, Good & Strong distinctions used in Google.

The goal here is to get the text into core so that we can start adding ARIA support based on the text we've agreed upon as specified in comment #66.

For @Everett's patch to add support for screen readers we don't need to have firm definitions of what happens under the hood (how we calculate that text) or what colors we use to indicate how good a user's done of defining a password. That can all change if need be.

However, not getting this text into core is holding up other development and real accessibility!

When this gets in we can then worry about bringing this stuff back in (with whatever modifications are required for maximum usability:

53         // Adjust the length of the strength indicator.
54         $('#indicator').css('width', result.strength + '%');
55         // $("#indicator").css('background-color', result.indicatorColor);
56 
57         // Update the strength indication text
58         $("#password-strength-text").html(result.indicatorText);
59         // $("#password-strength-text").css('color', result.indicatorColor);


164    if (strength < 60) {
165     indicatorText = translate.weak;
166     // indicatorColor = '#bb5555';
167   } else if (strength < 70) {
168     indicatorText = translate.fair;
169     // indicatorColor = '#bbbb55';
170   } else if (strength < 80) {
171     indicatorText = translate.good;
172     // indicatorColor = '#4863a0';
173   } else if (strength < 100) {
174     indicatorText = translate.strong;
175     // indicatorColor = '#47C965';
176   }

176   // return { strength: strength, message: msg, indicatorText: indicatorText    , indicatorColor: indicatorColor };
177   return { strength: strength, message: msg, indicatorText: indicatorText }

subscribe

The patch in #69 worked nicely...text cues and visuals both look good.

Incidentally, how easy is it to change the colors/text etc? I'm not sold that it's a necessity at least at first, just curious.

Glad you liked it. What do we need to move this to RTBC?

Text is in both the PHP & Javascript. There's no easy way to over-ride either that I know of. Adding new elements would be difficult too.

The colors are all in the user.js file so it would be simpler than modifying the text.

I can see a solution (for the coloring) that might be more flexible. We could just have the CSS reference background graphics in the theme that could be over-ridden. Would take some experimentation though.

I'm not sure that there's energy here though to push through a patch that is as flexible as this for D7.

I don't think we need to worry with flexibility here. Let's get it in first. A couple code review changes that need to happen (note that this is the first patch I've reviewed from this issue so I apologize if some of this was discussed earlier):

Two comments need periods at the end:

// Update the strength indication text

and...

// Based on the strength, work out what text/color should be shown by the password strength meter

Why is this line commented out instead of just removed?:

// if (indicatorText == translate.sameAsUsername2 || indicatorText == translate.tooShort2) {

What's the deal here (i.e., why is there a need for two different tooShort's)?:

         'tooShort' => t('Make it at least 6 characters'),
+        'tooShort2' => t('Too short'),

Once those changes are made, I'd be ok RTBC'ing.

Good points. I've got them all in this latest patch.

I dropped the reference to color here too as in this patch there are no color changes.

The tooShort2 was when I was trying to exactly emulate Google. I don't think it's needed though. Or if it is would require a lot more work to get the logic right. Thanks for pointing out the old code (which I've now eliminated).

Thanks!

Totally done with this issue, copy-c / copy-v of google's interface - will probably cause us more design community harm then we want - but meh, Drupal has no brand with these kind of issues, only consensus driven discussion.

@Bojhan

Are you willing to provide a patch or even a sketch for what you want?

I've rolled lots of patches for this issue as I think that what we've got now is very weak for everyone's accessibility. What's there now is much better than what we've had previously. It's also stronger than what was proposed with the changes brought in with comment #23.

Please tell me what you're going to do to move this issue forward.

I'll stick it back at needs review until Bohjan gives us something. No point in keeping it at CNW when nobody knows what needs to be worked on.

Ohh, didn't mean to change status.

There is no point discussing the impact it will have on the Drupal brand in terms of design, since people don't seem to care about that (that was my whole point). It won't be addressed by an image or a sketch, its a conceptual direction we either agree on or just ignore.

But if you need a accessibility/usability point, if we do a copy-c, copy-v at least do it correct and implement the four colors.

I think this is a step forward. Committed to CVS HEAD. Feel free to follow-up with the extra color coding -- I think that would be nice. Just re-open the issue.

That's great news. I've added the colour back in here with this patch.

Oh ya. I had to set this as needs review for the colour.

Also, wanted to note that I changed a quote to single quotes from double. Not sure what's the best for javascript and if there is any style or performance reasons for choosing one vs the other.

After testing, I'm ok with leaving it as-is. As Bohjan said (somewhere in this thread) you see a little bit of green and want to make more of it. I don't necessary see green and think "good" here. I see green and think "needs to be more".

Bojhan, I really don't understand the rationale for four colors. Just because Google does it doesn't mean it makes sense. As I said before, the analogy to traffic signals is understood everywhere there is enough traffic to have signals — and many places where there isn't, because railroads use the same convention.

If having four colors will get this done, then, fine, let's have four colors. But I don't understand why you've decided that I and others involved in this discussion have no concern for "the Drupal brand."

If the Drupal brand was so important to you, why did you wait until just four days ago to bring it up — comment #76 — when this issue has been around for over 10 months? I really would have been happy to consider that point, and I'm sure others would have been, too.

It's not that we don't care. It's just that we hadn't thought about it from that perspective. Had the suggestion come up earlier, perhaps one of us would have thought of a way to make the Druplicon look weak, fair, pretty good, and then as strong as Superman, and Mike could have written code to support that model. And maybe the result would have worked for all of us — and maybe not, but at least we could have had the discussion (and Mike would have had more of an opportunity to respond to your request).

Please, in the future, if something really does matter to you, get it out into the discussion early. Don't ambush the rest of us with a new thought at the end.

Cliff: comment #2 by bojhan makes similar points. It's not an ambush. Bojhan speaks from experience in seeing people *stumble only a little bit* over the password checker during usability tests. Most of this was fixed in another issue, explicitly leaving the colors out of the discussion because they don't really matter that much in the total of this specific interaction. Then this issue got created and look here, we're almost 100 comments in, talking about which color to paint the bikeshed. Sure, with accessability improvements committed along the way, but still going on about picking colors.

What we're trying to argue here is that we should try and make our own choices, *not* copy google or others because the context in which this interaction happens is so different. Here it's part of a much longer installation process, most other examples given here are part of a much shorter and simpler signup. I guess Bojhan's last comment was cynical in the sense of "if we don't dare to make our own informed choices, then be sure to go all the way in copying".

It's fixing things that are not broken. See #83, which is feedback from actual usage for example. It's just frustrating to see so much energy being put into what's mostly a non-isssue based on assumptions rather then actual usability testing.

And I guess it's equally hard to tell who's who and who knows what they are talking about from just reading comments, but yeah, that's the issue queue for ya.

[Edit : yoroy said it all]

@Cliff Sorry I just didn't have the strength anymore, to get in earlier - I missed that we reached consensus so I didn't put in my voice earlier.

oops

@yoroy and @Bojhan: Perhaps one day we can swap stories and share a few laughs over an appropriate beverage. I hope so. Still, I stand by my earlier comments. In #2, Bojhan does not mention anything about Drupal branding. Not even a hint. And to the extent that he's expressing concern about the usability test results, I think webchick in #3 quite clearly refuted his notion that the use of color was the actual source of the problem.

I, for one, have never seen Google's password checker. Everything I contributed came from the experience and professional judgment I've developed in years of Web design, Web redesign (!), and usability testing. So, although the "red-yellow-green" color scheme might not have been creative or even original, it would have been effective, and the suggestion that those who participated in this issue simply aped Google was completely out of line.

The well-designed small patch of red in the recent patches is a far cry from the big, ugly, obtrusive, and, coincidentally, red error message that triggered the problems in the usability test. I agree wholeheartedly with the point I hear from webchick in #3: It's important to incorporate testing by potential users into the design process, but it's even more important to be sure we identify and fix the actual source of each significant problem that process identifies.

In this case, the right answer was to replace something that was big, ugly, and obtrusive with something elegant — not to get rid of the color.

@Heather suggested a palette in #53. Might be others to explore too. There are four places to add color if we want it to. lighter to darker green is one option. Red, Orange, Yellow, Green would be another.

There are other common examples other than Google like say http://www.geekandproud.net/terror/ (a parody on the homeland security warning system)

Not sure that this is really closed. Right now the bar's all green still and this is the last phase to evaluate it.

Mike

Mike, the only problem with the scale used by http://www.geekandproud.net/terror/ is color contrast. No two adjacent pairs have sufficient contrast to pass at level AAA; only one of the pairs passed at level AA for large text (which I assume would be similar to any bar used).

Keeping in mind that people who use the Web spend far more time on other sites than they do on yours, let's go with Google's palette. That will keep things simple and familiar.

Unless someone wants to come up with five different versions of the Druplicon, ranging from anemic to robustly healthy, to use in place of a progress bar, and can do so in less than three weeks, I don't see a way of making everyone happy.

I don't know of a way to pass variables from a theme's .info file into jQuery. There very well might be a way to do this in which case it is something that could be over-ridden so that you could have a choice of color schemes to work from.

Maybe we have to wait till we can get something more customizable.

Mike

It doesn't look like we're going to be able to get consensus on color options on this for D7. For D8 though we're going to have to figure out how we deal with color. I've outlined in this issue some other places where it is a problem:

#660576: Ensuring Proper Color Contrast for Garland

subscribe

#81: just_colouring_01.patch queued for re-testing.

Can this be brought into D7 using the Accessible Helper Module?

There must be a way to override the functions in modules/user/user.js to add color without hacking core...

Pulling from #383032: Option to load js library files from Google repository I thought I'd answer my own question here:

function ADMIN_THEME_js_alter(&$javascript) {
  // Swap out jQuery to use .
  $javascript['modules/user/user.js']['data'] = path_to_theme() . '/js/custom_user.js';
}

Which could be just usual user.js with this patch - http://drupal.org/files/issues/just_colouring_01.patch

On that note. This seems like it should work:

        // Adjust the length and color of the strength indicator.
        $(innerWrapper).find('.indicator').css({'background-color' : result.indicatorColor, 'width' : result.strength + '%'});

        // Update the strength and color of the indication text.
        $(innerWrapper).find('.password-strength-text').html(result.indicatorText);
        $(innerWrapper).find('.password-strength-text').css('color', result.indicatorColor);

With this:

  // Based on the strength, work out what text should be shown by the password strength meter.
  if (strength < 60) {
    indicatorText = translate.weak;
    indicatorColor = '#bb5555';
  } else if (strength < 70) {
    indicatorText = translate.fair;
    indicatorColor = '#bbbb55';
  } else if (strength < 80) {
    indicatorText = translate.good;
    indicatorColor = '#4863a0';
  } else if (strength <= 100) {
    indicatorText = translate.strong;
    indicatorColor = '#47C965';
  }

But it doesn't seem to, but not sure why.

Updating patch in #81.

Reading user.js makes me cry inside.

There were two leaking vars here, and put the c in the last indicatorColor in lowercase, there is an issue for lowercasing every color. Also shouldn't the colors be in Drupal.settings or something? no way to overwrite them right now.

I'd like to put this as NW and refactor the JS so that it's all shinny and clean but at 102 comments that wouldn't be very nice. I'll open a follow up issue for the clean-up.

Excellent! Thanks for the new patch. Please let us know where the new issue is to clean up user.js when you start it.

If we can bring in the colors here I'm happy to set up a new issue to define them in Drupal.settings

That too would be a bigger issue than simply trying to enhance the text around the password text.

Nothing new to review

I've attached a screenshot after applying this to a fresh D8 install. Looks great. I'd say it's ready to RTBC. Especially since it's already gone through quite a lot of review.

@nod_ let us know where your new issue is.

Looks good. Committed/pushed to 8.x.

No, sorry, I was testing an plugin that I wrote for drupal. It's a sentiment analysis plugin, I didn't mean to save the comments.

rzilouc2; Are you a spammer?