Update (13.06.2013): The SmashingConf 2013 is sold out just 48h after the ticket sales launch. However, some workshop tickets are still available. We can’t wait to welcome you, dear attendees, in September in Freiburg! In fact, we’ve got quite a few surprises waiting for you; please stay tuned. You won’t be disappointed.

Guess what? The Smashing Conference is coming! 2 single-track conference days, 3 full-day workshops, 16 excellent speakers, and only 300 available seats. We’d be honoured to welcome you in our home town Freiburg, on September 9–11th 2013, at the foot of the legendary, beautiful Black Forest in Southern Germany.

You can enjoy the well-known “Münsterwurst” opposite the conference venue, also known as a “lange Rote”. Of course, there are also vegetarian tofu sausages available. Image credit.

SmashingConf 2013: We Are Building The Web

We want the Smashing Conference to be a unique, valuable and friendly event for everybody involved. Not only do we want to provide new perspectives into Web design in general; more importantly, we want the event to focus on how exactly we, designers and developers, work, design and code to solve real-life problems.

Tickets can now be purchased via the SmashingConf 2013 page.

We’ll explore in detail what techniques, strategies and tools we use, but also what lessons we can learn from our personal experiences, successes and failures. Smashing Conference is a conference about how we work and play — and how we build the Web today.

Get your ticket!

Speakers and Workshops

We’ve invited excellent speakers who all have something to share, be it personal experiences or case-studies on large projects. We’re very happy to welcome Jason Santa Maria, Dan Mall, Luke Wroblewski, Dan Rubin, Inayaili de Leon, David Březina, Andy Hume, Tim Kadlec and — of course — the Mystery Speaker among the first confirmed speakers. You can find more information about the talks on the SmashingConf 2013 Speakers page.

Taking notes the old-fashioned way. Image credit.

We are also happy to announce 3 full-day and 1 half-day practical, hands-on workshops that will take place after the two main conference days: Dan Mall will be teaching how to be the typographer you were born to be, Dan Rubin will be exploring how to design for User Experience, Luke Wroblewski will be exploring how we can improve Web forms for mobile, and Addy Osmani will be teaching how to become the real front-end warrior.

Does it all sounds good to you? Well, it gets even better: If you purchase a Conference Ticket + Workshop ticket, you can save 15% off the regular price! So what are you waiting for?

Date, Location, Prices

The conference will take place on 9–11th of September in 2013 in the Historic Merchant Hall in our lovely home town Freiburg, Germany. We have only 300 seats, so the number of tickets is very limited. Also, we’ve blocked every single hotel in town for you — you can select your hotel at the SmashingConf 2013 Location page (“Smashing Conference” is the magic word for hotel booking!).

Image credit.

AirBnB could be a good option as well, but be fast — there aren’t many rooms available. Freiburg is known for being a vacation place, so perhaps you’d like to combine the conference with a relaxing family vacation in the skirts of the Black Forest? We’ve prepared some information about the location of Freiburg, so you don’t get lost in the suburbs of the Southern Germany while travelling here. Now if that isn’t an experience of a life-time, what is? (No, seriously, you will enjoy it!).

The price per ticket is €369 (incl. VAT). We’re organzing 3 full-day (€349) and 1 half-day (€229) workshops. Make sure to actually consider booking a workshop as well — if you buy both a conf ticket and a workshop, you save 15% off the price right away. Three days of learning, sharing, networking — it’s getting better and better! No lunch will be provided, but drinks and snacks will be provided, of course.

Get your ticket!

Sponsors, Dear Sponsors

We keep the ticket prices affordable for everyone, and we’re happy to welcome sponsors to help us make the conference smashing in every possible way. If you’re interested in sponsoring the event, please contact Vitaly at hello [@] smashingconf [dot] com. We love our sponsors, and you make the event possible, and we’d be honoured to have you involved!

Snapshot of SmashingMag’s 2012 Conference badge and lanyard. Image credit.

• “This conference was well worth the money and I hope we will make it next year. Well done Smashing Magazine!” (Source)
• “The two days of talks offered a very good balance of design-, philosophy-, typography-, and development-based topics. [...] Thanks to all who attended, organized, cared, spoke and made this an overall very great event!” (Source)
• “It was an immensely successful conference [...] The talks, the beer and the interesting people definitely made me want to go visit Freiburg again next year!” (Source)

