[Decision Journal] Product Alert Re-build 

This document is an example only and has been made available here as a reference. It’s possible some links to images or external resources might not work correctly. Any comments or activity from others will also be missing.

Overview

Capturing some things learned and/or decisions made while re-building our product alert email templates for use in Blueshift.

Yardsticks

  • [Squad Goal] “Get fully away from ExactTarget and properly leverage Blueshift”
  • Simplify + ensure our product alerts can be created and updated by as many people as possible.
  • Don’t compromise on development best practices (version control, etc)
 

1. Local Dev Environment 

Problem: 
Blueshift provides useful tools to edit code in the cloud however web based code editing is never going to be a good substitute for a local code editing app such as Sublime or Atom. For this reason, and to make local development and testing smoother, easier to manage and integrate with our version control tools (Github) there is a need to ensure we continue to have a local development environment available.
This environment should be:

Simple, no frills, stored in Github
  • Mimic Blueshift functionality and templating structure as closely as possible

Solution:


Eleventy is a simple static site generator that, out of the box, uses Liquid as a means to manage templates, partials, data etc. This is the same language harnessed by Blueshift. Static site generators can be very complex, but in this case I was able to create an environment that, in terms of hierarchy and core paradigms, matches how we will be able to work in Blueshift exactly (aside from some minor syntax differences — where BS uses it’s own proprietary syntax).

All the additional complexity and layers of automation in our previous dev environment, including:

  • Posting assets to Amazon S3
  • CSS Inlining
  • Image size optimisation
  • ‘Inky’ HTML language abstraction

… have been removed in favour of keeping things super lean, super clean. 

In particular, this now means that every line of code in our emails is authored by hand. 

This leads to a huge reduction in code bloat/usability, for example:

 

Re: differences in syntax between local development and BS

When loading a “Shared Asset” (Blueshift speak for component or partial) we can use Liquid to do this locally, so:

{% include header %}

In Blueshift, this changes to the following, however is functionally identical.

<shared_asset> bsft_header </shared_asset>