Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-12-09T16:16:54Z

Mjwitte: /* Implementation */

== Introduction ==
[https://expertiza.ncsu.edu/ Expertiza] is an open-source education and classroom web-tool founded by the [http://www.nsf.gov/ 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* [https://en.wikipedia.org/wiki/Code_refactoring Refactoring] grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
[[File:Current Student.PNG|border|center|alt=The current student view.|The current review display for students.]]
'''Image 1. The current review display for students.'''

Image 1, above, illustrates the current design of the Student Review Report. We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Heatgrid_studen_condensed.png|border|center|alt=The proposed condensed student display.|The proposed condensed student display.]]
'''Image 2. The proposed student review report, in default collapsed view.'''

The main UI overhaul will occur in displaying the actual reviews. Image 2 illustrates the design for the student review report. To combat the length of the current review display, we have chosen to collapse all data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden. Because all of the comments are not available for all reviews in a single screen display, the rightmost field displays the number of comment fields for each criterion which have 10 or more characters. The purpose of this field is to provide the user a quick and effective manner to spark interest into whether or not the the criterion contains meaningful comments.

The colored background of the cells are based on a color scale relative to the score. These colors are added to the design into order to quickly spark interest to the users, allowing them to pick out the essential information without having to iterate through all the data.

[[File:Heatgrid_student_expanded.png|border|center|alt=The proposed expanded student display.|The proposed expanded student display.]]
'''Image 3. The proposed student review report, in expanded view.'''

Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments.

It is important to note a important data organization difference between the existing design and the proposed design; The existing review report design groups reponses by the reviewer who created them, while the proposed review report design groups responses by the criteria. This new way of grouping responses groups like with like, allow the viewing users to see all scores and comments pertaining to one criterion at once.

[[File:Current Instructor.PNG|border|center|alt=The current instructor view.|The current review display for instructors.]]
'''Image 4. Current design of the Instructor's Review Report.'''

The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. The student view will also be made available to the instructor via a link in the 'grades/view' page, allowing to see this updated scores report for a requested participant.

=== Design Patterns ===
The implementation team used following design patterns in the solution:

* '''[https://en.wikipedia.org/wiki/Strategy_pattern Strategy Design Pattern]''': Using the strategy design pattern, we can display two versions of the review page according to which role is currently logged in. For instance, in the student role’s review page, they will see a different layout than the instructor role's review page, but the actual content is more or less the same.

* '''[https://en.wikipedia.org/wiki/Module_pattern Module Design Pattern]''': Using the module design pattern, source code can be organized into components that accomplish a particular function. In JavaScript files, we use anonymous functions for responsiveness on client side via JavaScript and JQuery. We also developed a view model module to contain the necessary information needed to render the review content on the page.

* '''[https://en.wikipedia.org/wiki/Facade_pattern Facade Design Pattern]''': The façade design pattern provides a unified, high-level interface to a set of interfaces in a subsystem which is intended to make the subsystem easier to use.In our implementation, the student role's review page, grades, commands, and feedback are gathered from three different controllers, and they are accessed from within the review controller and displayed in one review page. The client need only interact with the façade, i.e., the review controller.

=== Use Cases ===

* '''View Received Scores and Reviews for Specified Assignment, Grouped by Criteria''': Accessed from the Student's landing page for a particular assignment. Allows a student to see scores, grouped by criteria, for self's assignment, as well as meta reviews and author reviews.

=== Controller Testing ===

Controller testing will be centered around the proposed views which will replace the "view" and "view_my_scores" view in the grades controller. The Functional testing section covers much of the modular functionality that make up the proposed views. It is not anticipated that the testing team will perform significant controller tests.

=== Functional Tests ===

* ColorMapping module: The generation of the heatgrid requires mapping review scores to color groups. Testing of the method's functionality requires various fixture collections which vary is size, range, max, min, and number of duplicates.

* Role Security Testing: In order to DRY the code, and make it maximally orthogonal, the intention is to reuse code where possible. To re-use code across students and participants will require security and role checks to confirm the session user has access to view the requested information. To test this functionality sufficiently will require testing as admin, instructor with access, instructor without access, student, non-participant, participant, teammember, non-teammember, etc.

* Char Comment Count Module: The generation of the "# of comments with chars > x" result will require the execution of a module. this module will be tested with various collections of comments which vary in size, range, length, and content.

* TeamReview(assignment,team): This is a controller helper method, which will be called to generate the peer review scores for a particular team (note: no author nor meta reviews.) A collection of review scores and comments will be generated. This will be tested for empty, null, many round, single round, many reviewer, single reviewer scores.

* ParticpantReview(participant): This is a controller helper method, which will be called to generate the review scores for a particular participant. Collections generated will include reviews, author-reviews, meta-reviews for a participant. this will be tested for empty, null, many round, single round, many reviewer, single reviewer scores.

* RubricQuestion(questionnaire): This is a controller helper method, which will be called by many views in the solution. It will return a list of criteria for each found of a questionnaire or rubric. this will be tested for empty, null, many-round, single round rubrics.

=== UI Tests ===
UI will be tested manually, but also automatedly with [https://en.wikipedia.org/wiki/Selenium_(software) Selenium]. Compliance and validation will be checked via an online tool.

== Implementation ==
Three models were added to retrieve useful data: <code>vm_question_response</code>, <code>vm_question_response_ row</code>, and <code>vm_question_response_score_cell</code>. They comprise a view model module which is used to centralize the data and content that is rendered to the page. The <code>vm_question_response</code> has multiple <code>vm_question_response_ row</code>'s, which has multiple <code>vm_question_response_score_cell</code>'s.

The <code>vm_question_response_score_cell</code> is just a data holder. It represents a single cell in the table view and holds the score it should display and it's appropriate color code, which is used by the stylesheet. The <code>vm_question_response_ row</code> represents a single row in the table view. It holds the question text, the score cells for that row, and the number of comments with more than 10 characters. It is also responsible for calculating the average score across all reviews for that particular question. The <code>vm_question_response</code> can be thought of as the controller for the table. It holds all the <code>vm_question_response_ row</code>'s in the table and is responsible for calculating various values, such as the total and average scores for each review.

Two core actions were added in <code>grades_controller</code>: <code>view_team</code> and <code>view_reviewer</code>.

The action <code>view_team</code> is a substitution of the old action <code>view_my_score</code>, which is used by the student to view all the reviews. This action first gathers the current user, the assignment being viewed, the user's team, and the rounds for the current assignment. It then iterates over the questionnaires, or the reviews, and creates a new view model, which is responsible for rendering the content, populating the data on the view model as needed.

The action <code>view_reviewer</code> can be used to view the details of all reviews. This action compiles the questions and their respective scores into a hash.

Two major views were added: <code>view_team.html.erb</code> and <code>view_reviewer.html.erb</code>. In <code>view_team.html.erb</code>, HTML table tags combined with javascript are used to generate a table that displays all the scores from reviews, categorized by question. The <code>stylesheet grades.scss</code> is used to create the heat grid effect, allowing users to quickly hone in on bad scores:

[[File:Detailedreview2.png|border|center|alt=uml.|UML]]

By clicking the question row, full question text and the scores from each review will be displayed:

[[File:Rsz_screenshot_2015-12-04_235548.png|border|center|alt=uml.|UML]]

In <code>review_reviewer.html.erb</code>, detailed reviews will be displayed:

[[File:detailedreview.png|border|center|alt=uml.|UML]]

==Future Enhancements==
* The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.
* Open Question: how to meet functionality of the various action links in the instructor view, such as: email student, delete score, change score, etc.

==References==
<references/>
https://expertiza.ncsu.edu/
http://www.nsf.gov/
https://en.wikipedia.org/wiki/Code_refactoring
https://en.wikipedia.org/wiki/Flyweight_pattern
https://en.wikipedia.org/wiki/Strategy_pattern
https://en.wikipedia.org/wiki/Front_Controller_pattern
https://en.wikipedia.org/wiki/Module_pattern
https://en.wikipedia.org/wiki/Iterator_pattern
https://en.wikipedia.org/wiki/Selenium_(software)

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-12-09T16:15:57Z

Mjwitte: /* Implementation */

== Introduction ==
[https://expertiza.ncsu.edu/ Expertiza] is an open-source education and classroom web-tool founded by the [http://www.nsf.gov/ 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* [https://en.wikipedia.org/wiki/Code_refactoring Refactoring] grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
[[File:Current Student.PNG|border|center|alt=The current student view.|The current review display for students.]]
'''Image 1. The current review display for students.'''

Image 1, above, illustrates the current design of the Student Review Report. We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Heatgrid_studen_condensed.png|border|center|alt=The proposed condensed student display.|The proposed condensed student display.]]
'''Image 2. The proposed student review report, in default collapsed view.'''

The main UI overhaul will occur in displaying the actual reviews. Image 2 illustrates the design for the student review report. To combat the length of the current review display, we have chosen to collapse all data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden. Because all of the comments are not available for all reviews in a single screen display, the rightmost field displays the number of comment fields for each criterion which have 10 or more characters. The purpose of this field is to provide the user a quick and effective manner to spark interest into whether or not the the criterion contains meaningful comments.

The colored background of the cells are based on a color scale relative to the score. These colors are added to the design into order to quickly spark interest to the users, allowing them to pick out the essential information without having to iterate through all the data.

[[File:Heatgrid_student_expanded.png|border|center|alt=The proposed expanded student display.|The proposed expanded student display.]]
'''Image 3. The proposed student review report, in expanded view.'''

Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments.

It is important to note a important data organization difference between the existing design and the proposed design; The existing review report design groups reponses by the reviewer who created them, while the proposed review report design groups responses by the criteria. This new way of grouping responses groups like with like, allow the viewing users to see all scores and comments pertaining to one criterion at once.

[[File:Current Instructor.PNG|border|center|alt=The current instructor view.|The current review display for instructors.]]
'''Image 4. Current design of the Instructor's Review Report.'''

The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. The student view will also be made available to the instructor via a link in the 'grades/view' page, allowing to see this updated scores report for a requested participant.

=== Design Patterns ===
The implementation team used following design patterns in the solution:

* '''[https://en.wikipedia.org/wiki/Strategy_pattern Strategy Design Pattern]''': Using the strategy design pattern, we can display two versions of the review page according to which role is currently logged in. For instance, in the student role’s review page, they will see a different layout than the instructor role's review page, but the actual content is more or less the same.

* '''[https://en.wikipedia.org/wiki/Module_pattern Module Design Pattern]''': Using the module design pattern, source code can be organized into components that accomplish a particular function. In JavaScript files, we use anonymous functions for responsiveness on client side via JavaScript and JQuery. We also developed a view model module to contain the necessary information needed to render the review content on the page.

* '''[https://en.wikipedia.org/wiki/Facade_pattern Facade Design Pattern]''': The façade design pattern provides a unified, high-level interface to a set of interfaces in a subsystem which is intended to make the subsystem easier to use.In our implementation, the student role's review page, grades, commands, and feedback are gathered from three different controllers, and they are accessed from within the review controller and displayed in one review page. The client need only interact with the façade, i.e., the review controller.

=== Use Cases ===

* '''View Received Scores and Reviews for Specified Assignment, Grouped by Criteria''': Accessed from the Student's landing page for a particular assignment. Allows a student to see scores, grouped by criteria, for self's assignment, as well as meta reviews and author reviews.

=== Controller Testing ===

Controller testing will be centered around the proposed views which will replace the "view" and "view_my_scores" view in the grades controller. The Functional testing section covers much of the modular functionality that make up the proposed views. It is not anticipated that the testing team will perform significant controller tests.

=== Functional Tests ===

* ColorMapping module: The generation of the heatgrid requires mapping review scores to color groups. Testing of the method's functionality requires various fixture collections which vary is size, range, max, min, and number of duplicates.

* Role Security Testing: In order to DRY the code, and make it maximally orthogonal, the intention is to reuse code where possible. To re-use code across students and participants will require security and role checks to confirm the session user has access to view the requested information. To test this functionality sufficiently will require testing as admin, instructor with access, instructor without access, student, non-participant, participant, teammember, non-teammember, etc.

* Char Comment Count Module: The generation of the "# of comments with chars > x" result will require the execution of a module. this module will be tested with various collections of comments which vary in size, range, length, and content.

