Going Commando

I’ve been explaining the kinds of projects I like to work on and I tend to go back to an old post of Jeff Atwood’s about Commandos, Infrantry, and Police. Briefly, the analogy is to software developers in their role at a projects. The first people in being the commandos:

A start-up’s biggest advantage is speed, and speed is what commandos live for. They work hard, fast, and cheap, though often with a low level of professionalism, which is okay, too, because professionalism is expensive. Their job is to do lots of damage with surprise and teamwork, establishing a beachhead before the enemy is even aware that they exist. Ideally, they do this by building the prototype of a product that is so creative, so exactly correct for its purpose that by its very existence it leads to the destruction of other products. They make creativity a destructive act.

Obviously this aligns well with startup concerns and is where I like to be. Though, this stage doesn’t seem to last too long before you have to consider the infantry-type jobs.

These are the people who hit the beach en masse and slog out the early victory, building on the start given them by the commandos. The second-wave troops take the prototype, test it, refine it, make it manufacturable, write the manuals, market it, and ideally produce a profit. Because there are so many more of these soldiers and their duties are so varied, they require an infrastructure of rules and procedures for getting things done — all the stuff that commandos hate. For just this reason, soldiers of the second wave, while they can work with the first wave, generally don’t trust them, though the commandos don’t even notice this fact, since by this time they are bored and already looking for the door.

I figure this one is what it’s like to be an early employee at a startup. By the time you are hiring you need to start thinking about refining products, tests and all the other stuff I only like to do when necessary. Lastly, there are the police:

These third-wave troops hate change. They aren’t troops at all but police. They want to fuel growth not by planning more invasions and landing on more beaches but by adding people and building economies and empires of scale. AT&T, IBM, and practically all other big, old, successful industrial companies are examples of third-wave enterprises. They can’t even remember their first- and second-wave founders.

These are the kinds of jobs I avoid. These positions tend to be filled with the kind of people who want a great job rather than want to make great software.

In the startup world all developers are basically “commando” or “infantry”. In a way, it’s not enough for a team’s first people to just be infantry, there have to be some commandos in there to really get some shit done and a ball rolling. I would actually worry about hiring someone who’s been doing too many “police” type jobs into a startup at all; you want someone who also codes on the weekend for fun and makes projects, even if they’re pointless, just for fun. When I worked at SAP (definitely a police-institution) I seemed to be the only one who worked on other projects when I got home. Google was different though; people there just seemed to love coding and were grateful to be at a company who gave them the famous 20% time (commando-time).

Everyone likes the idea of a commando-employee. On paper it sounds like you drop one into a project and all of the sudden its up and running in a few weeks. Every now and then you hear about a big company wanting developers that fit the commando description, but they’d soon realize that they couldn’t handle a team like that.  The trouble is, not everything about the commando breed is great. They get bored easy, distracted by other projects, and really don’t like being restricted by any bureaucracy. I’m not even sure how a big company could handle a commando-type.

There’s also an element of project being bigger than one team and that’s why you can’t let these types run rampant. You basically want to avoid the situation that this tweet so geniously explains:


It’s nice having an MVP up and running in no-time, but in the startup world iteration is the key and if you lose your ability to do that you’re done. Not to say commandos necessarily are prone to that, but there’s a reason we have process in software development. If you find a commando who can hammer out something well-structured with tests in short order: do whatever it takes to keep him.

Back in the startup world, I’m not sure whether the best technical co-founder would be a commando himself or just someone best described as infantry who can manage commandos in a way that a non-technical person would never be able to. I’d just avoid police-types. Founders looking for a technical founder tend to get desperate enough that they’d take anyone who can hammer out their app idea, but if it’s not the right type they may not be used to hammer out things quickly as required in startups. There might also be too many expectations in regards to short-term compensation and health-plans.

If you’re looking to recruit commandos for whatever reason, I’d suggest hackathons. That seems like the ultimate commando proving ground where small teams have to make a deliverable from scratch with a small team in a short period of time. It’s a special kind of coding that translates well to the startup world. As tempting as it sounds to have the academic programmer working on neural processing on your team, you need someone who can make a deliverable in a 2 days rather than a model of something in a few years. Hackathons will show you who have this ability.

