Been thinking about / working on the email design problem for a long time. Email is a great medium with a startling lack of good design tools. Here are the features I look for in an WYSIWYG email builder:

* Drag and drop with common content types. Text, HTML, image, button, divider, social icons.

* Controls for fonts, colors, borders, padding, etc. You don't want to adjust CSS after the CSS is inlined.

* Control over email structure. Most email layouts are a single column or pre-built with a multi-column area. A good editor allows you to add new sections that are single or multi-column.

* Responsive by default. For email this means that multi-column layouts can "collapse" to one column on mobile. So a 3x3 grid becomes 1x9 and the content of each cell isn't tiny on a phone.

* Cross email client compatible. It handle Outlook, GMail and Apple Mail out of the box. This means lots of <table>s, that's just life.

* One-click export to HTML with inlined CSS.

* Image hosting. You can host the images yourself, but most of the time that's an extra step you don't care about.

* Allows for saving and re-editing. It's not fun creating a variation of a template from scratch.

For the last three years, we've been working on our email builder: https://www.klaviyo.com/email-templates. I think it has all of the above.

It's only a matter of time until someone open sources an editor like this or, probably more useful more most people, creates a service that embeds an email editor like this in your app.

It'll be interesting to see how much adoption it gets because I don't think it's the solution most people really want. IMO, something simpler like a Markdown / Bootstrap for email is the real solution -- something that takes a simpler syntax or simple HTML and compiles it into "email compatible" HTML.

The thing that really sucks about email design is that you are stuck with HTML circa the early 2000s. An abstraction layer that took care of those annoying details seems like the real way to go. Curious what others think.

Dealing with actual clients that sends e-mail campaigns, trying to get them to deal with Markdown would be an absolute disaster.

Then again, we have in-house editor similar to this (though less polished), and letting them use that is often also a disaster. We've found that making the templates more restrictive (give them places to type text, but not much more) tends to work best.

I agree 100%, even giving the client access to a simple WYSIWYG editor (think mailchimp, campaign monitor, exacttarget, etc) always end up in a nightmare is mis-aligned and wrongly sized graphics and text. Not to mention what happens on mobile and of course outlook's wonderful rendering.

We build a lot of emails and we don't allow our clients to touch anything. It's something I hate dealing with on all levels but the ROI can be incredible for some business's.

Email supports multiple MIME types, so if someone sends you an HTML email, they should also be converting that HTML into a text representation as well so you can choose (or your email client can choose) which version you want to read.

Converting from HTML to text isn't that difficult, there are a number of open source libraries that'll do it. The harder problem is if someone sends you an email with a lot of images or where the layout of content is important, which is why people typically use HTML, it's much harder to map those aspects to plain text.

They should, but they don't. That's the problem.

Every time I get a crappy text version of an email, I try to contact the company (via email or Twitter) to get them to care about text emails. Usually, I've received encouraging replies. It seems like marketing email services don't optimise text versions and companies don't even realise that. Probably because fewer people care about text versions.

I encourage you too, to send requests for better text emails if you care about this.

I'm sure other people are wondering the same thing, so a quick take.

The problem is not if you're counting one thing (or even 100). The problem is when you want analytics and you want it to scale to 1,000s or 1,000,000s of counters. That may seem ridiculous (who could possibly need that many counters?). But it happens quickly when you say, "How many DAUs do we have? How many from country X? How many using device Y? How many from country X and using device Y?"

Also, to address an idea you mentioned around bitmaps. Bitmaps are great until you have lots of counters and lots of users/things to count. Then the problem is they get very sparse. Imagine user #100,000 does something. You need to allocation 97k of space (lots of zeros behind that 100,000th bit) just to count that one thing. Are bitmaps a good idea? Sure, in a lot of cases they are. The problem is they just break down at some point and that's when these other tricks are really nice.

We need a good feedback mechanism. Of the major forms of advertising (TV, radio, web, mobile), which allow you to respond to the ads? None so far. But I don't think it'll be that way for long.

Facebook? Much as we all love to hate them, they do in fact offer the ability to remove ads from both the right hand side and the feed. I have no idea if this matters, but it is an attempt to allow feedback (at a relatively imprecise level).

If for some reason you can't or don't want to implement webhooks, at least make sure you the GET endpoint for any object has a query param that supports fetching the most recently updated or created objects and supports pagination.

It sounds trivial, but you'd be surprised how many APIs don't support one or both of those features. When you're writing an API it might seem unnecessary to start (after all, who could ever have 1000s of <object>?), but if someone ends up polling your API frequently, having those two features can reduce a lot of unnecessary load for both you and the poller. And, of course, make sure you have an index on the created and/or updated dimensions.

That said, webhooks are terrific. Few things to consider when implementing them:

- Think carefully about the payload you send to the webhook. It's usually a good idea to send some related objects/data because many times when someone gets a webhook payload, that'll trigger calls to your API to get related information you could've reasonably sent them in the initial payload.

- You'll likely want to some way to keep track of errors so if an endpoint starts returning 404s or 500s you have a way to programmatically discard it after X failed attempts.

- In your docs, give sample, "real world" payloads developers can test against. It saves times over creating a RequestBin, pushing there, copying, cURLing, etc. (Remember, you can't set up a webhook to localhost.)

- A nice to have is some sort of retry capability with an exponential back-off. Servers go offline and if they get pushed webhook data then, those messages are lost. You could say, "tough, it's the consumer's responsibility," but if having all the data is important, most people will resort to polling. (Somewhat related, you'd be surprised how often the APIs of some larger SaaS companies are "offline" -- e.g. returning 503 --, so these things do happen.)

You can send a webhook to localhost, just in a roundabout way using one of the local tunneling solutions: http://john-sheehan.com/blog/a-survey-of-the-localhost-proxy...

Great points though.

Ridiculous and sad are the two emotions that come to mind. I've run the Boston Marathon and plan on running again next year (want to re-qualify, but will likely run with a charity anyway). I grew up close to the route and have spent pretty much every April watching family or friends run. It's ridiculous because I don't know how else to describe it and sad because a great tradition is going to change, likely in unfortunate ways, for the foreseeable future. It's just an empty feeling, like memories from the years before will never be possible again.

If you've never run a marathon, and especially a big one, it's a unique experience. Rarely are elite athletes on the same course/playing field with "regular" people and all being cheered on (with no barriers) by residents. Watch any footage and you'll see onlookers almost bump into the fastest men/women in the world (hell, they even give out cups of beer at BC). Talk about feeling close to a community and feeding off their energy, I can't think of anything else like that.

It's sad that something like that has likely changed forever. I hope more than anything in the coming months and years this disruption/incontinuity can be turned into a positive that makes the event even better, that the community will overcome everything that's happened. I'm confident it will, but right now it's just sad.

The pricing will probably change, but the reason we're charging at all is to ensure we can provide reliability.

We're not trying to compete with them, we're using them. They solved the hard problems of delivering email, we're just trying to make it easier to send good looking emails through them.

From the sound of it, I'm guessing they're similar, but I haven't had a chance to use Mandrill's templates. This started as an internal API we created and just decided to open up.

Our templates use a Django-like syntax, which let's you use loops and conditions in a easy to use way. Mandrill's might be the same or better. We done a lot with Django so that feels comfortable.

We're trying to focus on the experience of creating a new transactional or triggered email, so it's easy to go from "I have an idea for an email" to "I'm actually sending it." We use this internally with a simple Python script to send formatted summary emails of product usage each night and it's easy to set up -- write the script to fetch the data, create the email template and you're done.