I am elbow deep in wireframing at the moment and loving every minute. I love the nuances that can turn an average user interface into something that is a pleasure to use. Its this kind of attention to detail that is at the heart of our work at Headscape.
A recent example of this was giving the user the ability to contact a client via email.
Looking beyond the obvious approach
There are two normal approaches to contacting somebody via email from a website – an online form or a mailto link.
Both have their pros and cons. If you post your email address on a website the chances are it will be harvested and so you will receive a huge amount of spam.
If a form is setup correctly this spam can be largely avoided, but forms aren’t generally as convenient for the user:
- They can be fiddly to use on mobile devices.
- It’s not unusual for the content of a message to be lost if your connection drops.
- A copy of your message does not appear in your sent emails.
- The user cannot copy the email address for later reference.
Personally I am not a fan of making my problems (the chance of spam) the problem of my users (the drawbacks of online forms). I therefore decided to post email addresses online and risk the spam.
I could of encoded these email addresses with Javascript to reduce the chances of them being harvested, but this throws up various accessibility concerns.
What happens when they click?
This still left me with an issue – what happens when a user clicks on an email address?
The most obvious option was to launch the default email client using a mailto link. Unfortunately things are rarely straightforward.
A large number of users don’t use their native email application, instead relying on web based email. I have been in user testing when a person clicks on a mailto link only to be confronted with the “configure outlook” screen. This left them totally confused as they didn’t use outlook.
The second option was to go through to an online form, but that just brought me back to the problems inherent in online forms.
My final option was to copy the email address to the clipboard when the user clicked the address. You could then display a little popover telling them they could now paste this into their email client.
Although an unusual behaviour that would need explaining, I felt it had the potential to be useful. However as somebody on Twitter pointed out this could prove annoying if it overwrote something already in the clipboard.
In the end I decided to take a leaf out of iOS book. On rollover the email address would display three tooltip options and the user could choose:
- Open in email client
- Email from website – that would take the user to a form
- Copy email to clipboard
If Javascript was not available (as the popover would be reliant on it) then the user would be taken to the form, but it would also display the email address with a mailto attached.
The moral of the story
The reason I have posted this little anecdote isn’t to suggest this is the best way to handle the problem of email. It’s to show that even simple things can prove considerably more complex than they first appear. More importantly, it shows why web quotes often vary so massively. A designer with less time and budget would have just added a mailto link, but I was in the position to create a more robust experience because I had quoted a higher price for the project. I guess at the end of the day it comes back to the old adage “you get what you pay for.”
“Contact Us Blue Key” image courtesy of Bigstock.com
