API for the World is a sensor and web application that turns anything with a power cord into a networked object. At the flip of a switch you can send a message to twitter, facebook, foursquare, or any other service you define. We did this to fill the gap between old technology and the “smart” devices we see today.

Imagine if your grandmother could use her bedside lamp to communicate with loved ones. When she goes to bed, she flip off her bedside lamp and we get a message to twitter, and can be rest-assured that she’s alright.

We’ve included the ability to define new devices, behaviors, and message through an online dashboard. You can also add new servi
ces with which the application can communicate.

The application uses a current sensor (to tell if the device is drawing power) to send a wireless message to the application, which then pushes a message according to the scenario you’ve defined. For you geeks out there, the sensor measure induction and sends a POST request to a Rails app via an XBee module. The web app then uses the Twitter API to post a message.

We can imagine this app going in a bunch of different directions. You could use it to check into Foursquare or update facebook that you had toast for breakfast. In the scenario with grandma’s lamp, perhaps the lamp could order itself lightbulbs according to when the lightbulb is projected to fail.

We’re working on sensor documentation of the project and an instructable, as well as open sourcing the code. Thanks to TechCrunch and the ITP team for an awesome hack day.

The Team:

• Karla Calderon
• Cameron Cundiff
• Michael Zick Doherty
• Chika Iijima
• Rune Madsen
• Sofy Yuditskaya
• Shahar Zaks

From the beginning, I’ve tried to keep the application simple, not just for the end users, but also for administrators. I’ve done this by using third party API’s to offload data storage and administration to those sites. It means that if you or a customer hasn’t already added your business to Yelp or Yahoo! Local, you can add yourself and show up in Bridge into Beacon.

This approach leverages high connectivity and remote resources to ease the burden on administrators, which increases the initial viability of the application. However, it seems antithetical to the idea of resilience and sustainability. I wonder, in using third party APIs to promote resilience, is Bridge into Beacon past the threshold between local production and global services? What are the tradeoffs, and are they worth it? It seems to me these are some of the same issues facing resilient community advocates. Hope some of you will weight in.

With these points in mind, I plan to make the home screen a list and simple map with markers showing all locations, with three filter tabs: Food, Arts, and Shops. Each tab will narrow the map markers and the list to that category. If the user taps a marker or list item, they will see a details page with the location name, subcategory (i.e “cafe” or “gallery”), address and phone number, and directions from their current location in list form. Preview to come.

WordPress has the advantage of a standalone installation and very strong developer documentation. A standalone package is attractive because it does not rely on third party hosting, and could operate on a local mesh network without internet connection. Ning, on the other hand, is a hosted solution and the documentation is less comprehensive. However, setup is a cinch.

My inclination right now is to prototype a solution in Ning, then create a standalone WordPress package that can be installed on any server. I will probably end up creating custom plugins, especially for wordpress.

I hope that this prototype can serve as an inspiration for Etsy to develop a similar feature, or at least to implement a location search method to their API (this would make it much easier for developers to create similar apps).

Update 12.28.2009
Etsy Around is now Etsy Local. Added geolocation and limited search results to show more recent listings.

The ability to post comments on previous “blips” created an even more asynchronous experience than chat, that was engaging and fun. Also, youtube and image embedding was useful for trolling. My biggest gripe was that running it in firefox on my netbook was painfully slow and my screen could barely accommodate the UI overload. Nonetheless, it felt good to ride the Wave. If they can improve performance and get more people signed up, I would certainly use it more.

After experiencing the AT&T’s tyranny and crappy service, I’m ditching my contract and setting up an array of services and devices to do what I need, with no contracts and at half the price. I signed up for a Boingo wireless for my iPhone, getting lifetime Peek, and exploring Skype, SipDroid, and Google Voice. Right now I pay approximately $85 a month for AT&T service only to get a lot of dropped calls and a rigid contract. I’m estimating that all said and done I’ll be paying about $45 a month (over 2 years), factoring in the ATT contract cancellation fee and the cost of the Peek device. (This all follows a move from Time Warner Cable to Netflix streaming with a Roku box).

These are significant changes, not simply because of the savings, but because it’s even possible. It’s an exciting and palpable reminder that tech startups can effectively compete with massive companies.

The major advantages I can identify for native apps are speed and visibility (in app stores). These are strong arguments for native development. Also, access to the phone hardware, e.g. bluetooth and accelerometer, is possible only in native apps.

We’re creating a prototype for BeeMe using a Ruby on Rails web app, mostly because I’m better and faster with web development than obj-c or Java. In the long run it probably makes sense to create a native version for iphone and android, but perhaps over time we will see a departure from proprietary app stores to web apps, which would bode well for cross platform availability and development.

The tools I explored were balsamiq mockups, Adobe Dreamweaver (templating and libraries), Ruby on Rails, and scratched the surface on Google and Yahoo APIs. Balsamiq turned out to be an excellent tool for initial communication, discovery, and vetting. Ruby on Rails has a steeper learning curve but turned out to be an outstanding platform for high-fidelity prototyping, flexibility, and quick adjustments.

The exercise was useful and enlightening for both parties. Prototyping is an excellent means of product innovation, discovery, and user testing, and bridges the gap between product and engineering teams much earlier in the feature creation process. The result is clearer requirements and a higher level of consensus on feature details when time comes for development.

Big thanks to Etsy for allowing me a lot of freedom and flexibility, and for being so open and responsive to proposals and suggestions.

To help the untold others who feel frustrated with the “technology puzzle”, I’ve created Love the Blog. It will be a home for tutorials, and eventually a forum for people to help one another. One of my mantras for some time has been “Give a man a fish, feed him for a day. Teach a man to fish, feed him for life.” Creating a community will make the site self-sustaining.

The first tutorial outlines how to get a hosting provider and setup a wordpress blog and template to create a simple informational website.