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.

Okay, so what does that mean to regular folks? How about: We care about our communities and the world around us. So, we need to protect and improve it. How can we know more and be actively involved in the real changes, even at a incremental level?

Call to Map it, Change it.

The UN has stacks of resources about RIO+20. The Future We Want is an initiative focused on opening up the process to: Share your ideas. The UN’s Sustainable Future site includes a list of organizations and movements who demonstrate the power of: What Can You Do?

We invite you to join the fray: What can you map? There are countless local and global stories related to sustainable development. Take map aim at an issue that you care about to highlight the need for real change.

Mapsters in Action

At the recent United States Rio +20 pre-event, Ushahidi had a chance to feature the work of amazing deployers trying to share, understand and change their world. These examples should get your mind spinning on some of the untold map stories that you could activate. Citizen crowdsourcing can elevate and visualize your subject. And, you may be surprised who you hear from and how you can collaborate.

The Cost of Chicken project works with kids from around the world to collect data on local food conditions. It uses Crowdmap to track and share information ranging from the cost of chicken, water, and, even, candy. Learn more from Olga Werby, mapster advocate:

Can those kids be any more inspiring in their search to understand and connect with each other over food production? Thanks to each one of them for sharing their passion for change.

Take a World Tour:

Deployers around the globe are mapping about sustainability. These are some examples we shared at USRio+20:

• Global Energy Shortages This map includes a layer of Ajay Kumar’s project Powercuts.in.
• Find Fuel in Nairobi, Kenya
• Ministry of Agriculture, Irrigation and Livestock: Nangarhar Agriculture, Irrigation and Livestock ( DAIL ) (Afghanistan). More on this project: “A Moment of Discovery and Awe“.
• iWitness Pollution (Louisiana, USA)
• Spotting Fair Trade in North America (supporting sustainable products) (USA)
• Agrotestigo: Mapping Agricultural Social Networks (building collective resources about agricultural technologies) in Argentina
• Qiantang River Water Map 钱塘江水地图: A Collaborative Interactive Water Map for Qiantang River (China)

If you have more examples of great maps, please share them in the comments or add them to our Deployments Map.

And, when you create a new map, be sure to tweet to @UN_Rioplus20 and @ushahidi. Use the hashtags #futurewewant. We’d be happy to feature your map story on our blog. Simply drop us a line.

More Resources:

• Official United Nations Conference on Sustainable Development (UNCSD)
• UN Sustainable Future site
• United States Rio+20 Conference
• The Future We Want

Thank you: USRio20 participants and organizing team

Thank you to Noel Dickover, Richard Boly and Sarah Jessup for inviting Nat Manning and I to participate in USRio20. Special thanks to Carmelle Terborgh, ESRI, for supporting our participation.

We were delighted to meet participants and to brainstorm, learn and Speed Geek [video] about these important topics.

Thanks!

Heather L.

The world was shocked to learn about Kyrgyzstan’s second revolution within five years. The country’s anger resulted in the ousting of two presidents, and the 2010 revolution was followed by interethnic violence in the south of the country – making 2010 a challenging year. Some doubted whether Kyrgyzstan could remain independent and sovereign.

At the time, UNDP sent experts to the country to assess the situation and provide  technical support. Jens Wandel visited the UNDP office in Kyrgyzstan to learn about our projects including our support to the elections.

He asked me if I had heard about Ushahidi, a free, and open source software for collecting, visualizing and mapping information. Ushahidi is Swahili for “witness” or “testimony” and was used  for the first time in the 2007 Kenyan elections.

Since then, I have become addicted to the idea, especially since it coincides with our plans to use information and communication technology in our work to support democratic governance.

Since Jens arrived just before the Kyrgyz parliamentary elections, we didn’t have time to properly explore how the platform had been used, and ways to adapt it to the Kyrgyz reality.

Later, we learned that Ushahidi had already been used in Kyrgyzstan several years ago by a local NGO that recruited local election observers. However, they used the available software without adapting it to local circumstances and didn’t coordinate their activities with other partners.

I consulted local software developers and not only did they know about Ushahidi, but they also knew about the first time it was used in Kyrgyzstan and had a clear idea how to adapt the open source software to moderate activity on election day.

