CSC/ECE 517 Fall 2017/E1791. Track the time that students look at the other submissions - logging improvement: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 31: Line 31:


=== View modification ===
=== View modification ===
After we record start_at and end_at time for each piece of review, we need to display time that each reviewer spent for each link. Because the reviewer may save the review and start again in the future, so for each link there might be several entries, we need to sum them together. We will try to modify code in review_mapping/_review_report.html.erb first to modify the view. This framework follows well the "open to extension and close to modification" principle, which makes further changes more feasible without affecting current functions.
After we record start_at and end_at time for each piece of review, we need to display time that each reviewer spent for each link. Because the reviewer may save the review and start again in the future, so for each link there might be several entries, we need to sum them together. We will try to modify code in review_mapping/_review_report.html.erb first to modify the view. This framework follows well the "open to extension and close to modification" principle, which makes further changes more feasible by adding additional view components without affecting current functions.


=== Edge cases ===
=== Edge cases ===

Revision as of 23:04, 15 November 2017

Introduction

The expertiza project takes advantage of peer-review among students to allow them to learn from each other. To track the review time that each student spend on each submitted resources is meaningful to instructors to study and improve the teach experience. However, the time tracking of specific content on these resources is not perfect in the expertiza system. The previous team working on E1705 project has solved part of such problems by tracking the active time of windows opened from the submitted links. But for the submitted files which could be downloaded for local review, there is only a rough approximation solution yet. In this project, our team is going to solve this problem as well as improving previous time tracking methods using mature third-party APIs to record link review time more accurately. To accomplish this goal, here are the tasks needed to be done:

  • Design a database schema for logging the time a reviewer spend on a submission;
  • Design and implement a solution that handles the use case, where students’ submissions are hosted on an external website using third-party APIs, e.g. gem: Octokit for Github use case;
  • Modify Review report (views/review_mapping/_review_report.html.erb) to show the time spent on each submission.

Problem Description

Our team is going to solve the submission review time tracking by attempting to open the downloaded files inside popup windows of the web browser in order to record the time on the client side.

Type of submitted files

For most of our tasks, there are two types of submitted files.

1. One kind is online links, such as github repo or pull request link, youtube video link, expertiza wiki page link, etc

2. The other one includes files such as pdf, txt, doc, images, etc and other download contents.

Database shcema design

For this project, we need to design a database table to store all the time that we need to record for each review submission. We would like to name the table as review_time. For the table, we would use map_id in table response, which used as response_map_id as the primary information. Then we need to record reviewer_id and reviewee_id, file_link for submitted files, as well as time start_at and end_at, then store them in the table.

Time tracking mechanism

For each review, when the reviewer click on one link of the submitted files, we create an entry to the table review_time, we will write a function to record current time to the database.

For how to determine time when the reviewer complete with the opened link, there are different cases. If the reviewer click on save or submit button, close the page, or logout, we need to write to all open entry (without end_at) respect to this review and save current time to end_at. But for how to decide when the review close the opened link is a little complicated. For github and youtube links and txt, pdf, doc, image files, we will open submitted files in views/response/_submitted_files.html.erb so that when the user click on the link, it opens a popup window that shows the submission, record time when it opens and closes. This is done by controlling DOM using jQuery javascript library, and then send back the time records through Ajax. For the other files that need to be downloaded, we can only make an approximation by record the time when the reviewer click on the link until the time he/she enter the reviews.

View modification

After we record start_at and end_at time for each piece of review, we need to display time that each reviewer spent for each link. Because the reviewer may save the review and start again in the future, so for each link there might be several entries, we need to sum them together. We will try to modify code in review_mapping/_review_report.html.erb first to modify the view. This framework follows well the "open to extension and close to modification" principle, which makes further changes more feasible by adding additional view components without affecting current functions.

Edge cases

User shuts down browser during review.
User logs out while review reference windows still open.

Test Plan

UI and Manual test

We will test the following cases during our development

1. When we work the review, if we click on GitHub link, GitHub pull request link, check whether the system record review time correctly.

2. When we work the review, if we click on doc, pdf, image link, check whether system open submitted files in views/response/_submitted_files.html.erb and recore the review time correctly.

3. Check if the reviewer save the process and start again with click on same clink, check whether the system will record all the entry, and on the view page take all entries for one link into account.

Rspec Test

Test of new model and function will be written and tested during project development.

Related Files

1. review_time.rb

2. response_controller.rb

3. response/response.html.erb

4. review_time_controller.rb

5. review_mapping/_review_report.html.erb

6. review_mapping/_review_submissions_time_spent.html.erb

Team

Shijie Li
Wei Sun
Aishwarya Sundararajan
Darshan Balakrishna Bhandari