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.
Ada Lovelace, now expanded to view their work, started on September 12th, on Thursday (R). The U indicates that Ada re-opened the workspace and began working again on a Sunday.
- Each "-" indicates a develop run, meaning student ran their code in the zyBook.
- Each score, like the “0s, and finally 10”, indicates the student submitted and received that score
- A "," will separate any submissions with no runs between them.
- The time spent, “min:21”, at the end of the trail indicates the student spent 21 minutes working.
- The time spent will timeout after a minute.
- Clicking on any run or submission 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, down to the keystroke. For example, after clicking a score in the coding trail. Alternatively, with their workspace open, click the "History" button.
Move through the history by clicking the forward and back arrows on either side of the timestamp, or click the play button to move through the history at a normal pace, or click anywhere in the timeline to jump to that point in the history. The markers in the history's timeline can also be clicked to jump there.
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 to see edits there.
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 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. 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!