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.

A legend for what each icon means can be found in the lower left hand corner. 

In a workspace containing multiple edited files, each file will be represented by a different color.

Events on the timeline group into a "pill" to ensure that many actions at the same time remain readable. Pills display the paste icon if any paste events are grouped in, otherwise the most common icon will be displayed. Hover over a pill to see all the events contained within, or zoom with the controls in the bottom right to expand the timeline.

A zoom functionality can be controlled in the lower right for a more in depth view of edits.

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!