Questions?

Follow us at @smashingconf and get more details on the SmashingConf 2013 website. Also, more speakers will be announced soon, so get ready to be smashed with a few exciting surprises and announcements!

Questions? Shoot us an email anytime at hello@smashingconf.com — we’d love to assist you in every possible way and would be humbled and happy to welcome you in our lovely home town Freiburg this September!

Auf Wiedersehen!

Get your ticket!

© Vitaly Friedman for Smashing Magazine, 2013.

When a team builds a complex application, there is often a common breakdown of roles. Specifically on the back end, there are database engineers, application engineers and operations engineers, or something close to this. In recent years, more and more application logic is being deferred to the client side. For some reason, though, operations folks aren’t going with it.

I recently wrote an article on “Deploying JavaScript Applications.” It was largely well received, and I was happy with the content, but one negative comment stuck out to me. I probably didn’t have the reaction that the commenter was intending, but it pointed out something to me nonetheless.

“With all due respect, may I ask if you actually enjoy your job? I am a dev, and I do enjoy using tech to do stuff to a point. If your role is to squeeze every last second of performance out of your app, then yea, all this stuff must be cool. BUT if you are a coder doing something else and then come back to all of this as well, then wow, I don’t know how you haven’t gone mad already. I’d be sick to the stomach if I had to do all of this, in addition to my usual work.”

See, I had written my article with a few too many assumptions. I understood ahead of time that a few of my solutions weren’t globally applicable, and that many people wouldn’t have the time or energy to implement them. What I didn’t fully grasp was how different the role in that article is from the picture that people have of a front-end developer in their head. Up to this point, a front-end developer had just the few operations duties lumped into their role, and even then, many people chose to skip those steps (that’s why Steve Souders is constantly yelling at you to make your pages faster).

I think things are about to shift, and I’d (humbly) like to help guide that shift, because I think it’ll be great for the Web.

The Front-End Operations Engineer

A front-end operations engineer is not a title you’ve likely come across, but hopefully one that you will. Such a person would need to be an expert at serving and hosting front-end resources. They’d need to be pros at Grunt (or something similar) and have strong opinions about modules. They would find the best ways to piece together the parts of a Web application, and they’d be pros at versioning, caching and deployment.

A front-end operations engineer would own external performance. They would be critical of new HTTP requests, and they would constantly be measuring file size and page-load time. They wouldn’t necessarily always worry about the number of times that a loop can run in a second — that’s still an application engineer’s job. They own everything past the functionality. They are the bridge between an application’s intent and an application’s reality.

A front-end operations engineer would be very friendly with the quality assurance team, and they would make sure that “performance” is a test that comes up green. They’d monitor client-side errors and get alerts when things go wrong. They’d make sure that migrations to new versions of the application go smoothly, and they’d keep all external and internal dependencies up to date, secure and stable. They are the gatekeepers of the application.

Why?

We have reached a point where there is enough work to be done in the operations space that it often no longer serves us to have an application engineer do both jobs. When the application’s features are someone’s priorities, and that person has a full plate, they will typically deprioritize the critical steps in delivering their application most successfully to the end users.

Not every company or team can afford this person, but even if someone puts on the “front-end operations” hat for one day a week and prioritizes their work accordingly, users win. It doesn’t matter how many features you have or how sexy your features are if they aren’t delivered to the user quickly, with ease, and then heavily monitored. Front-end operations engineers are the enablers of long-term progress.

Builds And Deployment

If you were to ask most back-end engineers which person on their team has traditionally worried about builds and deployment, I’m sure you’d get a mixed bag. However, a very sizeable chunk of engineers would tell you that they have build engineers or operations engineers who handle these things. In that world, this often entails generating an RPM file, spinning up EC2 instances, running things through continuous integration tools, and switching load balancers over to new machines. Not all of this will necessarily go away for a front-end operations engineer, but there will be new tools as well.

A front-end operations engineer will be a master of the build tool chain. They’ll help run and set up the continuous integration (or similar) server but, more specifically, they’ll set up the testing instances that their application runs on and then, eventually, the deployment instances. They’ll integrate Git post-commit hooks into the application and run the tests (either in Node.js and PhantomJS or against something like Sauce Labs, Testling or BrowserStack) before anything gets merged into the master. They’ll need to make sure that those servers can take the raw code and, with a few commands, build up the resulting application.