Speaking of which, IronHacker 2013 coming soon. 

Reddit is Useful When You Unsubscribe From /r/funny

For someone oozing nerd-cred (I’m currently wearing a suit in celebration of PI day), I was actually a pretty late adopter of Reddit and really only got on it once I was working at a job that was sufficiently boring. While people may muse about the core of Reddit being ultra-liberal teenage stoners I suspect it’s actually the easily distracted 20-something working a desk job. In any event, Reddit was “Reddit” long before I showed up 3 years ago and it was generally just the thing you open up in a tab next to Facebook, Twitter, and Hacker News when I wanted to think about something other than code for a while.

When I took the startup plunge those distractions seemed to be hurting my company more than “the man”, so I had experimented with limiting my goof-off time.  I eventually found I could limit my goof-off time on Reddit by unsubscribing from a few of the more time-sinky default subreddits like /r/funny, /r/atheism, /r/politics, and /r/aww.

Over time I started adding subreddits for communities I was interested in. /r/ruby and /r/iphone being the clear ones but more recently I added /r/wordpress. What is interesting about /r/wordpress is that you can actually get insight into problems that people in the community experience. One of the golden rules for startups is to “solve a problem” and I’m starting to see subreddits as a way of gaining insight into a community’s pain points.

There was a post where people were complaining about how discovering plugins from the main WordPress codex was a horrible experience. It got me thinking that the codex is actually pretty easy to crawl and it wouldn’t be hard to calculate a week’s top plugins and which were the fastest moving rather than just the current total number of downloads. A Saturday later, WPplugindex was born. This also has a use for us at Placeling, as plugin discovery is a huge problem we need to solve given our need to get traction for our own WordPress plugin.

The other kick I’ve been on is /r/CrazyIdeas, where people are free to post mostly insane ideas. However, that affordance of it being “crazy” allows people to kick out some odd ideas that they might not otherwise bring fourth if they were suppose to be “good”. There was one where someone wanted a link-shortener which randomly kicked clickers to one of 2 possible links. I saw that and did a “fuck it, I’ll build that” and 2 hours later True5050 was born. I had to stop reading the subreddit after I seriously contemplated making the Shampoo bottle app.

In both cases posting the completed project back to the subreddit got it some initial distribution from an excited user base which is usually the hardest thing about a project. In both cases they were pretty small projects that didn’t require much commitment but it got me thinking that developers looking for app ideas that people would actually use could find users who are excited for an app before it even exists.

The hardest part of a startup is getting your first 1000 people excited about your product and subreddits can be a useful way of getting that if it doesn’t come across as “too marketingish”. Making something people have explicitly requested is a good was of avoiding that charge.

Somebody Make This

Once you’ve taken investor money for your startup you really aren’t suppose to be working on side-projects. The odds are already stacked against you even without the distraction. The trouble is being exposed to the startup world gives you more ideas (some better than others, but most end up being crap once you’ve had 48 hours to think about them) for shit you want made. I keep a note on my iPhone whenever I come up with or hear an idea I’d want made. I thought I’d clear it out a post a few of them:

  • Fake Expensive Receipt Generator - If you’ve seen Rich Kids of Instagram, you’ll know that a favourite Instagram of the 1% is of a really expensive receipt. If you want to be pretend-baller, have something that allows people to generate Instagrams of fake receipts of expensive bottle service or whatever.
  • Apply Dinosaurs to Photos - My friend Miranda has a thing for Dinosaurs and thinks entirely too few Instagrams have Dinosaurs as the subject matter. Even though they’re extinct, I feel like we’re at the point with CG where we can render them on an iPhone.
  • Overhead at App - If you ever hear something notable or quotable at a location you should be able to tag it to the location for others to see/shame.
  • Hashtag Alert App - There’s a few twitter hashtags I want to follow, but they aren’t used frequently enough to warrant a hootsuite column and I just want a digest of them or an alert if they’re used.
  • BabyBook/Babystagram - A special use app for taking baby photos. Since babies aren’t suppose to have Facebook accounts, a parent could tag their and other kids with the app before posting to Facebook. However, more importantly, it would allow people to just block a single app in order to never see baby photos on Facebook again.
  • Group Preferential Ballot App – I have yet to find a simple app that allows a group of people to submit a preferential ballot to reach a group consensus on an action.
  • OnStar for Real Life - iPhone app similar to Siri but with an actual human on the other end like OnStar
  • Psychics as a Service – I’ve never been to a psychic; I think they prey on the weak minded. But couldn’t we have some kind of Skype-esque service to connect people with them and bill by the minute?

