Design & UX
Article

Using Forms in Email: Method or Madness?

By Massimo Cassandro

So, the first question is: why would to want to use forms in email?

It’s a good one since I personally don't believe there currently is a good reason to embed a form in an e-mail. Users will still need to submit the form to a web page, so there is really no extra convenience in terms of usability.

In addition, you now lost the ability to perform client-side validation on email forms because JavaScript and HTML5 form constraints are inconsistent.

There may be usecases where adding a form to an email is raised as an option – maybe to increase the impact of a message or to stimulate immediate user interaction (for example, to ask for a comment).

In cases like this we are not talking about something that can be solved with a simple web link.

You may have seen something like this:

A panel with Three faces - smile, passive & sad

The safest and simplest way to do that is to add a link to each smile with a specific variable to record the user choice.

But what about something like this one?

A radio button set with three faces - happy, sad and passive.

Obviously you can't use a unique link to save both satisfaction and comment, so, if you decide you don't want to send users to a web page, you'll need to add a form to your email.

I searched the web for information on email form compatibility, but only found a handful of (mostly old) articles on the subject:

On the positive side, things have not changed very much from what they describe, but out of curiosity, I decided to run some of my own tests with a simple form on some email clients.

The Form

I built a very simple mail: it contains a sample of main form elements:

  • a text input
  • two radio buttons
  • a checkbox
  • a select
  • a textarea.

For each of them I provided a default value and, in addition, the input text field had a required attribute.

I ran two test with HTML5 and XHTML 1 strict doctypes. Both versions have passed the W3C validator.

Here is the HTML5 code I used:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <title>Email form test</title>
</head>
<body>
    <h1>Email form test</h1>

    <form id="form1" action="result_page.html" method="get">
        <div style="margin-bottom:10px">
            <label for="text">Text field</label><br>
            <input required type="text" id="text" name="text" value="Some text">
        </div>

        <div style="margin-bottom:10px">
            <input type="radio" id="radio1" name="radio" value="radio 1 value" checked>
            <label for="radio1">Radio button 1</label><br>
            <input type="radio" id="radio2" name="radio" value="radio 2 value">
            <label for="radio2">Radio button 2</label>
        </div>

        <div style="margin-bottom:10px">
            <input type="checkbox" id="checkbox" name="checkbox" value="checkbox value" checked>
            <label for="checkbox">Checkbox</label>
        </div>

        <div style="margin-bottom:10px">
            <label for="select">Select</label><br>
            <select id="select" name="select">
                <option value="select option 1">Select option 1</option>
                <option value="select option 2" selected>Select option 2</option>
                <option value="select option 3">Select option 3</option>
            </select>
        </div>

        <div style="margin-bottom:10px">
            <label for="textarea">Textarea</label><br>
            <textarea cols="60" rows="5" name="textarea" id="textarea">More text</textarea>
        </div>

        <div>
            <button type="submit" name="Submit">Submit</button>
        </div>
    </form>
</body>
</html>

Here is how it appears in Chrome (mac):

Chrome rendering

The XHTML version is almost the same save for a handful of some language-specific differences.

Checked clients

I've tried both versions of the form on these clients:

Desktop:

  • Apple Mail (v.8.2)
  • Thunderbird (OSX, v.31.4)
  • Windows Live Mail 2012 (Windows 7)
  • Outlook 2013 (Windows 7)

Mobile:

  • iPad Mail (IOS 8.2)
  • Gmail App on iPad
  • Yahoo Mail on iPad
  • Outlook for IOS
  • Gmail App on Android (v.5.0.1)
  • Native E-Mail App on Android 4.4.4
  • Yahoo Mail on Android (v.4.8.4)
  • Gmail Inbox Android (v.1.2)

Webmail:

  • Gmail
  • Yahoo Mail
  • Outlook.com

Webmail versions have been tested using Firefox 35 on OSX.

The Results

First of all: changing the doctype made no discernable, difference, as both the HTML5 and the XHTML doctypes provides the same result.

All the client I've tested correctly displayed the form, with the exception of Outlook for Windows and IOS.

Overall, Outlook delivered the worst results in the test: the form wasn't rendered on either Outlook 2013/Win 7 or on IOS. Forms element were either completely dropped (IOS version) or else rendered as plain text (Outlook 2013), as you can see in the screenshot below:

Outlook - Fail.

On Outlook.com the form is correctly displayed but can't be submitted.

As you may already know, the Outlook Desktop version uses MS Word as its HTML rendering engine, and this explains most of its issues. Word is designed for document creation, not web forms. How Microsoft concluded that Word was the appropriate tool for creating email is the eternal question.

I didn't have direct access to other Outlook versions, but I was able to take some screenshot with Litmus and I got the same result in most cases.

