Information is a medical device

Gibbon + MailChimp + RoR

Gibbon gem + MailChimp + RoR

To satisfy a privacy commissioner’s totally valid concerns we once built a native eBulletin service into a bespoke RoR CMS app. The advantage was that no 3rd party had access to their membership list and everything was handled in-app.

If you are a full stack developer and are thinking of doing this as opposed to integrating with a 3rd party bulk email campaign service here are a few things to weigh before embarking on this. They may cause you to go back and really be sure that the privacy concern is truly valid and a clear peril to your client. Some times the initially stated privacy concern is not as valid as first suspected. The client may be unaware (because you didn’t guide them) as to the necessity and costs vs benefits of a bespoke approach.

The experience we took away from our successful process (we were successful and it did work well and in accordance with privacy stipulations) was that there was a very good reason why there are very few companies offering this service to the public. Its not like with project managements web services where there are a lot of good looking services offered by smart looking start ups… all compelling, all fielding great utility. There are only a few bulk mailout services.

This is usually a clue as to the complexity of delivering the service in question. We suspect the same to be true with online survey companies which we’ve also emulated but that belongs in a separate post.

Here are a few reasons we think there are so few email campaign providers…

  • It’s hard to do,
  • 5 minutes after you are done your work is already old. Mail campaign companies are very nimble.. ‘cause mail campaigns are all they do. Their services update rapidly and out of your site so your product becomes old and you don’t even realize it.
  • eMail CSS is handled differently from Browser CSS. Even a battle hardened CSS pro who knows their way around old IE browser compatibility will be baffled by what different platforms do to their HTML mailouts. Many email apps have their own HTML interpreters. They are not kept up like a mainstream web browser’s HTML interpreter would be.
  • Large mailouts require a back end daemon or you get slammed as a spammer.
  • CRM (Client Relations Management) is a big part of what great mail campaign services do. It’s not just how the mailout looks, it’s can the consumer of your service join in 10 seconds before they loose interest. Server speed and user experience are mission critical and if you can’t match a 3rd party providers slick CRM this will get noticed by the user.

You can pull off making your own eBulletin module if you are good at what you do but in the end it achieves little more than giving your programmers bragging rights that will only impress other programmers. A lack-luster solution for your clients can hurt their interests. This is why on a go-forward basis we are replatforming away from this approach and challenging conventional notions around privacy.

Companies like MailChimp.com are easy to integrate and Rails gems like Gibbon help connect your app to MailChimp.com.


Octopress.org, Jeckyl and Markdown

We are replatforming the EM2data.com site to take advantage of Octopress. What a breeze if you are a Ruby programmer. Octopress is a very nice implementation of Jeckyl.

This is all it took to get up and running…

git clone git://github.com/imathis/octopress.git webapp
cd webapp
bundle install
rake install

# modify your Rakefile
ssh_user       = "yourname@yourdomain.com"
ssh_port       = "22"
document_root  = "~/yourwebapp.com/"
rsync_delete   = true
deploy_default = "rsync"

rake generate
rake preview 
rake deploy

For users without a ruby dev environment… http://octopress.org/docs/setup/


Maybe we will even start blogging and learn markdown.