incommunicado

[Cross-posted from PakReport Blog, written by Jaro Valuch of Konpa Group]

It was clear pretty early after the earthquake in Haiti in January 2010 that the disaster was exceptional in the scale of destruction as well as it was exceptional in the scale and type of response it triggered. Particularly unprecedential was the response from tech and crisis mapping community.

I was a part of the team that deployed haiti.ushahidi.com platform at Fletcher school in Boston, spent first two weeks as a SMS processing lead coordinating the flow of incoming SMS reports, their processing and dispatching to the first responders. Right after that I worked directly in Haiti in order to collect feedback, identify local hand off partner and assess the potential place of ushahidi data feeds in traditional humanitarian information management systems. Later on I participated in a number of events that were focused on the lessons learned from Haiti.

Ushahidi Haiti deployment was already documented in a variety of sources so I am not going to go in too much details here. Based on the lessons learned so far, it is clear that this deployment introduced a new concept of communication with disaster affected communities. However, it still needs to be clarified what was the actual scale of impact and what are the lessons learned for the future. External evaluation is ongoing and lessons learned process is unfinished as we continued working in Haiti also after the emergency period was over (http://blog.ushahidi.com/index.php/2010/08/18/haiti-noula/).

One question nevertheless resonated within our team for months already: What could be the ideal scenario of Ushahidi deployment in case of another major disaster? Finding the answer was difficult especially given the fact that Ushahidi is a tool and the way it is used only depends on the group(s) that decide to use it. Looking back on the first days at Boston sitroom, I remember more than clearly, how handy it would be to have some guidance or at least single advice based on previous experience. There was nothing much available, particularly for the case of deployment in humanitarian crisis. We had to go through undiscovered paths and learn on the run.

Despite the reported success stories from Ushahidi deployment in Haiti, there were also some concerns raised repeatedly by the humanitarian community as well as tech community  - part of it based on reasonable arguments that if Ushahidi should be a part of the emergency response systems, the way it is deployed has to be absolutely predictable. Nevertheless part of the concerns is based on misunderstanding of what Ushahidi actually is – what it can do, where are it’s limits and what is it’s place in the humanitarian response environment. To effectively address some of those concerns we still need more data and experiences, not only from Haiti and Chile.

When the disastrous floods hit Pakistan, it was clear that there will be a need and space for crisis mapping initiatives. Also Ushahidi was deployed again. This time in a way that it provided lot of answers to questions we had about the ideal scenario of future deployments: it was deployed locally. Faisal Chohan, TED Senior Fellow, mobilized a team around the pakreport.org platform and 3441 shortcode. From the moment we got in touch it was clear that his team will face some similar challenges we did, plus will have to face the expectations that were raised by the Haiti and Chile deployments. But it was also clear that they are serious about this and they are ready to invest all their capacity into this initiative. Based on the experience from Haiti, I would like to summarize some major concerns that are being raised regarding the deployment of Ushahidi in humanitarian crisis as well as I would like to outline some ideas (partly already implemented, partly still just ideas) that could help to understand the potential and added value of Ushahidi platform in disaster response.

It is not an uncommon perception, that Ushahidi aims to be a tool with ambition to replace the humanitarian needs assessments by crowdsourcing, but fails in that. Well, first of all, Ushahidi is just a tool, platform. It is accessible to anyone who is interested. How this tool is being used and for what purpose depends only on the goals and capacity of the entity that deploys. Speaking for Ushahidi Haiti team (and having a good insight into Pakreport.org deployment), it was never our goal to be a replacement for traditional humanitarian needs assessments. Collection of the data from the affected population can never be comprehensive enough without intensive field work of the teams collecting data directly on the ground in a standardized way all across the affected area. However, today, with increased access to technology enabling individuals and communities to become reporters of incidents in their area, I believe we simply cannot ignore such potential. Having this in mind, here is the list of roles that platforms such as Ushahidi can play in the disaster response:

• Filling the information gap in the very early emergency period
• Providing critical information about the needs of individuals and communities that may be lacking in rapid needs assessments
• Providing reports on sentinel events as well as reports that are time sensitive (such as outbreaks of diseases etc)
• Providing critical information from areas that are hardly accessible either for logistical constrains or security threats
• Providing up to date situational awareness that can be very useful for the teams on the ground
• Providing a source of data for cross reference

Anyway, seeing Ushahidi deployments as a tool solely for supporting the international relief efforts would be misleading. Humanitarian NGOs are only of of many potential audiences. The strength of Ushahidi is the potential to provide community based reporting for community/locally based response. Ability to provide locally based reporting can be very well utilized by the local groups of responders, governments, traditional community leaders as well as journalists. Such capacity should be encouraged especially in the situation when there are serious and unpredictable security risks for international responders.

Pakreport.org initiative is not asking the affected population to provide information about the needs. Obviously, such request would raise the expectations that reported need will be met. This brings the risk that unmet needs will increase frustration of the affected population. The message going to the population from Pakreport team asks for reporting observations related to floods – making anyone with access to mobile phone or email a reporter. Maybe slight difference from asking to report needs, but clearly addressing the survivors as a resource and partner, not as a liability.

Following the successful deployment of Ushahidi in Kenya during the constitutional referendum ‘Uchaguzi’, and the community meetups held every month at the ihub, the developer community in Kenya came together at the ihub yesterday. The main reason for coming together was to learn from long time coder Jason Mule, and developer Linda Kamau.

Jason explained the Kohana framework, a php framework that follows the MVC style of object oriented programming and how Ushahidi utilizes it. He demystified perceptions around plugin development. It may seem difficult to write extensions or plugins at first, but with an understanding of the framework, events and filters, it becames easier for the developers to grasp how they can add functionality to Ushahidi. During the meetup, Linda Kamau went into more detail, giving the attendees a better sense of how to create a plugin.

Mikel stopped by to highlight some of the ideas he and the MapKibera team had, to view their wishlist, check out this link.

For more information on how the plugin architecture, the plugin architecture screencast by Caleb Bell and David Kobia is quite instructive and useful. An example of a plugin developed with the new architecture is the Cloudvox plugin which allows people to call to report an incident.

The next meetup is scheduled for October 28th 2010, Kenya based developers are welcome to join us again.

Pics from the meetup are up on this flickr set.

SwiftRiver is an open source intelligence gathering platform for managing realtime streams of data. Today we’re happy to announce the relaunch of SwiftRiver at Swiftly.org and to release of our first app built on the SwiftRiver platform, simply called Sweeper App.

SwiftRiver | Sweeper

SwiftRiver is unique in that there is no singular ‘SwiftRiver’ application. Rather, there are many, that combine plugins, APIs and themes in different ways that are optimized for different workflows. If you’re a journalist researching different subjects you’ll probably use a different Swift App than say a crisis response organization. There are more Apps coming, Sweeper is just the first and it was specifically designed to optimize the workflow of Ushahidi users.

A Bit About the Technology

For the UI, we’re using the Kohana MVC, but our underlying technology operates completely independent from Kohana and can work with any programming language. That ‘core’ is SwiftRiver. Anything using the core is an App and any external service we rely upon is called an API.

Sweeper App

This first app, called the Sweeper is the first project to enter Beta and now ships with SwiftRiver.

Sweeper, is a term Ushahidi uses to refer to people who ’sweep’ through a system, performing certain tasks. During the Haiti earthquakes, volunteer sweepers were used to verify and geolocate some 100,000 reports that had been crowdsourced about the catastrophe. Thus, this application is designed for speed and ease of use with big easy to read text, bright buttons and a very clean layout.

SwiftWebServices (SWS)

SwiftWebServices is our API platform. These APIs power Swift and the various apps built for it, but they can also power any application. PubHealth.org for instance is using SWS to power a public health news aggregator. Others might use them to power different applications or programs. You can find out more about our APIs and pricing here.

Download v.0.5.0

You can find out more about the team behind SwiftRiver here.

What does real-time mapping with New York City public school kids look like? Recently, Digital Democracy was invited to work with 120 young people from all 5 boroughs as part of the Department of Education’s “Future Now” program. Having gone through the NY Public School system myself, I jumped at the opportunity to help them innovate. My task was to engage the kids in a conversation about what they’d like to see in the year 2020. Future Now is creating NYC’s Digital Storybook – a citywide youth project about school, community, and dreams. What better way to explore these themes than a mapping exercise to literally add and remove items in their communities and on their streets?

Solar Flashlight & Kazoo created by the students

To give the kids a real-life example of the changes that are happening in their community, we built a modified Ushahidi map with data overlays from the NYC Data Mine and Recovery.gov. I explained that these are the government’s official data related to spending and therefore allows for the reporting of potential fraud, waste, and abuse, but also for innovative new solutions by identifying the gaps. To make it personal, I asked them what they would do if they knew how much money their school was getting compared to the neighboring school. Not only did that set off a flurry of ideas from the students, but the teachers got pretty excited as well. This already started to show that opening government data can impact the lives of everyday New Yorkers and lead to a smarter city by getting citizens young and old involved in urban planning.

Another exercise that I had the kids run through was stating a mock vision: of the year 2020, gasoline would be expensive, the environment polluted, cars more scarce, and so encouraging the city to place a bike rack in front of my office would enable people to bike to work, making the city more peaceful, healthier and cleaner. Plus, if the government thought a bike rack existed where one didn’t, I could let them know about their error. In this case, I overlayed “Bike Racks”, as a set made available in the Geo Data Catalog. I then asked the students to brainstorm their own scenarios for the year 2020. The kids had a field day dreaming up solutions and adding them to the map. You can visit the website or see it embedded below to see their ideas. When working with young people, it’s important to keep in mind their protection and security, and so of course viewers of the site will notice that their personal information remains private.

Our Ushahidi lesson plan builds off of our participatory collaborative learning curriculum from around the world, Project Einstein. In this case, it was exciting to see the successes of incorporating a tool that integrates lessons from across different discipline: geography, computer science, economics, math, art, social studies, etc. But each local context reveals new insights for our culturally-specific programming and this case was no different.

The biggest problem I ran into was spell-check. I noticed that the students were taking an unusually long time to fill in their reports and after looking into it, found that when students were entering in their main body of information, a line would show up automatically under misspelled words. Every time this happened, students would backtrack and try to figure out the right spelling. This happened so often that I estimate it took about twice the time to create each entry as it otherwise would have. In the places where there was no spell-check, like in the titles, the entries are littered with bad spelling, but they were entered quickly. Our work confronts language problems head on, mainly working with visual media such as maps, photos, videos, etc that can allow people to connect beyond these barriers. It’s important to consider language barriers even with native English speakers as well. And in NYC, it’s even more complicated, with our students coming from places as varied as Tibet, Thailand, Congo, Madagascar and Brooklyn.

“OMG kids are on Facebook!” is one of my favorite challenges that also arose quickly. Two skateboarders had finished mapping their vision for perfect place for a skatepark in their community ahead of the other students and got distracted, finding themselves wandering the internet and logging into Facebook. Instead of scolding them and demanding that they go back to our site, I told them that no other students had added a photo to their posting so could they find the best photo to go along with their post, to make it easier for a politician to see exactly what they had in mind. The hunt was on, and they indeed found a great photo, without another distraction. To me, this is a key aspect to the model of 21st century education – information management. Can students find information that is going to add value to their post. Do they know whether it’s creative commons and how publicly it can be used. There are still many steps before getting to that point, but this is a start. Ushahidi serves as a strong tool because the barrier to entry is low, but the opportunity to dig deeper continues. Thanks to the new plug-in architecture, they can even proudly display that skate park on their Facebook wall.

While technology access is growing in our schools, so is censorship. These kids were astonished to see their work up and live on a website that is free and accessible to anyone. Increasingly, there is a limit to what they can access due to filters and firewalls, and what they can publish because the media that they’re producing has work that can’t be licensed, such as the videos they had made about New York that features the song “Empire State of Mind” by Jay-Z & Alicia Keys. Due to alleged copyright violations, their work can’t be screened to other kids. School banned website lists resemble the ones in Tunisia, a notoriously closed society.

To ensure the continuation of the open web and that students are given increasing access to powerful and empowering tools like Ushahidi, Digital Democracy used this instance in our lobbying efforts, testifying to the New York City Council Technology Committee on Open Data. Our testimony, available here, details how free and open source technologies, coupled with open data and progressive 21st century schools can foster positive engagement between students, their government and their community.

Whether working with kids or lobbying to government, I’m thankful to be able to use such a flexible and interesting tool to convey the message that technology can be used for civic engagement. And as a native New Yorker, the diversity of ideas, skills, backgrounds and approaches in this project reminds me how much I love this city. I just hope that we stop censoring it and start supporting more of these kinds of initiatives in the future and by 2020.

Future Now Ushahidi Map

[iframe http://handheldhumanrights.org/nyc/external 600px 475px]

What does real-time mapping with New York City public school kids look like? Recently, Digital Democracy was invited to work with 120 young people from all 5 boroughs as part of the Department of Education’s “Future Now” program. Having gone through the NY Public School system myself, I jumped at the opportunity to help them innovate. My task was to engage the kids in a conversation about what they’d like to see in the year 2020. Future Now is creating NYC’s Digital Storybook – a citywide youth project about school, community, and dreams. What better way to explore these themes than a mapping exercise to literally add and remove items in their communities and on their streets?

Solar Flashlight & Kazoo created by the students

To give the kids a real-life example of the changes that are happening in their community, we built a modified Ushahidi map with data overlays from the NYC Data Mine and Recovery.gov. I explained that these are the government’s official data related to spending and therefore allows for the reporting of potential fraud, waste, and abuse, but also for innovative new solutions by identifying the gaps. To make it personal, I asked them what they would do if they knew how much money their school was getting compared to the neighboring school. Not only did that set off a flurry of ideas from the students, but the teachers got pretty excited as well. This already started to show that opening government data can impact the lives of everyday New Yorkers and lead to a smarter city by getting citizens young and old involved in urban planning.

Another exercise that I had the kids run through was stating a mock vision: of the year 2020, gasoline would be expensive, the environment polluted, cars more scarce, and so encouraging the city to place a bike rack in front of my office would enable people to bike to work, making the city more peaceful, healthier and cleaner. Plus, if the government thought a bike rack existed where one didn’t, I could let them know about their error. In this case, I overlayed “Bike Racks”, as a set made available in the Geo Data Catalog. I then asked the students to brainstorm their own scenarios for the year 2020. The kids had a field day dreaming up solutions and adding them to the map. You can visit the website or see it embedded below to see their ideas. When working with young people, it’s important to keep in mind their protection and security, and so of course viewers of the site will notice that their personal information remains private.

Our Ushahidi lesson plan builds off of our participatory collaborative learning curriculum from around the world, Project Einstein. In this case, it was exciting to see the successes of incorporating a tool that integrates lessons from across different discipline: geography, computer science, economics, math, art, social studies, etc.  But each local context reveals new insights for our culturally-specific programming and this case was no different.

The biggest problem I ran into was spell-check. I noticed that the students were taking an unusually long time to fill in their reports and after looking into it, found that when students were entering in their main body of information, a line would show up automatically under misspelled words. Every time this happened, students would backtrack and try to figure out the right spelling. This happened so often that I estimate it took about twice the time to create each entry as it otherwise would have. In the places where there was no spell-check, like in the titles, the entries are littered with bad spelling, but they were entered quickly. Our work confronts language problems head on, mainly working with visual media such as maps, photos, videos, etc that can allow people to connect beyond these barriers. It’s important to consider language barriers even with native English speakers as well. And in NYC, it’s even more complicated, with our students coming from places as varied as Tibet, Thailand, Congo, Madagascar and Brooklyn.

“OMG kids are on Facebook!” is one of my favorite challenges that also arose quickly. Two skateboarders had finished mapping their vision for perfect place for a skatepark in their community ahead of the other students and got distracted, finding themselves wandering the internet and logging into Facebook. Instead of scolding them and demanding that they go back to our site, I told them that no other students had added a photo to their posting so could they find the best photo to go along with their post, to make it easier for a politician to see exactly what they had in mind. The hunt was on, and they indeed found a great photo, without another distraction. To me, this is a key aspect to the model of 21st century education – information management. Can students find information that is going to add value to their post. Do they know whether it’s creative commons and how publicly it can be used. There are still many steps before getting to that point, but this is a start. Ushahidi serves as a strong tool because the barrier to entry is low, but the opportunity to dig deeper continues. Thanks to the new plug-in architecture, they can even proudly display that skate park on their Facebook wall.

While technology access is growing in our schools, so is censorship. These kids were astonished to see their work up and live on a website that is free and accessible to anyone. Increasingly, there is a limit to what they can access due to filters and firewalls, and what they can publish because the media that they’re producing has work that can’t be licensed, such as the videos they had made about New York that features the song “Empire State of Mind” by Jay-Z & Alicia Keys. Due to alleged copyright violations, their work can’t be screened to other kids. School banned website lists resemble the ones in Tunisia, a notoriously closed society.

To ensure the continuation of the open web and that students are given increasing access to powerful and empowering tools like Ushahidi, Digital Democracy used this instance in our lobbying efforts, testifying to the New York City Council Technology Committee on Open Data. Our testimony, available here, details how free and open source technologies, coupled with open data and progressive 21st century schools can foster positive engagement between students, their government and their community.

Whether working with kids or lobbying to government, I’m thankful to be able to use such a flexible and interesting tool to convey the message that technology can be used for civic engagement. And as a native New Yorker, the diversity of ideas, skills, backgrounds and approaches in this project reminds me how much I love this city. I just hope that we stop censoring it and start supporting more of these kinds of initiatives in the future and by 2020.

Future Now Ushahidi Map

[iframe http://handheldhumanrights.org/nyc/external 600px 475px]

FrontlineSMS has long been a part of the Ushahidi ecosystem. When we rebuilt Ushahidi in the summer of 2008 at a free and open source platform, we built hooks into it so that anyone who used FrontlineSMS could easily sync that information to the Ushahidi maps. At that same time, FrontlineSMS open sourced their code, and we tried to learn as much as we could about how to better help users who were running their own SMS gateway through FrontlineSMS so that the system could truly be run by anyone, anywhere.

It’s a simple as this:

Today FrontlineSMS is adding MMS to their repertoire!

That’s a big deal. It means that we can now figure out how to include more than just text messages, but also images, video and audio. Incoming MMS messages can trigger an SMS auto-reply, or an external command, etc. It’s a great blending of SMS/MMS in one system, and shows how holistically their team has thought about the user interaction with simple messaging.

We’re thinking of implementations of this, and we’d love some feedback from you on how it could be done an what would be useful. Leave some comments below with your thoughts.

Taking the maps offline through FrontlineSMS

We’re working on even better integration into this longstanding keystone of the open mobile space. Right now we (“we” being Dale Zak, Emmanuel Kala and Brian Muita) are working closely with Ken Banks and his team of wizards to do a couple of cool things. First is the completing of the very exciting offline mapping tab which is probably about 70% done at the moment. Second, there’s also talk of adding functionality to allow Ushahidi users to post reports directly from FrontlineForms, and this could prove very useful in a wider capacity where people want to get structured data from end-users via SMS which is then posted online.

Many great things lie ahead for the two teams, and we expect more and better integration as we work on different features and functionality together.

[full press release: FrontlineSMS + MMS press release (PDF)]

Download FrontlineSMS v1.6.16 here.

[Guest Plot Post: Robert Munro is the Chief Information Officer at Energy for Opportunity and a Graduate Fellow in computational linguistics at Stanford where he specializes in methods for processing large volumes of information in less-resourced languages.]

Ushahidi platforms allow people to make order out of chaos. There is a lot of chaos. Especially during a crisis situation, large volumes of unstructured data need to be waded through to find information that is vital to the crisis affected population and to the aid organizations serving them. By the value-adding process of structuring the incoming reports (adding coordinates, categorizing, translating) the information can be quickly streamed back to those who need it most. The bottleneck is that it can take a lot of time to add structured data to unstructured reports, and people’s resources are already the most stretched during a crisis.

We are currently working with Ushahidi and CrowdFlower to address this, extending an existing collaboration in Haiti. In this new collaboration, we are working to support a team led by Faisal Chohan of BrightSpyre in Pakistan who are mapping the flood and post-flood conditions there, collecting reports from the general public and aid organizations via SMS, media monitoring and direct reports (www.pakreport.org). The potential scale of this information is extremely large, and therefore so is the potential bottleneck.

For this reason, we have built a new module for their Ushahidi deployment to ‘crowdsource the crowdsourced reports’. It is not feasible to open up the dashboard of an Ushahidi instance to too many people for reasons of scalability and security. However, we can export just the value-adding process of turning a written report into a geolocated, categorized report that is translated into one or more languages. For the deployment in Pakistan we are utilizing CrowdFlower for this process. Urdu, Pashto and English speaking volunteers from anywhere in the world can come online to the CrowdFlower task (pakreport.crowdflower.com), read one message at a time and then complete a form to add coordinates, categories and translations.

For someone managing the incoming reports with the Ushahidi deployment this processes is seamless. A report will come into the Ushahidi deployment in plain text without coordinates, translations or categories. Behind the scenes, this message is passed off to CrowdFlower for processing. Once consensus is reached in CrowdFlower, it is passed back to the Ushahidi deployment and the report is automatically updated with the structured data. Depending on the volumes of volunteers and messages, this whole process can take as little as 1 or 2 minutes.

Behind the scenes at CrowdFlower, data quality is maximized in a number of ways. Each message is passed to multiple volunteers and their responses are compared to each other for consistency. When there is great variation in responses, the task is automatically passed to more volunteers until a threshold of confidence is reached. Through this same method of cross-worker comparisons, a confidence in the overall accuracy of each individual volunteer is also calculated, which can be used as a factor in determining the overall confidence in the accuracy of the structured data for each report. For identifying coordinates, the centroid of the different coordinates is calculated, ignoring any outliers to remove the effect of individual errors. Along with the final structured report for each message, the information about response variation and confidence is also passed back to the Ushahidi deployment, allowing for a comprehensive interpretation of this processes by the core team.

Opening up this step to remote volunteers also allows for much richer interpretations of the information contained in each message. As we learned in Haiti, the crowdsourced volunteer translators were often able to identify the coordinates of addresses in emergency text messages with greater accuracy than the emergency responders. Therefore, the volunteers are also contributing their own unique knowledge to the crisis response efforts, in real-time.

It is likely that we will see more ‘crowdsourcing of croudsourced information’ in future Ushahidi deployments. CrowdMap are currently working on an API to allow the necessary interoperability and SwiftRiver are working on value-adding systems that utilize both crowdsourcing and natural language processing technologies. We are all still learning the best strategies for structuring and managing these crowdsourced integrations and work-flow processes, so we will be following the www.pakreport.org deployment closely.

Crowdmap is not just for crisis mapping even though a lot of the media has associated Crowdmap with crisis mapping. Crowdmap can be used to map a wide range of issues, from event-based issues, to resources like schools and market places. In any case, if you do plan to use Crowdmap for crisis mapping, then we recommend you follow the following 5 steps.

1. Find out if someone else has already deployed Crowdmap for the same emergency. There are several ways you can do this:

a). Do a Google Search

b). Ask on the Crisis CrowdMap Google Group.

c). See whether the domain name is already taken, e.g.: http://HaitiEarthquake2010.cowdmap.com

