Workin' on it. » Email

Links for blackberry’s

Jim — Tue, 27 Feb 2007 01:19:45 +0000

A user recently reported an issue with our emails. The issue being that our links weren’t properly coming through on his Blackberry unit, while links from others looked fine.

After a bit of digging the issue ended up being that:

displayed like this (which is desired on the unit):

While this:

displayed:

Not sure if ignoring links with single quotes is something on all Blackberries – just this unit – or even the way this particular unit is configured… but at least it’s not hard to fix once identified!

Email Signup Usability

Jim — Thu, 22 Feb 2007 04:47:47 +0000

One of our biggest goals at Seeking Alpha is to make it convenient to receive our content via email. A big part of that happens right up front – letting you know it’s available – showing you why you want it – and helping you set things up just the way you like. It’s a constantly evolving process and I’m constantly looking for examples of how others are doing this. Sometimes this means actively seeking examples, but recently an interesting example just kind of hopped out at me. I ran into it while researching a blog post for morecowbell.info. There it was on the front page of smashingpumpkins.com

That’s it – that’s not only the whole page – it’s damn close to the whole site. No worries of explaining to people what they’re going to receive or why they should do it. No need for an explanation of how to use it – if you can’t figure that one out… you probably couldn’t find the site in the first place. Just as simple as humanly possible.

After clicking submit you get taken to a page that requires a surprisingly large amount of data. I count 18 fields of data that they’d like to know about you – that wouldn’t be a terrible amount of work if the end result was a service that was highly customized to just how you like it… but it’s completely not. All the fields are for things like address, phone number, name, etc.

I know firsthand that I would be very hesitant to require such a large amount of data – in fact, it deterred me from signing up.

Be Proactive About Tarpitting

Jim — Thu, 14 Dec 2006 06:05:19 +0000

After a grueling 48 hours of attempting to get back in Google’s good graces regarding email to their domain we are ‘on the way’ to being whitelisted.

The process was aggravating, frustrating, and in the end I learned an important lesson: Tarpitting is definitely something worth being proactive about. With more subscribers everyday there are a number of popular destination domains coming up on the list…

If nothing else, the last couple days has led to a couple valuable URLs to share. Each providers site has a lot of good advice on what you can do to get email to their users and all users in general. These URL’s are what you’ll want once you’re sure you conform to all their criteria and you’re ready to get on the whitelists:

Google (Gmail): http://www.rackaid.com/newsletter/20050906/page4.html

AOL: http://postmaster.info.aol.com/whitelist/whitelist_guides.html

Yahoo: http://add.yahoo.com/fast/help/us/mail/cgi_defer

MSN/Hotmail (not quite as straightforward): http://postmaster.msn.com/Services.aspx#SenderSolutions

Receiving Email with ActionMailer

Jim — Wed, 06 Dec 2006 10:31:19 +0000

This really was a snap.

A nice and simple testing recipe (#68) demonstrates how to read in an email from a fixture in just a few lines and pass them to your processing method (MailReceiver.receive in this case).

def read_fixture(action)
IO.readlines(“#{FIXTURES_PATH}/mail_receiver/#{action}”)
end

def test_something
email = read_fixture(“junk_mail”).join
MailReceiver.receive(email)
# assertions
end

And then a few lines on how to feed it “for real”. and we’re up and running!

The only catch… there was some anger over the parens:

mailman: "|/path/to/app/script/runner Mailman.receive(STDIN.read)"

We ended up escaping them, but according to those directions I just linked to – you can also just quote the call to receive.

Email Formatting

Jim — Fri, 14 Jul 2006 17:24:44 +0000

I’m working on-and-off on an application to send financial web content direct to your email inbox. Over the next couple years we’re going to see a very large conversion as the incredible convenience of rss is generally accepted (and not scary) by the masses, but in the meantime this is really a handy service for many.

As will come as no surprise to those who have attempted this feat themselves: sending html content (with a plain text alternative) has proved to be a real bear.

We’ve had quite a bit of trouble with proper encoding – “Fancy apostrophes” look great in one client but the other inserts gobbledeegook (technical term).

Some issues with css applying correctly – Very very simple and in-line css mind you.

The most recent headache came when emails interpretted correctly in many clients were not looking so hot in gmail (and a couple others). CSS wasn’t applying (at all). Links were coming out looking like (noticing the missing “a href=h”):

Click here to view article

The answer this time? Remove this:
Content-Transfer-Encoding: Quoted-printable
Content-Disposition: inline

The frustrating part is why you must remove that… not sure. As many before me (I’m sure) I am working mostly from examples, in lieu of a true understanding of the intricacies of every spec there is out there on the subject. Just seems like for something like what we’re doing (really quite simple), the answer should be… well, really quite simple

Maybe it would have been worth leveraging ActionMailer outside of the Rails environment after all?