Jun 9, 2010

Time to reconsider preheaders?

I don’t know about you, but I’m personally starting to re-think all my email preheaders.

If you don’t know what a pre-header is, it’s the stuff you jam into the very tippy-top of your email marketing:


Mark Brownlow covers a lot of preheader basics here, and we discuss some design tips for preheaders here and here.

They’re important to have, but for some of my emails, I just don’t think they’re necessary anymore…

For example, the MailChimp Blog has an RSS-to-email list, and I think preheaders are a waste of space in this particular scenario.

I subscribe to a lot of similar "blog to email" lists out there, and frequently check these in gmail (b/c I don’t want them in my "real" inbox), or I check them on my mobile device (so I can read updates while I’m out at lunch and eating alone. Sooooo, so alone).

Recently, I caught a glimpse of one of our messages in Gmail’s inbox preview, and it looked like this:


Gmail is basically grabbing the first line of (machine-readable) content from my message, and displaying that in the preview window.

The problem was that the first line of content was my preheader, which says this:


That preheader text serves a very important function. but it isn’t very enticing in the inbox preview, is it? I normally wouldn’t recommend ditching it for big important campaigns, but my daily RSS-to-email messages are small, useful "tips" and news that people receive so frequently, I think readers would get sick of seeing the "view in your browser" text over and over. By now, they’ve either figured out how to switch to plain-text, or they’ve unsub’d and switched to their RSS reader.

So I removed it entirely, and added our table of contents merge tag above my content slot:


Now, whenever people get my updates in their gmail preview pane, it looks more like this:


On my iPhone, it all looks like this:


Check out the difference between my blog alert, and the Newegg and Old Navy messages. Their preheaders are filled with "utility links" (view in browser, unsubscribe, privacy, etc).

But their subject lines make up for that, and can be changed from campaign to campaign, so it’s all good.

Some messages need good, functional pre-header text and links.

In that iPhone screenshot above, my blog alert and the google keyword alert are daily updates that have the same, functional subject line every time (see why that’s not so bad). So it makes more sense to sacrifice the preheader here to make room for content.

Another option I’m experimenting with is just moving the "View in browser" link down below my TOC.

For example in my latest MailChimp Monkeywrench newsletter, I switched to this format:


Unlike my daily blog alerts, the MonkeyWrench goes out monthly(ish), and is usually filled with a lot more content. Typically 5 or more articles. When there’s that much to read, slight variances in the rendering of my design from program to program can get annoying fast (yeah, I’m talking about you Outlook and Lotus). So I suspect that even people who can view HTML in their email programs just fine might actually prefer to open the email in their browser instead.

That’s why for these newsletters, I’m not going to ditch my email archive link altogether. I’m just moving it below the TOC.