2. If a Crowdmap already exists, then contact the person who launched the platform to ask how you can help. If you want to use Crowdmap in a different way, then read on.

3. Choose a simple and intuitive domain name to customize your Crowdmap. We recommend using the following formats to name your map: CountryCrisisYear or CityCrisisYear, e.g., HaitiEarthquake2010. This will allow others to find you more quickly.

4. Sign up here to launch your Crowdmap.

5. Let the world know that you are deploying your Crowdmap:

a). Tweet: “We are deploying a @Crowdmap for the [blank] crisis, please get in touch if you’d like to help! [Add link to your Crowdmap, your organization or website, etc]“

b). Email: Go to the Crisis Crowd Map Google Group to let members know about your Crowdmap deployment so they can spread the word and get involved if you’re looking for help.

c). Blog: Keep the word posted on your deployment by writing posts on your blog.

A PDF version of these guidelines are available here.

[Cross-posted from Konpa Group Blog, written by Sabina Carlson]

I have read a number of the stories written about the Ushahidi Haiti Deployment, some of which said that it served as a lifeline for many Haitians affected by the earthquake of January 12th. And as the rescue phase transitioned into the recovery phase, as disaster slowly transitioned into development, and as incidents gave way to indicators, our team decided that our platform  had served its purpose and that it was time to close Haiti.ushahidi.com. Our site would always be kept up to serve as a snapshot of the crisis phase.

