• The US is clueless in response to the Wikileaks release of war documents
• The music and film industries continue to lose to the open web
• South Africa seeks to muzzle the press
• The UAE takes on RIM over the ability to read everyone’s email
• In Australia you can’t link to certain sites from your personal website
• More and more countries require SIM card registration on phones to track users

…it goes on.

This isn’t a conspiracy, it’s a reaction by those in the status quo (be they government, big business or large established organizations) to the inefficiencies that they represent in the system being overcome by changes in technology and culture. As the open web expands it becomes a real threat to controlling governments, even to the relevance of the nation state itself.

The Case of the Russian Fires

Blogging and social media have been utilized for transparency and accountability for a number of years. While that’s interesting in its own right, I find the translation of those online tools into offline activities far more compelling.

The Russian forest fires is a particularly interesting one, as it represents what appears to be a major shift in ownership and attitudes in Russia around governance and responsibility. At the same time, one of the main tools used to organize it was the Ushahidi platform (giving me that little bit of liberty to write some thoughts on the bigger picture).

“On the one hand, cooperation was empowered by a shared understanding that the government has failed to get the situation under control and, moreover, didn’t want to be held accountable for it. On the other hand, it was information technologies that provided both information exchange and tools for coordination and effective collaboration.”

Please, read the full Global Voices article on the Russian fires.

Final Thoughts

Personally, I don’t see too many governments being displaced or replaced by online cooperation alone. Trust, reputation and resources are just a few of the hurdles to overcome before that happens. Instead, I think we’re seeing the continuation of the refinement of mass movements, brought about by the inefficiencies in the system, which catch on faster and are enabled better online and then move offline for impact.

Hearing what works, what doesn’t, what is missing and what could be improved is essential to the ongoing development of Ushahidi. Feedback also plays an important role in building and growing a thriving community. Participating in this process is one way that those who have benefited from using Ushahidi can give back and help us build a better platform for future users. Feedback can include bug reports, technical difficulties, and feature requests as well as strategic insights and practical considerations.

A sample of feedback we have received includes requests for: language localization; customized themes; better configuration of email, SMS, and RSS alerts; improved alerts functionality such as the ability to subscribe to alerts for more than one location at a time or for a specific category; enhanced reporting tools to produce reports, graphs, bar charts…and more. You can see how these suggestions were incorporated into the roadmap for the Mogadishu release by visiting our wiki.

We also launched our community resources page in response to feedback from non-technical users.

We glean feedback from a variety of sources: we encourage our users to exchange information on our forums, welcome guest posts to our blog and appreciate when people who have deployed Ushahidi take time to complete our online surveys. In fact, we are currently revising our install survey and our post-implementation survey. Please feel free to let us know what you think of the questions. Do they make sense? Anything else we should ask?

Also, as part of our ongoing efforts to improve our capacity for gathering feedback, we are currently seeking volunteers to join our team. We are particularly looking for bilingual (English + local language) volunteers from Central and South America, Europe and Asia. If you are interested in learning more about how Ushahidi is used in the field, becoming a feedback volunteer will give you the opportunity to engage and interact with deployers who are actively using the platform. It’s also a great way for people without technical skills to contribute to shaping and improving the platform. If it sounds like something you might enjoy, please contact me via email to sarah [at] ushahidi [dot] com.

During a crisis situation, groups looking to use Ushahidi often need additional support beyond the software itself e.g. paying for hosting, supporting volunteers, SMS costs, etc. To this end, we’re engaging with GlobalGiving to help fund such groups.

What is the Global Giving Open Challenge?

“The Challenge is for participants to generate donations for their projects between September 1, 2010 (0000 hrs, EDT) and September 30, 2010 (2359 hrs, EDT).

Any project that is able to meet the challenge threshold of raising $4,000 from at least 50 separate donors will be invited to stay on at GlobalGiving. These projects will be eligible to continue receiving donations from the general public, private and corporate foundations through GlobalGiving and take advantage of GlobalGiving’s fundraising tools and services. “

Why the Ushahidi Rapid Response Fund is needed

Ushahidi needs a rapid response fund for deployments in response to major crises. The ability of groups (often volunteers) to respond quickly is considerably slowed as a result . While the technology itself is free, funds are needed for the non-tech side for instance, to do media outreach, to disseminate information by SMS, to set up a free short-code, to pay for a hosted server, and provide a space and some food for volunteers to work.

