Email template development guides, tutorials, tools - EDMdesigner Blog

Email Marketing and Mobile Optimization

Gergely Csaba Nagy — Mon, 14 Jan 2019 08:03:38 GMT

Although we know we are now in mobile email world, it seems that many subscribers in general still have negative feelings about marketing emails on their mobile.
The top three reasons:

Too many emails
They are not relevant
Too small to read and interact with.

Number one and two aren’t exclusive to mobile email. A marketer needs to overcome all three to become an inbox champion. Ideally, your subscribers have a profound appreciation for you and your messaging. If there is brand appreciation, there is a much bigger chance your subscribers will interact with them based on the relationship. Even if your emails are not perfectly targeted or sent at the optimum time

Content first: Emails must Help Subscribers

If your prime objective is to generate revenue through email marketing to your list, there is nothing wrong with that. Even more, the revenue is often one of the top reasons that email marketing is getting such high ROI, but subscribers aren’t ATMs and we shouldn’t approach it like that.

Look at your list as people who have reached out to you because they like the way you think. Look at your list as a community of people who need help, who need your expertise.

With every email you send, keep in mind that you can add value by helping subscribers with problems that they are facing. Yes, this can be through your own products and recommendation of other products that is perfect for their needs, nothing wrong with selling. But email marketing is not purely “Always Be Closing”, relationship building mails can be helpful without a secondary pitch.

Your subscribers will come to understand that you have (premium) products and services and might start to think about those over time as they come to trust you.

Emails MUST Be Easy to Read

A great relationship might give you inbox forgiveness, but your emails should be accessible. There are many aspects of readability that you can address. Like using mobile optimized and responsive design. Research on the importance of responsive email design shows that 82% of people open emails on their phones and that over half of that group delete emails that are not formatted for mobile displays. Responsive design allows scaling your full-sized newsletter and good email marketing provider’s tools will allow you to rearrange elements, to use larger buttons and reduce clutter very easily on mobile versions of your newsletter. But Responsive Design is not everything.

Image source: Getresponse.com

Readability

Emails need to be displayed in large fonts on mobile. This is just as important as being succinct. If someone is reading your email on their phone they are possibly talking or getting distracted at the same time. The attention you get is the attention you get, make use of it. You have to make the user’s life simple or they will just press the Delete button.

Make it easy to read.

Use a 16 px or 18 px sans serif font for phones. Use a 14 px font for tablets. Even on laptop screens emails need a** 12 px font** to allow viewers to read them easily.
Here are some mobile scanning tips:

Use short sentences. Short.
Use one or two sentence paragraphs.
Include a button to link CTA to the full post or product on your (responsive) website.

Email Frequency MUST Be Just Right

If you send emails less than once a month then subscribers are likely to forget that they signed up to your newsletters. If you send emails too frequently then your unsubscribe rate will sky-rocket. One of the most common complaints about email marketing is that emails are sent too often.

There is no magic number regarding email frequency; it depends on your relationship with your subscribers. Coming back to the point first made: Relationships first.

Conclusion

When someone signs up to your email list they are granting you a privilege. Respect that privilege or lose it. You are being invited into people’s homes and phones because they think you have something interesting to say.

You will read much advice about getting your subscribers to open your emails, but everything you read is less important than the emotional engagement between your subscribers and you.

Your Input

Do your email subscribers love you? How have you earned their love? Please share your thinking using the comments box below.

Guest post by @jvanrijn

Jordie van Rijn – is an independent email marketing consultant; Helps companies get the most out of their digital efforts and find email marketing software.

16 Command Examples to Send Email From The Linux Command Line

Mihály Sáróy — Wed, 11 Apr 2018 13:25:03 GMT

Whether you are a developer working non-stop in the Linux command line or a server administrator wanting logs or other data extracted from administered systems, knowing how to send email from the command line is greatly useful.

In this post, you'll find examples of how to send email from the terminal. We'll look at custom configurations and touch on how to set up SMTP connections to email accounts or email service providers. I'll show you how to install the necessary console mailer packages and provide background for command line options based on the package's manuals.

Setting Up Command Line Mailer Packages

All the mailer packages throughout the tutorial are available through Debian's Advanced Package Manager so the installation steps in the example below may be used for all the showcased packages.

Please note that these pieces of software may be installed by other default package managers such as yum or dnf depending on your Linux system distribution.

In most cases, either sendmail or postfix is available in each Linux distribution out-of-the-box or at least that's what similar blog posts say. Either I'm unlucky or the others were wrong, but I had to install one manually. However, you definitely need one of them for email delivery.

Setting Up Sendmail with SSMTP Package

I'll continue with sendmail and the SSMTP package. SSMTP contains the sendmail package under the hood as you'll see and it facilitates the configuration, which is pretty hard for sendmail otherwise.

Step 1. Check if Command Line Mailer Package is Installed

Type in the mailer package's name just the way you would run the command, to check if it's available:

If the package is installed, the command runs, and the prompt changes — while trying to execute the command — and you'll see a blinking cursor followed by the message Recipient names must be specified in the case of sendmail. Conclusion: the package is installed.
If the package is NOT installed, you'll receive a warning message and a suggestion how to install it:

$ sendmail

The program 'sendmail' can be found in the following packages:
 * exim4-daemon-heavy
 * exim4-daemon-light
 * postfix
 * citadel-mta
 * courier-mta
 * dma
 * esmtp-run
 * masqmail
 * msmtp-mta
 * nullmailer
 * opensmtpd
 * qmail-run
 * sendmail-bin
 * ssmtp
Try: sudo apt install

In this example, I tried if the sendmail command works. After we add the SSMTP package, this command and the ssmtp command will both work and change the command prompt in the terminal. Let's look at that!

Step 2. Installing Sendmail Command Line Mailer Package

As the terminal output suggested, we need to run the Advanced Package Manager's install command — usually with root permission — to install the necessary package. As mentioned before, the configurations are much simpler for sendmail when you abstract away the complexity of the configuration. That can be done with SSMTP:

     sudo apt install ssmtp

Step 3. Verify the Installation

After the installation completed, you can check if sendmail is able to forward messages. Type the below code in the terminal:

      echo "Subject: hello" | sendmail test@example.com

It should send out the email if everything works correctly. Here the "hello" string piped to the sendmail command will be the subject of the sent message, while the defined email address is naturally the recipient of the email.

You run the command... and, oops: sendmail: Cannot open mailhub:25. The reason for this is that we didn't provide mailhub settings at all. In order to forward messages, you need an SMTP server configured. That's where SSMTP performs really well: you just need to edit its configuration file once, and you are good to go.

Step 4. Configuring SSMTP

Let's locate the config file at /etc/ssmtp/ssmtp.conf. Here, you should put the code below to configure an SMTP relay:

    UseSTARTTLS=YES
	root=
	mailhub=smtp.gmail.com:587
	AuthUser=
	AuthPass=

This means that you set up an external service that will actually forward
your emails. When you provide credentials to Gmail for example, you'll see the messages sent from the terminal in your mailbox's 'Sent mail' directory. The configurations look similar with other services too.

This was the basic configuration for sendmail and the installation steps for any frequently used command line mailer package. Next, we'll jump on installing and trying out various other packages.

Sending Email Using the SSMTP Command

This is a nice little tool we just configured for mail delivery. As its man page suggests, it's a minimalistic emulator of sendmail. As such, SSMTP allows users to transfer emails through an SMTP server from the Linux command line. It provides the means to connect to a mailhub with a proper configuration file. If your config file was set up right, all your worries regarding command line email sending can disappear.

Basic Implementation of the SSTMP command:

If you just use SSMTP, the command should look as follows:

      ssmtp  test@example.com < mail.txt

Following the ssmtp command, you should put the recipient address, then you can include a file that will show in the email body. Here you can define headers for the message, list further recipients and set the content type. This way you can send HTML emails. SSMTP will interpret your message and use the provided values properly. Here is an example of an HTML you might send:

	Cc: example@edmdesigner.com
	Subject: This is an HTML email
	From: developer@example.com
	Content-Type: text/html; charset="utf8"


	html>
	
	
	
	You can add any valid email HTML here.

You can't really give further options with SSMTP as they are not respected by its minimalistic design.

Troubleshooting:

In case you run into the following error on the command line:

      ssmtp: Authorization failed (534 5.7.9  
      http://support.google.com/accounts/bin/answer.py?answer=185833 
      bk8sm8525341pad.28 - gsmtp)

that’s likely because Gmail is not treating SSMTP as a secure application. To get rid of this error, you need to change the settings in your Gmail account – you can look up more information on potential risks there as well.

Sending Email Using the Sendmail Command

For quite some time now sendmail is the classical mail transfer agent from the world of UNIX. It was first introduced in 1979 and its highly-configurable nature and scalability made it the default go-to for server administrators.

We've already seen how to send basic emails by the ssmtp command, so let's see the difference using sendmail:

      echo "Subject: hello" | sendmail -v test@example.com < mail.txt

I threw in the -v argument, which will make the communication between the mail server and your mail transfer agent visible.

There are plenty of configurations that you can use if you set up your own mail server and implement sendmail on it. However, that is out of the scope of this article. We will return to the topic in an upcoming one. Stay tuned.

Sending Email Using CURL Command

This tool is also tremendously common for data transfer from a server. It supports many protocols, like HTTP, FTP, POP3 or SMTP. The CURL package is used widely around the globe, one main reason is that it has native PHP implementation and PHP was the default server-side scripting language for a long time.

Installation:

Check if the package is already installed. If not run the below:

      sudo apt install curl

When you're done, you can access the cheat sheet for the available options for CURL by running curl -h. The more detailed version is accessible by either man curl or curl --manual. If you want to gain in-depth knowledge using cURL, there's this handy Ebook that contains everything you would ever want to know.

Basic implementation for email sending with CURL:

curl --url 'smtps://smtp.gmail.com:465' --ssl-reqd \
  --mail-from 'developer@gmail.com' --mail-rcpt 'edm-user@niceperson.com' \
  --upload-file mail.txt --user 'developer@gmail.com:your-accout-password'

In order to send an email with CURL, you need to set up SMTP connection. Most often Google's or Yahoo's outgoing mail servers are used for testing email sending with SMTP. Please note that you must turn on access for less secure apps in Gmail settings and similar additional security settings may apply for Yahoo as well.

In the terminal command snippet above, the --url and --user parameters define the SMTP connection settings. The password section for --user parameter is your account's password for the given email address. Naturally, you could also use cloud email service providers. I will show that using Mailgun in the following section.

Advanced implementation for email sending with CURL:

Working with email delivery platforms, you first need to obtain an API key. In this tutorial, I'll show CURL email sending example using Mailgun, so if you get stuck during the registration process follow this setup guide to get on the right track.

curl -sv --user 'api:key-7e55d003b...f79accd31a' \
    https://api.mailgun.net/v3/sandbox21a78f824...3eb160ebc79.mailgun.org/messages \
    -F from='Excited User ' \
    -F to=sandbox21a78f824...3eb160ebc79.mailgun.org \
    -F to=user@gmail.com \
    -F subject='Hello' \
    -F text='Testing some Mailgun awesomeness!' \
   --form-string html='EDMdesigner Blog

This tutorial helps me understand email sending from Linux console' \
    -F attachment=@logo2yellow.jpg

The syntax is pretty straightforward. You may have noticed before, but you need to end each line of the command with \ characters. This is a line continuation character, the command can be run without them all in one line as well. The other thing to remember is the -F option. An excerpt from the man page:

 -F, --form 
        (HTTP)  This lets  curl  emulate  a  filled-in form 
        in which a user has pressed the submit button. 
        This causes curl to POST data using the Content-Type 
        multipart/form-data according to RFC 2388. 
        This  enables uploading  of binary files etc. 
        To force the 'content' part to be a file, prefix 
        the file name with an @sign.

As I encouraged before, it's a good practice to dive into the manuals when using these command line mailer commands. As the CURL manual says, basically you're creating a form to send. Each line is an entry given as a name=content pair. When you attach files from your local machine, you need an @ in front of the file name.

This is how the delivered email will look like:

You could do the same using most of the other email delivery platforms, like Sendgrid for example.

Sending HTML email from the command line with CURL:

You can apply the same logic of building a form in a text file, which enables you to send HTML messages easily:

	To: customer@gmail.com
	Subject: This is an HTML message
	From: developer@yourcompany.com
	Content-Type: text/html; charset="utf8"

	
	
	
	
	You can add any valid email HTML here.

If you run the simple command from the first example...

curl --url 'smtps://smtp.gmail.com:465' --ssl-reqd \
  --mail-from 'developer@edmdesigner.com' --mail-rcpt 'edm-user@niceperson.com' \
  --upload-file mail.txt --user 'developer@gmail.com:your-accout-password'

... and direct the --upload-file parameter to the updated text file (mail.txt in our case), the received message will show the HTML content.

Troubleshooting:

You may need the --insecure switch, which allows CURL to perform "insecure" SSL connections and transfers. CURL will return an error message if the remote server is using a self-signed certificate, or if the remote server certificate is not signed by a CA listed in the CA cert file.

Sending Email Using Swaks command

As their documentation states, Swaks is a flexible, scriptable, transaction-oriented SMTP test tool. It is able to handle SMTP features and extensions such as TLS, authentication, and pipelining and multiple version of the SMTP protocols. It also supports multiple transport methods including UNIX-domain sockets, internet-domain sockets, and pipes to spawned processes.

Installation:

      sudo apt install swaks

Basic implementation for email sending with Swaks:

In order to connect to an SMTP account you need to provide the server -s, the user -au, the password -ap and the address -t (where you want to send your mail) flags. The -tls flag is also important if you connect on port 587.

      swaks --to mailbox@example.com -s smtp.gmail.com:587 
      -tls -au  -ap

The credentials can also be provided via command line prompts, if you only specify to authenticate -a, not filling in the user and password through command line options.

Advanced implementation for email sending with Swaks:

      swaks --to mailbox@example.com -s smtp.gmail.com:587 -tls -au  -ap   --attach  -d ./mail.txt

There are other options which we will not touch now. Let's head to our next mailer package!

Sending Email Using the Mutt Command

Mutt is different from the previous email clients, as it is a feature-rich command line email client. You can use it for reading emails from the Linux terminal, connecting to local user mailboxes or to POP/IMAP servers. Mutt supports several mailbox formats such as mbox, MH, maildir, MMDF, full control of message headers during email composition, and multiple message tagging and colors to handle messages.

Installation:

      sudo apt install mutt

Basic implementation for email sending with mutt:

By this time you won't be surprised by the structure of the command. You can provide an empty message body with < /dev/null:

# mutt -s "Test Email" user@example.com < /dev/null

Advanced implementation for email sending with mutt:

For sending email including attachments, you need the -a flag. This way you can send useful files, like system logs, to a specified address.

# mutt  -s "System logs" -a /opt/backup.sql user@example.com < /dev/null

You could also send HTML email if the file extension you add to the message body is in HTML format. Mutt will recognize the file type and resolve it so it won't send your HTML as plain text:

mutt -s "Email subject" test@example.com < email.html

This is it for email sending with mutt. If you have it on your machine, I'd suggest to try out how you can work with incoming configuring your mailbox and handling incoming messages. If you do so, please share your thoughts in the comment section below. I welcome any opinion about the packages shown in the tutorial.

Sending Email Using the Mailx Command

The Mailutils is a compound package for multiple use cases. It's designed to serve regular users, system administrators, and developers. We'll only touch on its basic functionalities regarding email forwarding. If you are interested in more features, check out its man page.

Installation:

      sudo apt install mailutils

Basic implementation for email sending with mailx:

The mailx package has 2 equal command syntax (mail and mailx both work in the exact same way). The most simplistic command consists of the mail/mailx command and the address to send the mail to, but you would probably include the subject and at least some text-based message body. Such a command should look like this:

      echo "message body" | mail -s "subject" test@example.com

