Tag Archives: geocommons

Our first CrisisMappers meeting took place in Orlando, Florida this past weekend. The meeting brought together a small group of tech professionals who are at the very cutting edge of crisis mapping. It truly was a powerhouse. Ushahidi, Development Seed, NiJEL, Emergencity, GeoCommons, InSTEDD, In.itiative and the Harvard Humanitarian Initiative (HHI). This meeting was mostly self-funded and scheduled on a Saturday. The fact that everyone showed up is a clear testament to the commitment we all have to pushing the new field of crisis mapping forward to the next frontier.

Andrew Turner gave a typical tour de force presentation on some of the most exciting tech-innovations in mapping. I highly recommend viewing his slide show presentations available on Slideshare here. I gave the second introductory talk and chose to highlight two major themes in the future of crisis mapping: Mobile Crisis Mapping (MCM) and Crisis Mapping Analytics (CMA).

The former focuses on our understanding of dynamic mapping platforms as communication tools. In other words, all our communication tools should be fully integrated within our dynamic mapping platforms. Imagine a Google Map interface from which I can receive geo-referenced text messages and forward those messages by SMS broadcast or email right back to the field, without ever having to navigate away from the map. InSTEDD’s GeoChat is a good example of what I have in mind.

Understanding mapping platforms as communication tools poses two challenges common to communication in crisis zones. The first is connectivity while the second is data security. In terms of connectivity, we urgently need to move towards meshed-networked peer-to-peer communication that obviates the need for cell phone towers. As for encryption, SMS encryption should be the default setting on all our communications. Anything less is simply unsatisfactory.

I’ve written about Crisis Mapping Analytics before, so won’t go into detail here. I just want to point out that as our crisis mapping platforms continue to crowdsource data, we will need to make sense of this information in terms of trends over both space and time. We are still far from having any user friendly  point-and-click statistical tools for identifying such trends.

Since I was the only token humanitarian-wanna-be-geek at the meeting, I closed my introductory talk with the following three reminders: (1) if our crisis mapping tools work in humanitarian crises, they’ll work anywhere; (2) we need to identify methods and metrics to evaluate the impact of our crisis mapping platforms; (3) if you don’t keep your crisis mappers as simple as Fisher Price, they are unlikely to be adopted by the humanitarian community; call it the Fisher Price Theory of Crisis Mapping.

Let me expand on the latter point. What our colleagues in the tech-world need to keep in mind is that the vast majority of our partners in the field have never taken a computer science or software engineering course. Most of my humanitarian colleagues have done a Master’s degree in Humanitarian Affairs, International Development, etc. I guarantee you that 99.9% of these graduate programs do not include any seminar on humanitarian information management systems let alone computer science.

The onus thus falls on the techies to produce the most simple, self-explanatory, intuitive interfaces. What we in the humanitarian field want are interfaces as simple as computer games. We want software packages that are simply plug-and-play. Say an iGoogle approach which allows us humanitarians to import various “widgets” such as 2-way SMS broadcasting, wiki-mapping, etc.

The rest of the CrisisMappers meeting was dedicated to a series of thought-provoking presentations on individual crisis mapping projects that each organization is working on. I shan’t attempt a summary here but shall close with the following. I had the good fortune of sitting next to Ushahidi’s David Kobia during the meeting. At one point, he turns to me and motions to his laptop screen: “Look, just got a text message from someone in the DRC.”

David was pointing to Ushahidi’s admin interface, and indeed, someone on the ground had gotten wind of Ushahidi’s new deployment and had texted the dedicated Ushahidi DRC number. The texter was expressing her/his concern that the DRC site was in English which posed problems for French speakers. The text message itself was in French. The Ushahidi team has been working diligently on a French version of the interface and are nearly finished. David asked me if I might be able to reply (in French) to the person and let them know that the completed interface will be ready next week. I did so, and pointed the texter to the “French Flag” icon on the Ushahidi DRC interface.

Here’s what I find particularly neat about this exchange. First, here we were sitting in a conference room in Florida on a Saturday afternoon getting a text message from someone in the DRC interested in reporting events using Ushahidi’s DRC platform. Second, the admin interface that David had up set up was simple and clear to understand. Third, David had included two optional buttons to send one-click replies to the text messages he receives: (1) please send us more information on the event; (2) please send us more information on the location event. Simple yet elegant. After I finished typing my reply to the sender of the text message, I clicked on send and off went my message, right back to the field. All this took place in less than five minutes.

Patrick Philippe Meier