A clarification: all of the prices in the system are user-generated via the same SMS interface. So the SMS syntax that needs to be developed should also cater for submitting prices. As with any user-submitted data, issues of quality-control, authentication, trust etc etc also come up. For instance, the system should not give the same amount of "trust" to prices from someone who has a record of giving the wrong info as it would to someone who has a pretty good track record. Perhaps this area needs its own thread? Anyone feeling "sufficiently philanthropic?" Saidi On Thu, Aug 5, 2010 at 6:32 PM, saidimu apale <saidimu@gmail.com> wrote:
As we discuss the housekeeping rules (in a separate thread), let's also discuss the actual project scope on this thread.
Very few project ideas survive in their original form, most go thro' an iterative refinement. The strength of an idea isn't in its immutability ("unchangeable-ness"), but rather in its ability to act as a good seed for the n-th generation ideas that actually get implemented.
From some of the responses to my earlier proposal for this project (originally an idea from my brother), quite a few other people had similar ideas. Let's decide which aspects of the various projects get implemented, why they should be implemented, and in what version(s).
I'll start by outlining my ideas and reasons; please add your ideas and let's come to a rough consensus fairly quickly. Feel free as well to constructively critique other people's ideas. This stage should act as a filter to isolate unworkable ideas, or ideas that really should be a separate project altogether.
Ok, here we go:
- find out the cheapest petrol prices closest to you
- report/update the prices of a petrol station
- to simplify the project: - restrict the petrol stations only to Nairobi (for version 1) - the only interface will be SMS (subsequent versions may include other interfaces: web, mobile apps, etc etc) - pros: no one needs a smartphone, or data plan for this. Most ppl are already comfortable with SMSes. - cons: a lot of really snazzy, graphical features need a browser (or a capable smart/phone). But subsequent versions can include more advanced interfaces for phones that can support it. - use twitter's already-existing interface to receive and send SMSes. - pros: free, many good libraries exist, easy to quickly get started - cons: how many ppl in Nairobi use, or know about, twitter? How easy is it to quickly get a user sending/receiving messages on twitter via their phone?
- to include as many people as possible: - use SMS as the main interface - allow a very fluid submission/query syntax (e.g. allow SMS-isms, abbreviations, incorrect street names etc etc
There is a tension between making life simpler for the end-users (e.g. a forgiving language parser) and making life harder for the developers. It is easier, from a programming perspective, to only allow strict grammar in the SMSes sent, but that will likely make the application unusable for most people (imagine trying to query/submit petrol prices while driving, in perfect grammar!).
Whenever possible, I tend to prefer transferring complexity away from the end-user and towards the programmer. These are some of the trade-offs we will have to decide on.
Over to the community for a constructive back-and-forth...
Saidi