The organizations being honored today are:
SODNET – Social Development Network (Kenya) For the work on Uchaguzi Kenya, and Huduma.info
Pamoja Media – Joshua Wanyama (Kenya) For the Wildlife Trackers Deployment
Citivox – Oscar Salazar (Mexico) For Cuidemos El Voto
Small World News – Brian Conley (Afghanistan and Bahrain) 3 deployments for elections in Afghanistan and in October 2010, elections in Bahrain
Digital Democracy – Mark Belinsky (USA)
Emoksha – Selvam Velmurugan (India)

Our dream team is composed of Rob Baker, John Etherton, George Chamales, Anahi Ayala and Jaroslav Valuch. When we prepare to release a new version the Ushahidi platform, they’ll be granted early access to the new code. They’ll take it out for test drives on various terrains, pushing the code to the max. Together with the Ushahidi Tech Team, they’ll identify bugs and swat them. We hope this will make our new releases more robust; so many thanks to the first members of Ushahidi SWAT for their time and invaluable support.

If you’re interested in joining Ushahidi SWAT, please fill out this form. There is a vetting process since this a team of advanced users who are part of our official quality assurance processes. If you think you’ve got it what it takes to swat Ushahidi bugs, then please apply! We will be working with the community to improve the process as we move forward.

• Clickatell - an SMS Gateway
• FrontlineSMS – A simple way to turn your mobile and laptop into a communication hub
• SMSSync (An application that will turn your Android phone into an SMS hub.

In addition to the options above, there is the standard email, twitter or reporting form as channels of participation. A mix of these channels can be made in consideration of the context, duration, and scope of the Crowdmap. With this in mind and the fact that we have varying levels of connectivity around the world. One of the ways the organization is working to help deployers and users of the different Crowdmaps to know what is available to contribute to is by:
1. Adding deployment search functionality to the mobile applications. This has been incorporated into the Ushahidi iPhone/iPad and Android applications.
Using your smartphone, you can search for Crowdmaps based on your location by specifying the radius you are interested in. For more on that either click on the graphic below or read more in the recent blogpost from Henry Addo regarding the new Android application.

2. Adding deployment search on Crowdmap.com. You can search by any Keyword, e.g elections, uganda, Amnesty International – Give it a spin and see which Crowdmaps are available for you to contribute to.

3. Our community site has a listing of deployments and is the congregating point for sharing information, plugins/add ons with the rest of the global Ushahidi community. You can add your deployment onto the listing on the site. These two systems are currently separate but we plan on integrating them soon.

The decision to be listed on this public listing remains that of the deployer. For instructions on how to change your settings so that your deployment is more discoverable, please see this brief video made by Brian Herbert.

We welcome your feedback regarding these steps in helping our users and deployers deal with discoverability. There will be more enhancements in future. As always let us know how we can make things better.

Heather Leson is our “Director of Community Engagement”. This means she’s responsible for coming up with the strategy for how we interact better with our non-tech users, and then implementing it. She’s the one who you’ll be in touch with on the Community.Ushahidi.com side, and who will help muster the right mix of case studies, tools and use-cases that make running your own deployment easier.

Heather comes with a boatload of community work. Hailing from Canada, she has over 10 years of experience in technical incident management, software life cycle development, customer care and communications in Internet technologies. In fact, I first met Heather (virtually) as we each led the Random Hacks of Kindness discussions between the Australia and Kenya teams last year. She was an important part of the growth of CrisisCommons, and has helped run multiple unconferences and hackathons.

Heather comes with the right mix of community engagement background, mixed with our ethos of open source, open ideas and open community. We’re SO excited to have her join us, and we hope that you’ll reach out and start engaging with her right away. After all, she is your ambassador within Ushahidi.

I’ve spent the past week at the iLab in Liberia and got what I came for: an updated reality check on the limitations of technology adoption in developing countries. Below are some of the assumptions that I took for granted. They’re perfectly obvious in hindsight and I’m annoyed at myself for not having realized their obviousness sooner. I’d be very interested in hearing from others about these and reading their lists. This need not be limited to one particular sector like ICT for Development (ICT4D) or Mobile Health (mHealth). Many of these assumptions have repercussions across multiple disciplines.

The following examples come from conversations with my colleague Kate Cummings who directs Ushahidi Liberia and the iLab here in Monrovia. She and her truly outstanding team—Kpetermeni Siakor, Carter Draper, Luther Jeke and Anthony Kamah—spearheaded a number of excellent training workshops over the past few days. At one point we began discussing the reasons for the limited use of SMS in Liberia. There are the usual and obvious reasons. But the one hurdle I had not expected to hear was Nokia’s predictive text functionality. This feature is incredibly helpful since the mobile phone basically guesses which words you’re trying to write so you don’t have to type every single letter.

But as soon as she pointed out how confusing this can be, I immediately understood what she meant. If I had never seen or been warned about this feature before, I’d honestly think the phone was broken. It would really be impossible to type with. I’d get frustrated and give up (the tiny screen further adds to the frustration). And if I was new to mobile phones, it wouldn’t be obvious how to switch that feature off either. (There are several tutorials online on how to use the predictive text feature and how to turn it off, which clearly proves they’re not intuitive).

In one of the training workshops we just had, I was explaining what Walking Papers was about and how it might be useful in Liberia. So I showed the example below and continued talking. But Kate jumped in and asked participants: “What do you see in this picture? Do you see the trees, the little roads?” She pointed at the features as she described the individual shapes. This is when it finally dawned on me that there is absolutely nothing inherently intuitive about satellite images. Most people on this planet have not been on an airplane or a tall building. So why would a bird’s eye view of their village be anything remotely recognizable? I really kicked myself on that one. So I’ll write it again: there is nothing intuitive about satellite imagery. Nor is there anything intuitive about GPS and the existence of a latitude and longitude coordinate system.

Kate went on to explain that this kind of picture is what you would see if you were flying high like a bird. That was the way I should have introduced the image but I had taken it completely for granted that satellite imagery was self-explanatory when it simply isn’t. I really kicked myself on that one. In further conversations with Kate, she explained that they too had made that assumption early on when trying to introduce the in’s and out’s of the Ushahidi platform. They quickly realized that they had to rethink their approach and decided to provide introductory courses on Google Maps instead.

More wrong assumptions revealed themselves during these courses. For example, the “+” and “-” markers on the map are not intuitive either nor is the concept of zooming in and out. How are you supposed to understand that pressing these buttons still shows the same map but at a different scale and not an entirely different picture instead? Again, when I took a moment to think about this, I realized again how completely confusing that could be. And again I kicked myself. But contrast this to an entirely different setting, San Francisco, where some friends recently told me how their five year old went up to a framed picture in their living room and started pinching at it with his fingers, the exact same gestures one would use on an iPhone to zoom in and out of a picture. “Broken, broken” is all the five year old said after that disappointing experience.

The final example actually comes from Haiti where my colleague Chrissy Martin is one of the main drivers behind the Digicel Group’s mobile banking efforts in the country. There were of course a number of expected challenges on the road to launching Haiti’s first successful mobile banking service, TchoTcho Mobile. The hurdle that I had not expected, however, had to do with the pin code. To use the service, you would enter your own personal pin number on your mobile phone in order to access your account. Seems perfectly straight forward. But it really isn’t.

The concept of a pin number is one that many of us take completely for granted. But the idea is often foreign to many would-be users of mobile banking services and not just in Haiti. Just think about it: all one has to do to access my money is to simply enter four numbers on my phone. That does genuinely sound crazy to me at a certain level. Granted, if you guess the pin wrong three times, the phone gets blocked and you have to call TchoTcho’s customer service. But still, I can understand the initial hesitation that many users had. When I asked Chrissy how they overcame the hurdle, her answer was simply this: training. It takes time for users to begin trusting a completely new technology.

So those are some of the assumptions I’ve gotten wrong. I’d be grateful if readers could share theirs as there must be plenty of other assumptions I’m making which don’t fit reality. Incidentally, I realize that emerging economies vary widely in technology diffusion and adoption—not to mention sub-nationally as well. This is why having the iLab in Liberia is so important. Identifying which assumptions are wrong in more challenging environments is really important if our goal is to use technology to help contribute meaningfully to a community’s empowerment, development and independence.

This is a quick infographic I made while thinking about a phenomenon that often occurs around Ushahidi deployments. You can sort of think of this as a ‘spectrum of interest’ over the life of a disaster or crisis event. I’ve mulled this over for a while, but the idea for the graphic came on a call this morning with Steven Longmire, Catherine Graham and Nicholas Bartlett (from GeoOp) who wanted to discuss the Christchurch quake deployment.

On one side you’ve got peak concern, enthusiasm and interest. An event occurs, the media explodes with coverage and people get involved. This is what I define as the attention stage. It also happens to be where the most data gathering or surveillance occurs. Participation, whether it be experts to experts, volunteers to volunteers or experts to volunteers is critical because everyone needs as much information as possible. Meanwhile, the public’s (the victim’s) needs are also at their peak. Urgency and momentum is highest here.

As the scenario unfolds, we move into what I call the advocacy stage. This is usually where public attention, and mass media coverage tends to stabilize and decline. The focus becomes less about what’s occurred, and more about mobilizing resources to do something. This is also where knowledge is transfered, groups tend to convene on the ground to begin the next phase.

The last stage is what I call the accountability stage. It’s where recovey happens, public attention was waned as people are drawn to whatever big event is now in the news. Groups who’ve made themselves accountable now deal with the real difficulties, the expectations of the public to do something with the data they’ve collected.

Now obviously, there is no clear linear separation between the three of these, it’s much more diffuse, and individual interactions or actions may move through all of these phases at different paces. For instance, the request from someone in the public for help, equally is urgent, requires analysis/action, and needs someone accountable for following through. Also, where these ‘stages’ meet, it’s important to consider the role of the technology in place. A tool in place to manage one process, may not be the same tool required to manage another. However, I’m well aware of efforts to make the Ushahidi platform more efficient at traversing each of these stages, if only to allow it to communicate with tools that were designed for each vertical (for instance GeoOp really shines in the Advocacy and Accountability stages).

Anyways, this is just my own visual brainstorming. I’d love the feedback from anyone who has thoughts on this and how I can improve the graphic.

Voix des Kivus

A crowd-seeding system in Eastern Congo that uses cell phones to obtain high-quality, verifiable, and real-time information about events that take place in hard-to-reach areas. This pilot project is led by Peter van der Windt and Macartan Humphreys from the Center for the Study of Development Strategies at Columbia University.

The pilot

Atrocities in hard-to-reach areas – for example many areas in Eastern Congo – often go unnoticed because of the lack of accessibility, both due to poor infrastructure and to the simple fact that fighting makes it too dangerous to get close. The inability of international organizations and humanitarian NGOs to collect information under these conditions hampers the provision of assistance in a timely and effective manner.

There is fast growing recognition of the role that technology can play in addressing these problems. But a real challenge faced by many approaches is the difficulty of getting data that is not just real time, but representative. Columbia University (with support from USAID) began the Voix des Kivus pilot project in summer 2009 to assess the technical feasibility of a decentralized, representative, SMS-based information system in the region and to assess the utility of the program to participating communities and potential users. Presently (beginning 2011) the program is operating in a random sample of 18 villages from four territories of the war-torn province of South Kivu in the Democratic Republic of Congo.

Phoneholders and the goal

It works like this. In each village participating in Voix des Kivus there are three cell phone holders: one representing the traditional leadership, one representing women’s groups, and one elected by the community. Holders are trained extensively on how to send messages to the system. They are provided with a phone, monthly credit, and a codesheet that lists possible events that can take place in the village. Sending messages to the system is free but it is also voluntary – while users do not have to pay for each message they do not get any financial rewards for sending content to the system.

For participating communities Voix des Kivus provides a system for creating histories, archiving testimonies, and communicating with the rest of the world about events that affect their daily lives. For researchers and practitioners working in the region the information gathered forms an important resource to learn more about the situation on the ground in hard-to-access areas.

Technology and the data

The technology for Voix des Kivus is cheap to set up and simple to use. Built on the freely available FrontlineSMS software, the system allows holders to send numeric or full text posts from almost any cell phone. On the receiving side a standard cell phone linked to a laptop linked to the internet comprise the necessary equipment. With other freely available software (R and LaTeX – our code is available upon request), messages received are automatically filtered, coded for content, cleaned to remove duplicates, and merged into a database. Graphs and tables are automatically generated which can then be automatically mounted into bulletins spanning any period of interest and with different levels of sensitivity. Translations of non-coded text messages (often from Swahili into French and English) are undertaken manually.

Over the last 18 months phone holders have sent thousands of pre-coded and text messages ranging from reports of attacks and abductions to reports of crop diseases and floodings. The constant flow of data from our phone holders is kept in a database and captured in weekly bulletins. Each Monday a bulletin is produced and disseminated that presents events that took place in the preceding week. These bulletins are shared with organizations that have received clearance from Voix des Kivus and its phone holders. The latter includes several development organizations based in Bukavu, DR Congo who can use the data to evaluate the situation on the ground throughout the region.

The figure gives the cumulative number of messages sent per phone holder since the summer of 2009. Phone holders show no sign of reporting fatigue (the slope of the lines do not decrease). As you can see, Voix des Kivus expanded from June 2010 onwards.

Crowseeding vs crowdsourcing

An important question for a system like this is whether the messages received can be trusted. Here we find the true value of crowdseeding. In most crowdsourcing approaches anyone can send information directly to the system. Crowdseeding works in a more restricted way with phone holders that are pre-selected, and only they can send in information. Crowdseeding has three main advantages for data quality: 1. The data is received from a representative set of areas; 2. All senders are known to the system and are in a  long term relationship with the Voix des Kivus program; 3. Because more than one holder is selected in each village “internal validation” is also possible. The system can also be used for sending information to holders and for engaging in more interactive forms of data collection. There are also disadvantages of this approach relative to crowdsourcing, the most obvious is that because of their relation with the program there may be concerns about the security of holders.

What we learned from the pilot

We have learned a lot from the pilot. The technical and social capacity is there right now. Interest in participating areas has been very great as witnessed by the steady stream of messaging. Technical barriers were also not as great as expected; solar technology can be used to power phones in the most remote areas and cell phone coverage is much greater than some maps suggest. Data quality appears good with fairly high levels of internal validation. Two questions though are still unanswered. First although we encountered no security concerns we do not know how safe the system would be for holders if it operated on a larger scale. Second, we don’t know whether this information will get seriously used. At the scale in which we have been operating many organizations expressed great interest in the concept and the data; but we do not know of any serious reactions from international actors to the messages coming in, including real time reports of attacks and abuses. Phone holders have continued to engage with the system despite the poverty of reactions, but we cannot expect that to continue forever.

Continuation?

After operating for more than  a year and a half as a pilot in Eastern Congo, the Voix des Kivus experience suggests that obtaining verifiable, high-quality data in real-time from these hard-to-reach areas is not only possible, but needs much less expense and oversight than previously thought. Our pilot is now coming to an end and Columbia is bowing out from Voix des Kivus. The big question we face now is whether and how to continue the system after the pilot, whether this should be run by a domestic group or an international group, whether this should continue as an open resource or as a resource tied to the operations of organizations that can respond. Please post your thoughts here.

For more information see: http://cu-csds.org/wp-content/uploads/2009/10/Voix-des-Kivus-Leaflet.pdf and www.cu-csds.org

Why did it work?

The “Trust Bridge”

Over the past three years we’ve seen thousands of Ushahidi deployments (12,000+ as of this writing), some of them big, many of them small. We always think about what makes a deployment successful. Why do some catch on and others don’t?

The common denominator for successful deployments that get the crowd involved, where communities are engaged and using the platform for both sending and receiving information, is that they’re run or endorsed by people or organizations that people trust. These entities form what I call the trust bridge. They’re the necessary glue that brings credibility and trust to a deployment so that people are willing to take part.

In the case of Kenya 2008, the reason that the first version of Ushahidi worked was because the public trusted us, the primary drivers and bloggers. Those of us behind the building of Ushahidi were well known and credible to thousands of readers, who in turn took that trust and passed it on to their friends and family in Kenya and in the diaspora.

The same applies to deployments of the platform in places like New Zealand earlier this year, where an open community worked and drove a successful operation. In Haiti, where a group of trusted organizations and volunteers came together to coordinate a rapid crowdsourcing response. The same applies to many others, including Japan, Australia, Kenya’s referendum and the Russian fires.

Building Your Trust Bridge

How do you get to a place where you’re the trusted entity?

The short response is that it doesn’t come at the time of an emergency. This applies if you’re an individual or a large organization starting something off; you have to have credibility and trust from others in order to gain traction.

The longer answer is that assuming you have that first level of credibility, you still should look for further verification and trust building through other trusted intermediaries vouching for you. There are a couple ways you can build this:

Partnerships – Find other organizations that fill roles that you lack or that share the same mission as you. Encourage them to take on roles that are highly inclusive and transparent to the community that you’re interacting with.

News Media – Contrary to popular belief, crowdsourcing and new media do not do away with traditional media. Over the years, these organizations have built up a certain amount of credibility. If your local media is compromised, you should still reach out to international media for coverage. One of the great benefits of international media is that they attract the diaspora to your cause, who in turn can volunteer or spread the word on the ground through their local family/friend networks.

Community – The most successful deployments of Ushahidi are those that are done by, and for, members of the community which is affected. Instead of closing off operations, messaging and administration of the deployment you should instead be reaching out to and openly involving these members to be a part of it. Give responsibility and extend your reach.

The technology that is the Ushahidi platform, Crowdmap and SwiftRiver are excellent tools. However, deploying of these tools is only the first, simple step, in a successful crowdsourcing and community engagement. Building trust bridges, communicating openly and effectively and running a well administered site are the real juice that makes a deployment catch on and thrive.

The outcome was about looking outwards while fixing inwards, and through discussion forums, and shared housekeeping tasks, achievements included:

• Translating targets into achievable milestones and see how they mesh with the various arms- Core, SwiftRiver, Mobile, iHub, Crowdmap – so that if this was a relay race, a visual of where passing the baton fits into the race.
• A better understanding of the products and how they fit across platforms.
• Realignment of the structures of the various teams to improve on product quality.
• Evaluation of the performance of team members and a framework was developed for future evaluations.
• First steps to develop frameworks for future Ushahidi project and community participation.
• Affirmation of achievements in the last year by both internal and external partners. This included a demonstration of the Liberia project, which is very unique in terms of the challenges faced in deploying crowd-sourced platforms in Liberia, which are different from other African situations.
• A chance to hear and respond to various queries of team members around the world, and appreciate the challenges they face in the countries they live.
• A better understanding of the tools the enable internal working & virtual collaboration across  nine time zones (soon to be 16).
• Introduction of new team members (including myself), and immediate bonds were formed that will be vital for collaboration over the next few months.  I also learnt to appreciate the sacrifice of time that team members make by frequent travels around the world, and that the “Up in the air” lifestyle is not as glamorous as it looks from the outside.

Finally, what was refreshing was that, in this this 3-year old company, there was the willingness to break down structures and tear up established models in recognition that the next three years may be radically different. Plus, in all this, there  was fun as people got crowned with, among other titles, ‘Governors’, ‘Dictator’, ‘Mr. Goosebumps’, ‘Director of SWAG’, and ‘Director of Insanity’!

The Ushahidi core team works from 7 different timezones ranging from Kampala to Louisville, soon expanding to places like Brazil and Korea. One weekend a year we’re able to get together, in-person, to solidify our connections with each other and talk through the big strategic topics that are best done face-to-face. It could be argued that it’s the most important 3 days of the year for us.

The First XV

2010 was a big growth year for Ushahidi, where we got up to 12 core team members – doubling in size from 2009. We’re adding 3 more people this year, which brings us to 15, a fortuitous number for the team as many of us are big rugby fans.

(Caleb decided to have a little fun, putting us all in our positions based on the date that we joined the team.)

12 Months Later

Last year we met in Miami, as we are this year, and a lot has happened since then. To name the big ones:

• Plugins – extensible way to add new functionality without bloating the core
• Crowdmap – maps for non-developers, also a means to quickly collect reports giving deployers time to install their own server
• SMSSync – simple and robust alternative to Frontline and Clickatell
• iOS – rich smart phone experience
• Checkins – opens platform to entirely new uses
• Stand-By Task Force – game changer in disaster response
• J2ME – extending reaching onto older devices
• Community Site – fantastic documentation
• Map Geometry

Looking at the historical record, it’s been a good year. However, there’s a lot more to do. At this meeting, besides drinking a Mojito on South Beach, we’ll get into some of the big future-looking issues, such as:

Visual Reporting: What’s the perfect Ushahidi dashboard? How do we surface “power stats” for Ushahidi deployments and metrics. Swift-Ushahidi integration visuals on the front and back end.

Knowledge Management: How do we come up with a plan to capture information that we know internally, so that it is shared with deployers and developers better?
The inverse, how do we handle and capture information that our *users* know regularly?

Crowdmap Scalability & Migration: Making sure that even the biggest deployments work on Crowdmap. Adding in new a la carte features, etc.

Of course, this is a chance to discuss some of the more mundane items as well, around operations, funds and how we work towards organizational financial sustainability as well. It also means that we’ll be offline from today until about Tuesday of next week. We’ll be a little slower on email and other communications mediums, but bear with us as it’s for a good cause.