In module 2, section 1, we explored hands-on workshops in Second Life. The activities consisted of
- Analysing hands-on workshops using an analysis grid and coming up with a list of key factors for the design and delivery of successful SL workshops. My personal list is here.
- Designing and implementing our own hands-on workshop
- Peer-evaluation of the workshops using an observation form based on the key factors that came up in activity 1.
- Writing an analytical “story” of our experience with our workshop using the STARR template for storytelling which was provided.
Constructive feedback from peers can help tremendously in helping a teacher to improve their teaching practise. Peer observation and evaluation can be rewarding for both sides, the observer and the teacher being observed. Having read most evaluations, in this workshop activity peer observation did not work well in my opinion. One reason might be that the observation form had not yet been complete before some of the observations started. Another reason, I suspect, was that peer feedback was “public” and could be viewed by all course participants and coordinators. This might have been a dilemma for some who might not have wanted to be critical openly. Additionally, as many of the participants are still very new to SL and this was the first workshop they had conducted in a virtual world, peers wanted to be encouraging. This is perfectly fine but for feedback to be developmental, there should also be suggestions for improvement.
As a result, I think peer observation and giving constructive feedback is a skill that needs to be practised. Also, as trust is an important factor in peer evaluation, these should not be made public. Instead, in a course, where all could benefit from reading about others’ evaluations, participants could be asked to collect main points they observed together with suggestions for improvement in a separate place without names, kind of like a teacher who gives general class feedback at the end with relevant points that they observed while monitoring a class activity.
My STARR story: Building a Board Game with Daffodil
A beginner Second Life builder trying her hand at giving a hands-on building workshop.
What was the setting in which this case study occurred?
After having observed and analysed hands-on workshops, we had to plan and deliver our own. It was difficult for me to think about a topic for my workshop. I had thought about and discarded several ideas due to time, space or other constraints. My building and scripting skills are limited but I decided I could manage a beginner building workshop. I knew I wanted it to be useful to my peers and fun.
What was the problem to be solved, or the intended effect?
To plan and deliver a workshop for beginners to build a simple interactive board game within a time limit of 60 minutes. The number of participants was limited by the number of building spaces provided to a maximum of 12.
What was done to fulfil the task?
When I had decided on building a board game, I first wanted it to be a collaborative building task but in the end I didn’t dare to do it. I was not sure I could handle all the problems with permissions that might come up, especially with beginners. So, I decided every participant would have their own building space which would be their game board. This meant that there was not enough space nor time for everybody to build a complete game that we could play together at the end but it would be enough to demonstrate the skills and the concept.
Preparation: I prepared 12 boards/building spaces for participants. This meant some of them would be out of normal chat range. I modified my SpeakEasy HUD script to make it shout the instructions (suggested by a friend) but we would also communicate and needed a save means for this. Not everybody knows how to shout. I thought of putting up a sign but participants might forget to and by habit simply hit the enter key. A friend came up with the idea of chat relay but an experienced workshop tutor said it caused lag. Another friend suggested I use group IM. Why didn’t I think of that? Sometimes, in a stressful situation (and preparing the workshop was stressful for me because I had no time), we forget even what we know.
I wanted to announce a demo of my workshop in another group of educators to test it, improve the instructions but again because of lack of time, I could not do that. On the day of the workshop, an experienced friend asked me on Twitter whether I wanted to do a run through. It was only three hours before the actual workshop but I agreed and am so happy I did. As a result, I simplified my instructions, deleted some slides and additional information and most importantly found out and solved some issues with permissions.
Another issue that came up in the run-through was that participants would have several windows open at certain times in the workshop (edit window, notecard, group or local chat window) plus needed to look at the slides and back at their objects. I could not avoid any of these but I decided to tell participants this would happen and gave some tips at the beginning (making windows smaller or minimising them when not needed).
Multi-tasking for the tutor can be challenging, too. In other lessons I taught in SL, it often happened that I received several IMs from friends who did not know I was teaching, from students who wanted to be teleported (instead of asking peers or finding the LM in their inventory), IMs from students present who preferred to ask a question privately than in local chat plus group notices or IMs from groups I belong to. At the same time having to deliver the lesson, change slides, take notes, chat with students in local chat, etc. can be quite demanding. And I am usually much more exhausted after a SL lesson than a Real Life one. In regular classes, I establish some rules with students (e. .g “send teleport requests to peers not the teacher”, “don’t IM teacher during the lesson except when it is required in a task or absolutely necessary”, for friends: “when I am in busy mode, it really means I am busy and will not reply”. This was not possible really for this workshop because it was a one-off session.
Tools can be of great help in delivering lessons but they can be a real pain, too. I rarely use more than two teaching aids or tools in a session. Of course, this depends a bit on the situation. The same goes for the actual topic and the lesson plan. For the workshop, I decided a slide screen, a material giver and (the invisible) SpeakEasy HUD was enough. I had prepared slides of the different steps to avoid having to give long-winded instructions. I used a screen that I had recently be shown by a friend on which you can highlight areas. Very useful indeed! I also printed out the instruction text and crossed off what I had already said with the SpeakEasy HUD.
I was a bit worried that my workshop might be too simple and my instructions too detailed. However, it was declared as a beginner workshop and details can always be ignored by those participants who don’t need them 🙂
At first there were only the two participants who had also signed up as criticla friends. But then two more came. The session went smoothly and participants could follow the instructions easily. I have to say, however, that several were not beginners. A late-comer started on his own and was able to catch up. One participant had frequent crashes and fell behind. Another participant did something I had not expected and this caused her problems for the later steps. I helped by giving her additional instructions in IM to remedy the situation. I am still not sure what caused this: my instructions, language issues or the participant being distracted by private IMs (which I suspected).
Latecomers can cause havoc in a workshop. I did not observe enough workshops in SL to know how experienced tutors deal with them but having planned to deliver my workshop in the MUVEnation sandbox, I knew I could expect latecomers and guests and this was to some extend even welcome. I did say how I would deal with them in my workshop description (observe or take the worshop material and try on your own) but, of course, not all would have read it. Some just popped in to do something in the sandbox, saw that something was going on and started chatting with me: “Long time no see” 🙂 I was determined not to have the flow of the workshop be interrupted too much by these but I didn’t mind observers and I didn’t want to sound unfriendly or unwelcoming. So I said a few words but indicated in local chat that we were going back to the instructions.
Surprise guest: At some point, a former SL student of mine suddenly materialised on a participant’s board. He was one of the students who were on the slide that I had shown at the beginning of the workshop showing him and peers playing my first board game. I thought I was dreaming and tried to make sense of it. I know a lot can happen in SL but I started thinking “my showing a slide of him can’t have made him appear in my workshop. Yeah, after being in SL for a longer while, you start believing such weird things can happen 🙂 It turned out that he had been teleported by the participant on whose board he arrived. I had introduced them some time ago and apparently they had developed a friendship.
All participants were able to finish their game. Although, none of them had prepared questions in advance (I had asked for this as preparation for the workshop). Nobody seemed willing to spend the time to write all the question notecards but they did write some so we could test the games. When taking their objects (the board with the tiles) into their inventory, they could not take the boards although I had set permissions to copy/mod. I had forgotten to tick one more box and when I did, participant were able to take them.
What did you learn from the experience?
- Instructions can never be detailed enough
- Talk your ideas through with someone
- Always do a run-through before you do the workshop for the first time
- Don’t expect participants to have read through your announcement and have prepared for it.
- Be prepared to do shortcuts and don’t force participants to do all the steps if it is not absolutely necessary.
- Always double-check permissions of your material.