#ukgc12 session on Ushahidi and Crisis Mapping write-up

January 24, 2012

I pitched a session on Ushahidi and Crisis Mapping at UK Gov Camp last week. I’ve been playing around with Ushahidi for a little while and paying attention to how these communities are developing. I really think we are at the beginning of a profound humanitarian movement.

It’s not a well-understood platform in the UK and there aren’t many crisis mappers in the public sector. So it was intended as a sort of Ushahidi 101.

Also I’m no developer so I was only able to talk about the application of the application.

I’ve got to say, talking a room full of clever and engaged people through a topic is a fantastic way of improving your own understanding of it. Thanks to everyone who came, this is hopefully a more coherent introduction to the topic thanks to your help, comments and questions.

Ushahidi
In early 2008 some Kenyan developers were concerned about the levels of violence following the disputed elections in their country. They wanted an independent source of reports of what was happening and where. They built a platform that allowed people to SMS reports which could then be placed on a map. They called it “Testimony” in Swahili (Ushahidi). The code was released as open-source and a developer community has been working on the platform ever since.

It can be downloaded and installed on your own server but, luckily for me, the community provides a simple cloud-based solution at crowdmap.com. Sign up and start your own Ushahidi instance.

I set up a simple instance for Gov Camp at ukgc12.crowdmap.com and asked people to submit simple reports: home base and favourite fruit. Thanks to everyone who did.

Reports can be submitted using a customisable form on the instance. This allows the user to plot their location on a map: Ushahidi uses external mapping services, I set mine up to use Google Maps but this is customisable.

The platform will also pull data from an IMAP or POP3 mailbox, through the twitter API and through RSS. It will also handle SMS from a gateway. I installed the SMSSync plugin which allows any android device to become a temporary SMS gateway.

Essentially what Ushahidi does is allow you to place “reports” onto a map. Reports contain text and links to other content. Human beings have to be involved and the platform provides some workflow.

Submissions made through the web form are already reports and so can be placed on the map by checking a box. They then become public (if it’s a public map) or available to restricted users. Reports will be placed into one or more categories and the map can quickly filter for reports matching only some categories.

There is a “verified” option. So you can place reports on the map but indicate that they are unverified. Admins can edit the reports at any time. The system maintains an audit trail of edits.

For other data (email, SMS etc), an admin must create a report to get the data onto the map. The platform is helpful and tracks what happens to individual items.

And you end up with something that looks like this (because Ushahidi uses are often transient you end up with a lot of screenshots rather than links).

Screenshot of the Christchurch Recovery Map

This is the recovery map for Christchurch, NZ post earthquake. Reports there included things like “working wifi” “working landerettes”.

So you can see that the platform has possibilities for a range of uses. It also requires a degree of skill and judgement to be applied in the processing of data into reports.

A practice of “Crisis Mapping” has evolved across the world.

Uses of Ushahidi (Crisis Mapping)
Not all uses of Ushahidi occur in a crisis. Not all crisis mapping occurs on Ushahidi but there is a close relationship between the platform and the practice.

There are a number of ways in which the platform is commonly used

Open crowdsourcing
The general public is invited to submit reports. One or more people process these reports and place them on a map. Usually public.
Nice example: Al-Jazeera English has been asking people in Somalia “How has the Somalia Conflict affected your life?” Responses come back by SMS. They are then translated by volunteers within the diaspora and placed on an Ushahidi map.
The real experience of humans in conflict while that conflict rages.

Bounded crowdsourcing
A closed group of trusted individuals monitor data feeds for particular types of information. They process reports and place them on an Ushahidi instance.
Nice example: The Standby Taskforce which is a global volunteer movement was asked to build a Libya Crisis Map for UN-OCHA during the Libyan conflict in 2011. In the end SBTF did this and then trained UN online volunteers who took over the map. There is a complex workflow required to assess the veracity of reports and create robust data. Much of this has to be handled off the Ushahidi platform.

The output was provided privately to UN-OCHA who then published a redacted version 24hrs later.
(disclosure: I’m a volunteer with SBTF though I was not active on the Libya deployment)

This blog post from a UN-OCHA employee is an interesting read.
Media monitoring
One person or a small group tracks RSS feeds for news and reports relating to a single issue.
This is a UK example with frustratingly little contextual information. Clearly it tracks reports of public sector cuts though

