bialecki

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.

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.

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.

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.

We probably should. You'll notice there's no pricing link in the header. That was our quick hack for this launch. ;)

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.

We're working on it. We wanted to allow for saving, so that's why we ask for an email.

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.

Also keep in mind that learning to "organize your data for fetching" is not necessarily something you can do before you start your project. Many (most?) times you can't predict which data access patterns will be most common and benefit from using Redis, etc.

Starting with a "slower, but flexible" datastore like a traditional relational database, monitoring which access patterns need a boost, and then optimizing or introducing a new datastore is almost always a solid plan of attack.

What about the LinkedIn app? Don't they use a lot of HTML(5) in their app?

Facebook just happens to be a big company that said HTML5 didn't work for them. For all we know they designed it wrong/optimized in the wrong way.

Saying web apps on mobile are a bad idea based on that doesn't make sense.

Oops, misspelled the domain. Thanks for pointing that out.

Very interesting. I started a service like this a few months ago called Add This Script (http://www.addthisscript.com/).

Collecting marketing/ad tracking scripts is just one use case for something like this (although it's likely the most easily monetizable). A host script like this can also manage script (e.g. jQuery) dependencies or provide unified APIs (e.g. a common API for web analytics/tracking usage with the ability to plug in which services you want data sent to).

Also, for anyone saying companies doing similar things are screwed, I actually think the opposite. Google entering this space validates what others are doing and gets people comfortable with the idea of putting all their scripts/tags in one hosted file. There are so many use cases for something like this and Google won't address them all, so there's plenty of opportunity. Google's primary focus will probably be on making it easier to tie together GA, AdWords conversions and other Google products.

EDIT: Fixed link.

I'm torn. On the one hand It's frustrating "major" tech new sites are now feature announcements for selected companies. On the other hand, this is a big problem. I do want a feed of cool new tech, but I guess I'd rather get it from the horse's mouth and decide whether I want to continue to follow or not.

Sorry this is OT, nothing against Snapjoy, I guess I just wish this was on the Snapjoy blog rather than from TC.

Listening to Steve talk, he's very upfront that there is no blueprint for creating a successful business/startup. His advice is not meant to be taken as "here's a list of steps, do them, and you'll be successful." His advice is more like a set of guidelines you'll likely want to pay attention to (or at least knowingly disagree with).

With respect to asking potential customers what they want, he's said specifically that you should do that, but don't take their answer and create exactly that. In his view, there's an "art" to startups that involves taking feedback and turning it into something that's useful. For example, the iPod/iTunes ecosystem wasn't something mp3 player users' would've come up with, but they probably would say, "I want it to be easier to get music my music on my mp3 player" and that's something Apple definitely knew.

There's definitely ambiguity around what you should asking potential customers and I don't think he'd claim there's a right answer about what to ask or not to ask. But it seems pretty likely that talking to people is worthwhile activity.

That said, he also admits there are exceptions to every piece of advice. You could avoid talking to anyone and still be very successful. It's just something he's seen correlated with success.

I'm not sure this is where I remember most of this from, but I think this podcast [1] has most of what I'm paraphrasing.

[1] http://startupsuccesspodcast.com/2012/02/show-134-prof-steve...

Random idea given that the header is "Backlift Blog." Why not make those two separate links that change color/opacity/something on hover where "Backlift" links to the home page and "Blog" links to the blog.

I don't think it'd be confusing and from a usability standpoint it's nice because you know people click the header to get to one of those two places. Since you can't anticipate which their going for, put them side by side and they're very likely to find the answer their looking for. Just a thought.

I just looked at the Spark wiki page[1], and Sizzle is a dependency (although they say it can be removed if you're willing to ignore IE 7). So it is separable, but might not be that small depending on your audience.

[1] https://github.com/meteor/meteor/wiki/Spark

If you go with SQS, keep in mind it doesn't guarantee that messages will be received exactly once[1]. I've used SQS for large projects and this was killer because we had to implement message locking ourselves to prevent messages from being processed twice. Since then, this has been a deal breaker for using SQS again (now use Celery).

[1] http://aws.amazon.com/sqs/faqs/#How_many_times_will_I_receiv...

Real-time is just a feature and it's here to stay. The problem is the amount of data available has exploded and the algorithms to sort/filter that data haven't caught up yet. But they will.

Take, for example, Facebook Top News. The benefit isn't that it's not real time, it's just that the algorithm for deciding what's top news isn't driven primarily by the post timestamp. In the future defaulting to Top News makes sense, but there's no reason that feed shouldn't be real-time. If a close friend gets engaged, I would want a notification about that as soon as possible. But I want Facebook to be smart about when it interrupts me.

The same is true for Twitter's weekly digest. I'd love to have the tweets Twitter picks out in real-time rather than only at the end of the week. I may not want to be notified in real time, but I wouldn't mind if they went in a special list I could browse every day. Basically whatever metrics Twitter uses to decide what are the best tweets for me, I want those applied is real-time, and when a story meets the threshold, let me know.