At work recently, we’ve been exploring the idea of integrating voice and/or SMS into our applications.  Much of what we do has to do with people responding to their physical environments — their neighborhoods and the streets and public spaces that constitute the bulk of our public experience.

So, I decided to take on a small weekend project, to experiment with voice and SMS.  There are several tools that help you do this, including Mobile Commons, Tropo, and Twilio.  For my first experiment, I chose Twilio, as the start-up process was really easy and they have a super well-documented API.  Twilio claims that you can get a voice/sms app up and running in five minutes.

Here are the project goals I was shooting for:

1. Something that can be done over a weekend, ideally in a small enough amount of time not to piss off my family.
2. Something simple and useful.
3. Something that demonstrates the power of connecting a phone experience and a web application experience, seamlessly tying the two together.
4. Something that takes advantage of the native capabilities of a regular phone.  In other words, something that wouldn’t be better implemented on a smart phone.

As the result of this experiment, I’m proud to present Phone Idol, a phone-based online singing competition.  You know, kind of like that other idol thing, but using a phone and with no big prizes.

http://phone-idol.com

Here’s how it works:

• Pick a song you want to sing, and think you can sing well (or at least humorously)
• Dial (718) 775-3384
• Sing your song!
• Go to http://phone-idol.com and listen to your recording online.
• Then, America votes, choosing their favorite tracks through online rating

Looking back at my project goals, I’d say this definitely accomplishes #1, #3 and #4.  It was done quickly, using just the Twilio API and a simple WordPress install, it demonstrates the power of connecting phones to web apps, and it works well using a regular phone.  However, it’s definitely not what I would call simple and useful.  But it was fun to make, and has spurred some more thinking about what’s possible here.

In the spirit of a weekend project, here are the things I didn’t do, but that I think would be cool:

• Identities and account management. Right now, all I know about each submitter is his/her phone number, which I don’t want to publish.  I am intrigued by the idea of web accounts that are bootstrapped and managed by phone only, not email.  One of the next features I want to build is to connect submissions to online identities.  This would be easy to accomplish by creating user accounts based on phone numbers and sending a text with credentials, and could easily connect to existing social networks.  I admit that without this, the site is much less fun than it could be.
• Content management. Right now, there’s very little meta data associated with each entry.  For example, I would like to include the name of the person who submitted it, as well as the title of the song.  Given the phone as an interface, this is bit tricky to manage, but not impossible.  Two ways this could be accomplished:  1) after submission, send the user a text asking them to respond with their name and the title of their song.  This approach would either require multiple texts (expensive) or a special syntax;  2) text the user a login link and their credentials (see Account Management, above) and ask them to log in and update their submission with details.  Neither of these approaches is perfect, and I’m sure there are other alternatives I’m not considering.  However, doing at least something would definitely be possible.
• More social integration. This could be huge on Facebook.  For now I just have standard Facebook and Twitter sharing links, but I could imagine maybe trying for deeper Facebook integration, maybe as a Facebook app.  Out of scope for a weekend project, but maybe worth doing.

And here’s a little bit of info on how it’s wired together:

• Twilio is configured to route calls to (718) 775-3384 to a script at Phone Idol, which produces TwiML, the markup language that serves instructions to Twilio.  You can see the XML output here.
• These scripts are written as a WordPress plugin, so that after the final step in the Twilio workflow, the response data (most importantly the URL to the recording) is posted to WordPress as a new post.  Given more work on account and content management, as described above, I’d make more use of the WP API.
• The website is an adaptation of the Stripey WordPress theme and uses a few plugins, most notably Audio, GD Star Rating, and Sociable.

That’s about it. Now time to tweet out the vote and see if anyone wants to sing us a song….

A few weeks ago, I created a small web app for scheduling project teams at TOPP Labs.  At any given time, we’ve got anywhere between 10 and 20 active projects, so keeping track of it all is difficult, and planning ahead requires a good clear overview of everything that’s happening.

Why create something new? Good question.  Before I started making a custom app, I experimented with a few existing tools.  I started with a basic spreadsheet.  Then, I tried dedicated project scheduling tools like OmniPlan.  While each of these tools got me part of the way there, nothing was exactly right.  Spreadsheets were too slow and OmniPlan was too complicated.  I really wanted to do one simple thing: drag people around from project to project on a weekly basis — including the ability to experiment with different configurations.  I didn’t need to get more granular than “project”, “person”, and “week”, and I needed something that would let me change these parameters easily and quickly.

The inspiration for what I wanted came from my time as a ballboy at the US Open tennis tournament.  At the Open, there are 18 courts, ~300 ballpersons, and 4-5 shifts per day.  At every shift change, a crew of 6 ballpersons is assigned to each court — each team consists of 4 “backs” and 2 “nets”, and the team makeup (ratio of veterans to rookies, etc) is critical.  The staff at the Open manages all this is with a giant magnet board, holding one magnet for each ballperson.  Before each shift change, the staff sets up “crews” by dragging the magnets around the board, grouping them, and finally assigning them to courts.  It’s a perfect system for the job — just the right amount of detail, and highly visual and tactile.

In many ways, that was exactly what I needed.  The result is The Board — a virtual magnet board for managing teams.  Check out the demo to poke at it and the project page for code.  Enjoy!