Design the user flow for sign up/ login

[iamjessklein]

@stenington and I took a stab at this, iterating on the work that @andrewhayward already incorporated into http://csol-wireframes.herokuapp.com/

After researching ( http://dl.dropbox.com/u/52395152/coppa.pdf) we came up with a list of common elements for this kind of work:

• choose a fake name
• choose an avatar
• create a password
• first name + last name (optional)
• guardian's email (parent or coach)
• birth date
• agreeing to terms and conditions
• confirmation email

Ultimately this is the flow that we came up with:

Minimal Sign Up flow (with Persona):

1. Choose learner or coach/guardian/parental unit

2. (a) If signing up for learner account:

   • present birthdate selector
   • user enters birthdate

   • if < 13:

     1. present username box (username maker) and parental email box
     2. completes and guardian is sent email - email instructs them to follow the workflow for signing up with persona for a guardian account to manage the child account, link to guardian login (we'll need separate guardian log in)
     3. user is logged in and able to do stuff? or has to wait for guardian to approve? not sure.

     *if > 13:

     1. present persona login button
     2. if creating persona account- users are given a prompt from persona to check their email for a confirmation. Confirmation Email says : blah blah redirecting in 5... or they have a shim and are logged in automatically on the site. user returns back to CSOL site after using persona and is signed in
     3. if they have a persona account - user signs in.

Notes: Persona alternatives? IF we wanted to offer alternatives to Persona as well. Any service that provides the site with the user's email address would work. we could offer it for >13s and guardians. The email would become the email that is required for badge issuance/the email that an <13 reported as their guardian's email

Devil's Advocate: if we're storing usernames, passwords and a guardian email address for < 13s. why not store username, passwords and user email for >13s and guardians? i.e. why use persona at all?

The next step here would probably be to wireframe this one out and then @cmcavoy can run it by legal.

[stenington]

Additional notes from today:

Since we have to build custom login for < 13s, it should be offered for the other types of users as well. Persona can be an option too.

The data to collect from students:

• first name + last name (optional)
• email (optional for < 13, but they have CPS email addresses that would be helpful to collect)
• birth date
• possible: student id #

Additional user types:

• admin user (MoFos)
  • data entry of program descriptions, etc.
  • set up mentors
• mentors
  • online evaluators
  • see list of submissions to approve/deny, maybe with a comment
  • offline evaluators
  • generate claim codes
  • submit email addresses for badge earners

Parental permission guidelines:

• <13 can create account, log in, begin to claim badges
• until a parent approves, we'll block them seeing their earned badges behind a "get parental approval" message
• parents are approving the child's account overall (not each badge)
  • should have a "child's activity" feed
  • should have the ability to disable child account

[iamjessklein]

As per our conversation on vidyo this morning, I am assigning this to @andrewhayward to take a stab at making a clickable version of this user flow.

[andrewhayward]

This is now deployed to the sandbox.

[threeqube]

@andrewhayward In the parent sign up option, is the parent signing their kid up for them?

[chloeatplay]

@iamjessklein @threeqube @andrewhayward Following up on Friday's stand-up // I am adding the flow for using a parent sign-in process as requested. It is following 100% the DIY model. I have included screenshots.

1.Choose an Avatar (include warning "please don't use a photo of yourself" )

1. Choose a Username (DIY provides a name already, you can push the handle to get a random username, it also strongly urges you to "please don't use your real name"

3.Enter your parents email address + a password (DIY provides a password already, that you can edit)

1. View series of tutorial pages
2. Parent gets verification email which includes verification link and info about DIY

6.Parent clicks on verification link that leads to "Activate Parent Account" page 7.Parent clicks on the sign option

8. Parent views "parent page", which includes section of "My kids"

-the end.

[andrewhayward]

@threeqube My thinking was that would be two routes for parents, that ultimately converge:

1. Kid signs up, adds parent's email address, parent gets link to follow, which is essentially a link to [2] with some sort of token
2. Parent goes directly to sign-up page, entering their email address and sorting out a password

Seems like I missed a bit out though, looking back at it, so it's not actually implemented how I had it in my head :(

[iamjessklein]

@andrewhayward that is correct. This would mean that you would also get rid of the hyperlink on the sign in/up window for parents to sign up. Correct?

[threeqube]

@andrewhayward and @iamjessklein Can we check back up on how log in user flow for < 13 and > 13 will work? We need to create copy around it.

[threeqube]

c.f. lego magazine email notification to parent:

[iamjessklein]

:icecream: that is a great reference. Yes lets loop back on this.

[iamjessklein]

Here is the user flow for sign up:

@andrewhayward note that there are a few slight changes based on the conversations with our legal team in terms of requirements. I still need to mock up the sign up for parents. This flow takes into account the need for email notifications, however, does not provide the design for them.

[threeqube]

:+1:

[cmcavoy]

there's email pieces to do, but otherwise this is done.