Experiment: Should I use forms in email
On Pechkin's blog on Habré, we write a lot about interesting techniques for working with email newsletters . Earlier, we considered common mistakes when creating forms in e-mails, and today we bring to your attention an adapted translation of a note by Italian designer Massimo Cassandro, who decided to find out whether this tool should be used at all in the layout of email-messages.
Why it might be necessary
Cassandro himself says that he does not consider the use of forms in email as a good practice - users will still have to go to a web page, so this will not give us any convenience in terms of usability. In addition, the ability to perform validation on the client is lost, because the limitations of JavaScript and HTML5 are inconsistent.
Sometimes there may be use cases in which a form appears as an option in a letter — for example, to encourage immediate interaction with users (you may need to ask for his comment). In such cases, a simple link to the external page will not succeed.
')
Perhaps you met something like this in the letters:
The easiest way to implement this is to add a link with a variable to record the user's choice for each smiley.
But what if you need to implement something like this:
Obviously, using a unique link to save rating information and comment at the same time will not work. Therefore, in order not to send users to an external web page, you need to add a form to the letter.
Unfortunately, the network is not so much information about which email programs will support the form. There are a couple of old articles in English ( one and two times ), and in Russian it is extremely difficult to find anything at all. By and large, since the writing of those materials, the situation has not changed much, but it will not be superfluous to get an idea of how things are now.
The form
Massimo Cassandro decided to conduct an experiment by creating a simple form that contains several elements:
- Text entry field;
- Two radio buttons;
- Checkbox;
- Element Select;
- Zone with text.
For each of them, the default value was set, besides the text input field had the required attribute.
The test was conducted for HTML5 and XHTML 1 strict doctypes. Both versions passed through the W3C validator. Below is the code 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> This is how it all looks in Chrome for Mac:
The XHTML version is almost identical to the one presented above.
Participating clients
Both versions of the form are checked on the following mail programs:
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)
Web:
- Gmail
- Yahoo Mail
- Outlook.com
Web clients were tested in Firefox 35 for OSX.
results
First of all, it is worth noting that changing the doctype had no effect on the results. All tested clients correctly displayed the form.
The only exception was Outlook for Windows and iOS. In the case of this program, the form is not rendered either on Outlook 2013 / Win7 or on iOS. The form elements were either completely cut out (iOS), or shown by playtext (Outlook 2013):
The form was correctly displayed on Outlook.com, but it was impossible to send the entered data.
Perhaps you know that Outlook Desktop is used as the HTML rendering engine for Microsoft Word, which explains a lot. Word is designed to create documents, not to display web forms. So Microsoft decided that using it to create an email would be a great idea - a separate question.
Cassandro did not have direct access to other versions of Outlook, but tests conducted using Litmus software showed that the result in their case would be about the same.
Older versions of Outlook, which used the Trident rendering engine from Internet Explorer, and Outlook 2011 For Mac (use WebKit) display the form correctly, but the question remains about the possibility of sending data.
Often, e-mail programs displayed an alert warning the recipient of the letter that he was sending data to an external site. From a security point of view, not a bad decision. This is how the alert appeared in the Gmail web client:
An interesting point - the required attribute was ignored by almost all email clients. The only exceptions were Thunderbird - highlighted fields marked with attribute, but you could send the form without filling them out - and Opera Mail - here the behavior was similar to the browser, with an error message and the impossibility of sending.
By the way, Opera Mail turned out to be one of the fastest and easiest to use email clients.
It also turned out that Yahoo Mail for iOS is the only client that displays the result without using an external browser. Valuable skill, in terms of UX.
Below is a table with the results of the experiment (screenshots and code are available in the repository on GitHub ):
| Customer | The form is displayed | Form works |
|---|---|---|
| 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) |
- The required attribute is ignored.
- Fields with required are highlighted if there is no data in them, but the form can be sent.
- There is an alert when sending.
- The text in the form can not enter and edit.
- The results page opens inside the application.
Conclusion
The result of the experiment allows you to declare that you should not use forms in email. Support for this functionality is very limited, often even the most basic elements will not work.
Source: https://habr.com/ru/post/268927/
All Articles