The beauty of the concept is that the final product would become a universal platform focused not only on electoral violations, but on other issues such as natural disasters like the earthquakes inHaiti and Japan.

The next step was also quite challenging: Could I convince my colleagues and our national partners that this is a useful and inexpensive way of exposing electoral violations during elections day?

Some of my colleagues were skeptical, mostly because of the complexity of information and communication technology. There were some doubts that local civil society would buy into the concept and participate.

In the end, proponents of the Ushahidi software prevailed and we hired a local group to develop the supplementary software and to moderate the process on election day.

Another requirement was to ensure strong coordination at all stages between the developers, the Central Electoral Commission (CEC), and key NGOs that would be providing information on violations to the system.

About 3,000 text messages with information on electoral violations were verified and posted online. More than half the violations were observed and reported in Osh and Bishkek, the biggest cities in Kyrgyzstan, and there were more than 27,000 hitswith an average duration of about  two minutes.

Kyrgyz NGOs gained experience with the Ushahidi platform and adapted it to the country’s needs. We saw firsthand that the platform can be used to monitor and increase the transparency of elections.

The CEC not only supported the idea and monitored the site, but also used some of the information for their own purposes.

Well, the statistics shown are quite impressive, however, the main question is this:

What is a non-expensive way of making sure that information from the website reaches each potential voter right way? Especially to the first voters, to demonstrate that the electoral processmust be and can be transparent, and any violation will be recorded and shared with the community?

What do you think?

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.

Here’s a full report from Kate Cummings, Program Manager for Ushahidi Liberia:

John is a remarkably talented developer and teacher. He has dedicated much of his time to not only creating contextually relevant plugins and features for Liberia’s Ushahidi instances, but also has spent the last 8 months conducting intro to programming training for the local staff so they can contribute their own code to the Ushahidi platform (and beyond). Working with John is an honor; he’s a natural humanitarian, always seeking ways to combine his technical expertise with pressing needs in places like Liberia.

The Simple Groups plugin – allowing multiple organizations composed of several unique users to have private admin access to the same Ushahidi instance. Each group has a private admin page that contains their own messages, reports, and admin map. Here are features we’ve added for groups:

• Whitelisted phone numbers – trusted sources’ phone numbers can be linked to particular groups
• Tagged reports – each group’s report is tagged with the organization’s logo so viewers can quickly identify the source that has approved and determined the verification status of the report
• Admin Map plugin– many partners to keep certain reports temporarily private due to their sensitive content. We created the Admin Map on each group’s admin page that shows all unapproved reports as black.

More features of Admin Map:

• Multiple categories can be compared at once using the Boolean functions OR and AND. These logical operators give groups a new way to look for trends in their data
• All of these features have also been added to the instance’s homepage (all except groups’ unapproved reports). Click on the “Big Map” button at the top of the election homepage
• Location Highlighter - When our partners are turning messages into reports, it can sometimes be difficult to find the message’s location on the map. To expedite this process, the Location Highlighter tool outlines Liberia’s counties and districts on the map to narrow the scope of the search. Because most of our groups work with low bandwidth, the Highlighter’s clear parameters allow admin users to spend less time clicking and dragging across the map and more time searching a clearly defined area
• Forwarding Messages feature – Because several of our partners have a customized instance and are Simple Group members on a shared instance (like Liberia 2011 or LERN), the “forward messages” feature was added so messages could be shared between the admin sides of both instances. We also created a code library for interacting with the Ushahidi API; this made it easier to use the API for forwarding messages, and will make it easier for all Ushahidi developers to interact with the Ushahidi API.
• Print Map – A map that’s setup to print well on letter and A4 sized paper. This page also adds a key to the map, so when it prints the user can see what categories were selected. The print map page also lets users create a link to just their customized map and selected categories. For example, if you wanted to show someone the reports of violence (one category) and women & children (another category) send them this link generated from the Print Map page at the bottom
• SMSSync and the platform – After extensive testing led by John Etherton and Ushahidi’s Henry Addo have formed a reliable protocol for operating SMS services in Liberia. Several issues were corrected in the SMSSync plugin and additional software was used on our phones to ensure the phones don’t default to “sleep” mode (which was disabling SMSSync). We now forward SMSs to our Ushahidi instances reliably.
• iFrame Map - This is for people who want to embed Ushahidi in another website. For an example, see this demonstration. Some of our partners that use the LERN site are using this feature to highlight their maps on their own websites
• Density map plugin - Another new feature on the instance is Ushahidi’s first Density Map plugin. Located on the right side of the homepage, just above the categories, the Density Map option makes it easier to separate reports by geographic region – in this case, by county. All reports that have been associated with a particular county will show up using the Density Map. This feature was requested by UN OCHA as well as other local partners, and serves as a small step towards making the Ushahidi platform a data analysis tool.
• Internationalization – Thanks to John’s twice-a-week programming trainings with Ushahidi Liberia’s local staff, many of the plugins written for Liberia have been setup to work in other languages. This helps to ensure the work we do in Liberia can be used in other parts of the world.

