Overview

We provide the coding trail and history to discourage plagiarism and promote academic integrity. 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 Trail

The coding trail is a compact representation of a student's history with a zyLab. zyLabs display a coding trail of work just below the submit button.

In this AZL example, we can see the details in the coding trail.

• The date the workspace was first active: 2/2
• The day the workspace was first active: F for Friday
• Indicators for develop runs (-) and submissions (score of 0) 
• The length of time they’ve spent on the assignment: min:1

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, now expanded, started on 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, 0, 8, 10”, indicates the student submitted and received that score 
• Each "," separates submissions. 
• The time spent, “min:13”, at the end of the trail indicates the student spent 13 minutes working, and times out after 1 min.
• Clicking on any run or score in the coding trail, like the highlighted “10”, opens their workspace and history to that point.

History

History allows examining learner's work in detail. For example, after clicking a score in the coding trail, or clicking the "History" button, their work can be checked keystroke-by-keystroke.

Move through the history by clicking the forward and back arrows on either side of the timestamp, clicking anywhere in the timeline, or clicking the markers in the history's timeline.

Any of the markers in history can be clicked to jump to that point, from submissions and runs, insertions and deletions, to resets of files.

In a workspace containing multiple edited files, the history for the active file will jump between edits for that file. In order to view the edits in other files, click another file in the file menu and scroll through the timeline or click the arrows to move keystroke-by-keystroke.

Discussion

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.

Coding trails can reduce the temptation among some students to cheat. Of course, we also don't want students feeling like they are being constantly monitored. 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. Informing learners about coding trails, history, and the similarity checker can help. 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!