Nicolás di Tada - InSTEDD

Using Verboice with Skype

2013-02-12T15:48:00.000-08:00

A month ago I posted a few tutorials on how to get started with Verboice, our tool to create voice applications (IVR).

The easiest way to test and play with your call flows is to use what we call a "Skype Channel". This will give Verboice a regular phone number from which it can receive and make calls to mobile phones and landlines. The name of the feature in Skype that provides that is called Skype Connect. It supports up to 300 simultaneous calls, so you can use this setup in a real scenario without any issues.

This video will show you how to set this up under your Verboice account.

Verboice Tutorials - Part 1

2013-01-18T14:45:00.001-08:00

For the last two years we have been working hard on a new tool called Verboice to simplify the creation of voice-enabled applications.

Verboice is a free and open-source tool that makes it easy for anyone to create and run projects that interact via voice, allowing your users to listen and record messages in their own language and dialect or answer questions with a phone keypad.

To make it easier to get started, I created a few simple videos.

How to setup an account

How to create a "Hello World" application

In this video you will see how to use the "play" command.

How to create a "Health Tips" hotline

This video will teach you how to use the "menu" command and provide options that your users can press in their keypads to navigate your hotline.

I'll try to find time to create a few more videos to showcase the rest of the features (which are plenty!), but hopefully these will get you started.

Please join our discussion list if you have questions or you want to suggest ideas or features.

Truebites wins Ashoka Changemakers' competition

2011-11-29T11:10:00.001-08:00

We are happy to announce that Truebites is one of the winners of the Ashoka Changemakers' competition Citizen Media: A Global Innovation Competition, sponsored by Google. Truebites aims to create a platform that would allow everyone to participate in the curation, validation and creation of news stories, without a centralized entity deciding what gets published or not (read more here and here).

We wanted to thank everyone for their votes and support. There were almost 500 entries from all over the world and we were already proud to be selected as finalists by the impressive judges panel:

	Esther Wojcicki Vice Chair, Board of Directors, Creative Commons
	Isaac Lee President, News, Univision
	Jared Cohen Director of Google Ideas, Google
	John Lilly Partner, Greylock Partners
	Justin Arenstein Publisher and CEO, African Eye News Service (AENS) and HomeGrown Magazines
	Michael Maness Vice President/Journalism and Media Innovation, Knight Foundation
	Sanjana Hattotuwa Founding Editor, Groundviews

We would also like to extend our congratulations to the other 3 winners:

FreedomBox: An integrated package of security and privacy tools to protect voice and text communications.
CrowdVoice: A website for tracking and curating voices of protest.
5th pillar: A set of tools for empowering citizens to report corruption by SMS, phone or email.

It's nice to see how well all these tools could be integrated and leverage each other. I hope we'll have the chance to work together.

In the next few months, we will use the prize to build a free and open source prototype of Truebites and start involving the community to take this to the next level.

Thanks everyone again!

Verboice - Listen and respond to the voice of your community

2011-11-01T11:44:00.000-07:00

Verboice allows you to use the power of voice to improve health, safety and development. Verboice is a set of free and open source tools that we have been building with the goal of dramatically simplify the development of Voice-based applications. It allows organizations and communities to build their own Interactive Voice Response (IVR) applications using the infrastructure and skills they have available.

Why would we build such a thing?

During the last few years, we have been working in many SMS-based projects and we've built an SMS service to support the applications we built and to make it really easy to develop new ones. However, during that time, we saw the need to go beyond SMS.

We have designed low-tech solutions for some of the problems we faced, but eventually we decided we needed to start working with voice. By "voice" I mean being able to setup information applications that can make or receive calls from users and allow them to interact by listening to options, pressing keys in their phone keypad and recording voice messages.

Voice is almost ubiquitous and character independent (it doesn't matter if your phone doesn't support your language alphabet, you can always speak and listen to your own language through it), therefore making it a much more applicable solution for several contexts.

At InSTEDD, we work in an agile way by building things quickly and trying them out with the people who will be using them as early on as possible. We emphasize simplicity and scalability throughout this process. We wanted a tool that would give us for Voice applications the same flexibility, scalability and simplicity that we already had for SMS applications.

Why couldn't we use what was already out there?

There are lots of voice-based tools out there, some free, some open-source, some cloud-based, but after spending some time reviewing our options, we couldn't find the kind of solution we were looking for.

Here's a look at some of the existing tools:

Tropo

Tropo is a great web-based service that allows developers to build and run Voice applications. Tropo was a great solution for some of our scenarios:

If we were working in one of the 40 (mostly 'developed') countries they have numbers for
If we had internet connectivity between our customer infrastructure and Tropo
If we didn't need to use any local telephone company infrastructure
If we didn't need our customer to be able to create or modify their application themselves

However, in several situations it would not work for us:

