diff options
Diffstat (limited to 'build/posts/plain-text-emails/index.html')
| -rw-r--r-- | build/posts/plain-text-emails/index.html | 109 |
1 files changed, 109 insertions, 0 deletions
diff --git a/build/posts/plain-text-emails/index.html b/build/posts/plain-text-emails/index.html new file mode 100644 index 0000000..0bed7e0 --- /dev/null +++ b/build/posts/plain-text-emails/index.html @@ -0,0 +1,109 @@ +<!doctype html> +<html lang="en"> +<head> + <meta charset="utf-8"> + <meta name="viewport" content="width=device-width, initial-scale=1"> + <meta name="color-scheme" content="dark light"> + <link rel="icon" href="data:,"> + <title>Plain Text Emails, Please</title> + <link href="/atom.xml" type="application/atom+xml" rel="alternate" title="Atom feed for blog posts" /> + <link href="/rss.xml" type="application/rss+xml" rel="alternate" title="RSS feed for blog posts" /> +<style>*{box-sizing:border-box;}body{font-family:sans-serif;line-height:1.33;margin:0 auto;max-width:650px;padding:1rem;}blockquote{background:rgba(0,0,0,0.1);border-left:4px solid;padding-left:5px;}img{max-width:100%;}pre{border:1px solid;overflow:auto;padding:5px;}table{text-align:left;width:100%;}.footnotes{font-size:90%;}</style> +</head> + +<nav> + <a href="#menu">Menu ↓</a> +</nav> + +<main> +<h1 id="plain-text-emails-please">Plain Text Emails, Please</h1> +<p>2019-09-09</p> +<p>When it comes to website / product design and development most devs should try to keep things simple. By only using as much code as absolutely necessary, projects avoid growing out of scope or becoming bloated. So, why isn’t this same approach taken for email?</p> +<h2 id="a-brief-history-of-email">A brief history of email</h2> +<p>Email has been possible since the 1960s with <a href="https://en.wikipedia.org/wiki/Time-sharing">time-sharing computers</a> being used to share files and messages across early devices. Around the 80s and 90s it seemed as though <a href="https://en.wikipedia.org/wiki/Government_Open_Systems_Interconnection_Profile">GOSIP</a> would dominate the market, but this was knocked out in favor of SMTP, POP3 and IMAP in 1995 when the <a href="http://www.walthowe.com/navnet/history.html">National Science Foundation ended its sponsorship of the Internet backbone</a>, and all traffic relied on commercial networks.</p> +<p>Things were looking pretty good at this point. Most operating systems now had a shared foundation of sending and receiving emails on the internet, allowing for a set of standards to be slowly developed and agreed upon over time. These were simpler times, with the default content sent between machines being plain text. No embedded images, no CSS3 fallback support, no <em>fluff</em> - just content.</p> +<p><strong>Sidenote:</strong> +Now, I’m not going to sit here and pretend to be some expert on the history of email (or the internet in general), so I suggest you take the time to read about <a href="http://www.walthowe.com/navnet/history.html">the history of the internet</a> if you’re into that kind of thing.</p> +<h2 id="looking-at-some-data">Looking at some data</h2> +<blockquote> +<p>Data isn’t everything</p> +</blockquote> +<p>I understand that the data being used is currently 16 years old - but not many extensive research studies have been performed (specifically for email-type preference in general)</p> +<p>In 2002[1], <a href="https://www.clickz.com/real-world-email-client-usage-the-hard-data/47429/">a small-set survey was run by ClickZ</a> was created to gauge the details of personal email data. The main data we will focus on is the user preference between HTML or plain text formats:</p> +<p><strong>Do you prefer receiving HTML or text email?</strong></p> +<table> +<thead> +<tr> +<th>Response</th> +<th>Percentage (%)</th> +</tr> +</thead> +<tbody> +<tr> +<td>HTML</td> +<td>41.95</td> +</tr> +<tr> +<td>Plain Text</td> +<td>31.52</td> +</tr> +<tr> +<td>No Preference</td> +<td>26.53</td> +</tr> +</tbody> +</table> +<p>On initial review, one could make the argument that the general public <em>prefers</em> HTML email over plain text (~42% vs ~32%) - but I would disagree with this analysis. The roughly 27% of respondents who answered with <em>No Preference</em> should not be dismissed so easily.</p> +<p>Since the <em>No Preference</em> respondents don’t care whether emails they receive are designed in HTML format, why not send them plain text variations by default? The positives of plain text greatly outweigh those of HTML:</p> +<ul> +<li>Plain text has reduced file size +<ul> +<li>Don’t forget that many users have limited data usage across much of the world</li> +</ul></li> +<li>HTML is more likely to be flagged as spam by email clients +<ul> +<li>This is due to extra code, tracking scripts, 3rd party assets / resources being called</li> +</ul></li> +<li>HTML / CSS can be inconsistent or even limited in support across email clients</li> +<li>Text only requires less design work for your development team +<ul> +<li>Don’t forget about testing all the various email clients too</li> +</ul></li> +</ul> +<p>Add to this that <a href="https://litmus.com/blog/53-of-emails-opened-on-mobile-outlook-opens-decrease-33">53% of emails are opened on mobile</a> - so any “fancy” marketing email designs need to look great on mobile screens and also take into account slower connections. What looks better and loads faster than simple plain text? 😛</p> +<h2 id="but-what-about-marketing">But what about marketing!?</h2> +<p>Sorry to say, but marketing should never trump user experience. Teams love to track email opens / click ratios, who subscribed / unsubscribed or who shared the campaign with others - but <strong>it’s all bloat on the user’s end</strong>.</p> +<p>Greg Kogan wrote up a great article / case study about his experience <a href="https://www.gkogan.co/blog/dont-design-emails/">switching over a client’s campaign from HTML templates to plain text</a> with some really interesting results. I highly recommend you give it a read for a better understanding about how the marketing goals and customer goals don’t always align.</p> +<h2 id="simple-or-lazy---it-doesnt-matter">Simple or lazy - it doesn’t matter</h2> +<p>Plain text can certainly have a reputation for looking lazy or cheap, but I feel this is mostly perpetuated in the design and marketing communities. I can assure you that your average day-to-day users are much less opinionated about your email campaign design than you are. Look to satisfy your customers’ needs before your own.</p> +<blockquote> +<p>Life is really simple, but we insist on making it complicated.</p> +<p>- Confucius</p> +</blockquote> +<p>That being said, at the end of the day, companies will justify their own reasons to use HTML email templates over plain text. You can’t convince everyone. My own personal experience with email template design, along with analyzing some of the data, leaves me to believe that most businesses should default to plain text. At the very least, you should try to convince your team to perform some simple A/B testing with your next email campaign.</p> +<p>The results might just surprise you.</p> +<h2 id="refs">Refs</h2> +<ol> +<li>This is the “latest” detailed survey I could find on email design preference</li> +</ol> +<footer role="contentinfo"> + <h2>Menu Navigation</h2> + <ul id="menu"> + <li><a href="/">Home</a></li> + <li><a href="/projects">Projects</a></li> + <li><a href="/uses">Uses</a></li> + <li><a href="/wiki">Wiki</a></li> + <li><a href="/resume">Resume</a></li> + <li><a href="/colophon">Colophon</a></li> + <li><a href="/now">Now</a></li> + <li><a href="/donate">Donate</a></li> + <li><a href="/atom.xml">RSS</a></li> + <li><a href="#top">↑ Top of the page</a></li> + </ul> + <small> + Built with <a href="https://git.sr.ht/~bt/barf">barf</a>. <br> + Maintained with ♥ for the web. <br> + Proud supporter of <a href="https://usefathom.com/ref/DKHJVX">Fathom</a> & <a href="https://nextdns.io/?from=74d3p3h8">NextDNS</a>. <br> + The content for this site is <a href="https://creativecommons.org/licenses/by-sa/2.0/">CC-BY-SA</a>.<br> The <a href="https://git.sr.ht/~bt/bt.ht">code for this site</a> is <a href="https://git.sr.ht/~bt/bt.ht/tree/master/item/LICENSE">MIT</a>. + </small> +</footer>
\ No newline at end of file |