Design Tradeoffs
Monday, November 17th, 2008As our project time enters its last month, we have started taking the abstract ideas from our design sessions and information generated from speaking with our partner organizations to begin an actual implementation that we will be presenting at the end of the semester.
My current work on our software implementation is the development of a client-side J2ME application to be run on cell phones for Catholic Relief Services (CRS). The primary purpose of the application is to allow CRS field agents to populate a 50-question survey that provides basic information about a disaster when it hits a given region and then send that information instantaneously to a server, which will log it and allow CRS to allocate resources accordingly.
NextLab had previously worked with CRS last semester (when it was called ICT4D), and a group had written a J2ME application already that handled some of our task. This is where some of the basic design trade offs in our application would come into play.
The application developed last semester does a really nice job of allowing flexibility in the forms that can be used in the application (forms are written in XML, opened by the application, and then answers are parsed into a string that is sent via SMS to a server, which populates a database entry based on the received SMS).
One problem with this design is that for the survey we are using, which has 50 questions (some of which have many parts and data fields), there is almost no way that all the answers will fit in the space of a 160-character SMS message. This poses a financial sustainability problem, since we will require many SMS messages to send a single survey’s answers.
A possible solution to this (which I am implementing this week) is using compression at the binary level (i.e. for a yes/no question, I only need 1 bit to represent the answer, for selecting 1 of 8 = 2^3 choices I need 3 bits, etc.). While this will almost surely allow us to compress the 50 answers into 1 SMS message, significantly saving costs.
However, the tradeoff here is that both client and server side will need to create compression that is specific to the form, which will require significant editing of the source on both the client and server side, which is not optimal from an operational sustainability perspective.
Over this week we will be making a lot of decisions regarding this trade-off, and one of the big questions will be discovering what matters more, costs of SMS or the flexibility to change the form? If the form has been the same and will be for the next 10 years, then hard-coding compression will make much more sense. If it changes every month, then we need a more flexible model.
In the end, I would like to implement some hybrid compression model that perhaps uses some metadata in the XML form that customizes compression. For the moment though, the priority will be to create a functional system that solves CRS’s problems and is as efficient as possible depending on their priorities.
More info on solving these problems to come soon!