* TeamReview(assignment,team): This is a controller helper method, which will be called to generate the peer review scores for a particular team (note: no author nor meta reviews.) A collection of review scores and comments will be generated. This will be tested for empty, null, many round, single round, many reviewer, single reviewer scores.

* ParticpantReview(participant): This is a controller helper method, which will be called to generate the review scores for a particular participant. Collections generated will include reviews, author-reviews, meta-reviews for a participant. this will be tested for empty, null, many round, single round, many reviewer, single reviewer scores.

* RubricQuestion(questionnaire): This is a controller helper method, which will be called by many views in the solution. It will return a list of criteria for each found of a questionnaire or rubric. this will be tested for empty, null, many-round, single round rubrics.

=== UI Tests ===
UI will be tested manually, but also automatedly with [https://en.wikipedia.org/wiki/Selenium_(software) Selenium]. Compliance and validation will be checked via an online tool.

== Implementation ==
Three models were added to retrieve useful data: <code>vm_question_response</code>, <code>vm_question_response_ row</code>, and <code>vm_question_response_score_cell</code>. They comprise a view model module which is used to centralize the data and content that is rendered to the page. The <code>vm_question_response</code> has multiple <code>vm_question_response_ row</code>'s, which has multiple <code>vm_question_response_score_cell</code>'s.

The <code>vm_question_response_score_cell</code> is just a data holder. It represents a single cell in the table view and holds the score it should display and it's appropriate color code, which is used by the stylesheet. The <code>vm_question_response_ row</code> represents a single row in the table view. It holds the question text, the score cells for that row, and the number of comments with more than 10 characters. It is also responsible for calculating the average score across all reviews for that particular question. The <code>vm_question_response</code> can be thought of as the controller for the table. It holds all the <code>vm_question_response_ row</code>'s in the table and is responsible for calculating various values, such as the total and average scores for each review.

Two core actions were added in <code>grades_controller</code>: <code>view_team</code> and <code>view_reviewer</code>.

The action <code>view_team</code> is a substitution of the old action <code>view_my_score</code>, which is used by the student to view all the reviews. This action first gathers the current user, the assignment being viewed, the user's team, and the rounds for the current assignment. It then iterates over the questionnaires, or the reviews, and creates a new view model, which is responsible for rendering the content, populating the data on the view model as needed.

The action <code>view_reviewer</code> can be used to view the details of all reviews. This action compiles the questions and their respective scores into a hash.

Two major views were added: <code>view_team.html.erb</code> and <code>view_reviewer.html.erb</code>. In <code>view_team.html.erb</code>, HTML table tags combined with javascript are used to generate a table that displays all the scores from reviews, categorized by question. The <code>stylesheet grades.scss</code> is used to create the heat grid effect, allowing users to quickly hone in on bad scores:

[[File:Detailedreview2.png|border|center|alt=uml.|UML]]

By clicking the question row, full question text and the scores from each review will be displayed:

[[File:Rsz_screenshot_2015-12-04_235548.png|border|center|alt=uml.|UML

In <code>review_reviewer.html.erb</code>, detailed reviews will be displayed:

[[File:detailedreview.png|border|center|alt=uml.|UML]]

==Future Enhancements==
* The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.
* Open Question: how to meet functionality of the various action links in the instructor view, such as: email student, delete score, change score, etc.

==References==
<references/>
https://expertiza.ncsu.edu/
http://www.nsf.gov/
https://en.wikipedia.org/wiki/Code_refactoring
https://en.wikipedia.org/wiki/Flyweight_pattern
https://en.wikipedia.org/wiki/Strategy_pattern
https://en.wikipedia.org/wiki/Front_Controller_pattern
https://en.wikipedia.org/wiki/Module_pattern
https://en.wikipedia.org/wiki/Iterator_pattern
https://en.wikipedia.org/wiki/Selenium_(software)

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-12-09T15:54:38Z

Mjwitte: /* Implementation */

== Introduction ==
[https://expertiza.ncsu.edu/ Expertiza] is an open-source education and classroom web-tool founded by the [http://www.nsf.gov/ 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* [https://en.wikipedia.org/wiki/Code_refactoring Refactoring] grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
[[File:Current Student.PNG|border|center|alt=The current student view.|The current review display for students.]]
'''Image 1. The current review display for students.'''

Image 1, above, illustrates the current design of the Student Review Report. We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Heatgrid_studen_condensed.png|border|center|alt=The proposed condensed student display.|The proposed condensed student display.]]
'''Image 2. The proposed student review report, in default collapsed view.'''

The main UI overhaul will occur in displaying the actual reviews. Image 2 illustrates the design for the student review report. To combat the length of the current review display, we have chosen to collapse all data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden. Because all of the comments are not available for all reviews in a single screen display, the rightmost field displays the number of comment fields for each criterion which have 10 or more characters. The purpose of this field is to provide the user a quick and effective manner to spark interest into whether or not the the criterion contains meaningful comments.

The colored background of the cells are based on a color scale relative to the score. These colors are added to the design into order to quickly spark interest to the users, allowing them to pick out the essential information without having to iterate through all the data.

[[File:Heatgrid_student_expanded.png|border|center|alt=The proposed expanded student display.|The proposed expanded student display.]]
'''Image 3. The proposed student review report, in expanded view.'''

Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments.

It is important to note a important data organization difference between the existing design and the proposed design; The existing review report design groups reponses by the reviewer who created them, while the proposed review report design groups responses by the criteria. This new way of grouping responses groups like with like, allow the viewing users to see all scores and comments pertaining to one criterion at once.

[[File:Current Instructor.PNG|border|center|alt=The current instructor view.|The current review display for instructors.]]
'''Image 4. Current design of the Instructor's Review Report.'''

The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. The student view will also be made available to the instructor via a link in the 'grades/view' page, allowing to see this updated scores report for a requested participant.

=== Design Patterns ===
The implementation team used following design patterns in the solution:

* '''[https://en.wikipedia.org/wiki/Strategy_pattern Strategy Design Pattern]''': Using the strategy design pattern, we can display two versions of the review page according to which role is currently logged in. For instance, in the student role’s review page, they will see a different layout than the instructor role's review page, but the actual content is more or less the same.

* '''[https://en.wikipedia.org/wiki/Module_pattern Module Design Pattern]''': Using the module design pattern, source code can be organized into components that accomplish a particular function. In JavaScript files, we use anonymous functions for responsiveness on client side via JavaScript and JQuery. We also developed a view model module to contain the necessary information needed to render the review content on the page.

* '''[https://en.wikipedia.org/wiki/Facade_pattern Facade Design Pattern]''': The façade design pattern provides a unified, high-level interface to a set of interfaces in a subsystem which is intended to make the subsystem easier to use.In our implementation, the student role's review page, grades, commands, and feedback are gathered from three different controllers, and they are accessed from within the review controller and displayed in one review page. The client need only interact with the façade, i.e., the review controller.

=== Use Cases ===

* '''View Received Scores and Reviews for Specified Assignment, Grouped by Criteria''': Accessed from the Student's landing page for a particular assignment. Allows a student to see scores, grouped by criteria, for self's assignment, as well as meta reviews and author reviews.

=== Controller Testing ===

Controller testing will be centered around the proposed views which will replace the "view" and "view_my_scores" view in the grades controller. The Functional testing section covers much of the modular functionality that make up the proposed views. It is not anticipated that the testing team will perform significant controller tests.

=== Functional Tests ===

* ColorMapping module: The generation of the heatgrid requires mapping review scores to color groups. Testing of the method's functionality requires various fixture collections which vary is size, range, max, min, and number of duplicates.

* Role Security Testing: In order to DRY the code, and make it maximally orthogonal, the intention is to reuse code where possible. To re-use code across students and participants will require security and role checks to confirm the session user has access to view the requested information. To test this functionality sufficiently will require testing as admin, instructor with access, instructor without access, student, non-participant, participant, teammember, non-teammember, etc.

* Char Comment Count Module: The generation of the "# of comments with chars > x" result will require the execution of a module. this module will be tested with various collections of comments which vary in size, range, length, and content.

* TeamReview(assignment,team): This is a controller helper method, which will be called to generate the peer review scores for a particular team (note: no author nor meta reviews.) A collection of review scores and comments will be generated. This will be tested for empty, null, many round, single round, many reviewer, single reviewer scores.

* ParticpantReview(participant): This is a controller helper method, which will be called to generate the review scores for a particular participant. Collections generated will include reviews, author-reviews, meta-reviews for a participant. this will be tested for empty, null, many round, single round, many reviewer, single reviewer scores.

* RubricQuestion(questionnaire): This is a controller helper method, which will be called by many views in the solution. It will return a list of criteria for each found of a questionnaire or rubric. this will be tested for empty, null, many-round, single round rubrics.

=== UI Tests ===
UI will be tested manually, but also automatedly with [https://en.wikipedia.org/wiki/Selenium_(software) Selenium]. Compliance and validation will be checked via an online tool.

== Implementation ==
Three models were added to retrieve useful data: <code>vm_question_response</code>, <code>vm_question_response_ row</code>, and <code>vm_question_response_score_cell</code>. They comprise a view model module which is used to centralize the data and content that is rendered to the page.

Two core actions were added in <code>grades_controller</code>. The action <code>view_team</code> is a substitution of the old action <code>view_my_score</code>, which is used by the student to view all the reviews. The action <code>view_reviewer</code> can be used to view the details of all reviews.

<pre>
def view_reviewer
@participant = AssignmentParticipant.find(params[:id])
@team_id = TeamsUser.team_id(@participant.parent_id, @participant.user_id)
return if (current_role_name!="Instructor" && redirect_when_disallowed )
@assignment = @participant.assignment
@questions = {} # A hash containing all the questions in all the questionnaires used in this assignment
questionnaires = @assignment.questionnaires
questionnaires.each do |questionnaire|
round = AssignmentQuestionnaire.where(assignment_id: @assignment.id, questionnaire_id:questionnaire.id).first.used_in_round
if(round!=nil)
questionnaire_symbol = (questionnaire.symbol.to_s+round.to_s).to_sym
else
questionnaire_symbol = questionnaire.symbol
end
@questions[questionnaire_symbol] = questionnaire.questions
end
#@pscore has the newest versions of response for each response map, and only one for each response map (unless it is vary rubric by round)
pscore = @participant.scores(@questions)
# make_chart
@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.get_current_stage(@topic_id)
# calculate_all_penalties(@assignment.id)
@rscore = pscore[:review]
end

def view_team
#get participant, team, questionnaires for assignment.
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.parent_id, @participant.user_id)
@team = Team.find(@team_id)
return if (current_role_name!="Instructor" && redirect_when_disallowed )
questionnaires = @assignment.questionnaires_with_questions
@vmlist = []
#get the rounds for the assignment. if >1, add the review questionnaire n-1 times.
#this will insure a separate html table appears for each round
@round = 1
@rounds = @assignment.rounds_of_reviews
repeat_questionnaire = nil
questionnaires.each { |questionnaire|
if questionnaire.type == 'ReviewQuestionnaire'
repeat_questionnaire = questionnaire
@round = @assignment.rounds_of_reviews
end
}

if @round >1 && !@assignment.varying_rubrics_by_round?
(2...(@round)).reverse_each do |x|
questionnaires << (repeat_questionnaire)
end
end
#loop through each questionnaire, and populate the view model for all data necessary
#to render the html tables.
questionnaires.each { |questionnaire|
if @assignment.varying_rubrics_by_round?
@round = AssignmentQuestionnaire.find_by_assignment_id_and_questionnaire_id(@assignment.id, questionnaire.id).used_in_round
end
vm = VmQuestionResponse.new(questionnaire,@round,@rounds)
questions = questionnaire.questions
vm.addQuestions(questions)
vm.addTeamMembers(@team)
vm.addReviewers(@participant,@team,@assignment.varying_rubrics_by_round?)
vm.get_number_of_comments_greater_than_10_words()
#if a multi-round assignment, decrement for each review questionnaire,
#to ensure the proper round responses are retrieved.
if questionnaire.type == "ReviewQuestionnaire"
@round = @round -1
end
@vmlist << vm
}
@current_role_name = current_role_name
@answers = Answer.where(response_id: 64882)
end
</pre>

Two major views were added: <code>view_team.html.erb</code> and <code>view_reviewer.html.erb</code>. In <code>view_team.html.erb</code>, HTML table tags combined with javascript are used to generate a table that displays all the scores from reviews, categorized by question. The <code>stylesheet grades.scss</code> is added for the heat grid effect:

[[File:Detailedreview2.png|border|center|alt=uml.|UML]]

By clicking the question row, full question text and the scores from each review will be displayed:

[[File:Rsz_screenshot_2015-12-04_235548.png|border|center|alt=uml.|UML]]

In <code>review_reviewer.html.erb</code>, detailed reviews will be displayed:

[[File:detailedreview.png|border|center|alt=uml.|UML]]

==Future Enhancements==
* The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.
* Open Question: how to meet functionality of the various action links in the instructor view, such as: email student, delete score, change score, etc.

==References==
<references/>
https://expertiza.ncsu.edu/
http://www.nsf.gov/
https://en.wikipedia.org/wiki/Code_refactoring
https://en.wikipedia.org/wiki/Flyweight_pattern
https://en.wikipedia.org/wiki/Strategy_pattern
https://en.wikipedia.org/wiki/Front_Controller_pattern
https://en.wikipedia.org/wiki/Module_pattern
https://en.wikipedia.org/wiki/Iterator_pattern
https://en.wikipedia.org/wiki/Selenium_(software)

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-12-09T15:53:59Z

Mjwitte: /* Implementation */

== Introduction ==
[https://expertiza.ncsu.edu/ Expertiza] is an open-source education and classroom web-tool founded by the [http://www.nsf.gov/ 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* [https://en.wikipedia.org/wiki/Code_refactoring Refactoring] grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
[[File:Current Student.PNG|border|center|alt=The current student view.|The current review display for students.]]
'''Image 1. The current review display for students.'''

Image 1, above, illustrates the current design of the Student Review Report. We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Heatgrid_studen_condensed.png|border|center|alt=The proposed condensed student display.|The proposed condensed student display.]]
'''Image 2. The proposed student review report, in default collapsed view.'''

The main UI overhaul will occur in displaying the actual reviews. Image 2 illustrates the design for the student review report. To combat the length of the current review display, we have chosen to collapse all data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden. Because all of the comments are not available for all reviews in a single screen display, the rightmost field displays the number of comment fields for each criterion which have 10 or more characters. The purpose of this field is to provide the user a quick and effective manner to spark interest into whether or not the the criterion contains meaningful comments.

The colored background of the cells are based on a color scale relative to the score. These colors are added to the design into order to quickly spark interest to the users, allowing them to pick out the essential information without having to iterate through all the data.

[[File:Heatgrid_student_expanded.png|border|center|alt=The proposed expanded student display.|The proposed expanded student display.]]
'''Image 3. The proposed student review report, in expanded view.'''

Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments.

It is important to note a important data organization difference between the existing design and the proposed design; The existing review report design groups reponses by the reviewer who created them, while the proposed review report design groups responses by the criteria. This new way of grouping responses groups like with like, allow the viewing users to see all scores and comments pertaining to one criterion at once.

[[File:Current Instructor.PNG|border|center|alt=The current instructor view.|The current review display for instructors.]]
'''Image 4. Current design of the Instructor's Review Report.'''

The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. The student view will also be made available to the instructor via a link in the 'grades/view' page, allowing to see this updated scores report for a requested participant.

=== Design Patterns ===
The implementation team used following design patterns in the solution:

* '''[https://en.wikipedia.org/wiki/Strategy_pattern Strategy Design Pattern]''': Using the strategy design pattern, we can display two versions of the review page according to which role is currently logged in. For instance, in the student role’s review page, they will see a different layout than the instructor role's review page, but the actual content is more or less the same.

* '''[https://en.wikipedia.org/wiki/Module_pattern Module Design Pattern]''': Using the module design pattern, source code can be organized into components that accomplish a particular function. In JavaScript files, we use anonymous functions for responsiveness on client side via JavaScript and JQuery. We also developed a view model module to contain the necessary information needed to render the review content on the page.

* '''[https://en.wikipedia.org/wiki/Facade_pattern Facade Design Pattern]''': The façade design pattern provides a unified, high-level interface to a set of interfaces in a subsystem which is intended to make the subsystem easier to use.In our implementation, the student role's review page, grades, commands, and feedback are gathered from three different controllers, and they are accessed from within the review controller and displayed in one review page. The client need only interact with the façade, i.e., the review controller.

=== Use Cases ===

* '''View Received Scores and Reviews for Specified Assignment, Grouped by Criteria''': Accessed from the Student's landing page for a particular assignment. Allows a student to see scores, grouped by criteria, for self's assignment, as well as meta reviews and author reviews.

=== Controller Testing ===

Controller testing will be centered around the proposed views which will replace the "view" and "view_my_scores" view in the grades controller. The Functional testing section covers much of the modular functionality that make up the proposed views. It is not anticipated that the testing team will perform significant controller tests.

=== Functional Tests ===

* ColorMapping module: The generation of the heatgrid requires mapping review scores to color groups. Testing of the method's functionality requires various fixture collections which vary is size, range, max, min, and number of duplicates.

* Role Security Testing: In order to DRY the code, and make it maximally orthogonal, the intention is to reuse code where possible. To re-use code across students and participants will require security and role checks to confirm the session user has access to view the requested information. To test this functionality sufficiently will require testing as admin, instructor with access, instructor without access, student, non-participant, participant, teammember, non-teammember, etc.

* Char Comment Count Module: The generation of the "# of comments with chars > x" result will require the execution of a module. this module will be tested with various collections of comments which vary in size, range, length, and content.

* TeamReview(assignment,team): This is a controller helper method, which will be called to generate the peer review scores for a particular team (note: no author nor meta reviews.) A collection of review scores and comments will be generated. This will be tested for empty, null, many round, single round, many reviewer, single reviewer scores.

* ParticpantReview(participant): This is a controller helper method, which will be called to generate the review scores for a particular participant. Collections generated will include reviews, author-reviews, meta-reviews for a participant. this will be tested for empty, null, many round, single round, many reviewer, single reviewer scores.

* RubricQuestion(questionnaire): This is a controller helper method, which will be called by many views in the solution. It will return a list of criteria for each found of a questionnaire or rubric. this will be tested for empty, null, many-round, single round rubrics.

=== UI Tests ===
UI will be tested manually, but also automatedly with [https://en.wikipedia.org/wiki/Selenium_(software) Selenium]. Compliance and validation will be checked via an online tool.

== Implementation ==
Three models were added to retrieve useful data: <code>vm_question_response</code>, <code>vm_question_response_ row</code>, and <code>vm_question_response_score_cell</code>. They comprise a view model module which is used to centralize the data and content that is rendered to the page.

Two core actions were added in <code>grades_controller</code>. The action <code>view_team</code> is a substitution of the old action <code>view_my_score</code>, which is used by the student to view all the reviews. The action <code>view_reviewer</code> can be used to view the details of all reviews.

<pre>
def view_reviewer
@participant = AssignmentParticipant.find(params[:id])
@team_id = TeamsUser.team_id(@participant.parent_id, @participant.user_id)
return if (current_role_name!="Instructor" && redirect_when_disallowed )
@assignment = @participant.assignment
@questions = {} # A hash containing all the questions in all the questionnaires used in this assignment
questionnaires = @assignment.questionnaires
questionnaires.each do |questionnaire|
round = AssignmentQuestionnaire.where(assignment_id: @assignment.id, questionnaire_id:questionnaire.id).first.used_in_round
if(round!=nil)
questionnaire_symbol = (questionnaire.symbol.to_s+round.to_s).to_sym
else
questionnaire_symbol = questionnaire.symbol
end
@questions[questionnaire_symbol] = questionnaire.questions
end
#@pscore has the newest versions of response for each response map, and only one for each response map (unless it is vary rubric by round)
pscore = @participant.scores(@questions)
# make_chart
@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.get_current_stage(@topic_id)
# calculate_all_penalties(@assignment.id)
@rscore = pscore[:review]
end

def view_team
#get participant, team, questionnaires for assignment.
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.parent_id, @participant.user_id)
@team = Team.find(@team_id)
return if (current_role_name!="Instructor" && redirect_when_disallowed )
questionnaires = @assignment.questionnaires_with_questions
@vmlist = []
#get the rounds for the assignment. if >1, add the review questionnaire n-1 times.
#this will insure a separate html table appears for each round
@round = 1
@rounds = @assignment.rounds_of_reviews
repeat_questionnaire = nil
questionnaires.each { |questionnaire|
if questionnaire.type == 'ReviewQuestionnaire'
repeat_questionnaire = questionnaire
@round = @assignment.rounds_of_reviews
end
}

if @round >1 && !@assignment.varying_rubrics_by_round?
(2...(@round)).reverse_each do |x|
questionnaires << (repeat_questionnaire)
end
end
#loop through each questionnaire, and populate the view model for all data necessary
#to render the html tables.
questionnaires.each { |questionnaire|
if @assignment.varying_rubrics_by_round?
@round = AssignmentQuestionnaire.find_by_assignment_id_and_questionnaire_id(@assignment.id, questionnaire.id).used_in_round
end
vm = VmQuestionResponse.new(questionnaire,@round,@rounds)
questions = questionnaire.questions
vm.addQuestions(questions)
vm.addTeamMembers(@team)
vm.addReviewers(@participant,@team,@assignment.varying_rubrics_by_round?)
vm.get_number_of_comments_greater_than_10_words()
#if a multi-round assignment, decrement for each review questionnaire,
#to ensure the proper round responses are retrieved.
if questionnaire.type == "ReviewQuestionnaire"
@round = @round -1
end
@vmlist << vm
}
@current_role_name = current_role_name
@answers = Answer.where(response_id: 64882)
end
</pre>

Two major views were added: <code>view_team.html.erb</code> and <code>view_reviewer.html.erb</code>. In <code>view_team.html.erb</code>, HTML table tags combined with javascript are used to generate a table that displays all the scores from reviews, categorized by question. The <code>stylesheet grades.scss</code> is added for the heat grid effect:

[[File:Detailedreview2.png|border|center|alt=uml.|UML]]

By clicking the question row, full question text and its score will be displayed:

[[File:Rsz_screenshot_2015-12-04_235548.png|border|center|alt=uml.|UML]]

In <code>review_reviewer.html.erb</code>, detailed reviews will be displayed:

[[File:detailedreview.png|border|center|alt=uml.|UML]]

==Future Enhancements==
* The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.
* Open Question: how to meet functionality of the various action links in the instructor view, such as: email student, delete score, change score, etc.

==References==
<references/>
https://expertiza.ncsu.edu/
http://www.nsf.gov/
https://en.wikipedia.org/wiki/Code_refactoring
https://en.wikipedia.org/wiki/Flyweight_pattern
https://en.wikipedia.org/wiki/Strategy_pattern
https://en.wikipedia.org/wiki/Front_Controller_pattern
https://en.wikipedia.org/wiki/Module_pattern
https://en.wikipedia.org/wiki/Iterator_pattern
https://en.wikipedia.org/wiki/Selenium_(software)

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-12-09T15:53:22Z

Mjwitte: /* Implementation */

== Introduction ==
[https://expertiza.ncsu.edu/ Expertiza] is an open-source education and classroom web-tool founded by the [http://www.nsf.gov/ 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* [https://en.wikipedia.org/wiki/Code_refactoring Refactoring] grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
[[File:Current Student.PNG|border|center|alt=The current student view.|The current review display for students.]]
'''Image 1. The current review display for students.'''

Image 1, above, illustrates the current design of the Student Review Report. We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Heatgrid_studen_condensed.png|border|center|alt=The proposed condensed student display.|The proposed condensed student display.]]
'''Image 2. The proposed student review report, in default collapsed view.'''