By using the echo command and piping the output to the mail command, you can avoid mailx's additional prompts for Cc addresses and the message body.

Advanced implementation for email sending with mailx:

For the advanced example, we will send a full-fledged HTML email again. We need to provide the email HTML file of our choice with the < character and add the "append flag" with the content type. The full code looks as follows:

      mailx -a 'Content-Type: text/html' 
      -s "This is advanced mailx indeed!" < email.html 
      "recipient1@gmail.com, recipient2@yahoo.com"

You can also set a return address with --return-address=, which may be useful. Another useful option, which I couldn't resolve to work with HTML email parallel, is to provide attachments in the same message: -A "mail.txt". Though you can list multiple recipients, only a single attachment can be attached. You could configure external SMTP server if that fancies you.

Using Telnet Alternative Openssl Command

Telnet is an interactive communication protocol for communication with another host. It could be used to open an SMTP connection to another server and transfer email messages. However, as the protocol is not secured, most servers will reject this communication type. This is where Openssl comes into the picture as it's built with SSL/TLS security included. It is invoked similarly to telnet with a host argument, and it performs an open command implicitly:

        smiska➜Desktop/emails» openssl s_client -connect smtp.gmail.com:465     
                               -crlf -ign_eof
        ---
               certificate negotiation output from openssl
        ---

        220 smtp.gmail.com ESMTP j92sm925556edd.81 - gsmtp
            EHLO localhost
        250-smtp.gmail.com at your service, [78.139.22.28]
        250-SIZE 35882577
        250-8BITMIME
        250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH
        250-ENHANCEDSTATUSCODES
        250-PIPELINING
        250-CHUNKING
        250 SMTPUTF8
            AUTH PLAIN *passwordhash*
        235 2.7.0 Accepted
            MAIL FROM: 
        250 2.1.0 OK j92sm925556edd.81 - gsmtp
            rcpt to: 
        250 2.1.5 OK j92sm925556edd.81 - gsmtp
            DATA
        354  Go ahead j92sm925556edd.81 - gsmtp
            Subject: This is openssl mailing

            Hello nice user
            .
        250 2.0.0 OK 1339757532 m46sm11546481eeh.9
            quit
        221 2.0.0 closing connection m46sm11546481eeh.9
        read:errno=0

I indented the inputs you need to provide while the communication channel is open. These inputs are self-explanatory, but one thing I need to detail is the password hash. It can be a base64 encoded hash, which you can obtain with the following command: echo -en '\000username@gmail.com\000gmailpassword' | base64. The escape characters from the string can't be omitted. If you don't have the base64 package installed, it is available through package managers.

As you can see above, this means of email sending only provides an interface for text-based messages, therefore it has its limitation in use cases. On the other hand, it shows all information exchanged with the mail server, which makes debugging really easy.

Troubleshooting Mail Problems

Check the mail logs

You need to locate your log file by navigating to the corresponding folder. I prefer to use my code editor (eg. Sublime Text) for this so I can have the logs with syntax highlight:

$ sudo subl /var/log

Depending on your current Linux distribution you may need to look at different source.
The log may contain useful information about deliverability problems. At this point, when you scroll to the bottom of this:

you can inspect if delivery is successful or understand why the process failed.
It can happen that your console shows no errors, but in the mail log you can see that the message was queued for delivery, so the process didn't halt on your machine but probably was denied by the mail server you were trying to reach.

Running All Command in a Sequence

So, everything is ready for the final test. All the mailer terminal commands are gathered here in a script file. Once you downloaded the working folder with the script file in it, navigate to the containing folder and make the script executable: chmod u+x mail.sh. If you have all the files I provided ready, you can start testing the mailer commands shown in the tutorial. You just need to replace the "" to your test email address in the code and run ./mail.sh in the command line.

Once the script finishes running, your inbox will be filled with the test emails.

Well done!

Summary

In this article, I showed you many ways to send email from the Linux command line. Hopefully, based on what you saw, you can install and configure these services on your machine yourself as well.

The post showed the most commonly used command line mailer packages and how to send emails with them, and in the end, I created a shell script that gathers all the commands used in the article. You can download the projects working files here, and if you install the packages introduced in the tutorial and also fill in your credentials and recipient details, you can run the script at your leisure.

Could you follow each step of the tutorial? Very well then, it makes me glad. In case you have questions or see an opportunity to improve the content further by your ideas, please head to the comment section below.

Thanks for your attention. Happy sending!

How to Create Responsive Email Designs with React Native

Mihály Sáróy — Wed, 28 Feb 2018 10:24:00 GMT

Responsive design is a factor that you need to consider while building applications, sending out emails, and designing templates. If the design looks awful on a small screen, more than half of your customers will feel dejected and the numbers are not going to get better.

Email development has many challenges on it's own. We tackled many of these topics in a previous article series. Imagine receiving a newsletter into your inbox with a broken layout, poor grid system and a microscopic font style that’s impossible to read without zooming in. As the web is being veered off into a mobile first environment, the strategy for designing emails needs to be upgraded.

In this post — written by Cloudinary, a leading SaaS technology company in digital asset management — we will discuss some of the basics things that you need to take care of while creating a responsive email design using a web/mobile application. As a developer, you might have to integrate responsively designed email templates into your application UI or create templates on the fly. This post will teach you how to do that for an application built using React Native.

Why React Native?

React Native, as you might already know, is a popular framework for building cross-platform mobile apps for Android and iOS, which perform as well as a native application. It uses similar technology to that of its web counterpart, ReactJS. Both React and React Native are gaining grounds in terms of user base and popularity. If you’re developing a website and a mobile app for your product, you can reuse some components between React and React Native (for some information about this type of conversion, see this post).

As a developer, you might be asked to integrate responsively designed email templates into your application UI, or to create templates on the fly and send them to a bunch of recipients. You can use an API to send the email to the recipients and that’s the easy part. But building a dynamic front-end layout for sending an email with multiple themes and images might be harder to do.

The steps involved are pretty much similar to that of building a responsive design using CSS. However, with React’s component architecture, you can use use third-party components to compose responsive templates that are dynamic and reusable.

For the purpose of this tutorial, we are going to use create-react-native-package to build a new React Native project.

      npm install create-react-native-app
      create-react-native-app responsive-email

Now that we have that out of the way, let’s see what we can do to make the email responsive.

Create Email Templates using react-html-email Library

There is an awesome library called react-html-email that lets you write reusable component based emails. The library has a renderEmail() method that accepts an input component and renders it into an HTML string. Install the library by running

      npm install --save react-html-email

Next, use the following code to generate a very basic email.

      import { Email, Item, A, renderEmail } from 'react-html-email';

      const BasicEmail = () => (

        
           Hi 
          
            Hello Buddy!
          
        

      );
        renderEmail();

The library exports a few components like Email, Box,Span Item, A and Image. This covers almost all of the basic tags that you’d require in an email. After composing the email template, you can pass it onto renderEmail() to generate the HTML string. Here’s an example output string:

link Test 
Hello Buddy!

One of the good things about react-html-email is that it has an inbuilt validator that checks your HTML for compatibility against popular email clients. It returns a warning or an error when a validation check fails. If you ran the above code, you’d get a warning in the console like this:

Warning: Style property `padding-left` supplied to `A`, 
in outlook: padding for p, div and a tags is not supported

Add Responsive Design using Media Query

Media queries are important for creating responsive designs. When you have to develop for smaller screens, you can use the @media declaration to specify the viewport of the screen that the style should apply to. Most of the major email clients support media queries and allow the inclusion of query styles in .

The Email component that we created earlier accepts a headCSS prop. You can use this space to declare all the styles that should go into the section. For instance, if you need to override the font-size to 14px for all devices with screen size 480px or less, you can do something like this:

      const css = `@media only screen and (max-device-width: 480px) {
        font-size: 14px !important;
        text-align: center !important;
      }`.trim()

If you forget to add the the !important rule, other inline styles could override these declarations.

Now, add the headCSS prop to the Email component.

      
      //Removed for Brevity

Optimize Images for Mobile