Examples abound for this type of work, including most recently the work by volunteer groups in Pakistan with the floods, the Mozambique riots and in Russia with the fires. Many times these groups don’t need very much money, it’s free software and volunteers who run it. That doesn’t mean that there aren’t costs that slow their response down though, and our goal is to overcome that challenge.

In a hot-flash crisis, every minute counts. We appreciate your assistance with this fund.

You can also help by spreading the word to people you know who can help (buttons are found here).

LISGIS is the Liberia Institute of Statistics and Geo-Information Services, and it is notorious for keeping its data on a short leash.  John (our team’s tech support manager extraordinaire) tried getting in touch with the Institute: a personal visit, an official letter – all to no avail.  Meanwhile the UN Mission in Liberia, the Norwegian Refugee Council and others were waiting to use Ushahidi – but without county and district boundaries displayed on Ushahidi’s maps, there was little our team could offer.

What was in fact the most challenging aspect of this data-chase was that we already had the LISGIS data; through one of his contacts at an NGO, John was able to view purchased LISGIS shapefiles in all their glory – one map after another of detailed boundary lines and villages with populations as few as five.  But these shapefiles were licensed to one particular organization for internal use, and therefore just out of reach (picture John and I at our desks, grinding teeth and biting nails).

During a meeting with the Ministry of Internal Affairs’ Peacebuilding Office, we mentioned this data deadlock; the Director of the Peacebuilding Office (PBO), one of the most connected men in Monrovia, casually offered to accompany us on our next trip to LISGIS.  The head of the Institute, he said, was a personal friend.  And here the tides began to turn.  In one visit, the PBO’s Director arranged a verbal agreement with LISGIS to release county and district boundaries, cities and villages, plus main and arterial roads for Google’s use; all that remained was for John and myself to get it down on paper.  And Google?  Our contacts at HQ were more than happy to post the census data on their maps as soon as we sent them signed permission.   I will abbreviate the course of events that followed, however I would be doing you an injustice if I did not at least summarize the run-around that ensued – it is, after all, an integral part of data collection in Liberia:

• Personally delivered document on PBO letterhead to LISGIS for the Director’s signature
• Hastily walked out of the office with signed permission in-hand.  Wait – he put the wrong date
• Back to the office.  Director crossed out the date, initialed, corrected it. Quickly again out the door to scan the document off to Google.  Done!
• Not quite.  Google writes: the document is not on LISGIS letterhead, and the Director’s listed email is a Yahoo address rather than an official LISGIS address (Liberians do have a fondness for elaborate Yahoo addresses)
• John inquires about the official email address: LISGIS does not have one.  Fine, Google understands, how about just a signature on letterhead, minus the Yahoo?
• Got it.  Back to LISGIS.  Up the stairs, into the office – the entire staff is on retreat.  For the week.  In a faraway town
• The next week: up the stairs, into LISGIS, yes hello again I know I’m truly trying my luck but my bossman says I have to get this on your letterhead.  Okay, said the secretary – but not on that thing (I’ve brought a USB stick with the original document).  I don’t ask why – sure, would you like to retrieve the document from my email?  They would rather rewrite the entire document based on a hard copy.  I offered to type it – no, no problem we can do it
• I waited in the lobby.  The secretary brought me a copy – there are some typos.  She tries again.  Another copy – a few remaining mistakes.  Once more.  An hour later, a pristine rewrite.  She went for the signature – can we get two copies, I asked?  I’m bit my lip, I had pushed too far, there was no way we could get away with this now.  I waited some more
• Secretary emerged, signed documents in hand.  On letterhead.  I bolted out of the door, scanned, copied, FedExed to Google, nearly framed the copies and built a mantle on which to admire them within the same hour.  Really. Done.

And it was worth it.  Below are samples from our friends at Google demonstrating how these added shapefiles will improve public maps of Liberia.  Within the next few weeks, this data will be available in the public domain.  As they say in Liberia for progress, one step at a time – “we’re trying small.”

Before and After: County and District Boundaries

Before and After: Main and Arterial Roads

Before and After: Cities and Villages

If you would like to see the shapefiles for yourself, check out this link on John’s site: http://johnetherton.com/file-share/Liberia/Census-Data/2008/

School children being told to chant candidates’ names by their teachers. Civil servants getting sacked for not campaigning for their political bosses. Zinc roofing being traded for votes. The public wholesaling of voters’ personal data to campaigners. Death threats to those who denounce electoral crimes.

Welcome to the unpleasant side of Brazilian electioneering.

