determine how omniauth (FB, Twitter, Github, etc) will work for user signups

[camallen]

When creating an account, Panoptes requires a user to have a login, email and uri_name. What will happen when a user signs up using an omniauth provider but doesn't alllow access to the required details?

• Will we prompt them for the details before allowing them to complete the sign up process?
  • This will hinder sign ups and leave an account in limbo?

Do we allow users to create a half completed account?

@mrniaboc really wants to have confirmed email addresses. Perhaps an alternative strategy is to create a confirm signup link without logging the user into the system, e.g. https://github.com/plataformatec/devise/wiki/How-To:-Override-confirmations-so-users-can-pick-their-own-passwords-as-part-of-confirmation-activation

Thoughts?

[edpaget]

Facebook and Google OAuth let you request email address details (Twitter doesn't); however the user can choose not share it, which is something I'm totally fine supporting. I don't think we need to predicate participation in our projects on users giving us an email, especially once we have a global notifications system.

[mrniaboc]

Tell me more about this global notifications system. At the moment the main
way we drive people back to our sites is with the newsletters. I'm worried
what will happen if we make it easier for users not to give us their email.

On 18 June 2014 15:26, Edward Paget notifications@github.com wrote:

Facebook and Google OAuth let you request email address details (Twitter
doesn't); however the user can choose not share it, which is something I'm
totally fine supporting. I don't think we need to predicate participation
in our projects on users giving us an email, especially once we have a
global notifications system.

—
Reply to this email directly or view it on GitHub
#67 (comment).

[brian-c]

uri_name sounds like too much. URIs should be based on user names. We should make sure new user names don't need escaping. If an old user's name is ugly in their URL, they should be able to change it. I imagine that should only affect a small minority of existing users.

[ttfnrob]

I'm totally with @mrniaboc on the need to confirm emails. Surely we need
emails to contact users and to allow them to authenticate themselves? The
global notification system works so long as everything is fine but if a
user is locked out - or we need to contact them, then email could be
essential.

On 18 June 2014 15:26, Edward Paget notifications@github.com wrote:

Facebook and Google OAuth let you request email address details (Twitter
doesn't); however the user can choose not share it, which is something I'm
totally fine supporting. I don't think we need to predicate participation
in our projects on users giving us an email, especially once we have a
global notifications system.

—
Reply to this email directly or view it on GitHub
#67 (comment).

[ttfnrob]

I think it's too early to talk about the notification system replacing
email.

On 18 June 2014 15:52, mrniaboc notifications@github.com wrote:

Tell me more about this global notifications system. At the moment the
main
way we drive people back to our sites is with the newsletters. I'm worried
what will happen if we make it easier for users not to give us their
email.

On 18 June 2014 15:26, Edward Paget notifications@github.com wrote:

Facebook and Google OAuth let you request email address details (Twitter
doesn't); however the user can choose not share it, which is something
I'm
totally fine supporting. I don't think we need to predicate
participation
in our projects on users giving us an email, especially once we have a
global notifications system.

—
Reply to this email directly or view it on GitHub
#67 (comment).

—
Reply to this email directly or view it on GitHub
#67 (comment).

[parrish]

I think it's fine if we decide we want to require an email address. That's what we've always done.

I also agree with Brian about the URI name. Just the username, and we're talking about forcing users to change their name when it doesn't meet the new validation, right?

[edpaget]

We obviously have to get emails when users are signing up with a password to enable password resets, but if they sign up using their Facebook or Google login, and say "I'd prefer to not share my email", do we turn around and say, "Give us your email before you can use your account"? I think that's a really bad user experience, and will certainly lose us more classifications by people that give up the sign up process at that step than we'd gain by being able to email them later.

I also think the number of Facebook/Google signups we'd have that decline to give us their email will be small.

[brian-c]

I wouldn't force them to change it. It's not going to break anything, it'll just be ugly in some browsers.

[brian-c]

I agree on not demanding emails. We could encourage it to the point of being annoying (Twitter currently doesn't know my email address and I get a big banner on every page), but we the account should still work.

[edpaget]

@brian-c I do think we should get emails for people signing up to get a zooniverse password, so they can reset it if they need to. I don't think we should require them to validate their email though (the whole sending an email with a link and letting them click it thing).

We should always be aiming for the time between a user signing up for an account and doing a classification with their new account to be as small as possible.

[mrniaboc]

I totally agree with Ed on making the user jump through as few hoops as
possible, however we recently had a bad experience with someone who's email
had accidentally been used to sign up for Zooniverse. Email validation is
something we should think about. I also like the way twitter annoy you
about your email without stopping you from using the site.

On 18 June 2014 16:04, Edward Paget notifications@github.com wrote:

@brian-c https://github.com/brian-c I do think we should get emails for
people signing up to get a zooniverse password, so they can reset it if
they need to. I don't think we should require them to valid their email
though (the whole sending an email with a link and letting them click it
thing).

We should always be aiming for the time between a user signing up for an
account and doing a classification with their new account to be as small as
possible.

—
Reply to this email directly or view it on GitHub
#67 (comment).

[edpaget]

@mrniaboc What kind of problem? I'd assume if that happened we'd just delete the account...

[mrniaboc]

It took us a while to figure out what had happened, and the guy was not the
most forgiving of people. The account was a genuine account what had been
used on Galaxy Zoo and Planet Hunters so I didn't want to just delete it.
In the end we just removed the email associated with it. The thing is this
can happen, and we don't want to get accused of spamming.

On 18 June 2014 16:10, Edward Paget notifications@github.com wrote:

@mrniaboc https://github.com/mrniaboc What kind of problem? I'd assume
if that happened we'd just delete the account...

—
Reply to this email directly or view it on GitHub
#67 (comment).

[brian-c]

What if we only sent newsletters to verified email addresses and email addresses we collected from another service?

[chrislintott]

One use case to add to this is when someone - who might only have visited a few times - turns out to have discovered something of note. Without an email address we can’t let them know.

On 18 Jun 2014, at 16:18, Brian Carstensen notifications@github.com wrote:

What if we only sent newsletters to verified email addresses and email addresses we collected from another service?

—
Reply to this email directly or view it on GitHub.

[edpaget]

I'm down with @brian-c's suggestion that we should only send newsletters to people who verify their email.

I also didn't realize we weren't already doing it but receiving the newsletters should really be an opt-in thing during signup.

[edpaget]

@chrislintott if someone doesn't provide a valid means to contact them, I think we could assume they have some reason for not wanting to be contacted.

[parrish]

@edpaget It's currently an opt-out, and for good reason.

I agree that non-verified accounts could get a banner/notice saying something along the lines of "Your account is not verified, to be notified of discoveries you've contributed to and to be credited for your work..."

We should be very cautious about not collecting emails. Most users stay subscribed and it's our most effective means of sending people to projects.

[edpaget]

@parrish it's actually not mentioned during sign up. Signing up on Snapshot Serengeti gives you no indication we're going to email you at all. There's not even a box someone could turn off.

I think there is never a good reason to opt someone into emails (for one that's why email is broken. I also feel its not right to assume you know what someone wants...), but I recognize that I'm not going to win that fight. We should at least allow them to disable newsletters during the sign up process. That's fairly standard practice everywhere else on the internet.

I'm also all for collecting emails of people who sign up using a password on our site. I also think we should ask a user for their email by default when they sign up through Google for Facebook. I just don't think we should reject users that deny us access to their email when signing up using a Facebook or Google login, as I think that would cause the very small number of users (literally dozens of us!), who would decide not share an email to never use our sites.

[camallen]

Good stuff everyone. In summary we should streamline signups as much as possible to get users into the system and classifying. To enable that we should go with the following:

• When signing up using Omniauth providers (FB, Twitter, etc) ask for their personal details (name, email, etc) but only require a unique login name.
• When creating an internal (username and password) account we will require Login, Email and Password only (display name?) to enable lost passwords to be reset.
• All signups should ask a user to opt-in to receive communications.
  • Not sure how this will work for omiauth signups.
  • Default is out, I agree with Ed but I don't really mind which way we go. However the UI should make the knowledge obvious and should not attempt funky wording to get people to opt-in.
• Combat spam by only sending emails to people with verified email address.
  • Perhaps we send them a link to confirm their address when they opt-in?
  • This will require syncing of details between our accounts and the mail list manager.
• Client UI will "annoy" users to add their email addresses and other user details.
• We remove the use of URINames for users and groups instead use user logins and group names for the URLs.
  • Linked to What's a User? #40 - Old users will get escaped characters in their url's.

Did I miss anything?

Once we all agree on this process we can break out the various tasks.

[ttfnrob]

All fine here. Opt-in to communications will ned to be clear regarding what
those communications are (potential discoveries, new project announcements,
project-specific news are all quite distinct really).

On 19 June 2014 09:52, Campbell Allen notifications@github.com wrote:

Good stuff everyone. In summary we should streamline signups as much as
possible to get users into the system and classifying. To enable that we
should go with the following:

When signing up using Omniauth providers (FB, Twitter, etc) ask for
their personal details (name, email, etc) but only require a unique login
name.

When creating an internal (username and password) account we will
require Login, Email and Password only (display name?) to enable lost
passwords to be reset.

All signups should ask a user to opt-in to receive communications.
- Not sure how this will work for omiauth signups.
- Default is out, I agree with Ed but I don't really mind which way
we go. However the UI should make the knowledge obvious and should not
attempt funky wording to get people to opt-in.
-

Combat spam by only sending emails to people with verified email
address.
- Perhaps we send them a link to confirm their address when they
opt-in?
- This will require syncing of details between our accounts and the
mail list manager.
-

Client UI will "annoy" users to add their email addresses and other
user details.

We remove the use of URINames for users and groups instead use user
logins and group names for the URLs.
- Linked to #40 #40 -
Old users will get escaped characters in their url's.

Did I miss anything?

Once we all agree on this process we can break out the various tasks.

—
Reply to this email directly or view it on GitHub
#67 (comment).