The main UI overhaul will occur in displaying the actual reviews. Image 2 illustrates the design for the student review report. To combat the length of the current review display, we have chosen to collapse all data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden. Because all of the comments are not available for all reviews in a single screen display, the rightmost field displays the number of comment fields for each criterion which have 10 or more characters. The purpose of this field is to provide the user a quick and effective manner to spark interest into whether or not the the criterion contains meaningful comments.

The colored background of the cells are based on a color scale relative to the score. These colors are added to the design into order to quickly spark interest to the users, allowing them to pick out the essential information without having to iterate through all the data.

[[File:Heatgrid_student_expanded.png|border|center|alt=The proposed expanded student display.|The proposed expanded student display.]]
'''Image 3. The proposed student review report, in expanded view.'''

Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments.

It is important to note a important data organization difference between the existing design and the proposed design; The existing review report design groups reponses by the reviewer who created them, while the proposed review report design groups responses by the criteria. This new way of grouping responses groups like with like, allow the viewing users to see all scores and comments pertaining to one criterion at once.

[[File:Current Instructor.PNG|border|center|alt=The current instructor view.|The current review display for instructors.]]
'''Image 4. Current design of the Instructor's Review Report.'''

The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. The student view will also be made available to the instructor via a link in the 'grades/view' page, allowing to see this updated scores report for a requested participant.

