With the launch of our new website at sayyeah.com we added a simple contact form to allow interested people to get in touch with us. From the moment the site went live, the most interested people getting in touch were spambots.

100s of messages quickly flooded Lee’s mailbox. Instead of prospective clients, he was inundated by offers for discount Michael Kors handbags, apparently being sold from a small fishing charter company and a diabetes care website (among many others).

We needed a way to block these useless submissions without adding any additional user requirements to fill out the form, such as captchas or simple math problems.

So how did we handle this challenge?

The answer in our case was to use a Honeypot form field. What this entails is creating a trap field. A human using the website won’t see or fill out this field, but a bot will, and when it dumps content in to it, we’ll have effectively caught the bot.

The Front End

Our basic form consists of a few fields. Name, Email, Message. This is what we’re looking for from real people trying to connect with us.

Our trap field is called Phone. This field shouldn’t be named trap, or gotcha, or lolsillybots, because it’s easier to detect something that looks out of place. By blending the naming convention in with the form, it’s harder for the bot to detect it.

Here’s our initial form, with all fields visible. The blank field is the honeypot field.

Remove from the tab index

First lets take the element out of the tab flow. If we don’t do this, when a user presses tab to jump from the adjacent field they will jump to the top of the screen with no understanding of what’s going on.

This tag goes right in the HTML. tabindex=“-1”

Visually remove the honeypot element

Next we can target the element #phone in a CSS stylesheet and position it absolutely {position:absolute;}, way off screen. {top:-10000px;}

This will ensure that the form field isn’t visible to the average person visiting your site.

Some notes:

• The field should not be disabled, otherwise, nothing can write in it, and that would defeat the purpose;
• You should also avoid using display: none; CSS as some bots can catch that you’re hiding the field.

The Back End

Now that we have the honeypot field in place and hidden from human eyes, we need to set up a backend method to catch and validate its value. What this will do is look at our field and make sure it meets the criteria we set, in our case, it must be empty.

How this is achieved will be different for each programming language, but for our example, here’s Express running on Node with node-validator installed.

What this line is saying is “Look at the value and ensure it’s nothing (string value=”).

If it is, continue, if it’s not, throw an error, don’t email us, call the FBI, log the request, etc. Whatever you choose as the outcome for invalid posts.

That’s it

And so far it’s working for our small submission form. It was quick to setup, taking less than 5 minutes, and dropped our spam submissions down to zero. At least for the time being.

This isn’t fool proof, and if our form had more value for the spammers they’d quickly find away around it. But it’s the first line of defence and if the bot(s) that spam us find a work around or get more sophisticated, we’ll have to up the ante.

There are many other methods for stopping unwanted form submissions, you can check out some suggestions in this post on StackOverflow.

Product strategy as a foundational skill

If you’re looking to bring fundamental product strategy methodologies and execution to your team, we’re here to help.

Get in touch

The post You catch more bots with honey: reducing form spam without captchas. appeared first on Say Yeah!.

We’ve also been keeping an eye on Tim Bray’s efforts to make logging in safer and simpler. He’s advocating two-step authentication now and a future where you don’t need a user name and password to login. That would be great, but we’re not there yet.

And today I was led to Mailchimp’s article outlining some key findings based on a few login page redesigns.

So let’s look at some of the most important login screen considerations.

From Mailchimp:

The engineering team, ever mindful of security, argued that being generic about username and password errors makes it harder for bad guys to guess usernames by pounding the form with random words or email addresses.

Most login forms give you a generic error along the lines of “Your username and password is incorrect.” Engineering has long held that this is to protect the site from hackers, but it means your user doesn’t know if they have the wrong password or the wrong user name. The result: more users having to go through a tedious password recovery process.

We’ve had this security argument with engineering teams in the past. Mailchimp won the battle for their users—and we encourage you to fight for yours—because letting users know exactly what’s wrong with their login credentials far outweighs any security considerations.

On the subject of social login buttons, Mailchimp has this to say about adding Facebook, Twitter, and other login buttons to login forms:

As you add login buttons to a page, you also add decision points for users, while creating visual complexity in your design.

And:

If you’re using Twitter and Facebook for signup too you’ve got a bigger problem. A user’s credentials are then bound to another account on another service that could be canceled at any time, breaking access to your app without the user knowing. Unless you require a username and password for your app, then pair that with credentials from a social network, you’re creating opportunity for confusion and frustration for your users.

Mailchimp says only 3.4% of their users would login via the Facebook or Twitter logins. Though I’d love to see some stats from both equally busy and smaller sites regarding social login button usage in 2013 (Mailchimp’s article dates back to last autumn), there’s no doubt there’s wisdom in a number of the considerations Mailchimp points out.

That said, avoiding social logins altogether isn’t necessarily the only or best option, with some sites now choosing to hide their own user name and password fields to reduce complexity and focus more on the social login.

Yet, if you read Mailchimp’s article in full, they continue to argue against any use of social logins, noting additional concerns around brand dilution, managing user accounts, and consumer confusion.

In fact, Mailchimp goes on to state that they didn’t want to trust the safety of their customer logins to a provider like Facebook or Twitter. They’d prefer to be responsible for that security themselves. And maybe they have the engineering chops to handle that, but I’d bet Twitter and Facebook have a much better handle on security than most web apps and other sites that require login credentials.

