spugbrap’s blog

Last week, I posted about my observation that, Gmail snippets include ALT text for images in HTML emails.

This information won’t matter to most people. But, I was thinking that anyone sending email promotions/customer service alerts/etc. might benefit slightly from this knowledge. I wouldn’t suggest putting a LOT of effort into it, since I’m sure the number of people who read their email in the gmail web interface, with the “show snippets” option turned on (I think it’s off, by default), is not large enough to warrant it, but it wouldn’t hurt to consider this tip: get right to the point!

What I’m suggesting is to put the main idea of the email in the first line of the message body (or better yet, in the subject line!). Or, at least put a reasonable hint, so the recipient can tell–at first glance–whether the message is relevant/useful to them.

You don’t get very much space to work with, here, so make it count! With my gmail window maximized, in 1280×800 screen resolution, with normal font sizes, I can see exactly 123 characters of [Subject]+[Snippet]. Usually, my window is not maximized, so we’re probably talking more like 80 characters.

I’m not in the email marketing business. I am just an ordinary consumer/geek. But I do recognize that, when reading my email, I follow some predictable behavioral patterns.

If I see a subject from Barnes & Noble like, “Two 25% Off Coupons Inside”, and have been thinking about buying a book/movie/etc., I will probably click it. However, if I see “This Week — Coupons, Anne Lamott, Tracy Chevalier, More”, I almost definitely would not. Kodakgallery.com rarely compells me to click, because they use titles like, “March Gallery Exposure: Winds of change!” Officemax.com and Dell usually mention specific coupon types/values in the subject line, which I like.

