Difference between revisions of "Classroom HackSpaceChallenge/Report/2"
(→Draft) |
|||
| Line 11: | Line 11: | ||
It also has the potential to be used for fun games as the button controller could be used to control a character. | 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, LEDs, buttons, some AVR micro-controllers and the wireless connections | + | 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. | |
| − | The key problems we will face is not getting too bogged down by feature creep | ||
====Feature Creep==== | ====Feature Creep==== | ||
| Line 23: | Line 22: | ||
All this means we have to be selective about what we try and implement. | All this means we have to be selective about what we try and implement. | ||
| + | |||
| + | ====Prototypes==== | ||
| + | |||
| + | So far we have an initial bit of [https://github.com/eb4890/lhsgghc/tree/master/programs 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. | ||
| + | |||
| + | |||
| + | [[File:protobuzzer1.jpg|200px]] | ||
| + | |||
| + | [[File:protobuzzer1.jpg|200px]] | ||
====Ease of Use==== | ====Ease of Use==== | ||
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. | 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* | 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* | ||
Revision as of 13:53, 2 April 2011
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.
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
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*