But, back in March, I deployed to the ground to serve as the Ushahidi Haiti Project’s (UHP) field representative for local outreach, and spent a month explaining the Ushahidi and 4636 system to a wide cross-section of Haitian civil society: in the middle of IDP camps, in destroyed churches, in local meeting halls, I explained Ushahidi in Creole and listened to what the affected communities had to say. And I made the interesting discovery that, during the recovery phase, Haitians saw Ushahidi not just as a life line, but a communication line – in fact, the only open communication line that seemed to exist between them and the humanitarian community.

And so, it is hard to convey how inspired, relieved, and motivated I was to hear about the Noula platform: motivated by the same drive to broadcast the voices of the affected population, a Haitian ICT company called Solutions had pooled its resources to create an interactive crisis and needs-mapping platform called “Noula” or “we’re here” in Creole. The concept is simple: based on the shortcode 177, Haitians can call into a call center for free that is staffed by trained operators, and communicate critical pieces of information on their situation or request information.  The information is then sorted, categorized, geolocated, and put onto the online platform Noula.ht, where responders can access the information directly or through subscribing to receive alerts.

Although UHP was born in Patrick Meier’s living room and Noula was born in a tent outside of the Solutions’ office, the platforms shared a common core function: to broadcast the voices of disaster affected populations onto a map that the world can see and respond to.

