Update 8/7

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.

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:

• 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:

http://tronixstuff.wordpress.com/2011/01/19/tutorial-arduino-and-gsm-cellular-part-one/

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).

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.

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:

Click & Learn

i>Clicker

SMART Systems

eInstruction

pollEverywhere

2know

dell

...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.

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.

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. 

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.