Category Archives: Crowdsourcing

Wag the Dog, or How Falsifying Crowdsourced Data Can Be a Pain

I had the pleasure of finally meeting Robert Scoble in person at Where 2.0 last week. We had a great chat about validating crowdsourced information, which he caught on camera below. In the conversation, I used Wag the Dog as an analogy for Ushahidi‘s work on Swift River. I’d like to expand on this since open platforms are obviously susceptible to “information vandalism”, ie, having false data deliberately entered.

The typical concern goes something like this: what if a repressive regime (or non-state group) feeds false information to an Ushahidi deployment? As I’ve noted on iRevolution before (here, here and here), Swift River collects information from sources across various media such as SMS, Twitter, Facebook Groups, Blogs, Online News, Flickr and YouTube. In other words, Swift River pulls in visual and text based information.

So where does Wag the Dog come in? Have a look at this scene from the movie if you haven’t watched it yet:

If an authoritarian state wanted to pretend that rioters had violently attacked military police and submit false information to this effect in an Ushahidi deployment, for example, then what would that effort entail? Really gaming the system would probably require the following recipe:

  1. Dozens of  pictures of different quality from different types of phones of fake rioters taken from different angles at different times.
  2. Dozens of text messages from different phone using similar language to describe the fake riots.
  3. Several dozens of Tweets to this same effect. Not just retweets.
  4. Several fake blog posts and Facebook groups.
  5. Several YouTube videos of fake footage.
  6. Hacking national and international media to plant fake reports in the mainstream media.
  7. Hundreds of (paid?) actors of different ages and genders to play the rioters, military police, shopkeepers, onlookers, etc.
  8. Dozens of “witnesses” who can take pictures, create video footage, etc.
  9. A cordoned off area in the city where said actors can stage the scene. Incidentally, choreographing a fight scene using hundreds actors definitely needs time and requires rehearsals. A script would help.
  10. Props including flags, banners, guns, etc.
  11. Ketchup, lots of ketchup.
  12. Consistent weather. Say a repressive state decides to preemptively create this false information just in case it might become useful later in the year. If it was raining during the acting, it better be raining when the state wants to use that false data.

Any others you can think of? I’d love to expand the recipe. In any case, I think the above explains why I like using the analogy of Wag the Dog. If a repressive state wanted to fabricate an information ecosystem to game an Ushahidi install, they’d have to move to Hollywood. Is Swift River a silver bullet? No, but the platform will make it more of pain for states to game Ushahidi.

Patrick Philippe Meier

Why Universities are Key for the Future of Crisis Mapping

In January 2010, I launched the Ushahidi Crisis Map for Haiti. In February, I launched the Ushahidi Crisis Map of Chile. Neither initiative would have been possible without the incredible student volunteer network that formed at The Fletcher School/Tufts University, the Graduate Institute in Geneva and Columbia University’s School of International and Public Affairs (SIPA). We also had a few volunteers from the London School of Economics (LSE).

At one point, I had set up a Skype IM chat group titled “Global Situation Rooms” which included the core reps from Fletcher, Geneva and SIPA. The highlight for me was when we all got on the chat group to debrief. I moderated the session and would literally write “Geneva, you have the floor”, “New York, you have the floor”, “London, you have the floor”, etc. Talk about the first open source, global neogeography disaster response operation.

Given that The Fletcher School/Tufts group have paved the way forward in absolutely amazing ways, I  suggested back in February that we formalize this set up and launch a network of global situation rooms. I think the Fletcher team could play a leading role in this bold initiative and become the convener or Secretariat of this global network. If a disaster strikes Madagascar, for example, the Fletcher team could convene reps from other University Situation Rooms (USRs) and coordinate the near real-time crisis mapping support.

I ran with this idea and pitched it to the Clinton Global Initiative University (CGI-U), which will take place in mid-April. I’ve called the project “Universities for Ushahidi” and made this my commitment as a student participant at CGI-U. I’ve thought about this initiative further over the past two months and would like to focus  specifically on universities in the developing world and not restrict operations to emergency response, or to Ushahidi.

So here’s my dream: have the awesome team at Fletcher pave the way in training 12 universities around the world, 4 in Africa, 4 in Asia and 4 in South America. Have each of these new Situation Rooms be capable of launching near real-time crisis mapping support projects within hours after a crisis strikes in their countries/regions. In between crises, the new Situation Rooms could run other projects using Ushahidi. As I noted above, however, I would want this to include training and applications combined with other tools including OpenStreetMap, FrontlineSMS, etc.