As a team, we saw Noula as having the potential to be that lifeline, that communication line, not just for the current crisis but for the long-term – and so we decided to take our experience, our resources, our networks, and our lessons learned to partner with Solutions to support Noula.

The Solutions team has an incredible wealth of technical experience, and the talent to create an incredibly responsive tool that is tailored to the current crisis and mitigation efforts in Haiti.  And while Solutions has all the networks and knowledge to build a tool for the public authorities in Haiti, they requested extra support in reaching out to the humanitarian community to understand how the tool could be best used by them as well.

This is where I have come back into the complex crisis communications world in Haiti: to act as a liaison between the Noula team and the humanitarian community. I have been here to find out about how information could best flow between the Haitians calling into the call center every day to the cluster leads and logisticians and information management officers that direct the humanitarian effort every day.

It has been an incredible opportunity to work with a dedicated piece of Haitian civil society to build from the ground up a crisis communications platform that is not only specifically tailored to Haiti, but to the complex post-earthquake, pre-hurricane reconstruction and risk reduction environment the country finds itself in.

And I am also grateful that our networks, experiences, and lessons learned from the Ushahidi Haiti Deployment can play a modest but consistent role in supporting what is now, and will continue to be, that channel of communication I found to be so vital back in March.

One week ago we launched the beta of Crowdmap, our cloud based service making it easy for users to create their own deployments of Ushahidi. On Monday (August 9th), the release was announced simultaneously on our blog and Twitter feed. It didn’t take long for people to notice.

