Collaborative Editing/alx

Collaborative Editing
Contributors	Christian Köppe, Michel Portier, René Bakker, Stijn Hoppenbrouwers
Last modification	June 6, 2017
Source	Köppe, Portier, Bakker, & Hoppenbrouwers (in press 2015); Köppe et al. (2016)
Pattern formats	OPR Alexandrian
Usability
Learning domain
Stakeholders

You want to show students how they can apply new knowledge, e.g. with Show Programming (Show Programming) or Show It Running (Show It Running) using a tool or editor.

***

Showing content in a tool using a projector makes you as teacher the only one who is actively working with the content, the students can easily slip back to their passive role.

Remote Hand (Remote Hand) does not work well with longer content parts (like whole functions in programming) as they time needed for dictating might be too long. Furthermore, complex content (like source code expressions) can easily lead to the "chinese whispers"-effect: the message is understood differently by the lecturer than originally communicated by the student.

Furthermore, if the lecturer does enter all the code into a tool, then the students are more or less forced to be passive and wait until the lecturer is done.

***

Therefore: Use a tool where both you and the students can edit the document and which everybody can access using their own computer. Have students also add, edit, or delete parts of the document instead of doing it for them.

This way the students can actively participate in collaboratively editing the content and they can copy&paste the results to their own environment.

This pattern is a variant of Remote Hand (Remote Hand). The biggest difference is that students partly add parts to the document themselves through the collaborative editing tool.

Beware of the group dynamics when you apply this pattern for the first time in a group, as the students are likely to test how it works and will heavily edit and change the document. In order to handle this, allow them to do so for a short period of time (announcing that they now can try the tool and write/change whatever they want as long as it is over-the-top). After this period you as lecturer decide who is allowed to edit the content.

Using a text-based tool for e.g. collaboratively editing source code has some advantages and disadvantages. On the one hand, it is great to just run a program and use the observable results (error messages, console print-outs, compiler messages etc.) for discussing the issues related to them. On the other hand, it can be good to not being able to compile and run the program, but rather discussing how it will behave if compiled or run. This encourages the students to think and reason about if the program is working and doing what it is supposed to be doing, a much more active approach that helps students with more deep learning.

In an introductory programming course at the HAN University of Applied Sciences, students have to write short programs which solve given problems, e.g. a robot who can guided along the screen and can pick up and drop small packets. After the students had worked on that assignment for some time, the lecturer opened the online collaborative editing tool Collabedit and started to build up the solution together with all students. Step by step he asked students to copy a small part of their program to the tool, which was then discussed with the rest of the class. In some cases other students had solved parts differently. These were asked to copy their implementation into the same document, so that two solutions were seen side-by-side. Examining and discussing the differences was of great value for the students, and many copied the alternative solution too.