Skip to content

Ask the downloader to email us user info#67

Open
xyzisinus wants to merge 4 commits into
BrickSchema:masterfrom
xyzisinus:czang-ask-downloader-to-email
Open

Ask the downloader to email us user info#67
xyzisinus wants to merge 4 commits into
BrickSchema:masterfrom
xyzisinus:czang-ask-downloader-to-email

Conversation

@xyzisinus
Copy link
Copy Markdown

@xyzisinus xyzisinus commented Feb 8, 2020

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
Copy link
Copy Markdown
Author

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
Copy link
Copy Markdown
Collaborator

jbkoh commented Feb 9, 2020

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.

Comment thread webpages/resources.md
The Brick ontology is distributed as a set of [Turtle][15] files.
Turtle is a compact textual format that is understood by most Semantic Web tools.

**Before downloading please take a minute to <a href="mailto:czang@cmu.edu?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
Copy link
Copy Markdown
Member

@shreyasnagare shreyasnagare Feb 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
**Before downloading please take a minute to <a href="mailto:czang@cmu.edu?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:czang@cmu.edu?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.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No problem!

Comment thread webpages/resources.md
The Brick ontology is distributed as a set of [Turtle][15] files.
Turtle is a compact textual format that is understood by most Semantic Web tools.

**Before downloading please take a minute to <a href="mailto:czang@cmu.edu?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
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Please suggest replacement. Thanks!

Copy link
Copy Markdown
Member

@shreyasnagare shreyasnagare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown
Author

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
Copy link
Copy Markdown
Author

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
Copy link
Copy Markdown
Collaborator

jbkoh commented Feb 9, 2020

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
Copy link
Copy Markdown
Author

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
Copy link
Copy Markdown
Member

  • 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
Copy link
Copy Markdown
Author

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

Great idea. Will do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants