Tag Archives: Match.com

From Russia with Love: A Match.com for Disaster Response

I’ve been advocating for the development of a “Match.com” for disaster response since early 2010. Such a platform would serve to quickly match hyperlocal needs with relevant resources available at the local and national level, thus facilitating and accelerating self-organization following major disasters. Why advocate for a platform modeled after an online dating website? Because self-organized mutual-aid is an important driver of community resilience.

Russian Bell

Obviously, self-organization is not dependent on digital technology. The word Rynda, for example, is an old Russian word for a “village bell” which was used by local communities to self-organize during emergencies. Interestingly, Rynda became a popular meme on social media during fires in 2010. As my colleague Gregory Asmolov notes in his brilliant new study, a Russian blogger at the time of the fires “posted an emotional open letter to Prime Minister Putin, describing the lack of action by local authorities and emergency services.” In effect, the blogger demanded a “return to an old tradition of self-organization in local communities,” subsequently exclaiming “bring back the Rynda!” This demand grew into a popular meme symbolizing the catastrophic failure of the formal system’s response to the massive fires.

At the time, my colleagues Gregory, Alexey Sidorenko & Glafira Parinos launched the Help Map above in an effort to facilitate self-organization and mutual aid. But as Gregory notes in his new study, “The more people were willing to help, the more difficult it was to coordinate the assistance and to match resources with needs.” Moreover, the Help Map continued to receive reports on needs and offers-of-help after the fires had subsided. To be sure, reports of flooding soon found their way to the map, for example. Gregory, Alexey, Glarifa and team thus launched “Virtual Rynda: The Help Atlas” to facilitate self-help in response to a variety of situations beyond sudden-onset crises.

“We believed that in order to develop the capacity and resilience to respond to crisis situations we would have to develop the potential for mutual aid in everyday life. This would rely on an idea that emergency and everyday-life situations were interrelated. While people’s motivation to help one another is lower during non-emergency situations, if you facilitate mutual aid in everyday life and allow people to acquire skills in using Internet-based technologies to help one another or in asking for assistance, this will help to create an improved capacity to fulfill the potential of mutual aid the next time a disaster happens. […] The idea was that ICTs could expand the range within which the tolling of the emergency bell could be heard. Everyone could ‘ring’ the ‘Virtual Rynda’ when they needed help, and communication networks would magnify the sound until it reached those who could come and help.”

In order to accelerate and scale the matching of needs & resources, Gregory and team (pictured below) sought to develop a matchmaking algorithm. Rynda would ask users to specify what the need was, where (geographically) the need was located and when (time-wise) the need was requested. “On the basis of this data, computer-based algorithms & human moderators could match offers with requests and optimize the process of resource allocation.” Rynda also included personal profiles, enabling volunteers “to develop an online reputation and increase trust between those needing help and those who could offer assistance. Every volunteer profile included not only personal information, but also a history of the individual’s previous activities within the platform.” To this end, in addition to “Help Requests” & “Help Offers,” Rynda also included an entry for “Help Provided” to close the feedback loop.

Asmolov1

As Gregory acknowledges, the results were mixed but certainly interesting and insightful. “Most of the messages [posted to the Rynda platform dealt] with requests for various types of social help, like clothing and medical equipment for children, homes for orphans, people with limited capabilities, or families in need. […]. Some requests from environmental NGOs were related to the mobilization of volunteers to fight against deforestation or to fight wildfires. […]. In another case, a volunteer who responded to a request on the platform helped to transport resources to a family with many children living far from a big city. […]. Many requests concern[ed] children or disabled people. In one case, Rynda found a volunteer who helped a young woman leave her flat for walks, something she could not do alone. In some cases, the platform helped to provide medicine.” In any event, an analysis of the needs posted to Rynda suggests that “the most needed resource is not the thing itself, but the capacity to take it to the person who needs it. Transportation becomes a crucial resource, especially in a country as big as Russia.”

Alas, “Despite the efforts to create a tool that would automatically match a request with a potential help provider, the capacity of the algorithm to optimize the allocation of resources was very limited.” To this end, like the Help Map initiative, digital volunteers who served as social moderators remained pivotal to the Virtual Ryndal platform. As Alexey notes, “We’ve never even got to the point of the discussion of more complex models of matching.” Perhaps Rynda should have included more structured categories to enable more automated-matching since the volunteer match-makers are simply not scalable. “Despite the intention that the ‘matchmaking’ algorithm would support the efficient allocation of resources between those in need and those who could help, the success of the ‘matchmaking’ depended on the work of the moderators, whose resources were limited. As a result, a gap emerged between the broad issues that the project could address and the limited resources of volunteers.”

