Classroom HackSpaceChallenge/Report/2

Brief

Provide a basic outline of the materials you will be using in your build and any key challenges you anticipate.

Draft

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 and the beginnings of the handets 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.

We have been in contact (through Daniel) with a school and they are worried about having to learn a new program. They evaluated a closed source solution and found it too complex to use, so we have to be wary of this trap. Hopefully we can soon show them a demo of how it will work to allay their fears.

Speaking of demos we are working on the software while waiting for the money to come through. We are mainly hacking things together as quickly as possible. Good engineering will have to wait a while. *Insert screen shot of the web controller*