- 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.
Hi, Ces -
We ran into this type of problem a while back. Google Docs and MS Word files appear to be riddled with non-displayable control characters. Although they weren't visible in our primary editor (Sublime) when we'd send previews of the email, certain clients like Outlook would display gibberish characters when the control characters were encountered. We had to use a binary editor to see these otherwise invisible control characters.
From what I can tell, displayable foreign characters do not appear to be a problem when sending the email (although you may need to convert them to HTML escape characters) but when there are invisible control characters hidden in there, I think that can trigger the problems you are seeing.
We added automatic sanitization into our automated workflow (Inkcite) so the control characters are now fully stripped from source of the email and we haven't had a problem pasting content from Google or Word documents since.
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.