=== Design Patterns ===
The implementation team used following design patterns in the solution:

* '''[https://en.wikipedia.org/wiki/Strategy_pattern Strategy Design Pattern]''': Using the strategy design pattern, we can display two versions of the review page according to which role is currently logged in. For instance, in the student role’s review page, they will see a different layout than the instructor role's review page, but the actual content is more or less the same.

* '''[https://en.wikipedia.org/wiki/Module_pattern Module Design Pattern]''': Using the module design pattern, source code can be organized into components that accomplish a particular function. In JavaScript files, we use anonymous functions for responsiveness on client side via JavaScript and JQuery. We also developed a view model module to contain the necessary information needed to render the review content on the page.

* '''[https://en.wikipedia.org/wiki/Facade_pattern Facade Design Pattern]''': The façade design pattern provides a unified, high-level interface to a set of interfaces in a subsystem which is intended to make the subsystem easier to use.In our implementation, the student role's review page, grades, commands, and feedback are gathered from three different controllers, and they are accessed from within the review controller and displayed in one review page. The client need only interact with the façade, i.e., the review controller.

=== Use Cases ===

* '''View Received Scores and Reviews for Specified Assignment, Grouped by Criteria''': Accessed from the Student's landing page for a particular assignment. Allows a student to see scores, grouped by criteria, for self's assignment, as well as meta reviews and author reviews.

=== Controller Testing ===

Controller testing will be centered around the proposed views which will replace the "view" and "view_my_scores" view in the grades controller. The Functional testing section covers much of the modular functionality that make up the proposed views. It is not anticipated that the testing team will perform significant controller tests.

=== Functional Tests ===

* ColorMapping module: The generation of the heatgrid requires mapping review scores to color groups. Testing of the method's functionality requires various fixture collections which vary is size, range, max, min, and number of duplicates.

* Role Security Testing: In order to DRY the code, and make it maximally orthogonal, the intention is to reuse code where possible. To re-use code across students and participants will require security and role checks to confirm the session user has access to view the requested information. To test this functionality sufficiently will require testing as admin, instructor with access, instructor without access, student, non-participant, participant, teammember, non-teammember, etc.

* Char Comment Count Module: The generation of the "# of comments with chars > x" result will require the execution of a module. this module will be tested with various collections of comments which vary in size, range, length, and content.

* TeamReview(assignment,team): This is a controller helper method, which will be called to generate the peer review scores for a particular team (note: no author nor meta reviews.) A collection of review scores and comments will be generated. This will be tested for empty, null, many round, single round, many reviewer, single reviewer scores.

* ParticpantReview(participant): This is a controller helper method, which will be called to generate the review scores for a particular participant. Collections generated will include reviews, author-reviews, meta-reviews for a participant. this will be tested for empty, null, many round, single round, many reviewer, single reviewer scores.

* RubricQuestion(questionnaire): This is a controller helper method, which will be called by many views in the solution. It will return a list of criteria for each found of a questionnaire or rubric. this will be tested for empty, null, many-round, single round rubrics.

=== UI Tests ===
UI will be tested manually, but also automatedly with [https://en.wikipedia.org/wiki/Selenium_(software) Selenium]. Compliance and validation will be checked via an online tool.

== Implementation ==
Three models were added to retrieve useful data: <code>vm_question_response</code>, <code>vm_question_response_ row</code>, and <code>vm_question_response_score_cell</code>. They comprise a view model module which is used to centralize the data and content that is rendered to the page.

Two core actions were added in <code>grades_controller</code>. The action <code>view_team</code> is a substitution of the old action <code>view_my_score</code>, which is used by the student to view all the reviews. The action <code>view_reviewer</code> can be used to view the details of all reviews.

<pre>
def view_reviewer
@participant = AssignmentParticipant.find(params[:id])
@team_id = TeamsUser.team_id(@participant.parent_id, @participant.user_id)
return if (current_role_name!="Instructor" && redirect_when_disallowed )
@assignment = @participant.assignment
@questions = {} # A hash containing all the questions in all the questionnaires used in this assignment
questionnaires = @assignment.questionnaires
questionnaires.each do |questionnaire|
round = AssignmentQuestionnaire.where(assignment_id: @assignment.id, questionnaire_id:questionnaire.id).first.used_in_round
if(round!=nil)
questionnaire_symbol = (questionnaire.symbol.to_s+round.to_s).to_sym
else
questionnaire_symbol = questionnaire.symbol
end
@questions[questionnaire_symbol] = questionnaire.questions
end
#@pscore has the newest versions of response for each response map, and only one for each response map (unless it is vary rubric by round)
pscore = @participant.scores(@questions)
# make_chart
@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.get_current_stage(@topic_id)
# calculate_all_penalties(@assignment.id)
@rscore = pscore[:review]
end

def view_team
#get participant, team, questionnaires for assignment.
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.parent_id, @participant.user_id)
@team = Team.find(@team_id)
return if (current_role_name!="Instructor" && redirect_when_disallowed )
questionnaires = @assignment.questionnaires_with_questions
@vmlist = []
#get the rounds for the assignment. if >1, add the review questionnaire n-1 times.
#this will insure a separate html table appears for each round
@round = 1
@rounds = @assignment.rounds_of_reviews
repeat_questionnaire = nil
questionnaires.each { |questionnaire|
if questionnaire.type == 'ReviewQuestionnaire'
repeat_questionnaire = questionnaire
@round = @assignment.rounds_of_reviews
end
}

if @round >1 && !@assignment.varying_rubrics_by_round?
(2...(@round)).reverse_each do |x|
questionnaires << (repeat_questionnaire)
end
end
#loop through each questionnaire, and populate the view model for all data necessary
#to render the html tables.
questionnaires.each { |questionnaire|
if @assignment.varying_rubrics_by_round?
@round = AssignmentQuestionnaire.find_by_assignment_id_and_questionnaire_id(@assignment.id, questionnaire.id).used_in_round
end
vm = VmQuestionResponse.new(questionnaire,@round,@rounds)
questions = questionnaire.questions
vm.addQuestions(questions)
vm.addTeamMembers(@team)
vm.addReviewers(@participant,@team,@assignment.varying_rubrics_by_round?)
vm.get_number_of_comments_greater_than_10_words()
#if a multi-round assignment, decrement for each review questionnaire,
#to ensure the proper round responses are retrieved.
if questionnaire.type == "ReviewQuestionnaire"
@round = @round -1
end
@vmlist << vm
}
@current_role_name = current_role_name
@answers = Answer.where(response_id: 64882)
end
</pre>

Two major views were added: <code>view_team.html.erb</code> and <code>view_reviewer.html.erb</code>. In view_team.html.erb</code>, HTML table tags combined with javascript are used to generate a table that displays all the scores from reviews, categorized by question. The <code>stylesheet grades.scss</code> is added for the heat grid effect:

[[File:Detailedreview2.png|border|center|alt=uml.|UML]]

By clicking the question row, full question text and its score will be displayed:

[[File:Rsz_screenshot_2015-12-04_235548.png|border|center|alt=uml.|UML]]

In <code>review_reviewer.html.erb</code>, detailed reviews will be displayed:

[[File:detailedreview.png|border|center|alt=uml.|UML]]

==Future Enhancements==
* The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.
* Open Question: how to meet functionality of the various action links in the instructor view, such as: email student, delete score, change score, etc.

==References==
<references/>
https://expertiza.ncsu.edu/
http://www.nsf.gov/
https://en.wikipedia.org/wiki/Code_refactoring
https://en.wikipedia.org/wiki/Flyweight_pattern
https://en.wikipedia.org/wiki/Strategy_pattern
https://en.wikipedia.org/wiki/Front_Controller_pattern
https://en.wikipedia.org/wiki/Module_pattern
https://en.wikipedia.org/wiki/Iterator_pattern
https://en.wikipedia.org/wiki/Selenium_(software)

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-12-09T15:43:35Z

Mjwitte: /* Design Patterns */

== Introduction ==
[https://expertiza.ncsu.edu/ Expertiza] is an open-source education and classroom web-tool founded by the [http://www.nsf.gov/ 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* [https://en.wikipedia.org/wiki/Code_refactoring Refactoring] grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
[[File:Current Student.PNG|border|center|alt=The current student view.|The current review display for students.]]
'''Image 1. The current review display for students.'''

Image 1, above, illustrates the current design of the Student Review Report. We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Heatgrid_studen_condensed.png|border|center|alt=The proposed condensed student display.|The proposed condensed student display.]]
'''Image 2. The proposed student review report, in default collapsed view.'''

The main UI overhaul will occur in displaying the actual reviews. Image 2 illustrates the design for the student review report. To combat the length of the current review display, we have chosen to collapse all data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden. Because all of the comments are not available for all reviews in a single screen display, the rightmost field displays the number of comment fields for each criterion which have 10 or more characters. The purpose of this field is to provide the user a quick and effective manner to spark interest into whether or not the the criterion contains meaningful comments.

The colored background of the cells are based on a color scale relative to the score. These colors are added to the design into order to quickly spark interest to the users, allowing them to pick out the essential information without having to iterate through all the data.

[[File:Heatgrid_student_expanded.png|border|center|alt=The proposed expanded student display.|The proposed expanded student display.]]
'''Image 3. The proposed student review report, in expanded view.'''

Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments.

It is important to note a important data organization difference between the existing design and the proposed design; The existing review report design groups reponses by the reviewer who created them, while the proposed review report design groups responses by the criteria. This new way of grouping responses groups like with like, allow the viewing users to see all scores and comments pertaining to one criterion at once.

[[File:Current Instructor.PNG|border|center|alt=The current instructor view.|The current review display for instructors.]]
'''Image 4. Current design of the Instructor's Review Report.'''

The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. The student view will also be made available to the instructor via a link in the 'grades/view' page, allowing to see this updated scores report for a requested participant.

=== Design Patterns ===
The implementation team used following design patterns in the solution:

* '''[https://en.wikipedia.org/wiki/Strategy_pattern Strategy Design Pattern]''': Using the strategy design pattern, we can display two versions of the review page according to which role is currently logged in. For instance, in the student role’s review page, they will see a different layout than the instructor role's review page, but the actual content is more or less the same.

* '''[https://en.wikipedia.org/wiki/Module_pattern Module Design Pattern]''': Using the module design pattern, source code can be organized into components that accomplish a particular function. In JavaScript files, we use anonymous functions for responsiveness on client side via JavaScript and JQuery. We also developed a view model module to contain the necessary information needed to render the review content on the page.

* '''[https://en.wikipedia.org/wiki/Facade_pattern Facade Design Pattern]''': The façade design pattern provides a unified, high-level interface to a set of interfaces in a subsystem which is intended to make the subsystem easier to use.In our implementation, the student role's review page, grades, commands, and feedback are gathered from three different controllers, and they are accessed from within the review controller and displayed in one review page. The client need only interact with the façade, i.e., the review controller.

=== Use Cases ===

* '''View Received Scores and Reviews for Specified Assignment, Grouped by Criteria''': Accessed from the Student's landing page for a particular assignment. Allows a student to see scores, grouped by criteria, for self's assignment, as well as meta reviews and author reviews.

=== Controller Testing ===

Controller testing will be centered around the proposed views which will replace the "view" and "view_my_scores" view in the grades controller. The Functional testing section covers much of the modular functionality that make up the proposed views. It is not anticipated that the testing team will perform significant controller tests.

=== Functional Tests ===

* ColorMapping module: The generation of the heatgrid requires mapping review scores to color groups. Testing of the method's functionality requires various fixture collections which vary is size, range, max, min, and number of duplicates.

