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.
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.
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.
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.
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.)
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.
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.
If you're looking for another free service that's kinda in between Tag Manager and Segment.io, we built "Add This Script" (https://www.addthisscript.com/) that lets you choose from more than just analytics scripts so you can include jQuery or Facebook widgets and manage that all in one place. We add new services every week or so.
We're also working on some dependency management stuff so you can include jQuery UI and it'll automatically pull in jQuery, for example.
You might want to check out our service, Klaviyo, and specifically https://www.klaviyo.com/features/integrations. We do exactly what you're describing around connecting your data with data from the all services you use. I definitely think it's the future and the future is coming sooner rather than later.
I also agree that metrics are not nearly as powerful if you can't tie them directly to action. Which is why we built our own, fully featured email solution so you can go from metrics, to important people to engagement automatically.
That's where we think things are headed and it's going to be incredibly empowering.
Quick thoughts from an active runner (70-80 miles/wk):
- Figuring out when my shoes wear down is not, IMO, a big problem. I can look at the soles and tell or I know after about 500 miles it's time to switch it up.
- That said, it is incredibly important to switch shoes (or replace soles) when they wear down. I've been fortunate to not run into too many injuries, but I've been hobbled more than once by not taking the time to get new shoes. There is definitely an opportunity for some shoe company online to send me an email every X months with a 20% of coupon for the SAME PAIR of shoes I always buy. I'm sure they could figure out how serious of a runner someone is by the shoes they buy or repeat purchases.
- Now, I might buy one of these to see what kind of data it stores because I believe the future of pedometers/activity tracking is they'll be cheap enough they'll come built into shoes. In 5-10 years I expect to buy shoes that come with a $5 pedometer/tracking device built in and that would be a killer feature. No FitBit to wear, etc., just something that shoes come with. That'll be awesome.
Tangent: One of my favorite classes in college was one that taught physics only at the level of order of magnitudes. It'd tackle questions like: Why is nuclear power more efficient than coal? How much more efficient? and then sought to answer those questions in terms of simple math and fundamental constants.
Considering problems/situations from an orders of magnitude point of view is an under appreciated approach IMO.
Of course the orders of magnitude argument get abused by marketing people (but what doesn't?). That aside, they're extremely valuable for personal or team understanding of the problems and goals.
Sorry, I think there's some confusion (you're not the first person). This tool is just to create the HTML. Our subscription email service allows you to send email, but the email creator is just for creating templates. Basically we took a feature and made it public and free -- our way of trying to make email a little better for everyone.
Create your template, save it, copy the HTML, and do with it what you want.
We're also talking with some email as a service companies about how we can integrate this with their service/app.
I'd be more focused on the personalization database Amazon is building/has built. There will be a market for "I need it now" but the larger opportunity is answering the question, "What do I need?"
Luckily for smaller businesses, they can compete with Amazon and other big box retailers on that front, but they're still learning how to use/leverage the tools the big guys have been using for years.
It's going to get better, this whole thing is still very early. Two things we focus on at Klaviyo to make taking all the data you have more useful:
1. Come up with the questions first, then decide what data you need to answer them. It's so now easy to track every mouse movement of your users that a lot of people just track everything assuming they'll find something useful later. It doesn't usually work that way. More is not better, it's distracting. Even worse, people tend to pick the easiest things to track, which aren't the most useful. If you start from a question and backtrack, it might be more work, but you'll definitely get something useful out of it.
Coming up with question isn't always easy. We're trying an experiment to help people with questions via an analytics/engagement "Cookbook" (http://www.klaviyo.com/cookbook). You pick a question, fill in the variables and then we tell you what to track to answer it. We're still fleshing it out, but that's one idea we've got.
2. Don't look at analytics only in retrospect, use them actively. People don't make most decision at a single point in time, it's about building enough momentum to catalyze action. Because of that, you can do a lot more if you have a way to communicate with them and can effectively leverage what you know to build that momentum. Someone doesn't sign up? When they come back, can you show them content based on what they didn't do last time (e.g. viewed pricing page, but not feature tour...highlight the feature tour). Someone signs up and doesn't get completely set up? Are you sending them an email with instructions tailored to where they stopped and why they might have stopped there.
Related side note: I've gotten plenty of emails after signing up for something asking if I want "help." While it's a nice gesture, as more people send those emails, it gets old fast. Why can't you use what I've done so far to anticipate the questions I might have or give me reasons to get back on the horse?
At least two years ago, most campaigns were using systems built by their respective parties, which were tightly integrated with their own voter databases. Things may have changed, but having a sibling working a big senate campaign this election cycle, I can tell you there's still a lot of room for improvement.
* 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.