Working primarily on setting up the server that Louis can use. I got a hold of it, set it up, and have started installing Ubuntu server; I chose that mainly because of the support that it has compared to other linux distros. Of course, it's also open source, free, and reputedly easy to use. I do wonder if it might be overkill for the limited intranet it will be used for (for example, it does not come by default with a GUI making it less friendly for less advanced users; I will be installing a GUI anyway), and I may change to regular Ubuntu instead.
Currently waiting on the router which I need to test the intranet. Louis sent out an email to one of the teachers; waiting for her to reply still.
Saturday, August 6, 2011
Monday, July 25, 2011
Update 7/25
Just an update on where I am right now. Going to meet with Professor Eglash tomorrow presumably to discuss the direction we'll be taking the clicker project, whether we're going forward with it or not, and the condom machine idea.
Essentially with the condom machine there is an idea of providing easy, anonymous access to condoms by placing vending machine-type dispensers in various locations (if I understand correctly). The problem then becomes:
Essentially with the condom machine there is an idea of providing easy, anonymous access to condoms by placing vending machine-type dispensers in various locations (if I understand correctly). The problem then becomes:
- How can we create and distribute these machines cheaply?
- How do we make sure they're refilled / create a notification system when empty?
- How can we provide information about locations easily so people can easily and anonymously access this information?
It seems to me that we can use something similar to what we designed with the program I created already, but this project would require an adaptation of it and cheap hardware design. For example, an arduino board that could send GSM messages:
That would have the disadvantage of requiring a SIM card for each unit, with a working cell phone service account. Each cellular shield alone is $100; that added to the price of monthly cell phone service might be cost prohibitive. Perhaps a simple passive notification system would work (instead of each unit sending a message out to someone when it's empty, someone manually goes around and checks each unit).
Saturday, July 16, 2011
Update 7/16
The past week or two I have mostly spent on a conference paper, which is now completed and submitted. I spent time researching the options for cheap clickers (see previous post), and the tradeoff is simple: either we make our own and have very basic, non-robust clickers, or we invest in something with a smart operating system that we can expand on later. I assume we'll be meeting to discuss this later. If we do decide to go with a software solution I will be able to put something together, however if we go with a solution that requires custom electronics construction I may be a bit out of my element.
The rest of my time was spent with minor repairs. I've started basic documentation on the code for the ghana sms program so that the project can be continued later and modified if need be. I worked with David while they were in Ghana to fix some bugs, which was particularly difficult because of the spotty / slow internet access they had there. Eventually he was able to take the laptop down to the hotel lobby where they were staying, and I remotely connected long enough to figure out the problem. Later I completed the fixes.
Not sure what the next step is at this point, as for now I'm spending my time just researching, and cleaning up with documentation.
The rest of my time was spent with minor repairs. I've started basic documentation on the code for the ghana sms program so that the project can be continued later and modified if need be. I worked with David while they were in Ghana to fix some bugs, which was particularly difficult because of the spotty / slow internet access they had there. Eventually he was able to take the laptop down to the hotel lobby where they were staying, and I remotely connected long enough to figure out the problem. Later I completed the fixes.
Not sure what the next step is at this point, as for now I'm spending my time just researching, and cleaning up with documentation.
Wednesday, July 6, 2011
Student Clicker Research
I've been looking up information relevant to the discussion I had a week or two ago with Jim, Shannon, and Liz regarding, among other things, a low-cost clicker system that, if I understood correctly, would allow for:
- Students to answer questions in class individually
- Teachers to come up with and ask questions "on-the-spot"
- Detailed reports of individual student progress, and summaries of the entire class accessible to teachers
- Individual student feedback (so each student can see if they got a question right or wrong)
- Future expandability (in the case where android devices were used, the possibility of integrating camera and gps functionality)
The initial idea of android phones ended up being somewhat costly (estimated cost: $100-$150 for older phones with no contract). The following possibilities are compared primarily by cost, implementation difficulty, ease of use / learning curve, and life (how long the solution is expected to be useful). In each of these I'll be referring to the student unit/clicker, which is the device the individual student will have, and the central unit, which will be coordinating all the devices and is managed by the teacher.
Building a custom device
While potentially the cheapest solution, it may be the most difficult to implement. Arduino boards could be configured to send tcp/ip packets to a receiver that would then be connected to a computer, which would probably be about $20 (Edit: I forgot that we need a wifi shield, which would be an extra $100 per student. A cheap, but tacky, workaround is to wire everything up so each student's clicker is physically connected by a wire to the central unit), and the central unit would be about $100-$150.
The disadvantages to this are clear: it's more difficult to implement (requires electronics tinkering), less reliable (if it breaks we need someone who understands a lot about how it works to fix it, and there's no real tech support to call), and not expandable (since each student clicker will not have any software running on it, if we wanted to upgrade it to do anything else besides just answer questions it requires a hardware modification; essentially this would be a redesign).
Buying android devices for each student, installing a phone app
Consider the possibility that it is within the budget to buy a lower-end android device for each student. As mentioned earlier, it could be $100-$150 per student unit, though that would get us rather slow and perhaps unreliable devices. Also, working on the tiny screens of the phone may be somewhat difficult for the students.
Another option is to purchase lower-end android tablets, archos is perhaps the best of these. (I do remember working with some really cheap chinese tablets, which I don't recommend. One of them broke when I plugged in the charger, the hardware was that badly made. The other didn't have a back button, and we couldn't even get the OS to do what we needed since it didn't have a memory card.) This is more costly; $250-$300 per student, but because the tablets have larger screens and don't have any of the bloat associated with phones (it won't be trying to look for phone reception), if that's in the budget then it's a much better solution.
Android devices also have built-in GPS and cameras (although I'm not sure about the archos tablets). Since we only have to install apps on the phones, their expandability is practically unlimited: writing a new app is much easier than redesigning the hardware.
As for the central unit, we can either construct a hardware device that communicates with the tablets (which invokes the disadvantages of building custom devices), have the android device listen to and run a program (which wouldn't be ideal since the devices are usually kind of slow), or have a computer as the central device, and have it communicate with the tablets through bluetooth or tcp/ip. But if we are doing that anyway, we might as well go with the next option:
Using a phone-compatible web app
Another disadvantage to the previous option is that if we put the energy into developing a phone app for android, we run into compatibility issues. Will the app work on all versions of android? Can it be run on an iphone? What if one student's device breaks, is there an alternate way to access the program?
Using web apps seems to be a better solution. Every android device with wifi access can run a web app. So can almost any other iphone, or blackberry with a sufficient browser. Furthermore, so can laptops, netbooks, etc. The app only has to be developed for one platform, as opposed to making different versions for each operating system and version it could possibly run on. Updating is also easier, it only has to be done once.
The only problem I can see here is security: it is easier to manipulate such a system, so that one could log in from anywhere (so that the person answering the question isn't necessarily the student you think it is). I don't see this as being a big problem, however, we could come up with a login verification system; maybe every day before logging in they have to type in a password that is given only to people physically in the class, for example.
SMS
If all students have phones with contracts, we can design an sms (text message) system, where they could text the answers to a computer that would receive all of them and collect/report the data. Identify verification is easy, as we'll know from which phone numbers the texts are coming. And this is actually the cheapest solution, since the only hardware we need to purchase is the SMS modem, around $150-$250 (with the big assumption that all students have text message-capable phones AND service plans, and the central computer has the appropriate software installed).
Purchasing Pre-made
Of course, developing from scratch is not always the best idea, and there are some good options already out there:
...plus a bunch more, I'm sure.
Recommendation
All of the above in mind, I would recommend a combination of the preceding categories--buy android devices or tablets, and install web apps.
Sunday, June 26, 2011
Update 6/26 - Border questions
In my previous post I said that we would limit this first version to the Kumasi area. Problem is that I can't find any definite borders anywhere (some sites are giving me inconsistent gps measurements for where its exact borders are) and there seems to be a recent (within the last few months) movement to slightly expand Kumasi to create a "Greater Kumasi" Metropolitan area (1) (2).
Because of this I've decided to limit our search area to the borders:
latitude = 6.583333 - 6.766667 (degrees N)
longitude = 1.516667 - 1.7 (degrees W)
Using data from google earth, I've gathered the data for and manually entered 137 schools, colleges, universities, churches, hotels, lodges, and major locations like the airport and primary post office. The database's structure allows for multiple names to refer to the same location, so for example "X Primary School" may be referred to as "X School", "X Primary", and whatever other unambiguous pseudonyms that I could think of.
Of course, we end up with the problem that some locations may have names I don't know about, or spellings or whatever. Initially I'm expecting a lot of recognition failures, and the plan is to use these to learn over time. The data we collect in this regard will be quite valuable.
Because of this I've decided to limit our search area to the borders:
latitude = 6.583333 - 6.766667 (degrees N)
longitude = 1.516667 - 1.7 (degrees W)
Using data from google earth, I've gathered the data for and manually entered 137 schools, colleges, universities, churches, hotels, lodges, and major locations like the airport and primary post office. The database's structure allows for multiple names to refer to the same location, so for example "X Primary School" may be referred to as "X School", "X Primary", and whatever other unambiguous pseudonyms that I could think of.
Of course, we end up with the problem that some locations may have names I don't know about, or spellings or whatever. Initially I'm expecting a lot of recognition failures, and the plan is to use these to learn over time. The data we collect in this regard will be quite valuable.
Saturday, June 25, 2011
Update: 6/25
Top priority, as I mentioned, is getting the program as bug-free and stable as possible before the team leaves for Ghana. The first step was to finalize a flowchart, based on the discussions yesterday. The new version assumes that the user is in the Kumasi Metropolitan district.
Working on implementing those changes today, after which I will be probably spending the rest of the weekend creating a simple form and database on the website that will allow for submission of provider locations and landmarks (both of which will need to be subject to manual verification before being added to the primary database). After that is the backup system, the "follow-up system" (the part which asks for some brief quality check after the session is completed), the web system which will allow people who prefer not to text to go online instead and access information there, and to manually input some starting landmark data: hospitals, schools, churches, etc.
Monday, June 20, 2011
Update 6/20
Designed and implemented the database, now I'm testing it. Looks good so far. I'm writing the python script that will ultimately handle the flow I described in my last post, which is arguably the "meat" of the project. The hardest part to implement will be the matching of landmarks to valid locations -- I have no idea what kind of input we'll actually get from users. It's an open question in that respect, to my knowledge nobody has done something like this before. This all points to a lot of tweaking that will have to be done in the first few weeks after deployment. Because of this, I'm designing all of the relevant software to be easier for me to change remotely (I'm using logmein so I'll be able to access the computer from America, assuming that there is sufficient internet access).
That being said, the question of whether the landmark system will produce valid results or not is an interesting question; I think it will provide valuable research data. I'm realizing that the flowchart I described in the last post has too many possibilities for syntactic failure, which conflicts with an implicit design goal--to make it so first time users can, with absolutely minimal instruction, use it successfully and want to use it again. So I've made some changes that make it easier to use, with the trade off that it may require more overall text messages back and forth to complete each session. I'll post an updated graphic soon; right now my priority is getting the system running and as stable as possible before the 30th.
I also just realized that my previous post had the subject line "5/12" when it was supposed to be "6/12". I'll not edit it, it will stand forevermore as a monument to the dangers of not knowing what month it is.
That being said, the question of whether the landmark system will produce valid results or not is an interesting question; I think it will provide valuable research data. I'm realizing that the flowchart I described in the last post has too many possibilities for syntactic failure, which conflicts with an implicit design goal--to make it so first time users can, with absolutely minimal instruction, use it successfully and want to use it again. So I've made some changes that make it easier to use, with the trade off that it may require more overall text messages back and forth to complete each session. I'll post an updated graphic soon; right now my priority is getting the system running and as stable as possible before the 30th.
I also just realized that my previous post had the subject line "5/12" when it was supposed to be "6/12". I'll not edit it, it will stand forevermore as a monument to the dangers of not knowing what month it is.
Sunday, June 12, 2011
Update: 5/12
I set up FrontlineSMS on the mini Acer laptop, with a Huawei GSM modem and a T-Mobile SIM Card set up with a "pay as you go" plan with unlimited SMS (with very expensive per minute charges, luckily we won't be using that). After a bit of configuration (windows 7's stock installation sure requires a lot of updates!) I was able to get it to work, and was able to receive and auto-respond to SMS messages. I left it running in the office so that I could remotely log in while I was gone for the week (using logmein.com) but it shut down for some reason, when I return I'll have to try to figure out why; I'm blaming windows's aggressive auto-update and restart policy, which I thought I disabled.
Meanwhile, FrontlineSMS has a feature that allows for a local command to be executed--I currently have it starting a python script that adds the received text to a local mysql database. That works great!
Now that the framework is set up, the next thing I have to do is figure out what kind of database we need. We need to create a simple logging system first of all, something that records the information available: the text that was sent, the date/time, and the number sent from (probably the response given as well). Design of the database also requires that we figure out what we need to know about the provider locations and how we intend to access and provide the correct information.
It is here that the limitations to the system and our experimental approach comes in. The following things apply:
With these things in mind, I think the best thing to use is a system that gets their region, a district if they know it, and then any landmarks they can use to pinpoint their location. We will then use some sort of probability-based ranking system (something like google maps uses) to provide a list of locations. The following flow chart describes my current idea:
I'm going to try to start implementing it this week. The hard part will be trying to figure out what ranking algorithm to use, and the specifics of how to store the data.
Meanwhile, FrontlineSMS has a feature that allows for a local command to be executed--I currently have it starting a python script that adds the received text to a local mysql database. That works great!
Now that the framework is set up, the next thing I have to do is figure out what kind of database we need. We need to create a simple logging system first of all, something that records the information available: the text that was sent, the date/time, and the number sent from (probably the response given as well). Design of the database also requires that we figure out what we need to know about the provider locations and how we intend to access and provide the correct information.
It is here that the limitations to the system and our experimental approach comes in. The following things apply:
- Text messages are limited to 160 characters.
- Ghanains are likely to know their region, but not necessarily their districts.
- Ghanains may not know any more detailed information like street addresses, as a uniform addressing system doesn't seem to exist like it does in the US. They are likely to use references to landmarks: "nearby the Hospital", or "between the graveyard and the post office".
With these things in mind, I think the best thing to use is a system that gets their region, a district if they know it, and then any landmarks they can use to pinpoint their location. We will then use some sort of probability-based ranking system (something like google maps uses) to provide a list of locations. The following flow chart describes my current idea:
I'm going to try to start implementing it this week. The hard part will be trying to figure out what ranking algorithm to use, and the specifics of how to store the data.
Monday, May 30, 2011
Weekly report: 5/25 - 5/31
The goals for this week were to:
The cost to implement this would be considerably less: we just need the hardware, and need to pay for whatever monthly Ghanaian service provider charges there are.
Implementation
To get this to work, we first need a GSM modem. This can be a phone that allows sending and receiving of AT commands, or (more reliably) a dedicated modem. We need the intersection of devices which:
- Figure out if there was a "mid-way" solution between using a smart phone to receive/send all sms messages, and whatever industrial solutions American Idol and the like uses.
- Continue researching, corresponding with people to ensure that our solutions will work. Finding out what similar solutions are already out there.
- Get started on smart phone development: Symbian, Blackberry, etc.
- Research the plausibility of a facebook app
Most of my time was spent with the first part, and I've made a lot of progress in that area. Essentially I learned that in order to do what we want, the only options are to use a smartphone as we previously learned, to use a commercial SMS gateway, and to use a GSM modem connected to your computer. (Good link summarizing that is here.) The latter two options are described below:
SMS Gateway
This option was the more expensive one, closer to the "American Idol"-like solution. It involves basically having another company take care of the technical details. I contacted a bunch of companies offering these services:
twilio - doesn't deliver sms to destinations outside US / Canada
textghana.com - sent email, no response
smsjunction - they responded: "As of now don't have stable coverage for Ghana"
routomessaging - sent email, no response
ozeki.hu - They claim to be the largest provider of sms gateways. They have a great api guide. They responded to my email by recommending their product "Ozeki NG SMS Gateway".
They also have great guides on how to set up gsm modems:
http://www.ozekisms.com/index.php?owpn=101
http://www.ozekisms.com/index.php?ow_page_number=201
Ozeki is by far the best of these that I've found. However, even if we went with them we are still required to purchase the required hardware (a GSM modem, computer to run software, SIM card from compatible Ghanaian service provider, etc). Furthermore, their pricing is set up for extremely large traffic clients (the cheapest is for 5 messages / minute, for about $850 USD+any separate fees the Ghanaian service provider charges).
GSM Modem
Since we'd have to purchase the hardware anyway, the mid-range solution would be to either write our own software to communicate with the GSM modem, or find something free out there. There are some good resources I've found and studied for implementing our own solution:
receive and send from gsm using visual basic:
http://www.codeproject.com/KB/cs/SMS.aspx
tutorial about gsm:
http://www.developershome.com/sms/GSMModemIntro.asp
But I first tried to find something that already existed. Fortunately something like that exists and is highly acclaimed. Frontlinesms seems almost custom made for us, just check out their mission statement:
Their software is free, and has been used by tons of other groups in order to establish sms services in 3rd world countries. I found one person who is using frontlinesms in Ghana, and I contacted him to get experiences and to find out his success rate (no response yet). Finally, the frontlinesms website claims the following uses are implemented already in Ghana:A lack of communication can be a major barrier for grassroots non-governmental organisations (NGOs) working in developing countries. FrontlineSMS is the first text messaging system created exclusively with this problem in mind.By leveraging basic tools already available to most NGOs — computers and mobile phones — FrontlineSMS enables instantaneous two-way communication on a large scale. It’s easy to implement, simple to operate, and best of all, the software is free. You just pay for the messages you send in the normal way.
- Helping citizens monitor elections
- Fundraising for charity football matches
- Interaction with audiences in radio broadcasts
- Tracking students returning to secondary education using surveys
- Providing automated responses regarding drug authenticity
- Communication with microfinance clients about their loans
- Allowing people to report human rights violations or other incidents
- Empowering local communities to express and convey their opinions
The cost to implement this would be considerably less: we just need the hardware, and need to pay for whatever monthly Ghanaian service provider charges there are.
Implementation
To get this to work, we first need a GSM modem. This can be a phone that allows sending and receiving of AT commands, or (more reliably) a dedicated modem. We need the intersection of devices which:
- Work in Ghana
- According to this website, almost all Ghanaian service providers support GSM 900.
- I asked MTN Ghana, and they responded that to use their SIM cards, we need a phone that has "the frequency bandwidth of 1800/900".
- Work in America - this is for testing purposes. As long as we have an unlocked device (one that allows us to use sim cards from different service providers; I emphasize because popular modems such as the T-Mobile Jet are locked to T-Mobile), every known US service provider supports at least GSM 900.
- Work with a T-Mobile SIM card - this is again for testing purposes.
- Work with the software we decide to use
- FrontlineSMS has a list of devices that work / sometimes work / don't work. Note that all blackberry and windows mobile devices won't work.
- Ozeki also has a great list (their website really has a lot of useful information)
- Can handle a reasonable load (this rules out all old phones)
Several devices fit all of these requirements, namely the recommended modems at the top of the Ozeki list I linked. Only one of these, the "HUAWEI E220 3G WWAN HSDPA UTMS USB MODEM 7.2M", is USB (the others are serial) and so I placed an order for one, it should arrive in the next few days.
Until then I'm trying to get used to the frontlinesms software, and have started testing it using my own phone as a modem.
Other Stuff
Haven't gotten around to the facebook and smartphone app stuff yet. However my initial research with the smartphone apps do not bring optimism: the development environments for android, iphone, symbian, and blackberryOS are too different to easily create a unified solution. Learning, developing, and testing for all of them may be too implausible for this summer.
Monday, May 23, 2011
Weekly report: 5/18 - 5/24
This week was spent investigating the options for a system which would allow cell phone owners in Ghana to easily access information about condom providers in the area, and possibly set up a social networking system that would update, rate, and improve the quality of this information. Particularly in regards to the following questions:
- Does Ghana have a zip code or area code system? Are they too big to be useful? Comfortable walking distances for Americans is typically a quarter mile radius (5 minutes at a comfortable pace).
- How do we embed location information into a text message. Do emergency (911) services help in this regard?
- What are the service providers in Ghana? Could they be of help to this project? Would they be interested in using our final (open source) product?
- How much does the software and hardware for a phone tree cost?
The questions and the relevant research is as follows:
Does Ghana have a zip code or area code system?
Ghana is divided into ten regions (capitals)(area code):
Ashanti Region (Kumasi)(32)
Brong-Ahafo Region (Sunyani)(35)
Central Region (Cape Coast)(Central)(33)
Eastern Region (Koforidua)(34)
Greater Accra Region (Accra)(30)
Northern Region (Tamale)(37)
Upper East Region (Bolgatanga)(38)
Upper West Region (Wa)(39)
Volta Region (Ho)(36)
Western Region (Sekondi-Takoradi)(31)
These are further subdivided into 170 districts which are either municipal, metropolitan, or ordinary. These districts range widely in size, anywhere from being 730 km2 (about 17 miles across) to 17,317 km2 (about 80 miles across). Some of districts are further subdivided into councils, but I am having trouble finding a complete, up to date list of these councils (I wonder if this is because the councils are somewhat more informal).
There appears to be no zip code-like system in place (USPS website confirms this) other than the area codes which refer to the regions.
How do we embed location information into a text message. Do emergency (911) services help in this regard?
9-1-1 works in the following way (from Wikipedia):
"In 2000, the U.S. Federal Communications Commission (FCC) issued an order requiring wireless carriers to determine and transmit the location of callers who dial 9-1-1. The FCC set up a phased program: Phase I transmitted the location of the receiving antenna for 9-1-1 calls, while Phase II transmitted the location of the calling telephone. The order set up certain accuracy requirements and other technical details, and milestones for completing the implementation of wireless location services. Subsequent to the FCC's order, many wireless carriers requested waivers of the milestones, and the FCC granted many of them. By mid-2005, the process of Phase II implementation was generally underway, but limited by the complexity of the coordination required from wireless carriers, PSAPs, local telephone companies and other affected government agencies, and the limited funding available to local agencies which need to convert PSAP equipment to display location data (usually on computerized maps). Such rules do not apply in Canada.[27]FCC rules require that all new mobile phones will provide their latitude and longitude to emergency operators in the event of a 9-1-1 call. Carriers may choose whether to implement this via Global Positioning System (GPS) chips in each phone, or by means of triangulation between celltowers. Due to limitations in technology (of the mobile phone, cellular phone towers, and PSAP equipment), a mobile caller's geographical information may not always be available to the local PSAP. Technologies are currently under development to remedy this situation and improve performance.[28] Although there are now technological ways to obtain the geographical location of the caller, a 9-1-1 caller should try to be aware of the location of the incident about which he or she is calling."
That should answer question 3, as well. The final question, and the rest of what I've learned so far, can be summarized by the following options I've been researching for how to implement this system.
Option 1: SMS -> Script -> SMS
This option seemed the most straightforward: write some program that could run on a server somewhere, have people text their location to a numer, have the program read the messages, process the text, and then respond with the nearest locations. I found a really cool python script that allows sending AND receiving of texts (both of these use textmagic):
- http://code.activestate.com/recipes/576826-send-and-receive-sms-messages-using-textmagic/
- http://dadhacker.blogspot.com/2011/04/send-and-receive-sms-with-python.html
Option 2: SMS -> email -> SMS
According to this website, you can send SMS to email from almost any phone by just typing in the email address. This worked with my phone.
Advantages
- Somewhat easy to implement
- Cheap -- all we need is a server running constantly (from anywhere, can even be located in the US) that checks emails, parses them and responds.
Disadvantages
- Do not know if it works with non-smart phones (need to test)
- Need to know if it works with Ghanaian service providers. It worked with mine, but I am using a smart phone (running Android) and T-Mobile as my service provider.
- My phone (with T-Mobile) added a bunch of extra information with the text -- the t-mobile logo, header info, etc. This will be difficult to parse through, since each service provider might include different information, and these formats might change over time.
- The idea of texting to an email address might be confusing to non-technical people (even I never knew it was possible before today).
Option 3: SMS -> Smart Phone -> SMS
Another option is to have an android device (or other smart phone) intercept text messages. The idea is that the smart phone would always be running a process which would be listening for incoming messages. Since the phone would have a phone number, it would receive texts, process them, and either send back a text on its own, or pass the message to a faster device (a computer) which would do the processing and reply with an SMS.
I contacted a T-Mobile representative about this option, to find out how we would set up a US-based smart phone to receive and send texts to Ghanaian numbers without incurring additional costs:
_Gregory C: John, you have several options for what you want._Gregory C: If you want a Ghanaian number, you will need to start service or obtain a sim card from Ghana. If you want a T-Mobile device to be unlocked for you, you can purchase any T-Mobile device at full retail price from a T-Mobile store.John Licato: can any t-mobile device be unlocked?_Gregory C: Yes they can. It is a short process in which we will submit a request to the manufacturer and an email with a code and instructions will be emailed to you, so you can recieve it anywhere in the world.John Licato: I see, and then any monthly rates or fees I'd have to pay would be to whatever Ghanaian service provider I choose?_Gregory C: That is correct.John Licato: I don't know if you'd know this, but do you know if those international service providers would charge any additional roaming fees for receiving and sending texts since the phone would be in the US?_Gregory C: Many providers around the world offer prepaid sim cards for a set price that allow international texts and calls.
I also contacted some Ghanaian service providers regarding this question and to see if they had any plans/rates that would work best for us. Still waiting for a response.
EDIT: Two Ghanaian service providers seem to imply that this is not true and that international fees will still be incurred, I am corresponding with them to confirm this.
Advantages
EDIT: Two Ghanaian service providers seem to imply that this is not true and that international fees will still be incurred, I am corresponding with them to confirm this.
Advantages
- Also relatively easy to set up (note that for options 2 and 3 I say they're easy, these are relative terms compared to option 1 and 4) since I already have experience programming Android applications.
- Easy to use -- the user simply has to text the phone number attached to our listening device.
- The "extra information" problem with option 2 would (presumably) be eliminated, since only SMS data would be transmitted.
Disadvantages
- Cost -- we have to not only buy a smart phone (one time fee), but we have to pay the monthly service charges to a Ghanaian service provider.
- The device receiving the incoming messages would have to be relatively fast to handle all of the traffic. We can mitigate this somewhat by having another device (a computer, laptop, whatever) to which the phone would delegate part of the processing power, but this solution would definitely not scale to extremely large numbers. It is, however, extremely plausible as a starting point.
Option 4: Smart Phone -> Website
Senyo seemed confident that a lot of Ghanaian users have smart phones which presumably would have internet access (my emails to the Ghanaian service providers asked to confirm this, hopefully they will respond with some data). If smart phones with internet access are sufficiently prevalent, then we actually have two sub-options here:
- Program a lightweight website that Ghanaians can go to with a web app graphical user interface where they can enter their location.
- Program an app they can download which would automatically determine their location and give them the relevant information.
Advantages
- Would be easy to use
- Virtually cost-free in terms of set up, equipment costs. All we would have to pay for is website storage and whatever trivial app market fees there are.
- The interfaces would provide better locations: turn-by-turn directions perhaps, and maps with locations clearly marked would make them much easier to find.
- Kills two birds with one stone: They can also easily rate places they've been to from the same app.
Disadvantages
- We don't know the distribution of smart phones in Ghanaians at this time. And even if it is relatively large, the amount of them that have consistent internet access and data plans may not be acceptable.
- Programming and maintenance would be extremely difficult. In addition to testing the smart phone app or web app on the different operating systems (at least Symbian and Blackberry OS), we may have to test it on phone models that aren't even available in the US.
- In the case of apps, installing the app before use may be a bit of a hassle for first-time users.
Option 5: Phone Call -> Auto-Answering System
The more old-fashioned back up plan is to have a system that would answer their phone calls, offer them a menu where they could press a button to choose their area, and give them the relevant information. Software exists for this purpose, and they range anywhere from $100 to $600 (I haven't found any free versions at this time).
Advantages
- Somewhat easy to implement
- Easy to use -- all they have to do is call, listen, press.
Disadvantages
- May be somewhat slow--it will take a while for the system to read through each option.
- Maintenance and creation will be difficult. We'd have to have a human voice recorded to read every possible location, which is a daunting task. Speech synthesis (automatic computer reading) might not be trustworthy enough to pronounce some things here.
- The software is costly, and the additional costs--how would we make it so Ghanaians wouldn't have to pay international calling fees each time?
- Pay-as-you-go plans may make minutes a rarity, and it could discourage some from using a call-only service.
Option 6: Facebook App
This may be something interesting to look at for the future -- a friend from Kenya mentioned to me that Facebook usage is becoming pretty widespread in Kenya and Ghana alike. The data from this source shows about 950,000 Ghanaian facebook users (3.9% of the population) and incredible rates of growth (50,000 new users just in the past month). A facebook app would be simple to use--they simply log into facebook, click their location on the map, and look for places nearby. It would give us all of the benefits of a web app (option 4.1).
Recommendation
With all of these options in mind, I feel that option 3 is the best way to go right now. It could give us something to start with that can be plausibly finished and implemented by the end of the summer, which can be built on and expanded easily. Options 1 and 4 are, in my opinion, ruled out. Option 2 is the second best idea, while option 5 is a good back-up idea.
Wednesday, May 18, 2011
Setup / Test Post
Just set up this blog today; this blog will contain the record of my work done this summer.
Subscribe to:
Posts (Atom)