users not remembering account name

[TimCliff]

It is a frequent occurrence where the user gets their email to activate their account, and then after they create the account - they don't remember the username that they used when they applied.

[TimCliff]

This could potentially be resolved by the changes being discussed in https://github.com/steemit/faucet/issues/220

[Jolly-Pirate]

I have helped over a dozen users with that issue today. Luckily we were able to retrieve their account name. Would be a good idea to send them the account name by email as @TimCliff suggested.

[Connorsmith93]

Definitely need to include some account name feedback during account creation.

There's too long a time frame between sign-up and then account creation and people will forget. Or at least warning the user during sign up that they need to write down their account name as it won't be provided again.

[Jolly-Pirate]

Not only that, I had two users who made a typo when they submitted their signup. So they were trying to login with the wrong account name.

[officiallymarky]

I've been contacted a lot lately about this.

[Jolly-Pirate]

Send them in my direction on the chat.

[pkattera]

@Jolly-Pirate @TimCliff A few things we could do:

• Repeat the user's chosen account name on the remaining signup screens (this will help to make sure there wasn't a typo)
• Include the user's account name within the email when their account is approved – are there any security issues around this @sneak
• After they click on the approval email link, we could pre-populate their desired account name before they create an password to finish account creation.

Thoughts?

[TimCliff]

All of those sound like good options. The email is probably the best solution, as it gives the user a permanent record of it.

[bonustrack]

Related #220

[bonustrack]

We can add a "Welcome back @username" message when user open the step 2.

The issue where the user don't remember his username from step 1 (before approval) can be covered by #220 proposal.

[Jolly-Pirate]

@pkattera all your proposals sound good. And if there are security concerns about sending the username in an email, maybe you can send it as an image instead of plain text.

[sneak]

Why do we need to email them their account name? The approval link uniquely identifies them. They shouldn’t be prompted for it again except to confirm.

[TimCliff]

Users receive the approval link, successfully activate their account, and then don’t know their username when they are prompted to login.

[sneak]

Maybe we should generate pubkeys for them when they choose their username. Then when they are approved, we prompt them for both chosen username and chosen password, and if they can’t provide both, don’t make an account for them.

[originated]

@pkattera could you please add a finalized checklist of approved items you'd like to handle this issue? Thanks!

[gl2748]

Right now, after the work for #220 we state the username after they have confirmed their email. One remaining step would be to simply state the username again once they have confirmed the SMS code. For the time being we will not state the username on email.

[sneak]

Seeing as the username they chose is just a proposed choice (and not real until their account is actually created), why not just prepopulate it on the final step after approval, and give them another opportunity to edit it before the actual creation? Nothing requires them to create with the same proposed username after approval as they chose in step 1 (which is only step 1 to increase stickiness and emotional investment in the process).

[pkattera]

I agree with sneak here. Let's continue to state the username after email confirmation (it's a nice, light bit of personalization). No need to continue including it on the SMS code confirmation screen or within the email.

Then, let's change the account creation screen from this:

To this:

Main changes

• New heading 'Finish account set up' (instead of it only being about the password).
• Include editable text field pre-populated with the person's desired username
• Form labels which are placed above the form field. Unfortunately, this is a new pattern within the sign up, but it's necessary in order to show both inputs on this screen.
• Reduced visual weight of the 'Generate new key' button.
• Changing the terminology from password to 'Master Private Key'.

Sidenote: @sneak this screen currently uses the term 'Password'. I'd like to use the term 'Master Private Key' on this page and across Steemit.com. Thoughts?

[jnordberg]

Something to bear in mind is that allowing the username to be changed after approval excludes it from being a variable used in the approval process

[sneak]

It’s not a private key, and we should not call it that as a result. I don’t object to changing it from “password”, but it isn’t a private key.

[pkattera]

@jnordberg Do you mean, we won't be able to use the username someone selects as a signal for whether the account is approved or not?

@sneak How about 'Master password'?

[jnordberg]

@pkattera Yes

[pkattera]

Updated design.

The goal of this change is to remind people of their selected username (not to give them the ability to re-edit and change their username). Let's just display their username in a disabled, locked field to remind them.

Notes:

• To avoid confusion with the 'lock' icons, please replace the 'lock' glyph with the 'key' glyph that is already contained in the icon font for the password field. This icon should also be updated in the next screen where the user is asked to confirm their password.
• I'm now using the term 'Master password' for this screen. We'll also need to update this elsewhere in condenser.

Updated hint text:

We've generated a a highly secure Master password for you. Please copy it and store it in a safe place offline, like on a text file on a USB drive.

[Jolly-Pirate]

The UI design is problematic as it doesn't show the full password https://github.com/steemit/faucet/issues/266

[pkattera]

I agree with @Jolly-Pirate

For this ticket though, let's just add the username part and deal with the password issue in #266.