We were ready for the masses to come in and set up their deployments. However, we weren’t anticipating a nasty bug that had gone unnoticed in internal testing. For those more technically adept, a caching issue was swapping sessions between users when they would visit the site simultaneously. We had to take the site down for a couple hours while we diagnosed the problem and promptly applied a patch for the bug. In the mean time ReadWriteWeb was quick to get the first article out about the service highlighting some of these very issues. Needless to say, Crowdmap is now running smoothly.

We have seen some innovative ideas already that we never really imagined. Gregory Hill wrote an article and produced a video highlighting how he was planning on using Crowdmap, “Equitable student sourced mapping: Crowdmap“. He’s looking at taking community mapping to the education space, having students report on happenings in their community in Spanish. These are the types of innovative uses we were hoping to see coming out of Crowdmap. What can you come up with?

Just to share some interesting statistics with you all, since we launched, we have seen over 1,500 deployments created by almost 1,400 users. When Lifehacker posted, “Crowdmap Puts Any Data on an Interactive Map” last night, we saw an immediate increase in traffic, boosting the number of deployments significantly. You can see this on the graph bar chart of Crowdmap deployments created since launch.

We’re working extra hard to make sure all bugs are patched and suggestions are considered. For those of you looking for more expanded functionality, we will be implementing Ushahidi’s plugin and theme architecture in the coming months. It is currently under development for the second version of the Ushahidi platform. Please, keep your bug reports and suggestions coming!