* Role Security Testing: In order to DRY the code, and make it maximally orthogonal, the intention is to reuse code where possible. To re-use code across students and participants will require security and role checks to confirm the session user has access to view the requested information. To test this functionality sufficiently will require testing as admin, instructor with access, instructor without access, student, non-participant, participant, teammember, non-teammember, etc.

* Char Comment Count Module: The generation of the "# of comments with chars > x" result will require the execution of a module. this module will be tested with various collections of comments which vary in size, range, length, and content.

* TeamReview(assignment,team): This is a controller helper method, which will be called to generate the peer review scores for a particular team (note: no author nor meta reviews.) A collection of review scores and comments will be generated. This will be tested for empty, null, many round, single round, many reviewer, single reviewer scores.

* ParticpantReview(participant): This is a controller helper method, which will be called to generate the review scores for a particular participant. Collections generated will include reviews, author-reviews, meta-reviews for a participant. this will be tested for empty, null, many round, single round, many reviewer, single reviewer scores.

* RubricQuestion(questionnaire): This is a controller helper method, which will be called by many views in the solution. It will return a list of criteria for each found of a questionnaire or rubric. this will be tested for empty, null, many-round, single round rubrics.

=== UI Tests ===
UI will be tested manually, but also automatedly with [https://en.wikipedia.org/wiki/Selenium_(software) Selenium]. Compliance and validation will be checked via an online tool.

== Implementation ==


Three model were added to retrieve useful data: vm_question_response, vm_question_response_ row and vm_question_response_score_cell, they are used for the convenience to display reviews as table.



Two core actions were added in grades_controller: view_team, this action is a substitution of the old action view_my_score, which is used by the student to view all the reviews; view_reviewer, which can be used to view the detail of all review.


<pre>
def view_reviewer
@participant = AssignmentParticipant.find(params[:id])
@team_id = TeamsUser.team_id(@participant.parent_id, @participant.user_id)
return if (current_role_name!="Instructor" && redirect_when_disallowed )
@assignment = @participant.assignment
@questions = {} # A hash containing all the questions in all the questionnaires used in this assignment
questionnaires = @assignment.questionnaires
questionnaires.each do |questionnaire|
round = AssignmentQuestionnaire.where(assignment_id: @assignment.id, questionnaire_id:questionnaire.id).first.used_in_round
if(round!=nil)
questionnaire_symbol = (questionnaire.symbol.to_s+round.to_s).to_sym
else
questionnaire_symbol = questionnaire.symbol
end
@questions[questionnaire_symbol] = questionnaire.questions
end
#@pscore has the newest versions of response for each response map, and only one for each response map (unless it is vary rubric by round)
pscore = @participant.scores(@questions)
# make_chart
@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.get_current_stage(@topic_id)
# calculate_all_penalties(@assignment.id)
@rscore = pscore[:review]
end

def view_team
#get participant, team, questionnaires for assignment.
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.parent_id, @participant.user_id)
@team = Team.find(@team_id)
return if (current_role_name!="Instructor" && redirect_when_disallowed )
questionnaires = @assignment.questionnaires_with_questions
@vmlist = []
#get the rounds for the assignment. if >1, add the review questionnaire n-1 times.
#this will insure a separate html table appears for each round
@round = 1
@rounds = @assignment.rounds_of_reviews
repeat_questionnaire = nil
questionnaires.each { |questionnaire|
if questionnaire.type == 'ReviewQuestionnaire'
repeat_questionnaire = questionnaire
@round = @assignment.rounds_of_reviews
end
}

if @round >1 && !@assignment.varying_rubrics_by_round?
(2...(@round)).reverse_each do |x|
questionnaires << (repeat_questionnaire)
end
end
#loop through each questionnaire, and populate the view model for all data necessary
#to render the html tables.
questionnaires.each { |questionnaire|
if @assignment.varying_rubrics_by_round?
@round = AssignmentQuestionnaire.find_by_assignment_id_and_questionnaire_id(@assignment.id, questionnaire.id).used_in_round
end
vm = VmQuestionResponse.new(questionnaire,@round,@rounds)
questions = questionnaire.questions
vm.addQuestions(questions)
vm.addTeamMembers(@team)
vm.addReviewers(@participant,@team,@assignment.varying_rubrics_by_round?)
vm.get_number_of_comments_greater_than_10_words()
#if a multi-round assignment, decrement for each review questionnaire,
#to ensure the proper round responses are retrieved.
if questionnaire.type == "ReviewQuestionnaire"
@round = @round -1
end
@vmlist << vm
}
@current_role_name = current_role_name
@answers = Answer.where(response_id: 64882)
end
</pre>

Two major view were added: view_team.html.erb and view_reviewer.html.erb. In view_team.html.erb, html table tags combined with javascript are used to generate a table that display all the scores from reviews categorized by different question. grades.scss is added for the heat grid effect:

[[File:Detailedreview2.png|border|center|alt=uml.|UML]]

By clicking the question row, detailed question and its score will be displayed:

[[File:Rsz_screenshot_2015-12-04_235548.png|border|center|alt=uml.|UML]]

In review_reviewer.html.erb, detailed review will be displayed:

[[File:detailedreview.png|border|center|alt=uml.|UML]]

==Future Enhancements==
* The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.
* Open Question: how to meet functionality of the various action links in the instructor view, such as: email student, delete score, change score, etc.

==References==
<references/>
https://expertiza.ncsu.edu/
http://www.nsf.gov/
https://en.wikipedia.org/wiki/Code_refactoring
https://en.wikipedia.org/wiki/Flyweight_pattern
https://en.wikipedia.org/wiki/Strategy_pattern
https://en.wikipedia.org/wiki/Front_Controller_pattern
https://en.wikipedia.org/wiki/Module_pattern
https://en.wikipedia.org/wiki/Iterator_pattern
https://en.wikipedia.org/wiki/Selenium_(software)

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-13T18:02:31Z

Mjwitte: /* Mock-Ups */

== 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* Refactoring grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
[[File:Current Student.PNG|border|center|alt=The current student view.|The current review display for students.]]

We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Heatgrid_studen_condensed.png|border|center|alt=The proposed condensed student display.|The proposed condensed student display.]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden.

[[File:Heatgrid_student_expanded.png|border|center|alt=The proposed expanded student display.|The proposed expanded student display.]]

Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

[[File:Current Instructor.PNG|border|center|alt=The current instructor view.|The current review display for instructors.]]

The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

[[File:Heatgrid_instructor_condensed.png|border|center|alt=The proposed condensed instructor display.|The proposed condensed instructor display.]]

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

View All Team Scores and Reviews for Specified Assignment, as Instructor
View Received Scores and Reviews for Specified Assignment, Grouped by Criteria, as Student (self)
View Received Scores and Reviews for Specified Assignment, Grouped by Reviewer, as Student (self)

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.

* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

=== Functional Tests ===

* ColorMapping module: The generation of the heatgrid requires mapping review scores to color groups. Testing of the method's functionality requires various fixture collections which vary is size, range, max, min, and number of duplications.

* Role Security Testing: In order to DRY the code, and make it maximally orthogonal, the intention is to reuse code where possible. To re-use code across students and participants will require security and role checks to confirm the session user has access to view the requested information. To test this functionality sufficiently will require testing as admin, instructor with access, instructor without access, student, non-participant, participant, teammember, non-teammeber, etc.

* Char Comment Count Module: The generation of the "# of comments with chars > x" result will require the execution of a module. this module will be tested with various collections of comments which vary in size, range, length, and content.

* TeamReview(assignment,team): This is a controller helpful method, which will be called to generate the peer review scores for a particular team (note: no author nor meta reviews.) A collection of review scores and comments will be generated. This will be tested for empty, null, many round, single round, many reviewer, single reviewer scores.

* ParticpantReview(participant): This is a controller helper method, which will be called to generate the review scores for a particular participant. Collections generated will include reviews, author-reviews, meta-reviews for a participant. this will be tested for empty, null, many round, single round, many reviewer, single reviewer scores.

* RubricQuestion(questionnaire): This is a controller helper method, which will be called by many views in the solution. It will return a list of criteria for each found of a questionnaire or rubric. this will be tested for empty, null, many-round, single round rubrics.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb app/viewsgrades/views.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

We should note that there will be no changes or impact on the database or underlying model classes.

==Future Enhancements==
* The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.
* Open Question: how to meet functionality of the various action links in the instructor view, such as: email student, delete score, change score, etc.
==References==
{{reflist}}

File:Current Instructor.PNG

2015-11-13T18:01:33Z

Mjwitte: uploaded a new version of "File:Current Instructor.PNG"

File:Current Student.PNG

2015-11-13T18:01:10Z

Mjwitte: uploaded a new version of "File:Current Student.PNG"

File:Heatgrid instructor condensed.png

2015-11-13T18:00:49Z

Mjwitte: uploaded a new version of "File:Heatgrid instructor condensed.png"

File:Heatgrid studen condensed.png

2015-11-13T18:00:27Z

Mjwitte: uploaded a new version of "File:Heatgrid studen condensed.png"

File:Heatgrid student expanded.png

2015-11-13T17:59:08Z

Mjwitte: uploaded a new version of "File:Heatgrid student expanded.png"

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-13T16:37:35Z

Mjwitte: /* Mock-Ups */

== 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* Refactoring grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
[[File:Current Student.PNG|800px|center|alt=The current student view.|The current review display for students.]]

We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Heatgrid_studen_condensed.png|800px|center|alt=The proposed condensed student display.|The proposed condensed student display.]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden.

[[File:Heatgrid_student_expanded.png|800px|center|alt=The proposed expanded student display.|The proposed expanded student display.]]

Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

[[File:Current Instructor.PNG|800px|center|alt=The current instructor view.|The current review display for instructors.]]

The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

[[File:Heatgrid_instructor_condensed.png|800px|center|alt=The proposed condensed instructor display.|The proposed condensed instructor display.]]

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

View All Team Scores and Reviews for Specified Assignment, as Instructor
View Received Scores and Reviews for Specified Assignment, Grouped by Criteria, as Student (self)
View Received Scores and Reviews for Specified Assignment, Grouped by Reviewer, as Student (self)

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb app/viewsgrades/views.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

We should note that there will be no changes or impact on the database or underlying model classes.

==Future Enhancements==
* The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-13T16:37:07Z

Mjwitte: /* Mock-Ups */

== 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* Refactoring grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
[[File:Current Student.PNG|800px|center|alt=The current student view.|The current review display for students.]]

We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Heatgrid_studen_condensed.png|thumb|center|alt=The proposed condensed student display.|The proposed condensed student display.]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden.

[[File:Heatgrid_student_expanded.png|thumb|center|alt=The proposed expanded student display.|The proposed expanded student display.]]

Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

[[File:Current Instructor.PNG|thumb|center|alt=The current instructor view.|The current review display for instructors.]]

The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

[[File:Heatgrid_instructor_condensed.png|thumb|center|alt=The proposed condensed instructor display.|The proposed condensed instructor display.]]

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

View All Team Scores and Reviews for Specified Assignment, as Instructor
View Received Scores and Reviews for Specified Assignment, Grouped by Criteria, as Student (self)
View Received Scores and Reviews for Specified Assignment, Grouped by Reviewer, as Student (self)

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb app/viewsgrades/views.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

We should note that there will be no changes or impact on the database or underlying model classes.

==Future Enhancements==
* The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-13T16:36:57Z

Mjwitte: /* Mock-Ups */

== 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* Refactoring grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
[[File:Current Student.PNG|600px|center|alt=The current student view.|The current review display for students.]]

We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Heatgrid_studen_condensed.png|thumb|center|alt=The proposed condensed student display.|The proposed condensed student display.]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden.

[[File:Heatgrid_student_expanded.png|thumb|center|alt=The proposed expanded student display.|The proposed expanded student display.]]

Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

[[File:Current Instructor.PNG|thumb|center|alt=The current instructor view.|The current review display for instructors.]]

The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

[[File:Heatgrid_instructor_condensed.png|thumb|center|alt=The proposed condensed instructor display.|The proposed condensed instructor display.]]

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

View All Team Scores and Reviews for Specified Assignment, as Instructor
View Received Scores and Reviews for Specified Assignment, Grouped by Criteria, as Student (self)
View Received Scores and Reviews for Specified Assignment, Grouped by Reviewer, as Student (self)

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb app/viewsgrades/views.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

