Monday, November 2, 2009

Late night with Otto and Lian

At the moment I am trying to spec out some next steps for rapidsms. I am focusing on a rapidSMS turn key solution - a one step process to install rapidsms (a sms gateway and web interface). What exactly should be installed by this one step process?

I keep using the dreaded W term - wizard. There are lots of wizard haters out there. To you wizard haters - please email me or leave comments - I have forgotten all the anti-wizard arguments.

Why a wizard??? With a wizard a non-programmers can customize a piece of software. I am thinking that perhaps we need a rapidSMS wizard for a rapidSMS easy install. That way users can specify what functionality they would like their rapidSMS deployment to have. The next question is, what in RapidSMS should be available for customization?

Some of the things I think that we need to work out is a way to specify SMS request and response. What messages map to what responses and is there a response flow. This is similar to the web application flow of many early app servers - like apache cocoon. Do people still use this? In the end, RapidSMS should have different modules that you can install for different purposes, an eHealth module, eCrisis, eBusiness... etc. I suppose FrontlineSMS does this with Frontline::Medic. I am not sure how intervention free we can make these modules, but ideally most of the business logic will be developed by engaging in field projects like the Malawi project this summer.

It would be nice to have a forms editor in rapidSMS so you can edit your SMS flow AND then it would be nice to have a HTML flow editor. Does this exist? Is there a GUI where you can edit the flow of your web application. I know this exists for mashups.

Ok now thinking about GUI editors. After the wizard process, where you specify what functionality you want, then you should get a list of sms keywords you need to implement. This means that we need to probably standardize the keyword functionality in rapidSMS. This can probably be implemented via the excellent keyword class that Adam (or Evan) wrote.
With your list of sms keywords you create a sort of flow chart or something similar to patch based programs like max/msp. You link the keywords with certain responses.

Finally, there should be a simple way to set up web reports, and email alerts....

Oooph - I just ran out of steam. I am really shot. I was at Kung Fu for about 4 hours and I cant turn my neck. Tomorrow I will blog more if I can turn my neck again.

My final thought - rapidsms apps need to have annotation to specify what parameters will be defined by wizards. I think this is the first time I have ever found a use for annotation in programming.

No comments:

Post a Comment