David Verhasselt's Profile

Group the activities by User and Action.

If the only reason they're not switching is because they already have an account, then they're probably not that grumbly. We're talking about subtle unconscious cues that influence the stats in otherwise unnoticeable ways here, not torturing users and tying a lease around their neck.

I bet it goes something like this:

On the one hand, if the user can try it, and doesn't like it after all, they definitely won't convert (and will look for another solution).

On the other, if the user needs to register before they can use it, they've already gone through the hurdles and might as well use it then. Even if they like it just as much (less) as in the previous example, the fact that the user will need to go through some more hurdles to find something else might keep the user with your solution.

Of course there's a tight balance there, but it's the same thing with credit cards and trials. Intuitively you might think it's best to allow people to do a trial without entering a CC#, but in fact if you make them enter a CC# for a trial, they'll be more prone to convert, since it's automatic (path of least resistance from then on for the user - they don't need to do anythign anymore)

Possible that this is due to my out of date (but unupdateable) rubygems!

Hey Ryan, an important heads-up!

You actually need to do
require "RMagick"

and not
require "rmagick"

This works on Mac OS because of the commonly case-insensitive filesystem, but once you deploy on a linux server, the all small-caps won't function correctly. Took me a while to figure out this discrepancy.

It heavily depends on how you structure your application, but here's what I'm going to do with my app, where the email is the unique identifier of a user.

First case: the user who registered previously tries to log in via Omniauth which returns the same email. Then the validations that email should be unique fails. You should tell the user that an account with this email already exists, and ask him to enter the password for that account so you can link both (then you don't create a new user, but you add Omniauth's provider/uid to his old account).

Second case: the user tries to log in/sign up normally after registering via Omniauth. In this case he will be told that (log in) the password is incorrect or (sign up) the address is already in use. When this happens you should check to see if the provider attribute of the user with that email address is not-empty, and if so, advise the user to login using "provider" (i.e. Facebook).