I’m really excited by the potential. Universities have a clear comparative advantage. What other organization or institution has the ability to mobilize hundreds of student volunteers for weeks on end? I do see this as a form of activism. Students should be paving the way, revolutionizing the way we think and do things. I’m proud to be a Fletcher School student and can think of no better way to contribute to our moto: “Preparing Leaders with a Global Perspective.”

Fletcher students are exactly the type of students who will go on to work for the UN and other humanitarian/development/human rights organizations. They are the first generation of Crisis Mappers and their leadership, professionalism and camaraderie will change what is possible in this space. That is why universities are key to the future of crisis mapping.

Patrick Philippe Meier

Using Massive Multiplayer Games to Playsource Crisis Information

This blog sequel follows this one on Netsourcing, Crowdsourcing and Turksourcing. This new round of thinking is inspired by a recent dinner conversation (that made it to the New York Times!) with Riley Crane, Omar Wasow, Anand Giridharadas, and Jen Brea. If the ideas below seem a little off the wall, the bottle of Kirsch I brought over for the Swiss fondue is to blame. Some parts of this post were were also inspired by The Polymath Project and conversations with Kuang Chen, Abraham Flaxman and Rob Munro during the Symposium on Artificial Intelligence for Development (AI-D) at Stanford University.

I wonder how many indoor cycling bikes exist in the world, or at least in the US. The number may in part be a function of the number of gyms. In any event, to borrow the language of Douglas Adams, the number must be “vastly, hugely, mind-bogglingly big,” especially the total number of hours spent on these bikes everyday in California alone. I’ve often wondered how much energy these machines generate when used; enough to recharge my iPhone? Hundreds of iPhones?  Why do I ask?

I’ve been thinking about the number of hours that gamers spend playing computer games in the US. Hundreds of thousands hours? I’m not quite sure what the correct order of magnitude is, but I do know the number is increasing. So how does the cycling analogy come in? Simple: how can we harness the millions of hours spent playing computer games every year to turksource crisis information? Could real world information be subtly fed into these games when necessary to process Human Intelligence Tasks (HITs) that would help tag and/or geolocate crisis information? Can we think of mobile games akin to FourSquare that could generate collective action around HITs?

In other words, what is the game equivalent of reCAPTCHA for turksourcing crisis information? Remember the computer game “Where in the World is Carmen Sandiego?” Could a cross between that type of learning game, a treasure hunt and “The DaVinci Code” get gamers hooked? I’m probably thinking way too old school here. Perhaps taking the most popular games today and subtly embed some HITs is the way to go. As mentioned in my previous blog post, one of the most time consuming and human resource intensive tasks that volunteers carried out during the first weeks of Ushahidi-Haiti was the manual, near real-time geo-location of unfolding events.

So how about adding a fun gaming user interface to OpenStreetMap? Like any good game, a user would be able to specify a difficulty level. Making a mobile UI would also come in handy when tourists are abroad and want to help geolocate. You’ve heard of eco-tourism, welcome to geo-tourism. Maybe Lonely Planet or Rough Guides could partner on such a project. Or, as happened in Haiti, geo-coding was also crowdsourced thanks to the pro-active Haitian volunteers of Mission 4636 who were far quicker at tagging than student volunteers. But what happens if the only volunteers around are not country experts or familiar with satellite imagery? Is there a way to use a Mechanical Turk Service approach to greatly simplify this geocoding process?

Maybe the day will come when kids whose parents tell them to get off their computer game to do their homework will turn around and say: “But Mom, I’m learning about the geography of Mozambique, which is what my quiz is on tomorrow, and I’m playsourcing crisis information to save lives at the same time!”

Patrick Philippe Meier

From Netsourcing to Crowdsourcing to Turksourcing Crisis Information

The near real-time crisis mapping of the disasters in Haiti and Chile using Ushahidi required a substantial number of student volunteers. These volunteers were not the proverbial crowd but rather members of pre-existing, highly-connected social networks: universities. How do we move from netsourcing to crowdsourcing and on to turksourcing?

