Tonight I checked my email inbox and found about 100 useless emails I didn’t even plan on reading. So instead of just deleting them as I usually do, I went on a marathon unsubscribing spree. This isn’t the first time I’ve done this and I’m sure it won’t be the last. Seeing many different interfaces for unsubscribing in quick succession made it apparent what makes for a good design.
Why is this important? While businesses might not directly care about someone unsubscribing since the unsubscriber is less likely to buy from the business again, it seems to me that making the unsubscription process painless makes a good last impression. This in turn makes the unsubscriber more likely to become a customer again one day or even recommend the business to a friend. To take myself as an example, just because I’m unsubscribing from the promotional emails from an online t-shirt store doesn’t mean I’ll never order from them again.
- Do make it a single click from the bottom of the email (no questions asked, no login needed, no retyping my email )
- If you have different frequency options or types of mailings, make a giant button that gets me off all of them so I don’t have to read all the options
- Don’t make me tell you why I’m unsubscribing (but an optional form after I unsubscribe is acceptable if you really care)
- Don’t make me reply to the email to unsubscribe
- Don’t make me send an email to a weird randomly named email address to unsubscribe (yes I mean you Conde Nast!)
- Don’t make me notice that while your website is pretty, your email system is run off of a cgi-bin folder on a forgotten mainframe. It should be polished and branded the same way you would any of your public content. After all, it’s your last chance to convey the impression of professionalism and trustworthiness to me.
- For god’s sake, don’t send me an email to confirm my unsubscription!
SOCAP12, which stands for Social Capital Markets, was held this week at Ft. Mason, the rehabilitated military base overlooking picturesque San Francisco Bay. It brings together organizations and individuals interested in social entrepreneurship, the idea that you can build a sustainable and profitable business model with a socially beneficial mission at its heart. The company I work for, ThoughtWorks, believes strongly in this idea and its reflected in our Three Pillar Model (originally from Ben & Jerry’s).
While the conference mostly focused on social entrepreneurship in general, I mostly attended the tech-focused sessions.
This past week I attended SF Disrupt 2012, a conference put on by startup news site TechCrunch. Thirty or so startups presented their ideas, many for the first time publicly, to the audience. These were trimmed down to finalists and then a final winner. I only attended the first two days so I missed the excitement of the final voting. However, I wanted to capture interesting ideas I saw while at the conference in this post. This attempts to be more journalistic. If you want more of
a rant my feelings toward its startup culture, see my other post.
Despite its focus on disrupting the status quo, in many ways Disrupt was a reflection of the current culture rather than a message from the avant-garde. For example, the winning startup is solving the First World Problem of being too busy to take your car to a mechanic. However, if you watched carefully there were glimmers of hope from a parallel culture, one building solutions that will truly improve the world.
Preface: I don’t think I need to explain why continuous integration is A Good Thing. If you don’t understand that, look elsewhere for nice explanations.
Continuous integration is a very beneficial process. You integrate with every commit against the other devs working on the same codebase. However, what about your application’s dependencies? What about integrating with the Rails developers? Or the jQuery developers? Don’t the same benefits apply? I’ve been on quite a few teams and it seems like we treat external libraries very differently from our own (or our own organization’s) code. We fit the mold of what the Build Doctor calls “reluctant integrators.” And I think this is actually a really dangerous process to follow, for many of the same reasons that practicing discontinuous integration is a bad idea with your own codebase. It might seem nice and comforting at first, but over the years you’ll end up under water with regard to technical debt.
As an aside, it’s worth mentioning at this point that if you’re lucky enough that your codebase lasts long enough to feel the downstream damage from discontinuous integration with external dependencies, then congratulations. Maybe it’s the short lifespan (planned, anyhow) of most systems that has meant this problem is not talked about as often.
For all of your libraries, you should have a periodic schedule to check for new versions and update to them. The alternative is to postpone and magnify the pain of doing so, in the exact same way it would be for not pulling in your teammate’s commits. But should you practice continuous integration with them, meaning upgrade to every public release?
I spent some time thinking about it and it seems like you should. Commonly, people mention lack of stability as a reason not to. I would then ask why you are using a library that you cannot count on the quality of. Many projects have stable, long-term support or other more conservative packages to meet this need. You can always use those if the developers are a little too experimental for your taste.
When a new version comes out, pull it in. After all, if your build goes red you can always revert.
If you’re looking for my web design portfolio, the only surviving site is Potts & Chapa Construction. Instead, I figured it would be more valuable to post more useful content on this space instead. Enjoy.