Online Startup Communities Need People, Not Money

TechVibes is reporting that Startup Canada to Fall Short on Fundraising Campaign.

Two months ago, Startup Canada set out to raise $100,000 to fund Startup Canada Connect, a national online platform for entrepreneurs to plug into the startup community.

At 11:59pm PST tonight the campaign will end on Indiegogo. And unless a number of $25,000 “Startup Benefactors” step up now, the initiative championed by Victoria Lennox will end far short of its goal.

I’m not shocked. $100,000 to make a what is effectively a website reeks of “community by committee”. The scapegoats for its failure seem to stem from anything from the campaign being ill-timed to Canadians not being big crowd funding backers to general apathy. I have a far, far simpler explanation:

$100,000 is a lot of money for a website that is probably not going to be used.

Asking for $100,000 tells me the organizers haven’t built a website on the cheap and don’t even have one technical person in their non-profit who is passionate enough about this cause to find the time to build this site in his/her spare time (that’s a red flag). If I pitched an online community to an investor and asked them for $100,000 they’d tell me to “get a technical co-founder, then build it, then get some usage, then come back to us”. I’m actually amazed they got over $30k in support already.

I won’t go so far as to agree with one commenter that “people don’t fund useless ideas. end of story.” It’s easy to say an idea will fail; you’ll be correct 90% of the time. The video (which looks like it cost as much as a website should anyway) on the indiegogo page actually identifies a clear problem that they’re trying to solve, which is actually more than a lot of startups have at the start:

So, they identified a problem in that people have a lot of questions they need answers to and need a common place to get answers.  They hypothesized that some kind of online community was a solution, then asked for $100,000 from the community to build it. In a few months they would find out if people would actually use this site, or whether it would become a ghost-town like so many other top-down website approaches (looking at you Made in Vancouver).  This tells me that the Startup Canada people haven’t really taken the whole “Lean Startup” methodology to heart. Which is a bit of a red flag for a group who are trying to centralize startup activity in Canada.

If they did get the $100,000, they could spend it on some overpriced agency to make a committee-driven community and find out in a few months whether people were actually interested or not. My hypothesis is that a simpler solution to the “finding answers to Canadian startup questions” problem is a StackOverflow-esque QA community. Such sites have been around for years and there are many, many software packages that alloy you to cheaply deploy such a solution quickly and costing little more than hosting fees.

But wait, why even go that far? Landing page creators like LaunchRock and UnBounce will give you something to collect emails to see if anyone is interested in your potential solution. For $20 and an hour, you can get webpage up that will show if people are interested in an idea enough to even give an email address. Use those to seed people to the site and you have the start of a community QA site. If not enough people are interested, you’re only out $20 and 2 hours, not $100,000 and god knows how many effort of your staff.

So please, when this indiegogo goes down in flames, let’s not take it to mean that Canadian entrepreneurs aren’t committed or are apathetic. It just means that Startup Canada pitched something not enough of the community wanted.

The Ever Shrinking World of Mobile/Local

For the past 5 months, Placeling has shifted a lot of our focus away from our iPhone app and onto making location-enabling publisher tools like our WordPress plugin. We weren’t seeing a lot of traction on the app, but it turns out we weren’t the only ones. When we launched the app a little over a year ago there were plenty of competitors who were doing something with mobile and local specifically around recommendations, Foursquare and Gowalla being the largest, but since then there has been a lot of consolidation.