Even still, let’s consider the process social logins afford vs traditional user/password combinations. With a social login, you can leverage your existing login to your daily obsession (Facebook, Twitter, Google, etc) and you simply authenticate (and can revoke at any time) the site you’re browsing. If you stay logged in to Facebook, for example, you never have to type a password into your browser, provided the sites you visit support Facebook logins.

Here’s Tim Bray with more details:

One of the key advantages Federated Identity (represented by social login buttons) is cutting down the number of times people have to type in passwords. There are a bunch of good reasons for this:

• Every time it happens, that’s another chance for password theft.
• We don’t want to get people into the habit of typing…passwords in here and there; that habit is a great big red target sign saying “Phish me!”
• Typing passwords all the time is a painful user experience, particularly on mobile devices.
• The easiest way to reduce that pain is to use a short, simple, password, probably the same one you’re using everywhere including on your easily-hacked kid’s-Little-League site.

Security isn’t just who holds the passwords, it’s also how your users interact with them. Social logins can help improve security overall by making user’s lives easier and less reliant on (often simplified for convenience) passwords.

In the end, your login page should be reflective of your user base and their goals, which means considering all of these factors.

If you’re not happy with how your sign up and login forms are performing, we can help you measure, refine, and improve this process for your users so they can focus on using your app.

Get In Touch

The post Towards better logins. appeared first on Say Yeah!.

On Tumblr, if you mistake the registration form for a login form and accidentally enter your existing username and password and hit the enter key, Tumblr catches the mistake and conveniently logs you into your account. There’s no point in displaying an error!

This highlights how making a smarter registration form can improve user experience. It’s an essential approach to consider with any interaction: let the system do the hard work and make everything easier for the user.

The post A look at how making a smarter registration form can improve user experience appeared first on Say Yeah!.

We’re in the throws of what feels like an endless project trying to improve on what should be a relatively simple donation form for Web Foundation. I’ve been pushing hard to work through the convoluted error messages that we’re getting back from the API we need to work with simply because running into a problem when you’re trying to give someone money is just about the last thing you need.

My first reaction when I see the following message is to question the security of the form and wonder if my information is safe

Error: there was a problem processing your request.

First of all the word “error” should be relegated to a technical issue, not a user issue. User’s don’t make errors, they miss things. You may do something in error, but your action is not an error. That’s what computers do. They error. Which usually means they’re broken. Which usually means your data isn’t safe.

And what is a “request”. User’s don’t make requests on the Web, they provide information. “processing a request” is something a computer does and it’s convoluted language for someone trying to donate money.

With that in mind, if there is a problem, we’re going to say something along these lines:

There was a problem completing your donation. Please ensure the required information noted below is filled in correctly.

I’m sure it’s a pain on the development side to try to work with an unforgiving API to adjust these things, but I couldn’t agree more that words are the soul of UX, and it’s nice to see yesterday’s post on 52weeksofux.com celebrating this.

The post Words are the soul of UX; making forms that speak to users. appeared first on Say Yeah!.

When we originally built the commenting system on the old PTE (pre-Tumblr era) Say Yeah website, we required users to create an account and sign in before they could comment. This created an unnecessary barrier to entry that reduced the likelihood that a user would comment. It just took too long.

At the same time, we wanted to ensure that we weren’t dealing with moderating spam comments all the time and the account creation process pretty much eliminated this. Additionally, the same user account for commenting allowed a user to post or like an event on the TO Events Calendar, so the barrier to commenting for calendar users wasn’t as high.

With all that in mind, and to encourage the conversation by making the process less painful for users, we took a fresh look at the relationship between commenting and user accounts on the Say Yeah site. For users who weren’t using the TO Events Calendar, it was clear they had no reason to make an account unless they wanted to comment, so we worked to combine these actions.

In short, we encouraged people to create accounts by attaching the creation process to a rewarding action.

Here’s how it worked.

The initial form is just two fields, asking only for an email address and comment.

Once the user enters their email address, and progresses to start writing their comment, we do a quick look up using AJAX to see if their address is in the database.

If we find it, we welcome them back and present a password field to confirm they are in fact the user we think they are.

If the email address isn’t recognized, we note that it’s their first time commenting and ask them to select a username and password.

We also suggest a username using the first part of their email address as the name. This is probably not what people will use as their name, but it gives them an idea of what we’re looking for in a username.

The button language also changes from ‘Post’ to ‘Register & Post’ to indicate that the user is indeed creating an account with us that can be used for other purposes, such as creating events on the TO Events Calendar.

The result of the change to the commenting system was an increase in comments to articles, and subsequently an increase in user accounts.

We’ve since moved away from commenting in favour of Tumblr’s system of Likes & Reblogs, but we know this process of creating accounts during the commenting process was a valuable addition to our site, as it allowed users to sign up at a time when they’re most engaged with content on the site and made an otherwise cumbersome process as simple as possible.

Would we have had more comments if we allowed users to post a comment using just their email address? Sure. But you can be sure it would have all been spam.

The post Towards better commenting on the Web. appeared first on Say Yeah!.