The March 11 earthquake in Japan triggered a flurry of concern in the Media Lab community at MIT. The natural desire to help was amplified by the fact that the disaster had hit many of our friends close to home in a very literal sense. Most messages suggested donations to support relief organizations — a worthy cause indeed — but there was also a more unique reaction: A call for relief technology.
It turns out that the use of digital tools in crisis situations is a concept with rich communities and plenty of solid examples. Within the Media Lab there are a handful of projects designed to assist in crisis situations and outside of the Lab there are hundreds more. Because I just started exploring the area, I want to share my initial observations along with a quick description of the projects I’m most familiar with.
Framing the Challenge
I always thought that social systems were complicated, but I will never complain again. The issues surrounding a crisis tool are almost unreal. Take a minute to think of the types of challenges that a relief technology project needs to consider up front, before even targeting a particular problem. Here are a few examples to get your brain running:
- Limited technology access — The primary stakeholders of a relief technology are those living in a disaster area. Maybe the area is a developing country with no digital infrastructure or a more developed country whose digital infrastructure just got annihilated. Maybe people have the Internet, maybe they just have cell phones, or maybe they really have nothing on the ground. Nothing is a given here.
- Shifting impact windows — What are the phases of disaster relief, how long do they last, and what changes between them? I like the general structure presented in this document [PDF]. It starts with an immediate response, which focuses on things like saving lives, cleaning up, and tending to basic human needs. This is followed by mid-term planning, which involves getting the basics back such as temporary housing and lifeline utilities. Finally the long term reconstruction phase begins. Each of these phases has drastically different needs, requirements, and timelines.
- Global-scale requirements — National disaster relief is a problem that even government-scale organizational structures struggle to deal with. What are the core needs and how can they be met? Who is being impacted? Who is going to participate and how? What are the implications of your solution? What is already being done and how can you fit in effectively? How many different cultures are going to be using your tool? What languages are involved? These are all vital questions which have to be thought through.
- Lives are at stake — Behind this entire process is an ultimate fact: These technologies are dealing with matters of life and death. If an organization relies on a tool for some portion of its operations and the tool fails there could be very real and serious consequences.
What exactly do these issues mean from a system design standpoint? How do these concerns end up shaping a project? Hopefully some examples can help illustrate that.
Example 1: Konbit
Greg Elliott and Aaron Zinman, two students at the MIT Media Lab, noticed a major problem with the way reconstruction efforts were being approached after the 2010 Haiti earthquake. The issue was simple: Haiti lacked the information infrastructure needed to effectively identify local skill sets at scale and hire Haitians to assist in the rebuilding tasks.
For instance, instead of hiring a local plumber or electrician, someone might be flown in from the United States to get the job done. Plumbers, bricklayers, drivers, nurses, and translators all live within the crisis areas, but without a way for foreign NGOs to easily discover them and their skill sets they simply aren’t hired. To make the problem more challenging, access to the Internet in Haiti is uncommon, meaning a purely web-based solution would offer no help at all. Additionally, 50% of the country is illiterate, so even SMS-based solutions are not appropriate.
They created Konbit to address this problem. It provides a phone-based interface that allows Haitians to register their skills and life experiences via an automated interview process. The interviews are then translated and categorized, resulting in an online searchable directory that employers and NGOs can use to discover local workers. They have more than 3,000 workers ready to be hired right now and are looking for NGOs and employers who can use their database.
Example 2: Ushahidi
While Konbit focuses on the rebuilding phase of a disaster, Ushahidi, a 2008 Knight News Challenge winner, has proven how powerful an information-mapping platform can be in the immediate response to a crisis. Within days of the tsunami in Japan, an instance of the platform was set up to track reports and needs from the ground. This particular map (see above) has an aggregation of reports with labels such as “Wanted!” “Disaster Area,” and “Available Service.”
As those of you who are familiar with the Ushahidi platform already know, it is brilliant because the open tools are general enough to be easily and quickly adapted for use in new situations. Information transfer based on geography is going to be needed in any crisis situation and many non-crisis situations as well. This helps separate the technology from the context, which means that at the very least a general information flow can be quickly set up almost immediately after disaster strikes.
Example 3: Grassroots Mapping
One of the projects that has come out of the Center for Future Civic Media is a set of tools and techniques for community-driven maps called Grassroots Mapping. The tools allow individuals to create high resolution maps using what boils down to a kite and a camera. Unlike Konbit and Ushahidi, this project is much more focused on the documentation of geographic change.
The project had immediate application after the oil spill in the Gulf of Mexico in 2010, where thousands of miles of coastline were contaminated with oil over a period of several weeks. Satellite imagery gave a sense of the damage, but grassroots maps made it possible to create high resolution maps of the damage, which are now part of the public record for anyone to view and use.
Designing for a Need
I want to wrap up the post with a story about my own miniature attempt to contribute to the world of relief technology. As reactors were beginning to overheat in Japan, I heard someone comment on a desire to better understand what was actually needed and how they could help. That night I threw together a quick Google Maps mash-up with the hope to make it easy for people to help log needs and support organizations on the ground:
The next day I learned about the Ushahidi instance and put my project on temporary hold; a few days of rushed hacking wasn’t going to save Japan and I needed some giant shoulders to stand on. One week later, it seems that the original need I was approaching — making it possible for American donors to understand how and where they could help — is still not being met. Ushahidi has the information buried inside of its maps but the interface is simply not designed for that purpose and the reports are in Japanese.
I want to tap into Ushahidi by creating a layer which can frame the information for charitable supporters rather than for NGOs and survivors. The goal is a system that turns information into action by helping people with resources understand where needs are being met, who is meeting them, and how they can help. In the meantime, though, I would love to hear about any type of relief technology that you have seen which stood out as successful or unique.