Ask the downloader to email us user info

[xyzisinus]

For the reviewer to consider:

1. The wording of the paragraph.
2. Who should be the recipients of the email (Currently it's myself. But it can be multiple people.)
3. What should be in the email body.

[xyzisinus]

The resources page is changed. A paragraph is inserted near the top of the page to ask the downloader to send us an email voluntarily.
Why this approach is taken (after discussion with Shreyas) over other approaches:

1. Yuvraij and Mario initially asked for a mandatory form to be filled before the user can download. If the downloader fills in garbage info, that's OK with us. But the user may download multiple files and we can't ask him to fill in the form repeatedly. To avoid that we need to track the user with cookies which is alarming in general.
2. We can also ask the user to voluntarily fill in a form that is sent to the our web server, instead of initiating an email action on their device. But according to Shreyas our web server is currently stateless (without persistent datastore) . I don't think this nice feature should be broken for the single purpose of tracking the form. Plus, when the user sends email from his email client, he sees the exact email addresses he's sending email to. He can verify the addresses via search to be assured.

[jbkoh]

I'd rather create a separate Contact page instead of putting the paragraph on the Resources page. The current location of the message degrades the usability by putting unnecessary information for the usage. I'd rather let users to voluntarily contact us through a separate Contact page. In the contact page, we might have two separate contacts as private emails and the Google user group. We can specify the purposes of each contact method though I am worried that it might discourage people to communicate through the Google Groups.

[shreyasnagare]

Suggested change

	**Before downloading please take a minute to <a href="mailto:[email protected]?subject=Downloading Brick resources&body=Hi, I am ... with ... I'm downloading ... We are interested in using them to ...">EMAIL US</a> so that we can send you importannt
	**Before downloading please take a minute to <a href="mailto:[email protected]?subject=Downloading Brick resources&body=Hi, I am ... with ... I'm downloading ... We are interested in using them to ...">email us</a> so that we can send you importannt

Caps is a bit unpleasant, I think.

[xyzisinus]

No problem!

[shreyasnagare]

I don't like the "so that we can send you importannt updates" part as it may scare people away.

[xyzisinus]

I don't like the "so that we can send you importannt updates" part as it may scare people away.

Please suggest replacement. Thanks!

[shreyasnagare]

I agree with @jbkoh that this will degrade the usability (which is very important). There is no way to get the user's information (also important) without affecting the usability. We need to find a balance between the two. Let's try and find other ways of doing this.

[xyzisinus]

I'd rather create a separate Contact page instead of putting the paragraph on the Resources page. The current location of the message degrades the usability by putting unnecessary information for the usage. I'd rather let users to voluntarily contact us through a separate Contact page. In the contact page, we might have two separate contacts as private emails and the Google user group. We can specify the purposes of each contact method though I am worried that it might discourage people to communicate through the Google Groups.

A contact page is fine. But if our purpose is to collect downloader info, I'll bet the contact page will collect fewer users than putting the email link directly on the resources page. How about I send email to all involved (including Yuvraj and Mario who don't necessaries watch the PRs)? It's their request after all.

[xyzisinus]

That said, I think having a separate contact page is great. I'm for adding a contact page AND a very short paragraph on the resources page to direct the downloader to the contact page.

[jbkoh]

Understanding who are using Brick is not our primary goal and not the website's. Having them use Brick is the primary goal. Thus, other secondary goals should not compromise usability.

Furthermore, I don't expect that just naively placing a mailto button on the Resources page helps to get more information from users. People who'd contact us will do it anyway if we provide the contact information. Otherwise, they will ignore our message regardless of where we put it.

[xyzisinus]

Furthermore, I don't expect that just naively placing a mailto button on the Resources page helps to get more information from users. People who'd contact us will do it anyway if we provide the contact information. Otherwise, they will ignore our message regardless of where we put it.

I fully agree with you that in most cases people will ignore the message. I don't feel strongly either way. But let's see what the initiators of this change are going to say.

[gtfierro]

• no mandatory forms; I think that's just part of being a good web citizen
• fine to ask them to sign up for a mailing list (voluntarily)
• a "stateless" webserver is orthogonal to logging the download requests through apache/nginx; why don't we do the latter?

[xyzisinus]

• a "stateless" webserver is orthogonal to logging the download requests through apache/nginx; why don't we do the latter?

Great idea. Will do.