User Experience

Honeypot for Rails Email Form

While working on my companies new website I realized that our contact form didn't have any spam protection and would become a favorite of bots not long after launch so I decided to add a honeypot.

If you're not familiar a honeypot is a hidden form that users can't see, but because bots don't read CSS they fill it in. If the form is filled in it automatically fails. This is a better alternative to the captcha because it doesn't require your users to type out a ridiculously illegible code (which from experience, i can tell you gets frustrating when you've gotten it wrong 60000 times).

I searched through a few gems and after being frustrated with the outcome decided to just do it myself because really it's just a few fields and the form is ajaxed and the gems would send a 200 response essentially removing the form, which was no my intention.

Open your form view and add a field for the honeypot. Be sure to add a label explaining it is a honeypot to ensure accessibility for screen readers and instructing users to not fill in the field.

<div class="field sweet_honey_for_bots">
  <%= label_tag :sweet_honey, "This is a honeypot, if you see this you're CSS is turned off or you're a bot. If you're not a bot don't fill it in." %>
  <%= text_field_tag :sweet_honey %>
</div>

Then go to your model and make your field accessible; attr_accessible :sweet_honey

One last quick step is to instruct your form what to do on save. You can have it simply fail with no error but that isn't accessible plus if anyone does fill it in, you might want to give a fun little message for them. I have my form rendering a partial because of the ajax-iness, plus I don't want the form to disappear just in case it's not a bot.

if params[:sweet_honey].present?
    format.html { render :partial => "emails/email_bot", :layout => false }
elsif @email.save
    ...
else
    ...
end

This is super simple implementation of a honeypot. I figured why make it more complicated when I just want to prevent send?

There's More to User Experience Than Ease of Use: Lessons in Not Scaring Your Customers

This post is not really going to be Rails related. But everything in a Rails blog doesn't need to be about Rails, or Ruby, or coding at all.

I feel like Rails is an experience, in not being frustrated with everything and it's easier to map out an application. The things that get in the way of building something awesome, the time consuming, awful things like join queries and pluralization are done for you. You can focus on your application and it's beauty and structure.

Well, user experience is also an experience and I hate that it's so often that a website has me banging my head against a wall. Recently, I logged on the Sallie Mae website to check something with my student loan. Being that I have it set for auto-debit and that I was logging in on a weekend I was met with a front page telling me I was delinquent on my loan.

Now people who know me will know my reaction without telling you. I literally flipped a shit. Thinking my bank account information was lost or some other awful scenario (was my bank account hacked and emptied?? no...it wasn't phew) I searched through my account for an answer when the answer occurred to me.

Sallie Mae does not have a failsafe in place so that when you have auto-debit activated and the date of debit falls on the weekend it doesn't "figure it out" it instead tells you you didn't pay and that you better do it now.

Awesome. Please when building an application make sure you put in if else statements that check for things like weekends, and auto-debit. It will make your customers happy. No one wants a mini heart attack on Sunday evening, to log in the next day and see all is well.

User experience is more than making a site easy to use, and beautiful (both which Sallie Mae fail at). It's also about not scaring the crap out of your clients and consumers — or accepting 76 early acceptance students accidentally (I'm looking at you Vassar). When desiging a web application consider all the horrible things that can go wrong for the user, not just you the developer and put failsafes in place to prevent those things. You will have happier clients that will keep coming back again and again.

Frustration is never good for business.