Skip to content
This repository has been archived by the owner on Jan 15, 2024. It is now read-only.

v2 flow

Jump to bottom
Peter Karman edited this page Aug 17, 2018 · 17 revisions

The UX flow of version 2 differs with four primary changes:

  • capture user contact info (name, dob, county, email, phone) on first step
  • perform SOS already registered check within the app itself (keep users on our site)
  • reduce total time to complete flow
  • offer Advanced Ballot registrations

Every input should have a (?) icon next to it that, onclick, answers the question: why are we asking you for this?

Step 0

Landing page is a form asking for:

  • first name (required)
  • last name (required)
  • DOB (required)
  • county (required)
  • email (required)
  • phone (optional)

If the home page is requested with ?ref=XXXX GET param, persist that ref code value as a hidden input in the form.

On POST, the server will:

  • validate whether the user is already registered, using the ksmyvoteinfo-py package.
  • if the user is already registered, then the response is a redirect to step 1.
  • if the user is not already registered, then the response is a redirect to step 1VR.

Regardless of the response, server writes all PII as encrypted blob to persistent store (PostgreSQL). Persistent store should also have auto-generated session UUID (used as the session cookie value), any ref code, and timestamps.

Step 0x

This alternate landing page will pre-populate the form via a POST with a ref=XXXX code. This allows referring sites to POST us PII and a ref code. It is likely that the referring site will not pass us County or DOB, so those fields will not be populated.

On successful POST, saves the PII as a new session and redirects to Step 0.

Step 1

Assuming they are already registered, the voter may want to do one of three things:

  • Change their registration (moved, change party, etc)
  • Apply for advanced ballot for upcoming election(s)
  • Apply for permanent advanced ballot.

This is just a page with links and helpful text.

Step 1VR

Start the Voter Registration process. Should contain some text about "We could not find a record of your registration. If you have recently registered to vote, it may take some time for your record to be updated. If you know are registered, and want to apply for Advanced Ballot, click here (link to Step 1AB)."

Form with:

  • Are you a citizen? checkbox, required
  • Will you be at least 18 yo by the next election? checkbox, optional

Step 1AB

The Advanced Ballot form. The assumption here is that the user is already registered (we may even arrive here from Step 8).

Form with:

  • Link to Step 1VR change their registration.
  • Which election do you wish to apply for an Advanced Ballot? Dropdown options should include any upcoming elections for the current calendar year (maximum of 2 -- primary and general). (We probably need a DB table just for elections and their dates, so we do not have to manually edit this dropdown's options.) The user may select multiple elections. If they select "primary" then they should be prompted to select which party they want the ballot for. There's some potential conflict here if the user is an Unaffiliated voter, so we need language that specifies that selecting a party's ballot different from their registration (which we know from Step 0) will be interpreted as a switch in party. This requires some UX teasing out.
  • OR, a checkbox for "do you wish to apply for permanent advanced ballot" with some language about eligibility.

On POST, the server should validate that either the checkbox was checked, or one or more elections were selected. If a primary election was selected, verify that the party was also selected. TODO We may need to stop the process here with an error if they are Unaffiliated and have selected a party.

If the session already has all the PII necessary, then redirect to Step 5AB. Otherwise, a valid request should redirect to Step 3AB.

Step 2

Form with:

  • prefix (dropdown, optional)
  • first name (populated, required)
  • middle name (optional)
  • last name (populated, required)
  • suffix (dropdown, optional)
  • were you previously registered to vote under a different name? checkbox, toggles a hidden-by-default form asking for same fields, under previous name

On POST, save to psql and redirect to Step 3VR.

Step 3VR

Form with:

  • Home address (required)
  • Apt/Lot (optional)
  • City/Town (required)
  • State (KANSAS hardcoded -- not a dropdown)
  • ZIP code (required)
  • Previously registered to vote at a different address? checkbox, toggles a hidden-by-default form asking for previous address
  • Do you have a separate mailing address? checkbox, toggles a hidden-by-default form asking for mailing address

On POST, server should validate all user-supplied addresses using the USPS API.

If server validation fails, re-render form with a bold red error message and common helpful hints. (TODO: should allow the user to somehow override the validation?)

If validation succeeds, save both user-supplied and USPS values to psql and redirect to Step 4.

Step 3AB

Identical to Step 3VR, except that we do not ask for previous address.

On POST success, redirect to Step 5AB.

Step 4

Display validated, normalized USPS addresses, but with bold note indicating they will not be used on the form.

Form with:

  • Choice of party (dropdown, required)

On POST, validate value is, in fact, a party, and on success, write to psql and redirect to Step 5VR.

Step 5VR

Form with:

  • Identification

NOTE: we may combine Steps 4 and 5 based on user feedback. The Identification screen may need a wall of text and stand alone.

On POST, store the ID number. Assemble the NVRIS payload and send to NVRIS. Wait for response. Cache the image in the psql session and redirect to Step 6.

Step 5AB

Form with:

  • Identification

We require Driver's license or state-issued ID number. NONE is not an option for the Advanced Ballot flow.

On POST, store the ID number. Assemble the NVRIS payload and send to NVRIS. Wait for response. Cache the image in the psql session and redirect to Step 6AB.

Step 6VR

NVRIS form preview. Important that we cache this image in the session so that user clicks "back" after signing that we can persist the preview. Should invalidate the cache if user clicks "back" to re-enter any information.

Include signing box beneath preview image.

On POST,

  • validate that we have received signature
  • Save to psql session
  • Assemble the NVRIS payload and send to NVRIS. Wait for response.
  • Cache the NVRIS image in the psql session.
  • redirect to Step 7.

Step 6AB

Identical to Step 6VR, but for Advanced Ballot preview.

If this is the non-permanent Advanced Ballot flow (AV1), and we have multiple selected elections, we need a separate form for each election.

On successful POST, redirect to Step 7AB.

Step 7VR

NVRIS signed form preview.

Include County contact information, including email address. We have county already from Step 0.

Include "I affirm that..." checkbox between the signed form preview image.

On POST,

  • Validate the affirmation checkbox
  • Save to psql session
  • Assemble the NVRIS payload and send to NVRIS. Wait for response.
  • Cache the NVRIS image in the psql session.
  • Queue the emails for sending.
  • Redirect to Step 8.

Step 7AB

Identical to Step 7VR but for Advanced Ballots.

On successful POST, redirect to Step 8AB.

Step 8VR

Confirmation receipt of emails sent.

Add a link to the AB flow in Step 1AB. Since we have all the PII at this point, we just need the election selection(s) or permanent checkbox values.

Step 8AB

Confirmation receipt of emails sent.

TODO other calls to action?

Clone this wiki locally