This is where many people use Grunt these days. With a quick grunt build, these machines could be serving the built version of an application in order to enable proper testing environments. The front-end operations engineer would be in charge of much that’s behind that command as well. grunt build could call out to RequireJS’ r.js build tool, or a Browserify process, or it could simply minify and concatenate a list of files in order. It would also do similar things to the CSS (or your favorite preprocessed CSS dialect), in addition to crushing images, building sprites and reducing requests in any other way necessary or possible.

Front-end operations engineers would make sure that all of this stuff works on people’s local machines. A quick grunt test should be able to build everything locally, serve it and test it (likely with some WebDriver API-compatible server). They’d make sure that team members have the power to push their applications into the continuous integration environment and test them there. And they’d remove single points of failure from deployment (GitHub being down during launch wouldn’t scare them).

They’d facilitate internal deployments of feature branches and future release branches. They’d make sure that the quality assurance team has an easy time of testing anything and that the managers have an easy time of demoing things that aren’t ready.

They’d help build multiple versions of an application to best suit each of their core sets of users. This could mean builds for mobile or for old versions of Internet Explorer, but all of it should be relatively transparent to those who are programming against those feature, browser or device tests.

They’d facilitate the process of taking a release, building it, uploading it to a static edge-cached content delivery network, and flipping the switch to make it live. And they’d have a documented and fast roll-back mechanism in place.

Perhaps most importantly, they’d automate everything.

(Image credits: Rube Goldberg)

Tracking Speed

The metric by which a front-end operations engineer would be judged is speed: the speed of the application, the speed of the tests, of the builds and deployment, and the speed at which other teammates understand the operational process.

A front-end operations engineer would live in a dashboard that feeds them data. Data is king when it comes to speed. This dashboard would integrate as much of it as possible. Most importantly, it would constantly be running the team’s app in multiple browsers and tracking all important metrics of speed. This space currently doesn’t have a ton of options, so they’d likely set up a private cloud of WebPageTest instances. They’d put them in multiple zones around the world and just run them non-stop.

They’d run against production servers and new commits and pull requests and anything they can get their hands on. At any given point, they’d be able to tell when, where, and what the surrounding circumstances were behind a slow-down. A decrease in speed would be directly correlated to some change, whether a new server, a diff of code, a dependency or third-party outage, or something similar.

They’d have a chart that graphs the number of HTTP requests on load. They’d also have a chart that tells them the Gzip’ed and minified payload of JavaScript, CSS and images that are delivered on load. And they’d also go crazy and have the unGzip’ed payload of JavaScript so that they can measure the effect of code parsing, because they know how important it can be on mobile. They’d instrument tools like mod_pagespeed and nginx_pagespeed to catch any mistakes that fall through the cracks.

They’d be masters of the latest development and measurement tools. They’d read flame graphs and heap snapshots of their apps from their development tools (in each browser that has them). They’d measure frames per second on scrolling and animations, prevent layout thrashing, build memory profiles, and keep a constant eye on compositing, rendering and the overall visual performance of the application. They’d do all of this for desktop and mobile devices, and they’d track trends in all of these areas.

They’d religiously parallelize tasks. They’d track the application via waterfalls and .har data to make sure that all serial operations are necessary or intentional.

They’d chart the average run time of the tests, builds and deploys. And they’d fight to keep them low. They’d chart their external dependencies in size and speed. They may not have control over slow API requests, but they’d want to be able to point to the reasons why their numbers are increasing.

They’d set an alarm if any of these numbers rose above an acceptable limit.

Monitoring Errors And Logs

Managing logging is a critical job of a normal operations engineer. The data that is generated from running an application is vital to understanding where things go wrong in the real world. A front-end operations engineer would also instrument tools and code that allow the same level of introspection on the client side.

This would often manifest itself as an analytics tool. Application engineers would be encouraged to log important events and any errors at certain levels to a logging service. These would be appropriately filtered and batched on the client and sent back as events to an internal or external analytics-style provider. The engineer would have enough information to identify the circumstances, such as browser name and version, application deployment version, screen size and perhaps a bit of other data. (Though they’d want to avoid storing personally identifiable information here.)

Logging stack traces can be very helpful in browsers that support them. You can integrate third-party services that do this for you.