Student volunteers from Fletcher/Tufts, SIPA/Columbia and the Graduate Institute in Geneva all represent established social networks and not an anonymous crowd. They contributed over ten thousand free hours over the past 3 months to monitor hundreds of sources on the web and map actionable information on an ongoing basis. The Core Team at Fletcher spent dozens of hours training volunteers on media monitoring and mapping.

Netsourcing presents some important advantages. Pre-existing social ties can help mobilize a trusted volunteer network. I  just sent one email to the Fletcher list-serve and because the Fletcher student body is a tight community, this eventually let do hundreds of volunteers being trained and contributing to the crisis mapping of Haiti.

The first call for volunteers

At the same time, however, netsourcing is bounded crowdsourcing. In other words, netsourcing is scale-constrained. Imagine if Wikipedia contributions had been limited to professors only—that too would be bounded crowdsourcing. So how do we move from netsourcing to crowdsourcing crisis information? How do we move from having 300 volunteers connected via existing social networks to 300,000 or even 3,000,000 anonymous volunteers?

This was one of the many questions that my colleague Riley Crane, a friend of his and I discussed for almost 4 hours over dinner. (Riley recently rose to fame when he and his team at MIT that won DARPA’s Red Balloon competition). The answer, we think, is to develop a Mechanical Turk Service plug-in for Ushahidi. I’m calling this turksourcing. The two most time-consuming tasks that volunteers labored on was media monitoring and geo-location. Both processes can be disaggregated into human intelligence tasks (HITs) combined with some automation, like Swift River. And none of this would require prior training.

This is a conversation I very much look forward to continuing with Riley and one that I also plan to bring up at Nathan Eagle‘s Symposium on Artificial Intelligence for Development (AI-D) at Stanford next Monday. There is another related conversation that I’m excited to continue—namely the use of distributed, mobile gaming as an incentive catalytic for collective action, an area that Riley has spent a lot of time thinking about.

In terms of Ushahidi, If turksourcing crisis information can be combined with gaming, users could compete for altruism points, e.g., for how many HITs they contributed to a disaster response. This could be a proxy for how “good” a person is; a kind of public social ranking score for those who opt in. I imagine having individuals include their score and ranking on their blog (much like the number of Twitter followers they have). Who knows, a high altruism score could even get you more dates on Match.com.

Patrick Philippe Meier

Towards an SMS Code of Conduct for Disaster Response

Picture this: it’s October 7, 2011, and a major hazard hits a highly vulnerable population resulting in a devastating disaster. The entire humanitarian response community mobilizes within 48 hours. Days later, the cell phone network is back up and dozens of SMS systems are activated by large and small organizations. Two or three of these systems use short codes thanks to rapid collaboration with the country’s national telecommunication companies. The other SMS systems all use long codes.

That picture concerns me, a lot. The technology community’s response to Haiti has demonstrated that using SMS to communicate with disaster affected communities can save lives, hundreds of lives. Humanitarian organizations and NGOs have all taken note and nothing will prevent them from setting up their own SMS systems in the near future. This wouldn’t worry me if coordination wasn’t already a major challenge in this space.

Let me elaborate on the above picture.

Picture further that one organization decides to send out regular SMS broadcasts to the disaster affected communities to improve their situational awareness and prevent panic. This is an important service during the first few days of a disaster. But imagine that this organization does not provide a way for users receiving this information to unsubscribe or to specify exactly what type of information they would like and for which locations. Next suppose that three NGOs set up long codes to do the same. Now imagine that two major organizations independently set up an alerts SMS system, asking individuals to text in their location and most urgent needs.

This is an information disaster in the making for communities in crisis.

So what are we going to do to prevent the above picture from turning into reality? The group Communicating with Disaster Affected Communities (CDAC) is probably best placed to support a coordinating role in this space. But before we even get to this, our own community should start drafting an “SMS Code of Conduct for Disaster Response” for ourselves. I can think of no better way to start the process by using distributed cognition (aka crowdsourcing). This blog post on lessons learned and best practices may be informative as well.

Here are a few ideas to begin with:

  • Set up a complaints mechanism
  • Do not duplicate existing national SMS systems
  • Set up a single clearing house for all outgoing SMS broadcasts
  • Ensure that SMS messages are demand driven in terms of content
  • Enable receivers of Disaster SMS’s to unsubscribe and to specify alert type and location

