Now that our responsive email framework Ink has been out for a couple months, we've had the pleasure of watching our "baby" grow up. We've seen people using Ink on bigger and bigger projects, giving us even more validation that there's a need for a responsive email framework like ours. This validation provided us with a good deal of encouragement. Better yet, it gave us the freedom focus on refining the product itself, rather than trying to establish its niche in the market.
Since the launch, we've been doing a lot of responsive emails with Ink ourselves. We've converted all our newsletters (12 monthly campaigns that reach over 100k people) to Ink, as well as generated a lot of content examples for blog posts, the responsive email newsletter and our responsive email training class. More importantly, we've been in contact with a lot of users about their emails — swapping code tips on GitHub and getting cool examples of HTML emails delivered to our inbox.
We've focused more of our effort and time on using Ink, rather than building it. And it's had the helpful side effect of making us better at the actual building.
More Users + Better Listeners = Better Builders
We've had a lot more examples to look at and dissect how Ink is used in the wild as more people use the framework. This increased dialog makes it easier to get direct feedback on what people like and what they don't.
A prime example of this: the panel element. Though we originally included it as a quick throw-in to help us build templates quicker, people found it a lot more useful than we originally imagined. Spurred on by pull requests and tweets, we worked hard to make panels even more useful in this release. We made them more generalized and easier to use, as well as compatible with the Ink sub-grid.
Another example of users guiding our process occurred with the typographic styles, which had been rendering a bit inconsistently in Outlook. While we had originally deemed this a low-priority fix, we found that it was a bigger deal for our users. With the help of the community, we were able to source a few quick and effective fixes to make sure your typography and paragraph spacing looks just as good in Outlook as it does in any other email client.
Spending more time as users, rather than as builders, also helped us do more with less. We focused more on what was already in the framework, finding clever ways to use it rather than adding new features. Things like full-width rows and offset-columns went from hacks to well-established practices, examples of which then made it into the docs.
A Battle-Tested Development Process
With every email we built, our implementation skills weren't the only thing to improve. So did our process. We developed a better grasp of the entire email workflow by developing better standards of how to use things like testing services and ESPs effectively.
Our process for developing the framework also improved with time and use. We learned a lot of lessons during development, like how we need to be careful to about roll out documentation and inliner changes with releases, lest we confuse users with unexpected changes. Other good ideas — like actually talking to people around the office before renaming things and making sure to test on actual hardware devices not rely solely on testing services like Litmus — slowly worked their way into our process as well.
Many of these insights (at least the applicable ones) have been added to the docs or the process page in this release, as well as talked about in various blog posts and training classes.
The Result: Ink v 1.0.5
As a result of all the lessons learned, we're happy to announce the release of Ink v 1.0.5. The new version cleans up a lot of small bugs and typos, expands and clarifies the docs and brings a bunch of insights from our users. The full list of changes can be found in the changelog.
