Email development has always been the bane of a web developer's existence. You have to use outdated methods and don't have access to the full modern web to create a nice looking email that thousands of people will see. It's like asking a Nascar mechanic to create a car using only tools from the 90s - it can be done but its more than a pain.

With time, however, email development has become easier and more developer-friendly. Gone are the days of creating the email entirely with images and then cutting it up. Now you can breakout out the tables and creating a responsive email that looks good on all clients, even Outlook.

The largest part of developing emails is how the email is actually rendered by the email client. While this seems pretty straightforward at first, the fact that every email client uses a different rendering engine or has its own quirks turns what should be pretty simple into a much larger beast. There are versions of Microsoft Outlook that using `margin` does not work, however, using `Margin` does. Keeping on the Outlook theme, it either uses Microsoft Word or Internet Explorer as a rendering engine. You don't have to be super tech-savvy to understand maybe using Word to display essentially a website may not be the best thing...

However, as time has progressed the rendering engines have gotten better and more standardized. While there are still a lot of quirks, you can build something and be fairly confident that it's going to look good across the board. With the iPhone and smartphones forcing email clients to account for media queries and Gmail dragging everyone along, it's not too bad developing emails.

Outlook is no longer the dominant client as the Apple Suite and Gmail have taken over.  Mobile reigns king as well with the top client being the mail application on the Apple iPhone. 

When I first started out in the web development industry as an intern, my first task was updating emails for clients. Even in 2013, this was a process of opening up the email in a HTML editor like Sublime and going thru the spaghetti code trying to make the changes. After a few weeks of email development, I understood why the intern got that job.

Today, the process is much more smooth. Here at VIA, we use three tools primary - 

. The first tool, MJML, is a development tool that allows us to create clean code and modular emails. It also includes a library of tested skeleton components that we can use in the emails and know they work already. It also will build the email and take care of any quirks and will inline and optimize the email. Using this tool has cut down on development time tremendously.

MailChimp is used primarily to manage email campaigns, contacts, and gives marketers the ability to visually edit email templates. MailChimp has the ability to import templates created elsewhere and use tags to create editable areas. Custom templates can be reused and customized for different campaigns. Gone are the days of having a developer create each email for the marketing team.

The other tool that we use extensively is Litmus. Litmus is an email testing tool that allows you to see your email in any of the major email clients. For instance, we have the ability to see what the email will look like in Outlook 2007, 2016, iOS Mail, and Gmail all the same time. It also has other features such as live editing and accessibility tools. With Litmus, we don't have to have the actual devices on site - no old Windows machine with Outlook on it.

When designing an email, a designer and developer at VIA first sit down and go over the constraints. We use the tried and true width of 640px as the base of the email and then try to design everything as blocks with no overlap. There is also a reminder on what modern CSS attributes, such as box shadows, do not work for emails. Previously, since it was a giant image being cut up or a much simpler email design, there was no need for dev and design collab.

Once we have a design approved by all parties, development starts. The email is cut up into the blocks and each is developed as a component in the email. Using MJML we are able to import these components into the main email file. In the end, we end up with a nice folder of components and an external stylesheet that is easy to navigate and make changes.

From there the email is imported into MailChimp, our email campaign tool of choice, and content loaded in. The email is then sent from MailChimp to Litmus to be tested in the major email clients. Typically there are the normal changes and then a set of Outlook only changes that have to be made. These revisions is typically resolved in one or two tests and then the email template is updated in MailChimp and sent for final approval.

Once this email template has been created and tested, it can be reused by the VIA marketing team without any help from developers. No more interns having to make changes.

Email

Email Campaigns

Frontend Development

Email @ 50: Email Development

The old viastudio.com website launched nearly a decade ago atop of Wordpress - our go-to custom website development platform. 

But much has changed in those ten years in web development - and the goals we had for the

We wanted something that would create a unique, elegant, interesting user experience, delivered "scary fast"  - that was also easy to develop and maintain.

We love Wordpress - it has been and remains our go-to for custom website development. In order to achieve our user experience and development goals for the 