On August 16, Twitter will be limiting requests using basic authentication for requests to their API and shutting them off entirely on August 31. What does this mean for Ushahidi? Ushahidi uses this method to connect to your Twitter account and download direct messages. If you have your own deployment of Ushahidi and you have added your Twitter username and password in the admin settings, you will no longer be receiving these messages. However, keep in mind that you will continue to receive messages based on your hashtag settings!

If you are just starting your own deployment or if you are planning on upgrading, the next release will have DM functionality removed. If you are running Ushahidi off of our development code base on GitHub, this functionality has been removed. If you are a user of Crowdmap, you will notice that this functionality has already been disabled.

So, why is Twitter shutting off basic authentication if it’s going to cause so much trouble? Twitter has many good reasons to disable basic authentication. The biggest reason is applications that use basic authentication have to store your username and password. Essentially, any application that has been written for nefarious purposes can ask for your username and password and gain control of your account. Another reason basic authentication is bad is because you, as a Twitter user, have no control over which applications can access your account. These are just a few of the reasons Twitter is moving away from this method of authentication. OAuth is the answer to these problems. Applications no longer have to store your password and you can have better control over how these applications access your account. In fact, you can see a list of the applications that have been connected to your account using OAuth by visiting http://twitter.com/settings/connections.

If OAuth is so great, why can’t Ushahidi support it? We would love to support OAuth, but at this time there isn’t a secure, convenient way to implement it in open source software. The reason being is every application that wants to connect to individual user accounts on Twitter must be registered and have a secret key hidden somewhere in the code. This is a problem for Ushahidi for two reasons, every deployment of Ushahidi is essentially its own application and would require registration for each one. Also, OAuth requires that applications have a secret key (like a password) that can’t be shared with anyone else. This key would have to be stored in the open sourced code (meaning anyone could take it and perform acts of evil).

