Posts Tagged ‘tools’
I recently launched a small web site called MyMotivatr, which allows users to quickly and easily create really slick motivational (or de-motivational) posters.
There are several online motivational poster-making tools, but they are usually very poor quality. For example, Despair, Inc has amazing, professionally-designed posters and a “DIY” user submission tool. If you compare the two, the DIY version uses high-compression/low-quality images, uses the wrong typeface (Times), does not drop caps or underline the title, and the description is not in small caps.
Using Flash, I created a tool that generates posters on the client, then submits the pixel data to the server, generating a permanent file. I paid close attention to detail, to make sure the result is as close to professionally-designed posters as possible.
MyMotivatr went live within 24 hours of conception, the maximum amount of time I was willing to dedicate to this particular for-fun project. During the site’s first 24 hours of operation, it received about 9,800 unique visitors, 22,500 page views, and 275 user-submitted posters.
Technology changes the way we do things. The fact that it does is not an astounding revelation. However, it is always fascinating to see how it does.
When we think about “creativity” from a classical perspective, we might picture a person creating a piece of artwork, whether it is a painting, a piece of music, a novel, etc. In the past, creative collaboration occurred on a very small scale, if at all. Today, the creativity landscape is shifting, thanks to the tools we have at our disposal with modern technology. One of the key ways technology has changed the world is communication. This opens the door for a type of collaboration that was not possible before.
How does this impact our view of “creativity”?
Unlike the past, where a creative, highly-skilled individual — or a small group of highly-skilled individuals — would develop a work of art, we can now develop tools that allow millions of people to contribute to a single project.
One example of this is Drawball.com. Drawball, which launched in late 2005, allows anyone to pick up a virtual airbrush and paint graffiti on one giant digital wall. While the majority of users contribute little more than a mess of scribbles, there is a “hall of fame” area that showcases some of the best drawings spotted on the wall.
Another example, though on a much smaller scale, is BrainFuel.tv‘s Caption Contest Fridays (with spin-off site Caption Fridays). Every week, there is a new photo that begs the question “What’s going on here?” and visitors are encouraged to make up a caption to explain what is going on in the photo. It is great to go through the comments at the end of the day to see what the blog’s readers had written.
This concept is fascinating and motivated me to start small, for-fun projects like Crappy Graphs (where visitors can draw their own ‘crappy graphs’) and TwitLibs (where visitors choose words or phrases to fill in the blanks in my sentences). I am constantly surprised by how great (or how terrible) the visitor submissions are.
Crappy Graphs started out as a blog where I drew and posted my own graphs. After releasing the user submission tool that allows users to draw graphs in my design/template, the best visitor-submitted graphs found their own way out onto the internet and now draw in more traffic than the main blog itself. That means collectively, Crappy Graphs’ visitors are funny than the original Crappy Grapher, me.
It is clear to me that none of us are as creative as all of us.
Digg.com is an ideal target for creating instant gratification content. You can come out of nowhere and have tens of thousands of new users in 24 hours. An inevitable woe is the Digg Effect — a sign of success and often the key to server failure.
How do you make 10,000 comparisons of Digg users to the rest of the community?
How do you display 600,000 links to relevant Digg stories in thousands of users’ browsers?
How do you tell 40,000 users where they are located on a map of 67,000 users?
How do you display 15,000,000 Diggs on that map?
How do you do it all on one shared hosted server?
Birth of a Digg Tinkerer
In December, I ran an experiment that required collecting a lot of data on thousands of users. Other parts of the experiment included measuring traffic and Google Adsense revenue during the Digg Effect. I created a little gadget, called “DiggStatus“, where Digg users could type in their user names to see how their Digg usage statistics stack up against the rest of the community. The experiment was much more successful than I had anticipated.
Every once in a while, it’s nice to get away from clients, meetings, deadlines, revisions, and product launches. Build something you want to build. Make your own deadlines. Change your mind — no deadlines. Finish it when and if you feel like it.
During the last few months, I have created a small collection of projects geared toward Digg users. Each is intended to be in itself a one-hit wonder. Get to the front page, get viewed by thousands, then recede into oblivion.
Creating content for Digg is all or nothing. Either it hits the front page and you get blasted with thousands of visitors in a short period of time, or it passes through Digg’s upcoming stories section without a hint of interest.
Creating tools and gadgetry for the Digg front page puts a developer with limited resources in a sticky situation. You have to last through the Digg Effect, or nobody will see it.
Looking into a Broken Mirror
Digg users are accustomed to using mirror sites to view content after the target web server crumbles under the load. Unfortunately, mirrors are only useful for static content. Mirrors can’t learn your application’s recommendation algorithm. Mirrors don’t know the coordinates of users on the map you just made.
As a tool creator, it is imperative to withstand the Digg Effect.
Every K Counts
Look at the amount of data your web server will have to send for every visitor.
If your web site has a layout that utilizes images, jump ship. Set up your to-be-Dugg page outside of your layout. Add color with HTML. Structure your page with very light-weight HTML. A logo at the top of the page can be all it takes to push your web server over the edge. With links back to your site, only interested traffic will be directed to your normal site.
If you require images, find somewhere else to put it, so the bandwidth can be diffused between multiple locations.
With thousands of Digg users slamming your server in a very short period of time, even the simplest database call can be destructive to your server. If you use a framework for your site, make sure you have caching set up so you don’t ping the database for the same data thousands of times just to display the page.
In the tool itself, you need to optimize, optimize, optimize! Database queries add up faster than you may think.
Put Your Money Where Your Mouth Is
This week, I released two tools that utilize a map I generated last weekend of the Digg community.
The first tool allows visitors to search for a user name to find where that user is located on the map. This one required 3 database queries per request — one to find the location of the user, one to count the user’s friends, and one to count the user’s fans. While it was on Digg’s front page, about 40,000 users were requested. The database was therefore queried about 100,000 times. All of this and I didn’t receive any mention of downtime from users. If I had used one more database call, and taken the total up to 130,000 queries, the server might not have been able to handle the load.
The second tool I released this week displays Diggs (votes) on the map in real-time (with a small delay) and placed at the Digging users’ location on the map. In 24 hours, the tool has displayed 15,000,000 of those votes. Unfortunately, there were a few hours that users had intermittent access to my site. Contributing to the overload, the first tool was still getting quite a few hits from Digg, it was featured on the BBspot.com home page as a Daily Link, and there were quite a few StumbleUpon users.
However, despite a little bit of downtime, this one did quite well, thanks to some heavy optimization. It may appear like there are tons of queries going on, with all those icons popping up on thousands of screens around the world. The search functionality in the other tool required 3 queries per request. This tool only required one query per 100 Diggs (though, the tool may at times display over 1,000 Diggs per minute). The results were returned to the client in a compact comma-delimited list, where the Flash front-end would then break the results apart.
Moral of the Story
If you create content for Digg, take a close look at the your page and/or tool’s weight on the server. You need to save every byte you can. You should only contact the database when absolutely necessary.
The Digg Effect should be a sign of victory not a sign of defeat.