Really, having technical tickets (issues, bugs, features and pull requests) and commits in the same place will help with the two big things: transparency and collaboration. We want to make it easier for you to see what we are working on, submit a ticket and lend a hand when you can. If you are busy creating great code, we’d like to know about it and be able to incorporate it into the core. Or, make it more visible for others to use your code for their Ushahidi-related projects. Git Issues is directly connected to our GitHub – Ushahidi. (E.g. Ushahidi core issues live under https://github.com/ushahidi/Ushahidi_Web/issues).

Migration Help and Schedule:

Our team has reviewed the Red Mine and have flagged issues to be migrated.

Please add a comment to any items that you think need to be migrated to Git Issues. We’ve added the document to our new beta wiki for your review. Every coders eyes will help us capture the active tickets/issues. Ping Hleson at ushahidi dot com if you have a questions.

Migration Schedule:

• Community Feedback on Issues to be migrated: February 8 – 15, 2012
• Migration Freeze on RedMine: Februay 15 – xxx
• Ushahidi Community Developer Skype Chat (time to be announced) Wednesday, February. 15, 2012
• Deprecate Redmine. February 29th, 2012
• Team cleans out the Github store procuring all the sweet Github Octocat hoodies. March 1st, 2012

Getting Help:

Tool soup is confusing. Duplication is less fun than collecting Nyan Cat mash-ups. Here’s a cheat sheet:

Forums: “How do I….”, “I’m troubleshooting”, “General Support”
Wiki: “Where are the documentation, best practices” and “How do I…”. Bonus points: document and share your knowledge
GitIssues: “Houston, we have a problem.” “Nyan, Ushahidi would rock it if…” (Issue/bug/feature)
Github: Commit, Pull Changes, Fork
Contact: General questions (eg. Erik’s favourite ihub story, business endeavours, events, press etc.)

Steps to get help:

Technical Issues:

1. Search the wiki or forums.
2. Collaborate with the community skype or dev mailing list. (This is a real-time stream of global chatter)
3. Search Git Issues for existing issues.
4. Add a Git Issue: (bug or feature) request.

Non-Technical Issues:

1. Search the wiki or forums.
2. Add a forum post for questions.
3. Share your knowledge on the wiki.
4. Collaborate with the Channel for Academics, Researchers and Community Skype Chat or mailing lists.
5. To ask general non-technical tickets, you can drop us a Contact note (http://ushahidi.com/contact-us).

We will review all Git issues weekly and assign priorities. The priorities could include assigning to a team member or requesting community help. More details as we get closer to launch.

To sum up: GitIssues, flag your tickets for migration, Octocat hoodies and Nyan Cat.

These badges are broken down into “badge packs”. For example, the Locations pack is a simple grouping of badges that follow a travel theme, with badges highlighting landmarks from countries around the world. The Ushahidi pack is a group of generic badges that the Ushahidi team has put together. New packs are expected soon, with contributions from the community and designers from other projects as well.

How can you use this as an Ushahidi administrator? Deployers of newer versions of the Ushahidi Platform and current users of Crowdmap have access to all of these badges already. Simply log into your admin panel and browse to the Manage->Badges settings page to get started. As an example, you may award the 25 Star badge to a user who has sent in 25 approved reports. This can be a manual process where you assign badges to users or set up Action Triggers to do this automatically. Just experiment with the platform to come up with interesting achievements to award your users.

We need your help! This collection of open source badges belongs to the community. If you’re a designer, developer or just interested in all things badgy, you can support this initiative. Your efforts will impact a multitude of projects, ranging from projects that crowdsource information in crisis and disaster situations to projects that reward people for submitting delicious pictures of cheeseburgers. Please check out our badge site for more information.

We’re really excited to see what everyone comes up with. We hope to see the badge image repository grow so other projects can get some value out of our open source badge initiative. Let us know in the comments what you come up with!

In September, I began teaching my first upper-level University course at Grant MacEwan University. Having taken some (and heard about some other) lack-lustre undergrad Software Engineering courses, I really wanted to make this course practical, project-based and interesting for the students. One inspiration was the Undergraduate Capstone Open Source Project (UCOSP) where final-year students select a project and are mentored by faculty across Canada to work on an open-source project for course credit. I also loved the practical approach of the Software Carpentry course taught by Greg Wilson and Paul Lu, which I was involved in a few Summers back and frankly preferred to some of the “Ivory Tower” Software Engineering that is common in undergrad courses.

It was Greg Wilson that pointed me to Ushahidi, and I felt Ushahidi’s humanitarian focus would be a great added benefit to my students. Computer science is so often focused on science, business, marketing and advertising that I felt this was an opportunity to show my students how a small group of dedicated people can use software to make a difference in humanitarian way. There were other great projects suggested too, such as the Sahana Foundation, but I made up my mind to go with Ushahidi once I was introduced to Heather Leson and got to peak in on a Ushahidi hack-a-thon from Nairobi via Skype. The energy of the group was obvious and very exciting.

Organizing the Curriculum

With much enthusiasm, I jumped into trying to build a course using Ushahidi as the core project component. The first major hurdle was that 3rd year computer science students have minimal system administration experience. Except for a few exceptions, they haven’t run a database or a web server on their own. Moreover, PHP is not part of a course curriculum. The sysadmin challenges were answered by using Harvard’s CS50 Virtual appliance. This VM is based on Fedora Linux and comes with PHP, Apache and MySQL already installed. The VM runs on VirtualBox, which is free so students could install it on their laptop (this is how most students ran it). As for PHP, I felt that PHP was accessible to undergrads coming from a Java background. It’s syntax and object-oriented are quite similar to Java.

Our courses at Grant MacEwan involve a weekly three-hour lab component. The first lab was used to introduce PHP with some sample programs. The second lab was used to introduce Kohana and the MVC framework. After the second lab, the first assignment was given. The first assignment consisted of 4 simple tasks

• Apply a patch to get Ushahidi to work with non-clean URLs
• Change the site name and tagline on the admin page to match the main page
• Modify the labels in the API stream
• Add a ‘’pirate’’ response type to the API

These assignments helped the students become familiar with how MVC web servers work. I also felt that the API was an important concept for them to understand well. In the end, this assignment was a bit too easy in some ways. In general, it’s very challenging to judge the level of difficulty when working with an existing code base. To this point, most of my students would have only written programs from scratch (similar to most undergrad CS courses).

It was also to determine what kind of hints to give. For example, problem #4 from above become quite trivial once you show students how to search (using grep) through a code base. Without that hint, students will try to trace the code manually and search manually. So the dividing line between dozens of hours of work and 10 minutes is literally the knowledge of how to use grep effectively. Once the students had completed the first assignment, it was time to throw them head first into Ushahidi on some more significant projects.

Picking the Projects

One advantage I had was that there were only 10 students, which enabled students to work on separate projects based on their interests. Mistakes with a course of 10 students are much more fixable on the fly than with, say, 40 students.

In trying to gather project ideas, I searched the feature requests on the Ushahidi development site and also I asked the Ushahidi community for ideas for projects. Projects from the feature request list included selecting multiple categories and multi-coloured dots. Others came from the Ushahidi group, such as 2-way SMS communication, OpenStreetMap integration and white-labeling the J2ME app. Some were my own creation, such as the SQlite back-end.

In general, is very difficult to carve 10 appropriate projects from an actively developed open-source project like Ushahidi for the following reasons:

• Ushahidi developers are focused on moving the project forward, adding real features that users care about. As such, they are typically not willing to risk those features not being developed by leaving them to an undergrad.
  Course projects are in 3 month blocks whereas actual development in the project focuses on small increments or “many months away”, so carving off a piece that fits nicely into a 2-3 month course project is hard because that is not how developers think. Developers, from what I gather, focus on the next few week or two, or they may focus on large scale goals (significant re-writes of subsystems) which again are difficult to break down into course projects.
• The knowledge gap – real developers know the code, my students do not. This gaps adds to the difficulty of developers creating projects that can be handed off to an inexperienced student to complete.

Even with the above challenges, our results show that it is possible and extremely valuable to use real software in an undergraduate course project. I believe that our projects on Ushahidi went as well as I could have expected for three main reasons:

The Ushahidi developers cared enough to try and suggest projects. Some projects were fine just as suggested while others could at least give me ideas that I could try and distill into projects. In the end, my responsibility is determining and setting the educational goals, so this worked well. The developers were of a great help, quick to respond to questions and supportive of the students, and I can’t thank them enough for this. My students were willing to accept the “ups and downs” of this kind of project. They knew the alternative was a canned, built-from-scratch project that no recruiter would care about. I was able to convince them that saying they had worked on (and got patches accepted to) a real software project would be of at least some merit over a typical SE course project.

There were certainly some bumps in the road in terms of some projects being too easy (to which I would assign further work) or too hard (a completely working project was not required in some cases). In then end, the students were able to make significant progress on some real problems that the Ushahidi community cared about.

Student Project Review

All that said, let’s talk about the projects, cause they’re really cool.

Dale Douglas (code) added the ability to allow reports to be edited on the main display. His implementation was not secure by any stretch, so may not be deployment ready, but was an interesting project. Dale wished that plugins could overwrite system files so that he wouldn’t have to modify the main Ushahidi codebase.

Brett McKay (code) white-labelled the J2ME app. He also discovered that the J2ME app was in the middle of re-write. So he added the functionality to the new re-write version to add a deployment site and fetch reports. This an example where a student had to take on additional tasks once his initial task (white-labelling) was complete. Brett was challenged in there is actually no documentation of the J2ME app at all

Richard Laan (code) added the ability to select multiple categories on the main map page. Richard’s learning curve was even steeper in that he had to learn Javascript for this project. In the end, a very successful implementation. Tracing the javascript was the most challenging aspect for Richard.

Joel Joseph (code) added a search functionality to the API. This feature allows an API query to search and return results for particular keyword. Joel’s first project was a refactoring suggested by one of the developers. This was another example of a project that needed to be extended once the initial task was complete.

Ranjoat Panesar (code) added a plugin to support 2-way SMS communication between an SMS user and the system. For example, the could stop and start notices or search for incidents related to a keyword. The motivating idea was having a user search for incidents around their current area, but we didn’t get that far.

Alex Molzhan (code) Alex added a button that allowed the incidents to be shown in their incident colour when being displayed under All Categories. Richard Laan is currently continuing to work on this feature in relation to his “Select Multiple Categories” project.

Chris Proulx (code) Chris added an AJAX-based interface to the reports editting page under the administrator. The features chris avoided reloading all the reports when one was deleted. His changes made the reports editing noticeably snappier.

Wilson Liang (code) Wilson created a standalone Java app for the desktop. His application would follow a particular deployment. It may be useful in a situation when connecting to a particular deployment may have intermittent connectivity.

Ruben Estevez de Freitas (document) Ruben worked on getting OSM installed locally and working with Ushahidi. Most instructions for OSM are for Ubuntu, so Ruben learned about the mess that is Linux package management and the difficulty in translating Ubuntu package names to Fedora package names. Ruben’s submission is not a github repository, but simply a document describing all the steps to get OSM working with Ushahidi on a Fedora virtual machine.

Andrew Gergely (code) worked on creating an SQLite-based database for Ushahidi. Andrew ran into two major issues. The first was that the configuration scripts presumed MySQL and were difficult to debug. The second issue was that MySQL and SQLite SQL queries are not completely compatible with each other. The lessonhere was that “standards” such as SQL are sometimes not that standard.

The course ended with project demos some of which the students put up for recording. The students have all made their code available and some are continuing to work on their projects.

I think I can say that the students all enjoyed working on a real software project and found it valuable. There were certainly challenges that the students mentioned. The most difficult was the lack of an up-to-date, detailed technical description of how everything works. The lesson here is that such a document rarely exists, especially on open-source projects. For one, the document would be too massive to read or to keep updated. Updating is especially difficult due to the incremental nature of open-source development where developers’ time is already stretched thin. Know-how comes from mostly from doing and playing with the code, not from documents. Although, as always, more documentation would certainly be helpful both in the code itself and external to it. In particular I think a “How to get started with Ushahidi” document would be helpful for new developers. Second, I think a curated “To do” list for various levels of experience (new, novice, advanced) perhaps on the new wiki, would help with new developers looking for a way to get involved (or for a university professors looking for projects ).

In the end the course went extremely well. I learned a lot about Ushahidi, got to interact with some great people and, of course, some great students. A big thank you to Greg Wilson, Heather Leson, Dale Zak, David Kobia, and Aaron Huslage for all their help and interaction over the last several months.

********
Contact Cam Macdonnell via email

To Cam, all the students and Grant McEwan University:
Thank you being the first class of students to focus an entire semester on Ushahidi open source software development. Your hard work has taught us much about how to integrate Ushahidi software development into classrooms. We are close to launching more changes to make it easier for people to contribute, including more Git love aka a “To Do” list. And, a special thanks to Greg Wilson for advocating open source in Canada’s universities.

To the Ushahidi Community Developer Skype Chat folks:
Thank you for supporting this initiative and answering Cam’s and his student’s questions. We hope to do more of this in the future and hope that you will join us on that journey.

This week several members of our team attended the 3rd International Conference of Crisis Mappers (ICCM) that was held in Geneva, Switzerland and we were blown away by the turn out (Follow #ICCM on Twitter). This community has grown substantially over the last 3 years – when we attended the first conference held in Cleveland, Ohio back in 2009 there were about 100 attendees. Now there are more than 400 gathered here discussing crisis mapping and the challenges they face. There are really 3 main things that we keep hearing as it relates to GIS and mapping:

• How to collect and organize data from the crowd around the globe as it relates to crisis
• How to enable action from this data
• How to build, collect, and maintain reference data for crisis

Collecting and Organizing Data from the Crowd

As for the first topic, collecting and organizing data from the crowd, there is a good tool developed by our partner Ushahidi. Ushahidi is a platform that takes crowd sourced information like SMS messages, categorizes them, and displays them on the map as a point or cluster of points showing relevant location. The result of this effort is a point map that begins to illustrate where individuals are vocalizing need or disseminating information.

Enabling Action

While points are a good start, we have been working with Ushahidi and a focus group comprised of both GIS and Crisis Mappers to define requirements for new tools that will support analysis of this data. We have heard the need for spatial and temporal analysis tools within the Ushahidi platform as well as the need for tools to bring Ushahidi data into ArcGIS where analyses can be run.

We are very excited to announce that we have made the first tool available to support these requirements-the ArcGIS add-in for Ushahidi which can be downloaded and quickly added to ArcMap. This add-in allows you to connect to a Ushahidi instance with the API enabled, convert text between languages, and download the Ushahidi data into a geodatabase. This opens up the feed of data being captured in Ushahidi to the rich spatial and temporal analysis tools within ArcGIS allowing users to empower action and inform decision makers using a sound scientific approach. Curious how this might work? At the bottom of this blog is a good write-up of using this tool to analyze information coming in from the current Thailand flooding.

Reference Data

Having this information and resulting analysis is great, but without good reference/basemap data as a backdrop, it is hard to understand the context of any situation. A common theme discussed here in Geneva is the isolated and rural nature of many locations and the lack of base data. While there may be global vector and raster datasets available, they are often either severely dated or at a scale that does not support local action.

One data set that supports crowdsourcing of basemap data is OpenStreetMap (OSM). OSM is constructed and edited for all types of use by a global user community, and yes you can join! Crowdsourced basemap data is particularly valuable during a crisis response where current and often high resolution data needs are compounded.

In support of this open source effort, Esri offers a desktop tool for ArcGIS that allows you to join the crowd by editing and publishing to OSM from within ArcMap. This tool also allows you to download OSM data over your area of interest directly into ArcGIS for use in a disconnected and offline environment common in response. You can download the ArcGIS Editor for OSM.

Esri is committed to supporting the crisis response community thru our Esri Disaster Response Program as well as thru the continued evolution of ArcGIS to support the collection, management, analysis, and visualization of data in a collaborative environment. While these tools don’t solve all of the problems we face as crisis mappers, we hope you will find them valuable in your arsenal and as a starting point to a dialogue around enhancements to and construction of additional tools or data. We are already looking forward to ICCM 2012 in Washington, DC!

ArcGIS Add-in for Ushahidi

Getting Started

To get started, first download the Esri Add-in for Ushahidi. Once you’ve installed the Add-in you’re ready to add it to ArcMap. Go to the Customize menu | Toolbars | Customize… located at the very bottom of the list.

In the Customize dialog, click the Commands tab| type Ushahidi in the Show commands containing: text box. You will see the Ushahidi2ArcGIS Add-In listed in the Commands pane.

Drag the Ushahidi2ArcGIS command to any existing toolbar in your ArcMap window. You must drag this command onto an existing toolbar, not just onto the map. You will see a new button with a blue circle icon show up on your toolbar.

Connecting to a Ushahidi Instance

To connect to an Ushahidi instance click on the Download Ushahidi Reports to ArcGIS button and enter the parameters.

The key parameter to enter is the API Endpoint. This is the main URL to the Ushahidi instance, such as Thailand Flood Crisis Information Map or Bushfire Connect. You also have the option to translate the data (using Bing Translator) for either just the categories or all the incident data. Note that the more you have to translate and the more records you have the longer the time it will take to download and create the data.

Once the data is downloaded it is added to a layer. The tool automatically sets the data to render on Unique Values in the Category Title field and uses the default colors from the Ushahidi instance.

Additionally the HTML Popup set and the description of the layer has been populated to reflect the source, date and time the data was downloaded. This is critical temporal information for Crisis Mappers.

Perform Further Analysis

Now that the Ushahidi data is downloaded you’re ready to perform further analysis. You can look at data over time, limit your focus on specific categories, or do more in depth spatial analysis.

For example if we wanted to get a better understanding of the reports of flooding around Bangkok we can focus on those reports (i.e. just one category of the incidents).

We can then visualize the data as a “heat-map” (by using the Kernel Density tool).

To get more detailed information on the data and to further determine significance of the reports we can use spatial statistics to determine if there are non-random spatial patterns and statistically significant hot or cold spots in the data. To do this we can use the Spatial Autocorrelation and Hot-Spot Analysis tools. The basic workflow is shown here in ModelBuilder:

The results of this analysis are highlighted in blue on the map as areas (1 km^2 ) that have statistically significant clusters of flood reports (in this case 8 to 27 per km2 ). These are the high priority areas that should be focused on first. Then we focus on questions like why are there so many reports in this area? Is there a single authoritative source of SMS feeds on the ground or is there a large group of people that need help?

This is just one type of analysis that can be run in ArcGIS Desktop from Ushahidi data. We are interested in learning more from you in the type of analysis that you’ve run using this tool. Please use the comments section of the tool and let us know how the tool works and what needs to be improved.

*****

Thanks to the ESRI team for creating this valuable plug-in.

On November 28th, 2011 crowds assembled at 62,000 polling stations to elect DR Congo’s fifth president in the country’s first independently administered presidential elections since independence in 1960.

Polling Station in Bukavu, Ibanda Commune

Technology had improved considerably since 2006 with most people having cell phones and greater access to wireless. On the other hand, the remote areas most sensitive to violence and election fraud are the ones without cell service and electricity. Thus, many of the same challenges remained. Knowing all these challenges, we still decided that deployment would be useful since many organizations are looking to crisis mapping to assist in combating the ongoing insecurity in eastern Congo and massive sexual violence. We could all learn from the experience. The site went live one week before the elections, on November 18th, reporting in French and English.

Organizing Networks and Teams

Through the international partners, a U.S. based diaspora group, RDC2XTE, seeking an alternative vision for DRC through supportive actions to improve accountability and advancement, and our own contacts, we created a network of local independent observers and media sources based in Bukavu and Goma in the eastern Congo and Kinshasa to continuously report back what they were witnessing at various polling stations.

One of our main dedicated partners in the east, the Institute for War and Peace Reporting, trained and organized local women journalists to SMS or email direct reports. A second dedicated partner, Collectif D’Actions Pour La Defense Des Droits Humains (CADDHOM), a local NGO focusing on a wide range of programs concerning human rights, was an official partner of the CENI (the National Election Commission) deploying 200 monitors in South Kivu. CADDHOM sent us reports via email and SMS as they received phone calls and SMS from their official field observers. I also accompanied the executive director of CADDOM, Pasteur Joseph on election day to observe the elections.

Outside EDAP Polling Station in Bukavu with CADDHOM Coordinator, Pasteur Joseph (right)

A third dedicated partner was Catholic Agency for Overseas Development (CAFOD), who organized to station a volunteer in Kinshasa to receive reports from the 30,0000 network of Catholic Bishop monitors in the field. Although in contact with the EU monitoring team, there were no actual exchanges of information and the Carter center did not respond to emails.

We provided all partners with training material and produced post card sized printouts with SMS instructions. I only arrived on the ground on November 25th, but used my time there to meet with local partners none of whom, even though they had received all my materials before hand, had actually visited the site. Internet access is simply too complicated to spend time trying to view a site that takes hours to access. On the other hand, once I arrived and installed the local SIM cards, the Android phones with SMSSync worked perfectly. In fact, since I put the SIM cards on roaming, they work even here in Chicago.

Election Day, SMS Blocked and Lessons Learned

Even with the late start, once the elections got underway we began to receive reports via SMS and email. But then a major glitch came when the government shut down the whole SMS network on December 4th due to concerns of impending violence with the announcement of the election results scheduled for December 6th. Our independent deployment hit a major roadblock between the block on SMS and evacuation of internationals from Kinshasa. I was scheduled to fly to Kinshasa on December 5th, but could not get there since flights were cancelled. All work was suspended in Kinshasa and people ordered to stay home. As CENI continued to delay announcing election results and tension mounted, the CAFOD volunteer could not send any reports. CENI finally announced Kabila’s victory on December 9th, but with growing unrest from the opposition, SMS was not restored until December 14. As soon as it was, we immediately began receiving reports from the volunteer, but these were limited to the December 13th press release that the EU confirmed the Archbishop of Kinshasa’s declaration of irregularities in the elections and media reports.

Speaking with many organizations on the ground, it became apparent that Ushahidi was not widely known in the DRC and, although I physically sat with locals and showed them the platform there was interest, no one I met with could view the site on their computers given the slow Internet connection. A local radio station in Goma. Radio Mutaani, had also set up an SMS system and gmail chat feeding into their website, but were weary of sharing data with Ushahidi given security concerns. I visited their radio station and attended a program at the University in Goma and was impressed with the level of engagement surrounding the election. Until SMS was cut off, they had a lot of activity through their gmail chat.

Without SMS the deployment shifted to media monitoring coordinated by undergraduate Liz Casano of the NorthWestern University Student team and Bharathi Ram and Leesa Astredo of the Stand-by Task Force. The SBTF was instrumental in sorting through and reporting on more than 20,000 tweets. So far, a total of 320 online reports have been uploaded from over 70 locations, comprising 55 types of incidents. There are over 150 reports still waiting to be input into the system, most likely with more to come as the team reviews additional media sources.

One of our goals going in to the deployment was to be able to provide a broad platform to link up the work of local and international monitors and amass all the reports in “real time” for use by all. We learned that this was not in the best interest of the official monitors. Given the strategic role of the National Episcopal Conference of the Congo, the country’s Catholic bishops’ council as the largest monitoring group, it was in their best interest to kept their reports secret until ready to make an official announcement which they did on December 12th. In the end, the need of human rights and humanitarian organizations to report on and respond to crisis, did not coincide with the needs of official monitoring efforts to postpone release of information until they could better assess and negotiate the political implications.

Although more time to conduct networking on the ground would have produced more buy in from humanitarian, civil and human rights organizations, it seems that in the end we might have had the same problems given the SMS and need of the largest observers to withhold their reports until the best strategic moment.

The project team is now shifting its focus to analysis. In the next three months our goal is to issue two reports on the elections. The first will examine the question of transparency that was central to the rejection of the election results by the opposition and critiques of the official monitors. The second will layer in additional data to seek to answer questions broader questions such as did NGO civics work result in reduced problems? Were their areas that had violence in 2006 but not this time? And what kinds of responses were most successful and why?

At the beginning of March 2011, OCHA HQ activated the Standby Volunteer Task Force (SBTF), a self-organized group of structured volunteers, to create the Libya Crisis Map (LCM) early in March of this year to help provide better situational awareness of the unfolding situation on-the-ground. This site and the data were made available to responding organizations with the intention to them improve their operational planning. The site was extended beyond the first month largely based on efforts from OCHA Colombia, volunteers sourced from the UNV online volunteer service, and SBTF members who choose to stay on beyond the official SBTF deployment.

But Why the Collaboration?

The LCM data was being incorporated into the traditional Who-is-doing-What-Where products and info-graphics which were being created remotely by OCHA IMOs [Colombia, DRC, Ethiopia, Kenya, Pakistan, South Africa, and South Sudan]. These products were then being printed and shared inside the emergency arena. So, what impact did those printed products have? We rarely try to measure their impact on decision makers but recognize they are necessary in every emergency. So, if the LCM data augmented these products, what measurable impact can we say it had?

The challenge in quantifying the impact of information products in situations such as the Libya crisis is they tend to be incomparable to other situations and may yield very skewed outcomes. For OCHA, the impact the volunteers had on the efficiency of the operations and quality of decisions being made is perhaps more interesting. This impact can be more easily quantified by assessing the effectiveness of the decision makers using the maps as input and compared to their workload in other crisis before the SBTF was put into action. This quantifying research is currently being conducted, but on our preliminary qualitative input we can already see that the SBTF has a significant impact on OCHA’s way of working.

The unexpected impact? How we now work differently.

There are three core areas in this collaboration that have influenced OCHA’s work:

1) Speed: as noted in my blog post on UN Dispatch at the end of March, I outlined how much faster we could produce standard IM products in the early phases of an emergency when working with remote volunteers and/or staff. It was quite stark and significant.

2) Connection / Communication: The information management team in OCHA HQ was quite impressed with how well the always-open, tiered Skype chats worked in collaborating with the self-organized task-team based volunteers. The team has taken this approach and opened our own group for OCHA Information Management Officers [which has really made our internal IM Community of Practice flourish and provide support to each other]. We have leveraged the same approach to help incorporate field-based staff into the development of standard tools and software – something we were rather poor at in the past. As well, when we had one IMO responding to floods in Cambodia, we asked for OCHA IM volunteers and placed them in a dedicated Skype group. We ended up with IMOs from Sri Lanka, Pakistan, Cote D’Ivoire, Liberia and Haiti helping out with the efforts.  The OCHA IM team is really learning how we can leverage remote support and are incorporating these concepts into traditional mechanisms.

3) Collaboration Platforms: to collaborate with the external volunteers, we had no choice but to accept the use of non-UN standard software [e.g. Skype and Google Docs]. However, the abilities that these modern tools unlocked helped some of our traditionally skeptical staff members realize there are better ways of working.  It has started a culture change [even if slow].