, we found that they aligned closely to the offerings of the JAMstack: static markup, delivered fast and enhanced with Javascript. This is commonly known as a "headless" content management system (CMS).

There are many JAMstack CMS options- including using Wordpress in a "headless" mode. But would that fit our needs?

Read How We Customized the Sanity CMS

The biggest challenge was moving our data from WordPress to Sanity, mainly our blog posts going back years. Fortunately, we were able to write a tool using PHP and Node to convert all of our WordPress data into a format that we could import into Sanity.

Read About Our How We Migrated Our Content

For a framework, we had two main options: Gatsby and Next. For me, the choice was easy. While Gatsby offers a theme and plugin ecosystem that resembles Wordpress’s in some ways, Next’s ability to dynamically work as a static site generator or a server side rendering framework on a page-by-page basis is a huge win. We had recently tested it out on our 

 and were immediately impressed. In the time since that project, Next has rolled out features like the incremental static regeneration which means that we can generate our featured case studies at build time, generate additional case studies at runtime when they are requested and also create server-rendered landing pages that can take advantage of A/B testing, cookies, etc.

Next also introduced API routes, which means instead of relying on a full custom server for things like form handling, we can just create a file at “api/form,” and Next will generate an API endpoint for us where we can run server-side code while doing everything else on the client.

Using a React framework also enabled us to take advantage of libraries like Framer Motion, which provides physics-based animations that give layout changes a more natural, playful feeling than duration-based CSS animations.

Vercel was our first choice for hosting because it supports Next out of the box as it is built by the same team. But more than that, they provide a great development experience. We have our project set up as a monorepo, for which Vercel recently rolled out support, which means our CMS and frontend are two separate packages that we host in one repository, and they each have their own project in Vercel with continuous integration through Github. Any time we open a PR for one of the projects, Vercel creates a preview deployment where we can view all the changes just how they will appear in production, and when we merge it into our “main” branch, a new production deployment is created. And if anything goes wrong, we can easily roll back to a previous deployment.

While we always work closely with the design team throughout the development process on a project, we often don’t get involved until fairly late in the design process. For this project, the goal was for design and development to collaborate on the design system and build it from the ground up, with an emphasis on componentization, since we knew we would be building the site with React.

Before design even got started, we got to work on the foundation of the design system. Inspired by the layout primitives in Andy Bell and Heydon Pickering’s Every Layout, we created React components for basic layouts that can be truly modular and intrinsically responsive, so we could use them all throughout the site. My favorite is The Switcher, which switches directly from a row to column layout with no breakpoint and no awkward in-between wrapping states with orphaned items.

To help with testing these primitives and collaborating with design, we built our components in 

, which enabled us to isolate components, visualize variants, and test responsiveness and accessibility. With this workflow we could develop layout primitives individually and share them with design; then design could construct layouts with these primitives in mind and hand back components, we could build those in Storybook and have them reviewed and incorporated into full page layouts, which we could then build in our Next.js app. This workflow brought design and development much more in sync and enabled a more efficient back-and-forth compared to a more standard hand-off where development begins after design has already completed the full page layouts.

The most exciting thing about our new site is what’s yet to come. Moving to a modern stack has opened the doors to all kinds of new ideas and experimentation. We’re only restricted by our imaginations.

We are extremely proud of what we were able to build and are excited to continue work on improving the site for our employees, clients and friends over the coming years.

PHP, Javascript & React

Custom Dev

Developing the New via.studio

User Experience

UX / UI

Ecommerce

Web Design

Websites

Foxhollow Farm Website Redesign

HTML, CSS and Javascript form the "presentation layer" of modern web development in your mobile and desktop browser. These things together are considered "Front-end Development". The tools, techniques and standards are changing all of the time - but our development team is always staying abreast of the latest. For our partners, we do the research, experimentation and testing needed to make sure your audience has an accessible, fast, reliable experience.

Frontend Development

Frontend Development: Case Studies

01

Foxhollow Farm Website Redesign

Frontend Development: Blog Posts

Email @ 50: Email Development

Developing the New via.studio