These are just some of the reports coming from Eleitor 2010, a “crowdsourcing” project aiming to facilitate citizen reports of abuses of the electoral process in Brazil.

In the largest democracy in Latin America – with over 120 million voters – this year, voters go to the polls they will be choosing the successor of one of the country’s most popular Presidents in history (Luiz Inácio “Lula” da Silva) but also voting on governors, a large portion of Congress.

Every country has its own unique political culture and oddities. Even the most minimal democracy has its own rules around electioneering, the mechanics of the vote, and ensuring that the state regulates the electoral process.

Brazil was one of the first democracies of its size to use electronic voting machines. It also has compulsory voting. But other aspects of its electoral process are unique, including attempts to strictly regulate of online campaigning, vote buying and what are called “showmícios” (concert-rallies).

Brazil has very clear and comprehensive laws regulating elections but the problem is enforcing these laws.

There is a real culture of politicians subverting the law, maintaining a privileged position as patrons of voters in Brazil. This stems from a distant colonial past and continued persistent inequality, where entrenched elite interests have maintained themselves.

The idea behind Eleitor 2010, which is a purely volunteer, non-partisan project run by a virtual team with zero funding, is to engage the voter beyond the day of the election. According to Paula Góes and Diego Casaes, its creators – who met via Twitter and now collaborate on Global Voices Online, the project is to promote critical and active citizenship, that challenges some of the arcane and undemocratic practices mentioned above.

Eleitor 2010 runs on the open source software Ushahidi, a web-based platform which received much attention for its utility in mapping incidents after the Haiti earthquake, driven by SMS reports from the ground.

Ushahidi has yet to reach its full potential as an election monitoring platform, say Góes and Casaes. With an estimated 25% of the country online every day, and one of the highest mobile subscriber rates in Latin America, they hope Brazil could be the place where it comes of age this year. Four weeks away from the election, Eleitor 2010 already has 230+ reports, from every state in the country, and from the most remote areas.

However, it is an uphill battle to get the message out about the platform, in a country where broadcast and print media are still strong, held in the hands of a privileged elite bent on defending its interests.

Despite this, the communications team at Eleitor 2010 has generated some media attention, and networking with other online transparency initiatives has been crucial. Google recently featured Eleitor 2010 on its page dedicated to the Brazilian elections.

Góes and Casaes hope that with their awareness campaign – on social networks including Orkut with over 40 million users, partnerships with networks of internet cafés, NGOs, and social movements – Eleitor 2010 will break through and change the way thousands of voters engage in the electoral process.

Through the plaftorm, some entertaining anecdotes have already come to light, well in advance of the October 3 vote.

Voters caught one man in a small town in the interior selling off Twitter accounts with 40,000+ followers for the sickeningly low price of US$125. This is illegal under Brazilian electoral law. When confronted, the man in question gave more incriminating evidence and then threatened to sue Eleitor 2010. The evidence, including screenshots and transcript of a chat with him, were delivered to the Electoral Courts.

Another comic report from São Paulo, where teachers at a school illegally encouraged children to chant for two candidates, one for mayor and one for President, and it backfired with children instinctively chanting “Lula!” “Lula!” The video circulated widely, and has had over 70,000 views.

Another video that raised eyebrows was one by blogger Ricardo Gama of a VW bus owned by the City Hall being used for a campaign in Rio de Janeiro. The blogger shouts “Are you carrying electoral propaganda in the car of the City Hall? This is an electoral crime! I filmed it. I am going to denounce you.”

From the north of Brazil, in the state of Maranhão, word reached Eleitor 2010 that a network of evangelical churches was offering to “trade” 3,000 votes for “support” after the election. In the state of São Paulo, one Bishop implored the faithful not to support President Lula’s chosen successor, Dilma Roussef.

These examples indicate how this platform and online, participatory tools will be of use in years to come. No matter whether it goes “viral” and becomes a household name, Eleitor 2010 and other transparency initiatives have already become game-changers this election year.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pics from the meetup are up on this flickr set.

SwiftRiver | Sweeper

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

A Bit About the Technology

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

Sweeper App

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

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

SwiftWebServices (SWS)

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

Download v.0.5.0

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

Solar Flashlight & Kazoo created by the students

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

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

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

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

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

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

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

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

Future Now Ushahidi Map

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

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

It’s a simple as this:

Today FrontlineSMS is adding MMS to their repertoire!

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

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

Taking the maps offline through FrontlineSMS

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

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

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

Download FrontlineSMS v1.6.16 here.