If there was no support for the country we were working. Most of Latin America, South-East Asia and Africa are not supported.
If we needed to connect our customer infrastructure-databases, existing systems, etc.-with the Voice application, and there was no access to the Internet. Tropo runs in the cloud, so anything you want to have interacting with it, needs to have internet access.
If we had to work within the infrastructure of a telephone company and connect to their telephone lines. Tropo provides their own phone numbers with their own billing. In most of the large-scale scenarios we've seen, the project involves an agreement with a telephone company that provides the 'call-termination' and, if you are lucky, a reduced cost for the calls. That scenario cannot be supported with Tropo
If we wanted our customers to be able to build their own simple Voice applications or maintain the ones we designed for them. Tropo requires you to have a software developer to build the app for you. There is no graphic user interface to do so.

Additionally, we hoped we could have a fully open-source and free solution. Though Tropo has released some of their platform as open source, most of the core components were branched in mid-2009 and have not been updated or maintained since then. We spent 2 weeks trying to install our own Tropo server and though their tech support was extremely responsive, we could not make it work. We need something simpler for our projects.

Twilio

Twilio is another Voice service, very similar to Tropo. The same of the above apply to this alternative, with the aggravate that Twilio only provides numbers in U.S. and Canada.

Asterisk and Freeswitch

Asterisk and Freeswitch are 2 great open source projects with incredible communities and support. Both are similar in features, and provide PBX capabilities. The role of a PBX was performed (and still is in most of the situations) by a gray box sitting in big offices with all the incoming phone lines on one side, and all the extension lines on the other. The PBX provides services like connecting incoming calls to extension, voicemail, out of office messages, and the like.