Contact John.

About the Ushahidi Trusted Developer Program

We are very thankful for our growing community. Each of their contributions are valued. We started the Ushahidi Trusted Developer Program to recognize excellence in Ushahidi software development.

Previous Posts in this series:
Introducing Ushahidi Badges
Recognizing Ushahidi Deployment Partners

Thanks John for all that you do! And thank you Kate for sharing.

I’m Kuo-Yu slayer Chuang from ITRI, a government funded research institute in Taiwan. We developed an open standard for exchanging location information via SMS among mobile devices called Open GeoSMS, which has currently been adapted officially by Open Geospatial Consortium (OGC). Several use cases of this standard are shown with the following video:

We introduce Open GeoSMS with a quick and real example. Noritsuna-san is a friend of mine from Japan and a guest researcher in our company. One night, I got an SMS from him saying that he can’t get taxi home since it’s too late. I had no idea where he was and he could not read the street names in Chinese. I thus asked him to send me an Open GeoSMS with our free application. I then got an Open GeoSMS with the coordinate embedded in URL that points to Google Map service. At the end I totally new where he was and drove my little car to rescue him.

In the previous case, Open GeoSMS sent as a peer to peer message between mobile phones. It can be also used between mobile and server in disaster management. Users who have smart phone with GPS for incident report can attach coordinate in SMS with Open GeoSMS format (usually, with an App such as Ushahidi app on Android that we hacked).

This feature enables users to do incident reporting without a data connection. We know some volunteers bring their own smart phones and work with expensive data roaming fee. This feature also enables the backend server to auto-process the geo-tagged report, and insert this POI to map automatically. Rescuing activity or the resource transportation tasks can be assigned with Open GeoSMS for more specific location information. Especially with the offline map supported such as Open Street Map, POI-based information exchange can be easily achieved through Open GeoSMS.

As for the notification, the server doesn’t need to care if the receiver is a smart phone user or not. Open GeoSMS notification is just an SMS and that works for almost every phone. On a smart phone, Open GeoSMS can bring out more information via URL. The latest spec and code are available on Google Code. If the SMS with coordinate is compliant to Open GeoSMS, other applications or services can easily parse it and get the x and y coordinates. Last month during a cyclone simulation of Samoa, PinPointAlerts provided Open GeoSMS as a notification option on http://www.SamoAlert.com so the simulation notification could be sent with this open standard. Our team also shipped five smart phones to Samoa with an Open GeoSMS enabled Ushahidi app installed or this Cyclone Simulation activity. As a result, not only could the general SMS-based incident reports be made, but also the Open GeoSMS style geo-tagged SMS could be sent to server for the possible automation afterwards.

Our team has hacked an Open GeoSMS enabled Ushahidi Android App, now we are working with Ushahidi mobile app team on additional projects to merge our technologies. Our next step is to implement a plug-in for Ushahidi to parse Open GeoSMS in order to gain the automated processing ability. Further objectives include working with offline maps such as Open Street Map (OSM) so users can have a better understanding re incoming Open GeoSMS. For more information and our latest activities, please visit our facebook page.

We really hope this tiny handy open standard can help people in various way

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!

