Opened 5 years ago

Last modified 5 years ago

#2234 closed change

Collect emails from a form field on a landing page — at Version 18

Reported by: annlee@… Assignee: sebastian
Priority: P3 Milestone:
Module: Sitescripts Keywords:
Cc: sebastian, saroyanm, trev, fhd, Kai, matze Blocked By:
Blocking: #2213, #2267 Platform: Unknown
Ready: yes Confidential: no
Tester: Verified working: no
Review URL(s):

http://codereview.adblockplus.org/5177883412660224

Description (last modified by sebastian)

Background

There is an email form field at the bottom of the landing page in issue 2213, in which people can submit their emails in order to get advance notice of the iOS browser launch.

The current plan is to notify people just once prior to the official announcement of the iOS browser.

We can wait until shortly before we notify people to access the addresses, which means I would only need to access the email addresses once.

What to change

Implement a WSGI app served by the multiplexer providing following two controllers:

/submitEmail

This controller should handle email addresses submitted in a form field with the name email in a POST request. A verification email should be sent to that email address. This email must include a link to /verifyEmail described below. The email address must also be stored in a way that it can be associated to the verification code given in that link. Once this has been done, a response with the text "Thanks for your submission! You'll receive a verification email shortly." should be sent.

/verifyEmail

This controller should handle the links in the verification emails sent by /submitEmail. The verification code will be given in the query string by the parameter code. If the verification code is known and can be associated with a previously submitted email address, that address should be marked as verified, and the user should be redirected to a landing page. If the verification code is unknown the user should be redirected to a different landing page.

Change History (18)

comment:1 Changed 5 years ago by annlee@…

  • Description modified (diff)

comment:2 Changed 5 years ago by annlee@…

  • Blocking 2213 added

comment:3 follow-up: Changed 5 years ago by sebastian

  • Cc sebastian saroyanm trev added
  • Component changed from Unknown to Sitescripts
  • Description modified (diff)

What is supposed to happen when the email address was stored? Is it sufficient to return a plain text response with english-only text? This is what the contact form on eyeo.com does. And I am opposed to implement a nicely designed HTML page here. That would belong into the website. So if we really need that, I suggest to issue a redirect back to a page on the website.

comment:4 in reply to: ↑ 3 Changed 5 years ago by annlee@…

Replying to sebastian:

What is supposed to happen when the email address was stored? Is it sufficient to return a plain text response with english-only text? This is what the contact form on eyeo.com does. And I am opposed to implement a nicely designed HTML page here. That would belong into the website. So if we really need that, I suggest to issue a redirect back to a page on the website.