So, you can easily deduce that OCHA is adopting concepts from the SBTF work style. How much of an impact is that?  Perhaps not quantitatively measurable, but could be qualitatively described a “big”.

But, what challenges arose from the use of new technology and the volunteers?

The challenges can be summarized into three categories:

1. Zoom Level. The volunteers tend to want to work at the highest possible zoom [i.e. close to the affected] and we can understand that desire. However, large responding agencies are dealing with multi-million dollar programme spanning across millions of people in countless locations.  Although they are concerned for the individuals, they need information at a different ‘zoom level’ in order to assess, plan and respond. Thus, we need to ensure that there is a way to aggregate the detailed data appropriately for people or organizations working at different zoom levels.

2. Always On. One major benefit of the volunteers, enabled by modern technology, is that they are dispersed around the world resulting in almost 24 hour support. However, the flip-side of that benefit is that the liaison person from the requesting entity can be faced with questions/issues around the clock if structures, messaging and requirements are not defined early. With the task-team structure used by the volunteers in place, we know that OCHA was sheltered from a large number of questions. Still, in the early days, there were a significant number of topics that arose which needed to be addressed. It meant that we had to be connected all the times – from checking Skype over breakfast, to responding to emails while on the bus, to skipping dinner in the evening to review a risk management strategy.

