Case Story: Programming Puzzles in Second Life

Summary	A reflection on teaching programming to a mixed class using e-voting handsets
Group / workshop	Formative e-Assessment	Status	seed
Project details...

Situation

What was the setting in which this case study occurred?

Situation
Today I co-taught a lecture class (50 minutes) on the Interactive Systems module for Computer Science and Information Systems students. We have 138 students registered on the module. It is a combination of first and second year students. A few students are studying for other subjects elsewhere in the university and for reasons I can’t fathom have been allowed to register for it. We are teaching Second Life, and today was partly focussed on Linden Scripting.  The students also come to two hour hands-on lab session later in the week. I had a flickery projector, 80 e-voting handsets, a laptop with an internet connection and some paper handouts.

Task

What was the problem to be solved, or the intended effect?

Task

My goals for classes tend to be varied. Here I was trying to: keep students interested and motivate them about their assignment which is to make a pet in Second Life; reward students by praising good work; introduce Linden scripting and give students some practice at it themselves. The main problem with all of this, is that half the students are novice programmers who are currently learning Java, half of them have a year of programming experience, and a few stragglers have no experience in programming at all and are not studying it elsewhere. 

Actions

What was done to fulfil the task?

Action

My solution was to: show examples of good work on the SL island, show screen shots of pets sent by students; ask my co-instructor to present good examples of student blogs on the VLE (also part of assignment); gave an example of a very simple script in SL. Gave students selected documentation of LSL for the relevant functions and set them a series of constrained puzzles to solve – i.e. write code (on paper) to accomplish this, based on the documentation. It’s pretty close to a real world task. I then showed them a sample answer and explained it. I wanted to know how easy they found this, so I had slides to use with the e-voting handsets asking the students to say whether they got the answer right, wrong, or in between. My last slide asked them to vote whether to move the class at a slower pace.

.

Results

What happened? Was is a success? What contributed to the outcomes?

Results

What happened? Hmm. I got through only one of the programming puzzles of the four I prepared. The e-voting handsets didn’t work because I forgot to put the usb dongle in the drive. The reason I only got through one example was that I saw the students were finding it pretty hard, so I gave them longer to try it, and I spent longer explaining it. When the handsets didn’t work, I tried again, then resorted to raising hands which meant the students had to admit in public if there were wrong. Not ideal.

Lessons Learned

What did you learn from the experience?

Reflections
 

Thinking about it, I realise we probably spent too long showing good examples of student work, and that is partly because I didn’t know how long my colleague would spend. It would have been better to spend some more time on the scripting examples.  As for the e-voting disaster I made the hardware mistake because I was trying to set up a laptop, a network connection, and the handsets in the 5 minute change over between classes when I was stressed. And attendance was low! 80 out of 138? What’s that about?

The problem of how best to teach this large but mixed group of students remains.  I have moved the examples I didn’t do in class to the lab exercise for them to try on Friday. But what do the second years get? They will gobble up the easy exercises and need something harder. But if I teach them something new, then the first years will fall behind. I need some material which is not essential for first years but which the second years would find interesting.

I don’t know whether I will keep on with the programming puzzles in class. It pains me to say this, but it might be better to resort to a lecture mode where I tell them stuff and give them worked examples and leave puzzles for lab time. Or at the very least I should scaffold the examples better so it isn’t so daunting. I was trying to take a cognitive apprenticeship thing of showing them how to solve problems (like how to look up documentation) but I think I mucked it up. I am just about to go to student coffee time, where I will ask them what they made of it and see if they can help me decide what would be best.

PS – We just got the e-voting handsets so I am experimenting with them

pps An obvious lesson might be not to be too ambitious for one class. I know this. I just ignore it all too often.

Licensing

This work is licenced under a Creative Commons Licence.