The front-end operations engineer would encourage a very small tolerance for errors. Any error that happened would be investigated and either fixed or logged differently. With the data that comes back, they should be able to visualize groups of errors by browser or by state information from the application. A threshold of errors would be allowed to occur, and when that is passed, engineers would be notified. Severities would be assigned, and people would be responsible for getting patches out or rolling back as necessary (with quick patches being heavily favored to roll backs).

Much like today’s operations people focus on the security of the systems they manage, a front-end operations engineer would have probes for XSS vulnerabilities and would constantly be looking for holes in the app (along with the quality assurance team).

A front-end operations engineer would have an up-to-date picture of the state of the application in production. This is challenging in the front-end world, because your application doesn’t run on your machines — but that makes it even more necessary.

Keeping Things Fresh and Stable

My favorite thing that good operations people who I’ve worked with in the past were really good at was keeping things up to date. For some applications, stability and security are so deeply necessary that caution is the larger priority; but in most cases, failure to keep dependencies and environments up to date is what causes applications to get stale over time. We’ve all worked on a project that’s four years old where all of the tools are very old versions of the ones we know, and getting good performance out of it is impossible.

A front-end operations engineer would be effective at keeping dependencies up to date and at removing cruft in systems. When the next version of jQuery is released, they’d use their skills to switch out the dependency in the application to work with the new version and then test it to validate the change. They’d keep Grunt up to date (and Node.js along with it). When WebP becomes viable, they’d automate moving the application’s images over to that format.

They’d work closely with the more architecture-oriented application engineers to make sure that the entire system still feels viable and is not lagging behind in any one area. They would keep on top of this stuff as often as possible. Updating a dependency here and there as you build is far easier than having a big “Update Everything” day. It encourages application developers to loosely couple dependencies and to build good, consistent interfaces for their own modules.

A front-end operations engineer makes it viable and fun to work on a project long after it’s new.

The Future

I’m sure plenty of commenters will tell me that these tasks have been going on for years, and plenty will tell me that they should be the concern of all developers on a team. I would agree with both statements. I am not introducing new concepts; I’m compiling tasks we’ve all been doing for years and giving them a name. I think this will help us build better tools and document better processes in the future.

The addition of this role to a team doesn’t absolve the other members of performance responsibilities. It’s just that right now, front-end operations are no one’s explicit priority on most of the teams that I’ve encountered, and because of that, they often get skipped in crunch time. I think there’s enough to be done, especially in the configuration and monitoring of these tools, outside of the normal job of a front-end engineer, to justify this role.

Most importantly, regardless of whether a new job comes from these tasks, or whether we solve the problem in a different way, we do all need to be conscious of the importance of solving these problems in some way. You simply can’t ignore them and still achieve reliable, robust, high-experience applications. Addressing these concerns is critical to the stability and longevity of our applications and to the happiness of programmers and users.

If we build with that in mind, it helps the Web win, and we all want the Web to win.

(al) (il) (ea)

© Alex Sexton for Smashing Magazine, 2013.

Over the past few years, soaring mobile usage has sparked an evolution, or perhaps revolution, in the way that we approach delivering content to online users. The ultimate goal is a fluid, mobile and device-agnostic web, and one school of thought has emerged as the widely favoured means to this end: responsive design. However, while the responsive zeitgeist has gathered steam, email design and development has struggled to keep pace.

This is due, in part, to the fact that HTML emails are a notoriously tricky medium for developers to work with. Archaic email client technology and a lack of standards have rendered many of the rules of modern, semantic code useless. But email is still a key marketing channel too important to be overlooked: over a six-month period in 2012, Litmus reported an 80% increase in email opens on mobile devices. In the same year, Campaign Monitor revealed that, for the very first time, their mobile email open rate had actually surpassed desktop and webmail.

Obviously it’s important to conduct proper analysis of your audience before taking the decision to invest in mobile-optimization. But a well-executed responsive email design can ensure an excellent user experience for both desktop and mobile users – and with widespread 4G just around the corner, the trend towards mobile is inexorable, so why not future-proof?

Square peg, round hole

If you’ve ever had the misfortune of opening a fixed-width email on a mobile device then you’ll understand the need for responsive email design. Screen-bursting, multi-column layouts can appear zoomed out so that font sizes are reduced to the point of illegibility. Users may zoom in but are then constantly and infuriatingly required to scroll horizontally left-to-right and back again in order to read content. Links appear small and congested, with no regard for fat fingers on touch-screen displays. And low-contrast designs on small viewports, dimmed to save power, often become unreadable. Clearly, mobile optimization is important but what’s the best way to go about it?

