CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions: Difference between revisions

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


=== Design pattern ===
=== Design pattern ===
'''Strategy:''' This project, for each review page, deals with different type of links. Javascript is used to track the access time for online links, such as github repo, youtube links, and more. For submitted files, such as txt, jpg, we will time it with  views/response/_submitted_files.html.erb.
'''What is the Strategy Pattern?''' Software design pattern that enables an algorithm's behavior to be selected at runtime. The strategy pattern:
* defines a family of algorithms
* encapsulates each algorithm, and
* makes the algorithm interchangeable within that family
'''Strategy:''' This project, for each review page, deals with different type of links. Javascript is used to track the access time for online links, such as github repo, youtube links, and more.


=== User Stories ===
=== User Stories ===

Revision as of 00:23, 14 April 2020

Abstract

Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

Problem Statement

Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:

  • Time spent of the Expertiza review itself
  • Time spent looking at external links
  • Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:

  1. Time spent on an Expertiza review must be tracked
  2. Time spent on external links and resources should be tracked/estimated
  3. Overall time spent on the review should be displayed in a "user friendly manner"

Previous Implementations

Thus far, Expertiza does not have the aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

  1. E1705 identified how to track the active time of windows opened from the submitted links.
  2. E1791 provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
  3. E1872 tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. (Wiki)
  4. E1989 tried to solve this by building off of E1791. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

Proposed Solution

In review of previous iterations of this project, it was found that project E1791 would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages. To achieve our goals outlined in the Problem Statement, the following changes need to be made:

The time spent on the Expertiza assignment review page needs to be tracked.
  • Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
  • After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project E1791.
The time spent viewing the external links/downloadable files needs to be tracked or estimated
  • Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
  • There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.
The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
  • Due to complaints about the use of a tabular method that was implemented in E1791, stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

Design pattern

What is the Strategy Pattern? Software design pattern that enables an algorithm's behavior to be selected at runtime. The strategy pattern:

  • defines a family of algorithms
  • encapsulates each algorithm, and
  • makes the algorithm interchangeable within that family

Strategy: This project, for each review page, deals with different type of links. Javascript is used to track the access time for online links, such as github repo, youtube links, and more.

User Stories

The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

Student

Students will be interacting with the implementation when filling out a review. A similar workflow from E1791 Fall '19 is used, however small edits were made to better suite our proposed implementation. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.

Image: 50 pixels
Image: 50 pixels

Instructor

Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from E1791 Fall '19 will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

Image: 50 pixels
Image: 50 pixels

Files to be Added and Edited

  1. Create a controller to handle the start/end times of the files viewed by the user in => controllers/submission_viewing_events_controller.rb
  2. Create a datatable to handle log start and end time for each link/file. Schema for this table is provided in the below section.
  3. Edit and add views to display results in a user-friendly manner. Edits to views should be defined in both the wiki and through modular commits on the repository in order to clearly distinguish code changes, an issue that prevented E1989 from pushing to base.

Database Schema

Our datatable will be named submission_viewing_events. The attributes and their descriptions are provided in the below spreadsheet. There is some uncertainty in how the time will be tracked separately for viewing downloadable files vs viewing the Expertiza assignment review page. Final form of the data table with this tracking feature will be elaborate on in future submissions.


Below shows the database relationship with other tables. submission_viewing_events will be touching response_maps. The boxes demonstrate which fields correspond to each other.

Testing Plan

Rspec

Automatic testing will be achieved using Rspec. We will test the changes made to controllers/submission_viewing_events_controller.rb to ensure proper test converge. Test cases are to be written in a meaningful and elegant manner, adhering to the following rules:

  • Test incoming query messages by making assertions for what they send back
  • Test incoming command messages by making assertions about direct public side effects
  • Do not test private methods
  • Do not test outgoing query messages
  • Expect to send outgoing command messages

Manual Testing

1. Log in as instructor

2. Assign a review to a student

3. Log in as student

4. Complete the dummy review in 5 minutes

5. Log in as instructor

6. Navigate to review report tab

7. Verify that the review was completed ~5 minutes.