- Copywriter works with appropriate departments to get the email's articles written and then approved by the appropriate stakeholders. A proofreader also reviews and approves the content.
- Coding begins directly and that ensures we're "designing within the constraints of email" which is actually quite freeing. If prototyping or design concepts are necessary, we create them as real emails. We don't use any templates - every email is hand coded. We benefit from an automated workflow which eliminates all of the complex hacks/one-offs/insanity most people associate with responsive emails. We're able to send completely custom, but fully-responsive previews from practically the first line of code. This allows to focus on the design (and typography, of course) -- iterating and trying new things is quick and easy.
- We send previews (both internally and externally to our clients) throughout the process. IMHO, the easiest way to get approval for an email project is to deliver the proof as an actual email the client can see and interact with on their favorite device.
- After all of the previews are approved, we send it off to Litmus, of course, for a final confirmation check. Litmus Analytics are assigned automatically and the final, minified assets are archived for delivery to the client.
The most bang-for-your-buck comes from whitespace and comment removal. While valuable in making sense of complicated email code, indentation and comments are completely unnecessary at the time of sending. I've seen examples where unnecessary whitespace accounted for 70% or more of the email's overall code weight.
Avoid optimizers that try to merge/simplify/remove attributes - this is where email code can get corrupted. As we all have experienced, verbose syntax and attributes are often necessary to ensure compatibility. HTML/CSS optimizers will try to rewrite your code to make it smaller. Many offer a way for you to disable messing with your code. Disable any options that aren't specifically related to whitespace removal.
Avoid a single, uninterrupted line. Some email clients choke on excessively long lines of markup. I recommend breaking lines at 800 characters. The extra line breaks won't add a significant amount to your overall file size but ensure you won't run into unexpected problems due to long lines.
Although our workflow produces a separate minified ready-to-send email (without modifying the original HTML), any decent IDE can take a minified HTML/CSS file and reformat it back into readable, organized, indented code.
Always send the minified version to Litmus for testing just to make sure. It's highly unlikely that whitespace removal will introduce any rendering problems but it never hurts to test the version you intend to send to your recipients.
So I solved the problem - at least in my own email. There was an extra <td> on a table set to fill, rather than stack. iOS Mail and Gmail were more forgiving and either ignored it after they recognized that there was nothing in that cell. Outtlook for iOS appears to be stricter. Once I found the extraneous markup and retested the email, it worked beautifully in Outlook for iOS.
Henri, thanks for the response!
I didn't realize that ImageOptim has MozJPG and Guetzli built-in. I was using an ImageOptim Ruby library (for ease of automation) that didn't offer those optimization options. I switched over the command-line ImageOptim.app and, yeah, that did the job in one step - which is awesome.
We have different image optimization routines based on the type of image.
For JPEG - first, we use Photoshop's Save for Web at 50-60% quality. Then we run lossy Google's Guetzli AND/OR* MozJPEG. They often optimize images in different, mutually beneficial ways, but for some images, the result is slightly larger so our automated system runs them sequentially and only uses the results when the image is smaller. Then we follow up with ImageOptim in lossless to squeeze the last unnecessary bytes from the image.
For PNG, we save out of Photoshop using SuperPNG, converting 24bit with transparency to 8bit with transparency. Then we run the through lossless ImageOptim.
For GIF, we Save for Web and painstakingly tweak until we've gotten the color count to an absolute minimum We use GIF just for line art and logos - so we're usually able to get the color count down to between 4-10. Then we run through ImageOptim in lossless mode.
The key for this workflow is automation. After the artwork is completed in Photoshop and exported into the email's image directory, our tools detect the image and automatically run the optimizations behind the scenes. The image that appears in the email is as compressed as it can be.
We're an agency and our process is:
Our process is possible because we invested heavily in automation. It's easy to see why many people would choose to design first in a graphics tool -- without automation and tooling, the barrier to designing directly in email is often too high.
Hi, Mike -
I always minify. There are many misconceptions about compressors - and so most email coders are afraid to use them.
I wrote an in-depth blog post about the benefits of HTML/CSS minification for email. We've been sending minified emails for years and highly recommend it. A++++ will minify again!
On a separate note, it sounds like you're already tackling your image size problem. I haven't seen your artwork but make sure you're using the right image format for the types of images your including. Photos should be JPEGs, not PNGs. JPEGs can be dramatically compressed without sacrificing substantial quality. Image optimization can be completely automated - I use a pipeline of ImageOptim, MozJPEG and Guetzli to squeeze every extraneous byte from the images in our emails.
Cosmin, that's a reasonable concern with many frameworks and something I wanted to avoid with my own open-source static email builder Inkcite. You get all the benefits of variables, modules and keeping your code DRY (don't repeat yourself) without any of the bloat. (I despise bloat and built Inkcite from the ground up to be bloat-free.) With Inkcite, styles and attributes are only added to elements because you assigned them - e.g. marked a specific table as having a background color or tell it to stack on mobile devices. Aside from some minimal industry-standard reset/boilerplate classes, Inkcite only includes styles and classes that are actually used.
We routinely build long-form emails with lots of graphics, CSS animations, pages of text and dozens of links -- and Google's limit isn't an issue. It also helps that Inkcite automatically and safely minimizes the final output - so you are free to comment, indent and style your code for readability and maintainability and have optimized, minified code to send to your recipients.