Mobile best practice

Before writing a single line of code, consideration of design features can vastly improve the user experience for those on mobile, although arguably these are advisable concessions regardless of screen size.

• Clear, concise content: small screens mean it’s more important now than ever to engage the user as efficiently as possible. 
• Single-column layout: simplicity is key. Layouts no wider than 640px will degrade gracefully. A single-column ensures no content will be completely lost outside the viewport when zoomed in.
• An engaging subject line: this is one of the email marketer’s most effective weapons in an overcrowded inbox. Keep it short and snappy.
• Large call to action (CTA): don’t punish fat fingers! Apple’s iOS Human Interface Guidelines recommend a minimum ‘tappable’ target area of 44×44 points.
• Generous font sizes: make sure your message can be easily read.
• Pre-header: another key area when it comes to visibility in the inbox. Try to avoid simply displaying ‘view in browser’ text.
• Left-aligned text: there are a number of reasons for aligning important elements to the left-hand side of the content area. (Eye tracking research suggests that western users focus the majority of their attention on the left-hand side of email content. This is hardly surprising since we read text from left to right. Certain operating systems, notably android, will not scale content to fit the screen, therefore displaying only the left half of an email. From an ergonomic perspective, the majority of users will find it easiest to interact with elements in the bottom left/middle of their hand-held screen.)
• Vertical hierarchy: diminished screen real estate places more credence than ever on the idea of ‘the fold’. Significant CTAs should be placed as near to the top as possible; if they are not seen immediately, perhaps they will not be used.
• Use images carefully: don’t assume that images will be seen. iPhone’s native email app will display images by default but many clients won’t.

These tips can improve the user experience for mobile customers, but you can, and probably should, optimize further. Thanks to growing CSS3 support among mobile email clients, responsive email design is now possible.

Getting started

As I mentioned earlier, HTML emails suffer from a woeful lack of standards – to the uninitiated, much of what follows will be a journey back in time to the early days of web development. Layouts must be arranged with tables due to the out-dated HTML rendering engines of some email clients and CSS must be applied inline. Several email clients will completely disregard any style declarations made in the <head> section of the document.

There are some fantastic email boilerplates available, I recommend Sean Powell’s excellent HTML Email Boilerplate as a starting point, but for the sake of demonstration, let’s begin from scratch.

For those of you that like to follow along with the code, you can download a template for this article from here.

Doctype

Hotmail and Gmail will automatically insert the XHTML 1.0 Strict doctype. It’s therefore not a bad idea to use it but it’s important to thoroughly test your email with and without a doctype as many email clients will simply strip it out altogether. 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"&gt;

Email on Acid has conducted extensive research on email doctypes here.

Media queries

We can now insert a viewport meta tag to make sure our email is correctly displayed on mobile devices. It’s also a good idea to specify the content-type and a title tag too. These will be ignored by many email clients but are a good idea if you’re planning on providing a link to a ‘browser version’ of your email.

Since the content-type will most likely be ignored, it’s advisable to encode all special characters within your email as HTML entities.

Also, we’ll include a couple of sensible style resets to ensure our email is rendered how we want it to be across platforms.

<head>
<meta name="viewport" content="width=device-width, initial scale=1.0"/>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Email subject or title</title>
<style type="text/css">
.ExternalClass {width:100%;}
img {display: block;}
</style>

Note that the viewport meta tag has negative implications for Blackberry.

Now we can insert our media queries; how many depends on the level of specificity you wish to deliver to each device. In this example we are going to use just one — making the reasonable assumption that most devices with a screen size no greater than 600px are modern, mobile and touch-screen and will benefit from mobile-optimized styling. Furthermore, we are going to assume that by following the universal mobile best practice techniques, outlined earlier, mobile users on larger devices receiving the desktop layout will encounter no major usability issues.

We are using media queries in the same way we would when building a website; if the viewport size is within the constraints set in the media query then apply that style.

@media only screen and (max-width: 600px) {
    table[class="hide"], img[class="hide"], td[class="hide"] {
      display:none!important;
    }
  }