3. Questions. The volunteers are not necessarily experts – and do not pretend to be when they are not. The challenge for the requesting entity is that someone needs to be available to answer hard questions in a very timely manner. In the Libya context, defining appropriate report categories was one of the first and most challenging questions for OCHA to answer and has reconfirmed that standards are needed.

Did ethical questions arise for the UN?

Of course ethical questions arose during the LCM deployment. They were not specific to the UN. In the Libya context, we dealt with three specific issues:

1. Identify. We did not want any information provided in the LCM that could be used to identify the individual who reported.

2. Location. To avoid anyone from being able to pinpoint anyone reporting, the data was generally anonymized to the centroid of the city it was reported from.

3. Do No Harm. Given the situation in Libya was conflict-based, we needed to ensure that whatever we did minimized the chance of causing anyone harm.

Early in the deployment, OCHA made a decision to run two separate websites. The private site would hold all original data and only be accessible to approved agencies. The public site would show no identifiable information and the data would be delayed by 24 hours. Some have argued that two sites were not necessary [e.g. everything private or only have the anonymized public site], but all we can say is that “It worked”.

What is OCHA doing now?

In June, OCHA held a lessons learned workshop with several of the V&TC entities with whom we collaborated with either for Libya or Japan. That workshop pointed towards 9 thematic Communities of Interest (COIs) to be developed to ensure future collaboration can be maximized [see the final report]. OCHA has been pushing these forward in an attempt to get them started and hosted a one-day meeting with the COI leaders prior to ICCM 2011. [Note: originally a Humanitarian Standby Task Force was suggested, but it has morphed to a 'network-of-networks' concept - which will likely be called the Digital Humanitarians - and be designed to receive requests for virtual support and then find the appropriate entities to support those requests]. In the Libya and Japan crisis, OCHA received support from several V&TCs which resulted in some (positive) unexpected impact and we want to continue to explore and understand the possibilities through the COIs mechanism to help maximize the benefit and effectiveness of V&TC engagements with the traditional humanitarian entities.