There are likely dozens more points we could add. So please feel free to do so in the comments section below. I will then create a more structured Google Doc out of your replies and send this out for further peer reviewing.

Patrick Philippe Meier

Ushahidi & The Unprecedented Role of SMS in Disaster Response

What if we could communicate with disaster affected communities in real-time just days after a major disaster like the quake in Haiti? That is exactly what happened thanks to a partnership between the Emergency Information Service (EIS), InSTEDD, Ushahidi, Haitian Telcos and the US State Department. Just 4 days after the earthquake, Haitians could text their location and urgent needs to “4636” for free.

I will focus primarily on the way that Ushahidi used 4636. Since the majority of incoming text messages were in Creole, we needed a translation service. My colleague Brian Herbert from Ushahidi and Robert Munro of Energy for Opportunity thus built a dedicated interface for crowdsourcing this step and reached out to dozens of Haitian communities groups to aid in the translation, categorization and geo-location of every message, quickly mobilizing 100s of motivated and dedicated volunteers. So not only was Ushahidi crowdsourcing crisis information in near real-time but also crowdsourcing translation in near real-time.

Text messages are translated into English just minutes after they leave a mobile phone in Haiti. The translated messages then appear directly on the Ushahidi platform. The screenshots below (click on graphics to enlarge) illustrates how the process works. The original SMS in Creole (or French) is displayed in the header. In order to view the translation, one simply clicks on “Read More”.

Ushahidi Back End

Incoming Text Messages

If further information is required, then one can reply to the sender of the text message directly from the Ushahidi platform. This is an important feature for several reasons. First, this allows for two-way communication with disaster affected communities. Second, an important number of messages we received were not actionable because of insufficient location information. The reply feature allowed us to get more precise information.

The screenshots below show how the “Send Reply” feature works. We weren’t sure if Universite Wayal was the same as Royal University. So we replied and asked for more location information. Note the preset replies in both English and Creole. The presets include thanks & requests for more location information, for example. Of course, one is not limited to these presets. Any text can be typed in and sent back to the sender of the original SMS. This feature has been part of the Ushahidi for almost two years now. We send off the request for more information and receive the following reply within minutes.

Preset Replies

When we receive an urgent and actionable SMS like this one, we can immediately create a report. By actionable, we mean there is sufficient location information and the description of the need is specific enough to respond to, just like the example above.

Creating a Report

First, the GPS coordinates for the location is identified. This can be done directly from the Ushahidi platform by entering the street address or town name. Sometimes a bit of detective work is needed to pinpoint the exact coordinates. Next, a title and description for the report is included–the latter usually comprising the text of the SMS. This is what we mean by structured information. The report is then tagged based on the category framework. Pictures can be uploaded with the report, and links to videos can also be included. Finally the report is saved and then approved for publication.

This is how the Ushahidi-Haiti @ Tufts team mapped 1,500+ text messages on the Ushahidi platform. We are now working with Samasource and Crowdflower to have the translation work serve as a source of income for Haitians inside Haiti. But how does all this connect to response?

Ushahidi’s “Get Alerts” feature is one of my favorite because it allows responders themselves to customize the specific type of actionable information that is important to them; i.e., demand driven situational awareness in near real-time. Not only can responders elect to receive automated alerts via email, but they can also do so via SMS. Responders can also specify their geographic area of interest.

Subscribe to Alerts

For example, if a relief worker from the Red Cross has a field office in neighborhood of Delmas, they can subscribe to Ushahidi to receive information on all reports originating from their immediate vicinity by specifying a radius, as shown below.

Selecting Area of Interest

The above Alerts feature is now being upgraded to the one depicted below, which was designed by my colleague Caleb Bell from Ushahidi. Not only are responders able to specify their geographic area of interest, but they can also select the type of alert (e.g., collapsed building, food shortage, looting, etc.) they want to receive. They can even add key words of interest to them, such as “water”, “violence” or “UN”. The goal is to provide responders with an unprecedented degree of customization to ensure they receive exactly the kind of alerts that they can respond to.

Highly Customized Alerts

On a more “macro” level, I recently reached out to colleagues at the EC’s Joint Research Center (JRC) to leverage their automated sentiment (“mood”) analysis platform. Sentiment Analysis is a branch of natural language processing (NLP) that seeks to quantify positive vs negative perceptions; akin to “tone” analysis. I suggested that we use their platform on the incoming text messages from Haiti to get a general sense of changing mood on an hourly basis. I’ll blog about the results shortly. In the meantime, here’s a previous blog post on the use of Sentiment Analysis for early warning.