Rendering optimized images based on screen size helps you create an attractive layout. For example, if you need a background image for the header, you can use a fluid image layout that looks like this.

      @media only screen and (max-device-width: 480px) {
      .header {
          background-image: url(https://www.example.com/image.png) !important;
          background-size: cover;
          }
      }

You can also stick to the traditional method, such as setting background-size to 100% if you’re not sure about compatibility.

For serving high-resolution images, the actual images will need to be twice their display size. You can use an image uploader component to add React Native images into the mix and then host them in different resolutions in the cloud. Based on screen size, the server will return a resolution of the image that aptly fits the screen size.

Responsiveness using MJML framework

We’d like to introduce you to another approach to automate the process of creating emails. MJML is a framework that was developed to reduce the pain of coding responsive emails. The framework isn’t React Native specific, but most of the features work with the React architecture. Prior to version 4, MJML used React components to render the output HTML and hence was fully compatible.

Being a framework, MJML lets you create reusable components that can be used to create email templates. It has an ecosystem of tools and plugins that you can use to extend the framework’s abilities.

To generate a basic responsive email using MJML, install mjml if you haven’t already, and import the mjml2html API. Create a basic mjml string like the one below, compile it and output it to the console.

      /*
        Compile an mjml string
      */
      const htmlOutput = mjml2html(`
        
          
            
              
                
                  Hello World!
                
              
            
          
        
      `)


      /*
        Print the responsive HTML*/
      console.log(htmlOutput)

MJML has its own responsive layout and a grid system that complements the layout. The whole email can be composed of multiple sections as shown in the code above. You can read more about the layout structuring in the documentation.

Summary

In this tutorial, we’ve covered some of the common techniques that you can use to compose responsive emails using React components. For building a front-end responsive email solution using React Native, you have multiple open-source tools like react-html-email and MJML that you can import into your project. The former is a small library that you can further customize depending on your requirements, whereas MJML is a full-fledged framework with focus on responsiveness.

Experiment with both the options and choose the one which works for you. If you have alternate ideas for integrating responsive email templates into a React Native project, share them in the comments!

Using PHP for Sending HTML Emails with Mailgun, Sendgrid & Amazon SES

Mihály Sáróy — Wed, 24 Jan 2018 14:36:11 GMT

We have already discussed the PHP native mail() method and PHP mailer packages in a previous article. First, we covered the mail() method features - such as sending rich HTML email templates with attachments. They were satisfactory on their own.

Additionally, we looked at two of the most frequently used packages, PEAR Mail package and PHP Mailer. We went through the installation steps and saw the value added by their use.

This includes, but is not limited to:

The choice of configuring external SMTP directly from the code
Easier handling of header fields and attachments
Cleaner syntax and
Built-in security features

Although these PHP mailer packages may be used for transactional emails as well as bulk sending for email lists, email cloud-based APIs are considered better solutions. There are several reasons for behind this. The most important one is that cloud hosts often prevent sending emails to preserve domain reputation. If you don't follow every requirement your emails may not be sent. The use of email APIs raises sending reliability and API providers also offer services that improve delivery rates.

Another reason is that when mass emails - eg. hundreds of thousands - are sent, you'll probably want to know statistics and also want smart tools to manage unsubscribes and email lists based on recipient behavior. They also help to simplify the required PHP mailing scripts, which is also a benefit from a developer's point of view.

Within this article, I'll show you three of the most popular choices for bulk email sending using PHP code. You'll see how to set these services up and you'll learn about some useful things such as a step-by-step description of how to include an image attachment with PHP script or how to create a reusable email template.

Sending HTML Email Templates Using Mailgun

Mailgun is a wonderful email API for sending transactional emails. As an email API should, they put a big emphasis on deliverability and domain reputation. You can set up multiple domains with isolated reputation, DKIM or SPF email sender validation, which is all key when it comes to managing reliable email sending.

To gain access to their API, first, you need to sign up on their webpage to get an Access Key. The key will enable the use of the API services. By first, you need to provide your contact details and information about your estimated email sending volume:

Then an opt-in account verification email will be delivered to your inbox.

After confirmation, you'll be faced with a quick setup guide:

You can choose the desired programming language and get started immediately. Moving on, I'll walk you through the PHP code implementation. Setting up a PHP wrapper script for Mailgun is really straightforward.

The steps are the following:

Include the vendor/autoloader.php script (when using Composer)
Instantiate the client
Make the call to the client

Other third-party services follow the same logic so you better store this piece of information really well.

Building PHP projects become much easier using the Composer dependency manager. If you are new to using Composer, read about the installation details and the background about it. It'll make PHP email sending much easier.

For now, we just go through with the necessary steps to have Mailgun ready for use with PHP:

    1. Run in the terminal: $ composer init

    2. Answer the setup wizard questions:

        example 1: Would you like to define your
                dependencies (require) interactively [yes]? no
        example 2: Do you confirm generation [yes]? yes

    3. Add these to the generated 'composer.json' file:

        "require": {
            "mailgun/mailgun-php": "^2.4",
            "php-http/curl-client": "^1.7",
            "guzzlehttp/psr7": "^1.4"
        }

    4. Run in the terminal: $ composer install

Do you remember the 3-step list from the beginning of the section? Good, because that's what we'll continue with:

         sendMessage($domain,
                    array('from'    => 'Developer ',
                            'to'      => 'Friendly User ',
                            'subject' => 'Hello Friendly User',
                            'text'    => 'Testing some Mailgun awesomeness with PHP!'));
        ?>

If you use the script in a web application, you should store the Mailgun API key and other sensitive data in environment variables.

The only thing you might not know already is where to find your domain and the corresponding API key. There's no need to worry, just sign in to your Mailgun account end select the "Domain" navigation item:

This was the most basic implementation of the Mailgun API with a PHP wrapper. Let's see a more compound example code of PHP with attachments and other customization!

HTML and Image Attachment with PHP Mailgun API Wrapper

In the previous section, we uncovered how to use the sendMessage function with the key parameters. Now, we'll reveal a few more properties we could use.

Working at a company providing bulletproof HTML email templates with drag & drop editor, I always consider the support of HTML format as a primary objective in emailing. Luckily, the sendMessage function accepts HTML without any complication. Add an HTML email template file to your working folder, complete the PHP wrapper with these missing lines:

            # 1. Reading the contents of the HTML email template
            $htmlContent = file_get_contents("htmlContent.html");

            # 2. Reference the HTML content in the array of the 
            #    sendMessage function's second parameter
                'html'    => $htmlContent

It may not bother you right now, but later you might want to add email attachments such as images or PDF documents as well. That can be done by adding a third parameter to the sendMessage function. This also has to be an array as the parameter before. As a result, you could reference multiple sources within that at the same time. The full example including the image attachments, HTML email template, seasoned with multiple recipients looks as follows:

        sendMessage(
            $domain,
            array(
                'from'    =>
                    'Developer ',
                'to'      =>
                    'Friendly User ',
                'subject' =>
                    'Hello Friendly User',
                'text'    =>
                    'Testing some Mailgun awesomeness with PHP!',
                'cc'      =>
                    'Developer2 ',
                'bcc'     =>
                    'Friendly User2 ',

                'html'    => $htmlContent
            ),
            array(
                'attachment' =>
                    array('./logo2yellow.jpg','./logo2yellow.jpg'
            )
        ));

        ?>

You may also be interested in seeing the example of email HTML code as well:




  
    Sending Email with Mailgun API PHP Wrapper
	
    
  
  


    
      
        
          
            
              
                
                  
                    
                      
                        
                      
                    
                  
                  
                    
                      
							Mailgun Test Email with PHP

							This is some memorable HTML you could send with Mailgun in the blink of an eye.
							


							Note the attachments as well.
                      
                    
                  
                  
                    
                      
                        2017 @ COPYRIGHT - EDMDESIGNER

The heavy use of tables in the HTML is the result of email design best practice.
There are many though spots in coding HTML emails.

And delivered to the inbox:

There are plenty of other parameters you could use. The full list is available following this link.

Sending Email Templates Using Sendgrid

While Mailgun was an easy to use mass email-sending service, Sendgrid is a little more compound, as it offers an HTML builder and several out-of-box integrations for popular CMS solutions. For this reason, it takes a little more time to find our ways around in the documentation, but otherwise, it's still easy to set up mailing with Sendgrid.

The process is very similar as before. You signup to obtain an API key, then use that key to leverage the API functionalities according to your needs. That's followed by the 3-step process of PHP wrapper creation: autoloader.php include, client instantiation and client calls.

This looks as follows with Sendgrid:

1, On first login you'll be directed to the setup guide. Select "Integrate using our Web API or SMTP relay" option by clicking "Start".

2, On the next page as recommended, select the Web API option and on the screen after that your desired programming language - make sure that it's PHP!

Let's look at the code that delivers our message:

    client->mail()->send()->post($mail);

        echo $response->statusCode();
        print_r($response->headers());
        echo $response->body();
    ?>

If you look at the example, you can spot that this time we want to access all information about the HTTP response from the API. That's very good for practice because you can debug failing delivery more easily. For example, if you omit a variable from the mail() method, the statusCode()'s return value 400 may not give you much help, but the request header and request body will tell a lot about the issue.

HTML and Image Attachment with PHP Sendgrid API Wrapper

Adding attachments requires the Sengrid $attachment object. There are five required parameters in the process: the arbitrary content Id, the base64 encoded image content, the file type, the include method and you can customize the file name. These are set with the call to the appropriate "setter" functions:

       // Setting the ID of the attachment
       $attachment = new SendGrid\Attachment();
       $attachment->setContentId("myId");

When you provided all 5 properties, you need to call the addAttachment method of the $mail helper class. As I mentioned before I always want to test if I can use HTML to my emails. Fortunately, it can be applied without any difficulty. We just need to provide it to the Content class:

        $htmlContent = file_get_contents("htmlContent.html");
        $content = new SendGrid\Content("text/html", $htmlContent);

The full example code looks as follows:

    setContent($file_encoded);
        $attachment->setContentId("myId");
        $attachment->setType("image/jpg");
        $attachment->setDisposition("attachment");
        $attachment->setFilename("logo2yellow.jpg");

        $mail = new SendGrid\Mail($from, $subject, $to, $content);
        $mail->addAttachment($attachment);

        $apiKey = getenv('SENDGRID_API_KEY');

        $sg = new \SendGrid($apiKey);

        $response = $sg->client->mail()->send()->post($mail);

        echo $response->statusCode();
        print_r($response->headers());
        echo $response->body();
    ?>

I hope the steps were easy to follow. If you have any questions don't hesitate to ask them in the comment section, below the article.

Sending Email Templates Using Amazon SES

Our last candidate is a product of the biggest cloud infrastructure provider in the world. Amazon SES stands for Amazon Simple Email Service. It's a cloud-hosted email delivery platform with a pay-per-use price-model. This makes it a scalable and affordable service for multiple uses. As with other Amazon services, there's a free tier provided for developers' testing purposes. We'll take advantage of that right now!

Sending Email Templates Using the AWS SDK

An Amazon registration is slightly different from the previously showcased email APIs, as you must provide credit card information and billing address as part of the sign-up process.

After registration there's an additional step you need to complete to be able to send test emails: you need to verify the email addresses you'll use for sending and receiving. Otherwise, you'll receive such errors:

      The email was not sent. Error message: 
      Email address is not verified. The following 
      identities failed the check in region US-WEST-2:

You can do this verification on the Amazon SES dashboard. That's a minor added complication compared to Mailgun or Sendgrid.

To obtain the API key and corresponding API secret follow these steps in the dashboard:

Click Your name in the navigation drop-down
Select "My security credentials" option
Click "Continue to Security Credentials" in the pop-up modal
From the accordion menus select "Access Keys"
Hit "Create New Access Key"
Then either click "Show Access Key" to activate the drop-down or "Download Key File" (that's better if you include it with environment variables)

Next, you'll need the following code:

    ");
        define('SUBJECT','Amazon SES test (AWS SDK for PHP)');

        // Replace sender@example.com with your "From" address.
        // This address must be verified with Amazon SES.
        define('SENDER', 'developer@edmdesigner.com');

        // Replace recipient@example.com with a "To" address. If your account
        // is still in the sandbox, this address must be verified.
        define('RECIPIENT', 'friendly.user@company.com');

        // Include the AWS Region you're using for Amazon SES.
        define('REGION','us-west-2');

        define('CHARSET','UTF-8');

        // Instantiate SesClient class
        $client = SesClient::factory(array(
            'version'=> 'latest',
            'region' => REGION
        ));

        // Send email with the defined named constants
        try {
            $result = $client->sendEmail([
            'Destination' => [
                'ToAddresses' => [
                    RECIPIENT,
                ],
            ],
            'Message' => [
                'Body' => [
                    'Html' => [
                        'Charset' => CHARSET,
                        'Data' => HTMLBODY,
                    ],
                    'Text' => [
                        'Charset' => CHARSET,
                        'Data' => TEXTBODY,
                    ],
                ],
                'Subject' => [
                    'Charset' => CHARSET,
                    'Data' => SUBJECT,
                ],
            ],
            'Source' => SENDER
        ]);

            $messageId = $result->get('MessageId');
            echo("Email sent! Message ID: $messageId"."\n");

        } catch (SesException $error) {
            echo("The email was not sent. Error message: "
                .
            $error->getAwsErrorMessage()."\n");
        }

    ?>

Let's see step-by-step what this piece of code contains:

First you require the Autoloader to be able to access the AWS SDK classes. We'll need the SesClient and SesException classes, so we refer them to the use operator
Next, provide the variables for the sendEmail function with named variables using the define method
Last we instantiate the SesClient class into a $client variable and in a "try-catch block" we call the sendEmail function of SesClient and print a success message or the error based on the delivery result

I bet you feel excited now. You head to the console to run the script: php .php and you receive: Error message: Email address is not verified. That's what I mentioned previously. Without verified addresses, you can't deliver emails, not even in sandbox mode. So, let's fix it.

Navigate to the Amazos SES dashboard:

and once it loaded go to "Email Addresses" under "Identity Management". You can add the email addresses you want to use there. When you retry you'll receive a success message and as the retrieval of the MessageId was set in the code, you'll also receive this Id that you can use to track your message delivery in the dashboard.

      Email sent! Message ID: 
      01010160fe95d93d-b7bc4b30-ebdf-4380-b2cf-b21771....

That's it! You sent your first email using Amazon SES and PHP. If you didn't receive it, this guide can cast light on what could have gone wrong.

In the next section, I'll show you how to use some features of the API.

https://docs.aws.amazon.com/ses/latest/DeveloperGuide/create-shared-credentials-file.html

Amazon SES API For Sending HTML Email Templates

We've seen how to send an HTML email template using Amazon SES with the file given at a certain location in your file-system. If you implement the PHP wrapper on a server that's all well and good or if you send it from your local machine. But wouldn't it be better if you could use templates stored in your Amazon SES account?

It certainly makes sense, and as it's just a few additional lines of code, I'll show you how to do it programmatically. You can fully re-use the code from the previous section.

We are going to use the necessary fields and methods of the Amazon SES API. Learning about these will enable you to create more complex code examples.

The first thing to do is to create a configuration set. On the client let's call the createConfigurationSet method as follows:

        $client->createConfigurationSet([
            'ConfigurationSet' => [ // REQUIRED
                'Name' => 'FirstSet', // REQUIRED
            ],
        ]);

Creating a template works similarly, we just switch the method and the supplied parameters:

        $client->createTemplate([
            'Template' => [ // REQUIRED
            'HtmlPart' => $htmlContent,
            'SubjectPart' => 'Subject of first awesomeness',
            'TemplateName' => 'Templating-101', // REQUIRED
            'TextPart' => 'This is just text']
        ]);

As you can see above, I supplement the HTML for the template as before by assigning the variable containing the HTML to the corresponding property.

If you insert these two pieces of code into the previously shown PHP wrapper and run the script, your AWS SES account will be enriched with your brand new template:

As the next step, we need to move these bits of code into a separate file or comment it out, as we don't want to make duplicates of the configuration settings and the template (actually we can't with the same names): The email was not sent. Error message: Configuration set already exists.

So the template is created, unnecessary code taken out, we just need to reference the created template:

    $result = $client->sendTemplatedEmail([
        'ConfigurationSetName' => 'FirstSet',
        'Destination' => [ // REQUIRED
            'ToAddresses' => ['friendlyUser1@company.com',
             'friendlyUser2@company.com']
        ],
        'Source' => 'developer@edmdesinger.com', // REQUIRED
        'Tags' => [
            [
                'Name' => 'Name', // REQUIRED
                'Value' => 'Value', // REQUIRED
            ],
        ],
        'Template' => 'Templating-101', // REQUIRED
        'TemplateData' => 'jsonValues for template', // REQUIRED
    ]);

If you included it correctly, your message will be delivered to the recipients without any problems. Note, that sendEmail method is replaced bysendTemplatedEmail to allow the use of the template from the Amazon account. Once you're done testing and ready to move to production, you can request a sending limit increase and move your account out of the limited sandbox environment.

If you're really serious about getting to know Amazon SES check out the video tutorials and the documentation.

Summary

There are an endless number of services for bulk sending emails using PHP. We saw the most well-known ones Mailgun, Sendgrid and Amazon SES.

We gained hands-on experience in their basic setup and explored some commonly used features to learn about their API. We saw how to attach an image file to the email through the examples of Mailgun and Sendgrid APIs and looked at how to provide previously built HTML email templates within the message body. Last but not least, we tried the programmatic process of creating and referencing email templates with Amazon SES API.

I hope you could learn the basics and feel confident enough to give email APIs a try. If you have additional resources or code examples that fellow coders could make use of or inspiring thoughts about email APIs, please share them in the comment section below.

If you liked this article, you may like the others to come. Subscribe to our newsletter to get them delivered to your inbox.

A Step-by-Step Guide to Sending HTML Email Templates Using PHP

Mihály Sáróy — Wed, 10 Jan 2018 12:42:58 GMT

Most developers who started off their programming careers before 2010 and had an interest in web development, most-likely encountered PHP as their first server-side scripting language. PHP was very, very popular back then. The easiest way to start a blog or a website was through content management systems (CMS) running on PHP, like Wordpress or Joomla, which boosted popularity even more. The language is still popular with great impact and a lot of options for different applications.

As the technology is used widely and many developers at email marketing agencies around the world understand the language well, we had the idea to gather as much information about sending email templates with PHP code as possible.

Our goal at EDMdesigner.com is to make eye-catching, bulletproof HTML email templates available for everyone. The EDMdesigner blog supports this mission by helping fellow developers get more educated in the field of email development.

By reading through this guide, you'll learn about how to write PHP code to send transactional and HTML emails. There are built-in methods, PHP extension packages, and we'll cover email delivery services integrable in PHP code in an upcoming article. They differ in flexibility and additional features. Learning about these options open the door to quick HTML email design testing capabilities during development. Reading this article will help you gain an understanding of the considerations when selecting the service suitable to your needs.

Installing PHP

The first step of bootstrapping any PHP code run project is to install PHP. That starts with fetching the necessary download bundle. Since our goal is to run PHP scripts and send transactional and HTML email templates, it's sufficient to have PHP installed on our system and, we don't need to additionally configure a server. For developers using Linux distributions the quickest setup may be executed by running the following in the terminal:


sudo add-apt-repository ppa:ondrej/php
sudo apt-get update
sudo apt-get install php7.0-cli // or other desired PHP version

You can read the detailed installation steps on the Launchpad web page.

After the successful completion of this process, you can test if everything works correctly with a simple script:

Place the above code in a test.php file, navigate to the folder where you created the file in the command line and run php ./test.php. This amazing script will print your message to the console. Well done!

Sending Email with Built-In Mail Function

The most basic way to send an email using PHP is the built-in mail() method. The only compulsory parts are the $to, $subject, $email_body variables. If you omit any of them you'll see the following sad little error log: PHP Warning: mail() expects at least 3 parameters, 2 given ..., warning you about your mistake. The least complex implementation of the function would look like this:

Let's see what happens, when we run the script! In the tutorial, we think in steps, so I go with running php step-00.php.

The most likely output is the following error: sh: 1: /usr/sbin/sendmail: not found. Now, this is a pity. As part of the installation, to be able to actually send test emails, we need to install the Sendmail Mail Transport Agent (MTA) as a locally accessible mail server. If you type sendmail in the terminal, you'll be notified about the packages that contain this library:

When proceeding with sudo apt install sendmail a lot of updates happen.

Now you can proceed with configuring the default sender's values in the php.ini file. The php.ini file is the place to store runtime variables for PHP and this file includes the SMTP setup, which tells your script about your local web server's configuration.

[mail function]
; For Win32 only.
; http://php.net/smtp
SMTP = localhost
; http://php.net/smtp-port
smtp_port = 25

; For Win32 only.
; http://php.net/sendmail-from
;sendmail_from = me@example.com

; For Unix only.  You may supply arguments as well (default: "sendmail -t -i").
; http://php.net/sendmail-path
;sendmail_path = "/usr/sbin/sendmail -t -i -f info@edmdesigner.com

If you use Unix-based systems, like Linux, you need to uncomment the sendmail_path variable by removing the semicolon from the beginning of the line, so PHP finds your sendmail location. When all the above is done, naturally we try running php step-00.php again. Miraculously the script runs and our first PHP-sent mail arrives. Congrats!

Later we'll see, that we can also choose our email service provider as the mail server and provide the SMTP setup in the script, for example, Gmail's email server.

This is all well and good, however, that's not all the mail() function can do. You can also:

send complex HTML email templates
set additional email headers, like (content type, character set)
provide multiple addresses with comma separated lists
add attachments to the emails by formatting the message conform to the Multipurpose Internet Mail Extensions (MIME) standard

Following this you may ask 'If I can send rich HTML content with the mail() function, why should I learn about additional ways to send emails?'.

The answer can be found in the user comment section of the PHP docs:

it's not efficient to bulk-send emails to email lists as the function opens and closes an SMTP socket for each email
you can only use 70 character long strings, you need to separate the excess with "\r\n" line-breaks.
you can't set up SMTP access to external mail servers

In the end, let’s see the updates to be made that enables sending any HTML email template.

They contain:

setting up additional headers telling that we created an HTML email, which compliant with the MIME standard
reading the contents of an HTML file (though we could also insert it in the PHP script directly)
providing the $headers to the mail function

$headers = "MIME-Version: 1.0" . "\n";
$headers .= "Content-type:text/html;charset=UTF-8" . "\n";

$htmlContent = file_get_contents("email_template.html");

// send email HTML
mail($to, $subject, $htmlContent, $headers);

If you assign the HTML directly to the $htmlContent variable in the script, it's important to avoid mixing single and double quotes. Otherwise, you'll be notified of a parse error of the mistake: PHP Parse error: syntax error, unexpected ' ...unrecognized string... ' (T_STRING) in ...PHP file location...

I also consider mail attachments an important topic but beyond the reach of this article, the following discussion may help to shed light on how to do it properly.

Sending HTML Emails with External PHP Packages

In the previous section, I mentioned that it’s not efficient to send emails with the PHP mail() function, considering multiple recipients as the function opens and closes an SMTP socket for each email sent. There are external PHP packages that handle these much better. These PHP scripts enable email sending with option for SMTP configuration of services like Gmail or Yahoo! Mail or other email service providers.

Most blog and community discussions on the web mention the PEAR Mail and the PHP Mailer packages as the default go-to in these situations, so I introduce these as well.

PEAR Mail Package

PHP Extension and Application Repository (PEAR) is a framework and distribution system for reusable PHP code components. The most important email sending script within PEAR is the Mail package. Based on the installed PHP version, you may already have PEAR available. You can check it running pear with no arguments in the command line. If you followed the installation steps recommended in the first section, the command will return:
The program 'pear' is currently not installed. You can install it by typing: sudo apt install php-pear warning. That's totally fine and exactly what we need to do.

Once that's done, we can start adding pear packages: we will need sudo pear install Mail and sudo pear install Net_SMTP for sending emails through email delivery services. You can find the PEAR Mail packages documentation here.

First, we reference the necessary PEAR component in our .php file:

        require_once "Mail.php";

Next include the SMTP settings for the email delivery service in variables, with Gmail it looks as follows:

        $host = "ssl://smtp.gmail.com";
        $username = 'username';
        $password = 'password';
        $port = "465";
        $to = "saroy.mihaly@gmail.com";

Please note, that the $host variable also holds the security protocol. Here, the username and password are supposed to be your actual Gmail account's username and password. If you use your script on the web, for security reasons, you would store these credentials in environment variables and include them programmatically in the script. PHP dotenv is a popular package to help with this.

You need to disable 2-step verification for the SMTP authentication to work in Gmail.

The second part of our code is to provide the parameters to the email header and the variables for SMTP authentication to the mail function. With PEAR Mail package it looks as follows:

        $headers = array ('From' => $email_from, 
            'To' => $to, 'Subject' => $email_subject, 
            'Reply-To' => $email_address);
        $smtp = Mail::factory('smtp', array ('host' => $host, 
            'port' => $port, 'auth' => true, 
            'username' => $username, 'password' => $password));
        $mail = $smtp->send($to, $headers, 
            $email_body);

If you examine it closely, that's where this external PHP package outperforms the original PHP mail() method besides that it enables SMTP: there you could only work with string variables, here you can use arrays for setting the $headers and the various parameters.

Here you can see the full example:

         $email_from,
                            'To' => $to,
                            'Subject' => $email_subject,
                            'Reply-To' => $email_address,
                            'MIME-Version' => $mime,
                            'Content-type' => $content);

            $params = array  ('host' => $host,
                            'port' => $port,
                            'auth' => true,
                            'username' => $username,
                            'password' => $password);

            $smtp = Mail::factory ('smtp', $params);
            $mail = $smtp->send($to, $headers, $email_body);

            if (PEAR::isError($mail)) {
            echo("" . $mail->getMessage() . "");
            } else {
            echo("Message sent successfully!");
            }
        ?>