This collaboration, amongst others recently, has helped to show OCHA’s IM team that we need to open up our work, our data, and our ideas to external parties very much in accordance with the principles Dan Tapscott outlined in Macrowikinomics: Collaboration, Openness, Sharing, Integrity and Interdependence. We are no longer in an era where good ideas only come from inside our own organization, but rather in a time where we have to be open and ready to receive them from outside.

Participants in November 2011 COI Leadership meeting included: Crisis Commons, Crisis Mappers, Geeks without Bounds, GISCorp, Harvard Humanitarian Initiative, HOT (OSM), ICT4Peace, Internews, ISCRAM (Tilburg University), MapAction, Missing Persons Community, MIT Humanitarian Response Lab, NetHope, SBTF, UN Foundation, UNHCR, UN-OCHA, UN-SPIDER, University of Munser, UNOSAT, Ushahidi, US State Department (HIU),  Woodrow Wilson Center, World Vision

]]> http://blog.ushahidi.com/index.php/2012/01/09/the-unexpected-impact-of-the-libya-crisis-map-and-the-standby-volunteer-task-force/feed/ 1 http://blog.ushahidi.com/index.php/2011/12/15/rhok-the-next-steps-for-ushahidi-hacks/ http://blog.ushahidi.com/index.php/2011/12/15/rhok-the-next-steps-for-ushahidi-hacks/#comments Thu, 15 Dec 2011 20:07:25 +0000 hleson http://blog.ushahidi.com/?p=6544 Random Hacks of Kindness (RHoK) is a short and mighty sprint of brains colliding to prototype on solutions on real world problems. RHoK was held on December 2 -5, 2011 around the world. We were delighted to see some projects use Ushahidi.

