How I Killed My Signup Form with Rails | Hacker News Reader

How I Killed My Signup Form with Rails

blog.henriquez.net

35 pointslhenriquez5 comments

Even though the <a href="http://www.alistapart.com/articles/signupforms">gradual engagement meme</a> 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, <a href="http://newsforwhatyoudo.com/">Newsforwhatyoudo.com</a> 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.

Open articleView on HN

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.)

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?

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.

I do something similar to your (1) but as I didn't want people with text browsers or screen readers to have problems I have a field labelled to look tasty for spambots and pre-filled with "don't alter this text" or similar and check that the text is unchanged. It seems very effective.

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

http://www.texelate.co.uk/blog/how-to-prevent-spam-form-subm...

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

Reply on news.ycombinator.com