Generalized Feedback/alx

From Open Pattern Repository for Online Learning Systems
Revision as of 12:15, 26 September 2016 by Sfrancisco (talk | contribs) (Created pattern in alx)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


Generalized Feedback
Contributors Christian Köppe, Ralph Niels, Robert Holwerda, Lars Tijsma, Niek Van Diepen, Koen Van Turnhout, René Bakker
Last modification September 26, 2016
Source Köppe, Niels, Holwerda, Tijsma, Van Diepen, Van Turnhout, and Bakker (in press 2015)[1][2]
Pattern formats OPR Alexandrian
Usability
Learning domain
Stakeholders

You have just been discussing student’s solutions to homework assignments (as described in Use Student Solutions (Use Student Solutions)). Your intention was to give students a deeper understanding of the subject at hand, and to make them see how the principles involved are useful to them.

***

Students may find it difficult to distill the main points or the important principles from the example problems and the student solutions under discussion.


The discussion of the subject matter and its important principles had been grounded in the concrete example problems that were posed in the homework assignments. Sometimes it’s possible to provide several different homework problems that involve the same abstract knowledge or skills in different ways. Oftentimes, though, there isn’t enough time for that.

Furthermore, the discussion has focused on solutions provided by a subset of the group. Especially when the homework assignment is interesting enough that it allows for several different kinds of solutions, quite a bit of the discussion will (and should) be focused on the merits and drawbacks of these different ways of applying (probably) the very same principles.

Many students prefer discussion of concrete issues above treatments of abstract principles. Although the abstract principle is much more useful to them, it’s also more difficult to grasp and more likely to be considered boring by these students.

A challenge to the lecturer, then, is to enable the transition of the discussion (and student’s understanding) from the concrete example problems and their concrete example solutions to a generalized understanding of the principles involved, and the main points that the lecturer wants to make.

***

Therefore: Interleave the discussion of the concrete aspects of the examples with explicitly mentioning the general principles involved. Inject small examples of other situations where the same principle can manifest itself in a different way.


For many students, working from the concrete issues/examples up to a generalized understanding of abstract concepts is more likely to succeed than the reverse approach that works from abstract principles down to concrete examples. This pattern describes a full-circle approach: from a concrete problem (in the homework assignment) with its concrete solutions (under discussion in class), move to the more abstract level of general principles. Then use the additional (small) examples to base the discussion of the abstract level by providing a connection back into the concrete level (and to support the generalization). It is therefore related to Solution Before Abstraction (Solution Before Abstraction).

By explicitly calling out the general principles, you’re helping students elevate their understanding, and empowering them to remember and apply those principles in new situations/problems.

Also, you’re connecting the student’s efforts (in doing the homework, and coming to class) more explicitly with the learning objectives of the course. This increases their perception of those efforts as valuable.

By adding small examples of other situations or problems that involve the same principle you’re, in effect, “proving" to the students that the principles indeed do have a more general applicability. You are also demonstrating that seeing the abstraction is useful, because it simplifies the understanding of a wide variety of concrete issues.

By introducing some or all of the general principles in class, you’re positioning their introduction after the student’s have spent some time and mental energy on the problems or phenomena. This will make them more receptive to the general principles that otherwise would be seen as (even more) boring.


In the programming course “Scripting for Designers" at HAN University of Applied Sciences, one assignment involves writing a program for finding the longest piece of text in a list of texts. This assignment is paired with an earlier assignment in which they had to analyze a given piece of programming code, to discover that it calculates the sum of a list of numbers. The solutions to these problems are only similar on a somewhat more abstract level. They both involve a “loop" (repeatedly executing the same instructions on different data), and the designation of a piece of computer memory to collect the partial result while the loop hasn’t finished yet. This is called an “accumulator". During the discussions in class, the general principle of an accumulator is distilled from the two examples, and made explicit. Some examples of other uses of accumulators are shown, from domains such as databases, game development and financial calculations.

In this case, the material that students studied at home, before working on these assignments, were videos that introduced features of programming languages for working with lists of data.

Anonymize Solutions-alx.png
The solution as handed-in by the student (left) and the anonymized version use in class (right).


References

  1. First mentioned in 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.
  2. 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). Pittsburgh, USA.