CSC/ECE 517 Fall 2021 - E2165. Fix teammate-review view
Introduction
Expertiza is an open-source education and classroom web-tool founded by the National Science Foundation. Built with Ruby on Rails, it is designed to manage complete courses and students’ work within those courses. Each course can have a collection of instructors and students, though the interaction between instructors and students is minimal. The real emphasis of Expertiza is placed on peer-to-peer interactions, fostering a student-driven learning environment. Courses are comprised of assignments which users complete individually or with a team. Assignments usually encourage or require a team to enforce practicing peer-to-peer interaction.
Assignment
Description
The tasks of the assignment are as follows:
- Distinguish reviews done by a student and for a student, by creating sections in the table
- For instructors, the table will have sections based on the students
- Include a checkbox on edit assignment page that enables/disables visibiity of heatgrid to students
- Fix average column for table (which breaks for some reviews)
- Show a composite score derived from all reviews. Make this code generalized, so other kinds of heatgrid views could use it.
- Changes should work even in anonymized view
Purpose
Motivations
- Enable users to clearly tell which reviews are done by them, and which reviews are done for them.
- Code should be generic so it can be used for different heatgrids as well
Discussion
// TODO: There is no denying that the usability of viewing peer reviews leaves much to be desired. It lacks uniformity across the student and instructor roles, and the view itself has no semblance of order or organization. Viewing a single student’s review is a chore for both instructors and students, as there is no clear separation between reviews. In addition, all reviews are displayed at once, meaning viewing a single review requires scrolling through the page until the desired review is found. Our goal is to take the same data in the current display and present it in a more focused manner that allows a user, in either the instructor or student role, to absorb and process the content in the peer review more efficiently. Accessing, viewing, and understanding a review should be a far more simple task than what it currently is. In addition to the overhaul of the presentation layer, we also strive to drastically increase code reuse in the controller and model layers of the review module, which will in turn create a more uniform experience for both the instructor and student roles.
Scope
// TODO: The scope of this task is limited to enhancing the usability of viewing peer reviews for both students and instructors. It is within our scope to modify the corresponding views for this functionality, as well as the underlying controllers and models as needed. The modifications to the Ruby classes will either be to accommodate changes to the view or to provide a uniform experience for both the instructor and student. As this is more of a user experience task, e.g, changing the way data is displayed to the user, there will be limited modifications to the base functionality of this module. It is not within our scope to change any element of the actual peer review process, such as selecting a topic to review or completing a review of a topic. As a result, we will not be modifying the results of peer reviews; the same peer review data will be present both before and after our task is completed.
Design
Discussion of Resolution
The goal of this project is to optimize code and UI of review module, to make it more readable and user-friendly. To be more specific, our work focuses on the following specific areas:
- Add the checkbox to enable/disable visibility of heatgrid for students
- Modifying UI to clearly denote the reviews given by and for a student for both instructors and students
Mock-Ups
// TODO:
Image 2. The proposed student review report, in default collapsed view.
Text
Image 3. The proposed student review report, in expanded view.
Text
Image 4. Current design of the Instructor's Review Report.
Text
Design Patterns
The implementation team used following design patterns in the solution:
- Pattern 1
- Pattern 2
User Stories
- Use 1
- Use 2
- Use 3
Testing
Much of the testing was done informally during the development phase in the development database. Because the database was converted from the production environment, the development environment provide many opportunities for parallel testing between the view_my_scores (existing) and view_team (new) views.
Some functional tests were completed with RSpec, but not many and probably not enough. This was because the scope of the project was large and the implementation team ran out of time before the deadline.
One situation where the parallel testing of the development environment provided limited value was with multi-round assignments and multi-round rubrics because the database came from production prior to the functionality being available in production. thus, in order to have sufficient tests, we created assignments new assignments, and new reviews in the development environment. The tests were not exhaustive, and probably not along the lines of TDD.
Functional Tests
- ColorMapping module:
- Role Security Testing:
- Char Comment Count Module:
- Calculate Total Review Score:
- Calculate Question Average Score:
UI Tests
UI will be tested manually, but also automatedly with Selenium.
Implementation
New Files
Modified Files
View Models: What, Why How.
Advantages:
- fast: The view_team view generates quickly compared to the view_my_scores. the main reason for this is that the view models only contain and retrieve what is necessary to populate the view.
Javascript, JQuery, CSS tactics in the view_team view
There are 3 main mechanisms that need to be understood in order to modify the view_team view in future development tasks:
The stylesheet grades.scss is used to create the heat grid effect, allowing users to quickly hone in on bad scores:
Text
Text
Users' Access of Report
see associated video for a visual walk-through here
- Instructors: Instructors will access the heat-grid view_team view via the grades/view . A 'heat grid' link appears for each participant.
- Students: Students will access the heat-grid via the student_task/view view, which already lists links available for a participant.
UML & ER diagrams
Below is a UML diagram of the main model classes used in our solution.
Below is a ER diagram of the added model classes used in our solution.
Special Testing
Screenshot of a single round assignment review
Screenshot of a multiround assignment review
Screenshot of a vary-by-rubric review, with reviews for rounds 1 and 3, and blank 2.
Screenshot of a vary-by-rubric review, with reviews for rounds 1 and 2, and blank 3.
Screenshot of a vary-by-rubric review, with reviews for rounds 2 and 3, and blank 1.
Future Enhancements
- The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.
- The project team suggests that an instructor view of the heat grid be created, with lists all peer reviews for all teams stacked vertically on one page.
- The mock-ups above include suggested functionality for expanding all heatgrid rows. This was not implemented due to time limitations.
- Teammate review display have been suppressed such that they will not be displayed. At the end of the project, we realized that teammate reviews are hidden for the current semester, and we don't know how to implement that logic, so we suppressed teammate reviews to be safe.
References
<references/>
// Add more