Table of Contents
One big project I worked on was The Peer Review system. The idea was to have a system where students review each other’s work, thus reducing manpower on the instructor, and increase student participation.
Development of this tool was a team effort.
The Peer Review System was a unique mechanism in the Mirasee Courses space, and I have yet to find a system that functioned as well as that. If you’re curious of how the Peer Review system works — join the Business Ignition Bootcamp to see it in action!
How it works:
During the Homework Due Phase — Student A submits their homework.
Once all homeworks are in, Peer Review starts.
- During the Peer Review Phase — Student A logs in to review Student B’s homework.
- In order to complete this phase, Student A must review 3 peer reviews.
- After Peer Review is finished, Student A should receive 3 peer reviews on their own homework.
- All submissions/peer review is anonymous.
- Student A must not receive their own work to review, or the same review from prior. (Example: Student A should not get Student B‘s homework three times.)
- The Review Pool randomly selects a homework to provide to a student.
- If Student A spends longer than 60 minutes on the review, it goes back into the Review Pool, to avoid ‘locking’ a review for someone who becomes idle within the program.
- The Review Pool’s algorithm ensures all homeworks receive a minimum of 1 review.
- The Review Pool’s algorithm ensures all homeworks receive a maximum of 3 reviews.
- Mathematically, all participating students should receive at least 1 review. The assumption is that at least 80% of students will commit to completing the Peer Review stage.
Our LMS was on a LAMP Stack running WordPress.
Bootstrap library, with HTML/CSS.
We used custom shortcodes that tied in with Gravity Forms to generate a homework/peer review UI.
The algorithm and Peer Review selection was written in PHP as a custom plugin.
The Peer Review system used Gravity Forms to store homework data within the MySQL database.
Within the database, we set up 2 MySQL Tables
- Table 1 stored user IDs, and homework submission IDs.
- Table 2 stored User IDs, homework submission IDs, and peer submissions ID.
There’s another set of code that then pulls who reviewed the student’s work, and displays that back to the student.
For example: Student A wants to see the feedback on THEIR homework.
The code will visit Table 2, and will look for that homework submission ID, and display all the Peer Reviews for that homework submission in a new page.
- You make a ‘homework questions’ & ‘peer review questions’ within gravity forms.
- That creates two form IDs. Example: “Homework Week 1 – ID1” & “Peer Review Week 1 – ID2′.
- When the user submits the homework, it fires off a api call to add that user, that homework submission ID, and the form ID to the SQL table 1.
- When a user visits the Peer Review, they are given two columns.
- Column 1 is generated by the Peer Review code.
- Column 2 is the standard Gravity forms (i.e. Peer Review Week 1 – ID2′.)
- To generate Column 1, the Peer Review code follows ‘the rules’ (listed above), and pulls a student’s homework submission from the database. It then notates who received that homework, the homework submission ID, and the Peer Review ID in Table 2.
- If the user fails to submit – another flag is added to that Peer Review ID, stating that the review failed and to return it back into the Review Pool.
- On submission of the review, Table 2 gets updated.
- Everything is tracked in the Peer Review table. Overall, the code will know that Student A has reviewed the following homeworks –> Student B, Student C, and Student D.
- Afterwards, a separate code displays that student’s results.
Shout out to the Mirasee team for all the bug testing.
The development team:
My work was defining the spec doc, developing much of the design/form management and additional functionality. Krunal Patel was involved in the algorithms and SQL data management. Maureen Lauder was in charge of project management.