Iterations

I made a point to walk past the Apple Store on the way to work yesterday morning, and while doing, captured the above shot of the line. The store entrance is clear on the other side of the block, and the line snaked around the corner onto Mercer Street, so it essentially took up a whole city block. It’s fun to see people so excited about technology.

In the spirit of the iPhone, which seems to be growing in popularity despite the fact that each release is comprised of a relatively small set of new key features and improvements, I thought I’d talk about some of the small (but hopefully meaningful) changes we have made to the Quirky platform recently.

One of our highest priorities is continually improving the speed of the site. Quirky.com is essentially a tool. Like any implement, is should be an unnoticeable helper, not a hindrance to its higher purpose. In order to make the job of contributing and improving ideas as easy as possible, the site needs to load pages extremely quickly; the more ideas a user can consider/submit in a given amount of time, the better the process works.

If you have been reading the blog (or frequenting the site), you are probably aware that we had a bit of downtime on Tuesday. What we were doing behind the scenes was moving our database from a small Amazon EC2 instance to a large Amazon RDS instace. We have been seeing a steady increase in site traffic, and what this means is more database hits. When you try to query an overloaded database (querying happens when you load a page on the site), it is like waiting in a long line at a supermarket without enough checkouts open. It takes forever, and lines start getting backed up into places they shouldn’t, like the aisles. The only way to solve the problem is to add more checkouts, which is what we did on Tuesday. Our new database should have about 4x the capacity of the old one.

The second change we made related to speed was adding asynchronous processes to the platform. That is a geeky way of saying that we made it so the platform can do some stuff in the background while other stuff is happening. For example, when a user uploads a picture with an idea, we need to do some stuff with it before it is ready to use. We need to create versions of it in a bunch of different sizes for different places on the site (which is slow), and we need to upload all those versions to our CDN (which is way slow). During all that time, if we are doing things synchronously, the user is waiting for the page with his/her completed post to load. If we offload all that work to a different process, however, we can just load up the completion page with indicators that the processing is happening, and replace those indicators with the actual pictures once everything in the background is complete. This way, it is the user’s choice whether to wait around and see what happens, or simply move on to the next task. This pattern works well in situations where the user may or may not care about the result of a particular job, and really, really well in cases where a long running task is completely opaque to the user, like when we need to distribute out rewards to influencers when someone makes a purchase on the site. As much as the influencers themselves may care about this process, the person buying the product really just wants to see the purchase confirmation and get back to browsing icanhascheezburger or Perez Hilton or whatever. The faster buying process equals a better user experience, and the better user experience equals more future sales, and more money for everyone.

Anyway, I hope that sheds some light on what we have been putting our efforts into recently. We have also made numerous other smaller changes (including user requests like comment notifications) that we will be trying to roll out in the next week or so. Please keep the requests/complaints/random observations coming.