Nobody seems to be taking advantage of the first line of their emails, though. Looking through my gmail right now, the only snippets that are useful *at all* are from personal emails, and a newegg.com RMA confirmation (which shows my invoice # in the title AND the snippet, and my RMA number in the snippet). Most of the marketing emails seem to start with things like “Having problems viewing this email? Click here.”, which makes their gmail snippets worthless.

Another reason to get right to the point, with a compelling title and first line, is for mobile users. When reading email on my mobile phone, I would rather not have to scroll through several pages of menu bars, company logos, icons, greetings/small talk, etc. I’d like to see the important information first. If I don’t see it right away, and don’t have a very specific need for the information, I will most likely skip reading that message, and may or may not try to read it on my laptop later.

Brevity becomes extremely important when it comes to sending information (such as bank alerts) via SMS. Bank of America does not know this. Every time I get an SMS alert from them, it’s at least 80% fluff, and usually gets broken up into 3-4 smaller messages by my wireless provider (which, if I was not on a text messaging plan, would cost me $0.15 per message, to receive). I’ll probably post more about that another day.

While checking my email this morning, I noticed something interesting about gmail’s “show snippets” feature. It wasn’t something that jumped out at me or anything. In fact, it didn’t really register in my mind until after I’d already clicked to view the message. The words “Bank of America Customer using a laptop” seemed a little strange. So, I went back and looked at my Inbox again, and saw this snippet:

This seemed like an odd bit of text for an email notifying me that a direct deposit just posted to my account. Sure, I am a Bank of America customer, who usually uses a laptop to access Online Banking. But they shouldn’t know that, so I clicked on the message again to see what they had to say about using laptops.

Well, the message, itself, showed no signs of the word “laptop”, but the large header image in this HTML email had a picture of a laptop in it. That’s when I realized that gmail was probably showing the ALT text for the header image! To verify this, I used gmail’s “show original” option, to view the full message source. Sure enough, the header was made up of several images, each of which had ALT attributes, and the header images appeared before any of the actual message content. The ALT text for the laptop image was, as expected, “Customer using a laptop for Online Banking”.

Apparently, to generate message snippets, gmail strips the HTML out of the message, leaving behind the ALT text from any IMG tags that appear in that code.

That makes some sense, since the ALT attribute provides a textual representation of the image content, for accessibility purposes. However, I’d bet that most of the time, images in HTML emails are not meant to be part of the content… Most of the time, they’re probably things like company logos, navigation bars (linking to different parts of a company’s website), list bullet icons, pictures of your [family member/friend]’s children, etc.

Don’t get me wrong. I’m not complaining about Bank of America’s email header, or gmail’s snippet generation method. I just thought this was interesting behavior. I have a few ideas for who might benefit from this information, and how they might use it, but I’ll have to save that for another post, tomorrow.

This seems like such a simple thing, but I’m really happy to be able to add it to my collection of useful code snippets:

The important part (HTML code snippet):
<form style=”display: inline; margin: 0px;”>

Explanation/history/context:
For years, now, I’ve just accepted (but been annoyed by) the fact that the HTML FORM tag causes some whitespace to display above and below the form contents:

html	screenshot
Form outside table:Text above table <form> <table border=”1″> <tr> <td>table cell</td> </tr> </table> </form> Text below table

One common way of avoiding that whitespace padding is to stick the FORM tag inside a TABLE tag, floating freely without being inside any particular row/cell, like this:

html	screenshot
Form inside table:Text above table <table border=”1″> <form> <tr> <td>table cell</td> </tr> </form> </table> Text below table

I’ve never bothered to find a better way, until recently, when I decided that I didn’t like HTML validators complaining about that. So I searched and found a method of avoiding that whitespace that’s simple, seems to work fine in multiple browsers, and passes HTML validation:

html
Form outside table with style:Text above table <form style=”display: inline; margin: 0px;”> <table border=”1″> <tr> <td>table cell</td> </tr> </table> </form> Text below table
screenshot

[…continued]

So, I decided to try to write a ‘bookmarklet’ (or ‘favelet’ as they’re sometimes called in the IE world), because I’ve been finding a lot of useful ones lately, and I often find myself throwing javascript into my address bar by hand to modify a particular page’s behavior. Before writing one myself, I searched for a while to see if it’s been done already. I wasn’t able to find any javascript code to transform a page of .CSV data into a more readable form (namely, an HTML table). I did find a CSV Converter page, which lets you paste CSV data into a textarea (or upload a file) and submit it to a CGI script, which returns the data as either HTML tables or WikiMedia format. I first tried writing a bookmarklet to submit the current page’s body to that CGI script.

But that didn’t work so well. Part of the problem, from what I could see, is that when IE rendered the page as HTML, the carriage-return/line-feed characters were replaced by a space. This presented a challenge for programatically parsing the CSV text, because now I had to know how many columns existed in the data, so I could figure out where to break the lines, so the table would have more than one row. (My earliest attempts produced a table with only one row, with LOTS of columns)

So, I ended up cheating a little bit, and requiring that the data in the first column on the second row will always be ‘IE’. Other than that, the bookmarklet I created can handle more columnns in the future, automatically.

Right click this link and add to Favorites/Bookmarks

If you’d just like to look at the code, click here to see it in a more readable form.

Well, wouldn’t you know it… this bookmarklet works in IE 5.01, IE 5.5, Firefox 1.07, and Opera 8.5, but NOT IN IE 6.0. The exact same browser whose shortcomings I was trying to work around. (The earlier IE versions also made the CSV == HTML assumption, but at least my bookmarklet worked in those versions). IE 6.0 did not generate any javascript errors when running the script, nor did it pop up its little security warning bar, or any other visible behavior. It just sat there.

I give up. Stupid IE.

To see the behavior (or lack thereof) of the bookmarklets above:

1. right click it and add it to your favorites/bookmarks
2. go to one of the CSV pages (all 3 files are the same–they just have different extensions):
   • MultiSelectPerformance.csv
   • MultiSelectPerformance.csv.txt
   • MultiSelectPerformance.csv.html
3. select the bookmarklet from your favorites/bookmarks list to run the script

Doing this with different browsers will unfortunately yield different behavior. If anyone can suggest how to make it work in IE 6.0, or how to fix it so it doesn’t require ‘IE’ to be the first value on the second line of the CSV file, I’d love to hear about it!

Sooo… I posted that .csv (comma-separated values) file containing some benchmarks as part of my previous post on the performance differences between browsers when populating multiple select boxes in 2 different ways. What I didn’t notice until later, though, is that that file looks like crap if you click the link to it in Internet Explorer. IE seems to make an assumption like “Hmm, it doesn’t have extension ‘.txt’, so it must be HTML!” and it renders it as such. Of course, this .csv file doesn’t contain any HTML tags, so it doesn’t look pretty when IE makes that assumption:
MultiSelectPerformance.csv

For comparison, I made 2 copies of the CSV file:
MultiSelectPerformance.csv.txt
MultiSelectPerformance.csv.html

When I tried clicking the original .csv file link in Firefox and in Opera 8.5, they both behaved as I believe they should. They asked me if I wanted to open the .csv file with the application that is registered in Windows to handle files with that extension, Microsoft Excel, or if I wanted to save it to disk, or cancel.

Screenshots of those dialogs:

It strikes me as odd that IE, with its litigiously tight integration with Windows, didn’t bother to check the Windows File Types list before jumping to the strange conclusion that .CSV is a typo for .HTML. It’s possible that I could change my web server config files so it would send an appropriate ‘Content-type:’ header when .CSV files are served. But screw that, this is a stupid behavior in one browser, and I may want to serve a .CSV file on a web server someday where I can’t touch the config files. I was determined to do something to handle it on the client side.

[to be continued…]