Overview
Many instructors asked for a way to detect plagiarism, so we added a "similarity checker" feature that finds similar program submissions among students in a class, and highlights similarities (like Stanford's MOSS program).
However, we also encourage instructors to focus on preventing plagiarism in the first place, by reducing a student's temptation. Thus, we also released a zyLab "coding trail" feature. A coding trail is a compact representation of a student's history with a zyLab. Students may be less likely to copy-paste code when they can see that the system is recording their work for instructors to see.
Coding Trails
Both Classic zyLabs and Advanced zyLabs display a coding trail of work just below the student's code output:
In this AZL example, we can see the details in the coding trail.
- The date the workspace was first active
- The day the workspace was first active
- Indicators for develop runs (-) and submissions (score)
- The length of time they’ve spent on the assignment.
Note: M: Monday T: Tuesday W: Wednesday R: Thursday F: Friday S: Saturday U: Sunday
Coding trails will display for each student in Student activity. You can click on a student to expand their coding trail and view their work.
The above student started on 3/8 (March 8th) on Wednesday (W).
- Each "-" indicates a develop run, meaning the zyLab is configured for students to code in the zyBook, and the student ran their code in the zyBook.
- Each score, like the “3, 8, 10”, indicates the student submitted and received that score
- Each "," separates submissions, so 8, 0, 10 means a submission earned 8 points, then the next submission 0, and the last earned 10.
- The time “min:13” at the end of the trail indicates how long the student spent working, and times out after 1 min.
- The blue highlight “,10” indicates what submission is open below the student’s coding trail. You can click on any run or submit to open their submission to that state.
If a zyLab is configured for students to code outside the zyBook and upload files, the coding trail will only contain submits. In that case, we recommend instructors tell students they are expected to submit their code throughout development, such as after every 20 minutes of effort, knowing the score achieved may be low, so that instructors can see when they started and the history of their effort.
Discussion
Coding trails can reduce the temptation among some students to cheat. This is akin to how many retail stores have a camera and video display visible to entering customers. Such displays are known to reduce shoplifting, as the entering would-be shoplifter sees the display and thinks "Hmm, there's video, maybe I shouldn't".
Of course, we also don't want students feeling like they are being constantly monitored. Thus, we've placed the coding trail in a location, and sized it, such that students will notice it but it does not dominate their attention.
Nothing can entirely prevent cheating. But we encourage instructors to take steps to try to reduce cheating before it happens, in part by reducing temptation. Coding trails can help, as can informing students of the similarity checker. Many students are young and may make bad decisions especially when overwhelmed or desperate. Reducing temptation to cheat can not only keep otherwise good students on track, but also reduces the headache instructors must endure to punish detected cheating. We hope coding trails help!