At one point there was a lot of apps that would allow you to discover places nearby based on friend’s or other’s recommendations, but none (our app included) had a credible business model and it seems as though Foursquare is the only one left. That being said, I wouldn’t bet on them lasting much longer given that analysts are predicting it will fail by the end of 2013.

I still think there is opportunity in this space.  However, my co-founder was San Francisco last week pitching what we can do for publishers to alt-weekly newspapers (who usually have some of the best local content around, think “best of” listings) and location-enabling their content still seems further down the road compared to their current tech hurdle of increasing CPMs on mobile ads.

Version 2.0 of the Placeling WordPress Plugin

We kicked out a new version of our WordPress plugin today with a few big enhancements.

  • When you activate the plugin it generates a “map” page which shows all the posts that you’ve tagged with the plugin. You can modify this to suit your needs, but if you you’re a food blogger and tag all your posts with our software, your blog readers will be able to navigate your blog with a Google Map. This map will only show blog entries you’ve tagged on your blog and not other locations you might have bookmarked with the Placeling iPhone app.
  • We cleaned up the footers we put on posts. The footers used to link to placeling.com but we changed that to link to the map page shown above to keep readers on your blog rather than sending them off to placeling.com.
  • We simplified tagging a place. You no longer have to add a memo once you tag a post with a location. A memo snippet is automatically generated from any excerpt you have from the post and combined with the tags. It’s a much easier flow.
  • There’s a settings page to authorize/deauthorize Placeling credentials. Credentials are also tied to a whole blog, rather than a user, so admins can link their blog to Placeling and authors can use the plugin.
  • The settings page also has a few nit-picky details about opening new windows and what page the footers link to.
  • placeling.com users will still your posts and drive traffic to your site if our users are looking at a place you’ve tagged.

I’ve enabled the plugin on this blog and tagged this post with Launch Academy, so you can get a sense for how it works. Please let us know what you think!

Special thanks to @teacup for helping me navigate some of the wonkier parts of wordpress plugin development.

My Mom has an Android, My Dad has an iPhone

My Mom has an Android; My Dad has an iPhone. My Mom does not know that she has an Android and my Dad specifically requests iTunes gifts for Christmas because he downloads mountains of apps. My Dad loves trying out new apps and is definitely an early adopter, whereas my mom mostly uses it to text my Sister and I to make sure we haven’t been kidnapped since we last spoke. This is the prism through which I view and news about Android Market Share jumping to 72%.

As an app developer, I want my app to be on as many phones as possible but one has to be careful about using the size of a platform as a proxy for how far an app can spread on a platform. I have a feeling that Android users are simply not as engaged in the platform as iOs users are. Case in point: TNW drops support for Android on their magazine.

To give you some insight in how little uptake we saw on Android here are some statistics: for every Android user that downloads an Android magazine we have 80 iOS downloads.

These are the kind of stats I find far more interesting than how many phones exist on a platform, or even worse, how many apps have been made for each app store. What I want to know for a platform is how many people are going to download my app relative to other platforms. Anecdotally, I also heard how certain social media apps will get 80% of their downloads on iPhone, but companies seem not to give those kind of stats easily. I have a feeling Flurry knows more about this than anyone but can’t say due to confidentiality.

Given what I’ve seen, I suspect people on the Android platform are more vocal than engaged. Still, some of my non-technical friends (important for nerds to have, they’re good mainstream canaries) have been trying out Galaxy S3s and if the platform keeps growing it’ll eventually reach engagement parity.

Trouble is, it’s not like Android is really one platform. People have talked at length about Android device fragmentation, but the OS issue is also a problem. More than half of those Android devices out there are running an OS that is more than 2 years old.

As I was playing with the Android SDK a couple weeks ago, the first thing you get hit with after installing is an SDK Manager asking you which versions you want to install. It’s kind of disheartening when you’re just playing around with it and see how much effort is required to have a great experience on “Android”.

Anyway, we’ve started looking at Titanium in hopes of allowing us to make apps for both platforms, but I’m a little worried that cross-platform solutions force you to the lowest common denominator. We’ll see, it’s at least initially looking good for some of the more basic apps we want to make.