Moving on, next we'll see an even more robust implementation of PHP mailing with the compound PHP Mailer framework.

PHP Mailer Package

The contributors of this PHP mailer class say it’s the most popular code for email sending and let’s be honest: the almost 5 million downloads seem to support this statement quite well. It has detailed documentation on the available methods and a few examples to help you get started.

The Mailer package may be downloaded or cloned from Github and the script set up manually in projects, or if you prefer to be neat, use the PHP dependency manager - Composer.

Getting Started with Composer

Composer is very similar to the Node Package Manager in the JavaScript world: you can install and maintain project dependencies in a simple and controlled way from a central registry. They both provide a huge library of public packages.

Composer uses Packagist as the main repository for these packages and the composer.json file put at the root of your project's repository instructs Composer. You can install it with curl -sS https://getcomposer.org/installer | php. To use Composer you need PHP 5.3.2+. After this command finished running, you can add PHP Mailer package to a composer.json file. The simplest way of doing so, if you add the packages by Composer's bootstrap process: composer init.

You'll be asked a series of questions during the setup guide, one of which will be to select the dependencies:

If you completed the setup guide as above, you can check if the package name and the current default version is added to the composer.json file: "phpmailer/phpmailer": "~6.0".

Now you only need to install the added project dependencies (in this case just PHP Mailer) with composer install. It'll add a vendor/ folder supplied with vendor/autoload.php script generated by Composer and the required dependencies.

Using the PHP Mailer Package

As we use Composer and have vendor/autoload.php out-of-the-box, it is much simpler to include the external library in our project:

      require "vendor/autoload.php";
      use PHPMailer\PHPMailer\PHPMailer;
      $mail = new PHPMailer;

and we are good to go.

On the PHP Mailer's $mail object, we set the properties used for sending mails: $mail->From = "from@domain.com";. There are helper methods in the process: addAddress addReplyTo, etc.

If you wish to send HTML email, and you'd probably want to, then set $mail->isHTML(true).

Sending along any attachment - such as an image - is really easy using the PHP Mailer script. You only need to call the mail object's addAttachment() method passing the file location to the argument as a string value. That's very different from the pain of having to configure MIME header boundaries, like using PEAR or the mail() function

Once you provided all the necessary properties, you can send the email with $mail->send().

Summary

In this tutorial, you could learn about the most commonly used options to send out plain text and HTML email templates with PHP. We started the post with the PHP mail function and settings for the local PHP environment.

We continued exploring PHP code based mailer packages and gained knowledge about the PHP package and dependency management system with Composer. We saw the example of Gmail on how to configure an SMTP mail server with these mailer packages.

This article focused on the possibilities strictly derived from the PHP ecosystem. Though we can send complex HTML emails to multiple recipients now, we can achieve a lot more through specific email delivery services. For this reason, we continue the topic with email delivery API services using PHP.

Thanks for your attention this time. Stay tuned.

How to Use a Templating Language in HTML Email Development

Gyula Németh — Wed, 13 Dec 2017 09:29:32 GMT

Throughout this article series, we have discussed many tools and methods that can help you to create maintainable email code. The most important concept is modularity. If you can decompose your monolith code, you already made a huge step.

A really good abstraction is when you think in components. If your component is general enough, does not include many hacks and you can use them as building blocks, then you are good to go.

Today, we are going to discuss some tools and technologies which will be your best friends in component-based email development.

Templating Languages

Most of you might have heard about templating languages and I guess many of you might have used them.

The typical usage is when you render something on the server side. The usual use-case is when you have to add dynamic content to your website, so when you fetch something from your database, you will have to replace some parts in your original template.

Besides that, you have basic control-flow in templating languages, for example, if branches and loops. These can help you to create a conditional rendering and to use the same sub-template multiple times. (Just think about a shopping cart, where you have to render multiple products. Their template can be the same, while the substituted data has to be different.)

The most popular templating languages that I know of and used are EJS, Handlebars, and Jade.

It's worth to mention, that in ES6 (the new standard for Javascript) there is a neat new feature called template strings. As you might have guessed, you can do the same trick with them as with templating languages. But which shall you use then? Don't worry, I will compare the two and talk about the pros and cons a little bit later.

Comparing Templating Languages and ES6 Template Strings

In this section, I am going to show you a short and easy to understand example implemented in EJS and with ES6 template strings.

I chose EJS because I have the most experience with that templating language. Also, it just adds to the original HTML syntax, so it's much more straightforward to me than Jade.

The example which I will show you is super simple. The page which we render will have a title and a list of products with prices. Each item will have different background-color, so we can easily navigate between the lines. It will look like this:

As you can see, it's super-simple. I am going to show you some complex examples with real email HTML, but for now, I want to keep things simple so everybody can have a solid basis before we plunge into the nasty email code.

The JSON data with which we feed the template to render our page is:

{
  "title": "My Email HTML Products",
  "products": [
    {
      "name": "Responsive Email Template",
      "price": 500
    },
    {
      "name": "Email Template Builder",
      "price": 2000
    },
    {
      "name": "HTML Generator",
      "price": 5000
    },
    {
      "name": "Drop Calc Generator",
      "price": 10000
    }
  ]
}

The EJS implementation looks like this:


    
        
    
    
        <%= title %>

        
            <% for(let idx = 0; idx < products.length; idx +=1) { %>
                <% if(idx % 2 === 0) { %>
                
                <% } else { %>
                
                <% } %>
                    <%= products[idx].name %>
                    $<%= products[idx].price %>
                
            <% } %>

The same in Javascript with template strings:

function renderTemplate(data) {
    return `
    
    
        
    
    
        ${data.title}
    
        
            ${
                data.products.map((item, idx) => {
                    const className = idx % 2 === 0 ? "even" : "odd";
                    return `
                        
                            ${item.name}
                            $${item.price}
                        
                    `;
                }).join("")
            }
        
    
    
    `;
}

Templating languages are great. Many people are most probably familiar with them already, so applying them to email development should not be a problem. Many of them are very well supported so you can enjoy syntax highlighting and many other neat features in text editors.

If you want to use templating languages (for example EJS), you have to use external libraries. To be honest, it can be a nightmare to debug these libraries. They hide many things from the developer. It's even impossible to use breakpoints, so you have to print every debug info to the output or the console if you want to debug something.

On the contrary, Javascript template strings are very, very easy to debug, because it's pure Javascript. You can use breakpoints and every other tool which you use for JS debugging.

You don't need dependencies because template strings is a built-in feature in modern Javascript.

My final argument is that template strings force you to use functional Javascript, for example, map, filter and reduce. If you master these features, you will be much, much more effective. You will write code faster and others who are familiar with these operations will understand your code in seconds.

Some people will not agree with me, but I think using Javascript's template strings is the way to go. What do you think about it?

Modularity with Javascript Template Strings

The previous example is obviously a monolith. Not a big one, but still... If you want to decompose it, you have to identify those parts which are logically separate from the other parts of the program.

If you want to define components properly, then they have to be context-free, which means, that these components must not depend on their parent's properties. In other words, it means that they will look the same no matter where you put them.

In our example above, we can define one component for the list items, one for the list itself and the main component, which includes the whole template.

After the decomposition, our product-list-item looks like this:

module.exports = function productListItem(item) {
    return `
        
            ${item.name}
            $${item.price}
        
    `;
};

The product-list looks like this:

const productListItem = require("./product-list-item");

module.exports = function productList(products) {
    return products.map((item, idx) => {
        const className = idx % 2 === 0 ? "even" : "odd";

        return productListItem({
            className: className,
            name: item.name,
            price: item.price
        });
    }).join("");
};

And the main function is the following:

function renderTemplate(data) {
    return `
    
    
        
    
    
        ${data.title}
    
        
            ${productList(data.products)}
        
    
    
    `;
}

You can download the tutorial's full coding examples on Github

The example above is super simple, but it shows the basic concepts of decomposing a huge HTML template into smaller independent chunks. This is a great way to create reusable code.

Defining a Component System for Email Development

Following the methodology above, you can define the most basic components for HTML emails. Later, you can define complex ones based on the basic components.

The basic elements fall into two main categories: layout and content elements. The layout elements can have children whereas the content elements are usually terminal nodes, meaning they don't have any children, but they hold the information of the email itself.

Layout Elements

Layout elements can be called as container elements as well since they contain other elements. They can contain other containers and content elements as well. This way they define the document tree.

There are three main layout elements:

Centered containers: their main property is their width (which is usually 600px in HTML emails.
Multi-columns: you can put multiple columns next to each other.
Sections: They are simple containers to divide different parts of the document, for example, header, content, and footer. They can be used in other containers as well. If you define their background colors, you can emphasize the difference between such areas in your email.

With these three layout elements, you can create any kind of email layout with ease.

The usage of multi-columns is obvious, but let me explain something about sections and centered containers. You can combine them in two ways.

You can put sections into centered containers, where your sections will be the header, content, and footer. This is a very traditional way, the colored backgrounds of the sections will be 600px wide as their parent container is.

The other way you can combine them is when you put a centered container into a section. This way the sections background color will spread across the screen. You can put multiple stripes under each other (each stripe contains a section and a centered container within the section), and you will get a nice modern-looking email template.

Content Elements

These kinds of elements contain the content itself. They can be text elements, image elements, and buttons. I think most of the functionality related to them is obvious, but let me go into a little bit more detail about the text element.

In this categorization, text elements can contain some markup as well. For example header elements (

, etc), list elements (

), and markdown which emphasizes some parts of the text (, , etc).

You could create separate element types for the ones above, but in many cases, you'd create this part of your template with a WYSIWYG editor so you can use the output of that editor directly as the value of the text element. But if you feel like, you can define your own basic heading and list components. (I'm sure that you don't want to define separate components for bold, italic, etc since then you'd have to define text-node as well.)

The Benefit of Redefining Such Basic Elements

The best thing in a component system is that it's declarative. It means that you have to write down what you want to do, not how you want to do it.

Effectively, you don't have to deal with the implementation. Or you can even configure which implementation you want to use. For example you can generate a div or a table based email, depending on the email clients you have to support.

This kind of abstraction also helps you to separate the data from the visualization. Again, the HTML is hidden inside the implementation of the components. You just have to feed them with proper data, which is usually a JSON document.

Even though your document descriptor is a JSON, you can also define a markup language, which automatically translates to JSON. It means that instead of a JSON similar to this:

{ ... "body": [ { "type": "container", "children": [ { "type": "section", "children": [ { "type": "text", "tag": "p", "value": "Header" }, { "type": "text", "tag": "p", "value": "Content" } { "type": "text", "tag": "p", "value": "Footer" } ] } ] } ] ... }

you can write a much simpler markup, like this:

Header Content Footer

If you want to write the code yourself, then you probably want to choose the latter, but if you need to do things programmatically, then the former might be more suitable for you.

You might have noticed that I used an tag in my second example. It stands for Email Markup Language, which I'm working on at the moment. I am very excited about it, it will contain tons of useful features for those who have to deal with HTML emails.

Complex Components

Based on the basic elements, you can define complex components. You can simply compose them to build up a complex one.

Just think about a hero unit component, which consists of an image, a title (which is a text element), a description (which is also a text element) and a call-to-action button.

Another example could be a product-list-item or a product-list, just as you saw in my very simple example.

Besides composing the atomic elements we already defined, you can create components with non-default functionality. Just think about interactive emails. There are multiple components, which can't be composed of our basic elements (for example a carousel, a tabbed pane or even prefilled forms).

Summary

In this article, you have learned about how to create reusable components for HTML emails with templating languages and Javascript template strings.

You also saw how to define a basic component system, which can be used as building blocks to create complex components.

This component system can be used to define a markup language to create responsive HTML emails. This is what I am secretly working on, so stay tuned, it will be released in the upcoming months.

CSS Inliner Tools Worth Considering for Your Next Email

Mihály Sáróy — Wed, 29 Nov 2017 14:52:09 GMT

There are three big "Ouch" moments for beginner email coders that you've probably got yourself over already (if not, check out the fundamental differences between web HTML and email HTML): external resources are mostly banned from email templates, you need to use tables for everything and last but not least - you have to inline your CSS styles. In this article, we'll be concerned with the why&how of the last piece.

You may also very well know that the must of CSS inlining has changed a lot since Gmail started to support the

Email coding is the best

....

Show me a button!

2017 @ COPYRIGHT - EDMDESIGNER

There are a few things about this tool, I should mention:

it preserves the media query in the style tag - you'll see that not all tool does so

inlines well the width properties of the layout classes col67, col33

adds tag to complete the table markup

it removes unknown CSS classes, like ExternalClass declaration

Examining the Litmus previews we can determine that the correct fluid layout is applied in most mobile email clients, while the desktop view shows on desktop and webmail clients. The tool doesn't offer any configuration to customize the inlining process, but I'm pretty satisfied with the results. There are two negative aspects I run into using the tool: 1, you can only use it to inline CSS from external stylesheet 2, it uses a tabulation that makes the template harder to modify after inlining. All-in-all I can recommend it whole-heartedly.

Setting Up an Automation Tool

When I wanted to test the various tools for the inlining process, soon it turned out that the only effective approach is if I gather and run them together via a scripting language. Though any solution would work, there are special tools, so-called task runners, that facilitate this job. This way I just need to modify the HTML, CSS and the CSS inliner tools' configurations, other parts of the procedure are handled for me.

Task runners are tools to make regularly occurring tasks automated. The usual setup is based on a configuration file, specific for the task runner that holds all the defined tasks to carry out on a simple command.

