Discuss redesign registration to accomodate secondary email

[ryanfeeley]

Adding secondary email to registration gives us the opportunity to give password creation its own page. Something like this:

Questions:

• Is this something we can experiment to measure the impact on user adoption, retention and password strength?
• When is the right time to get the user to verify their secondary email? After they verify their primary seems like the right time to me.
• Can we experiment with putting the Choose What To Sync screen before and after these screens?
• Can we include a password strength indicator that leverages our existing bloom filter? What would it look like. 4 bars?
• How can we prevent saying a password is strong when other parts of our validation reject it?

[ryanfeeley]

NOTES:

• Should probably include the success message with the primary email and mistyped? link

[shane-tomlinson]

First off, I think moving the "password" field to it's own page is the right thing to do so that we have the flexibility to implement password entry improvements. That said, I have reservations about the design/copy on both pages.

On the signup page, asking a user to enter not just one but 2 emails on signup muddles the signup process. The "Optional" text on the end of the label is almost an afterthought, I missed it three times. If I scanned the page and thought two emails were required, on any other site I'd say "screw you, I don't like giving one email address let alone two, I'm not signing up." I also worry that asking for two emails on signup breaks the logical order of the signup flow, some users are going to think "I have to verify both of these addresses to sign up." Finally, the signup page now contains so much text I don't know what to look at, or what's important. It's too much.

The password page is much better and I think is going to help users remember their password, ensure they typed the correct password to begin with.

Starting at the top, the text is too long. "for syncing Firefox data" is information that the user doesn't need to care about, it's a technical detail.

Further down, the "repeat password" field is confusing, it implies the user should keep typing the password over and over again. I'm not sure what the behavior is supposed to be with that field. Is the password deleted whenever it's typed correctly so that it can be typed again? Do we verify the passwords are the same?

The overall layout seems a bit confused to me, I understand what you are trying to do with the text between the two fields, but I think that text can be just as effective below the two password fields, and shortened a bit. Adding "reset it to" doesn't really add anything to the statement and can be removed.

Here's a simpler version that to me conveys the same info that's a bit simpler to grok:

I had to reset my Facebook password recently, here's the info they present to the user:

Maybe we can use it for inspiration.

[ryanfeeley]

@shane-tomlinson I'm working on something like LastPass does. A balloon when browser is wide, and inline when narrow. Similar messaging (but not the same) with a strength indicator below.

[vladikoff]

Let's reopen this if there are still plans to work on this