Patrick Philippe Meier

Location Based Mobile Alerts for Disaster Response in Haiti

Using demand-side and supply-side economics as an analogy for the use of communication and information technology (ICT) in disaster response may yield some interesting insights. Demand-side economics (a.k.a. Keynesian economics) argues that government policies should seek to “increase aggregate demand, thus increasing economic activity and reducing unemployment.” Supply-side economics, in contrast, argues that “overall economic well-being is maximized by lowering the barriers to producing goods and services.”

I’d like to take this analogy and apply it to the subject of text messaging in Haiti. The 4636 SMS system was set up in Haiti by the Emergency Information Service or EIS (video) with InSTEDD (video), Ushahidi (video) and the US State Department. The system allows for both demand-side and supply-side disaster response. Anyone in the country can text 4636 with their location and needs, i.e., demand-side. The system is also being used to supply some mobile phone users with important information updates, i.e., supply-side.

Both communication features are revolutionizing disaster response. Lets take the supply-side approach first. EIS together with WFP, UNICEF, IOM, the Red Cross and others are using the system to send out SMS to all ~7,500 mobile phones (the number is increasing daily) with important information updates. Here are screen shots of the latest messages sent out from the EIS system:

The supply-side approach is possible thanks to the much lower (technical and financial) barriers to disseminating this information in near real-time. Providing some beneficiaries with this information can serve to reassure them that aid is on the way and to inform them where they can access various services thus maximizing overall economic well-being.

Ushahidi takes both a demand-side and supply-side approach by using the 4636 SMS system. 4636 is used to solicit text messages from individuals in urgent need. These SMS’s are then geo-tagged in near real-time on Ushahidi’s interactive map of Haiti. In addition, Ushahidi provides a feature for users to receive alerts about specific geographic locations. As the screen shot below depicts, users can specify the location and geographical radius they want to receive information on via automated email and/or SMS alerts; i.e., supply-side.

The Ushahidi Tech Team is currently working to allow users to subscribe to specific alert categories/indicators based on the categories/indicators already being used to map the disaster and humanitarian response in Haiti. See the Ushahidi Haiti Map for the list. This will enable subscribers to receive even more targeted location based mobile alerts,  thus further improving their situational awareness, which will enable them to take more informed decisions about their disaster response activities.

Both the demand- and supply-side approaches are important. They comprise an unprecedented ability to provide location-based mobile alerts for disaster response; something not dissimilar to location based mobile advertising, i.e., targeted communication based on personal preferences and location. The next step, therefore, is to make all supply-side text messages location based when necessary. For example, the following SMS broadcast would only go to mobile phone subscribers in Port-au-Prince:

It is important that both demand- and supply-side mobile alerts be location based when needed. Otherwise, we fall prey to Seeing Like a State.

“If we imagine a state that has no reliable means of enumerating and locating its population, gauging its wealth, and mapping its land, resources, and settlements, we are imagining a state whose interventions in that society are necessarily crude.”

In “Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed,” James Scott uses the following elegant analogy to emphasize the importance of locality.

“When a large freighter or passenger liner approaches a major port, the captain typically turns the control of his vessel over to a local pilot, who brings it into the harbor and to its berth. The same procedure is followed when the ship leaves its berth until it is safely out into the sea-lanes. This sensible procedure, designed to avoid accidents, reflects the fact that navigation on the open sea (a more “abstract” space) is the more general skill. While piloting a ship through traffic in a particular port is a highly contextual skill. We might call the art of piloting a “local and situated knowledge.”

An early lesson learned in the SMS deployment in Haiti is that more communication between the demand- and supply-side organizations need to happen. We are sharing the 4636 number,  so we are dependent on each other and need to ensure that changes to the system be up for open discussion. This lack of joint outreach has been the single most important challenge in my opinion. The captains are just not talking to the local pilots.

Patrick Philippe Meier

Using Mechanical Turk to Crowdsource Humanitarian Response

I’m increasingly intrigued by the idea of applying Mechanical Turk services to humanitarian response. Mechanical Turk was first developed by Amazon to crowdsource and pay for simple tasks.