Our choice, Gulp, is a frequently used, performant JavaScript task runner, and under a simple default command, we'll set up all the different CSS inliner tools' run commands. The installation is quite the same as you've seen in the section about Inlining.

We'll zoom-in on task automation in an upcoming article creating an automated email development framework. On the other hand, it seems useful to warm you up a bit and introduce one popular JavaScript task runner for the sake of this post anyway. Let's Gulp!

You can download and inspect my recommended project setup from Github, but I'll quickly sum up how it works. If you see any way to improve that, I also welcome comments about it.

In our project will have:

An input.html that contains the email template markup and either a tag to the main.css containing the styles for the template, or the styles embedded into the
It's time to see what we've achieved:

](http://textversionjs.com/)

You can pass a configuration object for the tool with 7 configuration properties:

var styleConfig = { linkProcess : null, imgProcess : null, headingStyle : "underline"; // hashify, breaklink listStyle : "indention"; // indention uIndentionChar : "-", listIndentionTabs : 3 }

To sum up, you can set the indentation, link and image output format and heading styles. The linkProcess and imgProcess properties are special because they'll apply any custom implementation you provide.

There are a few highlights about usability:

It has no dependency, so you can use it safely and consistently

On the client-side, if you use custom strings you need to replace them before you could send the email

While you can convert the final HTML to text-version on the server-side, no additional steps required

I encourage you to check out how it works and give it a try now on the project's demo page and check out the full source code of the tool.

Crop Lines with BulletproofLineLenght

The next tool takes good care of long lines as most email clients have troubles displaying them. Many characters in a single line can break the layout easily. To prevent this from happening, we can use the BulletproofLineLenght tool and set up the line lengths to an arbitrary value.

In this section, we are going to use the tool on the server-side in the example, but you can access it online too.

The project's working folder contains a test tool, where you can try out quickly how this code modification works. We are going to use that for the server-side example, with the only difference of including the project's working files via NPM. The steps are the following:

1, Open a project folder:

The necessary commands are:

mkdir cd npm init npm install bulletprooflinelength --save

After npm init you are prompted several questions about the project, completing them you'll have the package.json file created. If you need a deeper understanding about getting started with NPM, you can check our previous tutorial on scripting or the NPM documentation.

2, Install BulletproofLineLength:

npm install bulletprooflinelength --save

With this command, a node_modules directory gets added to your working files.

3, Using the tool in projects:

As mentioned before we already have an exemplary use of the tool among our working files, and the project's documentation shows clearly how we can include it in our JavaScript files. So the modified code is:

// FROM THE DOCUMENTATION // Including from node_modules var bulletproofLineLength = require("bulletproofLineLength"); // FROM PROJECT'S TESTING TOOL // Requiring necessary Node packages var fs = require("fs"); var path = require("path"); var stringWithLongLines; var maximalLineLength = 50; // Parsing command line arguments var pathToFile = path.join(__dirname, process.argv[2]); var parsedPath = path.parse(pathToFile); stringWithLongLines = fs.readFileSync(pathToFile, "utf8"); var stringWithShortLines = bulletproofLineLength(stringWithLongLines, maximalLineLength); // Writing line-split HTML to file fs.writeFileSync(path.join(__dirname, "./results/", parsedPath.name + "-splitted" + parsedPath.ext), stringWithShortLines);

and that's it. We have BulletproofLineLength set up in our project, able to read HTML files and output line-split version of it into a separate file. It could be an end-task of an automated workflow.

It's time to spare some word about how the tool works and what restrictions or opportunities it has:

the tool accepts any input format, but only HTML and CSS lines are processed, otherwise, the original line is returned

the splitting of lines are set up based on typical separator characters of the language: <, >, ", ' in HTML and ;, ,, } in CSS. That means that long inline style declarations are not split in the HTML.

I encourage you to check out how it works and give it a try now on the project's demo page and check out the full source code of the tool.

Lists in Emails with Bulletprooflist

This third project was introduced years ago in our email HTML generator. A recent update in it made us realize that it can be helpful for fellow email coders. The tool is responsible for making unordered and ordered lists bulletproof.

In this section, our main focus will be on the generated output, namely what makes a list bulletproof in email clients.

There's a necessary addition in order to make the tool work in the browser: we need to bundle our server-side dependency, the Cheerio package with Browserify or a similar bundler. Bundlers let us implement external modules easily. with this out of the way, let's jump in the middle:

After copy & paste and generate we have a bulletproof list available for comparison with the original one:

Before

```

First Item

Second Item

Third Item

```

After

```

• First Item

• Second Item

• Third Item

You see in the above tables that the `ul` tags are converted to `table`s (just as `ol`s would) and each `li`s are replaced with a `tr` element with 2 cells. The first `td` holds the bullet point and handles the spacing with the `width` value. The second cell contains the text content of the list item. They each inherit an `align="left"` and a `font-size` property. Now the most important step is to check the results of visual tests. First, let's check what happens when we apply no style on our lists but have `margin` and `padding` reset as part of the necessary reset step of email development workflows. We can see that bullet points are not aligned correctly to their containers in regular lists, but they work correctly when used with the bulletproof method with tables:

Before After

![Original email preview of HTML list](/content/images/2017/10/appmail9-vertical-allowed-1366.png) ![Email preview of HTML list with Bulletproof code](/content/images/2017/10/appmail9-vertical-allowed-1366-bulletproof.png)

I only included Apple Mail's preview as it is the most modern client, but the same behavior was true for every other email client. We continue by adding the following snippet to the code, which will make regular lists to align correctly:
tr, td, ul, ol, li { margin: 10px; padding: 10px; }

We can open up the previews of the [original](https://litmus.com/checklist/emails/public/afe03b5) and the [bulletproof](https://litmus.com/checklist/emails/public/3e5e763) HTML to examine the difference. As you can see in the images below, list items aren't aligned correctly (bullet points are not in line with the ordered list's numbers) in some of the clients, but are fixed with the bulletproof code: Original ![Outlook 2003 original email preview](/content/images/2017/10/ol2003-vertical-allowed-1366-original.png) Bulletproof ![Outlook 2003 bulletproof email preview](/content/images/2017/10/ol2003-vertical-allowed-1366-bulletproof.png) Original ![Yahoo! Mail original email preview](/content/images/2017/10/yahoo-vertical-allowed-1366-original.png) Bulletproof ![Yahoo! Mail bulletproof email preview](/content/images/2017/10/yahoo-vertical-allowed-1366-bulletproof.png) Last, but not least some additions to think of when you use the tool: - it increases the email size, which may increase the spam score, especially with long lists - you have little options for customization. You would need to modify the tool's code to receive different output I encourage you to check out how it works and give it a try now [on the project's demo page](https://edmdesigner.github.io/bulletprooflist/) and [check out the full source code of the tool](https://github.com/EDMdesigner/bulletprooflist) ## Summary By finishing this tutorial post you have learned all about our ready to use code modification tools. We saw what TextVersionJS, Bulletprooflist, BulletproofLineLenght are good for but the name quite said it all. **The key takeaways:** You can use tools for single-purpose use cases. Ours are available if you want to: - bookmark them: [1](http://textversionjs.com/) , [2](https://edmdesigner.github.io/bulletprooflinelength/) , [3](https://edmdesigner.github.io/bulletprooflist/) - download or clone them from Github: [1](https://github.com/EDMdesigner/textversionjs) , [2](https://github.com/EDMdesigner/bulletprooflinelength) , [3](https://github.com/EDMdesigner/bulletprooflist) - install via NPM: [1](https://www.npmjs.com/package/textversionjs) , [2](https://www.npmjs.com/package/bulletprooflinelength) , [3](https://www.npmjs.com/package/bulletprooflist) Let your projects benefit from open source tools. We also mentioned that with the whole new email generator engine we're building at EDMdesigner, we are likely to release similar open-source tools. Hope that the email developer community will find these tools useful. If you enjoyed this tutorial post and you do not want to miss the next one, please subscribe to our newsletter.

Managing Full-time Employees at a Growing SaaS Company

Gyula Németh — Wed, 04 Oct 2017 06:44:00 GMT

Since we announced the Modern HTML Email Tutorial on the 23rd of November last year, we published only tech-heavy articles every second week. This time it's going to be different.

This and the next article in this series are about how to manage people, how to motivate, and how to delegate in an efficient way that things will be predictable.

In the last five years, we have grown from an idea to a stable company of 15 people. There were times when only full-time employees worked at our company, and there were times when only I remained on the project full-time. At the moment, there are 5 full-time and 10 part-time people at the company.
These extremely different conditions mean that we had to change our management style and methods from time to time. We had to adapt to these circumstances to survive as a company.

You always have to seek out for new methods to manage the chaos around you. This is especially true when we are talking about the management of part-time employees. There is an extra management cost, but if you build your company with this in mind, then you can have a lot of very motivated people working together with you to build a great company.

In this article, I'm focusing on managing a small team consisting of full-time employees. In my next article, I'm focusing on managing part-time teams.

Since this story is about growing a company from 0 to 15 people, I mainly recommend it to SaaS startups who have not grown to this level yet. Secondly, I recommend it to people who are interested in employing more part-time people, but they find it difficult to manage them.

The Early Days

Like many other startups, we also started off in a garage. Not exactly a garage, because we worked at my apartment, but the principle is the same. We worked irregularly because all of us had other jobs. I was teaching programming at a university, which turned out later to be a very good source for talent. Since there were only a few of us, we did not really need any kind of project management. It worked perfectly, communication on this level (3 people) was very easy.

Every project at the beginning is not very well organized, but to be honest, it does not really matter. You don't really need strict management policies when you have one or two developers working on a project.

After we got our investment, we hired two full-time employees (one of them from the university I was teaching at). Maybe it does not seem to be a big difference, but managing a five-people company is totally different from managing a three-people company. There were three main things:

Losing focus: It often happened to us that we tried to solve everything at once and eventually very few of those things became reality.

Lack of information/miscommunication: If there are more and more people then it will be more and more often that for a subset of those people certain issues are crystal clear but not for others. It leads to situations when people think that the others are stupid. It's definitely something to avoid.

Planning ahead was very hard: As mentioned before, we often lost focus, but also, we did not really plan the details of features thoroughly, so it was really hard to estimate when certain milestones would be ready.

On top of these very serious issues, there were a lot of distractions in the office. It was very chaotic and I think the productivity was not even close to the level where it could have been.

We needed a formalized system, which solves those problems.

SCRUM for the Win

Our solution for the problems above was the SCRUM methodology, which is a set of practices bound together in a way that works very well for software development teams. I think you should not stick to a specific pre-defined set of rules strictly, but you have to pick those which work best for you.

There are many great articles about the SCRUM methodology, so I don't want to spend the time to describe the different parts. If you are not familiar with these concepts, I suggest you search for a good article about the SCRUM methodology. In this article, I will focus on what worked well and not so well for us.

It took us some time, but eventually, we could pick those parts from the SCRUM methodology which worked great for us. Actually, we were very strict with most of the things and everything just clicked.

I have to emphasize one thing here. We were a team of 5 full-time people. When you think about part-time employees, you have to radically change your mindset, but I will talk about that in the next article of this series.

Sprints

We tried one- and two-week long sprints. Both of them worked well for us, but in different situations. Shorter sprints are great if you want your team to focus for a short period of time, but you still want to add or remove things relatively quickly. I think you should not think about releasing new things faster than this. Longer sprints are better when we needed to develop a little bit bigger features. We tried even three-week long sprints, but that was just way too long.

We had our sprint reviews and sprint plannings on Wednesdays. The reason is simple. If it's in the middle of the week, then usually you can finish it faster, because people are in the flow. We have tried Mondays as well, but then everybody was scratching their heads to recall what happened and what should be done differently. Also, it took some time for people on Mondays to recall the details of some features that were very well planned already. It just took too much time. (You know, weekends sometimes erase your memory from the last week...)

Sprint reviews were great. We created retrospectives, action items for improvement and there were people responsible for those action-items. Although it was great for the team, I often felt that it takes too much time and sometimes we did not use it properly.

Sprint plannings were very useful. We estimated the business value and the story points of every user story and based on those we chose which ones to implement in that sprint. After that, we associated well-detailed tasks to the user stories.

To be honest, estimating the story points never worked really well. Sometimes it seemed like we are doing it well, but after a few sprints, we failed again to estimate well. I think it can have a few reasons:

Planning and estimating like this is just bad. I think it's much better to plan the tasks ahead of time and iterate over them for a while. In my experience, estimations will be much, much more precise that way. (After a while we started to create tasks during daily planning, not during the sprint planning. It also helped to keep sprint plannings less boring.)

Involved people did not risk enough. I think there was not enough motivation to estimate well and to finish the tasks. We never had a rule to stay there for weekends if something is not finished, although that way everybody would have taken it much more seriously.

Many people might not agree with me, but classical SCRUM is rather for developed companies, not for startups. Even if you think about the concept of user stories, that works well when there's someone who ordered a software from you. If you create your own product it's a little bit ridiculous in "As a user... I want to..." sentences. The other very important thing is that there should be the well-defined different roles, for example, the SCRUM master and the product owner. These distinctions rarely happen at startups.

Daily Activities

We had daily standups every day. This is a great way to see if the team has any problems and it's also a nice and controlled way to deal with those problems. I think daily standups are great if the team is interested in almost every piece of info or they can help each other. If it's not like that, then the standup is a waste of time for many people.

There was a very useful thing which we did at the beginning of every daily standup. We updated our totally manual burndown chart, which we draw on a piece of paper. It helped the team to realize if we were behind schedule. I know that there are many tools for this, but this ceremony had a really good effect on the whole team.

Besides daily standups, we had another very, very important daily activity, which is usually not practiced by most companies. It's daily planning. It can help the whole team to have a commonly shared knowledge and point of view of the upcoming sprints' features.

We did it every day half an hour before our usual lunchtime. This way we were sure that these meetings wouldn't take too long. Just get to the point, and if you don't have enough time to discuss something, you can still do that tomorrow during the next daily planning. If that issue was not that important, then you will discuss something else.

Daily planning helped us a lot. When it comes to estimations, it leads the team from total chaos to a relatively well-coordinated state where we could make very good estimations and things were finished when they were supposed to be finished.

A Few Words about Project Management Tools

Let me share a few thoughts about the project management tools we used. At the beginning, we used trello for project management. It's good for kanban, but not enough for sprints and SCRUM.

We turned to Jira but to be honest, we never liked it. Although you can accomplish everything with Jira, it's extremely burdensome to use and it just does not feel right.

Eventually, we started to use ZenHub which is simply the best project management tool so far. It builds upon GitHub's ticketing system and enhances its functionality with neat things, for example, Kanban boards and burndown charts. There are a few caveats but I can bravely suggest you and your team give it a try.

The Pomodoro Technique

As I mentioned previously, there was a lot of distraction in our office, even though there were only 5 people at the same time. Even if you introduce some kind of policy to keep everyone quiet, people tend to break those rules.

Here comes the Pomodoro technique into the scene. It divides your distraction-free time intervals in which you have to focus on a specific topic from the breaks, in which people can distract you.

Originally this technique was invented for individuals to work effectively, but we introduced it on company level. This way we synchronized the focus time of every individual in the company.

If you want to try out a Pomodoro tool with which you can synchronize your whole team, try marinaratimer. Although it's not perfect, we used it on a daily basis.

Synchronizing the whole company worked great for us because everybody knew when they can talk to others without interrupting them. Even if somebody stuck with some task, the longest amount of time while they won't get their answers is 25 minutes at max. (And they can always work on something else in the meanwhile.)

Summary

By reading this article you have gained some insights how the management of full-time employees evolved in our first few years. From total chaos, we changed to a strict SCRUM company and we also used the Pomodoro technique to keep our distraction-free times.

I want to emphasize again that one of the most important habits we developed was the daily planning. With the help of that, we could estimate much, much better and the scrum meetings were more useful for everyone.

It worked very, very well with full-time employees, but after a while, we started to work together with many part-time employees. If you are interested why SCRUM was not suitable for them and how we changed the management in our company to work effectively, then come back and read the next article in this series.

Code Generator Tools Used in HTML Email Development

Mihály Sáróy — Wed, 20 Sep 2017 13:28:57 GMT

Every now and then you hear that only machines will produce programming code in the near future. Computers are taking over. It may be frightening or challenging, depending on the perspective. But don't worry, there is still some time for the transition and thus it's really advantageous to take control and learn about how code generation tools work.

In this article we'll show you tools that help to create robust email code based on presets. Small, yet important steps to the rise of computer domination in development.

Throughout this post, we'll be talking about Campaign Monitor's background and button code generators - well-known in the industry - and examine their advantages. Following these, we'll be showing two layout generators: one we created in-house and one found in our research.

By learning about these tools, we focus on quality and maintainability aspects of email development. We can use tools written by others or we can write them ourselves matching the best practices. We'll be able to leverage the controlled quality to always have the expected outcome.

In this tutorial series, we started off with generally-applicable improvements to anyone's email development workflow. As we have now a grounding knowledge on the basics, we dive into customized applications. By signing up, you can be an insider at EDMdesigner and look behind the scenes. Don't miss out on the chance!

Code Generation Tools

As mentioned in the introduction, the big idea behind code generation tools is that you have bulletproof code snippets that can take parameters and generate code accordingly. You'll be sure that the code will work in the email clients you want to support and the process will save you time. That's the case with backgrounds.cm and buttons.cm, so let's look at them first.

Background Generator

Supporting background images is somewhat tricky in email. You either want to insert them in specific areas or apply in the full email body. Based on your choice, you'll have different considerations. The backgrounds.cm tool has a solution for both:

Full Email Body Background Image

You can look at Campaign Monitor default code for background images when they are applied to the full email body below:

CONTENT

The considerations for full body background images are as follows:

As many clients block images by default, there's a background-color property in the DIV element as a "fallback color". You probably don't want blank, white backgrounds to show in marketing emails, so you can define fallback colors to be displayed in those situations.

Generally speaking, it's a good idea to have fallback colors for the cases where images are disabled. However, where the message is forwarded and the fallback color is defined on the email body, this color is applied to the forwarded message's email body as well. That's normally not preferable, especially with dark backgrounds (that's why this phenomena is called "Black reply"). The backgrounds.cm tool uses a wrapper DIV element to avoid "Black Reply".

Word-based Outlooks (2007/10/13 and Windows 10 Mail) don't support background images at all. You can only include them with encoding, meaning that the image is given in code. The one used for Outlook clients is VML. These are the parts surrounded with conditional comments (CONTENT
The highlights here are:

This setting has two additional sets of parameters (besides fallback color and image source settings).
You can customize the width of the cell with a toggle to fit the email width, and adjust the height with a different toggle to the content height. The latter is far more interesting, because in addition to providing the previously missing dimension, it adds a style="mso-fit-shape-to-text:true".

We also find a separation of "for Outlooks" and "for other clients". The VML version of the background image is placed inside the table cell and is applied in desktop Outlook clients. The background from the wrapper td is picked up by all the other email clients.

The background tool is a wonderful tool relied on by many email developers. From this short introduction, you could see how it works and if you run visual tests, you can experience it's great client coverage as well. We had our test by inserting the generated code in our boilerplate email template that uses the Drop Calc Method:

Litmus test results for Backgrounds.cm in single cell
You can check out the full source code of this step on Github

However, you may lack the option to use the tool offline in your workflow. The project is not open-sourced in a way that you could include it in your own projects programatically.

The other thing we miss out on is the support for retina background images. We've read about them before, and though it's only a thing for progressive clients yet, it would be nice if you could choose an option for them or be able to develop this feature on the basis of the existing tool.

Button Generator

Clickable Call-To-Action buttons are very important in email marketing that makes a bulletproof button generator, like Campaign Monitor's invaluable.

There are four basic button types: VML-based, Padding-based, Border-based and Padding + border-based buttons. You can look up these buttons, if you need more understanding about them. Last year we tested all and made some improvements yielding a fifth button type: the Line-height Based Bulletproof Button. Building upon the practical experiments from the last article, we'll conclude why the Buttons.cm generator is a great tool to use.

For appetizers, this is what the generators default code looks like:

Show me the button!

Your first instinct may be to run away while you can, but I promise that this snippet is simple (for most parts) and therefore wonderful.

The notable parts:

It's basically structured into two buttons: one for Outlook clients with VML, and a regular HTML button for regular email clients as we saw in the background section

VML is used for supporting desktop Outlook clients like with the background tool before. It's hidden for any other clients than desktop Outlooks as its conditional comments is only parsed by Outlook.

The regular HTML button consist of a DIV container element, and an a tag, which has display: inline-block, so it can apply the specified height and width for the link. The whole thing gets hidden by the mso-hide:all; property in desktop Outlooks.

The button can use a background image, which is a nice option to have. However, if the email client doesn't load images by default, the defined background-color will be visible.

If you check the theory around which this button is built, it's very similar to EDMdesigner's Line-height Based Button. It also doesn't have padding or margin properties to stretch the button's dimensions, but uses the line-height on the a tag and the width property.

See the Line-height Based Button's code below:

I am a button →

The main difference comparing the two lies in the use of VML and DIV elements (these we could omit).

As far as support goes, the only clients left out are: old Lotus Notes, Outlook.com and Office365. All the other clients seem to display the button.

Litmus test result for Buttons.cm
You can check out the full source code of this step on Github

Now, last but not least let the simplicity of the below UI convince you to try this tool next time:

In this section we analyzed the code of the bulletproof button generator and we have seen the advantages it has. By the above image, you can see the available parameter options for customization. You can design beautiful buttons easily.

From the point of flexibility, we miss the option to select which button type you would want the generator to use. For example, if you don't need support for desktop users, the VML part is totally unnecessary, which can make your code more easier to use and much shorter.

Layout Generators

We won't dive into the very details with layout generators, but there are two tools worth mentioning besides the several layout code generators for the web. One is an offline tool, which with certain customization can be truly powerful (you may see that in our article about automation), the other is an online tool ready for use.

With these last pieces, you have most of an email covered. You have tools to generate the layout, background images and bulletproof buttons.

EDMdesigner's TableGenerator.js

The first tool is the one we introduced in a previous tutorial. Our goal was to show, how you would start creating a code generator by yourself with JavaScript. In the post we showed a simple script, capable of creating multi-column layouts with Node.js based on command line parameters.

node tableGenerator.js 1 2 3 > index.html

You can check out the full source code on Github.

There are many options to improve the tool above. For simplicity's sake, we didn't customize it to high email client coverage with email specific styles and markup, but it can be done with little effort and some coding skills. Feel free to use the code from the article and make a custom tool of it for emails!

Email Layout Calculator by Julie Ng

We're going to visit another layout tool lastly, created by a fellow email geek who we respect very much: Julie Ng. You can access the tool following this link.

Now if you check it out, you can learn quite a handful and you'll get the help you need to design the layout. You get a description on how the tool works, why it uses the properties it uses, and you can customize your desired layout and see the generated code update on the fly.

Julie also published an article detailing how her tool was designed and what clients it supports.

A two column, 600px wide layout with 4px separator line would look like this:

Email Layout Calculator Column 1 Column 2

It's important to note that you can:

Set the layout width to any desired width, you are not limited to the long-standing tradition of 600px

The tool was created with concerns for email clients on mobile devices and as it was created before the big Gmail update last year, it has special focus on Gmail.

For easier understanding about how the layout work, we added the following code to the beginning of the embedded styles:

* { border: 3px dashed black; padding: 10px; }

It highlights each element, so it's visible how the layout is structured.

Litmus test results for the layout code
You can check out the full source code of this step on Github

Despite all of the very positive aspects, we still have the same wishes about the generator as before: the ability to customize the generation for specific client list, the ability to work offline and with that: to be able to add it to an existing workflow or modify to our own use cases (or possible email client improvements).

Summary

Throughout the article, we introduced 4 code generation tools and showed you why you may want to use them.

We reviewed some useful characteristics of the bulletproof background and button tools of Campaign Monitor.

We saw how they support desktop Outlook email clients with VML and that they have regular HTML for high client support in other email clients. We also gathered the customization options and saw their effect in the applied properties.

Next, we saw two layout generator. With the first, our aim was to show you an example on how to start developing a code generation tool and give you a reusable code base that you can modify. The second was a simple tool, which helped to create layouts that considers mobile email clients and provided helpful comments on the key aspects of the code.

These tools have high reliability as they are created with well-defined and tested conditions, based on real life experience with the various email clients. The bulletproof code snippets are usually customized with parameters and thus offer the advantage of speeding up the development process as well.

We hope you enjoyed the topic and that you'll join us next time. We also welcome questions and ideas you may have and inspirational thoughts for others.

In the next article,we're going to continue with code modifier tools developed in-house at EDMdesigner. Get the next post in your inbox by signing up.

Advanced Drop Calc Experiments

Gyula Németh — Wed, 06 Sep 2017 11:38:16 GMT

As you might have heard, Drop Calc is a new layout method for creating responsive emails. I invented it while I was working on one of the articles of the Modern HTML Email Tutorial. I am really happy that the community finds it to be useful, and I feel honored that I had the chance to talk about it at Litmus Live London last week.

I am going to publish a short article in next two weeks, recapping my experiences from the conference. Also, I want to include the video of my presentation, so hopefully it will be published by then. If you are interested in hearing about my experiences at the greatest email related conference, please subscribe below.

Drop Calc as a General Fallback Technique

A few days before the conference, my presentation was finished already. I rehearsed it in front of my colleagues. They provided me incredible feedback. Thank you guys. I also presented it to Jaina Mistry from Litmus, and her ideas were also very valuable.

BUT the following happened...

On the way to the airport I was reading my emails. One of our customers asked if it's possible to create equal height columns. Our usual answer is NO with capital letters, because if you stack those columns on top of each other on mobile devices, there will be lot of empty space, so you will have to scroll a lot.

But wait... Why don't we apply Drop Calc to the height property? - I asked myself.

Doing that can allow you to have equal height columns on desktop, and those columns will collapse on mobile, meaning that you won't have those disturbing empty spaces.

On top of that I thought that I could apply it to other properties as well.

I made some experiments a few hours before my presentation, and it turns out that Drop Calc method can be used on any property which can be calculated and which has an attribute version. (So we can fall back to something.)

Because of this, I decided to change my well-rehearsed talk. I hope it was worth it.

Recap of the Drop Calc method

Before talking about the new experiments, let's recap the most important parts of the Drop Calc method for creating responsive layouts or HTML emails.

There are two very, very important observations:

The first is that the CSS calc function is not supported in every email client.

The second is that there is a specific order of importance when it comes to width of tables: attribute < class < inline style < !important in class

Let's say that we use !important only in media queries.

Now, if you put calc in inline style, the following things can happen:

if the email client supports the calc function

and if it's a desktop client, then the calc in the inline style will be applied (which is the desktop version)

and if it's a mobile email client, then the media query will be applied (which is the mobile version)

if the email client does not support the calc function

and does not support the style tag (thus classes), then the value of the width attribute will be applied (which is the mobile version)

and it supports the style tag (thus classes), then the width in the class will be applied (which is the desktop version)

We are very lucky, because the desktop email clients which don't support the calc function support the style tag. The mobile email clients which don't support the calc function don't support the style tag either (so the attribute will be applied).

This way we can create robust responsive layouts which will be correctly rendered on almost every email client. If you want to check out a thorough example, please read my previous article.

Besides that, I suggest you to read my article about how to create wider than 600px email layouts, which also builds on the order of importance I mentioned earlier.

Experimenting With Height & Drop Calc

As I wrote previously, one of our clients wanted to have equal height columns on desktop and those columns had to collapse on mobile, so no unnecessary empty space would be shown when the columns are stacked on top of each other.

So let's apply the same principles to the height property of a table. It means that you have to add for example, calc(400px) in inline style and provide fallbacks in class for old desktop clients and in the height attribute for old mobile clients.

For mobile clients, the fallback is actually nothing. You don't need to put anything in the attribute, because we want to get back the default behaviour when we are on old mobile clients. It means that the default height (auto) will be applied.

For old desktop clients, you need to define the height in class without the calc function.

I created this example a few hours before my presentation at Litmus Live London (2017):

As you can see, there are three very famous people in this email from Litmus. But what's more important is that on desktop, our columns have the same 400px height.

Since it's an advanced topic I will let you, dear reader, discover the details of this experiment on GitHub.

If you are not that familiar with the Drop Calc method, you definitely should read the original article first.

Check out the Litmus previews.

Experimenting With Font Size & Drop Calc

After finishing the experiment with the height, I thought that we could use it for other numeric properties. I created another experiment with font size.

Luckily we have the good old tag which has the size attribute. It means that there is an attribute to fallback to. We can use the font-size CSS property in inline style with the calc function, and we can use the same property without the calc function in class.

This way we have two different things to fallback to, which is the basis of the Drop Calc method.

I created the following experiment which you can check out on GitHub:

As you can see, the main goal is to increase the font size on mobile devices (also on old Androids). It definitely works, but there is one issue: you can't set the line-height with attributes! If anyone knows how to solve that problem, pleas let me know in the comments section below.

If you are okay with the fact that you won't be able to set the line-height on old Androids, then it's worth it to try the Drop Calc method with the font size property.

Check out the Litmus previews.

Further Opportunities

As you can see from the previous examples, Drop Calc is a general fallback technique. If you apply it to the width property, you can create robust responsive layouts for HTML Emails.

You can apply it to any numeric property which has an attribute version to fallback to. In this article you have read about two applications: height and font-size. Besides these you can think about any numeric property, for example the border width.

If you don't have an attribute to fall back to, that is not necessarily a problem. As you have seen in the height experiment, sometimes the attribute fallback can be omitted.

I was also thinking about using inherited values instead of attributes. This would mean that you could define some properties on a parent element, and you could override it with inline style (and calc) in a child element... This way you might be able to define fallbacks, but it's only an idea. I'm very curious if someone can come up with something like this.

My last thought is that you can play around with other CSS functions which are not supported everywhere. I'm not that familiar with CSS functions, but it would be awesome to create a fallback technique similar to Drop Calc, but with non-numerical values. (What about rgb, rgba or attr?)

Code Quality Tools and Email Client Specific Targeting

Mihály Sáróy — Wed, 23 Aug 2017 13:27:56 GMT

EDMdesigner blog has been offering in-depth tutorials on HTML email coding for the past few months. In this current article series, we have used and will continue to use frameworks and technologies exceeding the HTML & CSS system of email coding. They are great ways to help productivity, but as a refresher we will take a step back into our comfort zone and look at online tools and less code heavy examples.

In this post, we look at additional tools that help to secure the output. We'll see free online tools to validate the HTML code. Many visual testing services, including Litmus and Email on Acid provide these kind of tools, but if you don't use them or want to see a second opinion on a compound template, it makes sense to test with another service.

In the article before, we discussed code inspection with the browser Developer Tools in webmails. It's also a good way to come up with client specific targeting. You see, a specific class or the way the client processes your code with its pre-processor can be the basis of custom designs.

In the third part, we'll see how Thunderbird can be a good companion in workflow and see extensions at your hands when you work in the browser.

There are some important topics however that we wont't discuss in this article. One is testing call-to-action buttons. It's hard to test them as you have to do it manually. We had a post on a new line-height based button before and we had quite a few click tests with it so you know what to expect. There are standard button types, where you can also rely on documented click tests.

We also leave off spam testing. There are easy-to-use initiatives to help you. We had an article last year gathering the full spectrum of email quality testing. For the purposes of deliverability, like finding out your sender score, you can find great resources there. I also recommend checking things off this list before you send out a campaign.

In the next article, you can read about the special responsive layout technique of The Drop Calc Method developed at EDMdesigner. You can gain insights of its development background and how it was received in Litmus Live Conference. Sign up, if you don't want to miss it!

Code Quality Checking Tools

We saw visual testing by the web browser and testing services in the previous article. We emphasized how important visual testing is, but it's no secret that there's so much more to email quality testing, which you should check before you hit send.

As mentioned in the introduction, first we cover email code quality. You need to make sure that the code has valid links, all the HTML tags are closed and that your code best fits to the standards. Many problems may be avoided by obeying this simple rule.

Code Quality in Code Editors

During development, the standard help is syntax highlighting, but it misses many mistakes, so can't be relied on for the job.

A more accurate option is to set up an HTML linter for your code editor. You can find an HTML linter for every popular code editor, like Sublime Text or Visual Studio Code. The purpose of linter packages is to help identify where and what the problem is. In the image below it's clear that something is wrong even by syntax highlighting, but the list generated by the linter-package makes it child's play to resolve:

Online Code Validators

There are an ever-evolving number of tools to check if your code is confirm to the email best practices. They are easy to use, as the usual operation is just 3 steps:

open the online service

copy & paste the completed code to the validator's text area

run the validation process

For checking HTML validity, the most common go-to is the W3C validator. It's hard to follow every rule, but it can help to spot rookie mistakes. However you'll often find that legacy email development techniques are often filtered as well:

A more appropriate tool is HTMLemailcheck as it's designed specifically for email testing. The free plan covers HTML and CSS, but it has affordable price for additional tools like link checking and accessibility testing. You can validate and get actionable suggestions to fix the problems.

Accessibility gains an evolving importance in web and email design and the available tools help you produce code that works in screen readers.

Last but not least, you need to know about Can I Use in HTML Emails, where you can quickly review support for CSS properties among the most definitive clients. As Outlook remains the most advanced client to support with respect to allowed properties, you may decide to run a quick test with this tool depending on your users' email client segmentation.

Targeting Gmail and Inbox Email Clients

Most challenges in email development derive from knowing what to expect from particular clients. This enables us to tailor higher quality for state-of-the-art email clients. It's the basis of email client specific custom designs, like progressive enhancement.

For the purposes of this article, we played around with this very cool Gmail/Inbox targeting technique. We found it on FreshInbox Blog.

The code looks as follows:

THIS IS GMAIL THIS IS INBOX

In the example we have inline styles hiding elements, and with a specialized CSS selector combination, we make them appear by display: block !important; property. For instance in Gmail, the class="gmail" is applied from the embedded CSS, while the class="inbox" is not.

The idea for this targeting is that in Inbox the section element gets removed, while GMAIL keeps it. It was our suspicion that the same rule applies to all HTML5 elements. It turned out mostly to be true (
or
are invalid even in Gmail).

If you need to look up the CSS selectors, here are links for the Class selector ("."), Adjacent sibling selector(">"), Child combinator ("+"), and Descendant combinator (" ") used in the article.

Using Inbox, with the Developer Tools we can identify that HTML5 opening and closing tags are replaced with HTML code. The nested content is raised to the same level as the tags, thus making this specific targeting work.

However, it's clear from the above that based on this targeting we can achieve different client specific designs.

There's a very useful resource at this point, if you want to target email clients other than webmails (for these, you can always use the browser Developer Tools to inspect the HTML): Rémi Permantier shared a link on Litmus Blog about a collection of methods to retrieve email messages' source.

The Thunderbird Workflow for Email Testing

We chose to demonstrate Thunderbird because it has some really cool features. You could use it as a code editor or an email sending service, which makes it an invaluable addition to our current testing tools.

Mozilla Thunderbird is a free, open source, cross-platform email, news, RSS, and chat client. (source Wikipedia). It was developed by Mozilla Foundation and though there's a fork in the road of Thunderbird and Firefox development, and Thunderbird is migrating off Mozilla Corporation infrastructure, the effect is apparent in the software everywhere.

From the point of email development, we deal with Thunderbird because of its capabilities to:

show email source for inspection even though it's a desktop client

have the unique moz-text-html class, which provides client specific targeting option (see it also in the above image)

let you insert HTML code and use it as sending service for HTML emails

extend HTML editing capabilites with ThunderHTMLedit

A possible workflow might look something like this:

You extract some raw code from your favorite code editor

Paste the HTML into the new message and send yourself a test

View the test to get a feel for the design and inspect with the smart wire-frames

Modify the code if necessary with the aid of ThunderHTMLEdit

Send another test, and repeat from the top if you need to

In this section you could see a complete testing workflow with Thunderbird and specific Thunderbird targeting with the moz-text-html property.

For a full collection on client specific targeting check out: tabletrtd.com's article. It's worth it to bookmark that page if you haven't done it yet. You can find actual email development gems there.

Browser Extensions for Google Chrome

In the previous section you could examine how an extension can add useful functionality to Thunderbird. In this section we'll boost the performance of our web browser in the same manner. We limit our selection to Google Chrome extentions, as Firefox is in the middle of transitioning their add-ons philosophy to the WebExtension system.

There are two extensions we would like to sell you on in particular, but feel free to leave recommendations about your favorite tools in the comment section below.

The first one is the Web Developer. As the name suggests it has functionalities exceeding our needs, but after you have installed it, it's just a click away to check in a completed template:

if you added alt text to all of the images:

inspect how your CSS works throughout the template:

and basically you can distinctly analyze any element or properties of your design. This flexibility to separate parts of your design can be really amazing. It's worth a try.

Our second recommendation is called Emmet Re:view. It's developed by the emmet.io team and is used to assist Responsive Design.

You may wonder why is it better than the Device Mode in Chrome:

Why we consider it a good addition to your toolset is its capability to show the design by the multiple breakpoints defined in the email's code:

You can also filter views based on device types, like 'tablets' or 'mobiles'.

In addition to introducing two extensions, it is worth mentioning that there are extensions for Email on Acid and Litmus. If you use these testing services, you can send code for full visual testing very easily. It can definitely help you speed up the testing process.

Summary

In this article we went over three topics:

code quality with online tools

client specific targeting

browser extensions

You could learn about a handful of ways to check your code, like installing HTML linter package to your code editor or using the validator services of W3C, HTMLEmailCheck and Accessible-email.org.

We hope you feel inspired and intrigued to start thinking on custom designs for Gmail, Inbox and Thunderbird for your next campaign.

Next time you need to inspect the web version of your template, you have the Web Developer and Emmet Re:view extensions to help you with your worries.

If you enjoyed the article join us next time as well. You'll hear about the Litmus Conference and EDMdesigner's part in it from Gyula Németh, CTO @ EDMdesigner. See you then!

Visual Email Testing with Developer Tools, Litmus and Email on Acid

Mihály Sáróy — Wed, 09 Aug 2017 13:18:17 GMT

In the previous articles of the HTML Email Develoment Tools series we gave some pieces of advice and showed some tricks for development productivity, like Sublime features and layout-generator scripts. By having read those posts, you can write code more efficiently.

Now it's time to see the tools that can define if the output is quality or rubbish. We consider the topic really important for email coders.

In this article, we are going to discuss visual testing, and we'll use the built-in tools of the browser first. The browsers' Developer Tools will enable quick iteration over design. It'll help us identify common mistakes that most email clients won't tolerate. Following that we'll walk through an example of some support problems that can only be identified via email testing services or email tests on physical devices.

Some of the tools throughout the post may be old friends from your professional experience or our previous tutorial series on HTML email coding. In the Modern HTML Email Tutorial Series, we revisited HTML email development principles based on the new era of modern emails as per the Gmail update.

In each topic, we had theories about how client-support may have changed in the past. We kept on continuously justifying these theories with visual email tests. With these tools, we could tell how code changes affected the rendered views in numerous email clients at the same time.

However, that was the time when we realized how time consuming it is to run tests through these services. We also noticed that we can save time if we do the initial testing of our concepts by the aid of web-browsers.

This article started off as a comprehensive introduction about testing tools for email coders. But soon enough we found out that there was so much to mention, that we decided to only discuss the built-in browser Developer Tools and visual testing in this post. We'll show other tools and extensions in the next article.

Introduction to Email Rendering and the DOM

Varied rendering is a worn out topic in email development. Every email client has its own implementation of supported HTML and CSS; to be a successful email developer you have to know about all of them. For this reason, we're looking under the hood inside our web browser to see the possible causes why our templates might break.

Next time you encounter odd behavior from some properties, you'll be able to identify the problem by yourself. In this section, we're going to discuss the theory first, then cover the topic through an example and sample images.

From HTML & CSS Code to Rendered View

Let's go over the process an email goes through until the recipient receives it. We cover this section based on our readings from Litmus' article.

Every fancy email starts with an HTML document, which has CSS inlined, like this:

Document TABLE, TR element TD element

Pretty straightforward, right? (Although if you think about it, we'll see some email-client differences already, as some clients support external stylesheets... But let's just forget about that and use email best practices!) The document is sent to mailboxes by some sort of server. As we talk about emails, it is the mail server. Usually, there's no change in the HTML at this step, a lot of additional data for the mail client.

Here is an example excerpt from Gmail about the previous HTML code:

Inside the recipient's email client there's a pre-processor which interprets the document. It eliminates all elements that are unknown or dangerous, like scripts from the attributes. If clients don't do this, the users are exposed to the security vulnerability of cross-site scripting XSS. Cross-site scripting enables attackers to inject client-side scripts into the emails. Source: Wikipedia

At this point, custom classes and additional markup may also be added. At this point, huge implementation differences arise. You can access this data directly in every webmail client, using the Developer Tools:

In the subsequent article, continuing the topic of email quality inspection, we'll show you how to exploit this behavior.

Following these steps, the rendering engine receives the modified HTML and parses it to create the Document Object Model (DOM). The DOM is an object, representing the HTML document and the applied CSS properties. This representation is visible in the browser or in the mail clients. The email clients often use the operating system's browser engine to show the DOM.

The main reason behind the DOM is that HTML elements and attributes can be accessed by scripting languages, like JavaScript. As it provides an interface for programmatic use it's called the DOM API. However, scripts are removed in the vast majority of email clients, so we don't need to worry about this at all.

The Developer Tools as a Testing Solution

As mentioned before, email clients often use web browsers present on your operating system to render views. Webmails use the browser in which you open them. Desktop email clients can default to specific browsers installed on your system. One example is Internet Explorer based Outlooks, they will use Internet Explorer or Edge on Windows-running machines.

By the above mentioned details, we have 3 + 1 reasons to test first in the browser:

Quick iteration over your design

Support to write properties on the fly

Easy way to debug with tools like the option to turn properties on/off

Almost immediate feedback about the payload and download speed

Webmail view is usually very similar to browser view with the same browser

Specific desktop client's views can be anticipated from the browser view

Internet Explorer 8 Emulated in Edge Outlook 2002

(Mobile views can be emulated in major browsers)

There's a plus one among the bullet-points because you always need to test emulated views as they are not 100% reliable.

There are a few conclusions to keep in mind here:

We suggest browser testing only as a preliminary step to help you decide on the main design principles. It's always advised to confirm with visual testing services and physical devices.

Just as in web-development, you need to consider other browsers. It's best if your workflow supports the most frequently used browsers (like Chrome, Firefox, Edge, Safari). See our recommendation for multi-browser testing through an example in the next section.

Browser Testing Example

Working with the browser can give an almost instant feedback on the design and we've seen quite a handful other reasons to do it. In this section, we'll see that we can also use it to catch rendering differences across browsers before we would use a testing service. First we'll work on our testing workflow, then we'll inspect what we've built through an example highlighting a rendering difference between Chrome and Firefox.

Getting Started - Testing Environment Setup

To be able to run consistent, well-orchestrated tests in multiple browsers, these are the tools you'll need:

A text-editor, possibly with LiveReload enabled

Major browsers installed

A server for serving your HTML documents. You can download one here running on Node.js

Virtual Machine with running operating systems for the browsers not supported on your system

In your workflow, you'll open up a text editor, fire up a boilerplate template, or generate some initial HTML&CSS combo first.

Then, you'll have at least the major browsers installed and open. If you still miss out on any, here are the download links for the recommended ones:

IE / Chrome / Firefox / Safari

Now, there's a problem. Safari is not supported on Windows, while you can't install IE on Linux (there may be other restrictions you encounter; if so, please share it in the comment section). You can eliminate these kind of problems, if you install Windows for IE and Mac for Safari on virtual machines.

For this purpose we use Virtual Box, which you can download here.

Testing in 4 browsers may seem overwhelming and you may decide to skip this part. It's actually okay, if you only test in two of the most important ones for your email client list, when you'll do visual tests by testing services later. Nonetheless if you follow our recommendation here, it becomes really easy to test in multiple browsers.

Next, we'll download and extract the server and start it with Node.js, running node server.js.

This gives us the benefit of accessible working files in all web browsers. Even in the guest virtual machine you can open the exact same files. You need to type ipconfig on Windows / ifconfig on Mac on your host, so you'll be able to find the IP address of your host machine:

If your servers are running, you can access the served files from the browser. Just type the following pattern in the URL address bar: localhost: on the host machine, or :/ on your guest virtual machine.

If you've also set up LiveReload, all the updates will show in every web browser on your host machine.

Inspecting the DOM Through the Developer Tools

With our environment ready, we can start actually developing and testing email HTML. In this example there is a very basic layout setup, which serves as a good basis to start inspecting elements.

The idea is that supported email HTML is developing among the various email clients, so maybe we could use DIV elements in our design. We're going to have a wrapper table, conform to email best practices, and have two DIVs inside, nested into each other. Filling it with nice, well-coded content, it could be developed into a beautiful marketing email - that's our goal.

The complete HTML of the document:

Document TABLE, TR element TD element Outer DIV Inner DIV

You can check out the full source code on Github as well.

As you can see in the CSS, we set the inner DIV to 300px with 300px bottom margin. The other dimension we apply is a min-height for the outer DIV. We'll expect the child DIV to stretch the parent DIV and all the table's elements surrounding. As we color each element, a nice layout should show.

These are the results (left - Chorme / right - Firefox):

Now the output is quite unexpected. They are radically different in Chrome and Firefox. If we would use testing services, the only thing we could do at this step is to modify the code. The visual feedback may help us to understand the initial cause of the problem.

When we use multiple browsers we can use the DOM inspector in each browser, turning features on and off and looking at how the CSS properties are calculated. In each browser, the Developer Tools are accessible by pressing: F12 / CMD + SHIFT + I.

Let's take a look at Chrome's DOM inspector:

And analyze the same in Firefox:

We can conclude what we've seen with the two ways of inspections:

If you examine carefully, both browsers know that the inner DIV is
600px high, considering height:300px and margin-bottom:300px

Firefox applies min-width:400px as an absolute value, and cuts off the inner DIV there, hiding the margin-bottom property

Chrome recognizes the min-width, but also nows that the inner DIV has a margin, so it counts it as if it were outside of the outer DIV

Firefox counts the TD element to 400px (+ font size), Chrome counts the same TD to 700px

These differences are present as the two browsers both struggle with deciding the correct height for the elements. We can fix the templates by even adding a zero dimensioned element, which forces the browsers to calculate each element's height.

The fix looks as follows:

... ... ...
Outer DIV Inner DIV ...

You can check out the full source code here.

Email Quality Testing with Visual Test Suites

We fixed the templates so it looked the same in Chrome and Firefox. We are now confident that webmail clients will render great. To confirm that this is the case or not, we'll use visual test suites, Litmus and Email on Acid. They are the most comprehensive and respected choices available on the market.

Running Tests

Both services provide a great number of features to help developing bulletproof emails. By far the most important service is the visual tests, where you can see live previews of your HTML code in several email clients.

You can also start development from scratch or paste your HTML code to their editors. We have our HTML ready so we can paste it as follows:

Paste in Litmus:

Paste in Email on Acid:

In each service you'll find an editor - specifically prepared to handle email HTML - and a preview pane. In the preview pane you have a browser view by default, which you can toggle to show numerous email client's previews:

In Litmus:

and also in Email on Acid:

The live previews guarantee the option to test in most of the significant environment setups of browsers, email clients and operating systems. It's also possible in both services to share the outcomes with a sharing link. We can now compare and contrast the results of the two testing service.

You can check Litmus previews before here.
You can check Litmus previews after here.
You can check Email on Acid previews before here.
You can check Email on Acid previews after here

Confirming our results in Litmus and Email on Acid we can see that browser testing was actually a good way to catch design problems, though we have a lot of differences remaining. If you wish to solve those too, our previous article may be useful.

Comparison of Litmus and Email on Acid

As you can see, both services are fundamental tools to make your design bulletproof. The only other option is to test on physical devices, which is costly and far more time-consuming. However there are other good features these platforms provide to help speeding up development process and improving code quality. Definitely our list won't be exhaustive, but let's see the most eye-catching items.

Both services have a number of pre-written templates, which you can modify to your needs. They have preview panes showing a browser view, which is quite similar to the browser testing we were doing before. You can switch it to examine mobile browser view or multi-client previews with a single click.

There's an option in both to follow up on your development history based on the code as well as the project preview. They have additional services like Spam Testing and email Analytics, but let's see more benefits that are related to code quality.

Litmus offers:

Grid view for easy understanding of your markup structure for the browser preview

A service available from the Checklist that enables you to verify your subject-line in many clients with live previews

Multiple email templates in a project and you can run tests for them separately.

Email on Acid offers:

A built-in inliner tool shipped - your embedded CSS become inline styles by a click

An very easy to understand code quality checker warning about problems with your code and also an Optimizer tool, which will correct them instantly

The ability convert your special characters to HTML code in an instant.

And last but not least, two very intriguing features: Litmus has Sync to ESP, Email on Acid has Mozify.

Summary

In this article we learned about the browser's Developer Tools and email testing services.

In the first part of the tutorial, we summed up the steps which an email goes through:

HTML document is created with inlined CSS

Mail server sends the information usually untouched

Pre-processor modifies the document, strips away dangerous content

Rendering engine creates the Document Object Model (DOM) for representation

Next, we inspected the DOM in Chrome and Firefox through a simple example, which was rendered very differently in the two browsers.

In the second part of the post, we discussed the two best email testing services, Litmus and Email on Acid. We analyzed the email previews and made some comparisons on their available features.

We hope that you found this article interesting. We're going to continue in the next one with some tricks and extensions in the browser and see some online services that will improve code quality. Join us next time as well!

How to Use JavaScript for Creating HTML Email Layouts

Mihály Sáróy — Wed, 26 Jul 2017 11:03:18 GMT

Email HTML has always lacked the presence of scripts. No interaction, no DOM manipulation, no fun. Of course, this is a bold statement to make, but if you know some JavaScript, you may have had the feeling that you spent so many days, nights and hours of your spare time to learn it, and what for? You have to forget about it when it comes to HTML email. But that's not necessarily true. Today we are going to get relief and use JavaScript for creating HTML emails.

This article is a chapter of the HTML Email Development Tools series. The aim of the series is to improve our email development workflow. We have so many thoughts on the possibilities. We're searching for the best ways all the time. In our first post, we showed code editor features with Sublime Text, for example saving snippets. You can check out below what we wish to cover in the upcoming articles.

In this post, we'll use some JavaScript for generating HTML Email templates. Don't worry if you aren't an expert; we'll progress in a step-by-step manner. In the first part, we gather the basics of scripting and show you why we chose JavaScript for our example. Next, we'll put together the pieces and code an example, which generates a table-based email layout from configuration lists. In the end, we will learn how to run the script in the command line to create the layout and push it into an HTML file.

The groundwork we lay down in this blog post will be used in future posts. We'll use scripting in the post about task-automation and probably in many more. If you don't want to miss them, please subscribe.

Getting Ready for Writing Executable Scripts

In this chapter, we go over all the theoretical knowledge that is crucial to get started. The topics we cover are: scripting in general, Javascript, Node.js, and last but not least the command line. Using these tools we can write really complex programs, but also simple scripts to support email development. In order to make the fundamentals easier to digest, we provide links at the end of each section enabling quick navigation back and forth between theory and practice.

Scripting in General

A script is a series of instructions for a computer program to follow. It's created with the purpose of executing of a custom behavior. A language is considered a scripting language if it can be interpreted by a program without compiling it previously, or — in the case of JavaScript in the browser — it is compiled on the fly (JIT compilation).

There are various languages available for the task. Standard examples exist for specific environments. According to Wikipedia, Bash is the default for Unix-like operating systems; ECMAScript (JavaScript), for web browsers; and Visual Basic for Applications (VBA) is for Microsoft Office applications, while Python is a commonly used, general-purpose language.

The three main reasons you would write a script are:

A single task is repeated several times (eg. compressing a file for size optimization)

Time-consuming operations for humans (eg. reading through a huge document to find words matching a text pattern)

You wish to define a general term for a set of instructions. You reference the term once, and all the instructions are implemented by that (eg. a "create project" term can be responsible for creating and naming a new project folder, creating and opening some default project files populated with pre-defined entries, etc.)

If you encounter all of the above, you would use a library to manage the complex, end-to-end processes. It's called task automation and we're going to have an entire article about that later.

For now, let's just see valuable, introductory use cases. Generating components and custom layouts for the email templates are good examples from email development. When you build dozens of similar templates, you probably need a nice little script to help you out.
Jump to the article's script example, if you can't wait to see it in action.

In the next section, we're going to continue the preparations by diving into the JavaScript universe and learning about Node.js and NPM.

Javascript & Node.js

There are various languages to help you interact with your computer and give it your list of instructions. Nonetheless, your choice should be based on performance, good support and widespread use in the developer community. Because of these points, we selected JavaScript. In the following paragraphs, we try to exhaust some of the important benefits.

Javascript is referred as the language of the web. The reason is that it is interpreted by every browser. Because developers use it so often, the language evolved into a general purpose language over time. It's considered the most popular programming language by StackOverflow's Developer Survey and Github's review.

JavaScript set its foot on the server-side with Node.js, but you can use it on your computer as well. Great applications were written in it: code editors like Brackets or Atom and operating systems using Node.js. If you haven't come across with it yet, Node.js is an open-source JavaScript run-time environment for executing JavaScript code. The engine behind Node is the same "V8 JavaScript engine" that powers Chrome browsers (and many more).

The Node.js runtime is shipped with the Node Package Manager (NPM), which constitutes the world largest software registry. The NPM is an amazing tool to include open source libraries into your code, or if you developed something new with high community value, you can make it public for others. Also, it's a great way to share the common libraries, developed within the company.

Before starting to code, you need to install Node. On their main page, they detect your operating system and serve the corresponding download bundles.

Go to the example run in Node to get a feeling on where this article is heading.

The Command Line

The last concept we need to grasp — before we could start scripting for HTML email layouts — is the use of the command line.

The command line is an interface for the computer, like the Graphical User Interface, but it is fully text based. It's a program that takes in text commands and passes them on to the computer's operating system to run. You can run programs, write scripts to automate common tasks, and combine simple commands to handle truly difficult tasks.

On UNIX-based operating systems like Mac OS X or Linux, they often refer to it as the terminal or console (for clarification on the proper terminology check this superuser discussion). On Windows-based systems it's called the Command Prompt.

In our example, we'll use the terminal to install NPM packages and run the scripts written in JavaScript by Node.js. If you need some refresher on how to find the command line, check out the links fitting your operating system:

on Windows / Linux / Mac

And below are links on how to use it:

on Windows / Linux / Mac

Since Windows has support for Bash - the standard shell program for UNIX-based systems, we'll focus solely on the UNIX-based command line. You can set it up easily for Windows too.

Jump to the command line heavy part of the example project.

Example Script for Layout Generation

In the previous section, we gathered everything necessary for a complex, holistic example. We are going to use the Node Package Manager (NPM) to manage the essential external libraries called the project's dependencies. We'll see how to include them in the script file we write. Then we're going to run the script from the command line. You are really excited now, aren't you? Let's start then!

NPM Init in The Terminal

First, open up the terminal. We begin by creating a new folder for our project with mkdir / command and start the development by initializing the Node Package Manager (NPM). For this, we run npm init. The command creates a package.json file and prompts us with a few questions regarding the project.

After each entry, you need to press enter. The answers are recorded to the package.json file. We left most of them empty, so after completion, it looks like this:

{ "name": "table-generator", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "author": "EDMdesigner.com", "license": "ISC" }

This being taken care of, we install the project dependencies. We need the cheerio package and pretty for this project as the only dependencies. Cheerio parses markup (like HTML) and provides an interface for navigating/manipulating the resulting data structure. This way it helps us selecting and nesting the HTML elements in the example. We install it by running the following: npm install cheerio --save.

We use the same steps to install "pretty", which will make the output HTML look a lot nicer.

By running the command, NPM will:

Look up its online registry (so you need an Internet connection) and download the code of the specified library

Create a new folder called node_modules on the same level as the package.json file is, and copy the code into it

Add the package's name in the package.json file

You can confirm it by opening the package.json file.

The last point in the list is useful because you can track the versions of the project's dependencies and also it makes your code easily usable for others, if you choose to publish your project.

If you need to look up the theory on the terminal from above follow this link.

Writing The Script Itself

Let's discuss a bit, how the program will work. Our goal is to control the layout generation process with just a series of numbers. We'll tell the program to create a layout in the email body with two rows, one column in the first, two columns in the second. For this, we just need to type: 1 2, hit ENTER ... and bam, there it is. How cool is that?

We'll implement the logic in this section. If you wish to check out the layout-generator first, and come back here to the very cool part after, then download the project in .zip format here, unzip the files, and hop on to the next section.

In a Node.js application, one of the first things to do is to require the packages necessary in that particular file. It'll virtually include the code from the selected sub-folder of the node_modules folder, making the public functions of those packages available. Logging events from the Node.js app will surely help you encounter any problems while trying this out.

var cheerio = require("cheerio"); var pretty = require("pretty");

Cheerio is a light-weight library inspired by jQuery core, so we initialize it similar to jQuery: on the $ sign. We can use it for easy selection of DOM elements.

The most important task is to abstract the functionalities away into specific methods in the JavaScript file. For this matter, we define the createLayout(){ // code }; and createMultiColumn(columnCount) { //code }; methods. The createLayout function creates the wrapper table and handles the single row - single cell type insertions. The createMultiColumn function is used to create the layout for more than one column. It includes additional table elements with single rows and populates them with the adequate number of table cells. This solution is called the multi-column element.

In the file, Node will read the instructing command line arguments as the "layout configuration list". We'll make it loop through the arguments, and based on their values, it'll either add a row with a single cell or create a multi-column layout.

The code for the createMultiColumn method looks as follows:

function createMultiColumn(columnCount) { var multiColTable = $(""); var tr = $(""); multiColTable.append(tr); // APPEND TABLE CELLS TO THE CURRENT ROW // CORRESPONDING TO THE COLUMN COUNT for (var cols = 0; cols < columnCount; cols += 1) { var td = $(""); tr.append(td); } return multiColTable; }

You can check out the full source code on Github.

Running The Table-Generator Script

Everything is ready now. If you followed along, the project should look something like this:

First things first, make sure that Node.js is installed. Run node -v in the terminal, and if you see a version number like this v6.x.x that means you are good to go.

You need to navigate to the working files, and run the following:

node tableGenerator.js 1 2 3

and you'll achieve this layout:

Sidenote: it's also possible to configure with the filepath, which file to run. This makes it so the current directory doesn't matter.

Now, we can generate any custom layout running the tableGenerator.js file with Node.js and using a series of numbers. We can take our example one step further by using powerful command line features:

node tableGenerator.js 1 2 3 > index.html

With the > operand, we can direct the console output into an HTML file.

Naturally, this example is quite simple; we just wanted to show the main concepts. A few more lines of code in the JavaScript file could include pre-written styles inside the HTML head or the addition of other components. The sky's the only limit.

If you need to look up the theory on running terminal commands follow this link.

Summary

We started this post by arguing the role of scripting in HTML email development. We wanted you to believe that it is useful in the development workflow. We saw the three reasons behind writing scripts:

Single task repeated multiple times,

Multiple tasks intended to execute on a single command

Time-consuming duties

and identified layout coding as a time-consuming task that's easy to facilitate by scripting. We also discovered tools from the JavaScript universe and learned the underlying theory in the latter half of the first part.

On the basis of our freshly grounded knowledge in general purpose JavaScript (Node.js), we coded a script file. Using the file, we could generate an email layout by a command and a few numbers describing the layout structure. We used the command-line to run the program. Here is a download link for the project's .zip. Feel free to modify it and share it with others. In case you made something clever from it, you shouldn't forget to also share it with us.

We are very proud of you making it 'til the end. This was a little lengthy and advanced article if you haven't written any scripts before, but we deeply believe that this knowledge can build nice template layouts fast. We hope that you agree.

As always, we encourage you to opt-in for the upcoming articles and also share your thoughts and ideas below to make these posts even better.

Email template development guides, tutorials, tools - EDMdesigner Blog

Email Marketing and Mobile Optimization

Content first: Emails must Help Subscribers

Emails MUST Be Easy to Read

Readability

Make it easy to read.

Email Frequency MUST Be Just Right

Conclusion

Your Input

16 Command Examples to Send Email From The Linux Command Line

Setting Up Command Line Mailer Packages

Setting Up Sendmail with SSMTP Package

Sending Email Using the SSMTP Command

Sending Email Using the Sendmail Command

Sending Email Using CURL Command

EDMdesigner Blog

Sending Email Using Swaks command

Sending Email Using the Mutt Command

Sending Email Using the Mailx Command

Using Telnet Alternative Openssl Command

Troubleshooting Mail Problems

Running All Command in a Sequence

Summary

How to Create Responsive Email Designs with React Native

Why React Native?

Create Email Templates using react-html-email Library

Add Responsive Design using Media Query

Optimize Images for Mobile

Responsiveness using MJML framework

Summary

Using PHP for Sending HTML Emails with Mailgun, Sendgrid & Amazon SES

Sending HTML Email Templates Using Mailgun

HTML and Image Attachment with PHP Mailgun API Wrapper

Mailgun Test Email with PHP

Note the attachments as well.

Sending Email Templates Using Sendgrid

HTML and Image Attachment with PHP Sendgrid API Wrapper

Sending Email Templates Using Amazon SES

Sending Email Templates Using the AWS SDK

Amazon SES API For Sending HTML Email Templates

Summary

A Step-by-Step Guide to Sending HTML Email Templates Using PHP

Installing PHP

Sending Email with Built-In Mail Function

Sending HTML Emails with External PHP Packages

PEAR Mail Package

PHP Mailer Package

Getting Started with Composer

Using the PHP Mailer Package

Summary

How to Use a Templating Language in HTML Email Development

Templating Languages

Comparing Templating Languages and ES6 Template Strings

<%= title %>

${data.title}

Modularity with Javascript Template Strings

${data.title}

Defining a Component System for Email Development

Layout Elements

Content Elements

The Benefit of Redefining Such Basic Elements

Complex Components

Summary

CSS Inliner Tools Worth Considering for Your Next Email

Email coding is the best

Setting Up an Automation Tool

Crop Lines with BulletproofLineLenght

Lists in Emails with Bulletprooflist

Managing Full-time Employees at a Growing SaaS Company

The Early Days

SCRUM for the Win

Sprints

Daily Activities

A Few Words about Project Management Tools

The Pomodoro Technique

Summary

Code Generator Tools Used in HTML Email Development

Code Generation Tools

Background Generator

Full Email Body Background Image