Being part of a global hacking community supporting open source software is very important to Ushahidi. Community members participated in various cities or virtually. They answered questions, taught each other, and happily, gave us feedback on how we can improve. We hope to support some of the project leaders as they continue to work on these initiatives.

Here are some of the weekend highlights:

Water Quality reporting

The co-winner of RHok Montreal, Watervoices, collaborated with RHoK Toronto to build an Ushahidi deployment focused on giving people voice about water quality in Northern Canada. The WaterVoices project was co-lead by Steve Sauder and Melanie Gorka. The teams in both cities included front-end and back-end software developers, international development specialists, emergency managers, graphic designers, open data advocates and researchers. The prototype is currently offline, but you can follow their twitter account (@mywatervoice) to see how they will proceed. To learn more, see a WaterVoices video featuring the RHoK Montreal team members.

Another highlight of this project was testing an easy-to-use application that lets people use Tropo to input data into Ushahidi via SMS. Thanks to the Tropo team for this! It is now available on Github for other people to use and test.

Offline to Online Communications

How to give voice when technology is unavailable is a huge quandary. There were a few hacks that worked with existing solutions testing to Ushahidi. The Reflab team with Francesco Ciriaci leading the charge built an HTML5 hack for reporting Offline/Online. This hack is something that Ushahidi would like to see continue. During RHoK, the DRC map was unable to receive SMS reports due to connection issues. We will be connecting with the various hackers and groups involved during the weekend on this to see how to move it forward, including Geeks without Bounds, Reflab, Mozilla, Tropo and more. The RHok Zurich team worked on Message Carrier (another offline/online communication tool). The code is listed on github.

