My Current HTML Email Development Workflow

HTML Email Development Workflow: A Practical Guide to Improve Efficiency

Each web developer has his own unique way of working: preferred editors, auxiliary tools, personal project processes, and more. For large or complex projects, a clear development path is crucial, which saves time and minimizes errors.

This is especially important in HTML email projects in my experience. Email requires a lot of repetitive tasks that are not particularly complex in themselves (at least not always), but can become tricky due to the large number of elements and tasks that need to be checked.

Here I will try to explain my personal HTML email development workflow. I hope you can pick out the sections you like from them.

Key Points

• The author emphasizes the importance of a clear development path in HTML email projects to save time and minimize errors caused by a large number of repetitive tasks.
• Using preprocessors, such as Jade for HTML and Less for CSS, can simplify the development process by reducing the need for lengthy code, especially in terms of nested tables. It is recommended to use tools such as CodeKit and Coda to compile files and preview work in real time.
• It is recommended to use the Gulp Email Builder package to automate the last few steps of the workflow, including inlining or embeding CSS files, testing with the Litmus API, and sending additional test emails.
• A good HTML email development workflow can significantly increase productivity. The author's workflow includes local testing creation, CSS inline, and automated testing using Gulp Email Builder. Customizing these steps is encouraged to suit your personal preferences and needs.

Typical email development workflow

The classic email development workflow consists of three main steps:

• Creation (conduct preliminary local testing)
• CSS Inline
• Test

The final test (using inline CSS) is the most time-consuming step, as we may have to repeat it multiple times. The "CSS Inline" and "Test" tasks require additional work and attention: First, you must be careful to distinguish the original working copy from the inline copy. Additionally, the final test requires you to send inline HTML to various accounts to check your design against various email clients.

Sending code by email is a bit tricky, as most clients don't allow you to compose emails by pasting HTML code into the body (the only one I know is Thunderbird). But every test requires many operations to write emails, inline CSS, paste code, etc.

If you have a testbed account (Litmus, Email On Acid, Campaign Monitor, or others), you can simplify the final test task by submitting inline code to the testbed, but for more accurate testing you still need to Send codes by mail. In the past, I used a small PHP script to send test emails, which saved some time, but still required repetition of certain tasks.

Back to CSS, you may need to work on two files: one for inline and one for embedding (for clients that support media queries).

You have to edit the CSS directly into the HTML file, then start the inline tool (such as the Mailchimp inline tool), and finally embed the second CSS into the inline file (it feels annoying to just write it out!)

We can now review our workflow plan in more detail:

To obtain a truly efficient workflow, many problems remain unresolved, with significantly more repetitive steps than creative steps, which rarely lead to good results.

Luckily, we still have some ways to use: preprocessor and task runner.

Add HTML and CSS preprocessor

When I started using preprocessors, I immediately realized how useful they are for email development. For both HTML and CSS, preprocessors can easily simplify the need for lengthy code (especially HTML).

I mainly use Jade for HTML and Less for CSS, but you can choose the technology you like. Jade is very useful when dealing with duplicate and confusing code, such as nested tables. Please see the following three-layer nested table examples.

<code class="language-html"><table> width="100%" id="wrapper">
  <tbody>>
    <tr>>
      <td> width="100%">
        <table> align="center" class="header">
          <tbody>>
            <tr>>
              <td> width="100%">
                <table> width="100%">
                  <tbody>>
                    <tr>>
                      <td>>cell 1</td>>
                      <td>>cell 2</td>>
                      <td>>cell 3</td>>
                    </tr>>
                  </tbody>>
                </table>>
              </td>>
            </tr>>
          </tbody>>
        </table>>
      </td>>
    </tr>>
  </tbody>>
</table>></code>

The Jade code that produces the same code is as follows:

<code class="language-jade">table(width="100%" )
  tbody
    tr
      td(width="100%")
        table( align="center")
          tbody
            tr
              td(width="100%")
                table(width="100%")
                  tbody
                    tr
                      td cell 1
                      td cell 2
                      td cell 3</code>

As you can see, there is no longer an issue with unclosed tags, the code is easy to read.

With Jade, you can create complex templates and build your own library of code snippets to reuse code in more projects. For Less or Sass, you can do the same.