In the example above we are telling some elements with a class of “hide” to display:none on screens narrower than 600px. The !important property ensures that any inline style is overridden. This is the basic principle of responsive email design: overriding inline style declarations made in the body of the HTML document with !important style declarations made in the <head> section, and targeting these style overrides to specific screen sizes with media queries. A glaring exception is the gmail app that will ignore any style declarations in the <head> section. However, conscientious left-aligning of content should ensure a satisfactory user experience for gmail fans in your mailing list. Obviously this isn’t an ideal solution but at present, responsive email design is as much about considered compromises as it is about cutting edge techniques.

It is worth noting that we are targeting our HTML elements with CSS attribute selectors to overcome a rendering quirk of Yahoo! Mail.

So we can see that media queries are a useful tool for selectively displaying content but we can also use them to manipulate other features of our layout. Perhaps most importantly, we can constrain the column width of our email — the key to a great mobile experience. 

@media only screen and (max-width: 600px) {
    table[class="content_block"] {
    width: 92%!important;
    }
}

We have now stated in our media query that all tables with a class of “content_block” should scale to 92% width on devices with a screen size of up to 600px. Now all we have to do is specify a width attribute inline (600px) for any table with a class of content_block and we have a fixed width container that then scales proportionally on screens under a certain size. Provided that the width attributes of the child elements of this container are all specified as percentages, this is a basic responsive email template.

Take care when disabling webkit automatic text size adjustment on the body tag, as a rule of thumb, try to keep font sizes above 12px minimum.

Buttons

Calls to action (CTAs) are usually the most important part of a marketing email. They should be eye-catching, well-placed and above all, usable. The criteria for a great CTA are different depending on whether it is to be selected by a cursor or a finger. This is a powerful function of responsive email; to provide users on smaller touch-screen devices with finger-friendly buttons that are not affected by image blockers.

Unfortunately, such buttons cannot be displayed universally as they rely on padding properties that are not supported in some desktop email clients.

@media only screen and (max-width:600) {
a[class="button"]{
      display: block;
      padding: 7px 8px 6px 8px;
      -webkit-border-radius: 5px;
      -moz-border-radius: 5px;
      border-radius: 5px;
      color: #fff!important;
      background: #f46f62;
      text-align: center;
      text-decoration: none!important;
}
}

The style declarations above will transform tags with a class of  “button”, like the one below, into large, engaging, coloured buttons that span the width of the content area, so long as the device screen width is not greater than 600px. CSS3 support shouldn’t be a problem as we can assume the mobile technology we are targeting is reasonably modern.

<a href="#" style="color:#f46f62; font-weight: bold; text-decoration: underline;">Click me!</a>

The inline styling is sufficient for mouse users that may select links with greater accuracy but overriding these styles to make links large and clear for touch-screen users decreases the likelihood of interaction mistakes. Importantly, this approach does not rely on images and so avoids the usability issues that image blockers would otherwise present.

In conclusion

Responsive email design is still a compromise. The baffling array of different devices, email clients and rendering engines present designers and developers with a daunting task. But as technology progresses it’s becoming easier to provide users with appropriate layouts that they can effortlessly consume and interact with. Growing support for media queries in email has changed the landscape of mobile email optimization and provides us with a platform to drastically improve the user experience on more devices. It is now up to us, the designers and developers, to experiment with creative ways to reach the mobile audience.

Have you designed for email? Did you use a responsive approach? Let us know in the comments.

Featured image/thumbnail, via mattw1ls0n

Thirsty Rough Font Family – only $9!

Over the past few years, soaring mobile usage has sparked an evolution, or perhaps revolution, in the way that we approach delivering content to online users. The ultimate goal is a fluid, mobile and device-agnostic web, and one school of thought has emerged as the widely favoured means to this end: responsive design. However, while the responsive zeitgeist has gathered steam, email design and development has struggled to keep pace.

This is due, in part, to the fact that HTML emails are a notoriously tricky medium for developers to work with. Archaic email client technology and a lack of standards have rendered many of the rules of modern, semantic code useless. But email is still a key marketing channel too important to be overlooked: over a six-month period in 2012, Litmus reported an 80% increase in email opens on mobile devices. In the same year, Campaign Monitor revealed that, for the very first time, their mobile email open rate had actually surpassed desktop and webmail.

Obviously it’s important to conduct proper analysis of your audience before taking the decision to invest in mobile-optimization. But a well-executed responsive email design can ensure an excellent user experience for both desktop and mobile users – and with widespread 4G just around the corner, the trend towards mobile is inexorable, so why not future-proof?