Also see Francesco Ciriaci’s post on his Mobile Web App for Ushahidi.

Other Ushahidi RHoK Hacks

RHoK Montreal worked on a Security Alert App for Humanitarian Workers. Medicins San Frontieres provided invaluable use case input to the team who created this Ushahidi prototype using Tropo. To learn more, see their presentation and videos (see Part 1 and Part 2).

For two RHoK events (including Rhok Portland this month), Pascal Schuback has been hacking away on SAARRA: Situational Awareness and Rapid Assessment Application using Ushahidi. He continue to work away at this and would really like to know how to have the ruby app work with Ushahidi software. If you have knowledge and can assist, let us know.

Luis Hernando Aguilar, RHoK Bogota lead, had a team of people collaborating on the “Sistema De Control de Simulacro” using Ushahidi to test within official humanitarian simulations.

RHoK Boston participants lead by, Rufus Pollack, hacked on a Pybossa to Ushahidi Geodoing Microtasker (github link).

And, lastly, we’re really excited to see Open NASA’s multi-partnered efforts with The Catalyst Map. Various cities built prototype on how actions plus activists can be connected to big data. Stay tuned for more on that topic.

RHoK in over 30 cities can be very hectic with global collaboration and juggling hacks. If we missed any active projects that used Ushahidi at RHoK or if you want to elaborate on the detail, please add comments below.

