Sign In Flow — to code (depreciated)

[mkhandekar]

We discussed and iterated through the sign in flow in #617. Here are the screens to be coded for the sign in flow by @juliaelman & @harrisj. Sketch files are here.

• @mkhandekar @esgoodman determines how to best to make integrators aware of style recommendations for login modals.
• @mkhandekar @esgoodman create new layouts for step one of sign in flow, as it is needing more research
• @harrisj adding custom "Why?" text to permissions pages, see Integrators should provide custom explanations why they are requesting scopes from the user #675 [Backlogged]
• @harrisj determines whether new routes need to be created for step by step registration process
• @harrisj figuring out how to display routes in development without need to run separate omniauth client locally
• @juliaelman styling permissions page with new "Why?" text, modals and text changes.
• @juliaelman adding new header and disclaimer to top page
• @juliaelman creating new "step by step" styles per the wireframes

Logging in at Integrator Site

Prior to arriving at MyUSA

Choose MyUSA or via email / external IdP

User chooses to log in via email

Begin Registration / Log in at MyUSA

User chooses to log in via MyUSA. These are the log in and make an account screens (these are two different screens, see the following image for interaction)

How the log in and make an account screens work

Check email

User get's a notice saying they need to check their email for the access link

User checks their email address, and clicks on Access Link

Permissions

User sets permissions
This is when none of the toggles are selected "yes".

This is when one or some of the toggles are selected "yes". Note the explanation text below "Continue Sign In" changes.

"Why?" button hover

User clicks on "Why?" to see explanatory modal

Logged in

User is logged into integrator website

Logging in at MyUSA (after logging in at Integrator site first)

User chooses to log in via MyUSA. These are the log in and make an account screens (these are two different screens, see the above image for interaction)

Check email

User get's a notice saying they need to check their email for the access link

User checks their email address, and clicks on Access Link

Account management

At subsequent log ins, user is taken to their dashboard/account management. Permissions page is skipped (this is account management work. nothing needs to be coded on this screen yet, just want you to know where the access link leads to.)

[harrisj]

Here's a look at the Routes that currently exist and associated views that would have to be edited:

1. The email signin for MyUSA (not to be confused with email/password signin for application) form is rendered by the sessions_controller#new method (part of the Devise gem, not in the application). This renders a login form that allows user to toggle between email or Google signin
2. If the user does submit an email for login, that request is sent to SessionsController#create which is in the logic for MyUSA (and not a standard part of Devise). This is turn renders out the email and shows the user the almost there HTML screen

All of this stuff exists currently in the application and just needs to be restyled to match the new flow generally. The one exception is whether or not we want a method to check if the user already has registered in 18F with their email previously. This is a backend AJAX method that is specified in the new flow but it may not actually be needed as this flow is a bit confusing and might be redesigned. Waiting until I implement that part.

[harrisj]

Just wanted to confirm something with @mkhandekar and @esgoodman. If the user navigates directly to the MyUSA login screen (ie, alpha.my.usa.gov after you have logged out), do we want to show them this exact same new layout for the Log in at MyUSA and the almost there/resend email screens? Or are their important differences for those screens on an application-directed authentication vs. directly logging into MyUSA

[jackiekazil]

This ticket will be closed and rewritten by @mkhandekar, so I am assigning back to her. :-)

[mkhandekar]

Closing this issue in favor of #735 (Sign in flow — to code) which is capturing all the moving parts of the sign in flow.