During the 2011 Liberian Election process, Ushahidi Liberia proved to be an invaluable team member for the United Nations Mission in Liberia (UNMIL).  Their crowdseeding efforts provided the people of Liberia, UNMIL and others, with timely access to objective reports from around the country.  Lighter and more agile than the UN structure, the Ushahidi Liberia team was able to collate nearly 5,000 reports from perspectives previously not readily accessible to most observers.  Additionally, the constant communication by phone, email and in person between Ushahidi Liberia and the UNMIL Joint Elections Operations Center (JEOC) personnel allowed for cross fertilization and information vetting, improving the fidelity of reporting for all consumers.

Situational Awareness Tools

The best sensors are the human senses. Broadly leveraging what these sensors acquire is impossible without standards, tools, training and leadership, structure that is both formal and informal.  The affected, on-the-ground responders, and providers with reachback capabilities create a circle of dependency that is often broken because of the lack of structure. On the flipside the ability to achieve and maintain situational awareness was and remains bound by the lowest common denominators of an organization and its personnel. The Ushahidi platform allowed UNMIL to break through some of the challenges of:

• Knowing what information is important, available and where to find and leverage it
• The End user’s
  • Education level
  • Language skills
  • Computer skills
  • Motivation level
  • Access to tools (power, computer, internet, phone)
  • Training on the tools

Information flows during Liberia's 2011 election

In the end, success was based on preparation and relationships.  The Ushahidi Liberia team provided access to resources and information that UNMIL simply could not have leveraged in their absence.  Constant communication by phone, email and in person between Ushahidi and the UNMIL JEOC allowed for cross-fertilization and information vetting.

About Ushahidi Liberia

1. Ushahidi Liberia has direct partnerships with 16 different NGOs (international and local), civil society coalitions and the government. Among these partnerships there are many other indirect partners (example:  Elections Coordinating Committee is a partner, but they are composed of 30 organizations; IFES has 20 CSOs that Ushahidi has trained who are out in the field reporting to them, etc). Ushahidi has also provided a map for UN OCHA made at their request.

2. Ushahidi had about 7 volunteers during the first run-off.

3. Total reports on elections instance since January = 4,954 (that are public)

4. Androids – Ushahidi had 4 of them running the free election shortcode and also the free long number for a national early warning map (LERN).

5. Ushahidi Liberia’s VSAT connection during the election was 1054/512 kbps (the fastest public internet connection in Liberia), now reduced (due to high costs) to 768/256 kbps – it is a dedicated C-band connection available to Ushahidi Liberia users in their facility. They have 16 computers running open source software. Their Dir. of IT, Dir. of Training, and Program Director are based in-country, with a Tech Lead based in the US.

Data from USAVE to end users

The geography of crisis and response

Geographic location, type of crisis, responder specialty and organization greatly impact the way in which the individual will operate.  However, each shares common, basic geographic (map) data requirements.  Imagery, terrain, political boundaries, infrastructure and hydrography are the minimal data sets required for any type of fieldwork.  Depending on the event, political, social, demographic, medical, refugee, reported violence and other kinds of information may become most critical to obtain.  For the purpose of this thought process we will focus on the base geographic data requirements.

LOCATE: Where am I?  Where is the disaster?  Where are those in need?  Where are response resources?  How do I get to the resources?  How do I get the resources to the affected?

- Country, city, town, base camp and devastated area

- Affected, other responders, and external partners

- Infrastructure (water, power, communications, sewer, medical, transportation, and security)

- Resources (water, food, shelter, medical, transportation, communication, security)

COMMUNICATE: Information, requirements, coordinates, coordination, challenges and successes.

- Affected, other responders, higher headquarters and external partners

- Collected field data, open source

- Data, space and ground based sensor data

- Needs, challenges and successes

FACILITATE: Response, assessments, support, capacity building, documentation & retrograde.

- Information collection and sharing

- Resource acquisition, delivery and employment

- Initial and sustainment training

- Documentation, configuration control

- Responsible turn-over to and departure from Host Nation

Just on the tip of what is possible

Looking to the future

If space-based providers can push data down to the lowest common denominator in a timely manner, in a format they may leverage, the future is bright.  If not, expensive space-based products will remain tools employed by the elite and an educated few “in the know”, remaining invisible to those it would best serve.  Using geographic information systems is no longer a luxury, it is a necessity across the spectrum of United Nations mission sets.  Manual procedures of reporting, filing and analyzing information should be placed behind us.