We’re excited to see these projects come to fruition and hope to see the next steps!

The Nangahar Connect deployment, which crowd sources information on commodity prices of beef, veal, milk, corn, wheat[Commodities], labour prices, service prices etc. This is a deployment that is well populated with information, run by the ministry of Agriculture and uses the Ushahidi Cloud based application (Crowdmap). What struck us about this deployment is first, the amount of data available. Substantial. Khalid Amini, the Manager of Geospatial services at Afghanistan Information Management Services AIMS commented that the data was accurate.  We explored the map more on mobile by using the filter capability on the mobile app mentioned above. Mohammad Nasir Shir, The Executive Director of Gisworking.af explored with us and we found that the deployment also included diesel prices. Mr. Mohammad noticed that there was information about fuel prices in an area that is relatively dangerous to be in and that it was great to have access to such information online and on mobile.We were speechless at both observations; Because we just discovered a great source of information that is geolocated, contextual and relevant to Afghanis. It is encouraging that our platform and service is of use to the Ministry of Agriculture in Afghanistan, and the people of Afghanistan. Explore the map and add the irrigation channel layer provided on the site. Many thanks to the Ministry for doing this deployment, we are certainly in awe of what has been achieved thus far.

As we go into 2012,the experience underscored our plans at Ushahidi to organize Crowdmaps by country so that discoverability of initiatives like this can be more commonplace and easier than it is right now. We are inspired and encouraged by the various uses, and this particular deployment gives us a glimpse at how useful contextual information can be disseminated, and how layers can be used to provide even more context. We will continue to explore and bring you ways to engage with and contribute to Crowdmaps around the world, on issues that you care about on a local level.