We should note that there will be no changes or impact on the database or underlying model classes.

==Future Enhancements==
* The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-13T16:34:22Z

Mjwitte: /* Mock-Ups */

== 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* Refactoring grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
[[File:Current Student.PNG|thumb|center|alt=The current student view.|The current review display for students.]]

We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Heatgrid_studen_condensed.png|thumb|center|alt=The proposed condensed student display.|The proposed condensed student display.]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden.

[[File:Heatgrid_student_expanded.png|thumb|center|alt=The proposed expanded student display.|The proposed expanded student display.]]

Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

[[File:Current Instructor.PNG|thumb|center|alt=The current instructor view.|The current review display for instructors.]]

The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

[[File:Heatgrid_instructor_condensed.png|thumb|center|alt=The proposed condensed instructor display.|The proposed condensed instructor display.]]

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

View All Team Scores and Reviews for Specified Assignment, as Instructor
View Received Scores and Reviews for Specified Assignment, Grouped by Criteria, as Student (self)
View Received Scores and Reviews for Specified Assignment, Grouped by Reviewer, as Student (self)

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb app/viewsgrades/views.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

We should note that there will be no changes or impact on the database or underlying model classes.

==Future Enhancements==
* The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-13T16:33:16Z

Mjwitte: /* Mock-Ups */

== 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* Refactoring grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
[[File:Current Student.PNG|thumb|alt=The current student view.|The current review display for students.]]

We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Heatgrid_studen_condensed.png|thumb|alt=The proposed condensed student display.|The proposed condensed student display.]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden.

[[File:Heatgrid_student_expanded.png|thumb|alt=The proposed expanded student display.|The proposed expanded student display.]]

Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

[[File:Current Instructor.PNG|thumb|alt=The current instructor view.|The current review display for instructors.]]

The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

[[File:Heatgrid_instructor_condensed.png|thumb|alt=The proposed condensed instructor display.|The proposed condensed instructor display.]]

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

View All Team Scores and Reviews for Specified Assignment, as Instructor
View Received Scores and Reviews for Specified Assignment, Grouped by Criteria, as Student (self)
View Received Scores and Reviews for Specified Assignment, Grouped by Reviewer, as Student (self)

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb app/viewsgrades/views.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

We should note that there will be no changes or impact on the database or underlying model classes.

==Future Enhancements==
* The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-13T16:30:29Z

Mjwitte: /* Mock-Ups */

== 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* Refactoring grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
[[File:Current Student.PNG|thumb]]

We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Heatgrid_studen_condensed.png|thumb]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden.

[[File:Heatgrid_student_expanded.png|thumb]]

Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

[[File:Current Instructor.PNG|thumb]]

The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

[[File:Heatgrid_instructor_condensed.png|thumb]]

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

View All Team Scores and Reviews for Specified Assignment, as Instructor
View Received Scores and Reviews for Specified Assignment, Grouped by Criteria, as Student (self)
View Received Scores and Reviews for Specified Assignment, Grouped by Reviewer, as Student (self)

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb app/viewsgrades/views.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

We should note that there will be no changes or impact on the database or underlying model classes.

==Future Enhancements==
* The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-13T16:29:42Z

Mjwitte: /* Mock-Ups */

== 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* Refactoring grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
[[File:Current Student.PNG|border]]

We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Heatgrid_studen_condensed.png|thumb]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden.

[[File:Heatgrid_student_expanded.png|thumb]]

Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

[[File:Current Instructor.PNG|thumb]]

The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

[[File:Heatgrid_instructor_condensed.png|thumb]]

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

View All Team Scores and Reviews for Specified Assignment, as Instructor
View Received Scores and Reviews for Specified Assignment, Grouped by Criteria, as Student (self)
View Received Scores and Reviews for Specified Assignment, Grouped by Reviewer, as Student (self)

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb app/viewsgrades/views.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

We should note that there will be no changes or impact on the database or underlying model classes.

==Future Enhancements==
* The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-13T16:23:23Z

Mjwitte: /* Mock-Ups */

== 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* Refactoring grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
[[File:Current Student.PNG|border]]

We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Heatgrid_studen_condensed.png|border]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden.

[[File:Heatgrid_student_expanded.png|border]]

Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

[[File:Current Instructor.PNG|border]]

The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

[[File:Heatgrid_instructor_condensed.png|border]]

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

View All Team Scores and Reviews for Specified Assignment, as Instructor
View Received Scores and Reviews for Specified Assignment, Grouped by Criteria, as Student (self)
View Received Scores and Reviews for Specified Assignment, Grouped by Reviewer, as Student (self)

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb app/viewsgrades/views.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

We should note that there will be no changes or impact on the database or underlying model classes.

==Future Enhancements==
* The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-13T16:22:41Z

Mjwitte: /* Mock-Ups */

== 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* Refactoring grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
[[File:Current Student.PNG|border]]

We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Heatgrid_studen_condensed.png|border]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden.

[[File:Heatgrid_student_expanded.png|border]]

Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

[[File:current_instructor.png|border]]

The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

[[File:Heatgrid_instructor_condensed.png|border]]

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

View All Team Scores and Reviews for Specified Assignment, as Instructor
View Received Scores and Reviews for Specified Assignment, Grouped by Criteria, as Student (self)
View Received Scores and Reviews for Specified Assignment, Grouped by Reviewer, as Student (self)

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb app/viewsgrades/views.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

We should note that there will be no changes or impact on the database or underlying model classes.

==Future Enhancements==
* The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-13T16:22:12Z

Mjwitte: /* Mock-Ups */

== 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* Refactoring grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
[[File:Current Student.PNG|border]]

We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Heatgrid_student_condensed.png|border]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden.

[[File:Heatgrid_student_expanded.png|border]]

Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

[[File:current_instructor.png|border]]

The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

[[File:Heatgrid_instructor_condensed.png|border]]

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

View All Team Scores and Reviews for Specified Assignment, as Instructor
View Received Scores and Reviews for Specified Assignment, Grouped by Criteria, as Student (self)
View Received Scores and Reviews for Specified Assignment, Grouped by Reviewer, as Student (self)

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb app/viewsgrades/views.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

We should note that there will be no changes or impact on the database or underlying model classes.

==Future Enhancements==
* The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-13T16:21:16Z

Mjwitte:

== 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* Refactoring grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
[[File:Current Student.png|border]]

We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Heatgrid_student_condensed.png|border]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden.

[[File:Heatgrid_student_expanded.png|border]]

Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

[[File:current_instructor.png|border]]

The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

[[File:Heatgrid_instructor_condensed.png|border]]

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

View All Team Scores and Reviews for Specified Assignment, as Instructor
View Received Scores and Reviews for Specified Assignment, Grouped by Criteria, as Student (self)
View Received Scores and Reviews for Specified Assignment, Grouped by Reviewer, as Student (self)

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb app/viewsgrades/views.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

We should note that there will be no changes or impact on the database or underlying model classes.

==Future Enhancements==
* The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-13T16:20:29Z

Mjwitte:

== 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* Refactoring grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
[[File:current_student.png|border]]

We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Heatgrid_student_condensed.png|border]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden.

[[File:Heatgrid_student_expanded.png|border]]

Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

[[File:current_instructor.png|border]]

The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

[[File:Heatgrid_instructor_condensed.png|border]]

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

View All Team Scores and Reviews for Specified Assignment, as Instructor
View Received Scores and Reviews for Specified Assignment, Grouped by Criteria, as Student (self)
View Received Scores and Reviews for Specified Assignment, Grouped by Reviewer, as Student (self)

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb app/viewsgrades/views.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

We should note that there will be no changes or impact on the database or underlying model classes.

==Future Enhancements==
* The project team may attempt to implement sorting of the lists and tables in in both the instructor and student review pages.

==References==
{{reflist}}

File:Heatgrid student expanded.png

2015-11-13T16:17:53Z

Mjwitte:

File:Heatgrid studen condensed.png

2015-11-13T16:17:36Z

Mjwitte:

File:Heatgrid instructor condensed.png

2015-11-13T16:17:22Z

Mjwitte:

File:Current Student.PNG

2015-11-13T16:17:04Z

Mjwitte:

File:Current Instructor.PNG

2015-11-13T16:16:45Z

Mjwitte:

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-13T05:27:43Z

Mjwitte: /* Mock-Ups */

== 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* Refactoring grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Final Review Mockup.png|border]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden. Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. This way a student can compare comments and scores for a single question across all reviews. Clicking the column header for a specific review will display all the comments left by that reviewer. A student can use this functionality to view the entirety of a single review, including scores and comments. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

Note that the specific interaction schemes outlined thus far, including the screenshots, have applied to the student role. The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.
* '''Expand All Reviews''' : Reviews may be initially condensed in the UI by default. This use case covers the ability for a viewing user to expand expand all reviews in the UI at once, with one click of the mouse.
* '''Condense each Review''' : The ability to expand and condense each review of the scores page.
* '''View Review Detail: (As Student)''' : The ability to see review detail (questions, scores answers), of each review, as student.
* '''View Review Detail: (As Instructor)''' : The ability to see review detail (questions, scores answers), of each review, as instructor.
* '''View Reviews, with Versions in a comparable manner''' : The ability to see different versions or rounds of each review, either side by side, or tab from one to the other.
* '''View Reviews, Grouped by Review''' : The ability to group responses by reviewer (current functionality.)
* '''View Reviews, Grouped by Question''' : The ability to group responses by question/criteria.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

We should note that there will be no changes or impact on the database or underlying model classes.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-13T05:19:40Z

Mjwitte: /* Implementation */

== 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* Refactoring grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Final Review Mockup.png|border]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden. Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. Clicking the column header for a specific review will display all the comments left by that reviewer. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

Note that the specific interaction schemes outlined thus far, including the screenshots, have applied to the student role. The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.
* '''Expand All Reviews''' : Reviews may be initially condensed in the UI by default. This use case covers the ability for a viewing user to expand expand all reviews in the UI at once, with one click of the mouse.
* '''Condense each Review''' : The ability to expand and condense each review of the scores page.
* '''View Review Detail: (As Student)''' : The ability to see review detail (questions, scores answers), of each review, as student.
* '''View Review Detail: (As Instructor)''' : The ability to see review detail (questions, scores answers), of each review, as instructor.
* '''View Reviews, with Versions in a comparable manner''' : The ability to see different versions or rounds of each review, either side by side, or tab from one to the other.
* '''View Reviews, Grouped by Review''' : The ability to group responses by reviewer (current functionality.)
* '''View Reviews, Grouped by Question''' : The ability to group responses by question/criteria.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

We should note that there will be no changes or impact on the database or underlying model classes.

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-13T05:14:40Z

Mjwitte: /* Discussion of Resolution */

== 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
* Refactoring grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
* Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
* Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
* Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
* Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
* Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
* Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Final Review Mockup.png|border]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden. Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. Clicking the column header for a specific review will display all the comments left by that reviewer. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

Note that the specific interaction schemes outlined thus far, including the screenshots, have applied to the student role. The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.
* '''Expand All Reviews''' : Reviews may be initially condensed in the UI by default. This use case covers the ability for a viewing user to expand expand all reviews in the UI at once, with one click of the mouse.
* '''Condense each Review''' : The ability to expand and condense each review of the scores page.
* '''View Review Detail: (As Student)''' : The ability to see review detail (questions, scores answers), of each review, as student.
* '''View Review Detail: (As Instructor)''' : The ability to see review detail (questions, scores answers), of each review, as instructor.
* '''View Reviews, with Versions in a comparable manner''' : The ability to see different versions or rounds of each review, either side by side, or tab from one to the other.
* '''View Reviews, Grouped by Review''' : The ability to group responses by reviewer (current functionality.)
* '''View Reviews, Grouped by Question''' : The ability to group responses by question/criteria.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-13T05:14:00Z

Mjwitte: /* Discussion of Resolution */

== 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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:
1. Refactoring grades_controller.rb and review_mapping_controller.rb to optimize code organization, making code easier to read.
2. Modifying UI to be more friendly. Instructor can see users' names and user-IDs, student should see review numbers, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
3. Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
4. Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
5. Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
6. Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
7. Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Final Review Mockup.png|border]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden. Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. Clicking the column header for a specific review will display all the comments left by that reviewer. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

