I thought I would tell you more about the thinking behind the buzzer project. The idea is to allow a quick and quiet feedback channel from student to teacher. Quick is important so that teachers can tailor the teaching to performance of the student and quiet is useful because some students don't like displaying their lack of knowledge to the whole class. The idea is that it can be used in multiple ways. Some basic examples are things like multiple choice tests and just asking the students if they understand at certain points in the lesson.
It will have lights to give some immediate feedback, and a buzzer so that in some modes the teacher can tell who buzzed.
It also has the potential to be used for fun games as the button controller could be used to control a character.
We haven't yet got the stipend through so we haven't done our first order. It is not going to be a very surprising though in terms of materials. Electronic components will probably consist of, LEDs, buttons, some AVR micro-controllers and the wireless connections. For the handsets and hubs MDF, plywood, acrylic, rubber, nuts and bolts will the the main materials used.
The key problems we will face is not getting too bogged down by feature creep. Also making something easy for teachers and something the students want to use will be a challenge whilst keeping the platform open and hackable.
Feature Creep
We have had lots of ideas. One of them we are implementing currently is to allow mobile phones to act as controllers by creating special web pages with buttons on. This will allow us to test the logic, and give demos of usage while the hardware is being worked upon.
We also are thinking about possible games we might create, different ways of associating controllers with students (so results can be logged) and a lot of other things.
All this means we have to be selective about what we try and implement.
Prototypes
So far we have an initial bit of code for the "hub" part of the setup so we have some structure for the computer based communications (we'll make some pretty diagrams of the organisation of the software at some point, it is somewhat complex as we want to be able to switch in different bits). We also have beginnings of the handsets for the pupils to use.
Ease of Use
Most teachers are opposed to any change, even if they are told it is beneficial, and especially if its to do with IT. This is the hurdle the design has to overcome - the classroom benefit has to be very obvious to them, and teachers should not have to do much more than open the program to learn how to use it. This is because teachers are wary of education technology, which is typically expensive and very low quality, and they need to know it well enough to pass it on to students. This means that all the complicated stuff needs to be hid from teachers.
