After years of proprietary tags, forked code, (not-so) graceful degradation, and sites best viewed on this browser or that browser, developers finally have a reasonably solid set of standards on which to build web-based sites and applications. But what about email?
For years, web developers labored under the inconsistencies and competition between browser creators. The so-called “browser wars” forced developers to provide multiple versions of markup, detection methods to determine the browser, scripts to level set the code, or some combination thereof. This led to unnecessary complexity and bloat, and even then many outliers failed to fully comply.
Fortunately, by the time responsive web design (RWD) began its rise to prominence a few short years ago, the major browser makers had settled on a large number of industry standards. The browsers these companies produce can more and more read and understand the same code. And, as the need for responsive Web design grew, this standardization greatly facilitated development across browsers.
Unfortunately, email development lags far behind web-based development. Creating HTML emails feels not unlike web development from 15 years ago: multiple email clients on the market, a lack of standardization, tables-based layouts, rudimentary inline styling, and so forth. The infusion of mobile devices, and their growing proportion of use, only exacerbates the problem. Until email clients follow the same path as browsers to reach some measure of standardization (a process that will likely take at least a couple of years), what is a developer to do to meet the needs of the growing HTML email market?
Ultimately the answer lies in the retroactive methodologies mentioned above. However, these methods can be utilized in such a way so as to create a baseline shell and reusable widgets for emails that will work across the majority of common email clients and on many different devices in use today. Furthermore, recognizing that users actually read emails even less than web pages—particularly on mobile devices—the need to focus on simplification and scan-ability becomes quite apparent.
We’ve planned a series of posts to show you how to get started with these basic, responsive HTML emails. Plus, we’ll be sharing several tools and utilities that we’ve found useful for development and testing. Today we’re going to be outlining the tools you need to gather before you get started.
Filling Your Toolbox
Properly building HTML emails is quite similar to building web pages, just with a rather different code base. Ultimately, the tools and utilities that you use to build your email marketing service will be established through trial and error, settling on what works best for you and your clients. You’ll want a reliable code editor, means to test your work, and a platform on which to host (and from which to send) your emails. One area that is a little different are the utilities to assist in building the emails so that they are viewable on the majority of email clients.
The choice of editor really comes down to personal preference, namely, the features you need and a comfortable interface. Since emails are styled almost entirely inline, the code can tend to get somewhat extensive and even jumbled, so one suggestion is something that distinguishes types of code and perhaps tags in some way, most probably through color coding. Also, an application that allows you open and neatly display multiple files (to facilitate reuse via cut-and-paste, for example) will prove useful.
Here at Authentic, we’ve used and recommend the following editors:
- Sublime Text 2
Here at Authentic, we make use of a couple of online utilities that facilitate our email development.
The first, and most prominently used, is the free CSS Inliner (https://inliner.cm/) utility. CSS Inliner bridges the gap between writing CSS comfortably as we’re accustomed for websites and pages, and the difficulties of inline CSS necessary for HTML emails. Simply write your CSS in the <head> of your email file using classes. Then paste the entirety of the code into the inliner tool, and it converts the styling to inline.
The second utility that we’ve used, but to a lesser degree, is Bee Free (http://beefree.io/), a free, online editor for responsive emails. Bee Free is, according to its builders, a bit of a work in progress. While we don’t use the utility to build emails en totale, it does provide excellent baseline code snippets and code methodologies.
With the plethora of email clients available, proper testing is essential. Nothing is more comprehensive than Litmus (https://litmus.com/), which simulates multiple platform and client combinations, including desktop, tablet, and mobile devices, as well as online applications. Litmus allows the user to annotate the tests for reference, and save configurations for later sessions.
In addition to Litmus, it’s not a bad idea to view your emails in Microsoft Word, because Outlook 2007, 2010, and 2013 use the Word rendering engine to display emails rather than a browser engine. While Litmus will simulate these clients, viewing the emails in Word locally before submitting to Litmus will reveal problems early on in testing.
Once your emails are built, you’ll need a service to send them out. Among the services that Authentic has employed for successful campaigns, are the following:
- Act-On (https://www.act-on.com/)
- Campaign Monitor (https://www.campaignmonitor.com/)
- Salesforce Marketing Cloud, formerly ExactTarget (https://www.marketingcloud.com/)
- MailChimp (http://mailchimp.com/)
- Marketo (https://www.marketo.com/)
- Sitecore EXM (https://doc.sitecore.net/email_experience_manager)
Any service is likely to have features that you want and/or need, as well as some quirks, so this choice can vary based on numerous factors. Requirements for the project and extensive research will lead you to the solution you need.
Once you have your tools ready to go, stay tuned for the next part in our Tackling Responsive HTML Emails series that will outline the process to start building the shell of an email.