Since their original inception in 2006, Parsons puzzles have repeatedly been shown to be an
effective tool for supporting the development of students’ programming skills. There have been
so far very few software tools designed to help students practice with these puzzles. In this work,
we propose to first review existing tools from the traditional perspective of the requirement to
better serve students, but also by adopting a similar perspective including the needs of instructors
and Computing Education researchers. We also introduce a new tool, EvoParsons, and show how
it proposes to address some of the limitations and opportunities that were identified.
EvoParsons is a proof of concept implementation designed to interchangeably use both
instructor-designed Parsons puzzles, but also automatically generated ones. Simply enabling such
possibility already taught us the critical importance of providing an easily extensible Parsons
puzzle implementation. Computing Education researchers, who are interested in applying
artificial intelligence techniques, benefit greatly from open source access to Parsons puzzle
software. However, we found these implementations to be even more useful if they rely on
language-agnostic technologies such as REST web-based APIs.
These needs differ when Computing Education researchers are more interested in analyzing the
students interactions with the puzzles. In such scenarios, simplifying the deployment of multiple
server versions (aimed, for instance, at supporting different experiments or groups) is essential.
We identified Docker containers as a way to address such needs efficiently. In addition, such
researchers also need to have easy access to very detailed logs of the interactions that occurred
between students and the puzzles. Relying on a well-established format facilitate further analysis
of such logs by a wide variety of tools.
From the students’ perspective, our preliminary evaluation of EvoParsons also revealed the
importance of identifying and mitigating aspects of the user interface that might increase the
user-fatigue phenomenon and thus make the student-puzzle interactions less meaningful.
Accessibility of the software, which for many students nowadays also includes tablets or smart
phone, was also found to be an essential feature absent from existing tools.
Last but not least, from the perspective of instructors, making Parsons puzzles easily available to
their students is the primary goal. Again, ease of deployment of server-side components plays a
central role in this that can also be addressed by the use of Docker containers. However, it is just
as essential for instructors to be able to easily modify the puzzles managed by the software.
Parsons puzzle software should therefore facilitate the contribution of new puzzles, either via uploading files describing puzzles in a straightforward format, or by providing an instructor
interface to the software allowing to manage such contributions. We explored the former
possibility so far.
We conclude our comparison between EvoParsons and existing tools by reviewing preliminary
student feedback on the use of the EvoParsons system.
Are you a researcher? Would you like to cite this paper?
Visit the ASEE document repository at
for more tools and easy citations.