When you get speechless about discovering something together, the thing you do is take a picture right? Right. This is the picture we took to remember this joint moment of discovery and awe. That the picture was taken by Dr. Michael Gould of ESRI adds another of awesome doesn’t it. In case you missed it, ESRI has been a great technology partner for Ushahidi. Data feeds from Ushahidi deployments, Flickr and other geo services can be overlaid on custom ESRI maps.

Ah. Khalid Amini AIMS, Angela and Juliana of Ushahidi, Mohammad Nasir Shir and Bilal Ahmad of Gisworking.af

There’s a problem that constantly plagues us in this day of information overload, and that is the ability to sift the stream of incoming information into the bits that are valuable from those that aren’t. It’s a tough issue that we’ve been working on at Ushahidi, and re-working, a solution on for a while now. Our solution is called SwiftRiver.

SwiftRiver is a free and open source intelligence platform that helps people curate and make sense of large amounts of information in a short amount of time. In practice, SwiftRiver enables the filtering and verification of real-time data from channels such as SMS, Email, Twitter and RSS feeds. It’s especially useful for organizations who need to sort their data by their unique expectations of authority and accuracy, as opposed to popularity. Such organizations include journalists, community based-organizations, PR/marketing, emergency responders, election monitoring groups and more.

SwiftRiver, In Plain English

There’s a torrential river of information that’s constantly flowing on the Internet. If you dive into that river in search of something, chances are you’d drown.

Now before we go any further, let’s first define this river of information. Simply, the “river” is made up by billions of bits of information. In the context of SwiftRiver, we call these things “droplets.” For example, common droplets in the river are tweets, Facebook updates, and blog posts. These are common examples, but by definition, things like text messages, emails, and even rows in a database table are considered droplets, too.

So how does SwiftRiver help you make sense of all these droplets? Well, it analyzes droplets much like your brain analyzes the world around you. For example, when you look at a kitchen table, your brain instantly determines its color, height, location and texture. In the same way, when SwiftRiver looks at a droplet, it determines all its attributes. For example, if SwiftRiver looks at a tweet, it can determine things like location, time, author and meaning (in the form of keywords). Generally speaking, SwiftRiver does this using a process known as “natural language processing.”

Once SwiftRiver analyzes all the droplets, you then have the ability to filter them down from that torrential river to a manageable stream. In addition to filtering, you can run different analyses on them, helping you get the “big picture” of your set of droplets.

SwiftRiver Glossary of Terms

Droplet: The basic unit of content inside SwiftRiver, i.e., a tweet, a Facebook update, a blog post, an SMS text message, etc.

Identity: The originator of a droplet from a specific channel, i.e., a Twitter account, a Facebook account, a phone number, an email address. Identities are automatically extracted when a droplet is “siphoned” from a channel.

Source: Comprises one or more identities, and could be a person or organization. Unlike identities that are automatically extracted, sources are subjective and put together by users in the system.

Channel: The vehicle for transporting a droplet into the river, i.e., RSS, SMS, Twitter, JSON, XML, etc.

River: The torrent of droplets that come from the predefined channels.

Filter: The mechanism for reducing a channel or river from a torrent of droplets to a more manageable set.

Stream: A collection of droplets whose contents are defined by a filter or a combination of filters.

Bucket: A group of hand-picked droplets from a stream.

Trends: A narrative based on the droplets in a bucket. Components: description, time, sources, places, media (links), tags, theme.

Types of stories, i.e., outputs:

• Text
• Maps
• Timeline
• Graphs, Charts, Heatmaps
• Gallery: Photos, Video, Audio

A sneak peak at the rebooted platform

Since the end of this summer, the Ushahidi team has been focused on rebuilding much of the platform so that it would dovetail perfectly with the Ushahidi core platform and Crowdmap. So, it’s a standalone application that anyone can access and use by itself, but it also answers our users’ need for a faster, more nimble way to manage information flow on their deployments.

Back in August, we completed the first iteration of our ID and authentication system, RiverID, the first step needed for us to have a collaborative profile-based tool for SwiftRiver services. In October, we locked four of the Ushahidi team, made up of two designers and two engineers, away in a cabin, deep in the woods of Georgia. Their job: Do two months’ worth of work in six days.

This they did.

While we haven’t released the code yet, the beta will be available in mid-December (three weeks) for the community first, then for the general review. But, in an effort to quench your curiosity, here’s a sneak peak via screenshot.

As mentioned earlier, SwiftRiver will be available in the coming weeks. We will release the roadmap, a new look and feel, and provide an outline on how you can contribute to the next Swift. You can connect to the Swift community via our google group: swiftriver@googlegroups.com

Evan extending an outdated looking point and shoot camera in a pub.

Evan brings a unique element to the team with his background in game design. He worked on projects like Conduit 2 for the Wii and The Grinder for Xbox 360. This is not to say that Ushahidi is planning a FPS any time soon! Evan has years of experience in all aspects of web development, from great looking front end work to building servers that scale. His latest personal project manages a quarter million World of Warcraft game items on WoW Instant.

Evan has already been hard at work testing out different scaling technologies in conjunction with Ushahidi, fixing bugs and taking names. All of us at Ushahidi are excited to see what Evan conjures up for Crowdmap and the platform as a whole!