Opensim in education (with alpha software)- lessons learned

just some quick notes… so i don’t forget them. More will get posted at openhabitat.

Well… for those of you following, the second run at it went MUCH better than the first one. We rejigged our plan, forwarded our initial goals to the front end, used a little more scaffolding, and the whole process skimmed along quite nicely.

So, when your working with alpha software, it helps if you’ve got two things going on in the computer lab. What we did this time is that we took four students and used them to develop our workflow live and in cooperation with the students. What we did this time is that we had the students roughly cut into two, and one group worked on editing their blog posts and the other was working in opensim using the workflow developed by the students. Groups of three, two coaches and one ‘driver’ who was actually trying to get the initial ‘quest’ accomplished. So important, i think, to have a nicely strucutured activity to complement more freeform fun in the MUVE… and to forward the structure. Play seems to be automatic and, so far in my experience, isn’t encumbered by more early structure as it seems to in a standard website.

The degree to which every student i saw on Monday had a full set of computer literacies was astonishing. Every one of them seemed to be able to move forward and backwards, navigate up stairs etc… I may have missed one or two students, but the ones i saw were quite proficient. They also seemed to be able to recognize flaws in the system quite easily, which was also useful. Several students expressed a desire to be part of the debugging process.

As always, don’t panic. We had several issues that cropped up, much much fewer than last time, but the fact that the team was willing to work together kept things pretty steady. Our decision to make the MUVE part of a larger project was gold for this part of the exercise.

1. because of the potential for vast literacy differences from class to class, establish workflow and goals at the beginning of the project with the students who will be using the software.
2. have two things going on so that you have a fallback lesson already running if the cutting edge tech starts to fall apart. You don’t really want to be sitting there with a bunch of worksheets (boring) to fill the time. A class planned with two concurrent activities one technologically dependable, one more risky, makes the transition to the ‘other activity’ seemless and much less painful.
3. forward the structure to the front end of the lesson. Unlike other social networking sites, students don’t seem to feel ‘restricted’ in their play by having a heavily structured exercise as their introduction.
4. ask for volunteers for gathering debugging information. Some students seem very keen, and valuable information can be lost in the drama of the moment.
5. Make your MUVE part of a larger project. whether your muve is proprietary or on an unstable platform, it’s nice to have the canonical information in another venue… and it diversifies the project. Many people will never see the muve… and if they can visit the website, with video of the MUVE, it helps spread out the reach a bit

Author: dave

I run this site... among other things. View all posts by dave