For more information try

• https://crowdmap.com
• http://ushahidi.com/
• crisismappers.net
• Or give me a shout @likeaword

[EDIT: Several minutes after posting]

And also I pulled together a few links onto a google  doc. Some of which are in the post above.

Photo credit:
Photo is by the genius-like #ashroplad pulled from the #ukgc12 flickr stream and used under CC

Screenshot is from the Christchurch recovery map and used under CC

20 thoughts from #ukgc12

January 22, 2012

On Friday and Saturday I went to the UK Gov Camp in London. Along with about 300 other, fairly geeky, people. It’s an annual unconference full of energy, ideas and a lot of typing. The excellent Dan Slee has floated the idea of noting down 20 things that struck one after the event. These, for better or worse, are my 20.

I have more to write, in particular about open data in housing, housing benefit apps and Ushahidi. But for now:

1. My netbook running Ubuntu Linux is way cooler than your Macbook Air

2. Many of the issues relating to open data relate to the way organisations perceive and use data rather than openness

3. If anyone asks you to show the ROI of social media you should explain to them that they know nothing about communications

4. The public sector is massive, complex and messy. And it’s only one part of public services

5. We must not lose sight of accountability, governance and power issues in the quest for excellent services

6. When do we move the open data debate out of the state and into corporates?

7. The Ushahidi community and the wider crisis mapping communities are a bit wonderful

8. It’s really healthy to ask why we do this thing (or that thing, or a third thing)  at all

9. Talking is great, doing is better, doing without talking first is a waste

10. We maybe don’t have as many models of mutuality as we could do

11. Open data is a governance issue for every organisation. Or should be.

12. QR Codes are so much more wonderful than I had imagined

13. Brompton riders rule

14. While Sharepoint may not be evil, it is a pig. Still, properly wrangled, it’s amazing what a pig can achieve

15. Putting things on maps is cool. Giving others the power to put things on maps is disruptive

16. Shropshire leads the world in Jelly (the foolishly named co-working movement rather than the trifle ingredient). Jelly shows how economic development could be really different

17. We need leaders who understand networks

18. We need to understand networks

19. I am very tired

20. This year will be all about Ushahidi.

Photo is by David J Pearson and depicts one of the delegates (Puffles). Used under CC BY-SA-2.0.

Your website will fail

January 12, 2012

Your corporate website is robust right? Massively over-specified servers, redundancy and clever load balancing technology make it seamless at managing demand several orders above base level. Clever and dedicated geeks monitor its every move, tweaking and adjusting to keep everything humming along nicely.

No matter. It will still fail.

Websites do fail. They fail all the time and the consequences may well be felt in the real world.

In the Queensland floods local authority websites were overwhelmed by demand for the flood inundation maps at precisely the moment when failing to deliver those maps had severe consequences.

Social networks can spike demand on servers in surprisingly short order to extreme effect. These networks are increasing in scale geometrically.

And there is always a risk of malicious actions, someone pouring coffee into a key router or a problem upstream in the DNS ecosystem.

So what can you do?

1. Clearly continue to work hard to make sure the website doesn’t fail. Critical systems are much more reliable these days than even a few years ago. Cloud-based systems have attraction for their resilience (though may give information managers the heebee geebees).

2. Have excellent back-up arrangements. Plan, exercise and refine the process of restoring from a backup. I work with an EU web-based company who lost their server and found that the promised back-up arrangements were nowhere to be seen. This is not something you want to discover when the data has been lost. The fact that you can sue won’t help your customers on that day.

3. Have alternative web procedures: a “dark site” which gets fired up in extremis or mission critical data distributed onto other platforms. You will also need a plan about how to let people know where this data is to be found. An attractive feature of the growth of social networks is that you can communicate with customers online in a range of platforms. So if you fire up dark.marchford.gov.uk you can let your facebook users know at least.

4. You could also look at this critical data in your web architecture. Maybe those flood inundation maps should be stored on an Amazon machine and not in your server at all. Maybe they should be available in a range of file sizes and quality, delivering smaller files at times of high demand.

5. Exercise. Pull the plug: at 3 on a Sunday morning, in the middle of a live multi-agency exercise, at 1030 on a Friday night. Test those procedures, improve them, make them normal practice.

But the key is to start thinking “when this website fails, what will customers do, what will we do?”.

Because your website will fail.