is something like this possible? (this was @sven's suggestion)

it's similar to the contact form on eyeo.com, but the difference is that the "Thank you for your submission!..." text replaces the form field and button, instead of appearing below it

comment:5 follow-up: Changed 5 years ago by sebastian

  • Description modified (diff)
  • Ready set

I just checked again how the contact form on eyeo.com is actually integrated. If JavaScript is enabled the form is submitted with an XMLHttpRequest and the response text is nicely shown below the form (it can be styled without any restrictions there). However, if JavaScript is disabled the form still works but the user is redirected to the plain text response. Sounds good to me. So let's do it the same way here.

comment:6 Changed 5 years ago by sebastian

  • Priority changed from Unknown to P3

comment:7 in reply to: ↑ 5 ; follow-up: Changed 5 years ago by saroyanm

Replying to sebastian:

I just checked again how the contact form on eyeo.com is actually integrated. If JavaScript is enabled the form is submitted with an XMLHttpRequest and the response text is nicely shown below the form (it can be styled without any restrictions there). However, if JavaScript is disabled the form still works but the user is redirected to the plain text response. Sounds good to me. So let's do it the same way here.

Please note that in comparison with eyeo.com we will need translation as well.
So I think we will use the response text only in case the JavaScript is disabled on user side and show the hidden block with success message in case of successful XMLHttpRequest response. Not sure if that worth the effort to also translate the response text.

BTW: Did you referring to the current page implementation ?

comment:8 in reply to: ↑ 7 ; follow-up: Changed 5 years ago by sebastian

Replying to saroyanm:

Please note that in comparison with eyeo.com we will need translation as well.
So I think we will use the response text only in case the JavaScript is disabled on user side and show the hidden block with success message in case of successful XMLHttpRequest response. Not sure if that worth the effort to also translate the response text.

Not having the response text translated here, but only showing it to users without JavaScript, while showing a translated message when handling the response with XMLHttpRequest sounds good to me. But note that you must handle the status code of the response, showing an error message if it's not 200.

BTW: Did you referring to the current page implementation ?

Yes, that is what I were talking about.

comment:9 in reply to: ↑ 8 Changed 5 years ago by saroyanm

But note that you must handle the status code of the response, showing an error message

Sure, thanks.

comment:10 follow-up: Changed 5 years ago by sebastian

  • Description modified (diff)
  • Owner set to sebastian

I changed the path of the script to /formsubscribe for consistency with /formmail.

comment:11 Changed 5 years ago by sebastian

  • Review URL(s) modified (diff)
  • Status changed from new to reviewing

comment:12 Changed 5 years ago by sebastian

  • Blocking 2267 added

comment:13 in reply to: ↑ 10 ; follow-up: Changed 5 years ago by trev

  • Cc fhd added

Replying to sebastian:

I changed the path of the script to /formsubscribe for consistency with /formmail.

"formmailer" is a common term. I think the original suggestion (/submitEmail) makes more sense, /formsubscribe is just weird.

I realized that we will be putting unverified email addressed into that list, is this really a good idea? I think we need to send people an email and only add the email address if they click a link there.

Finally, does this really belong in the sitescripts repository? fhd wanted to keep functionality related to Adblock Browser out of it for now, we can have external web handlers. The code itself doesn't seem to mention Adblock Browser, so if the commit message doesn't do it either this should be fine.

comment:14 in reply to: ↑ 13 ; follow-up: Changed 5 years ago by sebastian

  • Description modified (diff)

Replying to trev:

Replying to sebastian:

I changed the path of the script to /formsubscribe for consistency with /formmail.

"formmailer" is a common term. I think the original suggestion (/submitEmail) makes more sense, /formsubscribe is just weird.

Fair enough.

I realized that we will be putting unverified email addressed into that list, is this really a good idea? I think we need to send people an email and only add the email address if they click a link there.

Yes, we are storing unverified email addresses. However, email verification would add unneeded complexity, requires additional designs and texts, and would ultimately reduce the number of users going through the process of submitting and verifying their email address.

Is there a particular reason, you think we have to make sure that the email address exists and belongs to the user who submitted it, before sending the actual notification? Shouldn't make any difference whether sending a verification email or the actual notification to an unverified email address, right?

Finally, does this really belong in the sitescripts repository? fhd wanted to keep functionality related to Adblock Browser out of it for now, we can have external web handlers. The code itself doesn't seem to mention Adblock Browser, so if the commit message doesn't do it either this should be fine.

Yes, the code doesn't mention Adblock Browser, neither did I plan to mention it in the commit message. So what are we talking about here?

comment:15 in reply to: ↑ 14 ; follow-up: Changed 5 years ago by trev

Replying to sebastian:

Is there a particular reason, you think we have to make sure that the email address exists and belongs to the user who submitted it, before sending the actual notification?

Complying with various anti-spam laws?

Yes, the code doesn't mention Adblock Browser, neither did I plan to mention it in the commit message. So what are we talking about here?

Should be fine I think, but I think fhd should be aware of this.

One more conceptual issue:

Once the email address were successfully stored a response with the text "Thanks for your submission! We'll notify you before the launch." should be sent.

@annlee: This seems silly, what exactly are we thanking for? Also, people want
to be notified when we launch, not before that. How about: "Your email
address has been recorded, we will notify you when we launch."

comment:16 Changed 5 years ago by philll

By Ann-lee:
Replying to trev:

Once the email address were successfully stored a response with the text "Thanks for your submission! We'll notify you before the launch." should be sent.

@annlee: This seems silly, what exactly are we thanking for? Also, people want
to be notified when we launch, not before that. How about: "Your email
address has been recorded, we will notify you when we launch."

'Thanks for your submission' is a standard response in this situation, we're thanking them for taking the time to signup and show their interest in our product.

On the landing page, the text right next to the email form field says, "Get an exclusive heads-up, in advance of the launch".
As such, we do plan to notify them before the launch, I don't know exactly how much in advance, an hour or a couple hours before perhaps, something to be worked out by PR. The targets of this email signup are 'early adopters' who would appreciate being the first to know

comment:17 in reply to: ↑ 15 Changed 5 years ago by sebastian

  • Cc Kai added
  • Ready unset

Replying to trev:

Replying to sebastian:

Is there a particular reason, you think we have to make sure that the email address exists and belongs to the user who submitted it, before sending the actual notification?

Complying with various anti-spam laws?

It seems that a double opt-in isn't legally required. But the problem is that with a single opt-in you can't be sure whether the submitted email address belongs to the user who opted in:
http://de.wikipedia.org/wiki/Opt-in#Deutschland

@Kai: Can you please advice?

comment:18 Changed 5 years ago by sebastian

  • Description modified (diff)
  • Ready set

As discussed internally, we need a double opt-in to avoid spamming users who didn't submit their email address themselves. Otherwise we would risk legal issues and might upset users. I have updated the issue description accordingly, and uploaded an updated patch for review. But we still need:

  1. A text for the verification email (this would be English-only as we don't have a mechanism for translations here).
  2. A landing page for users who clicked the verification link with a valid verification code. Those users will receive the actual notification later.
  3. A landing page for users who clicked the verification link for the second time or went to the verification URL directly without a valid verification code.

@saroyanm, @annlee

Note: See TracTickets for help on using tickets.