The current eWorkshop design course is in its third week. We’re starting to design learning activities and the current group is facing what eWorkshop designers face with every design: What should be an individual task? What should be done collaboratively? What should be cooperation?
It’s often the difference between cooperation and collaboration that requires the biggest mind shift. The difference is important and it has significant design implications.
I like Pierre Dillenbourg’s explanation: “In cooperation, partners split the work, solve sub-tasks individually and then assemble the partial results into the final output. In collaboration, partners do the work ‘together’.” Olga Kozar’s definition is also very clear: “Cooperation can be achieved if all participants do their assigned parts separately and bring their results to the table; collaboration, in contrast, implies direct interaction among individuals to produce a product and involves negotiations, discussions, and accommodating others’ perspectives.”
So what does that mean for eWorkshop design?
The following is a typical activity in online courses out there: “Do this piece of work, share it with others in this forum, read at least 2 other submissions and comment”. Because it involves other people, you might think that this is collaboration. It isn’t. It’s cooperation.
There are a few issues with this approach – I explained this here.
It’s OK to have a few cooperative tasks in an eWorkshop, but keep in mind that the backbone of any eWorkshop should be collaborative problem-based learning. This is what the model is based on – this is what makes it successful. This means that the main activities should be collaborative. In an eWorkshop of 5 to 7 weeks, there would typically be 2-3 core collaborative tasks, which might be supported by a range of minor cooperative and individual tasks.
What do we mean by ‘collaborative learning’?
Pierre Dillenbourg explains the concept really well in this article. He says: “Collaborative learning is not a method because of the low predictability of specific types of interactions. […] It’s a situation in which particular forms of interaction among people are expected to occur, which would trigger learning mechanisms, but there is no guarantee that the expected interactions will actually occur. Hence the general concern is to develop ways to increase the probability that some types of interaction occur.”
He goes on to categorise these ways. I borrowed three of them here and reflect on how we approach them in the eWorkshop model.
Set up initial conditions. Dillenbourg writes: “A first way to increase the probability that some types of interaction occur is to carefully design the situation.” There is a whole range of ‘design’ elements that play a role here: ideal team sizes, team composition, the tools used, how they are used, the type of task (is it suitable for collaborative processes?), just to mention a few. This is probably the hardest part of the task design. It gets easier when you have designed a few and have been able to try them out on a group (and tweak if necessary).
Use scenarios based on roles. We don’t use roles in our team activities (apart from team leaders/presenters), because with a typical dropout rate of 20%, this is too risky. But Dillenbourg’s focus on scenarios is interesting here and one we use constantly. It is closely linked to problem-based learning principles. Real-life problems that reflect systematic differences between learners, or complementarity between learners’ skills require rich interactions.
Monitor and regulate the interactions. The role of the e-facilitator is paramount in the success of collaborative learning. It’s important that we facilitate and don’t tutor – because, as Dillenbourg points out, “the point is not to provide the right answer or to say which group members is right, but to perform minimal pedagogical intervention (e.g. provide some hint) in order to redirect the group work in a productive direction or to monitor which members are left out of the interaction.” What the article doesn’t mention is the importance of the e-facilitation style, including the e-facilitators’ online voice, their feel for when to support and when to stand back, etc. It’s part art, part science.
Ready to design for collaboration? This past blog post might be helpful too.
2 Comments. Leave new
[…] The current eWorkshop design course is in its third week. We’re starting to design learning activities and the current group is facing what eWorkshop designers face with every design: What should be an individual task? What should be done collaboratively? What should be cooperation? It’s often the difference between cooperation and collaboration that requires the biggest mind shift. The difference is important and it has significant design implications. […]
[…] […]