To this end, Gregory readily admits that “the initial definition of the project as a general mutual aid platform may have been too broad and unspecific.” I agree with this diagnostic. Take the online dating platform Match.com for example. Match.com’s sole focus is online dating; Airbnb’s sole purpose is to match those looking for a place to stay with those offering their places; Uber’s sole purpose is matching those who need to get somewhere with a local car service. To this end, matching platform for mutual-aid may indeed been too broad—at least to begin with. Amazon began with books, but later diversified.

In any case, as Gregory rightly notes, “The relatively limited success of Rynda didn’t mean the failure of the idea of mutual aid. What […] Rynda demonstrates is the variety of challenges encountered along the way of the project’s implementation.” To be sure, “Every society or community has an inherent potential mutual aid structure that can be strengthened and empowered. This is more visible in emergency situations; however, major mutual aid capacity building is needed in everyday, non-emergency situations.” Thanks to Gregory and team, future digital matchmakers can draw on the above insights and Rynda’s open source code when designing their own mutual-aid and self-help platforms.

For me, one of the key take-aways is the need for a scalable matching platform. Match.com would not be possible if the matching were done primarily manually. Nor would Match.com work as well if the company sought to match interests beyond the romantic domain. So a future Match.com for mutual-aid would need to include automated matching and begin with a very specific matching domain. 

Bio

 

See also:

  • Using Waze, Uber, AirBnB, SeeClickFix for Disaster Response [link]
  • MatchApp: Next Generation Disaster Response App? [link]
  • A Marketplace for Crowdsourcing Crisis Response [link]

MatchApp: Next Generation Disaster Response App?

Disaster response apps have multiplied in recent years. I’ve been  reviewing the most promising ones and have found that many cater to  professional responders and organizations. While empowering paid professionals is a must, there has been little focus on empowering the real first responders, i.e., the disaster-affected communities themselves. To this end, there is always a dramatic mismatch in demand for responder services versus supply, which is why crises are brutal audits for humanitarian organizations. Take this Red Cross survey, which found that 74% of people who post a need on social media during a disaster expect a response within an hour. But paid responders cannot be everywhere at the same time during a disaster. The response needs to be decentralized and crowdsourced.

Screen Shot 2013-02-27 at 4.08.03 PM

In contrast to paid responders, the crowd is always there. And most survivals following a disaster are thanks to local volunteers and resources, not external aid or relief. This explains why FEMA Administrator Craig Fugate has called on the public to become a member of the team. Decentralization is probably the only way for emergency response organizations to improve their disaster audits. As many seasoned humanitarian colleagues of mine have noted over the years, the majority of needs that materialize during (and after) a disaster do not require the attention of paid disaster responders with an advanced degree in humanitarian relief and 10 years of experience in Haiti. We are not all affected in the same way when disaster strikes, and those less affected are often very motivated and capable at responding to the basic needs of those around them. After all, the real first responders are—and have always been—the local communities themselves, not the Search and Rescue Teams that parachutes in 36 hours later.

In other words, local self-organized action is a natural response to disasters. Facilitated by social capital, self-organized action can accelerate both response & recovery. A resilient community is therefore one with ample capacity for self-organization. To be sure, if a neighborhood can rapidly identify local needs and quickly match these with available resources, they’ll rebound more quickly than those areas with less capacity for self-organized action. The process is a bit like building a large jigsaw puzzle, with some pieces standing for needs and others for resources. Unlike an actual jigsaw puzzle, however, there can be hundreds of thousands of pieces and very limited time to put them together correctly.

This explains why I’ve long been calling for a check-in & match.com smartphone app for local collective disaster response. The talk I gave (above) at Where 2.0 in 2011 highlights this further as do the blog posts below.

Check-In’s with a Purpose: Applications for Disaster Response
http://iRevolution.net/2011/02/16/checkins-for-disaster-response

Maps, Activism & Technology: Check-In’s with a Purpose
http://iRevolution.net/2011/02/05/check-ins-with-a-purpose

