Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell. I'm your host and today I'm interviewing Dan Denny. Dan is a front-end web developer at Codeschool.com. Codeschool is one of the largest online code education platforms in existence, really. Dan writes a lot of the front-end code for the main website, but he also writes HTML emails. Now, you might have experienced the pain of writing HTML emails. Dan is going to talk a little bit about how to ease those pains today. Dan's actually creating a course, which we'll talk about a little bit probably in the show as well. And then I'm actually going to talk with Dan a little bit about the conference that he used to be the organizer for, the Front-End Conf. Front-End Conf is still in existence, so you should check out Front-End Conf as well. And of course, you can find Dan Denny. In the show notes, his Twitter account, etc. But for now, I hope you enjoy the interview. But for now, I hope you enjoy the interview with Dan Denny. Hey Dan, welcome to the show. I really appreciate your time coming on the show today. And I think a lot of our listeners will also appreciate your time. Especially because I think a lot of people who come to this show, to this episode, are going to be wanting to know about your... Well, about two main things, which are the two things we're going to focus on. Your experiences with Front-End Conf. And then HTML email. The course that you're building on HTML email. So, let's start out with a little bit of an introduction. What do you do these days? I'm a front-end developer at CodeSchool. And so normally, that would entail working on the site and or some courses. But for the past four or five months, I've been solely on creating HTML emails. And working on content for a course for HTML emails. I probably got one of your emails today. Are you guys, are you working on the Pluralsight emails as well? Oh, no, not yet. Oh, okay. I shouldn't say not yet. I mean, but no, we haven't like talked about doing anything like that yet. Okay. Well, then maybe I didn't get that one. Maybe that one wasn't your handiwork then. But I probably have received some from you before because of CodeSchool. So, for... Any of the listeners who are living under a rock and don't know about CodeSchool, can you give like the 30-second pitch on what CodeSchool does? Sure. So, CodeSchool is an online training site. And we create the ability for people to learn in the browser. So, if you want to learn a new technology, say Ruby or JavaScript, HTML, you can jump into a course, do some video training, and then actually... Do some challenges in the browser. So, you don't have to do any type of local setup to learn a new technology. Wow, yeah. And what's cool about that to me is that it kind of lowers the barrier to entry for people who, you know, don't know how to get like Ruby version manager set up on their local machine quickly. Or like they don't want to commit to the time commitment of getting that stuff set up. And instead, they just want to see, you know, does my brain work with this language or whatever? Yeah, I agree wholeheartedly. Because that's... That's always the biggest challenge for me is that initial setup of getting an app up and running. The first time you actually achieve that is... It's a big accomplishment. Sure. Yeah, and I think it's... There's a lot of tools that kind of help with that barrier to entry. But learning is a different... Like a different part of that. Like we've got tools in the production realm for people who kind of already know how to build somewhat, build an app. But on the learning side, I think there's still like... Most of the readme say, all right, so installation, you know, and it's like going through the compile, you know, all those steps that a lot of people may or may not want to actually take just to get like Hello World in their browser or whatever. Yeah, that's very true. I don't want to take it too far off. But nowadays, you almost have to have some kind of build set up in order to even grab repos from GitHub. It's a really interesting thing. Yeah, yeah, no kidding. So, but you're a front-end developer, right? So... Yeah. But you're a front-end developer, right? So... Like you said, you've been working primarily with emails. But on the actual primary site, you've been involved with some of that as well. Is that correct? Yes. Okay. So I've worked at Coastal for almost three years. And I started doing emails about two years ago. But other than that, we work in a Rails stack. So the .com site is, you know, Ruby on Rails app. We do the front-end development for that using like Sass and Haml. Cool. And then we also have a separate app that runs the majority of our courses. And that is actually an Angular app with a Rails backend also that we work on to actually create the newest courses. Interesting. So what I'm really interested in, and maybe this is not the time to discuss it, but how in the world you guys get the, like, the REPL working in the browser. For, like, something that's not Ruby. Like, I'm guessing that there's some kind of sandboxing that happens to where, you know, you can run an environment in the browser. I'm sure there's a bunch of these things. I'm just not familiar with it, quite honestly. But I would imagine that it's pretty involved to get a secure REPL running a given language for somebody to play around with. Yes. So I haven't actually ever done that. But I do know... I know that it is our biggest technology investment. So anytime that we want to be able to teach a new technology, that is the big upfront cost, both in hours and everything, is just to get that executor running to process that other language. Because it's safety, right? That's the big problem, I'm assuming. Right, yes. Yeah, there's a lot of work that has to go into allowing someone to run code on a server. Sure, yeah. Well, so we won't talk too much more into that because I don't think either one of us is ready to talk about that right now. But what we can talk about is what you are doing there, the HTML emails, which is probably about as complicated as the other. HTML email is just full of painful parts, right? The hard parts and the kind of dumb parts, unfortunately. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. But yeah, I would say that the biggest pain is actually updating. So when you're working with more than one email that goes out for a product and anything changes, that requires a change that has to touch every single file that you have for an email going out. So I would say the biggest pain point is having multiple emails that you can never update them all at the same time. Right. Beyond that, you've got the standard thing. So figuring out a process to write table code and test in multiple clients, those are the other big challenges. That's really interesting that you mentioned updating because I don't really think about that as often as I probably should. A lot of the time I'm thinking about like, oh, how painful is it to write inline styles? And there's tools to help with that. So it's become a little bit easier. I'd be interested to know kind of what your tool set is, which we'll talk about in a second. But the updating is something that I'm so used to being able to do elsewhere that I don't really think about it in emails because so often emails are kind of the afterthought in an application. It's like, okay, well, we're going to build the core functionality. We're going to build onboarding or whatever. And then we're going to tack on the emails at the end. Right. Yeah, that becomes a big challenge. Sure. Are you guys using the built-in mailing system in Rails? No. No. So not Action Mailer? No. Okay. So I heard recently on Shop Talk that you are using Mandrill. What are your other tools that you are using in terms of templating as well as the actual Ruby gems or whatever it is that you're using? Are you using Rails to send your emails at all? The only thing that's actually, I guess, Rails driven would be the API request. Yeah. So we have some like mailer RB files in our app that hook up with the Mandrill API and then fire requests to send off transactional emails. Okay. So you're sending data over to Mandrill and it's kind of filling in the template for you essentially. Yeah. So sometimes like a template might be on Mandrill, but a portion of it is created within our app. And then other ones, yeah, we're just sending along data. Okay. Okay. That makes sense. So what about tooling in terms of like processors or really what I want to know is kind of what your basic workflow is. Because I know, again, on the Shop Talk episode where you were talking with Chris Coyier, you mentioned that you had worked with Jekyll at one point. What are you using now to actually create those editable templates? So the one interesting thing is I almost never create an editable template. Nothing beyond editable, meaning that you could go into the source code on MailChimp or if you have access to the Mandrill templates to change something in there. So I do work locally, but everything that I create is basically like the end product that's going to get pasted into one of the services that we use. And the reason I do that is I want to keep a GitHub repo up to date with all of our emails. So if I'm ever hit by a bus or anything happens. Sure. All of that stuff is easily picked up by anyone else right away. Yeah. So as far as like building them goes, I use, I wanted to use Haml. So I started using Jekyll and then now I use Middleman. And that's because Middleman is like the popular pet project tool amongst the front end dev team at Code School. Oh, okay. Okay. And so that also gives me the opportunity to use PreMailer. So I've been testing that out a little bit. At the lastension, you may have seen the At the lastension, you may have seen the At the lastension, you may have seen the find a different gem for it. Sure. So, and a lot of the time, really, to write an effective email, you don't need a ton of markup anyway. Would you agree with that? Definitely. A lot of it is repeat. Yeah, sure. And I mean, ultimately comes down to this. A good email focuses on a clear and concise singular message. And that's testable, which is the next thing I'd like to talk to you about is testing. But good emails typically have a clear message and they aren't extremely long and they don't have like multiple columns usually. Or if they do, they're very simple columns. It's not like you aren't trying to create a full webpage that you send to somebody's inbox. That's not the goal with an email. Yeah, I definitely agree with that. And it's something that we try to focus on a lot, especially because these are product-based emails. So really our goal isn't for you to stay in your inbox and consume anything. Like if you're running like a typical newsletter, the real goal is for you to take an action from the email, whether that's play a course, check out a new screencast, something along those lines. Sure. Yeah. So that leads me to my next question. I know that there's a lot, I mean, one of the things that comes along with email campaigns, everybody talks about analytics and everybody talks about testing. So there's two different kinds of testing that are relevant to you and me. One is like testing the effectiveness of the email. The other, of course, is just testing whether or not it looks right. Are you guys doing A-B testing? And if so, what are you using to do those? And what kind of A-B tests are you running? Limited amount of that. And that is actually a really awesome guy that I work with on the marketing team. His name's Corey and he does A-B testing, but pretty much just for subject line and or from address. He's able to find a lot of interesting results by testing those two. But the limitation that I've run into so far with the service that we use is that seems to be the only things that you can test. I haven't found a way yet to, to test multiple templates to see how they perform. Sure. Interesting. Okay. And so, so you are doing a little bit of it, but it's mostly with, with the two, what I would say, probably the two most important pieces, which is the subject line. And the reason why that's important is because it's the first thing people see is subject line and from address. And so it's whether or not they open that. And then from there, it's more, it's the, the job of the copy to, to lead the process. And so that's the, that's the, that's the final call to action, right? Very true. Cool. Yeah. Okay. And then, so in terms of testing for rendering, well, first, how many people on average would you say are getting your emails? Typically at this point on Ascend, we're close to 1 million. Wow. So that is, okay. Maybe we should have led with that. That's important. And the reason that's important is because a million emails is like, oh man. So let's talk about this for a second. Emails important guys. I don't know if you know this, but email is important. And the reason email is important is because it still is one of the highest convert converters, right? So people get emails and they click on them more than they do when they just visit a website. A conversion metric for an email is, is generally much higher. And the only thing it falls short to, I believe if I remember all of my statistics correctly is actual physical mail. And maybe it may even be rising on that as well. But the reason email is important is because everybody uses email and it's their generally their primary means of communication, especially for people who are doing code school. Uh, it's very likely that they're going to get a lot of emails. So it's going to be a lot of conversion metrics for an email is generally much higher. And the only thing that they're going to get is a lot of email. So it's going to be a lot of conversion metrics for an email. that they're in their inbox, a large portion of the day. And so having a million emails, I don't know what I could say that's equivalent to, uh, but that is a lot of emails to be sending out. And so you have the ability to do a pretty, I would imagine that you have to test pretty much every single, uh, every single email thing. What is it? Email client, right? Uh, you would think so, but no, I live in like the dream world. Of HTML, uh, email clients. You get responsive HTML email, right? Right. Yes. And, um, fortunately I can test just over like 80% of our opens on all of the equipment I have right in front of me. And that is because with an iPhone and a Mac, I can hit just over like 80% of all of the clients that people are using. That's incredible. So you're talking about, and the reason for that presumably is because most of the people who are on code school are using Mac products or they're using something that Mac has either an emulator or, or what, how does that work? Yeah. So like a large portion would be using Gmail with Chrome. That's a, you know, significant number of our opens. Um, beyond that though, we do get it. The next one's up would be Apple mail and iOS mail. Interesting. Yeah. Wow. And so what that means for you is that you aren't having to do like virtualization, which would take forever. All right. So I do have to, so it's not, it's like the bulk of our people. And so like, this is one of those things that when you start playing with numbers, it's kind of interesting, right? So when you talk about 2%, do you worry about 2% of, you know, something when you're talking about supporting a technology or when you're reaching in the area of like, 800,000, 900,000, a million, that number is really big. When you send that out, like if I send that out, we're talking like 20,000 emails could look really broken if I send out something looking awful in Outlook. So yeah, I do still send, I do still use virtual testing tools. Uh, litmus is amazing for that. Yeah. I was going to ask you if you guys use litmus because I've used litmus in the past and it's been generally, I've had a really good experience with it. And so if anybody is listening to this, I would love to hear from you. So if you're listening to this, and you're looking for a tool, uh, to do email rendering testing, litmus is a good one. Uh, do you have anything actually native on the iPhone or, or another, uh, kind of app on Mac that does this kind of stuff? Uh, that is it. Other than the fact that I have probably four clients on the Mac and six on my phone. Okay. So you're probably testing in like the mailbox and in those kinds of things. Definitely. And that wouldn't hurt my feelings for a long time. Cause I love it so much, but they had some, some issues with rendering early on that have been great. Now they do. They they're great at this moment. So that brings up a good question. What is the worst email client that you're, that you're having to build for right now? Uh, Gmail. Gmail is a killer. Yeah. And so I don't like Gmail alone makes it so that that's the reason why we have to do inline styles. So that's one thing. But then the bigger thing is apps that they put out are just notoriously bad for, for viewing emails and people use them. Lots of people use them. And that is the one where I'll usually get my hate mail from. It's kind of counterintuitive too, because you think like, okay, the maker of Chrome would be like at the forefront of this, of, of, of email or of, I'm sorry, of inbox rendering. Uh, but apparently not. Right. Yeah, definitely not. And it's, it's a big deal. They've, uh, they've put out a couple of posts this year and there's been a little bit of like a social media buzz, like, you know, like fix email and some putting some social media pressure on them to, to fix things. Huh? Interesting. Well, cool. And so I've, I've led up to this because I wanted to wait and, and address the final piece of this, which is that you're creating this course for, uh, for HTML email. And I'm assuming that you're creating it for code school. Is that right? Uh, yes, definitely. Uh, so tell me a little bit about how that's going to, how that go, how that's going to go for people who are listening and might want to take the course. Sure. Uh, so we're going to focus on the basics. It's only going to be talking about like creating a design and hand coding that into inline styles that works across pretty much all of the popular clients. Okay. So above that 80% number, probably. Right. Yeah, no, we're definitely touching the outlooks. Um, the only thing that I haven't really addressed is, uh, Lotus notes. I haven't addressed that in any way. It does still exist. It is still out there. Uh, I haven't ever seen it. And so I, I haven't been able to include that one. Yeah. It's kind of tough to test for something that you can't get your hands on anyway. I think there is a, a, like Litmus might have it, but there is some service that does testing for it, but I just have never even seen it on a chart. So. Yeah. So I have another question. I am so interested in this because it's such a different, uh, a different form of front end development. How do you, um, how might, would, how would you approach the idea of progressive enhancement, uh, when it comes to emails? What can you leave out? And for instance, I know that Gmail doesn't render images unless you click the button that says, show me the images. How does that affect your workflow? Uh, it's like a tug of war all of the time. So, you know, that popular GIF where it's like CSS and he's like pulling on the window shades. Yeah. It's, it's like that. Um, so you, you kind of like you take an inch and then you have to go back and figure out some sort of hack to be able to go that one extra step for one client and then not break things for everything else. And people have gotten insanely creative on hacking the various clients. Most of the known issues are out there. They're documented. And then people have found really interesting ways like targeting WebKit with a media query, just various ways to allow you to do a lot of the fun stuff, but then not break things for the older clients. Very cool. Very cool. So, uh, so this HTML email course, uh, I'm guessing the best way for people to find out about it is just to stay tuned to you on Twitter and probably to code school.com. Right? Yes. We'll definitely make some noise about it for sure. Thanks so much for listening to this episode of Developer Tea with Dan Denny. Of course, the next part of the interview will be in the next episode. If you have any feedback for me, you can reach out on Twitter at at Developer Tea, or you can email me at developertea at gmail.com. Of course, the show notes for this episode and all of the other episodes can be found at developertea.com. And there's also a contact. On developertea.com. If you're enjoying the show, please consider leaving a review and a rating in iTunes. It's the best way to help other developers just like you find the show. Now, not everybody can support the show monthly, but I wanted to extend a thank you to the few who can. Those of you who have decided to support this show, I appreciate your donation so much. If you would like to join them, you can. You can go to developertea.com front slash donate. Even the smallest amount is a huge help. So thank you so much to those of you who have decided to support the show on a monthly basis. Until next time, enjoy your tea.