Our old contact form had some characteristics that most people would consider good. It was linked to from our footer, which is a common place for people to look. And we listed our phone number and our email address, so we were easy to get a hold of. People often used both. They would email and then they would call just to make sure we get email.

The problem
Unfortunately, we overlooked an important point. Most people who found the contact form were not looking to contact us–they were looking to contact the site owner (for example a conference organizer). Apparently many of the organizations that we work with have contact info that’s so hidden, ours, buried in the footer of an interior page several clicks into their site, is the first that a visitor can find. We would get a lot of questions from people who hadn’t even heard of the social network yet. Did my registration go through? Do you have student discounts to attend the event? How do I buy an exhibition booth?

Here is how we redesigned our contact form to make it possible for people to get through to the site owner, while also making sure users can still get great technical support.

Features
For small features (like this one) I start by listing out our goals. Usually I’ll break the list into two parts, the first part is for things that have to be done (must dos) for the feature to launch. We launch improvements whenever we have free time and the only test we hold ourselves to before launching is, “Is this better than what’s there right now?” The second part is for embellishments, things that are going to make the feature amazing (there are many definitions of amazing).

Must dos:

• Site owner is contactable
• CrowdVine is contactable for software support
• Clear delineation between the site owner and Crowdvine
• Site owner is not subject to spam

Embellisments:

• Contacter feels heard or at the very least, we set clear expectations
• Form adheres to current form design best practices (I have to look those up)
• Code adheres to Rails best practices

On the embellishments, remember, our old contact form was completely broken. The difference between broken and good is much bigger than the difference between good and best. Although, you should be able to guess, since I’m writing this blog post, that I got all of the embellishments in.

Gotchas
Then I ask, is this going to cause anyone any trouble? Well, yes, a little bit. If the site owner has a preferred way of being contacted then this feature is going to co-opt it. I think as a default, that we’re doing the site owner a service. Many of the people we hear from want to give the site owner money (either registration or sponsorship). But what if the site owner really wants people to go through a different contact form? In that case, we’ve got to give them a way to change the default.

Mockup
I use a web-based tool, Balsamiq, for mockups. This lets me work out design issues and get feedback quickly. Here is what the initial mockup looked like:

The hardest design decision was how to communicate who you are contacting. It’s a bit much to expect a visitor to your website to be able to parse the difference between your organization and your service providers. But on the other hand, there’s no hiding that CrowdVine and our customer are two different organizations that respond to different kinds of contact requests. In the end, we settled on radio buttons for the site owner, us, or both. The “both” option is so the visitor doesn’t need to make a decision. We thought hard about having all emails go to both parties but then decided it would create a logistical hassle for the site owner.

The easiest design decision (because I knew the answer going in) was how to prevent spam. We’re using the ReCAPTCHA service, which is a CAPTCHA (prevents automated spam by making people read and type a random text) that pulls random text from digitally scanned books. The work that people do to complete the captcha goes toward digitizing the text.

Contacter Love
The reason I wanted to put some thought into making the contacter feel good is because so many of the people we talk to seem lost, angry or annoyed. They need help now, they’ve been clicking all over, and they found contact info but they don’t trust that they are going to get a response. Our contact form isn’t magical. It just moves the person one step closer to a solution–it can’t actually solve the problem. But I do think that with clear communication, the contact form can be a calming and reassuring step.

There are two places were we tried to be exceptionally clear (or at least transparent). First, we’re exposing the difference between us and the site owner. For most people this is the first time they’re hearing about us, so we tried to give a clear explanation.

Second, we also want to set expectations for when a person will hear back from us. CrowdVine is on California Pacific Time and we aim to respond within one business day (we’re often faster or responding during off hours, but we want to give ourselves a chance to exceed expectations). Setting default expectations for our customers is a little trickier–we don’t know their response times. Here’s the default language we’re using:

Your message was delivered to a real person at SITE NAME, but there may be other official contact channels on other portions of their site. If you do not receive a prompt response from SITE NAME you may want to keep looking for other contact options. To set your expectation on the definition of prompt, many organizations of lesser quality than SITE NAME take several business days to respond.

I want that text to communicate: “You have successfully contacted this organization. Somebody has heard you. However, let’s be real, this isn’t a customer support hotline. Give the organization a chance to get it’s act together. If you really need instant help, you should keep looking for another contact option.”

Contact Form Best Practices
I did some research on form best practices and the best information I cam across came from LukeW Interface Designs. You can buy his book but most of my questions were answered by his Web Form Design Best Practices presentation.

This may sound pedantic, but I was really curious to find out what the current thinking was on placement of form labels. It turns out there’s good research comparing top-aligned, to the side and left-aligned, and to the side and right-aligned. Each has pros and cons. For us, we clearly fit the characteristics of a form that should have top-aligned labels (as demonstrated in the mockup above). This style of labeling works well with forms people are familiar with (ours looks like many other contact forms and also a lot like an email composition form). The only problem with looking up best practices for one feature is that you start to feel bad about other parts of your site.

There’s no need to indicate required fields. They’re all required. Also, we don’t have a cancel button. The best practice advice was to either minimize secondary actions (like Cancel) or eliminate them. For ten years I’ve wondered why so many forms have cancel buttons and I couldn’t figure out why we would have one on this form. Maybe somebody will use this contact form to ask us to add the cancel button back.

The next form design best practice is to provide sensible defaults. I got this far in the design before I remembered that some of these users are already logged into CrowdVine so we already have their name and email. So we can pre-fill those.

Rails Contact Form Best Practices
In Rails, the way that you validate forms that aren’t tied to a database model is with ActiveForm. Many of the blog posts about using ActiveForm use a contact form as an example use case. Clearly, this is the right model for us. However, I couldn’t figure out which is the proper plugin to install. There’s a competing, but different Gem, and there are several forked branches of the plugin on GitHub. I’m pretty sure this is the one to pull from:
http://github.com/cs/active_form

The ReCaptcha plugin worked great, except that I couldn’t find a way to write a functional test to submit the form with correct Captcha text. I worked around it by getting as close as possible to submission in my functional tests and then making sure the unit test coverage was good.

I did some searching for a ruby library for email validation. Even though everyone and their brother writes their own regular expression for this, I know the best practice is to go with something that’s well tested. Unfortunately, in Rails, it’s nearly an officially sanctioned practice to go with this liberal, but incomplete regex: /\A([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})\Z/. That regex is even in the official Rails documentation. So, that’s what I did. For regex geeks, the characteristics of that regex are that it accepts some malformed emails, but never (I think) rejects valid emails.

Liquid Templates
Remember the gotcha about wanting to give sites an option to opt-out of this feature? We open up a lot of CrowdVine for customization through Liquid templates. Liquid is a user-safe templating engine, which means it’s safe for one site to edit and change a template without having access to data from other sites. In this case users have three places to override our default contact form. They can edit the template with our footer links and link somewhere else. They can edit the contact page template and put their own contact information. Or, finally, they can edit the contact-received page that people see once they’ve submitted the contact form (for example if the site wants to be more explicit about when they will respond).

We basically love Liquid templates although there seems to be a lot of magic going on, so I’m never sure when we start in on one whether it’s going to be straight forward to complete. In this case, my big concern was whether ActiveForm would play well with Liquid. The good news is that they did–you can open up your ActiveForm model attributes with the liquid_methods shortcut (this makes sense once you start working with Liquid templates).

How would you make this even more ultimate?

Related Posts:

• No Related Posts