Square peg, round hole

If you’ve ever had the misfortune of opening a fixed-width email on a mobile device then you’ll understand the need for responsive email design. Screen-bursting, multi-column layouts can appear zoomed out so that font sizes are reduced to the point of illegibility. Users may zoom in but are then constantly and infuriatingly required to scroll horizontally left-to-right and back again in order to read content. Links appear small and congested, with no regard for fat fingers on touch-screen displays. And low-contrast designs on small viewports, dimmed to save power, often become unreadable. Clearly, mobile optimization is important but what’s the best way to go about it?

Mobile best practice

Before writing a single line of code, consideration of design features can vastly improve the user experience for those on mobile, although arguably these are advisable concessions regardless of screen size.

• Clear, concise content: small screens mean it’s more important now than ever to engage the user as efficiently as possible. 
• Single-column layout: simplicity is key. Layouts no wider than 640px will degrade gracefully. A single-column ensures no content will be completely lost outside the viewport when zoomed in.
• An engaging subject line: this is one of the email marketer’s most effective weapons in an overcrowded inbox. Keep it short and snappy.
• Large call to action (CTA): don’t punish fat fingers! Apple’s iOS Human Interface Guidelines recommend a minimum ‘tappable’ target area of 44×44 points.
• Generous font sizes: make sure your message can be easily read.
• Pre-header: another key area when it comes to visibility in the inbox. Try to avoid simply displaying ‘view in browser’ text.
• Left-aligned text: there are a number of reasons for aligning important elements to the left-hand side of the content area. (Eye tracking research suggests that western users focus the majority of their attention on the left-hand side of email content. This is hardly surprising since we read text from left to right. Certain operating systems, notably android, will not scale content to fit the screen, therefore displaying only the left half of an email. From an ergonomic perspective, the majority of users will find it easiest to interact with elements in the bottom left/middle of their hand-held screen.)
• Vertical hierarchy: diminished screen real estate places more credence than ever on the idea of ‘the fold’. Significant CTAs should be placed as near to the top as possible; if they are not seen immediately, perhaps they will not be used.
• Use images carefully: don’t assume that images will be seen. iPhone’s native email app will display images by default but many clients won’t.

These tips can improve the user experience for mobile customers, but you can, and probably should, optimize further. Thanks to growing CSS3 support among mobile email clients, responsive email design is now possible.

Getting started

As I mentioned earlier, HTML emails suffer from a woeful lack of standards – to the uninitiated, much of what follows will be a journey back in time to the early days of web development. Layouts must be arranged with tables due to the out-dated HTML rendering engines of some email clients and CSS must be applied inline. Several email clients will completely disregard any style declarations made in the <head> section of the document.

There are some fantastic email boilerplates available, I recommend Sean Powell’s excellent HTML Email Boilerplate as a starting point, but for the sake of demonstration, let’s begin from scratch.

For those of you that like to follow along with the code, you can download a template for this article from here.

Doctype

Hotmail and Gmail will automatically insert the XHTML 1.0 Strict doctype. It’s therefore not a bad idea to use it but it’s important to thoroughly test your email with and without a doctype as many email clients will simply strip it out altogether. 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"&gt;

Email on Acid has conducted extensive research on email doctypes here.

Media queries

We can now insert a viewport meta tag to make sure our email is correctly displayed on mobile devices. It’s also a good idea to specify the content-type and a title tag too. These will be ignored by many email clients but are a good idea if you’re planning on providing a link to a ‘browser version’ of your email.

Since the content-type will most likely be ignored, it’s advisable to encode all special characters within your email as HTML entities.

Also, we’ll include a couple of sensible style resets to ensure our email is rendered how we want it to be across platforms.

<head>
<meta name="viewport" content="width=device-width, initial scale=1.0"/>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Email subject or title</title>
<style type="text/css">
.ExternalClass {width:100%;}
img {display: block;}
</style>

Note that the viewport meta tag has negative implications for Blackberry.

Now we can insert our media queries; how many depends on the level of specificity you wish to deliver to each device. In this example we are going to use just one — making the reasonable assumption that most devices with a screen size no greater than 600px are modern, mobile and touch-screen and will benefit from mobile-optimized styling. Furthermore, we are going to assume that by following the universal mobile best practice techniques, outlined earlier, mobile users on larger devices receiving the desktop layout will encounter no major usability issues.

