I was invited by Lirneasia to a presentation on Sahana’s new SMS module yesterday. Lara’s live blogging of the event is available here. The module works well and looks nice and is particularly well suited for sending early warning messages to the disaster response network of Sarvodaya around Sri Lanka (there’s an acronym for this that I can’t remember). Scalability of the module to deal with a larger constituency (thousands of journalists and millions of citizens) is very suspect, but that’s not what it was designed for. As was explained to us, it’s also a problem of the sequential nature of sending SMSs out from the system.
But as was noted, no tests to date have been made on the actual performance of the system that for the moment runs on Dialog. My experience with SMS communications last year after a bombing close to home suggests that SMS is also prone to congestion that can last for hours, though a technical agreement with Dialog may possibly address this by prioritising message delivery for a specific set of numbers.
Cost was whatever the cost of sending an SMS within or through the Dialog network. It was clear that setting up this module needed to be done in consultation with (or at the very least, adequate notification given to) the mobile telecoms provider it used for message delivery. Else, as was pointed out, warning messages to hundreds could easily be shut down by automated SMS spam guards, which would defeat the purpose of the system.
One suggestion I had was to simplify their three character survey response code. My suggestion was to limit the characters to the first key press of a mobile keypad (a,d, g, j, m, p, t, w and *, 0 # if necessary) since multiple key presses to get to the other letters could lead to, particularly when also dealing with a chaotic context, high levels of stress and possibly sleep depravation, higher levels of error in input.
The suggestion was also made to made the UI a bit more like Twitter, with notification of how many characters had been used in a message and how many there were left.
It would also be necessary for Sahana to encourage the best practice of the most urgent numbers at the top of any group list, given the sequential nature of SMS delivery, ensuring that they got the message first. It would be useful then to also encourage the creation of groups based on geo-location – so that say in the case of a tsunami alert, disaster responders along the coastal belt most likely to be affected could be alerted as first and then others. Extrapolating key numbers from a group that contained a whole bunch of numbers at the time of sending the message out would be next to impossible.
It would be interesting to see if the Government Information Dept. or National Disaster Management Centre takes this up as a means of communicating disaster early warning and subsequent information to journalists and other key actors. A key conversation in this regard was facilitated by an article of Chamath Ariyadasa from JNW news on Groundviews, well worth reading even today.
One feature I would like to see in the Sahana SMS module is an automated keyword response mechanism, akin to what FrontlineSMS already has. For example, someone in the field types “emc colombo” which could be a short-code understood by the system as a request for emergency contacts for that particular location / district / GN division. Those managing the module would be responsible for updating responses with current information. So in this example, “emc colombo” could result in as SMS like “N.D. Hettiarachchi, email@example.com, +94112431590 T, +94112431593 F”.
It would be interesting if the system actually logged the delivery time of messages to the extent made possible by delivery receipts with Dialog and Mobitel (maybe with Tigo too). It would be interesting to get a a baseline on a normal day (a dry run of the system with Sarvodaya’s network) and another during an actual disaster warning / early response context to compare how the system deals with stress placed on it and on the larger mobile network.
I wonder if Sahana can and will provide this module as a web service delinked from the larger Sahana system? I can see far broader applications for this than disaster early warning and a web services approach or at worst a thin client approach would allow it to be used by those who don’t necessarily want or need the full blown Sahana system.