Note that the specific interaction schemes outlined thus far, including the screenshots, have applied to the student role. The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.
* '''Expand All Reviews''' : Reviews may be initially condensed in the UI by default. This use case covers the ability for a viewing user to expand expand all reviews in the UI at once, with one click of the mouse.
* '''Condense each Review''' : The ability to expand and condense each review of the scores page.
* '''View Review Detail: (As Student)''' : The ability to see review detail (questions, scores answers), of each review, as student.
* '''View Review Detail: (As Instructor)''' : The ability to see review detail (questions, scores answers), of each review, as instructor.
* '''View Reviews, with Versions in a comparable manner''' : The ability to see different versions or rounds of each review, either side by side, or tab from one to the other.
* '''View Reviews, Grouped by Review''' : The ability to group responses by reviewer (current functionality.)
* '''View Reviews, Grouped by Question''' : The ability to group responses by question/criteria.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-13T05:10:46Z

Mjwitte:

== 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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 focus on the following specific areas:
1. Refactoring grades_controller.rb and review_mapping_controller.rb, to optimize code organize, making code easier to read.
2. Modifying UI to be more friendly. Instructor could see user’s name and user-ID, student should see reviews number, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
3. Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
4. Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
5. Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
6. Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
7. Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
We propose entirely removing the summary statistics at the top of the page. The data in these statistics can be displayed in a more efficient manner.

