Losing touch with contact forms

99park-editing

Illustration by Greg Storey

Anyone who has ever sat down to write a blog post has done so with the hope that their words will have an impact on someone—to make some sort of a connection. So it stands to reason that we want to give our audience a convenient way to connect with us.

In the earlier days of the web, this was done by simply providing an email address somewhere in a “Contact Us” module. But when the internet became largely evil, spammers made short work of publicly available email addresses, spamming them into obsolescence. 

This is one reason why contact forms exist. Instead of exposing an email address, contact forms give users a UI for writing to blog owners, from within the blog.

form

An example of a contact form from the LexBlog platform.

The form submission is handled in private, on the web server, without the sender ever even knowing the recipient’s email address.

In addition to the anti-spam concern, contact forms have become a habit of sorts. A de facto requirement for blogs, just because. The UX community has developed the tacit assumption that contact forms are a better experience for users than copy/pasting an email address. The time has come to question that assumption for two reasons:

  1. Spam filters have mostly gained the upper hand in the spam war. It’s uncommon for an inbox running on an enterprise level email system to see an onerous volume of spam. If it does, that’s an indictment of the spam filter in place, not an indictment of email in general.
  2. It turns out users don’t like contact forms.

Who doesn’t love a good contact form? Most users.

The UX Collective conducted an interesting survey on user preferences for contact methods:

Created by potrace 1.16, written by Peter Selinger 2001-2019 quote-left

By doing this survey I found out that most people’s preferred method is contacting via email (41,8%), either by clicking a hyperlink (16%) or copy/pasting the email address into their preferred email client (25,8%). Surprisingly the second most popular method was via chat platforms (27,5%). On the other hand, one thing that did not surprise me at all was that people tend not to trust contact forms and if the website displays both a contact form and an email address, most people will use the email address (67,3%).

Wow! It’s amazing to think of all the work that goes into contact forms, only for it to end up harming the user experience. How could the industry have gotten this so wrong for so long?  A few reasons.

  1. More of our life and work takes place online, and we’re tired of filling out forms. It wasn’t always like this. We spend more of our time filling out forms than we used to, and we dislike it more than we used to.
  2. It used to be the case that filling out a form was easier than firing up email software, digging out a password, logging in and finally writing. That’s not how people email anymore. Many of us have Gmail open in a tab at all times.  Nearly all of us have an email app on our mobile device that we’re already logged into.
  3. Paper forms have existed for a long time, so they were intuitive for users in the early days of the internet.  Meanwhile, email seemed like alien technology. That’s obviously no longer the case: We appreciate the convenience of having an address book, drafts, a record of past conversations. Many of us email ourselves to quickly stash notes or documents.
  4. We’ve been burned too many times and we no longer trust contact forms.  Everyone reading this has felt the frustration of submitting a form, not feeling quite sure if it “went through,” and never getting a response. Email is better in this regard because invalid or non-existent email addresses will trigger a warning. More importantly, we know our email clients work. The same cannot be said for your garden variety contact form.

Computers don’t like contact forms either.

The UX concerns are significant, but there’s also security. Contact forms are an attack vector. Any sort of form is going to be a magnet for malicious bots attempting to hack into the blog and cause mayhem. Even if there’s no actual vulnerability, it still creates extra traffic that can draw on server resources.

Of course, don’t hear what I’m not saying: Contact forms on the LexBlog network are not an out-and-out security vulnerability. But more code means more problems. Occam’s razor applies here.

These issues are persuasive. Every blog should consider trading in their contact form for an email address. In doing so, there are a couple of best practices to keep in mind when providing an email address instead of a contact form.

It’s possible to screw up email as well.

It’s a good idea to wrap the email address in a link, so that users who wish to do so can simply click on the link and automatically get a draft started in their default mail client. This is great for mobile users and for folks who use a desktop application like Outlook.  

It’s an even better idea to spell out the email address in its entirety, as opposed to merely displaying something like “email us,” so that users can easily copy and paste the email into a browser-based email client like Gmail. The end result would be something like:

<a href=”mailto:hi@hi.com”>hi@hi.com</a>

That’s user friendly for both browser-based, and OS-based email.

Let’s stop assuming and start observing.

We’ve used contact forms for years on our platform, born out of the assumption that it was a better UX than the alternatives. While I’ve begun to suspect that’s a false assumption, I don’t want to combat one assumption with another. I want data.

That’s why I’m in the process of deploying a plugin to the LexBlog network, to listen for successful form submissions. We won’t be recording or observing the content of the form submissions, we’ll just be counting them. At the same time, we’ll be recording the number of clicks on `mailto:` links. After a designated time period, we’ll tally up the results. While not the sole factor, this data will inform our recommended practices for all blogs, and potentially change the configuration for the templates we use for new blogs.

Scott is a WordPress theme and plugin developer with a penchant for connecting the dots between services like MailChimp, Cloudflare, and GoDaddy. He has been published in A List Apart and CSS-Tricks.

Photo of Scott Fennell
Subscribe to 99 Park Row via Email or RSS
Recent Posts
See our Archives for more.