An excellent example of a Mechanical Turk service in the field of ICT for Development (ICT4D) is txteagle, a platform that enables mobile phone subscribers in developing countries to earn money and accumulate savings by completing simple SMS-based micro-tasks for large corporate clients. txteagle has been used to translate pieces of text by splitting them into individual words and sending these out by SMS. Subscribers can then reply with the translation and earn some money in the process. This automatic compensation system uses statistical machinery to automatically evaluate the value of submitted work.

In Haiti, Samasource and Crowdflower have partnered with Ushahidi and FrontlineSMS to set up a Mechanical Turk service called “Mission 4636“. The system that Ushahidi and partners originally set up uses the generosity of Haitian volunteers in the US to translate urgent SMS’s from the disaster affected population in near real-time. Mission 4636 will relocate the translation work to Haiti and become an automatic compensation system for Haitian’s in-country.

At Ushahidi, we aggregate and  categorize urgent, actionable information from multiple sources including SMS and geo-tag this information on the Ushahidi’s interactive mapping platform. In the case of Haiti, this work is carried out by volunteers in Boston, Geneva, London and Portland coordinated by the Ushahidi-Haiti Situation Room at Tufts University. Volunteer retention is often a challenge, however. I wonder whether we an automated compensation system could be used to sustain future crisis mapping efforts.

Another challenge of crowdsourcing crisis information is tracking response. We know for a fact that a number of key responders are following our near real-time mapping efforts but knowing which reports they respond to is less than automatic. We have been able to document a number of success stories and continue to receive positive feedback from responders themselves but this information is hard to come by.

In a way, by crisis mapping actionable information in near real-time and in the public domain, we are in effect trying to crowdsource response. This, by nature, is a distributed and decentralized process, hence difficult to track. The tracking challenge is further magnified when the actors in question are relief and aid organizations responding to a large disaster. As anyone who has worked in disaster response knows, communicating who is doing what, where and when is not easy. Responders don’t have the bandwidth to document which reports they’ve responded to on Ushahidi.

This is problematic for several reasons including coordination. Organizations don’t necessarily know who is responding to what and whether this response is efficient. I wonder whether a Mechanical Turk system could be set up to crowdsource discrete response tasks based on individual organizations’ mandates. Sounds a little far out and may not be feasible, but the idea nevertheless intrigues me.

The automatic compensation system could be a public way to compensate response. Incoming SMS’s could be clustered along the UN Cluster system. The Shelter Cluster, for example, would have a dedicated website to which all shelter-related SMS’s would be pushed to. Organizations working in this space would each have access to this password protected website and tag the alerts they can and want to respond to.

In order to “cash in” following a response, a picture (or text based evidence) has to be submitted as proof, by the organization in question e.g., of new shelters being built. The number of completed responses could also be made public and individuals compelled to help, could send donations via SMS to each organization to reward and further fund the responses.

The task of evaluating the evidence of responses can also be crowdsource à la Mechanical Turk and serve as a source of revenue for beneficiaries.

For example, local Haitian subscribers to the system would receive an SMS notifying them that new shelters have been set up near Jacmel. Only subscribers in the Jacmel area would receive the SMS. They would then have a look for themselves to see whether the new shelters were in fact there and text back accordingly. Dozens of individuals could send in SMS’s to describe their observations which would further help triangulate the veracity of the evaluation à la Swift River. Note that the Diaspora could also get involved in this. And like txteagle, statistical machinery could also  be used to automatically evaluate the response and dispense the micro-compensations.

I have no doubt there are a number of other important kinks to be ironed out but I wanted to throw this out there now to get some preliminary feedback. This may ultimately not be feasible or worthwhile. But I do think that a partnership between Ushahidi and Crowdflower makes sense, not only in Haiti but for future deployments as well.

See also:

  • Digital Humanitarian Response: Moving from Crowdsourcing to Microtasking [Link]

Haiti and the Power of Crowdsourcing

It’s been two weeks since I called David Kobia to launch Ushahidi’s crisis mapping platform in Haiti. I could probably write 100 blog posts on the high’s and low’s of the past 14 days. Perhaps there will more time be next month to recount the first two weeks of the disaster response. For now, I wanted to share an astounding example of crowdsourcing that took place 10 days ago.

Boston, January 17, 8pm

Picture a snowy Boston evening and the following “Situation Room” a.k.a. my living room at Blakeley Hall, part of The Fletcher School.