[[File:Final Review Mockup.png|border]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden. Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. Clicking the column header for a specific review will display all the comments left by that reviewer. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

Note that the specific interaction schemes outlined thus far, including the screenshots, have applied to the student role. The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.
* '''Expand All Reviews''' : Reviews may be initially condensed in the UI by default. This use case covers the ability for a viewing user to expand expand all reviews in the UI at once, with one click of the mouse.
* '''Condense each Review''' : The ability to expand and condense each review of the scores page.
* '''View Review Detail: (As Student)''' : The ability to see review detail (questions, scores answers), of each review, as student.
* '''View Review Detail: (As Instructor)''' : The ability to see review detail (questions, scores answers), of each review, as instructor.
* '''View Reviews, with Versions in a comparable manner''' : The ability to see different versions or rounds of each review, either side by side, or tab from one to the other.
* '''View Reviews, Grouped by Review''' : The ability to group responses by reviewer (current functionality.)
* '''View Reviews, Grouped by Question''' : The ability to group responses by question/criteria.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-13T05:00:05Z

Mjwitte:

== 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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
==== Motivations ====
* Lack of uniformity between student and instructor views
* No defined separation between reviews
* All reviews and review data (comments, question text, etc.) are displayed at once

==== Discussion ====
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 ===
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 focus on the following specific areas:
1. Refactoring grades_controller.rb and review_mapping_controller.rb, to optimize code organize, making code easier to read.
2. Modifying UI to be more friendly. Instructor could see user’s name and user-ID, student should see reviews number, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
3. Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
4. Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
5. Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
6. Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
7. Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
We propose minimal, if any, changes to the stats portion at the top of the view. This section already looks refined and provides a nice summary of the reviews submitted for a particular assignment. The only changes that might be incurred would be to the links to “hide reviews” and “show author feedbacks.” It may not make sense for these actions to remain once the presentation of the review content changes. The table of scores for each review will be removed and replaced by the new view for reviews.

[[File:Final Review Mockup.png|border]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden. Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. Clicking the column header for a specific review will display all the comments left by that reviewer. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

Note that the specific interaction schemes outlined thus far, including the screenshots, have applied to the student role. The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.
* '''Expand All Reviews''' : Reviews may be initially condensed in the UI by default. This use case covers the ability for a viewing user to expand expand all reviews in the UI at once, with one click of the mouse.
* '''Condense each Review''' : The ability to expand and condense each review of the scores page.
* '''View Review Detail: (As Student)''' : The ability to see review detail (questions, scores answers), of each review, as student.
* '''View Review Detail: (As Instructor)''' : The ability to see review detail (questions, scores answers), of each review, as instructor.
* '''View Reviews, with Versions in a comparable manner''' : The ability to see different versions or rounds of each review, either side by side, or tab from one to the other.
* '''View Reviews, Grouped by Review''' : The ability to group responses by reviewer (current functionality.)
* '''View Reviews, Grouped by Question''' : The ability to group responses by question/criteria.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-09T23:28:25Z

Mjwitte:

== Intro ==
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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
There is no denying that the usability of viewing peer reviews leaves much to be desired. It lacks uniformity across varying roles (student and instructor), and the view itself has no semblance of order or organization. Viewing a single student’s review is a chore for both instructor and student, as there is no clear separation between reviews. 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 ===
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 focus on the following specific areas:
1. Refactoring grades_controller.rb and review_mapping_controller.rb, to optimize code organize, making code easier to read.
2. Modifying UI to be more friendly. Instructor could see user’s name and user-ID, student should see reviews number, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
3. Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
4. Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
5. Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
6. Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
7. Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
We propose minimal, if any, changes to the stats portion at the top of the view. This section already looks refined and provides a nice summary of the reviews submitted for a particular assignment. The only changes that might be incurred would be to the links to “hide reviews” and “show author feedbacks.” It may not make sense for these actions to remain once the presentation of the review content changes. The table of scores for each review will be removed and replaced by the new view for reviews.

[[File:Final Review Mockup.png|border]]

The main UI overhaul will occur in displaying the actual reviews. To combat the length of the current review display, we have chosen to condense all of that data into a single table that can be viewed without the need to endlessly scroll through the page. Each row of the table corresponds to a specific criterion of the review and the scores each reviewer gave with whatever comments they may have offered. The columns dictate which review the score came from. By default, the full criterion text is truncated, while the comments from a review are hidden. Clicking the row number will display all comments for that particular criterion, i.e., comments from each review. Clicking the column header for a specific review will display all the comments left by that reviewer. The individual scores to each criterion will be colored based on its value relative to the total score for the criterion. In this way, a student can quickly perceive the criterion on which they received poor scores from the reviewer.

Note that the specific interaction schemes outlined thus far, including the screenshots, have applied to the student role. The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.
* '''Expand All Reviews''' : Reviews may be initially condensed in the UI by default. This use case covers the ability for a viewing user to expand expand all reviews in the UI at once, with one click of the mouse.
* '''Condense each Review''' : The ability to expand and condense each review of the scores page.
* '''View Review Detail: (As Student)''' : The ability to see review detail (questions, scores answers), of each review, as student.
* '''View Review Detail: (As Instructor)''' : The ability to see review detail (questions, scores answers), of each review, as instructor.
* '''View Reviews, with Versions in a comparable manner''' : The ability to see different versions or rounds of each review, either side by side, or tab from one to the other.
* '''View Reviews, Grouped by Review''' : The ability to group responses by reviewer (current functionality.)
* '''View Reviews, Grouped by Question''' : The ability to group responses by question/criteria.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-09T23:15:30Z

Mjwitte:

== Intro ==
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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
There is no denying that the usability of viewing peer reviews leaves much to be desired. It lacks uniformity across varying roles (student and instructor), and the view itself has no semblance of order or organization. Viewing a single student’s review is a chore for both instructor and student, as there is no clear separation between reviews. 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 ===
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 focus on the following specific areas:
1. Refactoring grades_controller.rb and review_mapping_controller.rb, to optimize code organize, making code easier to read.
2. Modifying UI to be more friendly. Instructor could see user’s name and user-ID, student should see reviews number, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
3. Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
4. Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
5. Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
6. Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
7. Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
We propose minimal, if any, changes to the stats portion at the top of the view. This section already looks refined and provides a nice summary of the reviews submitted for a particular assignment. The only changes that might be incurred would be to the links to “hide reviews” and “show author feedbacks.” It may not make sense for these actions to remain once the presentation of the review content changes. The table of scores for each review will be removed and replaced by the new view for reviews.

[[File:Final Review Mockup.png|border]]

The main UI overhaul will occur in displaying the actual reviews.

Note that the specific interaction schemes outlined thus far, including the screenshots, have applied to the student role. The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.
* '''Expand All Reviews''' : Reviews may be initially condensed in the UI by default. This use case covers the ability for a viewing user to expand expand all reviews in the UI at once, with one click of the mouse.
* '''Condense each Review''' : The ability to expand and condense each review of the scores page.
* '''View Review Detail: (As Student)''' : The ability to see review detail (questions, scores answers), of each review, as student.
* '''View Review Detail: (As Instructor)''' : The ability to see review detail (questions, scores answers), of each review, as instructor.
* '''View Reviews, with Versions in a comparable manner''' : The ability to see different versions or rounds of each review, either side by side, or tab from one to the other.
* '''View Reviews, Grouped by Review''' : The ability to group responses by reviewer (current functionality.)
* '''View Reviews, Grouped by Question''' : The ability to group responses by question/criteria.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-09T23:14:44Z

Mjwitte:

== Intro ==
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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===

The tasks of the assignment are as follows:

# Compact the review display. Eliminate the blank lines between items within a single review. Instead vary the background color from line to line to improve readability.
# Add the following to the top of each review: who submitted the review. The instructor should see the user’s name and user-ID. A student should see “Reviewer #k”, where k is an integer between 1 and n, the number of reviews that have been submitted for this project. the version number of the review, and the time the review was submitted.
# Add functionality to allow the instructor to view different review rounds. Also, provide instructor with a review report page of all reviewers’ reviews to every project.
# Allow different alternate view: group by question.
# Reduce the duplicate code between instructor and student grade reports.

=== Purpose ===
There is no denying that the usability of viewing peer reviews leaves much to be desired. It lacks uniformity across varying roles (student and instructor), and the view itself has no semblance of order or organization. Viewing a single student’s review is a chore for both instructor and student, as there is no clear separation between reviews. 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 ===
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 focus on the following specific areas:
1. Refactoring grades_controller.rb and review_mapping_controller.rb, to optimize code organize, making code easier to read.
2. Modifying UI to be more friendly. Instructor could see user’s name and user-ID, student should see reviews number, like “Reviewer #k” where k is the number of reviews submitted to the project/assignment. Besides, the round of reviews (version number) and submitted time of reviews could also be saw by both students and instructor.
3. Modifying UI to make it easier for students/instructor to see reviews of different rounds. Tabs is a good choice, besides drop-down menus are a good alternate. Maybe we also need to modify models to make it adaptive to different rounds of reviews.(Currently, review models will only record the latest version of reviews.)
4. Providing a new page to display all reviews of one project/assignment as review report. In this page, reviews will be displayed as a format like “Question 1, Reviews 1, Reviews 2 … Reviews n” (reviewer’s name should also be included here). Besides, here we also need to provide different version/round of reviews of different questions. At the top of this page, there should be a matrix to show the summary of questions(as a row) and reviews(as a column).(How can different version be displayed in the matrix? Using different matrix works?)
5. Providing a way to hide or gray the questions, making students/instructor more focus on reviews.
6. Providing a search reviews through a specific keyword. And when searching, providing a ‘next’ button to navigate to next keyword place.
7. Providing a two-dimensional table to show the scores of each question and reviewer’s name who gives the score to the question.

=== Mock-Ups ===
We propose minimal, if any, changes to the stats portion at the top of the view. This section already looks refined and provides a nice summary of the reviews submitted for a particular assignment. The only changes that might be incurred would be to the links to “hide reviews” and “show author feedbacks.” It may not make sense for these actions to remain once the presentation of the review content changes. The table of scores for each review will be removed and replaced by the new view for reviews.

[[File:Final Mock Up.png|border]]

The main UI overhaul will occur in displaying the actual reviews.

Note that the specific interaction schemes outlined thus far, including the screenshots, have applied to the student role. The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of reviews in the column headers, student names will take their place. We will be able to reuse the structure in the student's view for this purpose.

=== Design Patterns ===
The implementation team expects that the following design patterns be used in the solution:

* '''FlyWeight Design Pattern''': using flyweight design pattern, we can use sharing data/gui to support large numbers of fine-grained objects efficiently. For instance, in expertiza system, students’ review pages and instructor review pages. We can use one page to display in both students’ ‘version’ of review page and instructor’s ‘version’ of review page.

* '''Strategy Design Pattern''': using strategy design pattern, we can display one page into different ‘version’ of page according to different role. For instance, in students’ review page, he will see reviewer’s id, and in instructor’s review page, he will see reviewer’s fullname. In here, student and instructor are different strategy.

* '''Front Controller Design Pattern''': with front controller design pattern, we will display different views based on the URL and currently user’s role.

* '''Module Design Pattern''': by module design pattern, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. In JavaScript files, we use anonymous functions for responsiveness on client side via javascript and jquery.

* '''Iterator Design Pattern''': iterator design pattern is used to iterate through data structures in Ruby actions and when rendering the view. For instance, we need to display all reviewer’s reviews to one round, so we need the collection of all reviewer’s reviews and then iterator to display.

* '''Facade Design Pattern''': facade design pattern provides a unified and higher-level interface to a set of interfaces in a subsystem, which makes the subsystem easier to use. For instance, in students’ review page, grades, commands and feedbacks are from three controller, and they are combined in review controller and display in one review page.

=== Use Cases ===

* '''View Review Page as Student''' : General use case, capturing a student viewing his or her own reviews with corresponding user account.
* '''View Review Page as Instructor''' : General use case, an instructor associated with the course in which to review's assignment is included, viewing reviews for a student participating in that assignment.
* '''Expand All Reviews''' : Reviews may be initially condensed in the UI by default. This use case covers the ability for a viewing user to expand expand all reviews in the UI at once, with one click of the mouse.
* '''Condense each Review''' : The ability to expand and condense each review of the scores page.
* '''View Review Detail: (As Student)''' : The ability to see review detail (questions, scores answers), of each review, as student.
* '''View Review Detail: (As Instructor)''' : The ability to see review detail (questions, scores answers), of each review, as instructor.
* '''View Reviews, with Versions in a comparable manner''' : The ability to see different versions or rounds of each review, either side by side, or tab from one to the other.
* '''View Reviews, Grouped by Review''' : The ability to group responses by reviewer (current functionality.)
* '''View Reviews, Grouped by Question''' : The ability to group responses by question/criteria.

=== Proposed Tests ===
* UI Testing: all new functionality must be tested with supported browsers.
* Controller Testing: view person with no reviews, view person with reviews but no scores nor comments, view reviews with scores --,0,1,2,3,4,5. view reviews with comments with length 10,20,30,40,50,60,70,80,90,100,110,120,130,140,150,160,170 characters.

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, questions, responses, response_maps, answers.


'''Task 1''': Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some 'BR' tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

'''Task 2''': Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>
 For instructors, team_users_popup.html.erb should be edited. The information such as reviewers's id, name, review's round number and updated time can be added after the 'else' division:

<pre>
<%if @scores == nil%>

<tr> <td align = "center">No review done yet.</td> </tr>
 
<tr>
<th align = "left"> Reviewer score </th>
</tr>
<tr>
<td align = "center">--</td>
</tr>
 
<%else%>
</pre>


'''Task 3 and 4''': Use tab to change reviews according to round, version and questions.


Using the 'round' attribute in the 'response' table to differentiate reviews in distinct rounds, for students the code inside following for-loop located in the _reviews.html.erb wil be rewritten and tab UI in JQuery will be used.

<pre>
<% for review in rscore[:assessments] %>
.
.
.
<% end %>
</pre>
For instructors, in the team_users_popup.html.erb file, the code inside 'else' block should be rewritten to adapt tab UI.
<pre>
<%if @scores == nil%>
.
.
.
<%else%>
.
.
.
<%end%>
</pre>

==References==
{{reflist}}

File:Final Review Mockup.png

2015-11-09T23:07:02Z

Mjwitte:

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-07T18:03:58Z

Mjwitte:

== Intro ==
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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

=== Purpose ===
There is no denying that the usability of viewing peer reviews leaves much to be desired. It lacks uniformity across varying roles (student and instructor), and the view itself has no semblance of order or organization. Viewing a single student’s review is a chore for both instructor and student, as there is no clear separation between reviews. 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 ===
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 ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

=== Mock-Ups ===
We’ll outline our proposed changes starting from the top of the review page and working our way down.

[[File:Mock Up 1.png|border]]

We propose minimal, if any, changes to the stats portion at the top of the view. This section already looks refined and provides a nice summary of the reviews submitted for a particular assignment. The only changes that might be incurred would be to the links to “hide reviews” and “show author feedbacks.” It may not make sense for these actions to remain once the presentation of the review content changes.

The first instance of major change will occur in the table under the stats section. The table will become interactive, dictating which individual review to show at any given point. To increase readability of the table headers, they will either be spaced out more along the top or rotated to display at an angle. The "Average" in "Average score" will be removed, as it is not indicative of the value held in the table. The percentages will contain links to display that particular review in a table below. Clicking that link will automatically scroll the page down to take the user to the displayed review.

[[File:Mock Up 2.png|border]]

The main UI overhaul will occur in displaying the actual reviews. We intend to pull all of that content and place it in a tabbed table, similar to an Excel spreadsheet. Rather than have the confusing options to show or hide a review from a different round, the table will have multiple tabs, one for each version of the review, which will be labeled with the the particular review phase they belong to. Clicking these tabs, the user can toggle between the review they would like to look at. Each review question will have it's own row in the table, with the following columns: Question Number, Question, Score, Reviewer Comments. These columns will be interactive, i.e., clicking a column header will sort the table based on that column. Under each question number, there will be an option to "View Aggregate Scores," which will compile a table consisting of the selected question from every review. In this manner, a user can swiftly compare the scores they received on a single question from every review.

Note that the specific interaction schemes outlined thus far, including the screenshots, have applied to the student role. The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of a 2 x N table like the student role has holding the scores from each review, the instructor will have a M x N table, where M is the number of students in the course and N is the number of assignments for that course. The column headers will become the assignment names, and the rows will have the names of students. The i, j entry will contain the score that Student i gave for Assignment j. This value will be interactive, controlling which review is displayed below the table. The columns will be sortable just as they are in the student view. Clicking a score will display that particular review below the master table in a tabbed tabular view, just as it is for the student's view. We will be able to reuse the structure in the student's view for this purpose.

=== Design Patterns ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

=== Use Cases ===
* View Review Page as Student
* View Review Page as Instructor
* Expand All Reviews
* Condense each Review
* View Review Detail: (As Student)
* View Review Detail: (As Instructor)
* View Reviews, with Version side-by-side, in a comparable manner.
* View Reviews, Grouped by Review
* View Reviews, Grouped by Question

=== Proposed Tests ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, responses, response_maps


Task 1: Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

Task2: Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>


Task3 and task4: Use tab to change reviews according to round number.


Tab UI in JQuery can be used.


== Suggestions for Future Improvements ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

==References==
{{reflist}}

File:Mock Up 2.png

2015-11-07T18:02:58Z

Mjwitte: Mock Up 2 for review design overhaul.

Mock Up 2 for review design overhaul.

File:Mock Up 1.png

2015-11-07T18:02:37Z

Mjwitte: Mock up 1 for review design overhaul.

Mock up 1 for review design overhaul.

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-06T16:23:10Z

Mjwitte:

== Intro ==
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.

One of the main tenets of Expertiza is its implicit peer-review system. Assignments inherently have a review stage where, rather than having instructors review a team’s work, other students review a team’s submission for that assignment. When completing a review, a student is presented with essentially a rubric for the assignment, and they fill in each category with the score they deem commensurate with the work of the team. Of course, each category has a comments box for the student to qualify the score they doled out. Each member of the submitting team is notified of the review, and the team can then decide as a whole how to rework their submission based on the feedback in the peer reviews.

There do exist issues, however, with respect to viewing one’s team’s reviews, particularly in the realm of usability. Our team has been tasked with revamping and enhancing the review UI to produce a more focused and uniform user experience for students and instructors alike.

== Assignment ==

=== Description ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

=== Purpose ===
There is no denying that the usability of viewing peer reviews leaves much to be desired. It lacks uniformity across varying roles (student and instructor), and the view itself has no semblance of order or organization. Viewing a single student’s review is a chore for both instructor and student, as there is no clear separation between reviews. 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 ===
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 ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

=== Mock-Ups ===
We’ll outline our proposed changes starting from the top of the review page and working our way down.

[[File:Mock Up Screenshot 1.png|border]]

We propose minimal, if any, changes to the stats portion at the top of the view. This section already looks refined and provides a nice summary of the reviews submitted for a particular assignment. The only changes that might be incurred would be to the links to “hide reviews” and “show author feedbacks.” It may not make sense for these actions to remain once the presentation of the review content changes.

The first instance of major change will occur in the table under the stats section. The table will become interactive, dictating which individual review to show at any given point. To increase readability of the table headers, they will either be spaced out more along the top or rotated to display at an angle. The "Average" in "Average score" will be removed, as it is not indicative of the value held in the table. The percentages will contain links to display that particular review in a table below. Clicking that link will automatically scroll the page down to take the user to the displayed review.

[[File:Mock Up Screenshot 2.png|border]]

The main UI overhaul will occur in displaying the actual reviews. We intend to pull all of that content and place it in a tabbed table, similar to an Excel spreadsheet. Rather than have the confusing options to show or hide a review from a different round, the table will have multiple tabs, one for each version of the review, which will be labeled with the the particular review phase they belong to. Clicking these tabs, the user can toggle between the review they would like to look at. Each review question will have it's own row in the table, with the following columns: Question Number, Question, Score, Reviewer Comments. These columns will be interactive, i.e., clicking a column header will sort the table based on that column. Under each question number, there will be an option to "View Aggregate Scores," which will compile a table consisting of the selected question from every review. In this manner, a user can swiftly compare the scores they received on a single question from every review.

Note that the specific interaction schemes outlined thus far, including the screenshots, have applied to the student role. The instructor role will also receive interaction updates using the same underling display structures, but the content differ slightly from that of the student. Instead of a 2 x N table like the student role has holding the scores from each review, the instructor will have a M x N table, where M is the number of students in the course and N is the number of assignments for that course. The column headers will become the assignment names, and the rows will have the names of students. The i, j entry will contain the score that Student i gave for Assignment j. This value will be interactive, controlling which review is displayed below the table. The columns will be sortable just as they are in the student view. Clicking a score will display that particular review below the master table in a tabbed tabular view, just as it is for the student's view. We will be able to reuse the structure in the student's view for this purpose.

=== Design Patterns ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

=== Use Cases ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

=== Proposed Tests ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

== Implementation ==


Target files: app/models/response.rb, app/views/grades/_reviews.html.erb and app/views/popup/team_users_popup.html.erb


Key tables: questionnaires, responses, response_maps


Task 1: Compact the review display and colorize the background.


The code for displaying review is implemented in a action call 'display_as_html' in app/models/response.rb. The action basically links html code then return it as a string.
To eliminate the blank line between items, some tags in the display_as_html need to be delete.
To use different color in the background for different review, we plan to insert id for reviews in _reviews.html.erb, then write css for colorization in the app/assets/stylesheets/ folder.

 

Task2: Show basic information about each review for both instructor and student.


To extract the data that need to be displayed, the models involve and their relationships to each other need to be analyzed. For students, _reviews.html.erb should be edited. The code to display those data should be insert after 'Review #' and before 'display_as_html' as following:

<pre>
<% if controller.action_name != "view_my_scores" %>
<a name="<%=prefix+"_"+review.map.reviewer.name%>"></a><%= review.display_as_html(prefix) %>
<% else %>

<h2>Review <%= count %></h2>
<!--insert basic information--!> 
<%= review.display_as_html(nil,0, nil) %> 
</pre>


Task3 and task4: Use tab to change reviews according to round number and


== Suggestions for Future Improvements ==

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

==References==
{{reflist}}

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-06T14:06:33Z

Mjwitte:

File:Mock Up Screenshot 2.png

2015-11-06T13:56:03Z

Mjwitte: Screenshot of the second mock up.

Screenshot of the second mock up.

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-06T02:56:29Z

Mjwitte:

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-06T02:49:29Z

Mjwitte:

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-06T02:44:15Z

Mjwitte:

CSC/ECE 517 Fall 2015 E1577 MayYellowRoverJump

2015-11-06T02:29:27Z

Mjwitte:

File:Mock Up Screenshot 1.png

2015-11-06T02:28:46Z

Mjwitte: uploaded a new version of "File:Mock Up Screenshot 1.png": Smaller.

First screenshot for the mock up of what's going to change.