Almost anything-voice can be built on top of Asterisk or Freeswitch. The issue is that both require a highly specialized programming knowledge and are far from simple to deploy, configure, use and maintain. However they provide an incredible range of support for great hardware to connect your phone lines (and that's why we support them in Verboice. Read on!)

Awaaz.De

Awaaz.De is a relatively new open source voice message board. It allows people to call to a number, leave voice messages and listen to others' messages. They provide a hosted-service in India so you don't need to have your own phone lines or infrastructure if you are working in that country.

Awaaz.De is an example of the kind of development that we aim to simplify a lot. The system was built on top of IBM tools (Spoken Web, WebSphere Voice Server), requiring not only access to proprietary commercial software, but also a skilled team that can develop the application on top of it.

Freedomfone

Freedomfone provides an easy way to build interactive voice menus and polls. It is another great example of the kind of applications you could build on top of Verboice very easily.

Freedomfone was built on top of Freeswitch, the Open Source PBX mentioned above. Creating applications on top of Freeswitch or Asterisk requires access to a skilled software developer with knowledge of how to install and configure the system, plus knowledge of how to develop applications on top of them.

Freedomfone is great for small-scale deployments, as you don't need an internet connection and it can run on your own server. That is also the downside: you need your own server, plus a hardware device that you use to put the SIM cards that will be used to make the phone calls. There is no way to connect it to Voice-over-IP lines or more "enterprise-like" infrastructure.

So what are we building?

Our solution is composed of several layers. When you use one of the outer layers, you don't see or care what's below. If that layer is not flexible enough for your needs, you peel that one and use the one beneath.

Starting from the outer layer and going down, we are building 6 layers:

1-A Web graphic user interface for building simple voice applications

This tool will be hosted online, and you will be able to build simple interactive voice applications, by visually configuring the steps in your account. There is no need for a software developer or a server at this level. For now however, you do need a Voice over IP (VoIP) phone line provider. We will put together a list of recommended providers in several countries and would gladly help you find one in your country.

If VoIP does not work for you, you can always download Verboice to your own server and connect your phone line to it. In this case, you still don't need a software developer as you would still be building your application visually, but you'd need somebody that can install and configure the server.

This tool will support the most common voice interactions and provide great flexibility, while still being simple to use.

This are some of the steps you can include in your application

2-A script-hosting web server.

If you need more flexibility to build your application than what the graphic user interface provides, we support two XML-based voice standards: Twilio Markup Language (TwiML), VoiceXML.

Those XML languages allow your developer to easily script a complete voice application. You don't need your own server, you can still upload the script to ours and run it from there, but you do need to provide your VOIP phone-line.

As with before, you can always download and deploy this to your own server and connect your phone lines to it.

3-A web service that allows you to program your own custom applications

If the script is not enough and you have a willing software developer, you can use our web programming service to power your voice applications. The good thing is that your developer can work in the language of his choice, .NET, Java, Ruby, PHP, Python, etc. anything can interact with our web service. This way you can have your Voice application interact with any existing database or system you already have in place.

This is the level at which you would use Tropo and Twilio.

Again, if you have your own server, you can host your application plus Verboice there, and avoid requiring an Internet connection.

4-A library to interact directly and synchronously with Verboice

If you still need finer control and don't want to rely on your application communicating with Verboice through the internet, you can have it interact directly through code with Verboice.

5-An open source and free voice engine

All of the above is open source, as well as the core component that powers the Voice functionality. In case you are doing something extreme or there are features we don't yet support, you can always modify the source code and adapt it to your needs. We'll gladly welcome your contribution!

6-A pluggable call-termination backend

If you are still reading, it's getting more complicated here. If none of the above has answered how to have your users call to your application, this is where you can might find an answer. Verboice is built "PBX-agnostic", meaning that it can sit on top of anything you have receiving or making the phone calls. We've built support for SIP phone lines (the VOIP standard), Asterisk and Freeswitch. Those last 2 cover a great deal of hardware options.

If you are working with hardware that is not supported by Asterisk or Freeswitch, and VOIP is not good for you, you can always build your adapter to whatever infrastructure you need to use, or you can contact us and we'll build it for you!

Examples

We've built Watchfire on top of Verboice. Watchfire was originally developed for the Red Cross with support from Cisco to help them recruit volunteers, but can be used for any geographic-based, massive yes-or-no confirmation by people. Read more about Watchfire.

Together with PopCouncil, we have been awarded a grant to take clinical screening to women in the critical period before and after birth. "Baby Monitor" will be built on top of Verboice.

Next steps

We are working hard at completing and improving all the components described above, while we learn from the work on our current Voice projects. Get in touch if you have questions, ideas on things you would like us to build or support, or a project you would want Verboice for.

A New Kind of News?

2011-10-12T16:09:00.000-07:00

Yesterday
During most of the traditional journalism era, reporters would collect information and facts, somebody else or the same person would write the article, an editor would correct a few things and maybe ask for more details and then the news would be out for the masses to consume it.

Today
In the the last few years, new technology tools have enabled what came to be called "citizen journalism". Anybody with the will and access to some gadgets and a regular internet connection, can now report what they see and share it with others. Depending on how good the skills and materials of the person are, their audience can be as big or bigger than the average mainstream media. Popularity is not limited anymore by the access to media such as print press, a TV channel or radio station. Anybody (mostly) can have a voice.

Some organizations in the traditional world of media have leveraged this new trend by using materials contributed by citizens and having them be their 'eyes' in the scene. The process of curation, verification and edition is still in the hands of the organization.

At the same time, several tools have allowed groups of citizens to collaborate and contribute to a repository of information, be it opinions, reports of violence or issues they've seen, quantitative data, etc. but still, the process of curation, verification/validation and editing is done by a 3rd party, be it a single individual or a group or people.

In both scenarios, only the collection of information has been decentralized and distributed. The true act of making meaning and understanding what's going on, is still a process that takes place in a controlled and centralized environment.

Tomorrow?
Think about the typical process for reporting a story or an ongoing event. There is a team of reporters, some stringers, maybe a few informants. Then there's the journalist that collects all the pieces and puts the story together and the editor that ask for clarifications or further details and then the process of dissemination of the news. Now think about how would it be if everybody in that team could switch their roles as often as they want, the journalist could be informant, the stringer an editor and the editor a reader. Take it even further, think about all of them doing all of that at the same time. Now suppose they don't work in the same building, maybe they don't even know each other. And now imagine they are all in different places, some are in the field, others in a office, some have access to mainstream news, others are disconnected from it but participating in the event in real time.

How would it be to have the complete act of journalism distributed among whoever wants to participate?

But even more important, could they possibly come up with a story that made sense?

Around 1910 the cubism movement thought there was something wrong with the way everybody was painting. Things were represented from a single perspective, the truth that was being transferred to the canvas was only capturing one side of the reality. It was fractional by design, incomplete by definition and ontologically false as a conclusion.

Juan Gris: Mann im Café, 1914.

Cubist painters, attempted to present objects by condensing all the perspectives at the same time. A story goes, they would have a still life on top of a motorized sculpture turntable, each time the eye switched from the canvas to the object to capture a facet, a different perspective was presented to the artist.

I believe that something similar can be done with journalism. I think that that not only the reporting work can be distributed, but the whole act of creation, curation, validation, verification and edition can be decentralized and set completely free of boundaries and roles. My opinion is that by de-structuring the process a much richer and complete picture could be formed and a more useful and truth story could arise.

How would this look like? How would a cacophony of everybody saying everything about anything at the same time be avoided?

First, we need to break the information reported in small bits or bites. It's much more difficult for anybody to say they agree or disagree with a 3000 words article. There will be things that you agree on, others you might not be sure, and some you might fiercely oppose. If the fact you are confronted with is a short sentence, it's much more easy to define where you stand with respect to it. Plus, you don't run the risk of throwing the baby out with the bathwater.

Here's where the hip 140-characters information bits come in handy. If the whole story is composed out of 140-characters-long pieces, the process of refuting, discussing, confronting, denying or confirming parts of the story becomes much more manageable. And distributable.

Now let's say there are ways that those pieces can be related to each other. Causality could be one relation, correlation could be other. Other connections between those pieces could expand on any axes of the information contained, such as who, why, when, where, etc.

A wide number of channels to report information abound: anybody with access to the internet through a computer or a mobile device, or a text-message enabled phone could contribute with bits of information.

Let's add now a system on the reception side of this process that basically acts as the aggregator and information conduit of these information bites. If somebody reports something in Lima, Perú, the system will send it to other users in the same region and ask them to confirm it, deny it or expand on it. The system could help anybody reporting in the field through text-messages to create the nodes of information pieces by expanding in the desired axes. A dialog between the citizen and the system could go like this:

Citizen: "There are shootings going on in Lima",
System: "Do you know when it started?"
Citizen: "12:35 am"
System: "Do you know what caused it?"
Citizen: "Police trying to crack down on a drug deposit"

Or the citizen could proactively submit different connected bits without the dialog with the system. Or he could simply submit unconnected information bits and others could help relate those. There are a number of design alternatives that need to be analyzed.

Anybody interested in a specific region or topic could be subscribed and be notified when new bits are reported. He could participate in the story creation by adding other information bits, refuting some of the reported bit or creating new relationships among the different nodes that compose the story.

As the cubist turntable, the system would act as a "perspective turntable", making sure everybody has a voice in the story elicitation process, and that all angles, conflicting opinions, facts, dates and places are combined and linked in a network that can be easily navigated by people trying to understand the story.

This is by no means a replacement of a well-written, carefully researched, coherent narrative. On the contrary, it empowers that process, by unleashing the potential for anybody to have access to a much richer and complete network of information pieces on which to build their own version of reality.

The premise is that any story is made of small parts than are related by different semantic connectors and that people have a much easier job having a determined and specific opinion on small bits of information. The design of a system that would allow this distributed network of participants to create this graph of information bites is the task ahead.

We have some ideas on how this could be done, and we want to involve others to contribute and work with us in exploring such a possibility.

For this purpose, we submitted an entry to an Ashoka Changemakers competition. Come on board, comment on it, contribute your ideas, get in touch and help us create a much more transparent, decentralized and holistic approach to journalism.

Live recruiting of volunteers through phone calls and text messages

2011-09-06T13:59:00.000-07:00

A month ago we started working with the American Red Cross Bay Area Chapter, thanks to a grant that Cisco provided InSTEDD to customize or extend InSTEDD's platform in ways that it would support Bay Area community resiliency.

The Approach

We spent some time working with the Red Cross to identify possible uses of technology to leverage and simplify their work. Together, we went through their workflows, had conversations with people in different roles and discussed their tasks and responsibilities in order to find a pressing need that we could support (it is an amazing thing that more than 99% of Red Cross staff in the Bay Area are volunteers).

We ended up deciding that something we could do was to help them reduce the workload of the recruiting process to respond to disasters of any scale.

The Problem

Currently, when an incident is reported, the DAT (Disaster Action Team) coordinator, needs to call volunteers one by one until they have enough people confirmed to staff the response. The coordinator uses a spreadsheet that contains a list of all the volunteers, with their time-shifts, the city they live and their contact phone numbers. For a small incident that requires 5 responders, an average of 20 calls to different volunteers need to be made. That means that the coordinator spends more than 2 hours making phone calls, just to put together the team that will respond.

The Goal

We set up to reduce that workload and automate the process as much as we could, while still keeping the DAT coordinator in control of the aspects of the recruiting process they needed to handle.

Watchfire

Over the last few weeks, we have designed and developed Watchfire, a web application that will automate the recruiting process. The application imports their spreadsheet and stores that in a database, including their location and landline and mobile phone numbers.

Administrators or volunteers can edit the information, including their contact information, location and availability. At any point they can import a new spreadsheet to update the information.

When the DAT coordinator needs to start the recruiting process, they enters the number of people to recruit, the category (team lead, volunteer, trainee, etc.) and the location of the event. The system then creates a calling list of the people that are closest to the event.

A circle around the area where the recruiting is happening will be shown, giving the user feedback about how far the volunteers might be coming from. The user can also block some of the people in the calling list to have the system skip them. When they're ready, and clicks "Start recruiting", Watchifre starts calling people in the list by order of proximity. The calls are made to the registered phones, and the receiver hears an automated message with the description of the event, asking them if they can respond. Text messages are also sent to volunteers that have texting plans (only 50% of the Red Cross volunteers do).

As volunteers start responding, the system refreshes to reflect the status of the recruiting process, giving the DAT coordinator a list of the people that have confirmed their availability.

Any number of recruiting processes can be run at the same time, each with it's own calling list, location, category and description. The event screens allows the coordinator to monitor the status of each recruiting process as it happens.

Phone calls are made using Verboice, the voice service component of our platform, which enables applications to make and receive phone calls. Verboice supports an unlimited number of phone lines, so Watchfire can make as many simultaneous calls as lines are available, reducing the response time even further. We are using VOIP (Voice over IP) phone lines, at a $20/month national flat-rate.

Text Messages are sent through Nuntium, our messaging service.

Other uses

Needless to say, there are countless other uses for this tool besides staffing disaster responses:

Activism organizations could have their database of members and issue a call when they are having an event. People could RSVP their participation through the keypad or by replying a text message
Requests to sign petitions could be sent through phone calls or text messages and registered users of the tool could "sign" through their phones
Distributed working groups could be activated to respond to events
Meetings or event could be organized in the same way

Feedback

We welcome your feedback, ideas, needs and suggestion to make this a tool that can help you with your work. Don't hesitate in leaving your comments here. Thanks!

Mapping alcohol ads with GeoChat

2011-08-23T13:31:00.001-07:00

"Excessive drinking is a significant problem in the United States and in New York City (NYC). It is the third leading behavioral cause of death in the US¹ and has been linked to intentional and unintentional injuries, cancers, sexually transmitted infections, and other adverse health consequences.² […] A systematic review of longitudinal studies demonstrated an increased likelihood of drinking among adolescents exposed to alcohol ads compared with those not exposed.³"

Chris Goranson is the Director of the GIS Center at the Bureau of Epidemiology Services of the New York City Department of Health and Mental Hygiene. In the fall of 2010 he decided to conduct research on alcohol advertising visible at the street level in retail-dense blocks of NYC.

Throughout November and December, a team of 16 people used InSTEDD GeoChat to report and aggregate alcohol ads. The team was composed of 13 graduate-level students from Hunter College, enrolled in a GIS for Public Health class, and 2 other Health Department staff members.

GeoChat is designed to work as a group chat, for sending out alerts or for reporting information like in this case. We learned about NYC Health project when Chris reached out with some questions to the GeoChat Users Community. We were thrilled when we heard of such an original use for the tool.

To collect the data from the streets, they split up into 3-member teams, with one member responsible for navigating and selecting the appropriate street segments and the other two reporting the identified advertisements by texting a Geochat message. For each industry alcohol advertisement, the team sent a GeoChat message including the alcohol type-beer, wine, liquors-, brand, advertisement type-indoor, billboard, bus shelter, outdoor, ambient-and address. By typing an asterisk between each field, messages could later be broken up into columns. The geocoding functionality of GeoChat automatically assigns coordinates to each message containing an address, leaving the information ready to be mapped.

Messages sent by a data collection team looked like the following: 100 Worth Street * indoor * beer * [beer brand name].

GeoChat allows all the messages in a group-including the geographic coordinates, date and time-to be exported in standard formats, so the team could map their data and analyze it using ArcGIS (a geographic information system).

Of the 30 sampled zip codes, 27 (90%) had alcohol advertisements on at least one of the retail- dense blocks sampled. Of the 312 blocks sampled, 122 (39%) had at least one alcohol ad. To learn more about the study and read the complete results, you can check the paper.

You can learn more about GeoChat here and join our user group here to discuss your ideas, scenarios or questions.

MOKDAD AH, MARKS JS, STROUP DF, GERBERDING JL. Actual causes of death in the United States, 2000. Jama 2004;291:1238-45.

CDC. Alcohol use and healthFact Sheets, 2010 (vol 2011).

ANDERSON P,DEBRUIJN A,ANGUS K,GORDON R,HASTINGS G.Impact of alcohol advertising and media exposure on adolescent alcohol use: a systematic review of longitudinal studies. Alcohol Alcohol 2009;44:229-43.

Make your SMS apps scale

2010-08-11T22:54:00.000-07:00

A new version of Nuntium, is out and I wanted to share some of the great new features it contains.

Nuntium is an open source and free messaging service, built with Ruby on Rails. It has a simple but powerful API that you can use to integrate your application. You can use Nuntium from InSTEDD's server or deploy it in your own machine. Join our list to get help or discuss your needs.

To put it in a simple way, Nuntium acts as your one-stop for all the messaging needs of your applications, including -but not limited to- SMS, Mail, Twitter and XMPP. It allows you to focus on your functionality without having to deal with all the crazy quirks of telephone companies infrastructure, SMS aggregators or communication protocols.

It also supports the QST protocol defined by the OpenMobile Consortium.

Every single feature built in Nuntium, is the result of a concrete need that we had during our work with messaging systems, mainly in South-East Asia -where Nuntium delivers the daily communications and disease reporting of a few thousands users- and Haiti where it served as the keystone layer for receiving and sending hundreds of thousands of messages from the 4636 shortcode. So, instead of going through the features I'll present some examples.

Share your number among many applications

Once you have created your account in Nuntium, you can add as many applications as you need. Let's imagine that after lots of negotiations you got a 1234 shortcode in Kenya and you need to use it with four applications. We'll call them "Maternal Health", "Road accidents", "Disease Reporting" and "Team chat".

For the Maternal Health application, you decided you are going to ask your users to prefix their messages with "MH". In the case of "Road accidents", your users are 5 specific individuals and you know their phone numbers. For "Disease Reporting" you are using a mobile application that sends SMS reports in a machine-readable format. And with your "Team chat" app you don't want people to have to prefix their messages.

By using Rules in Nuntium you could configure that scenario, and support 4 different applications, coded in different languages, with a single number for all of them. All that, while keeping the routing logic out of your apps, and making it transparent to each one.

Rules can change properties in the message, like removing a keyword prefix or decide to which application the message should be routed. You can do simple things like matching the start of the body, or use regex expression to target very specific formats or syntaxes.

Supporting complex, emerging, dynamic ecosystems

In many situations you might face a constantly changing environment, in which you need to switch routing rules, deliver messages through different channels according to the carrier of the recipient, or you might have to create an infrastructure by combining plugged-in phones, direct network connections to telephone companies and international aggregators. All that while keeping track of what is going on with each single message.

Nuntium is packed with lots of tools to do so. You can:

Configure any number of SMPP connections to telephone companies
Specify an individual throttle number for each connection
Create rules to route messages based on their carrier, prefix, country code, or any custom attribute that you want to create
Track each single message with a detailed log
Define delivery strategies like broadcasting through different channels or choosing the most appropriate channel based on priorities
Configure restrictions to the use of channels, based on country, carrier or custom attributes
Re-route messages that failed through a specific channel, through another one
Track credit consumed by channels.

Tracking your messages

Nuntium gives you detailed logs of what happened to each message:

How and when it was received
Which channels were available to send it
Which was chosen and based on what strategy or priority
Errors or warnings in the communication with the telco server
Sucessful deliveries

Using Clickatell

Clickatell is the de-facto service for a quick, reliable, international messaging setup. They provide you with one or more numbers that you can use in several countries and carriers.

Nuntium supports the creation of a channel for Clickatell. All you need to configure are your credentials, decide if you want to use it as incoming, outgoing or bi-directional channel and the network that you got your number in. That network determines in which countries and carriers your phone number will work. Nuntium already imports periodically all the coverage tables from Clickatell, so you don't need to worry about that.

After doing the setup, you can either pull the messages using an RSS feed, or you can configure an endpoint in your app, an Nuntium will do a post to that URL for each incoming message. That way you don't even need to code a scheduled recurrent task to check for new messages.

Using a plugged-in phone or a gsm modem

A very common scenario in a mobile app deployment is that the use of international numbers for SMSing is either cost-prohibitive or just doesn't work. Getting a local telephone company to provide you with a cheap number and a machine-friendly interface to read and receive messages can take some time in many countries.

The default choice in this cases is to buy a local simcard, get a cheap phone and just interface through a computer.

You can also do that with Nuntium by configuring another type of channel and downloading our mobile gateway application. It's a java app, so you can run it under Windows, Linux or OSX.

The nice thing is that whenever you need to scale up and you have your short-code or long-code ready with a carrier or aggregator, you just add another channel and without changing a single line in your application, you are ready to go from a few messages per minute, to hundreds or thousands.

Allowing your apps to interact with users through Twitter, Email and Chat

Nuntium does more than sending SMS. You can use it for any other messaging channel you can think of. Mail is supported through POP3 and SMTP, so you can just create a gmail account and start sending and receiving mails from your app. Or create a twitter account and set it up. If you want your users to be able to chat with your application or receive notifications in their GTalk, Adium, or any other XMPP (ex-Jabber) client, you can also do it.

And all of this through only ONE interface. Your application doesn't have to worry if it's an SMS, email, twitter or instant message what it want to send. Just adding a prefix like "xmpp://" or "sms://" to the recipient address will tell Nuntium everything it needs to know to dispatch the message. You will also get all the incoming messages in exactly the same way.

Summary

If you need to SMS-enable your apps, or if you want to switch to something that will allow you to scale both horizontally and vertically, get in touch, we would love to help you out build a world-class app with world-class messaging powers.

IT without Software

2010-06-18T06:43:00.000-07:00

During August 2009, we went on a number of field trips to health centers in remote areas of Thailand and Cambodia. The idea was to conduct a few usability tests on Geochat syntax alternatives that we were exploring. Our goal was to simplify the interaction between health workers and the system to ultimately allow them to report disease cases in a semi-structured way.

The case information always originates at the local health center level - this is where the patient comes and gets diagnosed. Most of the case reports are made through phone calls to the district level (the higher administrative level). Case details get lost when the district level summarizes the information by disease and reports the quantity of each to the provincial level.

During our visits to provincial offices, we received useful feedback which ultimately led to the design of the current syntax. However, in health centers we found a few issues that needed to be solved before any syntax at all could be used:

Most people do not know how to send SMS.

Some of them do not know how to read an incoming SMS.

Support for Khmer and Thai characters is not common in the handsets and carriers most people use.

Even if there is support for the characters, writing SMS using them is much more difficult than writing in English due to the amount of letters in the alphabet.

These posed a huge barrier to solve even before the reports could be collected. It was not about simplifying a syntax.

Reinventing the Wheel

On our way back from the visits, feeling discouraged over the challenges ahead, an idea arose. What if we decouple the process of structuring the report from the channel through it was sent? If you ask someone to send a telegraph, he does not need to know Morse code. In the same way, we could allow health workers to create the report outside the constraints of the tool being used to transmit it.

The reporting wheel has 3 concentric circles. The material can be paper, card-stock or plastic. The circles turn independently, so you can combine any set of values of each ring. On the left side is the value to be selected, on the right side a code that represents that value.

The cover of the wheel allows you to see the values you are selecting and the number you need to report. Once the user has selected the day of the month, the disease and the number of cases he wants to report, a 9 digits number is formed on the right side which represents the 3 values selected.

The user can then make a call to a reporting hotline and enter the number or send it through an SMS (it's usually much easier to train people to text numbers than letters).

Additional instructions can be written on the cover to make the tool "self-documented."

This tool is very easy to build and can be done locally; it's cheap without being fragile; can be shared and does not require batteries. Best of all, it can be created for any language while still being language independent, that is, different wheels in different languages can contain the same codes and thus be used to report the same values. Some initial usability tests indicate that it's intuitive and easy to learn. In one particular case, a health worker was explaining how to use it to a colleague after just 5 minutes of training.

Codification

There are two issues in the codification process:

Mistakes in the typing of the numbers: a typo could cause a Malaria report to be mistaken for Dengue.

If multiple groups want to use the same reporting hotline for different kinds of reports such as veterinary diseases or crop yields, the recipient of the reports needs to know which kind of wheel it came from.

The solution for both problems happens to lie in the same trick. The codes for each reported value are selected in a way that not only allows the detection of errors in the typing, but also enables the detection of the kind of wheel used to report. With the method we developed, a total of more than 600k different wheels can be created and each can be uniquely identified with no additional information - only the 9-digit number reported is required. That means the same reporting hotline can be used to receive reports from a wide variety of sources.

At the moment we are conducting pilots in Thailand and Cambodia. We will soon have more to report on this.

Haiti SMS short-codes ecosystem (update)

2010-02-04T22:50:00.000-08:00

After some problems in the way messages where received before from Digicel, they have now re-routed the incoming messages (MO) through SMPP, the standard protocol for SMS messaging. Messages from both carriers are now being handled by Nuntium, an InSTEDD open source and free service for messaging.

The infrastructure looks like this now:

References:

Digicel: Haitian Telco
Ax: Preexisting connection to Digicel done by Votident
Comcel: Haitian Telco, a.k.a Voila
Clickatell: International aggregator
Crowdflower: provider of the platform for tagging, translating and geo-locating messages.
EIS: Emergency Information System, developed for Thomson Reuters Foundation byInSTEDD
Nuntium: Messaging service by InSTEDD
Geochat: Group communication tool over SMS. (more)
Ushahidi: Crisis map of incoming messages.

Haiti SMS short-codes ecosystem

2010-01-27T13:38:00.000-08:00

Too much debriefing and blogging needs to be done, and this is not an attempt to do so. I just wanted to share a diagram with the current situation of connections between systems and telcos at Haiti. It's probably very technical, but good as reference:

Some references:

Digicel: Haitian Telco
Ax: Preexisting connection to Digicel done by Votident
Comcel: Haitian Telco, a.k.a Voila
Clickatell: International aggregator
4636.ushahidi.com: ad-hoc development from Ushahidi to curate incoming messages. Soon to be moved to crowdflower.com
EIS: Emergency Information System, developed for Thomson Reuters Foundation by InSTEDD
Nuntium: Messaging service by InSTEDD
Geochat: Group communication tool over SMS. (more)
Ushahidi: Crisis map of incoming messages.

Hope it's helpful, please send any feedback or corrections.

(thanks Brian for the kick-off)

Harnessing information flow to empower survivors

2009-12-26T16:57:00.001-08:00

‘Information is a vital form of aid in itself […] Disaster-affected people need information as much as water, food, medicine or shelter. Information can save lives, livelihoods and resources.’ (World Disasters Report 2005)

During 2009 we have been working with Thomson Reuters Foundation on a free and open source information management system designed to be deployed in emergencies caused by sudden onset natural disasters.

The first and basic rationale for the system is that people caught up in disasters are not helpless victims and that life saving, actionable information is as important as blankets and tarpaulin. As first responders, they need reliable information to make decisions and minimize the impact.

The aim of the system is to streamline the communication flow and collaboration between the affected population with media, aid workers and government agencies, to help citizens get verified, accurate and actionable information that will enable them to make decisions and recover from the disaster.

The EIS system also provides means for affected population and field workers to channel vital data back up into aid response.

The combination of crowd-sourcing features with collaborative analytics and machine learning tools, in the hands of a team with a vast experience on humanitarian news opens up unprecedented opportunities in the area.

This tool is part of a free information service run by Thomson Reuters Foundation to help survivors of natural disasters called EIS.

Design objectives

There is an article from Bruno Giussani that provides a very interesting insight into the future role of journalism and which I believe describes perfectly what we have been trying to do:

The new power of editors and journalists will depend on their ability to take on new tasks: to animate a group of people; to develop ways to organize how information is gathered and used, with the participation of what used to be called "the audience;" and to help people navigate an information landscape that's increasingly crowded and constantly shifting.

In line with this idea, our objectives were:

Collect reports originated from the very first layer of affected population - survivors; combine that with information received from the field including aid agencies, local media and government.

Provide fast and reliable means to filter, search and detect important information in the pool of reports.

Streamline the flow of information inside a distributed editorial team including local translators.

Reach out to affected population with useful and actionable information in a timely manner.

1-Subscription and Collection

Citizens can report their location by sending an SMS to the system with the name of the village they are. That simple action registers them in the system to receive alerts targeted to that village.

Every citizen, either registered or not, can report information to the system through SMS.

The system allows submission of raw reports through several channels:

SMS: through mobile aggregators (like Clickatell) or plugged-in phones. People can send information to a specific number, which then stores the message in the system.

Twitter: both streams from particular users or certain hashtags can be imported.

Email: any number of email addresses can be checked by the system and directed to specific collection baskets or inboxes

RSS: feeds can be checked periodically and new articles will appear in the system.

Web: any user with permissions can post information using the web interface.

Bounded and Unbounded Crowd-sourcing

Through the use of a feature we called "Working groups" and in combination with the "Baskets", both bounded and unbounded crowd-sourcing processes can coexist in the stream.

Identified users can be assigned to "Working Groups" and the reports coming from those groups, can be configured to go to specific baskets. Therefore, some baskets can be monitored more often or by different people, depending on the working groups (bounded crowd) putting reports there. An unbounded basket could be even configured to be self-filtered by the same unbounded crowd and items with 10 or more people marking them as "alert" or a specific tag could then be pulled by another basket which is monitored by some agency.

The possibilities are endless and it is yet to be discovered which patterns work better depending on each situation. There is probably no silver-bullet and it'll be up to the expertise of teams deploying this to find-out, share and adjust for cultural, social and political contexts.

2-Selection and Filtering

Through a number of different tools, users monitoring the pool of raw reports can filter important information. The goal in this stage is to try to deal with as many situation awareness “demons” as possible, being data overload and context stress the most salient ones in these kinds of scenarios. These tools include search, tagging and automatic extraction of the location the text refers to. Other features that can be added to customize the experience and workflow include flagging documents, hiding them, commenting and relating them. The objective of these features is to aid in the process of collaboratively selecting useful information to initiate the editing workflow.

The platform is completely modular, allowing the customization of each collaboration space, based on the balance of features vs. simplicity.

3-Workflow

The system allows for a flexible and tailored workflow by the use of a simple but powerful metaphor:

A module called “Baskets” allows the configuration of a custom workflow tailored to the specific team and situation. The module works based on the concept of baskets. Each basket is a collection of pieces of information (items), that acts both as inbox and outbox. Each user in the system is given permissions to read, write, move in or move out items from one or more baskets.

Typically, a user would monitor one or more baskets based on his role. As new items appear, he will decide what to do, act on the item, flag it as urgent, write a comment, create a new alert or translate it to another language. He would then put the new item or the edited one in another basket for someone else to do his part of the job. The administrator is allowed to configure "baskets" and determine who can put, view, edit and remove items from those baskets. Users can then perform given tasks on the articles and move them to the next step.

The flow improves when people have not only direct access to information, but the benefit also of credible intermediaries to help discover, gather, compare, contextualize, and share information. (Knight Commision)

Different flows can be created and tuned during a deployment, ranging from a completely crowd-sourced citizen journalism to a standard editorial workflow involving translation, editing, approval, etc.

4-Informing

Once an alert is ready to be sent out to relevant recipients, the system allows the user to target affected population by location through a map with references of clusters of citizens. The user sees a map with the different groups of citizens and the number of citizens in each group.

The objective of targeting by location is not only to keep the information relevant to everyone, but also to avoid that people in a desperate situation end up traveling to a distant location just because they received a message saying there is food or blankets there.

The alert can be sent through SMS and Email, and can also be addressed to specific working groups, like aid workers, local media or government agencies.

Technology

The EIS system was built on top of RIFF (http://instedd.org/evolve), an InSTEDD platform tool developed as a general collaboration environment for content creation, social metadata annotation, and automated analysis with potential applicability in a wide range of areas.

Results

A recent pilot of the system in Tomohon, North Sulawesi Indonesia, in partnership with the Local Red Cross and the Search and Rescue Team, has proved the validity of our assumptions. Even if the incoming stream of reports from the field contained (by design) a low signal/noise ratio, the editorial team managed to process the information, select relevant topics and going through a quick but reliable loop with local translators could provide alerts with verified data.

A short summary of the pilot can be seen here

Conclusion

We have built a tool that can handle information collection, flow and reach out in a wide range of deployment scenarios in disaster situations, providing the support for channeling information up and down as needed among a heterogeneous ecosystem of stakeholders. The system will serve as the basis for further learning, development and work on the subject.