The success of the next crisis response begins today.  With the right equipment for the mission, end users may even operate disconnected from the grid, know where they are, collect and share information with others on the ground and, when finally connected, receive and transmit vital information to all interested parties. Each scenario requires the end user to pack appropriately based on factors such as financial resources, logistics restrictions, availability of infrastructure within the impact area, on-ground transportation and individual capabilities.

To give the end user access to harnessed capabilities one may consider providing equipment and training so the value may be broadly shared amongst operators instead of unintended hoarding amongst technical specialists.  If the end user connects to the grid, they will be able to receive timely ground and space based data like high resolution post-event imagery from numerous sources, as well as interface with the “cloud.”

The future is already here

A circle of dependency has become apparent between organizations, formal and informal, and the crowd.  They are intertwined, even though some resist.  The bounds have become tighter and the value greater among those parts of the circle working with, rather than against, each other.  During the election season, Ushahidi Liberia provided an environment of professional cooperation necessary for the cultivation of numerous complex relationships.  Together, we have taken a very large step forward into the future. Although, likely never to be the same, the road has now been traveled.  There is no going back.  Know the past, anticipate the future, show the way!

What types of hacks? Here’s an example from Dave Leng of Samoa

Dave’s “Make Ushahidi Dynamic: Ushahidi tweak from static to dynamic display of incident reports” proposed hack is something he has been pondering since the summer. He would love for this hack to be ready for his team in Samoa and our friends in the Standby Task Force to use for the UN Spider Samoa Simulation (occurring at the same time as RHoK). If you can hack on this keep us posted, I’d recommend a design jam as it will be a large project to prototype over one weekend.

Connecting others doing Ushahidi RHoK Hacks

We’d love the wider Ushahidi community join a local city and help out on some of these hacks either in person or virtually. I’ll physically be in Montreal, Canada for RHoK, but online. Global collaboration can be hard via Google docs, Skype and email, but fret not. We have a plan:

1. Join the RHoK community and sign up for a problem definition and connect with the problem owner. (See the list below for specific hacks citing Ushahidi.)
2. Participate in a local event or connect with a problem definition group online. Keep in mind that the group hacking may be in a different timezone.
3. Next: If you are a member of the Ushahidi Community Developer Chat, please ping us there to be connected to a separate RHoK event Skype chat. If you would like to join, add Heatherleson with the note (RHoK-Ushahidi connect).
4. RHoK contacting: It might be best to not send an email. Rhok is so hectic and real-time. I’ll try to keep up with your requests, but best to ping us on Skype or via twitter @ushahidi. We may be setting up Google Hangouts as the hackathon proceeds.
5. Check out this Google Doc to track and connect: RHok with Ushahidi!

The Solutions to Discover:

I’ve scoured the daunting list of over 269 RHoK Problem Definitions to determine which hacks both pertain to Ushahidi and appear to be active. This list may change over the course of the weekend, but this is a running handbook. These hacks range from very specific map projects to technical kludges for offline/online, mobile or usability design. And, it is a truly global adventure.

Offline/Online Access

Often we are asked what the work-around to store offline data and send it to Ushahidi when services are connected and/or restored. The winning team from last June’s RhoK Toronto created Message Carrier. The team will not be continuing this hack for the December 2011 event. But, Francesco Ciriaci will be leading a hack in Trento, Italy for an Ushahidi offline/online app. Also, see their blog post on Reflab.

I’d like to suggest that the code from Message Carrier be reviewed. As well, there is another incomplete project for and the Data over Amateur radio (Ham Radio).

Hack for Your City, Your Community

Ushahidi Open311 GeoReport API Integration
City and community hackers: This problem coding has already started, but it would be good to see it continue. This is a co-hack for OpenPlans and Ushahidi. Fortunately, the Open Data Hackathon is happening simultaneously.

Or, Making your Cities: Street Safe (Rhok Atlanta)

Emergency, Preparedness and Simulation Hacks