As a Canadian who went to Waterloo, I really want BlackBerry 10 to succeed, but unfortunately  I have to take a wait-and-see approach given limited development time. As for Windows 8, there’s a Microsoft Bizspark guy who comes by the office every now and then and asks us what it would take for us to develop for it, my response was “First off, I need to know someone who willingly bought one.”

Funnel Metrics of a Hackathon Registration Quiz

I love Startup Weekends, but due in part to the success of the lean startup movement, recent ones in Vancouver have become more of a customer development competition.  I don’t have a huge problem with this, given that market challenges are usually more pertinent than product development ones for startups, however, it means that developers are becoming less useful when teams are pivoting every couple of hours.  Also, recent local hackathons have similarly become muggle-heavy with half your team potentially being MBA-types looking for technical co-founders.

As a response to this, I started planning Iron Hacker on behalf of Launch Academy.  It’s meant to be a fairly opinionated event (for which I go into details elsewhere), but one of the key ideas is that it should be a developer-only event.  This becomes an interesting proposition because I don’t want to scare away motivated hobbyists who may not be developers in a professional sense but would gain a lot from the event and could still contribute to a team.  I figured the only fair thing would be to have some kind of online quiz that acts as a “coder filter” to ensure only developer-types get to the registration page.

The quiz is a simple sinatra app that is meant to make sure a candidate has the bare-minimum of coding abilities. Actually, it requires even less ability than necessary to complete fizz-buzz, but I figured it would be enough to scare away non-technical people.  You can see the quiz at the iron hacker page.  It starts as a page of multiple-choice questions most of which I remember from various technical screens I did while looking for jobs, followed by 2 more steps of coding extremely simple javascript functions.  Given that this was the first time I knew of a local event doing this, I didn’t want to put too many barriers in front of people wanting to register.  The javascript functions are run server-side in a heavily sandboxed setup to ensure their correctness

As soon as it was online and accepting registrations, I got a question that I hadn’t thought about, but gave me pause:

It’s interesting because I hadn’t really thought about how many people would actually be turned away by the quiz (bad startup-guy bad).  Since the app has been operating for 2 weeks, I thought I’d check the access logs to see what that funnel looked like so far.

Unique Visitors Retention
Landing Page 366
Started Quiz 266 72%
Passed Multiple Choice Page 153 57%
Passed 1st Programming Page 106 69%
Passed 2nd Programming Page 102 96%
Registered on Eventbrite 22 22%

These numbers are more/less what one would expect. The biggest drop-off is immediately after the first step of the quiz then rises as less technical visitors are weeded out. The multiple-choice portion could be guessed based on just googling the questions, but by the time a visitor has gotten past the first programming question, they are very likely to have the ability to complete the second.

Of course, with any hacker challenge a number of people will try it just to see if they can complete it (kind of like you are, right now), so we’ll likely see a drop-off to actual registrations once a visitor has reached the eventbrite page. Interestingly, someone actually sent the organizers an email noting that our questions really weren’t that hard:

Dear organizers, I am a computing science student and tried your mini pre-registration test for fun. The test was too easy (all the answers can be found online by a single google search), and does not reflect the skill level of hackers at a hackathon. Please consider making the test harder next time to give people a sense of what the actual event will require. thanks and cheers,

The kind of person who would do the quiz for fun then complain that it wasn’t hard enough is exactly the kind of person we would want to attend. I do hope she’ll end up coming. I would make the quiz more difficult, but at this stage the coder wall was meant more to scare away non-technicals than pre-select the “best of the best”. If Iron Hacker becomes a big enough event in Vancouver I definitely would have a harder test, but putting hurdles in front of registration for an event with a venue you have to fill is playing with fire.

Other Things

  • The first step of the quiz had the path “/first”, the second step was named something random, but I put a placeholder at “/second” with a cheeky note for anyone thinking they were clever. Alas, nobody tried to game the system through urls.
  • Plenty of people (mostly pranksters in my office) put in infinite loops in their javascript code. The requests time out after a few seconds to prevent runaway processes.
  • The eventbrite page was also the first place that attendees would see the “early bird” sticker price of $25, which might account for some more of the drop-off.
  • Having this coder wall made it pretty easy to get sponsors who were looking to recruit local developers. It’s one thing to be say “developer only” event, it’s another to say any candidates you get from us will survive the phone-screen laugh-test.

