Pairing VAC Benin Data with Mapbox and TileMill

For the first month of the summer I worked with Plan Benin on their effort to use Ushahidi to collect and visualize reports of violence. Ushahidi is great for crowd-sourcing reports via a variety of channels and offers visualization capabilities for browsing data on the deployment’s website. I thought it would be neat to visualize the VAC Benin data on a custom map that isn’t on the list of supported basemaps in Ushahidi, most of which don’t provide very good local data for Benin. While it’s possible to add map overlays to your Ushahidi deployment, I decided instead to run everything through through MapBox, which provides a suite of tools for creating and hosting custom maps. MapBox comes from the team at Development Seed, where I’m spending the remainder of the summer break.

Using TileMill, MapBox’s open source custom map studio, I created a map that includes only the data relevant to Plan Benin’s activities on this project. In particular, it includes GIS data for Atacora and Couffo, the two “Program Units” where Plan operates. Those are in light blue on the map in the northwest and southwest corners of the country, respectively. I also included labels for the important cities in both Program Units. The red dots indicate the reports of violence and if you mouse over a dot you can see a summary of the incident. If you click on the incident, you see more information. This interactivity is baked right into TileMill. The reports were geolocated by hand using information in the text messages. The map also incorporates the World Bright basemap, which includes country borders, custom labels, population centers (in light yellow/brown tones), and other information.

Though this is really the tip of the iceberg in terms of what TileMill can do — it would also be possible to add multimedia-rich interactivity, use a choropleth scheme to indicate hotspots of violence, cluster reports, etc . — I think it is easy to see how this custom map improves the experience of interacting with data collected through Ushahidi. Highlighting the Program Units draws the eye to the important areas, adding custom map labels solves the problem of local data being absent from the major map providers, and the built-in interactivity means that visitors don’t need to browse to multiple pages (a killer in low-bandwidth environments) to view information on individual reports. Plus the map is super fast!

Finally, TileStream hosting makes it easy to host the map and generates embed code so the map can be widely shared. Take a look at the map below and feel free to click over to the VAC Benin Ushahidi site to see the difference for yourself.

VAC Benin Data Collected via Ushahidi and Visualized via TileMill:

Working with Ushahidi in Benin

Plan Benin uses Ushahidi to map reports of violence against children in Benin. The platform is powerful right off the shelf (or right out of GitHub, as it were) and the latest version offers enough features to get the majority of deployments up and running without issue.

One benefit to working with Ushahidi — there are other options for gathering and mapping reports, of course — is that the global Ushahidi team works hard to cultivate a community of software developers hell bent on improving the software and innovating around new use cases. During my month in Benin I took advantage of a number of resources available to individuals and groups using Ushahidi. A few resources I consulted when working on solutions to technical problems:

• the Ushahidi user manual published by Anahi Ayala Iacucci and the Ushahidi team in March;
• the Ushahidi developers chat on Skype;
• the Ushahidi forum;
• the Ushahidi wiki; and
• individual staff and freelance developers (thanks in particular to Henry Addo, a full time Ushahidi staffer and John Etherton, a technology consultant who develops tools for Ushahidi).

In addition to making use of Ushahidi’s standard functionality, in Benin we’ve made some small customizations, configurations, and tweaks to that extend the functionality of the system, making it easier and faster to use. A few tweaks:

• FrontlineSMS – after upgrading to the latest version of Ushahidi, we made use of the new Plugin architecture and activated the FrontlineSMS plugin, which facilitates a seamless connection between FrontlineSMS and Ushahidi.
• Location highlight – developed by John Etherton, this plugin improves the experience of mapping locations in areas that are not well-mapped. Instead of staring at a blank map, users creating reports can select the program area and nearby city from a drop down menu. Administrators can add as many points or areas as they’d like to aid the mapping process. Furthermore, the relatively slow internet connection in Benin makes loading map tiles and labels a painful process. In many cases, Location Highlight allows users to avoid having to load new zoom levels.
• Nested Categories - a visual improvement more than anything, this functionality is supported out of the box. Rather than loading the Ushahidi landing page and seeing 20+ categories, we now see the major categories and users have the ability to drill down on the various categories to filter results.
• Custom forms - the use of custom report forms with private fields allows Plan Benin to track information related to cases alongside the public report, allowing Plan staff in disparate geographies to track the reporting and resolution of incidents.

Nested categories and the location highlight plugin:

Carpet Salesman in Cotonou

Future Proofing the VAC Benin Project

Wishful thinking! There is of course no way to “future proof” an information and communications technology (ICT) for development project. There are ways, however, to ensure that an ICT project has a fighting chance at sustainability. Here in Benin we’re revisiting the entire Violence Against Children (VAC) Benin workflow in an effort to document the non-technical aspects of the project so that each person that touches this system fully understands the way that information moves through it. In addition to supporting training, this small but critical step will help drive consensus around how the project should and can work well into the future.

A succinct overview of this project:

The beginning of any development initiative is often marked by energetic optimism. At the onset, when a project enjoys the attention and enthusiasm of its creators and supporters, it is easy to forget that over time this attention will wane, priorities will shift, and critical personnel will undoubtedly take on new responsibilities or even different jobs. Purposeful problem definition and documentation can minimize the impact of these eventualities and only with a thorough understanding of the problem is it possible to discuss appropriate technology-enabled responses. And yes, in the real world, the problem often shifts over time as the situation changes or new information comes to light. But with a well-defined problem you have clarity around your intent and can face new challenges head-on.

Once defined, the problem and corresponding solution must be documented so that others may benefit from the insight gained during this process and apply that insight systematically. This seems elementary, of course, but in years of ICTD work I’ve found that the documentation of both technical systems and non-technical processes is often neglected in the rush to deploy or as a result of over-reliance on a few knowledgable individuals. Furthermore, in international development, documentation sometimes plays second fiddle to the production of reports and case studies.

Now I’ll happily get off my soap box and get back to business in Benin.

After sketching out the various aspects of the information flow with my colleague Elsie, I documented the workflow in a way that can be used to inform, train, and guide others as they interact with this project. I’m working on reference materials of different shapes and sizes including a number of graphics. Several of the graphics appear below; these are drafts and will be revised with Elsie, translated, distributed to the team, and revised again. These graphics represent the way we would like the system to work and are intended to be living documents.

In this graphic I included all the critical actors and their key responsibilities:

In this flow chart, I illustrated the way that messages should be processed:

In this graphic, I illustrated the way that reports should be created:

Finally, this flow chart will support report approval and verification:

Pineapple Salesman in Cotonou