Older versions of Outlook (which use Internet Explorer's Trident rendering engine) and Outlook 2011 for Mac (which uses Webkit) display correctly the form, though I wasn't able to confirm if they functioned correctly (I'd love to hear for anyone able to test those clients directly).

For more info about Outlook take a look at A Guide to Rendering Differences in Microsoft Outlook Clients from Litmus.

Many clients display an alert on submitting the form, so users always have the option to cancel a form sending. That's not a bad thing from a security perspective.

Here is the alert displayed by Gmail web:

Gmail alert

Note that he required attribute is completely ignored in almost all mail clients, with two exceptions: Thunderbird highlights empty required fields but the form can still be submitted. Opera Mail, on the other hand, behaves just like a browser, displaying an error message and preventing form sending:

Opera: Prevents sending

All in all, Opera Mail is the client that I was most surprised with for its speed and ease of use.

I also found it very interesting that Yahoo Mail for IOS is the only mail client that displayed the result without the use of an external browser. I think this is extremely valuable in terms of UX.

Yahoo's IOS client

This is a summary report of the tests I've made (I used the same criteria of the Campaign Monitor article cited before).

All the screenshot and the email code are available on my GitHub repository.

Client Form is displayed Form is functional
Thunderbird 31 (OSX) Y Y (2)
Apple Mail 8.2 (OSX) Y Y (1)
Opera Mail 1 (OSX) Y Y
Windows Live Mail 2012 (win 7) Y Y (1) (3)
Outlook 2013 (Win 7) N N
Outlook.com (web) Y N
Yahoo Mail (web) Y Y (1) (3)
GMail (web) Y Y (1) (3)
GMail App (Android) Y Y (1) (3) (4)
GMail Inbox (Android) Y Y (1) (3) (4)
Yahoo Mail App (android) Y Y (1) (4)
Android Mail (4.4.4) Y Y (1) (4)
Gmail App (IOS 8.1.3) Y Y (1) (3)
Apple Mail (IOS 8.1.3) Y Y (1)
Outlook for IOS (IOS 8.1.3) N N
Yahoo Mail for IOS Y Y (1) (5)
  1. The required attribute is ignored
  2. Fields with required attributes are highlighted if empty, but the form can be submitted anyway
  3. Alert on submit
  4. Input text and textarea fields are not editable
  5. Result page is opened inside the app

Conclusion

My conclusion, in this case, turns out to be very simple: Don't use forms in emails. Support is extremely uncertain and in most cases you can not use even the most basic functionality.

There are already examples of how it would be possible to make e-mail an extremely effective tool: if email clients began to implement web standards in a consolidated way, this outcome could be achieved.

Comments
felgall

From a security perspective forms in an email are something to definitely avoid - even if your testing had given different results and shown that they could actually be made to work across all of those email clients.

There would be no way to tell which spammer you were transmitting the form to (unlike links to web pages where at least some browsers will give you a some idea of where they really go if you hover over them).

If using forms in emails actually worked then all spam emails would include forms to collect information from anyone who is misled into opening it and filling out the form. Not only would the spammer confirm their email address (as they can if the person clicks a link in their spam or allows remore images) but they also get the information the person typed into their form.

Those email clients that refuse to display the form are far more secure than those that simply displaya dialog telling the person they can cancel submitting the form.

alexmwalker

Agreed. Currently it's arguably easier to obfuscate where a link is really going on a webpage than it is in email. I can code a webpage link to Google.com, but overwrite it with 'evilspammer.com' as you click it, as long as JS is available. In email I can't think of a way of hiding a bad link from hover.

But a form would allow you to hide that URL destination away from anyone not viewing and understanding the source.

I wonder why browser makers have never tried to feed the destination URLs from forum submit buttons back to the status bar?

ralphm

It's so simple just to provide a link to an online form that it seems pointless to fret over how forms can be placed in emails. Of course, clients and their whims are always the fly in the ointment. It's good to have articles like this to point them to, all the same!

I often take my lead on this sort of thing from the major emailing services themselves, and even they don't like the idea much. See this, for example: https://www.campaignmonitor.com/resources/will-it-work/forms/

pinoniq

FYI: The reason microsoft uses Word to render html in outlook is very simple: In the earlier days, IE was used. So everything worked perfectly well. But then came along politicians (EU) who prohibited this. The reason IE is not allowed to be used as rendering engine in Outlook is that IE is delivered as part of Windows and not as part of Office. And Outlook is part of office.

It's the same reason we now have Windows versions without Windows Media player (atleast in the EU).

ralphm

That's not a reason to use Word as a rendering engine, though. Why not build something that makes the web work properly? It's appalling what they've done to email.

massimo_cassandro

In my opinion emails are a very good tool for communication and marketing, and could be better if the clients were improved with greater adherence to standards and more attention to the security issues rightly reported in previous posts.
Right now, forms in email are a very bad choice but, I think, it could be possible make them work fine.

About Outlook.I think that the problem arises from the choice, more than legitimate, to integrate it with the Office family. Unfortunately, as we have seen many times before, the "rest of the world" was not taken into account ...

Mittineague

To me, emails are NOT web pages. Text and a few small weight non-beacon images are fine. But if a page is wanted, link to it. Please

ralphm

Yes, and that's the problem. MS should have learned during the browser wars that doing your own, proprietary thing is ultimately doomed to fail, and is bad for the community as a whole, too. Sadly, the message still isn't getting through to some parts of the company. frowning

Recommended

Learn Coding Online
Learn Web Development

Start learning web development and design for free with SitePoint Premium!

Get the latest in Design, once a week, for free.