Transcript
All right, today I'm going to be talking about building emails 70 times faster with reverse science fiction and Kanye West. For those who don't know me, my name is Adam Brock, and I am a senior front-end developer. This is my first talk ever, and it's going to be riddled with mistakes. I'm pretty sure all the slides are out of order, so join me on this wonderful ride to the abyss. I'll get started now.
I've been an agency developer and designer for the last eight years. I've pretty much been born and bred into the agency way of doing things. I started as a designer, developer, and literally everything else for the first four years, then shifted into development once I realized that design and development were really merging together. That trend has just proven to continue. I'm dead inside.
Previously, I was shouldering the burden of greatness with John in advertising at Leo Burnett. I think half the agency probably had a mental breakdown or two at one point or another, which only led to good things. As you can see, I'm trying to lead a team and work on improving worthwhile things at Tundra. These are some of the brands I've worked on. At the moment, Nike is taking up about 50 to 60 percent of my time, but I've also worked on these brands as well. I have a pretty good idea of how companies work, and on a long enough timeline, they all become very similar.
To give you a quick snapshot of what I do, these have been the last four weeks for me in Nike land. The first project was building a shoe vending machine for the launch of a new React shoe. We built this using Vue.js, Node, and Socket.IO. There were actually people in that space behind a vending machine with a backend filtering out orders and stuff like that. It was pretty cool; I had never done it before.
Then, literally two days ago, we did MX Day, where we created five augmented reality moments using A-Frame, AR.js, and WebRTC. We hadn't done it before, and we had ten days to execute it after I pitched it to Nike in about five minutes as just an idea. They wanted us to do it, and we did that, which was also really cool.
Today, I really want to address agencies. A lot of the talks I've been to feature awesome people from client-side or product-focused companies, which is always great, but I think agencies also need to be spoken for. If there's a show of hands, who's from an agency here? Cool, like a third of you, maybe.
In an agency, there's obviously a need for speed. If you've been in that environment, it can be really intense. Breaks are coming in the morning, and you have to execute by midday and deliver by the end of the day. It can be really time-critical. I want to kick off with this quote from Mad Men: "If you don't like what's being said, change the conversation." You've probably been in a situation where you've encountered a conversation with a client or internally that just doesn't make sense. A lot of the time, it's easy to get complacent and just go along with it. It's kind of folklore to do things the way they were done yesterday, and that's the only reason you're doing it. It seems crazy to me.
I like this snapshot of being able to change things. If you don't like what's being said, I'm going to give a quick example of some of the dumb stuff that I build in my free time at work to help people out. This is an example of an Electron app I built. I found out the producers were spending about three hours manually going through these massive CSVs for email sends. I decided to build this little app for them, which automated their entire process. I took three hours of work down to three seconds with the lazy UGH cartoon.
The reason I built it in Electron was to remove the barrier to entry. I could have easily sent my code and got them to set up a Node server or something, but they wouldn't have liked that. All the producers actually had this saved to their desktop, even if they didn't use it, because they liked having a little egg icon at the bottom.
This is a website that I created in four hours because my agency wouldn't let me post my job ad that I had written. I realized that we were pretty bad at recruiting for about the last 12 months. All the applicants we got in, we just weren't feeling any of them. We realized it was because of the copy we were putting out on my ad. I basically rewrote this ad in the spur of the moment as if I were writing it to my own team. HR wasn't too happy about it; they said I would never post this under Tundra.
My first instinct was to say to my tech director, "Well, it's clear to me we have to start our own agency." What do we call it? I wanted "Agency," but that was taken, so we set up a digital agency called Double-O. You can go there; it's still up if you want to apply. We're still looking.
The ironic part is that in the two weeks after we posted this, we had the best candidates we had had in two years. We had tech directors from a bunch of the top agencies in Melbourne and just a whole bunch of people inquiring, mostly asking if it was a joke. The answer is yes, it is a joke, but we took it seriously. We had a great response from it.
We also hijacked our web directions. I made 300 business cards and put them everywhere. This one was on the desk next to a recruiter, which says, "You're not really my type." The other one was in a toilet, which said, "Down for docking." This was our real recruitment. We had a budget of zero dollars, and again, the return on investment was pretty good.
I'll run through these pretty quickly. You can go to this one as well: "This is Death by Meeting." You can calculate the true cost of a meeting by adding the number of people in it, and it tells you in real-time how much money and time it's costing for everyone. This one's been really popular as well, so you can reevaluate your life while you're in the meeting.
Last one, we have a platform called Ness, which is the Nike email self-service tool. It's built on Salesforce, which is awful. I did this to make the designers' jobs easier. They have to resize these assets every single day, so I made this '90s themed tool called Ness Quick, where they can do this in about 60 seconds.
I'm just going to give you a quick five-step guide of going rogue at work. You can identify a recurring problem by counting the number of times your team mentions jumping out of the window on Slack. Recurring is a really key thing; you just want to identify problems that keep popping up all the time but you can solve. Then ask yourself, "What would this look like if it were easy?" I don't mean a lazy version of that; I just mean if you could come up with a fancy solution, what would that look like?
You want to come up with a science-fiction solution that takes you from zero to one—something that doesn't exist and you'd create, or that's ten times better, not ten percent better. Then you want to reverse it. Decide what to build first and work backward to figure out how you could develop an initial version quickly and make it fun, like I was demonstrating before: execute on an MLP, a minimum lovable product. A good idea in downtime at home, then demo to your team. That's a super high-level blueprint of what I do.
EDMs are public enemy number one for repeatable work in agencies. Everyone complains about these things. I personally find them cool and challenging to make interesting. In 2015, when I first started, EDMs were taking 30 hours to build. It was out of control; they were 100 percent hand-coded, all done manually. Ridiculous.
In 2016, the former tech lead introduced an automatic system. We would get Foundation and align it with this web-based inliner, and then Nike moved to using Salesforce, which kind of threw a spanner in the works. It was just a really uncomfortable process, as I can attest to as well.
In 2017, we switched to this Yeoman generator, which basically generated a boilerplate version of the email. Let's say it saved twelve hours on average. Then we lost half of our front-end development team in a single afternoon, which threw me into a period of trying to figure out where to go next. It basically started a two to three-month period of just trying to rethink everything we were doing and how we could actually not hire any more people and still do all the same amount of work.
In 2018, the spoiler is it's not even the title, but we'll reveal that. Rethinking EDMs or destroying Ness, the Nike self-service tool. We send out a lot of EDMs for Nike; this is why it's such a big thing in our agency and why it deserves some thought. I'm not going to be talking about bridging the gap between design because I think the shortest distance between two points is zero. Similar to what Mark was just talking about, I personally think that the designer and developer mediums should really just be the same thing wherever possible. I don't think it's a good use of anyone's time to redo the exact same thing in two different mediums and keep those in sync, and vice versa. It just doesn't make any sense.
I started thinking about how to do this. Aside from Event Horizon, where I show you how to bend space-time, you go through the space-time in a piece of paper. That's kind of a nice way to visualize it. I realized that emails are really just content. What if I were to build a component-driven content management system so that anyone could design, build, and update these emails? The thing that really drags these down is that they're not that slow to build or to come up with the first version, but the feedback loop can be very time-consuming. It can go through three people just to get the developer to make a change. What if the producer or the copywriter could just log in and do these changes with that design? What if the designers could build these emails without ever needing a developer? That's what I wanted to solve.
Back to going rogue: the question isn't who is going to let me; it's who's going to stop me. It takes a lot of energy to actively stop someone in your agency from doing something. I'll run out of steam pretty quick. They can write a memo; they can tell you what you're doing, but they're too busy with their emails and their busy work to actually have any real fight in them, so I will always win.
I built West, which is the first working email self-service tool, as opposed to the Nike one, which was made by the Brown family, which is my team name. I run the team like a cult; I take all the best lessons from cults and apply them to the team, which has worked fairly well so far.
I'm just going to go through the stages of this endeavor. I'll break it down for you. For the backend, I chose Craft CMS. I really like the CMS. I don't know how many people have used Craft. Any hands? Zero? Yeah, obviously. If you haven't checked it out and you use a CMS in your agency, definitely do this. On a scale of Drupal to good, this is way past good. The content managers and the developers are just on the same level. It's really that good; I'd really recommend it, and the team is really good too. They're an awesome development team behind this.
This is what I built it on. I use Craft CMS mostly because of its component-based model that's built into the core of Craft. It really just seems for using a component-based system. You can basically create emails as you would with any other content. I've created some custom fields, so I've got platforms like Salesforce, MailChimp, Campaign Monitor. We've had recently, so these will change the templates on the fly when you're building. If you need to, which we do often, for some reason we have to send one email to multiple platforms using multiple different services. I can change that in here, and all the templates will basically change those tags and those platform-specific variables on the fly for me.
As you can see here, this is a bit of an example of what it looks like in Craft. You have a list of components. I took the 80/20 approach with the designers, so it basically audited our emails and figured out what the 80 percent of the components were using—sorry, the 20 percent of the components we were using to get 80 percent of the results in head science. We narrowed it down to these, so we can actually build most of what we need to with these components. You can pretty much drag that into the page, rearrange them, all that sort of stuff.
This is a few image components. These images are all getting uploaded to Amazon S3 on the fly, so there's no middle management of assets, which is great. This is the test component; you can change basically anything you want to as a designer, which is really cool. This is just the configuration screen in Craft. I'm using some matrix fields, which are basically repeatable fields with multiple fields, so that's what I'm using to build the components structurally.
Speaking of components, I'm using Foundation for Emails as a base. This is a really solid base for emails. There's no glory in trying to write your own email framework; these guys have done it and ironed out all the bugs. It's great on Outlook. We've added a few extra things of our own, of course, but this is just a super solid base.
The components look something like this. They're using Twig language for Craft, so you can see the spacer component is from Foundation. That's what it looks like; it's just written as "spacer," and you can put a size in there, and that'll give you a vertical spacer in your email. What we're doing is giving each component in the loop effectively a unique ID, and then we're rendering some inline style tags, which later get inlined onto the actual element and also the head tag for the responsive or media query stuff.
This is exactly what the image one looks like. All the image calculations are done in Craft, so you no longer have to manually look at the Photoshop file or Sketch file and check what the dimensions of the image are and get the retina right and change it again when they update the image inevitably ten times before it gets sent. This takes care of all that headache as well.
The loop basically looks something like this. It's just looping through every component in the post and then searching for the relevant component name based on the name of the component handle in the CMS. It simply passes all the data that you put in the CMS and the signs of the platform, so you can put those tags in correctly. It's really simple.
We're also using Sass for most of the styling. The styling inline is just the dynamic styles that you need to get from the CMS, but the rest is just written in Sass. It's a really simple build script just using NPM scripts. I'm using the Inky, which is Foundation's templating transpiler. I'm just running it in here, and you know, it's just come to compile that. Also, Fractal, which I'll run through briefly in a minute.
It's a really simple build script; it just compiles the Inky templates into HTML tables, and you can do it all through the CLI, so it's quite nice. The style guide is a really rudimentary style guide. I'm just using Fractal, which I know if anyone's used before. There's a Twig adapter for it, but it didn't support Inky, so I had to create a new adapter called Twinkie, which is a Twig adapter, so I can render but at the same time in my UI kit.
This is roughly what it looks like. You can see the data attributes that you need through the HTML tab, actually. The structure is there as opposed to the component custom tags we just had up a second ago. Should flick to the view in a second, hopefully. There we go. You can see rows and columns; those are the original tags that we write as developers, and then in Inky, that's outputting the correct syntax of correct HTML.
This brings me to Kanye. Kanye is a plugin that I wrote for Craft, which is the greatest email plugin of this generation. There are a couple of others who have written Gudetama, which is a plugin that basically lets you use the @ symbol for specifying your component paths instead of trying to find out how many levels deep or three components. There's also our Pokedex plugin, which is just a bunch of brand new Twig filters we wrote, and Neo is the plugin we're using to have nested matrix fields.
You can see here I'm basically using the Twig extensions to inline all of that code. Obviously, the code we just saw a second ago was all very loose. This basically runs through it and matches up the CSS to the class names, and it inlines all of that style onto the HTML elements because that's basically how email works. This takes care of all of that; you don't need a Node script to do it. I did that because I wanted it to also be done in PHP, so you wouldn't have to fire up a development environment.
This brings me to the front end. This is what it looks like on the front end. Anyone on my team can log in; they can view a list of all the emails that have been built. You can click on the source button, and this will spit out production-ready code for you. If we produce a nice login, they can grab that, throw it into Salesforce, and it's all done.
You'll see here this is what an email looks like in this example, and shortly you'll see the rendered code. It's going to look quite ugly, but to me, it's beautiful. Here we go. This is what the final version looks like. This is production-ready email. You can see all the styles have been grouped in a massive media query at the top for all the styles that were needed there, but all of our class names have been shortened. You can have way fewer characters in a huge email. All the assets are uploaded to S3, so again, no need to do that manually. This is good to go, basically.
In 2015, we already saw the time it took go from 30 hours to 18 hours to 12 hours. What does it look like today? The answer is we go from brief to production-ready in 10 minutes. I'll just run through what we ended up with. I also recorded—I didn't do it for this talk, but my very first production build using this tool. I screencapped it; it literally took me 10 minutes. I've time-lapsed it to five minutes just so I thought we could play it in the Q&A time.
I'll run through all the benefits and what we ended up with. We got extendable, bulletproof components, which are all Litmus tests, which is the email testing platform. They've all been run through that. But a UI kit, there's no barrier to entry, so anyone can use this. It's hosted on a subdomain just for people at our office to use, so it means a designer can go in here. They're building these in improv now; they don't have to do it in Photoshop or Sketch or whatever they did before, which is super cool.
There's no development requirement. You just go to the website, log in, and start building it out in the CMS, and everyone loves that. The feedback I've had internally is so good; the producers are really into it. All the changes are tracked; we can see who's updating what, what revisions are made, and they can roll back and duplicate. It's crazy; it's really good.
As I said, we can build an email from a blank canvas in 10 minutes. That's literally getting the brief and building it. It takes 10 minutes, and emails that we've already built using a template, we just have to make a couple of changes. We can edit and have it done in about five minutes. From the front end, we've literally got a one-click process to copy out that production-ready code, and anyone can drop it into whatever email platform they've built it for.
The best part about this for me is being in the agency where this is something that happens daily. We're basically getting paid out dividends in time. All the time we save that we don't think about these solved problems, we can actually use that time to build more of these things for other problems that we want to solve in any agency as well. For me, that's the biggest benefit.
This is my time-lapse of building my very first email full production, which we sent out from getting the brief in JIRA to having the code done. It took ten minutes, and I've time-lapsed it to five for the interest of time.