The Security Alert App for Humanitarian Workers project owner, Angelique Mannella, will be leading this hack in RhoK Montreal. (I’ll be joining her team in person.)

Do you speak Spanish and want to help a Rhok Bogota (Colombia) simulation install? Contact Luis Luis Hernando Aguilar.

RHoK Zurich led by the wonderful Frank Werner-Krippendorf and Ivan Jovanovic will be brainstorming with the Caritas team about mapping hazards globally. This springs from conversations started at RhoK Berlin: Hack Caritas Germany mapping app using Ushahidi to test out the needs.

Pascal Schuback will be in Portland and tinkering with the original RHoK Seattle SAARAA: Situational Awareness and Rapid Assessment Application problem definition:

Water Hacks!

Mark Liffe and his Taarifa team won the London (UK) Water Hackathon in October 2011. This project may be continuing.

Melanie Gorka (RhoK Toronto), Steve Sauder (RhoK Montreal) and the RhoK Toronto team will continue to iterate on waterhacks.ca.

Also, see Map the Crap (This hack hasn’t started yet, but is similar to some of the other solutions).

Mobile Hacks?

Overflow app Android Based Huawei Project #1 or Project #2 (Tanzania)

Or you can mode the Check-ins capability in the ios/Andoid apps available from Ushahidi so that there is an option to send out a security check in that is then broadcast to a pre-set list of emergency contacts.

These hacks may be active as well:

Bushfire Connect was a hack first issued at Rhok 1.0 in Sydney. There is still work to be done. You can contact Keren and Maurits in Australia for more details.

Food distribution is a constant global concern, Moving Food was previously hacked on by Rhok Seattle and Silicon Valley.

Indonesia: one of the most disaster-prone countries in the world. You can hack on this NGO tool for Situational Awareness and Sharing Information.

If you have any updates to add to this list, please let us know. Also, take pictures, videos etc. and send them our way. We’d be glad to feature you and your teams’ efforts.

Happy Hacking!

CAUSE Resiliency (West Coast) Experiment 2011

The CAUSE Resiliency (West Coast) Experiment project 2011 was a collaboration between the governments of Canada and United States with operational emergency management communities in British Columbia and bordering states. The goal was to simulate an emergency response with the use and integration of some emerging technologies, including the Multi-Agency Situational Awareness System (MASAS), ESRI and Ushahidi. Simon Fraser University, under Dr. Peter Anderson’s guidance, trained students to use Ushahidi for citizen reports:

CAUSE Ushahidi Chapter – FINAL from Planetworks Consulting on Vimeo.

Citizens will use the many online communication channels (email, Twitter, Facebook, Youtube, Flickr, and more) and their mobile devices during an emergency. Examples like this demonstrate how official organizations can incorporate citizen reporting platforms like Ushahidi to plan, give voice and build partnerships with their communities. Emergency responders often say that citizens are the first responders and witnesses in their neighbourhoods. With training and planning, it is possible to have an installation of Ushahidi ready for emergencies and use the mobile applications. The mobile apps can be white-labelled and customized for your city or emergency response group. There is a huge opportunity to replicate this simulation model connecting official responders, universities and volunteers. All it takes is leadership, initiative and a plan.

The Canadian National MASAS Information eXchange (MASAS-X) supports operations, exercises and training. (www.MASAS-X.ca).

Thank you
Special thanks to Jack Pagotto (Head, ESEC [Emergency Mgmt Systems & Interoperability, Surveillance/Intel, E-security, Critical Infrastructure Protection] Centre for Security Science) for funding and making this video clip available, Doug Allport, Senior Advisor, MASAS National Implementation Teamand the MASAS team for building software that connects citizens and emergency responders, Dr. Peter Anderson (Director, Telematics Research Lab, SFU Faculty of Communication, Art and Technology) for his support of Ushahidi and for engaging students, Daniel Stevens (Vancouver EOC) for his introduction, and as well many thanks to the actors and other professionals involved.

The SciFi geeks may recognize the actor who volunteered some of the narration as Bruce Greenwood, of the Star Trek movie fame and a native Vancouverite. This video was provided by Paul Childs, Planetworks Consulting with the film by Black Dog Productions.

More clips may be available from the Centre of Security Science on request.