Opened 5 years ago

Last modified 5 years ago

#2234 closed change

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

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 under /submitEmail handling email addresses sent as form data in a POST request. The email address will be given by the email form field (one email address per request). Those email addresses must be stored in a persistent file on the disk, one line per email address (this will be compatible with CVS). Moreover, the file needs to be locked for writing to avoid problems when concurring requests try to access it at the same time. 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.

Change History (14)

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 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?

Note: See TracTickets for help on using tickets.