With the much appreciated help of crowd-sorcerer Henry Addo, we have upgraded Voice of Kibera to Ushahidi 2.0, and the plugin system.
![crowd-sorcerer](http://irevolution.files.wordpress.com/2010/08/crowdsorcerers.jpg?w=460&h=343"){kind=link}
The first plugin we installed immediately was the mobile plugin, which sure, gave us iphone and ipad support but what really excited us was support for any phone, really any phone, with any kind of internet access, via a web browser. In Kenya, mobile internet is booming and it is not uncommon for Kibera people to have internet enabled phones, mostly accessing Facebook. The cheapest internet enabled phone on the market is only 2000 KSH ($25). Phones and data are only going to get cheaper. For many people, the phone will be the first real chance to access the internet, and I reckon WAP is going to really take off. 10 years ago in the EU, WAP was over-hyped and crashed because people were used to a full internet experience, and didn’t really get interested in mobile internet until the iPhone. Here in Kenya, WAP is the right technology, right now. I’m incredibly excited to see what happens now that Voice of Kibera is available on the phone.
An Alert on Alerts
With 2.0 finally out of the way, I had a chance to examine our bugs and features against what’s in 2.0. One long standing issue for VoK, and I’m told other instances, were that Alerts didn’t work correctly. Sometimes they didn’t get sent out at all, or got sent out in huge numbers, almost spamming subscribers (this happened with Uchaguzi, I’m told). I had never investigated or confirmed this, but after a quick test yesterday with VoK, yes, alerts weren’t working!
I examined the code and the database, and discovered the problem. Reports are marked for alerting when approved via “admin/reports/index”, but not via “admin/reports/edit”. This means that if someone marks a report as approved while applying or reviewing location and category, it’s never sent out for alerting. At least with Voice of Kibera, this is the common usage pattern, and I suspect the majority of instances … the same person who creates and geocodes the report, approves it. The approver is often going to check out the map, rather than just read a summary. It’s only in specific circumstances that index would be used on Ushahidi instances, and I can’t say how often that the report listing would be used. This inconsistency made it a troublesome bug to figure out.
Anyhow, I submitted a bug on this, and David Kobia quickly submitted this fix. I was a little concerned that such a core feature had a major bug, but very glad that Ushahidi quickly responded to my report.
If you’ve noticed any problem with Alerts in your Ushahidi instance, I suggest at least applying David’s fix, if not upgrading to the latest codebase completely.
SMS Wishlist
Along with WAP, we see SMS Alerts as a major way Voice of Kibera will be accessible in Kibera. We’ve examined how things work, and have come up with a number of improvements.
- Should be able to sign up for Alerts to specific category, rather than everything. I believe the Haiti instance had this, but that hasn’t been integrating to 2.0
- Should be able to sign up for alerts via SMS. For example, someone interested in sporting events could text in “Kibera subscribe sports” and be signed up. That will text them back information on how to unsubscribe via SMS, etc.
- Admins should be able to toggle whether a specific message is sent out for alerts. Looking at the code around the bug above, I see this would be straightforward.
- Admins should be able to mark a report for sending only via SMS, and not on the site. These could be special communications, or take the form of a daily/weekly digest of information.
- Finally, it would be helpful to assign a name to SMS reporters and subscribers. Reports should be linked to messages that come in via SMS, so that you can see the original message and reporter when approving.
Geo and Other Stuff
Naturally being a mapping guy, I have lots of ideas! One thing that happened in Uchaguzi, and in Haiti and Chile, was a choice of base map layers, so that both OpenStreetMap and Goog were available. These were done by hacking in a little OpenLayers javascript. It would actually be pretty simple to offer a choice of several base map layers in core Ushahidi. Also helpful would be a little design work to make base map choice more obvious.
That could lead to more custom base map layers. During Uchaguzi, there was an unfulfilled need to overlay polling place districts on the map. Since that’s a fairly large KML, a more efficient method on the browser side would be to build up semi-transparent tiles.
Another place to look is geocoding. Currently only Google geocoding is offered, while there are other good, and free, services like Nominatim (based on OSM data) and Geonames. Which geocoder is in use should be somewhat invisible to the reporting interface, and done in an efficient cascade. Also, need to present choices of results to user, rather than just the first.
There may be circumstances where you want to build your own custom geocoder. Again, Uchaguzi could have benefited from geocoding on polling place locations; that database was available, but not with a license shareable with OpenStreetMap (it’s a looong story). What could be done is build up a geocoder using the open source geocommons geocoder, and integrate it with Ushahidi via its RESTful interface.
Anyhow, just a few ideas, which we’ll be processing into specific bug reports and feature requests, and yes, finding time to work on … it’s open source after all!
Great catch – our alerts were also not working. Like the other useful suggestions as well!
Great catch – our alerts were also not working. I like the other useful suggestions as well!
Hi,
How is the basemap issue coming along? Have you managed to hack the javscript to get custom basemaps into Ushahidi?
cheers,
Rob