Twitter has recognized these problems for projects in this type of situation and has been working on a secret keyless solution. Unfortunately, it will not be ready for the cutoff. When that time comes, expect to see a plugin for the second version of the Ushahidi platform that will allow you to connect your Twitter account to Ushahidi with expanded functionality!

[Crossposted on TED Fellows Blog by Faisal Chohan, senior TED Fellow and Co-Founder | www.BrightSpyre.com & Cogilent Solutions.]

I am still a few miles away from one of the worst floods in the history of Pakistan.  Still, I could not figure out the meaning of life and hope after losing your loved family, losing everything you built in your life in front of 30 feet high flood wave, where everything is completely devastated for millions of people. I do not know how to save hopes of people in current situation. But as a technology and social entrepreneur, I have read hundreds of case studies and talks that a SMS is a ray of hope and decided to setup SMS based incident reporting.

I want to bring first line of incident reporting live for millions of people in Pakistan. This requires technology, spreading the right word to millions, building team, Logistics, resources and coordinating all the incident reporting. The last week was spent on the technology front.  So, after sleepless nights, power shortages, worst news written on faces everywhere, the effort continued. With the help of few friends, I got access to short code 3441 in Pakistan.  Next the Crowdmap was launched at http://pakrelief.crowdmap.com.  Then, the short code integration was done. And the technology milestone is achieved.

Then, I started carefully spreading the message to select forums and people about the SMS and incident reporting platform, people from all over the world are joining us that is bringing a hope on a SMS message. Team building is on way and spreading the message to millions of flood affected people is next big challenge. Remember, the mission is to save one hope by one SMS message at 3441.

The message to spread is simple. “Text your observations about the disaster and your location so we can put this on a map.” People can report their observations by texting 3441 and starting their message with “FL”.

One hope will be saved, if this message is properly understood, mapped by humanitarian agencies, people or anyone in the world looking to help flood affected populations in Pakistan. We need your help, please join our team (email us at pkfloods@brightspyre.com) and lets try to save one hope with one SMS message.

One of the first tasks as Ushahidi’s Mobile Project Manager, is to deliver the much-anticipated Ushahidi iPhone app. We’ve had an iPhone app in the works for the past year, however a lot has changed since we first envisioned the app. For example, background processing is now available on the iPhone 4.0, and the iPad now offers a much larger screen real estate.

So if we built the app from the ground up, what would it look like? How could we design the app to be as simple as possible, and yet still familiar to the user?

After some discussion about the current iPhone app prototype, I’ve realized the desired Ushahidi app functionality mirrors that of the current Apple Mail app.

Apple Mail Ushahidi App Allows you to access multiple inboxes Should allow you to access any of the Ushahidi deployments Selecting an inbox will display the email for that account Selecting an Ushahidi instance should display the list of reports Selecting an email displays the full details Selecting an incident should display the full report details You can forward an email to your friends You should be able to share an incident with friends via Email, Facebook or Twitter A new email is created via a modal dialog You should be able to create new report in the same famous

So, taking those points into consideration, I created a new iPhone and iPad project using the Apple Mail app as a model. Below is a Prezi demonstrating the proposed application flow:

This is the first attempt at re-thinking the Ushahidi app, so your feedback is always welcome.

You can view the current Ushahidi iPhone code at: http://github.com/ushahidi/Ushahidi_iPhone

Note, this blog article was originally posted here.

For many Kenyans who are not techies, getting to implement the Ushahidi platform can be tough, especially when not clear how exactly the use will contribute to achievement of organizational goals. That is why the Ushahidi 101 sessions were started; to give interested users a chance to understand how it works and get hands on experience.

The August Ushahidi 101 mainly attracted people who had downloaded the software or expressed interest in using the platform, it was a session for people to interact with Ushahidi team and get answers to most of the questions.

After the introduction of what Ushahidi and what its not, you can almost feel that people understand better and the next question was on the level of tech knowledge needed to implement. From the discussions, people download and fail to implement because they at times fear they do not have the expertise, are not aware that they can do simple installations, and are not aware that the tech work can be outsourced.

At the 101 session, participants get a chance to go through the back end, are shown simple installations that have worked with minimal tech experience and can ask all the questions, here there are no damn questions; that is why its a 101 and we answer all of them!

The second session is broken into thematic groups; technical and non-technical. The tech group helps users navigate the back end and understand how to update and manage information. Because there is huge bandwidth at the Innovation Hub (iHub), it helps if you have a laptop, then you can practice as you go along. If not, the projector does a decent job of making sure its all inclusive.

The non-tech group gets a chance to meet at the balcony and have a better view of Nairobi in the evening. The group discusses ways to promote the instance. It has always been said that technology is 50 percent of the solution and the other half is people-related. So, if there are questions on how to deploy, how to develop categories or how to ensure more people visit the site, this is your group.

After the session, people get a chance to catch up with old friends and enjoy some Pizza and drinks. Its an important social for people to explain how they deployed and some of the challenges you can expect.