Why Geo-Fencing Will Revolutionize Crisis Mapping
http://iRevolution.net/2011/08/21/geo-fencing-crisis-mapping

How to Crowdsource Crisis Response
http://iRevolution.net/2011/09/14/crowdsource-crisis-response

The Crowd is Always There
http://iRevolution.net/2010/08/14/crowd-is-always-there

Why Crowdsourcing and Crowdfeeding may be the Answer
http://iRevolution.net/2010/12/29/crowdsourcing-crowdfeeding

Towards a Match.com for Economic Resilience
http://iRevolution.net/2012/07/04/match-com-for-economic-resilience

This “MatchApp” could rapidly match hyper local needs with resources (material & informational) available locally or regionally. Check-in’s (think Foursquare) can provide an invaluable function during disasters. We’re all familiar with the command “In case of emergency break glass,” but what if: “In case of emergency, then check-in”? Checking-in is space- and time-dependent. By checking in, I announce that I am at a given location at a specific time with a certain need (red button). This means that information relevant to my location, time, user-profile (and even vital statistics) can be customized and automatically pushed to my MatchApp in real-time. After tapping on red, MatchApp prompts the user to select what specific need s/he has. (Yes, the icons I’m using are from the MDGs and just placeholders). Note that the App we’re building is for Androids, not iPhones, so the below is for demonstration purposes only.

Screen Shot 2013-02-27 at 3.32.29 PM

But MatchApp will also enable users who are less (or not) affected by a disaster to check-in and offer help (by tapping the green button). This is where the match-making algorithm comes to play. There are various (compatible options) in this respect. The first, and simplest, is to use a greedy algorithm. This  algorithm select the very first match available (which may not be the most optimal one in terms of location). A more sophisticated approach is to optimize for the best possible match (which is a non-trivial challenge in advanced computing). As I’m a big fan of Means of Exchange, which I have blogged about here, MatchApp would also enable the exchange of goods via bartering–a mobile eBay for mutual-help during disasters.

Screen Shot 2013-02-27 at 3.34.17 PM

Once a match is made, the two individuals in question receive an automated alert notifying them about the match. By default, both users’ identities and exact locations are kept confidential while they initiate contact via the app’s instant messaging (IM) feature. Each user can decide to reveal their identity/location at any time. The IM feature thus enables  users to confirm that the match is indeed correct and/or still current. It is then up to the user requesting help to share her or his location if they feel comfortable doing so. Once the match has been responded to, the user who received help is invited to rate the individual who offered help (and vice versa, just like the Uber app, depicted on the left below).

Screen Shot 2013-02-27 at 3.49.04 PM

As a next generation disaster response app, MatchApp would include a number of additional data entry features. For example, users could upload geo-tagged pictures and video footage (often useful for damage assessments).  In terms of data consumption and user-interface design,  MatchApp would be modeled along the lines of the Waze crowdsourcing app (depicted on the right above) and thus designed to work mostly “hands-free” thanks to a voice-based interface. (It would also automatically sync up with Google Glasses).

In terms of verifying check-in’s and content submitted via MatchApp, I’m a big fan of InformaCam and would thus integrate the latter’s meta-data verification features into MatchApp: “the user’s current GPS coordinates, altitude, compass bearing, light meter readings, the signatures of neighboring devices, cell towers, and wifi networks; and serves to shed light on the exact circumstances and contexts under which the digital image was taken.” I’ve also long been interested in peer-to-peer meshed mobile communication solutions and would thus want to see an integration with the Splinternet app, perhaps. This would do away with the need for using cell phone towers should these be damaged following a disaster. Finally, MatchApp would include an agile dispatch-and-coordination feature to allow “Super Users” to connect and coordinate multiple volunteers at one time in response to one or more needs.

In conclusion, privacy and security are a central issue for all smartphone apps that share the features described above. This explains why reviewing the security solutions implemented by multiple dating websites (especially those dating services with a strong mobile component like the actual Match.com app) is paramount. In addition, reviewing  security measures taken by Couchsurfing, AirBnB and online classified adds such as Craig’s List is a must. There is also an important role for policy to play here: users who submit false misinformation to MatchApp could be held accountable and prosecuted. Finally, MatchApp would be free and open source, with a hyper-customizable, drag-and-drop front- and back-end.

bio