Foundation.mozilla.org: Implement Email Signup in Creep-O-Meter Flow

[beccaklam]

Implement an email sign up in between the creep-o-meter screen and the results screen.

---

🗒 Design -> Dev Handoff Checklist
(Feel free to remove items that are not applicable.)

• [x] Design has been finalized
• [x] Link to original design ticket: #3614
• [x] Link to Redpen: https://redpen.io/sh6ecf0f84f26f2694
• [x] Design changes been merged into the master Sketch file
• [x] Desktop and mobile mockups are included

[kristinashu]

Requirements for step 1: Vote

• [x] Update pill button to square button to match our style guide
• [x] To increase signups and reduce barriers, update the Likely/Not Likely button to not-required (so people can users will be able to submit there vote even if they haven't interacted with either question)
• [x] Vote & see results no longer needs to be disabled and Likely/Not Likely button no longer needs the hint animation

Requirements for step 2: Signup

• [ ] Please follow styles and rules from foundation site (included error states) - no need to language or country picker
• [ ] Add analytics events
• [ ] Clicking No thanks brings user to results screen

Needs discussion
We don't want to bombard users with newsletter signup prompts if they have already signed up. Any suggestions on how to do this? My initial thoughts:

• if a user comes from our email subscribed=1then we skip the signup prompt (after voting then a user goes to the results screen)
• if a user has voted 3 times in one visit then we skip the signup prompt

Requirements for step 3: Results

• [x] Update pill buttons to square to match our style guide

[youriwims]

* [ ]  Add analytics event/tracking

@kristinashu What should the category, label and action be for this? I'll update the ga spreadsheet once I know :)

Needs discussion
We don't want to bombard users with newsletter signup prompts if they have already signed up. Any suggestions on how to do this? My initial thoughts:

* if a user comes from our email `subscribed=1`then we skip the signup prompt (after voting then a user goes to the results screen)

@alanmoo @mmmavis In terms of the logic, this sounds about right to me. I'm thinking of this in terms of subscribed being a state and once the user signs up successfully, then subscribed: true. Then if subscribed: true, the signup prompt never displays again else..._it does_. Does that sound good or anything else I should consider in my approach?

* or a user has voted 3 times in one visit then we skip the signup prompt

I agree with this, if they've rejected the prompt 3 times already in their visit, they probably don't need to see it anymore.

[kristinashu]

• [ ] Add analytics event/tracking

@kristinashu What should the category, label and action be for this? I'll update the ga spreadsheet once I know :)

I've just added it to the spreadsheet ~but I'm not too familiar with analytics tho so it would be great if someone double checked it~ (Matthew has reviewd them).

[mmmavis]

I'd suggest breaking this ticket into several tickets/PRs as it covers quite a bit. Maybe one for updating step 1 and step 3 and one for adding the signup portion in?

In terms of ways to prevent us from bombarding users with signup prompt

1. if a user comes from our email subscribed=1 then we skip the signup prompt (after voting then a user goes to the results screen)
2. of a user has voted 3 times in one visit then we skip the signup prompt

@kristinashu The two ideas above cover different use cases. Are we doing both or either?

@youriwims state isn't persistent. It gets reset when the component is remounted. We likely need to use localstorage or sessionstorage for idea # 2.

[kristinashu]

The two ideas above cover different use cases. Are we doing both or either?

• [x] If they come from our list then we don't show it
• [x] If they aren't coming from our list then we show it
• [ ] If they aren't coming from our list and they vote 3 times then we show it the first 3 times but then don't show it after that

[youriwims]

@kristinashu should the social share buttons match exactly what we have on the style guide(aside from them being square)? I'm just asking because the icons are different and here it says _Link_ instead of _Copy_.

[kristinashu]

Oh yeah, please match what is in the style guide.

Just clarifying, what do you mean by "aside from them being square"? We do want PNI to move from the round/pill buttons to the rectangular ones from the style guide.

[youriwims]

Oh, I was trying to make sure that aside from updating them to be square, that we wanted the icons and link text to match what's on the styleguide.

[kristinashu]

Ah ok good good. I just made a comment in redpen too, it's ok if the buttons end up being wider than in the comp (guess they buttons will be full width).

[youriwims]

[For Step 2] @kristinashu how exactly do we want to do the form error states? For example, when a user clicks _No Thanks_, I assume we don't want errors to block them from continuing to the final results view. So, when/where during the signup view do we want the error to show up e.g. if they click _Submit_ and the value(s) are invalid?

[kristinashu]

That's right, Sign up would trigger the error states if something is wrong and No thanks just brings users to the next screen, no error states.

[youriwims]

Okay, and if they do choose to sign up, do we want to show the success message once they've signed up successfully or just skip straight to the results?

[kristinashu]

Ooooh good question... I guess we won't show the success message, we should just bring a user to the results.