I’ll post a post-mortem after the event, but in the mean time you can still try the coder wall and register for Iron Hacker 2012:

Iron Hacker
Saturday Dec 8th, 2012, 9am – 9pm
Launch Academy Offices, Vancouver, BC
http://ironhacker.org

8 Tips To Help Win a Hackathon

I’ve been to a good chunk of Vancouver hackathons in the past year and have done pretty well at a few. Now that I’m organizing Iron Hacker 2012, I thought I’d impart some of the wisdom I’ve come across in hopes of helping newbies do well if Iron Hacker is their first.

  1. Make a Webapp – As cool as native mobile apps are, they’re hard to get going in a short period of time and you aren’t going to allow a judge to interact with it in a frictionless way. Of course, this depends on the nature of the hackathon, but given the option, webapps don’t require getting UDID’s from judges or a week in the app store approval queue.
  2. Don’t Drink Until You’re Done For the Day – A lot of hackathons seem to lure developers in with “free beer”. Wait until the coding portion of a hackathon is over before you start drinking. I’ve always been skeptical people of people who think they code better with a few drinks in them; you don’t. Hackathons are really intensive and I’ve never seen even a slightly sauced winner at one.
  3. Make Liberal Use of Generators – Generators are in a lot more frameworks than just Rails and you can find generator helpers that do a whole lot more to get you up and running. I’ve had luck using the Rails App Composer for getting an app started very quickly. These take out a lot of the overhead of making models, user authentications, and DB setup. If you can shave an hour off of your development time by blowing through the overhead, you’re in a better position than other teams.
  4. Do The Learning Ahead of Time - Don’t be learning APIs the day-of. It’s not cheating to familiarize yourself with it ahead of time. Also, if you’ve never done something like queues before, don’t let a hackathon be the first time you have to. Development slows down greatly as you hit learning curves for new technologies, so try not to be surprised or use things ahead of time.  Corollary: find a team that is familiar with the same web framework you are; you don’t want to have to learn a whole new framework because your teammates are familiar with another. 3 Rails developers will do a lot better than 2 Django devs paired with 2 PHP devs.
  5. Use Bootstrap – Yes, twitter bootstrap makes all webpages look similar but it still looks better than default html and by agreeing on a layout with your team the pieces can come together a lot more quickly. If you’re really concerned about the common look there are a bunch of sites you can get custom themes on top of bootstrap like wrapbootstrap.
  6. Focus On Having a Deliverable – If you have even a remotely functional app at [whatever].com, you’ll be significantly ahead of most teams at a hackathon. Get the domain for your app early on (nameservers take time to update) and setup something on a VPS, Amazon Web Services, or whatever as soon as possible. Capistrano is your friend for quick deployment if you’re doing a Rails app. Everyone will understand that the live site won’t work perfectly but it takes real guts to tell a room of developers that they can go to [whatever].com and play with your live code.  Judges notice this kind of moxie and there’s a lot more hacker honour in mediocre live code of “what is” than a perfect powerpoint of “what is planned”. Corollary: put your code on github and reference it in your presentation. Hackathons allow us to learn from each other and it has the added benefit of giving the judges an electronic paper trail showing you were adhering to any rules that the app must be made day-of.
  7. Keep Your Scope Small – Hackers have a lovely ability to think they can make pretty much anything from Foursquare to Klout in a weekend.  Weekends tend to be a lot shorter than most devs think and in a lot of cases hackathons are only a day.  When brainstorming the super-awesome Facebook-killer you’re going to make using the Twilio API, keep in mind that your imaginations tend to write cheques your coding ability can’t cash. In keeping with #6, think “minimum viable deliverable”. What is the smallest thing you can have up and running at [whatever].com that demonstrates what you’re going for. After you have that up and running, you can start adding features, but you’ll be amazed at how little you will actually do beyond that.
  8. Do something you’re excited about – It’s going to be an intense day of coding in fairly competitive environment at a time that you could otherwise be playing Halo 4. When brainstorming your app, choose something that excites you, otherwise, you aren’t going to be motivated enough to finish and the temptation to say “fuck it” and take advantage of the free beer might be too great. If you’re sufficiently motivated, you’ll be surprised at how much code you can squeeze out of a human in a day.

 

