Somehow I have inched my way towards week 6 of semester, clinging on with my fingernails. Next week I am not in the office, so I don't have classes to prepare and I can take the opportunity to think about what has happened with my monster class so far, and where to take it from here. Monster class? I am referring to the number of students (138) rather than their natures (mostly quite sweet).
Monster class is a horrible hybird, consisting of students from our first and second years of both computer science and information systems degrees. We also have a peppering of second year maths students and some combined studies students. The module is Interactive Systems, and requires some Linden Script programming skills. Some of the students have no programming experience at all, some are learning Java at the same time, and some have a year of Java instruction behind them. Some of them have been professional programmers, or are very experienced hobbyists. (Thankfully none of them are Sun certified Java programmers, which happened to me on my very first year of teaching when teaching a Java module. ) Nobody would design a module this way, but it has happened due to a conspiracy of circumstances for this year and this year only (or so I am assured).
We have sorted out the main technical and admin challenges; by now people are signed up with Second Life and working on the island. For some snapshots of the island in progress, see Nicole (aka Flexible Learning Pal)'s blog. Watch out for the snowmen armies. There is an outstanding issue with the students who are under 18, but I will spare you a repeat of my rant on that front. Each student has a blog in Blackboard, which has a truly horrible interface, and they are in groups to give each other support via blog comments. My colleague and I try to leave comments on blogs where we can, but as you can imagine it is a Sisyphean labour. I also visit the island when I have a chance to talk to students, and send them instant messages commenting on their work. A feature of the weekly class is "Creature of the Week" where I showcase some examples of the students' work. You will perhaps recall that their assignment is to create a virtual pet. We've got monkeys, piggy banks, snakes, dancing dinosaurs, ray fish, and dancing dinosaurs. Oh yes, and a ninja bunny, as we see below.
Second Life is working out reasonably well. Our students are techy savvy gamers who are not easily impressed with technology. According to a debate on our discussion boards, they look down on the SL technology as it pales in comparison with games they commonly play. At first some people couldn't see the point of it. "It's boring" they said. "What are you meant to do?" In my view, this is like being given a big box of plasticine and whining "but there's nothing to play with". The point is - you're meant to make it yourself! Or at least, the point for this class is to learn to build things, but more importantly to program behaviour. However, I think that now the students have been working on their own creatures and have been learning how to script, their attitudes are more positive. Hard to tell, of course. I was talking to a student the other day who wanted to learn C or C++ instead because it would help him get a job. So I did the whole "Learning Linden Script will teach you how to learn a programming language even if it is not useful in itself" speech. In fact, I have been really emphasising the process of learning how to program for yourself, particularly in the area of looking up documentation. Nor do I think that every module in a degree course needs to teach you industry skills (even although our uni motto mentions "useful knowledge"). There are other reasons for learning things, particularly in the first year, and this module is designed to teach a number of broader skills including the iterative creative process of design->implementation->testing->revision->peer review.
It's quite interesting to see how the students react to learning scripting in SL. I was talking to some first years the other day, and some of them said it was much easier than Java which they are learning in another class just now. I suspect this is because Linden Script is not object orientated and they can hack together something quite quickly if they know another procedural language from school. By contrast, our Java module teaches using Blue J (which I love), and is focussing not on just writing programs that work, but on writing well designed programs that work elegantly using object oriented principles. It's the difference between hacking and software engineering. I can see why it might seem like step backwards to use BlueJ if you had been accustomed to visual basic or something, and why Linden Script might seem comforting. I don't find Linden Script comforting. It's poorly documented and lacks some features which you might expect such as arrays or decent string processing. The in built script editor is very limited, although it is possible to download the free LSLEditor which has a debugger and bracket matching, which is always useful to learners.
You might wonder why I am using Second Life at all, given the scathing things I have to say about it. The answer is that I think that the positives currently outweigh the negatives. It's a lot of fun for me to teach, and based on the learning logs from last year, a lot of fun for the students to learn with. The students get very absorbed in their own projects, develop their own goals, and research how to solve their own problems. They don't do this because someone has told them they need to learn independently. They do it because they want to make their rabbit respond when it is petted. Or they want to make their spaceship fly, or their phoenix glow with a soft gold light. The students are making things they are proud of, and that counts for a lot in a first year course. I also think it's sufficiently challenging. I hope so anyway. I am tying myself in knots trying to keep the second years challenged but preventing the first years from getting lost. In a way, the open ended nature of SL is on my side because the second years have a lot of scope for investigating their own ideas. Whether they will or not is another story: one of them did ask me what was the easiest thing he could do for most marks. <sigh>
This exploratory learning approach does have drawbacks. For example, in the labs some of the students get side tracked by making floppy dog ears when I want them to make snowmen dance. Not a problem you have? It is only problematic in the sense that making dog ears is relatively easier than writing a script to make a snowman move position. You could argue that they must be highly motivated to be so caught up on working on their pets for their assignments. But part of teaching is diagnosing what skills the class have, and so I sometimes need to see them working on the same task to know how to judge the pace we move at. I did manage to convince the first years to work on the lab tasks this week, so I will see if I can also persuade the second years.
A note on collaborative learning: Nicole pointed out that the students last year were much more inclined to collaborate than the first years this year. This may be because they are older, but also they were partly assessed on their group work. I wasn't brave enough to try group work in SL with the first years, so labs have mostly been individual work. But Nicole inspired me to set up some explicitly pair activities. Last week I got the students to program their chatbots in pairs. (As an embarrassing aside: I was preparing for this lab by writing an Eliza like chatbot which responded if you said things like "I am sad". I was talking to it to test it, when a student working beside me overheard and smirked "nice conversation". Hopefully he now realises why I was appearing to get therapy in SL!) It is actually very useful because it not only gives them some extra support for a difficult task, but it also gives me the opportunity to hear them articulate their thoughts about what they are writing. Once I hear how they are thinking I am better able to help, rather than just watching them stare at their own screen. And for those students who always have their eye on whether something makes them employable, many software companies have a practice of pair programming.
One last comment about peer support is the success of asking some of the more experienced programmer students to volunteer to help out in labs. Nicole has written about this a bit, particularly about how a couple of the students made a beacon in SL which students can press if they need help. If any of the student helpers are logged in, then they will be notified and can choose to accept or decline the request. If they accept, they are notified of the student's location so they can fly there. Isn't that cool? These are the kinds of things I would like to write but never have the time to do. I share their geeky sense of glee in getting such things to work!
For beginners,though, face to face help with programming is often more helpful than help through typed messaged in world. Sometimes they need help with spotting a compiler error, and sometimes they just really need to sit and watch how a more expert programmer solves a problem. The student helpers have so far been great at this. It makes a big difference to have more helpers so the other students get more face to face time at a crucial time in their learning.
As the semester goes on, we'll be in a better position to evaluate teaching with SL to this student group. In the meantime, I am going to enjoy next week where I am in the blissful situation of teaching kids to make games with a staff to learner ratio of 3:10 instead of 3:60. Hooray for research!
Comments