Email Renderability Testing with Code Based Previews vs. Screen Captures
To date, there are two different methods for generating a preview of an HTML email in the most popular email clients. Each solution comes with its own set of challenges and limitations. In this article, we’ll watch as the Tortoise and the Hare battle it out to see which strategy wins the race.
The first approach is to send your email through each email client application and parse together a screen capture of the final result.
Though it may sound like an easy and straight forward task, the Tortoise has some fairly extensive technical challenges. For one, his strategy requires that each of the email clients and mail server ISPs are prompt in processing the original email. It also requires a number of different servers, each processing screen captures for one particular email client. In order to guarantee each email client is up and running, additional servers are required for redundancy.
Using this technique, your email is sent to each individual email client as soon as you submit an email for testing. From there, test results will return in the order that they are received and processed. This allows you to peruse your test results as they become available to you.
Let’s take a look at a complete list of pros and cons that may come up with regard to the Tortoise’s strategy.
- Completed screen captures will always provide an exact preview of your email.
- You can store each of the test results to ensure to your customer or supervisor that you tested your email at a specific day and time.
- Test results will come in as they are completed so you will not have to wait very long to start browsing through your results.
- Text wrapping and subtle font differences between browsers and operating systems will always be precise and accurate.
- It may take longer for you to receive a complete test result in all supported clients and spam filters
- The service is dependent on each of the web based email clients. For example, if Hotmail where to get bogged down, that particular email preview might take longer to process.
- It requires a considerable amount of load balancing and redundancy.
- For long, vertical scrolling emails, it may require 4 or more screen captures to be parsed together. This increases processing time.
- If the email contains large images or the server that is hosting the images is very slow, the process must wait until the entire page is loaded before a screen capture is taken. This corrects broken images being displayed in the preview and ensures the page is parsed correctly, however processing times may increase dramatically.
- Requires a considerable amount of storage for all of the screen captures.
- Web based email can be opened across a variety of different browsers, and desktop clients can be installed on a variety of different operating systems. It is difficult to provide a separate screen capture in every possible combination.
- With a screen shot, you won’t be able to test the interactivity of your email such as the links, image maps, hover effects, and animated gifs.
Code Based Previews
The Hare’s approach is to generate a preview by analyzing and parsing your original HTML and CSS code much like each of the email clients do. To do this, a proprietary set of diagnostic tests must be sent to each email client to identify how it interprets HTML and CSS. This process must be completed regularly to ensure that web based email client previews are as accurate and up-to-date as possible.
This technique is challenging because there are additional factors involved such as email client style sheets and DOCTYPES. This is very important because your email will be displayed within the layout and style of each web based email client and in a variety of different web browsers and operating systems.
Let’s look at the pros and cons the Hare’s approach:
- Complete test results are processed faster and load times are far more reliable.
- The service is not dependent on third parties like Hotmail, Gmail, Apple Mail, etc.
- It requires less processing, less storage, fewer servers and less redundancy.
- Users can run a test in many different browsers to see how it will render in each of the web based email clients vs. being limited to a screen capture in one or more web browsers.
- Developers can see exactly which elements, attributes, properties, and values where altered by each email client enabling them to identify and correct rendering issues faster.
- A preview of all of your selected clients will always be returned whereas in some cases one or two screen captures may never get processed due to a third party issue.
- You can generate a text version of your email.
- You can easily convert your embedded CSS to inline CSS.
- You can test all of your links, image maps, hover effects, and animated gifs.
- Challenges arise when attempting to simulate browser differences among desktop clients. For example, Outlook 03 uses an IE rendering engine. If you run an email simulation using Firefox, it is difficult to display the result exactly as it would appear in IE. Therefore, additional logic is built into the system in order to simulate these differences.
- Diagnostic tests must be sent through each web based email client on a regular basis to see if any changes have been made.
- In order to process code, emails must be converted to UTF8, this can cause issues with special characters.
- Since your HTML code is being processed for each email client within one, fairly extensive web service call – it may take between 1-2 minutes before you can start browsing through your results.
Email on Acid offers both of the technologies listed above and it is our intention to provide code based previews and screen captures for every email client that we support. This gives our users complete control over how they test emails.
We also provide an auto detect feature – if you select this option, we use a combination of screen captures and code-based previews to deliver the fastest, most accurate result based on your web browser and OS.
Note: Clients like Outlook 07, 2010, and Lotus Notes 6.5, 7.0 8.0 and 8.5 require screen captures because of their proprietary rendering engines.