It's been a whole month since we launched Ink, our responsive email framework. And it's certainly been a busy month: After four patch releases, 30 closed GitHub issues, seven accepted pull requests, almost 3,000 stars and a surprisingly friendly hacker news thread later, we've learned a lot of lessons from the launch.
1. Test on Real Hardware
Even though we did a lot of testing with Litmus prior to launch, not every problem can be caught by a screen-capture tool. When we first launched, we had buttons that looked brilliant on almost every mail client, including all of the most popular ones. Unfortunately, they were completely unclickable in Outlook.
A screenshot of a Litmus test.
We could've caught the problem earlier had we tested the the email in a virtual machine or on an actual Windows computer with Outlook. While the issue has since been patched, the experience taught us to be a lot more careful in testing the actual interaction. Although email is limited compared to 'traditional' web design, email is an interactive medium, not just a static surface like printed content.
Context matters, and making sure that a product is usable on an actual device is an important concept. Testing emails on touch screens, on different operating systems and even in different lighting conditions can give many insights into whether or not something will actually work for your users.
2. Let Users Guide Your Development Strategy
Following the hacker ethos of 'move fast and break things' is becoming common practice when rolling out dramatic changes with a small, communicative team. Though things may break, the reward of providing a better experience for the user in the long term justifies this highly productive, if disruptive and Machiavellian, method of development.
While we believe in "failing fast," or validating your hypotheses as quickly as possible, we're not huge fans of the "breaking things" part, especially when your main users are developers. While developers love new features as much as anybody (maybe even more), they tend to get upset when you change code they may depend on.
We broke a couple of things during our frenzied month of development, and we certainly heard about it from our users. When we changed our button syntax to fix the Outlook issue, it disrupted many of our users, some of whom didn't actually need Outlook support and were fine with the old-style buttons. We did our best to mitigate the problem by transitioning slowly and keeping the old syntax in the framework for a few releases.
Old Buttons
<a href="#" class="button">
<table>
<tr>
<td>
Button Title
</td>
</tr>
</table>
</a>New Buttons
<table class="button"> <tr> <td> <a href="#">Button Title</a> </td> </tr> </table>
Changes to syntax or updates to the documentation have the potential to be extremely disruptive to our users — a consequence of building a developer-focused product as opposed to a consumer-focused one. Featuring a prominent change log on our site, as well as grouping documentation changes into releases, has helped us to minimize the disruption.
The Ink changelog.
3. Save Your Butt by Planning Ahead
It may sound trite, but planning ahead can save you some serious headaches. The Ink marketing site was on a server for weeks before the actual launch. The framework itself had been circulated to a couple dozen beta testers, thus making sure we wouldn't encounter too many nasty surprises. Just as importantly, we also put a lot of time before launch into making sure we had a robust system in place for pushing new releases and documentation fixes to the live site. Using Grunt let us edit the docs directly from the project repo, meaning that we could push fixes without having to take down the marketing site.
Figuring out the mechanics of building and maintaining the marketing site let us focus on iterating the actual framework itself after launch. Releasing a product is stressful enough. Dealing with a malfunctioning server or a tricky deployment issue will only make things worse.
Looking to the Future
We've learned a ton this past month, and continue to incorporate these and other lessons into Ink. Far from the "launch it and forget it" mentality, we're continually pushing forward with trying to make HTML email a bit less of a nightmare, adding commits to Ink on a weekly (and often daily) basis.
A graph showing our Github commits.
We have many features and tweaks in store for Ink, but we're always looking for more feedback. Hit us up at @inkzurb or submit a pull request to help us build the world's best responsive email framework.
If you'd like to hear more about the lessons we've learned while building Ink, we're having a training class on Dec. 19, 2013 at 9:00 AM PDT called "Introduction to Responsive Emails." In the class, we'll talk about the basics of workflow and content, as well as the technical side of building robust, responsive emails that look great on any platform. Even Outlook.