During my first few weeks in Liberia, I found myself at the mercy of my driver.  The lack of street signs and numbered addresses meant that finding an office inevitably involved stopping to ask a woman selling bananas, or going up and down nearby streets until we’d eyed each nook and cranny of the concrete honeycomb.  This isn’t how two mapping consultants go about their business, John and I thought; we had the power to do something, however small, about the disorder of Liberia’s capital.  So we set out on in John’s surfboard-adorned jeep with GPS unit in hand.

Our initial goal was simple: to map as many NGOs we came across in that one day.  We could start a map with this information and then hand it over to the public for crowdsourced locations of interest.  We started with NGOs because this is the sector to which most of our local partners belong, and because we thought putting them on the map might – just might – begin to address the NGO community’s lack of consistent coordination and communication.

Our mapping day was sunny with no clouds – a rare occurrence during the rainy season.  On the console of the jeep was our eTrex Garmin GPS unit, in my lap an open notebook for recording the name of each location (in GPS terms “waypoint”) and, in the crease of the notebook, a small digital camera for snapping the entrance to each organization.  We were admittedly undercover on this mapping mission; while none of the NGOs we planned to geo-locate were secretive about their post or mission, there were security guards manning each gate and thus any suspicious behavior (like flashing fancy gadgets, copying down coordinates, taking photos out of vehicles) would likely be questioned – that is, if we were stationary long enough.

Guarded NGO gates

So John was the driver and I the notation officer – when we saw an NGO signboard approaching, he would slow down to the side of the road; with one hand I would start copying down the name, with the other I lifted the camera and glanced through for a quick snap of the building and, as soon as the camera was down (which was usually just as we were cruising up to the entrance), I would click the GPS unit to record the waypoint, John would read aloud the coordinates as I copied them down in my notebook (for good measure), and finally he would speed up and back onto the main road.  Each drive-by took roughly thirty seconds, and on that one day we were able to collect the locations of 55 different NGOs, mostly international, in the greater Monrovia area.  This, amazingly, does not encompass all of the INGOs in town, not to mention the hundreds of local NGOs we have yet to map.

Back at the office, we had to decide how best to display these organizations on the map.  We realized that if we aimed not only to locate organizations but also to improve the likelihood of communication between them, points on a map alone wouldn’t do the job; the dots, as we originally envisioned them, would simply answer the question I constantly faced upon arrival – “where in the world is NGO xyz?”  Greater information sharing, we decided, might be better facilitated by providing a variety of data on each organization – such as each NGO’s mission, types of programs, and links to any available online information.  In addition, we created ten general categories under which most of the NGOs’ activities fell, as a way of clustering organizations around programmatic overlap and individuation.  We also made customized changes to the Ushahidi instance’s default tabs; for example, “reports” became “places on the map”, “submit an incident” became “add to the map.”

Liberia Mapped

It didn’t take long for us to realize what template we were trying to replicate: the Yellow Pages.  A Liberian Yellow Pages, however, needs some additional features: nuanced addresses (such as “the alley just behind the Carter Center in Mamba Point, Monrovia”), photographs such as the ones we took to distinguish one steel gate from another, and the date of the submission to determine how recently the information was added (and thus the likelihood the NGO is operational and in said location).  Web links to an organization’s website or related articles can provide users with additional info without navigating away from the page.

Submitting information to Liberia Mapped

For this budding Liberian directory, what we’re calling Liberia Mapped, to become a viable one-stop shop for everything from development initiatives to best restaurants, we need the public to populate it. We’ve started in the capital city only because that is where we are able to easily geo-locate or verify submissions, but we welcome any sites of interest not already included.  If a category does not yet exist, suggest one!  If there’s a report about your NGO or business and you want to change it, let us know!  Liberia Mapped is to encourage information sharing in a place where, for too long, the lack of an easily accessible and centralized data source has been the perennial excuse for poor communication, transparency and accountability.

When the Ushahidi platform was written as an open source project in 2008, the vision was to have a platform that any individual or organization could easily deploy in any situation. While providing the software for free to anyone to install on their own servers has worked well so far, we have realized that there was a need to rapidly deploy Ushahidi without any required technical acumen in the shortest amount of time possible. The answer to this challenge has been Crowdmap.

Crowdmap is a service provided by Ushahidi with all the benefits of Ushahidi out of the box but with nothing to install. It takes all of five minutes to get a vanilla deployment up and running on crowdmap.com subdomain. You will have full administrative access to your deployment, just as you would if you installed it yourself. You will have the ability to choose themes, edit categories, solicit reports, just as you would if you had a server administrator get your deployment up and running. Crowdmap will even accept SMS reports from FrontlineSMS or your Clickatell account.

Setting up a deployment is easy. All it takes to get started is filling out a simple form with your password, a valid subdomain, name and tagline for your deployment and you’re good to go. After your site is setup, you log into your deployment and begin making modifications. When you are ready to start a second deployment, it’s just a matter of logging into your Crowdmap account at crowdmap.com and clicking on “New Deployment”.

The functionality we have written to run Crowdmap is baked into the core Ushahidi code and we will be offering it as a standard component of your future Ushahidi downloads. You will be able to take Ushahidi and host your own deployments soon!

We are really excited to see what you all come up with using Crowdmap. Being able to rapidly deploy will give you opportunities to try things you wouldn’t normally have tried. We know you all will get out there and do awesome things with Crowdmap. Go ahead and give it a go!