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:

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

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.