You can compile files with Gulp or Grunt, but for a quick preview of your work, I found that Coda and CodeKit provide the best solutions.

The "local test" task in our workflow provides us with initial feedback on the work and, crucially, it does not require other actions.

CodeKit compiles our Jade and Less files on save and can preview your project in real time. Coda, on the other hand, allows you to edit files and preview automatically refreshed compiled files in a separate window:

All of these steps are fully automated, and you can focus your work on design rather than those less fun, repetitive tasks.

Now we have Jade and Less files for creation, as well as compiled HTML and CSS files for preview. The next step is to put everything together for final testing.

Quick test with Gulp

I have looked at a lot of Gulp or Grunt scripts to automate the last few steps of the workflow. npm offers many solutions, but in the end I chose the Gulp Email Builder package. This package is the Gulp version of a larger project, and it also has a Grunt version if you prefer.

Email Builder allows you to inline or embed CSS files, test using the Litmus API, and send additional test emails.

To use Email Builder, of course you need to install Gulp. I've covered this in my post "Customize Bootstrap icons with Gulp", so you can check out the post for help. Additionally, you can read Etienne Margraff’s article on Gulp and Grunt workflows.

In addition to Email Builder, we will also use the Gulp-Replace package, so you will need to install it as well.

As with every Gulp task, we must set gulpfile.js:

<code class="language-html"><table> width="100%" id="wrapper">
  <tbody>>
    <tr>>
      <td> width="100%">
        <table> align="center" class="header">
          <tbody>>
            <tr>>
              <td> width="100%">
                <table> width="100%">
                  <tbody>>
                    <tr>>
                      <td>>cell 1</td>>
                      <td>>cell 2</td>>
                      <td>>cell 3</td>>
                    </tr>>
                  </tbody>>
                </table>>
              </td>>
            </tr>>
          </tbody>>
        </table>>
      </td>>
    </tr>>
  </tbody>>
</table>></code>

First, we include all the required packages and set four variables:

• current_date is a string representing the current date; we will use it to distinguish test email subject lines so that it is easier to distinguish different versions.
• email_subject
• remote_imgs_basepath is the URL of the remote folder containing our image. I use it to perform local tests by setting relative paths for the image (so that I can easily make all the necessary changes), but the final test (and send task) requires the image to be uploaded to the remote folder, so I use Gulp Replace to get all the src properties Change to remote_imgs_basepath
• email_builder_options is an object used to configure Email Builder

In this example, the email_builder_options object has three elements, and you can check the email-builder-core page for a complete list of all available options.

The first element encodeSpecialChars ensures that all special characters are encoded into their HTML numeric form.

emailTest element is used to set up email testing. It requires some parameters:

• email: Comma separated email addresses to which we send test emails. I have an account for every email service that needs to be tested (Gmail, Outlook, Yahoo, etc.) to quickly check them in their web mail pages and mobile apps.
• subject: The subject of the mail (note that I have added the current_date variable to quickly identify which version I am working on).
• transport: The sender needs to perform the parameter

If you use Gmail as the transport parameter, you need to activate "Allow less secure apps" in your Google Account settings, otherwise the sending task will fail (it is better not to use your personal account for this):

The third parameter allows you to set up tests on the Litmus platform (of course, you need a Litmus account). You must indicate your account parameters, optional topics (which will be used for grouped tests if you perform multiple tests), and a list of email clients to test.

To add a client, you must use its to test the application code . You can get this code from the application_code field of the https://litmus.com/emails/clients.xml file (note that you must be logged in to access this file).

In the example above, the line

<code class="language-html"><table> width="100%" id="wrapper">
  <tbody>>
    <tr>>
      <td> width="100%">
        <table> align="center" class="header">
          <tbody>>
            <tr>>
              <td> width="100%">
                <table> width="100%">
                  <tbody>>
                    <tr>>
                      <td>>cell 1</td>>
                      <td>>cell 2</td>>
                      <td>>cell 3</td>>
                    </tr>>
                  </tbody>>
                </table>>
              </td>>
            </tr>>
          </tbody>>
        </table>>
      </td>>
    </tr>>
  </tbody>>
</table>></code>

