SMS is the data protocol that connects most people in our world. Cheaper in many cases than voice, more reliable when there is iffy reception, accessible from the cheapest devices, they have proven to be a reliable resource from in places as disparate as Katrina and Laos. However many obstacles get in the way of using this as a component in technology solutions. One of them is hosting a scalable infrastructure to manage incoming and outgoing messages, typically requiring custom code and dedicated computers.
This framework evolved from our experiences in the last weeks building the infrastructure for Golden Shadow and surveying requirements for or Mekong Basin program. We are also currently using this as part of our Directory to allow you send position updates via SMS and query nearby friends from your cell phone.
This framework simplifies writing programs that use Twitter to interact with users. Using Twitter's services you can effectively create a worldwide SMS gateway with little effort - as long as the interaction with your app falls within the style dictated by Twitter. Using this framework makes writing the code a matter of programming your bot without worrying about plumbing tasks such as user enrollment, and only focusing on themessages you want to exchange with your users. Advanced solutions requiring SMS would probably 'graduate' from using Twitter as a core component, but using this bot framework allows for fast prototyping and deployment, initiating the design process (For example we took the first cut of our 'Friends nearby' SMS service to Laos and we had tons of feedback after only a day of use - if we had waited to have a full-blown SMS service we wouldn't have learnt as much, as fast, or as vividly).
This project is build on the .NET Framework 2.0 and requires a connection to the internet to interact with Twitter obviously, and a twitter user account to act as the bot itself.
Note: Twitter has become very popular - and understandably the Twitter team keeps a close eye on the scalability impact of having ‘bots' using their API, as bots touch the system more often than people using interactive applications. Twitter therefore enforces limits on the use of their API and you will need to contact them if you want to build bots that run continuously. You can sidestep this issue if your bots don't require active conversations with your users by running your bot logic less often.
Fortunately, Twitter has been very generous and has allowed an exception so a couple of our own proof of concept bots targeting the humanitarian workforce run with less performance throttling. This is something that Twitter manages per bot account and does not come ‘for free' if you use the InSTEDD framework to build your bot.
As an independent, nonprofit organization, InSTEDD discovers, develops, evaluates, and distributes software and other technology-based tools to improve prediction, surveillance, preparedness, and response capabilities for those responding to global health threats, natural disasters, and human-caused emergencies. Visit our website at http://instedd.org.
At InSTEDD we are continuously looking for feedback. Would you like to help us shape our requirements and stories from a humanitarian aid perspective? please visit our forum at http://instedd.org/techforums.