I am a huge proponent of building quick web prototypes. Launching a quick and dirty tool helps guage interest in a new product or service, exposes you to challenges and obstacles you may not have foreseen, and provides real data on usage patterns and user feedback which are invaluable during the conception and design process.

With that background: Wednesday night I saw this tweet from Jason Fried, founder and partner at 37 Signals:

For a not-yet-launched project, I have been working with some new functions in the Twitter API, only days old, that simplify the process of polling for a user’s friends and followers. I thought it would be fun and educational to launch a super-quick using the same toolset, and so  Venn’d was born. Venn’d is a dead-simple tool: given two Twitter users, it calculates the overlap between each of their collections of friends and followers, and presents the results using a Venn diagram. Here’s a behind-the-scenes look at the services and tools I used to build it.

The core functionality of Venn’d is driven by Twitter’s API, specifically the calls to request a user’s friends and followers.

For a quick, “free”, scalable hosting platform I chose Google’s AppEngine. I put free in quotes because eventually you’ll be able to purchase more AppEngine computing resources if you go over the free quotas, but that functionality hasn’t been rolled out yet. Google says that the platform will remain free for applications requiring less than 500 megabytes of storage and generating fewer than 5 million monthly pageviews. Beyond those levels, the expected pricing is:

• $0.10 – $0.12 per CPU core-hour
• $0.15 – $0.18 per GB-month of storage
• $0.11 – $0.13 per GB outgoing bandwidth
• $0.09 – $0.11 per GB incoming bandwidth

The current functionality of Venn’d only required a few of AppEngine’s service APIs: DataStore to record the details of each request (except for Twitter username and password information) and URL Fetch to access the Twitter API. I used my own modified version of a Python REST framework to streamline the code under the hood (can’t find the original source I used at the moment, I’ll update this post if I track it down later). My knowledge of Python is only just passable; the nuts and bolts of Python and AppEngine would’ve been faster for someone who really knew their stuff.

I chose jQuery as the JavaScript/AJAX framework. I typically use Prototype, because of its tight integration into Rails, and thought this would be a good opportunity to learn more about an alternate tool. The jQuery form plugin and validation plugin made it easy to add AJAX validation and submission to the main form. Instead of hosting jQuery locally within the application, I referenced the copy of the library that Google makes accessible through their AJAX Libraries API. Because a signficant number of other sites around the web do the same, the odds that a user will already have a cached version in their browser goes up, improving page load times and performance.

To generate the Venn diagrams, I used the Google Charts API. This made it quick and easy to visualize the overlap between each user’s friends and followers. The designer in me wanted more control over the look of the charts, so I spent a little time looking into generating custom charts from scratch. Turns out it would be a huge pain, and not worth the effort. One of AppEngine’s restrictions is that you have no access the filesystem of the server running your code. Essentially all of the available image generation libraries available for Python presume such access, so you can’t use them. Google recently released an Image API for AppEngine, but it can only handle basic rotate/resize/crop type manipulations, not generating an image from scratch. There are a lot of forum threads clamoring for better image support, so this may be functionality Google provides in the future. I briefly considered using a browser-based solution like SVG or CSS with transparent images, but thought both would be too much effort and have browser compatibility issues. Using an API is always a compromise between the speed and convenience of using an off-the-shelf solution and the power and customization of writing your own code. For a quick and dirty tool like Venn’d, using an existing API was the way to go.

As a small nod towards making the app more viral, I added a “tweet this” link to each generated diagram to make it easy for a user to share the results on Twitter if they wanted to. To deal with Twitter’s 140 character cap, I used the bit.ly API to generate a shortened version of the permalink to each new page.

I make it a point to add Google Analytics from the get go to every site I build. It might not be necessary at first, but having good data on how your application is being used is invaluable as your traffic grows. And check it out! 40 whole pageviews! :)

Finally, a few notes on design. I didn’t want to invest much time or energy into the visual look of the app. I grabbed a royalty-free pattern image to use as the background. For a color scheme, I sampled a few of the primary colors from twitter.com itself using the ColorZilla Firefox plugin‘s eyedropper tool. I test-drove a few CSS typography schemes using Typechart and chose one I liked.

That’s it! The “finished” product: Venn’d