We are using media queries in the same way we would when building a website; if the viewport size is within the constraints set in the media query then apply that style.

@media only screen and (max-width: 600px) {
    table[class="hide"], img[class="hide"], td[class="hide"] {
      display:none!important;
    }
  }

In the example above we are telling some elements with a class of “hide” to display:none on screens narrower than 600px. The !important property ensures that any inline style is overridden. This is the basic principle of responsive email design: overriding inline style declarations made in the body of the HTML document with !important style declarations made in the <head> section, and targeting these style overrides to specific screen sizes with media queries. A glaring exception is the gmail app that will ignore any style declarations in the <head> section. However, conscientious left-aligning of content should ensure a satisfactory user experience for gmail fans in your mailing list. Obviously this isn’t an ideal solution but at present, responsive email design is as much about considered compromises as it is about cutting edge techniques.

It is worth noting that we are targeting our HTML elements with CSS attribute selectors to overcome a rendering quirk of Yahoo! Mail.

So we can see that media queries are a useful tool for selectively displaying content but we can also use them to manipulate other features of our layout. Perhaps most importantly, we can constrain the column width of our email — the key to a great mobile experience. 

@media only screen and (max-width: 600px) {
    table[class="content_block"] {
    width: 92%!important;
    }
}

We have now stated in our media query that all tables with a class of “content_block” should scale to 92% width on devices with a screen size of up to 600px. Now all we have to do is specify a width attribute inline (600px) for any table with a class of content_block and we have a fixed width container that then scales proportionally on screens under a certain size. Provided that the width attributes of the child elements of this container are all specified as percentages, this is a basic responsive email template.

Take care when disabling webkit automatic text size adjustment on the body tag, as a rule of thumb, try to keep font sizes above 12px minimum.

Buttons

Calls to action (CTAs) are usually the most important part of a marketing email. They should be eye-catching, well-placed and above all, usable. The criteria for a great CTA are different depending on whether it is to be selected by a cursor or a finger. This is a powerful function of responsive email; to provide users on smaller touch-screen devices with finger-friendly buttons that are not affected by image blockers.

Unfortunately, such buttons cannot be displayed universally as they rely on padding properties that are not supported in some desktop email clients.

@media only screen and (max-width:600) {
a[class="button"]{
      display: block;
      padding: 7px 8px 6px 8px;
      -webkit-border-radius: 5px;
      -moz-border-radius: 5px;
      border-radius: 5px;
      color: #fff!important;
      background: #f46f62;
      text-align: center;
      text-decoration: none!important;
}
}

The style declarations above will transform tags with a class of  “button”, like the one below, into large, engaging, coloured buttons that span the width of the content area, so long as the device screen width is not greater than 600px. CSS3 support shouldn’t be a problem as we can assume the mobile technology we are targeting is reasonably modern.

<a href="#" style="color:#f46f62; font-weight: bold; text-decoration: underline;">Click me!</a>

The inline styling is sufficient for mouse users that may select links with greater accuracy but overriding these styles to make links large and clear for touch-screen users decreases the likelihood of interaction mistakes. Importantly, this approach does not rely on images and so avoids the usability issues that image blockers would otherwise present.

In conclusion

Responsive email design is still a compromise. The baffling array of different devices, email clients and rendering engines present designers and developers with a daunting task. But as technology progresses it’s becoming easier to provide users with appropriate layouts that they can effortlessly consume and interact with. Growing support for media queries in email has changed the landscape of mobile email optimization and provides us with a platform to drastically improve the user experience on more devices. It is now up to us, the designers and developers, to experiment with creative ways to reach the mobile audience.

Have you designed for email? Did you use a responsive approach? Let us know in the comments.

Featured image/thumbnail, via mattw1ls0n

The Only Journal App You Will Ever Need for Windows or Mac – only $19!

W3C published today a report summarizing the Open Data on the Web workshop that took place in April. The report summarizes the major themes discussed and conclusions arising from them. Participants discussed how to bridge the gap between the worlds of tabular and linked data, and how to ensure the long term growth of the Web as a platform for data.

Sponsored by Google, Adobe and Microsoft, the workshop was organized by W3C in conjunction with the Open Data Institute and the Open Knowledge Foundation, and hosted by Google at Campus London. Learn more about the Semantic Web.