What do we do with email?

Email is an interesting channel and is often widely promoted as a choice of communications. On council websites you will see a variety of approaches which essentially trigger emails – individual emails, team emails, forms etc.

As we work on redeveloping the councils website we have started to think more and more about how we manage email on our site and how we make it accessible and usable across all size browsers.

One of the current challenges is that the mailto: attribute doesn’t work if someone uses a web based mail client such as gmail, yahoo mail, hotmail etc and would essentially have to copy and paste the email address into the “to” box.

On mobile devices (if the settings have been enabled) if you select a mailto: attribute you will often open the default email client on your phone or tablet.

We’ve thought that a contact form might be the best way to go, but what would someone do if they required to send attachments and or maintain copies themselves…this is obviously achievable in a contact form, but should we provide a “file store” for uploaded files, do we have a maximum size etc…

So we are currently thinking and discussing as a team “what do we do with email?”

We broadly see five options

  1. maintain existing approach and don’t address the user issues
  2. use a script that displays an option to open email in your desktop application or to use a contact form
  3. don’t use the mailto: attribute at all and simply display plain text
  4. to provide a copy to clipboard option next to the email address
  5. a combination of the above

What do people think, what examples have people found where email works well across all browsers and devices and doesn’t require a user to copy and paste manually…

Tim Barrett

I am a frontend developer for Devon County Council. I work mainly on WordPress and PHP.

More Posts

Follow Me:
Google Plus

4 comments on “What do we do with email?

  1. Sophie Dennis on said:

    I’m inclined to think that you may be overanalysing the problem with regard to regular webmail users. I expect they are used to dealing with mailto: links. However, it occurs to me that the contact form option might be important for people who don’t actively use email at all. This may be an important consideration where you are concerned about making services accessible to the ‘digitally excluded’.

    Overall it seems to me this is a perfect candidate for some quick prototyping and real-world user-testing. Find out what users actually do and find easiest, rather than speculating about it. Put some samples/prototypes together – or use existing pages and tasks which involve contacting the council by email – and observe real users completing the task. Do webmail users find copy and paste difficult or confusing, or is this something they are familiar with doing? How convenient is a mailto: link for desktop email users and mobile users compared to a web form?

    A user survey might be a good idea to identify if lack of access to personal email is an issue, if you don’t already have that information.

    On a few specifics, I don’t feel either options (3) or (4) are worth pursuing. Obviously with mailto: you would want to require the full email address to be visible and selectable, ie your style guidelines would need to enforce the format “email Tim Barrett at [timsemailaddress@devon.gov.uk]” as opposed to “[click here to email Tim Barrett]” (where the square brackets indicate the clickable link). Provided you do that, I don’t see how (3) a plain text email address is any better for users than a mailto link – in fact it seems worse as *no one* gets to click it to trigger their email programme. I am also not sure (4) is worth the development effort to simply duplicate native functionality, but again user testing would reveal if “not knowing how to copy and paste” is an issue or not.

    I think option 2 may have value. I would probably skip the script, and go for a simpler option which used a standard wording such as “email Tim Barrett at [timsemailaddress@devon.gov.uk] or use the [contact form]“. You could then develop a generic contact email form with the to: address passed through from the link. This would reduce duplicate development and hopefully be simple to create in the CMS (in WordPress, some form of custom shortcode maybe?).

    With the contact form, it would obviously be possible to give people the option to get a copy of their message emailed to them (see e.g. eBay messages for a design pattern for that). I would suggest an audit of how email is currently used and again user testing to answer the attachments question – ie do people currently send attachments? Of course, with the hybrid approach you could decide to make the call that if people need to send attachments, they need to use their own email programme and not rely on the contact form.

  2. Stian Sigvartsen on said:

    It’s sometimes good to explore things that we take for granted on the web. You’re right that there exists a problem with “mailto:” in HTML in that web clients aren’t even considered. My thoughts are that rather than deviate from the semantics that “mailto:” provides (i.e. an action to send email), we should let browsers & associated standards catch up and actually implement discovery support for web clients. Possibly HTML5 “intents” is a foundation for this.

    On the topic of email as a delivery mechanism for submissions web forms. This truly is a flawed concept and the cause of much wasted staff time. Any interaction should be considered a transaction. Emails can get auto-deleted by filters based on wording or attachment type/size, which is terrible and leaves the customer thinking that we will get back to them at some point whilst we remain blissfully unaware they have even attempted to contact us. Nice. A new option 6 is now available.

    As you know the new web service delivery architecture for DCC that you are integrating websites with encompasses a few components relevant to this discussion.

    * Authenticated user access, allowing the customer to choose their preferred authentication method whenever this satisfies the security requirements of the service they are interacting with. This component is on-going work and your input would be valuable.
    * Role based content delivery
    * Standards based web forms solution, which does device detection and provides native input controls for devices like the iPhone. Submissions are stored into a database and can be version controlled.

    The integration of these components is enabling self service solutions to be delivered and a move away from reliance on email. Of course it is quite useful to provide the customer with a receipt email nevertheless, though not critical to the process of service delivery. If the customer isn’t interested in self service (the user authentication aspect), they don’t have to register for it. It’s their choice. Registration should be at the end of the interaction when the customer’s immediate need has been met and only there to either let them make amendments, track actions related to the current interaction, or make future interactions quicker/easier.

    We’re in the middle of migrating our 300+ web forms to the new web service delivery architecture at which point they will be “freed” from DCC’s current corporate CMS and can be placed on your and other websites as widgets. Nice. Would be great to have your input to help make the integrated experience better for the end customer :)

Leave a Comment

Your email address will not be published. Required fields are marked *

Comments are held for moderation. House rules