Tell Litums to test our emails using the Gmail App (Android), Gmail (Explorer), and iPhone 5s (iOS7).

The results can be viewed on Litmus, just like handmade ones:

Of course, if you just want to perform email tests, you can remove the litmus parameter from email_builder_options.

The last few lines of the gulpfile do all the work:

• We first told Gulp to do our work using the explore_and_taste.html file (this is the HTML generated by CodeKit from our Jade file, which we just used for the first preview)
• Using the replace module, all local paths will be replaced with the remote path we set earlier (replace(/src="imgs//g, 'src="' remote_imgs_basepath))
• Finally, execute the EmailBuilder task, send the test to Litmus and email address, and register the ready-to-send file.

Where is the CSS file?

Email Builder really simplifies this task. You can manage them by simply adding data attributes to links or style tags:

• Links or style tags without data attributes will be inlined
• If they have data-embed attribute, the CSS rules will be embedded
• Finally, data-embed-ignore allows you to set some CSS rules for development purposes only (they will be ignored when processed).

Similarly, Coda simplifies Gulp processing, allowing you to use its internal terminal application:

Conclusion

Now we can finally reschedule our workflow:

You can customize each step according to your needs, use another editor instead of CodeKit, use Grunt instead of Gulp, use Sass instead of Less, and more. No matter what technology you choose, such a workflow can really increase your productivity.

If you have your own HTML email workflow and how it differs from the ones covered in this tutorial, please let me know in the comments.

Frequently Asked Questions about HTML Email Development

What are the best practices for HTML email development?

HTML email development is a complex process that requires in-depth understanding of coding and design principles. Some best practices include using inline CSS to ensure your style is applied correctly, using tables to layout to ensure compatibility with all email clients, and testing your emails on multiple platforms and devices to ensure they are anywhere All look good. Furthermore, it is important to keep the code concise and orderly, use alt tags for images, and include a plain text version of the email for users who cannot or do not want to view HTML emails.

How do I learn HTML email development?

There are many resources available for learning HTML email development. Online courses offered by Udemy and Skillshare can provide a comprehensive introduction to the topic. Additionally, blogs and articles on SitePoint and Email on Acid can provide valuable tips and insights. Practice is also critical – try to build your own email from scratch to understand the process.

What HTML email development tools do I need?

HTML email development requires a text editor for writing code, an email client for testing emails, and possibly a design tool for creating email layouts. For these tools, there are many free and paid options available, so you can choose the one that best suits your needs and budget.

How to make my HTML email responsive?

Making your HTML email responsive includes using media queries to adjust your layout based on the screen size of the device you view your email. This may include changing the size of the image, adjusting the layout of the table, and so on. There are many resources available online to guide you through the process.

What are some common challenges in HTML email development?

Some common challenges in HTML email development include handling inconsistencies between different email clients, ensuring your emails look great on a variety of devices, and keeping your code concise and orderly. Additionally, balancing an attractive design requirement with the limitations of email coding can also be challenging.

How to test my HTML email?

Testing your HTML email is an important part of the development process. This can be done by sending an email to yourself and viewing it on different devices and email clients. There are also some online tools that can simulate different devices and email clients for you.

How to use forms in HTML email development?

Tables are a key tool in HTML email development because they provide a way to create layouts compatible with all email clients. This includes creating a grid-like structure for your email using HTML table tags and then placing your content in this structure.

How to use inline CSS in HTML email development?

Inline CSS involves placing your CSS styles directly in HTML tags, rather than in a separate stylesheet. This is important in HTML email development, as some email clients do not support external stylesheets. To use inline CSS, just include your style in the "style" property of the HTML tag.

How to include images in my HTML email?

Images can be included in HTML emails by specifying the URL of the image using the "img" tag and the "src" attribute. It is also important to include a "alt" attribute to provide a text description of the image to users who cannot or do not want to view it.

How to create a plain text version of HTML email?

Creating a plain text version of an HTML email includes removing all HTML tags and leaving only text content. This can be done manually, or there are some online tools that can do this for you. Plain text versions containing emails are important for users who prefer not to view HTML emails.

The above is the detailed content of My Current HTML Email Development Workflow. For more information, please follow other related articles on the PHP Chinese website!