My fellow PhD colleague Anna Schulz, who has rapidly become an expert in satellite imagery analysis and geolocation, receives an urgent request via Skype from InSTEDD‘s Eric Rasmussen pictured below with Nico di Tada. That tent is pitched right next to the runway of Port-au-Prince’s international airport, some 1,600 miles south of Boston.

The urgent request? GPS coordinates for 7 key locations across Port-au-Prince where many Haitians were known to be trapped under rubble. They needed to communicate this information to the Search and Rescue (SAR) teams before 0600. Anna immediately got to work.

Boston, January 17, 8.30pm

An hour later, Anna had found the GPS coordinates for all but one of the locations for the rescue operations.

Boston, January 17, 9.41pm

Boston, January 17, 10.26pm

Some time later, the same urgent request originally sent by Eric and Nico appears on the CrisisMappers Google Group:

Boston, January 17, ~11.00pm

At Anna’s request, I send out the following Tweet on Ushahidi.

Boston, January 18, ~1.00am

The following report is submitted to the Ushahidi-Haiti platform by someone from the Twittersphere:

Boston, January 18, 1.20am

My colleague Jaroslav in The Fletcher Situation room Skypes back to Anna:

Courtesy of high-resolution satellite imagery on Google Earth:

Boston, January 18, ~2.00am

It’s getting late but the ALL CAPS in this Tweet to Ushahidi catches my eye:

My colleague Jaroslav and I decide to try the number. Low and behold, we get Marc on the phone after just one ring. With a mixture of English and French, we find out that he was indeed a former employee of Au Bon Prix which happens to be a book store just off “Au Champs de Mars” near the Palace. We immediately Skype this information back to Eric and Nico at Port-au-Prince airport.

Boston, January 18, ~2.15am

Boston, January 18, ~4.30am

It’s still snowing in Boston. Time to get a few hours of sleep. We hand over operations to the Ushahidi Team in Africa.

Patrick Philippe Meier

Responding to Feedback on UN Foundation/Vodafone Report

Update: I’m in conversation with the UN/Vodafone Foundation about adding a paragraph on case selection, a case study on Sahana and correcting the error on UNOSAT.

The UN/Vodafone Foundation recently published a new Report on New Technologies in Emergencies and Conflicts. This blog post responds to feedback on this report. Please note that I do so as second-author. My respected colleague Diane Coyle is the report’s lead author and editor so she may have other thoughts on the feedback. Naturally, I will only address the feedback that relates to my input.

  • Intended audience: The report was written for a general (non-technical/expert) audience as a way to showcase technology applications in the humanitarian space.
  • Case selection: The case studies were selected in consultation with the UN/Vodafone Foundation throughout the research period. These consultations included the authors of the report (Diane and myself) and three members of the UN/Vodafone Foundation who served as editors. Some of the case studies were requested by the Foundation. For the other case studies, we strove to highlight some of the most recent initiatives in consultation with the UN/Vodafone Foundation. Of the 19 case studies selected, 13 didn’t exist some 2 years ago. The others comprise major global initiatives, fit well together as examples for a general audience, or were requested case studies. Clearly, the limited space did not allow us include everyone’s favorite project.
  • Length of report: We originally had some 80-or-so draft pages between us and had to reduce the content to about 60 pages. This meant having to decide what to keep and what to put aside. Some of the rewrite was also done to make the report less technical and more widely understandable. This helped to save on space.
  • UNOSAT and Sri Lanka: The reference does not intend to endorse or discount the interpretation of the imagery by the international community. The reference is based on in-person consultations with several well-placed experts. That said, I would agree that some rephrasing is in order this paragraph needs to be reworked.

On a personal note, I have found the tone of some criticisms rather disappointing and old school. There are several ways to give feedback: one is constructive, another is destructive. The former provides incentives to improve and continue an open collaborative conversation as a community. The latter defeats the incentive for growth and leads to a more self-centered community.

Some of the criticisms of this report have been destructive. Why is it that some of us can’t get our points across with more composure? Does bitterness make us feel more important? I expected a lot more from some of my (older, wiser) colleagues. But I haven’t always been good on providing constructive feedback either, so thanks to my “new fan club” I’ve got another New Year’s resolution for 2010: I will do my best to give constructive, supportive feedback.

Patrick Philippe Meier