Friday, December 13, 2013

Responsive redesign of an HTML newsletter

As a precursor, read about my previous experience/success with a basic HTML email newsletter and how to track your email campaign results with Google analytics.

I recently came across an article by Zurb that said "Over 40% of emails are opened on a mobile device". Correction: Actually it is way more than that (79%) based on this data on Luke Wroblewski's blog.

This made me think it is time to extend our love of mobile optimization to HTML newsletters as well.

Another question that has surfaced often in conversations was, "What do most people do when they come across HTML emails that they can't read well on a mobile device?"
Based on what I heard from many, and my own experience was that they will not save it to read later on a more compatible device (desktop/tablet) but would mostly delete and move on.

I am sure many of us can relate to that, especially at a time when we are bombarded with tons of emails every day and ruthlessly send as many as we can, to trash.

So, responsive email is more of a need at this time, with the proliferation of mobile devices, our own experiences and the above factoid from Zurb.

General notes about responsive emails:

    Although I find creating responsive websites easy, on the contrary, I find there is a lot more pain-factor involved in this relatively tiny piece of responsive email (vs a website), which I think is mostly because:
    • Email clients are way behind even the worst browsers in terms of web-standards/technology and way more diverse in their presentation and support, many that don’t make any sense at all!
    • Unlike websites, it is not easy to check your fixes just by the refresh of a browser window (every time you fix something, you need to send the email out, yes, even on litmus) and check emails.
      Word of caution, just as with browser simulators it is always best to check on as many real email clients and devices as possible and not just rely on litmus tests. I found that actual result was way worse than what litmus test showed me.
    • You need to code like it is the nineties, but still use progressive enhancement for newer mobile email clients with media-queries, balancing a mixture of old and new. 
    • Outlook is to responsive email as Internet Explorer is to responsive websites.
      I found to be even worse than outlook desktop app and about 80% of my testing and fixing was for some of which had to be left at a not so pretty state as there was no way to fix them in spite of numerous trials (eg. Weird blue underlines irrespective of the style, justified text in some cases etc.).
    • Many of the proposed solutions online didn't work for So, there are some things you just have to end up accepting due to the limitations of email clients. 

    But, don't lose heart. It is lovely to see the mobile-friendly end product (think of how enticing, easy-reading it would look to your users, esp. compared to all other un-optimized emails in their mobile inbox), not to mention the joy of squishy-fun factor for you (still hasn't gotten old for me)!

    Just don't assume to square it off in a day when you are doing this for the first time. It only gets easier for the next time!

    Technical Notes:

    • Even if you have designed and coded regular HTML emails before, start out by reading some articles on basics (many references at the end) and why things are done the way they are, so you don't blindly follow a boilerplate or get into trouble because you overlooked something that shouldn't have been done.
    • Do not start without a boilerplate template eg. Litmus, Zurb, Antwort etc.
      Why? They take care of common issues that have been already found and addressed so you don't have to spend additional time reinventing the wheel. You will still have enough to deal with when you create your templates.  
    • Even if you do start out with a boilerplate or sample template, make sure you send it in an email to test it before you customize and work on your’s. I found some that I started out with, didn't work responsively (perhaps they were just quick run-through examples and weren’t tested) and I had to create my own, based on the knowledge from several articles and examples.
    • Keep it as simple and concise as possible. Mobile-first approach is ever so important in this.  
    • I really liked the strategy explained in this article. I used a mostly single column layout and two columns only in one section. 
    • The table spaghetti code will be much cleaner when you keep it simple and minimal which you will appreciate!
    • I didn't use a responsive email framework (it was a bit too much for my purpose). Zurb has created responsive framework called ink if you want to try it out. 
    • Although I generally use code based HTML editors like Sublime Text, I found it helps to code in a visual HTML editor like Dreamweaver for this. As it is old-fashioned code, with all styles inline (kinda icky!) it is easier to copy and paste similar sections in design view as it copies the inline-styles associated with each paragraph, list item, link etc. (which is a must).

    A general overview of the layout, code:

    • Pay attention to the doctype declaration in the boilerplates. 
    • Create a body tag and a 100% width wrapper table.
    • Start out with a 600-640px width, content table. If you have multiple sections (keep it limited), you will have several of these. 
    • If you want to delineate each section with your brand-colors in a 100% width wrapper for better clarity of sections, each of those fixed-width content tables need to be wrapped in their own wrapper tables.
    • Although you set your content tables to fixed width, don't forget to assign flex 100% width classes to them so you can stretch them to 100% device-width in one column on smaller screen-sizes via media-queries (media-queries added inline at the top style section of your email).
    • In your media-query/ies (I only had one for below 640px in my example) you will also style your basic underlined-links on wider screens to work as non-overlapping buttons on mobile (don't forget classes for your link styles even with inline styles specified). Make sure to have enough margin-separation/whitespace so mobile users don't accidentally touch other links due to close proximity. Have your touch-targets large enough for mobile (44px recommended).
    • In case of two columns, they will be just two left-aligned nested tables that fit next to each other within the parent table on non-responsive larger screens but with class 100% flex-width for mobile, they fall one below other on smaller screens. 
    • You can have responsive background-images of multiple sizes for mobile as background images, but I used 100% width images that resized on mobile with the same strategy for optimization that I have used in my previous WVU Research website responsive redesign post
    • Don't forget to run your code through a validator.  
    • Test often on litmus (not 100% accurate) and also send it out to your own multiple email accounts on several webmail and desktop email clients, multiple devices and blast off with the back-up of online version.
    Well, that's about it and I guarantee that if you have to support outlook and, you will be spending most of your time there. Good luck!

    End Result (after responsive redesign)

    This is just a view on browser, which is pretty much what I see in most email clients although browser view not recommended approach to testing as it is not a true representation of how it looks in some email clients.

    Web URL:

    Responsive Views:

    Litmus test results:

    Click to view a bigger image. The unchecked screenshots are just the email clients that don't support responsive emails. It works fine on all the desktop webmail and mobile specific native mail apps and a some other mobile mail apps (eg. gmail app on android and such).

    Here is a quick Polar Poll. Please click to answer (yes/no) and see votes.

    References, Further Reading:

    HTML email campaigns: Basics

    HTML emails/campaigns aren’t anything new, but there are simple, “obvious” facts about it that are ignored by many, leading to their failure and even to complete abandonment of receiving email communications from the sender.

    First and foremost is to keep the frequency of our emails to a tolerable limit. I find it surprising that senders, esp. marketers lose track of this, making us want to hate any email (are these people living in a matrix? don’t they face email overload in their own inboxes?!).

    I find a frequency of once a month to be most appropriate. The more often we see an email the more we seem to be put off by it. Sometimes even the ones that give an option of reducing the frequency still seem to be too frequent! 

    Take a look at a Polar poll below on email frequency and related unsubscribe effect. Vote on your choice to see results.

    When I started our WVU Research HTML e-newsletter, I was a bit weary.

    Given the number of emails we receive, I was afraid this might just be one of those lost causes. But much to my pleasant surprise, when followed up several times with Google Analytics RealTime Live and user flow analysis, following a blast, it was found to increase the website visits to WVU Research portal website by 227 - 180 % on several days following the email blast and showed that users explored the website beyond just the links in the email. 

    It was also refreshing to see subscribe requests by faculty/staff/researchers who were not in the mailing list by default and it also brought about increased interest and participation by faculty and staff at WVU (when I was actually afraid of a slew of unsubscribes).

    Although many of the factors above can be automatically tracked by HTML email campaign monitors’ tools, it is just as easy to send out and track stats with your basic e-mail blasts (via any email client with which you can send out an HTML email) coupled with Google Analytics.

    Sending: With Safari and Mac mail, sending out an HTML email just involves "mail contents of this page" and sending it out to your constituents/list-servs. Many other email clients on Windows also have easy ways of sending out an HTML email.

    Tracking: If you create trackable URLs in your email with Google URL builder you can follow up on the visits to links within the email with the free Google analytics tools. Including campaign info right in your URLs will help you monitor multiple campaigns over time.

    Based on my experience, I think the overall success of any HTML newsletter/campaign has to do with:
    • Keeping your content focused and minimal
    • Lower frequency (don't bombard with a slew of links/offers/info/reminders every other day!).
    • Sending out information that is of value to your users/customers.

      In our case, along with news highlights, I also included funding opportunities, time-sensitive information sent well in advance, featured new equipments in Labs, changes in processes etc. 

      For commercial vendors, including free articles, videos etc. related to the items sold would be good (eg. Photography tips/articles with a camera and accessories vendor). 

    A step up:

    Read about my experience with redesigning this basic HTML newsletter to a mobile-friendly, responsive format.

    Here is the screenshot of the plain old HTML email before responsive redesign:

    Sunday, December 1, 2013

    WVU Research responsive redesign, web performance optimization and more...

    The main purpose of this article is to share my experience and lessons learned during the responsive redesign of WVU Research website and also dispel some myths about responsive design, workflow and especially SIZE of responsive websites with example and proof.

    I am grateful to the openness in web-community in sharing knowledge and information in these exciting times and inspiring others with their work, knowledge and feedback.

    Website link: Please note the version of the website described here (designed and coded by me) is currently only available through screenshots below as the current iteration of the website is different from this.

    Screenshots: On my portfolio page

    Myth #1: Responsive design is bloated and a responsive webpage is generally over a Mb.

    No, not if it is done right. Proof is all through this article.

    Read on to find out how I have managed to have the sizes of home page at ~205K loads in 665 millisecs to 1.5 secs on desktop and 160.52K, 1.29 secs on mobile. Home page and other pages tested were faster than 95% of all websites tested!! According to Pingdom webpage test and mobitest data.

    The feedback has been very good so far, from administrators, internal users and clients on the effectiveness of the website overall.

    See results below:!/cYu2xJ/

    Myth #2: Responsive design workflow is a big hassle.

    I agree that we are still figuring things out regarding process (and more), but we can share and learn from others and adapt what's best for our model. I can even say it has perhaps made things easier and faster in certain ways, more so if you can code.

    More on Responsive workflow:

    Slide decks from BDConf from Ben Callahan's presentation

    and perhaps a lot more I may have missed… Need I say more?

    Myth #3 Responsive design takes too long to create and not a good option.

    As much as the complexities have increased, we have more resources, knowledge and sharing at this time that takes some hassle out of this and makes things easier for designers and front-end developers to create responsive websites.

    If a single in-house designer/front-end developer (yours truly) can create several responsive websites this year, along with other projects, a team can certainly handle bigger and more complex websites. With better workflows, one can cut down time from much of the processes we used to get stuck on earlier and even come out ahead on time!

    Myth #4 Frameworks are bad and is it worth learning Sass?

    Again, not if used wisely. Choose just the components that suit your website and the ones that work well for your UI. Also, just because you choose a framework doesn't mean that you choose every component that comes with it. Modify and customize components based on your needs, UI and UX and add your own.

    In fact, Sass is what helps you keep things modular, smaller, and in order. Read more below.

    To Sass or Not to Sass or better yet,

    Take my word for it and many other converts of Sass, it's worth it... learning and using it!

    Frankly,  it scares me to think of changing things on my previous non-Sass website!!

    I. Background on this project and wireframes

    See details on my portfolio:

    WVU Research website wireframes

    II. My workflow, process

    As with my previous responsive websites, I kept the workflow and process agile which is why you may see UI change somewhat during the process.

    I started out with wireframes which was a big help in communicating to administrators and content folks on information architecture and various content areas. The linked wireframes were especially important in stakeholders getting an idea about the key areas, give their feedback and it took very little time to create.

    After this process, since there is a good idea of layout and content, I get to the code as quickly as possible (in case of new designs, this would also help with content folks getting to work in parallel).

    With the help of frameworks and Sass components, it was really easy to start a functional mockup of basic templates and get feedback from others and adding refinements as I moved on.

    In a situation such as our's (an educational institution, or a corporation) this process becomes quicker as one would have defined style guides, but Style Tiles and more functional styles and pattern libraries would be of help at this stage in other cases.

    The links I've posted on workflow in the introduction section cover a lot of workflow scenarios.

    III. The Fun part: Website coming alive!

    @lukew, Yes, I admit it… Responsive design is FUN! (refer tweet)

    I used Sass along with CodeKit (use any other compiler of your choice) and Sass version of Foundation 4 (latest at the time).

    Typography, variables, global styles, styles for each component, javascript, everything is/can be separated. Read the nitty gritty of these in my Sass post.

    There are many more articles written about Sass to make you a convert. You don't need to use command line or know Ruby etc. and yes, you can also use Sass based frameworks, eg. via codekit (not necessarily as Ruby lib.) and hook them up ever so easily from anywhere on your machine and customize your components.

    Mobile First, Performance Optimization and Testing

    These were not NOT separate steps in the process but were incorporated, intertwined and thought about in each step of the process starting from wireframes (annotated).

    Mobile-first isn't really hard to make it work. Use respond.js or, many frameworks have created specific grids just for their frameworks and it only took me about a day to make it work decently in IE8 with some additional IE8 specific styles.


    If you have to support IE7, sorry, no tips here.

    Having used the functional, coded "mock-ups" I didn't have to create 30 different images in photoshop to show how the site looked in many devices. In fact, it even saved me time compared to previous workflows.

    I did tweak the breakpoints and modify them along the process. I didn't use device breakpoints. Firebreak (a firefox add-on) helped me in refining my content, design based breakpoints.

    I want to stress upon incorporating testing in all phases of the project (coded) and that really saves you much trouble later on.

    Below are some of the basics I started out with.

    You will have many web resources on these which I will not repeat here.

    1. SVG images (eg. the WV branding pattern on the home page was a mere ~4KB v/s a jpg or png image of the same which would've been close to 20K (or more).
      I added *subtle* CSS3 gradients to it to have a similar effect and some dimensionality as a jpg.
    2.  Iconfonts: I used Icomoon icon fonts.
      James Williamson at #BDConf shows you how to create your own icon fonts! (as usual, his talk summarized by Luke W).
      I haven't used it in this project, but Grunticon from filament group has svg icon solutions (with png back up).
    3. Note that in addition to icons in navigation area, I have also used icon fonts as visual reinforcement/imagery on pages, coupled with CSS3 border-radius in several cases (just works with font-size).
    4. For the Find Research page, I started out with the icons from the noun project and customized them. Due to backward compatibility issues, I have used a sprite of all those on that page (with added CSS3).
    5. I started out with CSS only modal windows on the Find Research page (uses JS on IE8) to showcase centers and research in each research field but unfortunately found out that they had several issues on mobile devices eg. The modal windows trigger links underneath them in several cases and had many issues on Kindle Silk browser.

      For my purpose, I found that a content-dropdown worked out better (a component of Foundation 4, works great on all browsers and devices, even on blackberry!!).

    The dreaded carousel:

    Another thing we love to hate, along with Brad Frost but something many of us are forced to use.

    Bottom Line: Don't use it unless you have strong reason to.

    If you do have to, it takes hell of a long time to make captions work for multiple breakpoints.

    Here is a poll on carousels I made on Polar Polls by @lukew click to cast your vote and view results.

    I used the carousel on research website as an enhancement for larger screens to showcase multiple areas of research-focus at WVU, coupled with content related to that (available on all screens).

    It is not displayed on smaller screens, (ideally it should be based on bandwidth and device and NOT screen size), but to compensate for that I have made sure that I have kept the sizes low for any screen size/devices.

    Here are some points to note…
    • I used responsive flex-slider which has many useful features
    • Didn't make it to be auto-forwarding (distracting to users).
    • Made the controls clearly visible and usable.
    • Made content/caption as HTML copy.
    • Made it touch enabled (Caveat: I found out that the touch option doesn't work on HP touch enabled desktop, need to check on that.) 
    • Used randomize option to present all items for repeat visitors. 
    • Loaded only first two images and not all images in carousel by using this script by Erik Runyon.
    • In addition to the above, for the smaller screen cases, when the carousel is not presented at all, I wrapped the above JS in screen.width to not load ANY images on those.

      if (screen.width > 400)
      … carousel images uncomment script


    Here is a similar technique as above by Dave Olsen of WVU for lazy loading and showing/uncommenting any content on a webpage via user action/mediaqueries.

    Foundation 5 also has a new feature, interchange with HTML 5 partials to accomplish the same (haven't used it yet as of this writing).


    During early stages of development I used browserstack's browsers and emulators (via web tunnel when testing on desktop).

    Mobile browser emulators are helpful but only provide a starting point. Can't stress enough on the importance of testing on real devices. Most of the issues that I came across were during testing on devices. Kindle Silk browser and older androids seem to be quite limiting.

    Even if you don't have a device lab or is inconvenient to access, try and gather/involve some devices from your colleagues and test. I did the former in initial stages and tested at our WVU device-lab on a larger set of devices later.

    Tested OK on many versions of iOS, android and even on blackberry (except for icon fonts).

    Lesson learned: We already know this… and I reiterate: Test early and test often (on as many devices and browsers as you can, at each step).

    More notes on Performance

    Optimize web performance and get the size of your webpage as LOW as you can.

    Not everyone is on unlimited data or a T1 line and don't penalize them just for visiting your website!

    Most of you have surely seen innumerable articles on the increase of mobile visitors on all websites. If you want to blow out your mind… check out this list.

    Thanks to Jason Grigsby (@grigs) @lukew and many others at BDConf for inspiring me to do more w.r.t. performance.

    It's been said numerous times (with data) and I will say it again…

    Images account for about 70% the weight of an average webpage.
    Think more about reducing the number and size of pretty pictures on your website before complaining about the size of a CSS framework or JS library.

    Responsive Images

    Frankly, I haven't done much w.r.t. responsive images but rather used alternative and low-tech tactics to keep image sizes low on all (reducing images, image sizes, icon fonts, svg etc.)

    These are some more tricks below I used for lowering image sizes:

    • A basic photoshop "save for web" doesn't cut it any more (only a starting point). I used and other jpg, png optimizers in addition. 
    • I saved 2X images (200%) at 0% quality + optimized (looks terrible in that size) but shrunk it down to 100%, on the webpage, in situ (eg. a 1200X600 displayed as 600X300. This has been talked about at many conferences including BDConf recently. Oct 2013). This gives more than 50% savings on image size. Be less rigorous on photo-based websites/portfolios as the images suffer in quality. 
    • If you have a lot of images, command line batch processing options may be of use. 
    • Simpler images (think shallow DOF), work well and are also smaller in size than busier images. 
    •  If you have too many images and your site is based heavily on images, Grigsby suggests online solutions for hosting responsive images. was suggested by a reader.

    If you've looked at Web Perf tests on pages with embedded youtube videos, you will see big sneaky embeds showing up. Here is an alternative to reducing the size of Youtube embeds which reduces the size by 300k (until upon request for video play). Won't work on IE 8 use alternate embed for IE8 .ltie9 + specific style.

    If you have questions or suggestions and need clarifications on any, please contact me.

    Thank you for reading and hope you learned something new!