Implementing Single-click Unsubscribe

It’s hard for a startup to prioritize features which allow a user to limit your engagement with them (our product is the amazingest thing ever? who would ever limit their contact with it?). Naturally, when you start sending your users email, there has to be some mechanism for them to say stop but it takes some development effort to go the extra mile to get one of those super-friendly one-click unsubscribes.

When Placeling started sending out weekly emails with recommendations of nearby places that we think our users would enjoy based on the people they follow in our system, the only way to stop receiving these emails was to log in and unclick the option from our notifications section under a user’s account page. I had thought that only serious “Sheldons” would care about this kind of thing. They only place I’ve ever heard people complain about “more than 2 clicks to unsubscribe being spam” was on hacker news, so I didn’t think that much about it since we were getting a lot of positive feedback from users about how much they loved the emails.

However, it turns out it really annoyed a segment of users. A large segment; tech savvy people and other “zero inboxes” seem to treat when gets sent to their inbox a little more sacredly than a lot of the 20-something non-technicals I know who get a sea of daily-deal reminders and don’t even try to read them all. Also, our app is primarily mobile, so logging into a web page is a friction point to say nothing of how much I love it when I get emails from services with “login to unsubscribe” (looking at you linkedin). So do unto others….

I figured there wasn’t much point in a 2-click (link on email, confirm on webpage) model, as I doubt users accidentally click on tiny unsubscribe link at the bottom of email footers. So we elected on a one-click model (clicking link on email stops emails) where a user is unsubscribed but given an option of re-subscribing after they perform the action.

Googling around for a solution, I came across a stackoverflow page which gave a general idea of how to do it: How to generate links for unsubscribing from email.  The basic idea of this is that you generate a crypto-key for users which you can include in links to perform the action. This link won’t log a user in as that would be scarier from a security point, but for email preferences, its fine.

To do this in our mongoid-back rails application, we first had to add a string field called “ck” onto our user model which would contain the unique cryptographic key for a user we’d use in our links. To create these keys, we add a before_create method to our User object to create the crypto key when a user is created using the SecureRandom library. We set the “n” value of the hex parameter to be 30, but its just needs to be sufficiently long, the method defaults to 16.  From the rubydocs: “The argument n specifies the length of the random length. The length of the result string is twice of n.”:

1
2
3
4
5
before_save :add_cryptokey
 
def add_cryptokey
  self.ck = SecureRandom.hex(30)
end

We’ll also need a migration to give existing users their own cryptokey.

1
2
3
4
5
6
  def self.up
    for user in User.all
      user.ck = SecureRandom.hex(30)
      user.save!
    end
  end

Since we’ll need to search for users based on this key, you’ll want to index it as well. Speaking of which, we’ll probably want a helper method on our model to keep that logic out of the controller:

1
2
3
  def self.find_by_crypto_key(key)
    self.where(:ck => key).first
  end

Now we need to add an unsubscribe action onto our users controller which uses a ck param from a link to actually unsubscribe a user (be sure to wire it up on the collection part of your routes.rb file). The setup you use for determining a users email send preferences will be specific to your app, but we have a “user settings” model with a weekly_email boolean which holds that data for us:

1
2
3
4
5
6
7
8
9
10
  def unsubscribe
    @user = User.find_by_crypto_key(params[:ck])
 
    @user.user_settings.weekly_email = false
    @user.save
 
    respond_to do |format|
      format.html
    end
  end

With this, we can now put a link into the email templates we send to a user giving a link to unsubscribe that doesn’t require authentication:

1
<%= link_to "Unsubscribe", unsubscribe_users_path(:ck => @user.ck) %>

You can follow a similar pattern for a “resubscribe” link which you could put on the unsubscribe page in case users rethink their decision. We also found that the view for unsubscribe is also a great place to try and guilt those who were unsubscribing into resubscribing: