General guidelines for the Raspberry Pi Labs project

Download PDF version here

1.     1 a) Participants should draw on open content in developing any course materials, few course materials should be written directly. OER Guidance is available, e.g. and should be applied to any materials produced. Most proposals envisage rather long periods for writing lab manuals. The writing for these should be reduced as much as possible. It is likely that they will need changing after the first round of labs anyway, so draw on OER as much as possible, develop draft materials, and then test the labs with students. (I.e. use an agile development cycle, rather than waterfall.)

2.     All materials should be published as “Open Educational Resources” on this wiki

3.     Where general materials are developed (e.g., basic introduction to Raspberry Pi), the materials should be collaboratively developed between all grant holders, on a shared platform. Grantees are encouraged to use the mailing list (grantees@kenet.or.ke) and this Wiki to communicate in their own time and share lessons with the rest.

4.     Participants should introduce a change in pedagogy alongside the introduction of Raspberry Pi. Research evidence shows that introducing new technology first, then pedagogical change does not work. However, technology can be used as a leverage for pedagogical change.

5.     We encourage the teams to focus on a smaller set of activities first and then test them with students in an iterative fashion instead developing many courses.

6.     Engage students with the Raspberry Pi over longer periods (since it is supposed to be students-owned lab) rather than limiting their use to about 6 hours per week. This will allow students to gain familiarity with the Raspberry Pi and to innovate.

7.     We recommend the following models:

a)     Model 1 - Several shorter RPi-based activities are integrated into an otherwise traditional lab. Students only get short bursts of exposure, and it may be difficult for those students to fully get to grips with RPi, and thus difficult for staff to learn from the experience.

b)     Model 2 - A single Raspberry Pi-based lab takes place, supporting several courses. This would give students more experience and more chance to get to grips with Raspberry Pi, and thus staff can learn better what the possibilities are. Students can also compare the different activities, and rate them. Of course, it may not be possible to make these arrangements, but it would be worth considering.

8.     Allow students to experiment as much as possible. For example, get a group of students who have done the required course (e.g. in a previous year) to experiment with the lab, at the beginning of 2015. Once the testing group has tried the exercises, the lab can then be integrated into the regular labs.

9.     All laboratory exercises should draw on the special features of the Raspberry Pi. Teams should ask:

a)     Whether the same exercise is just as feasible on another platform.

b)     What is it about the Raspberry Pi that makes this exercise more interesting for the students?

c)     If it provides a better learning experience for the students?

d)     How does the Raspberry Pi contribute to making this exercise successful?

10.     Consider extending the use of the Raspberry Pi beyond the labs. For example, the Raspberry Pi comes with Mathematica for free. It should be possible to give some student projects that make use Mathematica if possible.

11.     In most cases, consider using the Raspberry Pi model A+. It may be fully sufficient for the lab work envisaged and it’s cheaper. To enable future collaboration, grant holders are encouraged to look at http://www.cambridge-africa.cam.ac.uk/funding/ and to apply for funding for projects jointly with the University of Cambridge, if appropriate.Transforming education through ICT