Compare Solutions/alx
Compare Solutions | |
Contributors | Christian Köppe, Ralph Niels, Robert Holwerda, Lars Tijsma, Niek Van Diepen, Koen Van Turnhout, René Bakker, Stijn Hoppenbrouwers |
---|---|
Last modification | June 6, 2017 |
Source | Köppe, Niels, Holwerda, Tijsma, Van Diepen, Van Turnhout, and Bakker (2015)[1][2]; Köppe et al. (2016)[3] |
Pattern formats | OPR Alexandrian |
Usability | |
Learning domain | |
Stakeholders |
You want to Use Student Solutions (Use Student Solutions), so the students got assignments or problems to solve. These assignments can be solved in different ways or different approaches can be taken to come to a solution. The handed-in solutions of the students will therefore likely be very heterogeneous, but will still (attempt to) solve the same problem.
Students are only familiar with their own solution, and are unable to recognize strengths and weaknesses in them.
By themselves, students will only discover a single way of reaching a solution and try only one, or maybe few, approaches. Students are often not yet capable to judge the merits of their solution, or to criticize it.
By showing the students solutions and approaches of other students, you may take away the valuable lesson of either getting to the best solutions themselves, or of making mistakes (which often is a better way to learn than watching other people’s mistakes).
Also, students may be less interested in watching other students’ solutions than they are in watching their own.
Therefore: show multiple solutions to the same problem that are comparable and differ in interesting ways. Discuss the strengths and weaknesses of them in comparison to each other.
Comparing student solutions is a good way of implementing Use Student Solutions (Use Student Solutions). The most simple implementation is to show two differing solutions side-by-side. Highlight the positive and (potentially) negative aspects of each (or have students name the strengths and weaknesses of the solutions themselves). Show how different approaches can come to different solutions, and how different solutions can come to the same solution, but in a more or less efficient way.
The solutions can also be used in a sequence, hereby highlighting and collecting the strengths and weaknesses of each solution and comparing these afterwards.
By applying this pattern, students gain insight in different styles of thinking about a problem. Seeing how other students approached and/or solved the problem can bring them towards a better understanding of the problem. In some cases, they will see better or more efficient solutions by other students, which will help them in getting to that solution the next time they try to solve a similar problem. In some cases, they will see solutions that are equally good as their own or that are of less quality or are less effective. This will help them to gain a better understanding of the quality of their own solutions, and it will help them recognizing, and preventing taking less successful paths in similar problems.
Students may feel the alternatives are being artificially demonstrated. This patterns should therefore not being over-applied.
An alternative for Compare Solutions (Compare Solutions) is Peer Feedback (Peer Feedback). Even though the students are exposed to different solutions (and possibly approaches) here too, this pattern lacks the advantage of being able to consciously choose didactically valuable solutions that help with overcoming known misconceptions and that show a variety of relevant approaches and solutions.
The problem that students may be less interested in watching other students’ solutions than they are in watching their own can be counterbalanced by applying Every Student Solution Counts (Every Student Solution Counts).
As always when students’ solutions are used, make sure to apply Student Contribution Esteem (Student Contribution Esteem) and optionally apply Anonymize Solutions (Anonymize Solutions) in the beginning when appropriate.
In the introductory programming course at HAN University of Applied Sciences, students start with simple programs written with the Processing[4] environment. One of the first assignments is to write a small program that prints the coordinates of the mouse in the message area. In order to compare different ways of realizing this assignment, the students’ solutions were chosen and presented to the class with the projector. The figure below shows how two different solutions were presented to the students and then were used for comparing and discussing the strengths and points for improvement of both, e.g. printing in draw() vs. printing in mouseMoved(), usage of comments and extra variables, or usage of the constrain()-method.
References
- ↑ Köppe, C., Niels, R., Holwerda, R., Tijsma, L., Van Diepen, N., Van Turnhout, K., & Bakker, R. (2015). Flipped classroom patterns: designing valuable in-class meetings. In Proceedings of the 20th European Conference on Pattern Languages of Programs (EuroPLoP 2015). New York:ACM.
- ↑ Also mentioned in Köppe, C., Niels, R., Holwerda, R., Tijsma, L., Van Diepen, N., Van Turnhout, K., & Bakker, R. (in press 2015). Flipped Classroom Patterns - Using Student Solutions. In Proceedings of the 22nd Conference on Pattern Languages of Programs (PLoP 2015). New York:ACM.
- ↑ Patlet also published in Köppe, C., Niels, R., Bakker, R., & Hoppenbrouwers, S. (2016). Flipped Classroom Patterns-Controlling the Pace. In Proceedings of the 10th Travelling Conference on Pattern Languages of Programs (VikingPLoP 2016). New York:ACM.
- ↑ https://processing.org/