

How I Killed My Signup Form with Rails - lhenriquez
http://blog.henriquez.net/2009/08/kill-your-signup-form-with-rails.html
Even though the &#60;a href="http://www.alistapart.com/articles/signupforms"&#62;gradual engagement meme&#60;/a&#62; has been around for a while, and everyone just hates signup forms, they just seem to keep popping up like a bad habit.  My site, &#60;a href="http://newsforwhatyoudo.com/"&#62;Newsforwhatyoudo.com&#60;/a&#62; was one of the guilty parties.  We saw users coming back to the site repeatedly, but not signing up.  The percentage that looked at the signup form and then bolted was uncomfortably high.  It was time to kill the signup form.  This blog post documents how we implemented gradual engagement using Ruby on Rails and restful authentication.
======
patio11
I did something which is sort of similar for my site.

Quick takeaways:

1) You can break almost all spambots by requiring them to evaluate CSS or
Javascript to avoid a tripwire. For example, I have a field on all my
(publicly accessible) forms labeled "comment" and hidden via CSS. A
before_filter bounces anybody who puts anything in it. Simple, took 5 minutes
to implement, reduces spam registrations to essentially zero.

2) It was easiest for me to create virtual user registrations in a private
namespace (trial users provide an email address, virtual users are given an
unguessable email address on my domain that does not actually correspond to a
mailbox) and assign them a particular limited role, which let me reuse almost
all of the code for "real" trial users. This lets you upgrade people out of
virtual userhood trivially -- grab the virtual user, write over two fields,
save to DB. Done.

If you do it like this, and give the virtual users sensible defaults, you
minimize the amount of almost-duplicated-but-not-quite code that you have to
include in views. That will save you on a lot of bugs and aggravation.
(Reproducing bugs for particular well-used "virtual" users is a pain in the
keister.)

~~~
gohnjanotis
patio: great idea about avoiding spam bots.

We recently struggled with this on the design of the front page of an
application. A similar issue we ran into is scaring people away with
login/password boxes on the front page.

What does everyone think, is it better to have the login/password boxes
visible immediately to save the user a click, or do what digg and twitter do
to avoid scaring people about a sign-up form in the not so distant future and
hide it behind some AJAX?

~~~
patio11
I think its better to do whatever the A/B test says works better for your
particular users.

I burned two hours a week ago trying to test that but my CSS and lightbox
implementation did not play well with each other and I eventually scrapped it.
I'll take another stab at it in November -- no killing the magic pumpkin
before Halloween.

I have compelling evidence that using a lightbox to "pre-sell" the
form/download increases conversion rates, at least among my users. Try
clicking on the giant image in the middle of my home page -- it works
_beautifully_.

------
percept
Here's a good summary of options for fighting form spam:

[http://www.texelate.co.uk/blog/how-to-prevent-spam-form-
subm...](http://www.texelate.co.uk/blog/how-to-prevent-spam-form-submissions/)

I prefer #2 for its unobtrusiveness (as the article suggests).

