Email notifications (also known as transactional email messages) are important to a mailing lists, such as those on OnlineGroups.net. They include the emails that invite people to join a group, welcome the new group members, and inform the administrator that the invitations have been accepted. Notifications are harder to design than a typical Web page because they arrive in an inbox out of context, and must work with a far wider collection of email clients. In this post I will mostly discuss the context problem, because it is the more difficult problem to solve. I will also discuss how I tackled the technical issue of constructing the email message at OnlineGroups.net.
The design of a notification
The challenge for an email notification is to provide context: it has to relate message to the past experience of the recipient, explain why the person was sent the message, and why the person should care.
The From and Subject of the email will be the first thing a person sees of the notification, so they must provide the initial context. Care must be taken with both as space can be highly constrained, for example on email clients on mobile devices.
The From allows us to name the site — such as “Open New Zealand Online Groups” — providing the initial context for the message. However, the From presents some challenges. Consider, who is an invitation from? In our case, OnlineGroups.net sends the invitations, but at the behest of the group administrator, and the recipient probably has a closer relationship to the administrator than to us. However, claiming that the message is from someone with an email address at Comcast, for example, can get a message classified as spam, as it can run afoul of domain-based message authentication, reporting and conformance (DMARC). So we need to consider DMARC before writing the From address.
My goal for the Subject of notifications is to provide enough information that the recipient can decide to open the message immediately, or find the notification later.
- Invitations need to be responded to quickly, because starting discussion in the group may be delayed by people failing to join. The Subject contains the text “action required” to try and emphasise that the recipient has to carry out a task. However, if the invitation looks too pushy then the notification may be classified as spam by the recipient or the email client.
- The Group welcome message (which is sent to a new group member) contains useful information, but nothing that has to be acted on immediately. Instead the subject has to provide cues that allow the notification to be found later, possibly when something has gone wrong and the group member is under considerable stress.
The body of the message also provides context. The notification is designed to look similar to a Web page on the site that sent the notification. This reinforces the relationship that was first made in the From address, and is also emphasised by the name of the site that is written in the header bar section of the message, just like on the Web. Then the subject is repeated, appearing as large text immediately under the header bar, providing a summary of the notification.
To build trust the recipient is then named (if we know his or her name) in the opening salutation. We decided to use a formal “Dear…” to open the notification, because we realise that the main relationship is with the group, rather than OnlineGroups.net.
The rest of the notification differs greatly depending on the message. Normally we present why something has happened (someone has invited you to join a group) and what can be done (accept or decline the invitation); the latter through links to the Web.
The body of the notification ends with the closing, such as
If you have any problems, email us at
The OnlineGroups.net Team
The links to Support, like the one above, are far more complex than they appear. To make it easier for people to write email messages to us each link is constructed to pre-fill the subject and body of the email with details like links to the group, and the profile of the person. Click the link above to see the effect.
The technical construction
The redesign of OnlineGroups.net extended to email, as well as the Web. The notifications that we send out were completely overhauled — in an update far more radical than the changes made to the Web pages. The design was trialled with the topic digests, which were already formatted in HTML. Once we had the design finalised we could then work on the framework for constructing the messages.
The messages themselves are written as HTML page templates, which are laid out by the
gs.content.email.layout library. The page is then styled with CSS, which is sourced from the the
gs.content.email.css library. However, normal
<style> blocks and
<link> elements cannot be used in email — because many programs ignore them — so the
premailer library is used to turn the
<style> blocks into
style="" attributes; this is orchestrated by the the
gs.content.email.base library. The result is an HTML page that can be embedded into an email. (Every notification is also a Web-page that can be linked to, because it makes development and debugging much easier.)
For each HTML-formatted email message there has to be a plain-text version, for people that use email clients that cannot handle HTML (yes, they exist). Because the medium is different the plain-text notification is worded differently to its HTML counterpart. For example, to make the links easier to use they appear on lines by themselves, so the text has to be rephrased to accommodate this.
Once the two forms of the message are generated the standard Python