Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2019 - Project E1937. Integrate suggestion detection algorithm.rb

2019-04-27T01:34:11Z

Pjain22: /* Tests */

==Introduction==
=== Team ===
Dr. Gehringer (mentor)
* Sushan Basnet (sbasnet2)
* Jasmine Wang (jfwang2)
* Bill Mwaniki (bnmwanik)
* Pratik Kumar Kundanmal Jain (pjain22)

==Project plan==
===Problem statement===
Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as how many suggestions they contain. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms will be so coded in the future.

===How it will work===

In order to make the API call, the response_controller.rb will be responsible for sending a JSON input to the web service. The input will contain the review comment submitted by the user in the following format:

Below is a sample input
Sample Input:
{
"reviews":[{
"text":"review text here",
"metrics":["problem","suggestion","sentiment"]
},{
"text":"another review here",
"metrics":["problem"]
},{
"text":"more text, maybe a large para or whatever you like",
"metrics":["sentiment", "suggestion"]
},{
...
}]
}

Once the request is send, we expect the output to be in the following format:

Sample Output: (as 'suggestion' and 'volume' as you might expect)
{
"metrics":[{
"suggestion":{
"suggestions_chances":30,
"suggestions":"absent"
},
"volume":{
"total_volume":10,
"volume_without_stopwords":3
}
},{
...
},{
...
}]
}

The output (which is a JSON) will be parsed and the suggestion metrics such as the tone and presence of suggestion will be extracted so the user will be able to view a summarized result of how well their review comments were. In addition, an average score will be computed based on the scores they received for each comment section, and the result will be presented in a colorful format to the user after they hit the submit button.

===Previous work===
[https://github.com/expertiza/expertiza/pull/1308 Fall 2018 pull request]
* They had a functional suggestion detection API call that successfully communicated with the PeerLogic Server and retrieved the output.
* They included their API call in response.html.erb using JavaScript.
* They were able to display the output for each review beside the review. They displayed all of the information returned from the endpoint, which can look clunky.
* Since the code is added in the views, they performed manual testing in the views.

More information about the suggestion detection service can be found at https://www.peerlogic.org

[[File:Prev.png]]

=== Flowchart to Describe Plan of Action ===

[[FIle:x.png]]

== Changes Made ==
* Move API calls of suggestion-detection algorithm from view to response_controller.rb
* Change default review view from displaying analysis for each comment to summarized analysis for all comments
** Do not include comment text in analysis view
** Focus on sentiment_score, suggestions, suggestions_chances returned from API
* Include displaying analysis for each review as a "debug" option
* Ensure that CORS does not need to be enabled for API call to work
* Write unit tests for our method(s) in response_controller.rb
* Fix grammar issues in response.html.erb
* Evaluate how much time this API is taking and, if possible, work a way out to improve it.

=== Files that we changed ===
* '''app/views/response/response.html.erb''' - Refactored and reworked JS methods for the autosave and form submits, added a new hidden button to the response form
* '''app/controllers/response_controller.rb''' - Refactored and reworked methods for the autosave and form submits, added an API method to pass to view
* app/helpers/review_mapping_helper.rb - Adjusted the bar thickness according to desired specifications
* config/routes.rb - Added another route to support the new review confirmation page listed below

=== New files we added ===
* '''app/models/metric.rb''' - New ActiveRecord model added to act as a template for future API usage
* '''db/migrate/20190425194052_create_metrics.rb''' - New table added for permanent storage of the Metric class
* '''app/views/response/show_confirmation_page.erb - The new page added for review confirmation
* '''test/fixtures/metrics.yml''' - In support of the new ActiveRecord model called Metric
* '''test/models/metric_test.rb''' - In support of the new ActiveRecord model called Metric
* '''app/assets/images/lightbulb.png''' - Lightbulb picture for the new review confirmation page
* '''app/assets/images/music_note.png''' - A music note picture for the new review confirmation page

==== Response Controller ====
Lines 359 and 360 are where we will retrieve the input from each review comment found in the form.
* The '''Answer''' model represents the review provided by the reviewer.
* On line 360, answer: v[:score] is the review comment from a given textarea HTML element
* params[:responses] stores the aggregate review data provided by the user

[[File:create_answers.png]]

=== Confirmation Page View ===

=====Student View=====
The program flow is as follows:

# After the reviewer has filled out their review, they have 2 choices: See an analysis of their review or Save the review.
# The reviewer selects to view their analysis by clicking on "Confirm Submission" button
# The program directs the reviewer to the new confirmation page which displays an analysis of their review.
# The reviewer has 2 options in the confirmation page: Submit the review or go back and modify their review.
# If the reviewer decides to Submit their review, the program directs them back to where they started (Create or edit review).

The image below shows the above steps in a visual depiction.
[[File:program_flow.png]]

==== Detailed Popup Information ====
Below we showcase the available information from the API if a reviewer is curious to find more details

[[File:review_response_w_popup_1.png]]
[[File:review_response_w_popup_2.png]]
[[File:review_response_w_popup_3.png]]

==== Conditional Formatting ====
To make the interface more user-friendly, we used conditional formatting to color our text. For the suggestions metrics, anything >50% means suggestions are present while anything <50% means suggestions are absent. Our conditional formatting is set so "Yes (>50%)" is green, 50% is yellow, and "No (<50%)" is red. The formatting is the same for the class average of suggestions metrics.

For tone, there are three options in the API: positive, neutral, and negative. We created conditional formatting in our view file so positive is green text, neutral is yellow text, and negative is red text.

==Testing plan==

=== Travis CI ===
Since we changed the controller and UI in our project to add the redirect view, the current Travis CI test build is failing.
* For TESTFOLDER=features, in the response.hmtl.erb view, we changed the submit button text from "Submit" to "Confirm Submission" in order to accurately reflect the new redirect page.
* For TESTFOLDER=controllers, we modified the save method inside response_controller.rb to redirect according to logic defined above.

=== Tests ===
* We tested the new model added i.e. Metric model in metric.rb.
* The RSpec file is added to the rspec/models folder with the name metric_spec.rb.
* The testing tests the calculation of the average of suggestions chances from each response for a particular assignment.
* This also tests the output text of the sentiment that is received based on an input numerical value.

=== View Tests ===
We have...
* Manually tested response.html.erb to verify the Review page outputs the correct message
* Provided sample inputs and shown expected outputs using screenshots

==Links to our work==
* [https://github.com/pratikkumar-jain/expertiza/tree/beta Our repository]
* [https://github.com/expertiza/expertiza/pull/1427 Pull request]
* [https://www.youtube.com/watch?time_continue=1&v=FjHAODvHtk4 YouTube Video]

CSC/ECE 517 Spring 2019 - Project E1937. Integrate suggestion detection algorithm.rb

2019-04-27T01:33:46Z

Pjain22: /* Tests */

==Introduction==
=== Team ===
Dr. Gehringer (mentor)
* Sushan Basnet (sbasnet2)
* Jasmine Wang (jfwang2)
* Bill Mwaniki (bnmwanik)
* Pratik Kumar Kundanmal Jain (pjain22)

==Project plan==
===Problem statement===
Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as how many suggestions they contain. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms will be so coded in the future.

===How it will work===

In order to make the API call, the response_controller.rb will be responsible for sending a JSON input to the web service. The input will contain the review comment submitted by the user in the following format:

Below is a sample input
Sample Input:
{
"reviews":[{
"text":"review text here",
"metrics":["problem","suggestion","sentiment"]
},{
"text":"another review here",
"metrics":["problem"]
},{
"text":"more text, maybe a large para or whatever you like",
"metrics":["sentiment", "suggestion"]
},{
...
}]
}

Once the request is send, we expect the output to be in the following format:

Sample Output: (as 'suggestion' and 'volume' as you might expect)
{
"metrics":[{
"suggestion":{
"suggestions_chances":30,
"suggestions":"absent"
},
"volume":{
"total_volume":10,
"volume_without_stopwords":3
}
},{
...
},{
...
}]
}

The output (which is a JSON) will be parsed and the suggestion metrics such as the tone and presence of suggestion will be extracted so the user will be able to view a summarized result of how well their review comments were. In addition, an average score will be computed based on the scores they received for each comment section, and the result will be presented in a colorful format to the user after they hit the submit button.

===Previous work===
[https://github.com/expertiza/expertiza/pull/1308 Fall 2018 pull request]
* They had a functional suggestion detection API call that successfully communicated with the PeerLogic Server and retrieved the output.
* They included their API call in response.html.erb using JavaScript.
* They were able to display the output for each review beside the review. They displayed all of the information returned from the endpoint, which can look clunky.
* Since the code is added in the views, they performed manual testing in the views.

More information about the suggestion detection service can be found at https://www.peerlogic.org

[[File:Prev.png]]

=== Flowchart to Describe Plan of Action ===

[[FIle:x.png]]

== Changes Made ==
* Move API calls of suggestion-detection algorithm from view to response_controller.rb
* Change default review view from displaying analysis for each comment to summarized analysis for all comments
** Do not include comment text in analysis view
** Focus on sentiment_score, suggestions, suggestions_chances returned from API
* Include displaying analysis for each review as a "debug" option
* Ensure that CORS does not need to be enabled for API call to work
* Write unit tests for our method(s) in response_controller.rb
* Fix grammar issues in response.html.erb
* Evaluate how much time this API is taking and, if possible, work a way out to improve it.

=== Files that we changed ===
* '''app/views/response/response.html.erb''' - Refactored and reworked JS methods for the autosave and form submits, added a new hidden button to the response form
* '''app/controllers/response_controller.rb''' - Refactored and reworked methods for the autosave and form submits, added an API method to pass to view
* app/helpers/review_mapping_helper.rb - Adjusted the bar thickness according to desired specifications
* config/routes.rb - Added another route to support the new review confirmation page listed below

=== New files we added ===
* '''app/models/metric.rb''' - New ActiveRecord model added to act as a template for future API usage
* '''db/migrate/20190425194052_create_metrics.rb''' - New table added for permanent storage of the Metric class
* '''app/views/response/show_confirmation_page.erb - The new page added for review confirmation
* '''test/fixtures/metrics.yml''' - In support of the new ActiveRecord model called Metric
* '''test/models/metric_test.rb''' - In support of the new ActiveRecord model called Metric
* '''app/assets/images/lightbulb.png''' - Lightbulb picture for the new review confirmation page
* '''app/assets/images/music_note.png''' - A music note picture for the new review confirmation page

==== Response Controller ====
Lines 359 and 360 are where we will retrieve the input from each review comment found in the form.
* The '''Answer''' model represents the review provided by the reviewer.
* On line 360, answer: v[:score] is the review comment from a given textarea HTML element
* params[:responses] stores the aggregate review data provided by the user

[[File:create_answers.png]]

=== Confirmation Page View ===

=====Student View=====
The program flow is as follows:

# After the reviewer has filled out their review, they have 2 choices: See an analysis of their review or Save the review.
# The reviewer selects to view their analysis by clicking on "Confirm Submission" button
# The program directs the reviewer to the new confirmation page which displays an analysis of their review.
# The reviewer has 2 options in the confirmation page: Submit the review or go back and modify their review.
# If the reviewer decides to Submit their review, the program directs them back to where they started (Create or edit review).

The image below shows the above steps in a visual depiction.
[[File:program_flow.png]]

==== Detailed Popup Information ====
Below we showcase the available information from the API if a reviewer is curious to find more details

[[File:review_response_w_popup_1.png]]
[[File:review_response_w_popup_2.png]]
[[File:review_response_w_popup_3.png]]

==== Conditional Formatting ====
To make the interface more user-friendly, we used conditional formatting to color our text. For the suggestions metrics, anything >50% means suggestions are present while anything <50% means suggestions are absent. Our conditional formatting is set so "Yes (>50%)" is green, 50% is yellow, and "No (<50%)" is red. The formatting is the same for the class average of suggestions metrics.

For tone, there are three options in the API: positive, neutral, and negative. We created conditional formatting in our view file so positive is green text, neutral is yellow text, and negative is red text.

==Testing plan==

=== Travis CI ===
Since we changed the controller and UI in our project to add the redirect view, the current Travis CI test build is failing.
* For TESTFOLDER=features, in the response.hmtl.erb view, we changed the submit button text from "Submit" to "Confirm Submission" in order to accurately reflect the new redirect page.
* For TESTFOLDER=controllers, we modified the save method inside response_controller.rb to redirect according to logic defined above.

=== Tests ===
* We tested the new model added i.e. Metric model in metric.rb.
* The RSpec file is added to the rspec/models folder with the name metric_spec.rb.
* The testing tests the calculation of the average of suggestions chances from each response for a particular assignment.
* This also tests the output text of the sentiment that is received based on a input numerical value.

=== View Tests ===
We have...
* Manually tested response.html.erb to verify the Review page outputs the correct message
* Provided sample inputs and shown expected outputs using screenshots

==Links to our work==
* [https://github.com/pratikkumar-jain/expertiza/tree/beta Our repository]
* [https://github.com/expertiza/expertiza/pull/1427 Pull request]
* [https://www.youtube.com/watch?time_continue=1&v=FjHAODvHtk4 YouTube Video]

CSC/ECE 517 Spring 2019 - Project E1937. Integrate suggestion detection algorithm.rb

2019-04-27T01:30:28Z

Pjain22: /* View Tests */

==Introduction==
=== Team ===
Dr. Gehringer (mentor)
* Sushan Basnet (sbasnet2)
* Jasmine Wang (jfwang2)
* Bill Mwaniki (bnmwanik)
* Pratik Kumar Kundanmal Jain (pjain22)

==Project plan==
===Problem statement===
Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as how many suggestions they contain. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms will be so coded in the future.

===How it will work===

In order to make the API call, the response_controller.rb will be responsible for sending a JSON input to the web service. The input will contain the review comment submitted by the user in the following format:

Below is a sample input
Sample Input:
{
"reviews":[{
"text":"review text here",
"metrics":["problem","suggestion","sentiment"]
},{
"text":"another review here",
"metrics":["problem"]
},{
"text":"more text, maybe a large para or whatever you like",
"metrics":["sentiment", "suggestion"]
},{
...
}]
}

Once the request is send, we expect the output to be in the following format:

Sample Output: (as 'suggestion' and 'volume' as you might expect)
{
"metrics":[{
"suggestion":{
"suggestions_chances":30,
"suggestions":"absent"
},
"volume":{
"total_volume":10,
"volume_without_stopwords":3
}
},{
...
},{
...
}]
}

The output (which is a JSON) will be parsed and the suggestion metrics such as the tone and presence of suggestion will be extracted so the user will be able to view a summarized result of how well their review comments were. In addition, an average score will be computed based on the scores they received for each comment section, and the result will be presented in a colorful format to the user after they hit the submit button.

===Previous work===
[https://github.com/expertiza/expertiza/pull/1308 Fall 2018 pull request]
* They had a functional suggestion detection API call that successfully communicated with the PeerLogic Server and retrieved the output.
* They included their API call in response.html.erb using JavaScript.
* They were able to display the output for each review beside the review. They displayed all of the information returned from the endpoint, which can look clunky.
* Since the code is added in the views, they performed manual testing in the views.

More information about the suggestion detection service can be found at https://www.peerlogic.org

[[File:Prev.png]]

=== Flowchart to Describe Plan of Action ===

[[FIle:x.png]]

== Changes Made ==
* Move API calls of suggestion-detection algorithm from view to response_controller.rb
* Change default review view from displaying analysis for each comment to summarized analysis for all comments
** Do not include comment text in analysis view
** Focus on sentiment_score, suggestions, suggestions_chances returned from API
* Include displaying analysis for each review as a "debug" option
* Ensure that CORS does not need to be enabled for API call to work
* Write unit tests for our method(s) in response_controller.rb
* Fix grammar issues in response.html.erb
* Evaluate how much time this API is taking and, if possible, work a way out to improve it.

=== Files that we changed ===
* '''app/views/response/response.html.erb''' - Refactored and reworked JS methods for the autosave and form submits, added a new hidden button to the response form
* '''app/controllers/response_controller.rb''' - Refactored and reworked methods for the autosave and form submits, added an API method to pass to view
* app/helpers/review_mapping_helper.rb - Adjusted the bar thickness according to desired specifications
* config/routes.rb - Added another route to support the new review confirmation page listed below

=== New files we added ===
* '''app/models/metric.rb''' - New ActiveRecord model added to act as a template for future API usage
* '''db/migrate/20190425194052_create_metrics.rb''' - New table added for permanent storage of the Metric class
* '''app/views/response/show_confirmation_page.erb - The new page added for review confirmation
* '''test/fixtures/metrics.yml''' - In support of the new ActiveRecord model called Metric
* '''test/models/metric_test.rb''' - In support of the new ActiveRecord model called Metric
* '''app/assets/images/lightbulb.png''' - Lightbulb picture for the new review confirmation page
* '''app/assets/images/music_note.png''' - A music note picture for the new review confirmation page

==== Response Controller ====
Lines 359 and 360 are where we will retrieve the input from each review comment found in the form.
* The '''Answer''' model represents the review provided by the reviewer.
* On line 360, answer: v[:score] is the review comment from a given textarea HTML element
* params[:responses] stores the aggregate review data provided by the user

[[File:create_answers.png]]

=== Confirmation Page View ===

=====Student View=====
The program flow is as follows:

# After the reviewer has filled out their review, they have 2 choices: See an analysis of their review or Save the review.
# The reviewer selects to view their analysis by clicking on "Confirm Submission" button
# The program directs the reviewer to the new confirmation page which displays an analysis of their review.
# The reviewer has 2 options in the confirmation page: Submit the review or go back and modify their review.
# If the reviewer decides to Submit their review, the program directs them back to where they started (Create or edit review).

The image below shows the above steps in a visual depiction.
[[File:program_flow.png]]

==== Detailed Popup Information ====
Below we showcase the available information from the API if a reviewer is curious to find more details

[[File:review_response_w_popup_1.png]]
[[File:review_response_w_popup_2.png]]
[[File:review_response_w_popup_3.png]]

==== Conditional Formatting ====
To make the interface more user-friendly, we used conditional formatting to color our text. For the suggestions metrics, anything >50% means suggestions are present while anything <50% means suggestions are absent. Our conditional formatting is set so "Yes (>50%)" is green, 50% is yellow, and "No (<50%)" is red. The formatting is the same for the class average of suggestions metrics.

For tone, there are three options in the API: positive, neutral, and negative. We created conditional formatting in our view file so positive is green text, neutral is yellow text, and negative is red text.

==Testing plan==

=== Travis CI ===
Since we changed the controller and UI in our project to add the redirect view, the current Travis CI test build is failing.
* For TESTFOLDER=features, in the response.hmtl.erb view, we changed the submit button text from "Submit" to "Confirm Submission" in order to accurately reflect the new redirect page.
* For TESTFOLDER=controllers, we modified the save method inside response_controller.rb to redirect according to logic defined above.

=== Tests ===

=== View Tests ===
We have...
* Manually tested response.html.erb to verify the Review page outputs the correct message
* Provided sample inputs and shown expected outputs using screenshots

==Links to our work==
* [https://github.com/pratikkumar-jain/expertiza/tree/beta Our repository]
* [https://github.com/expertiza/expertiza/pull/1427 Pull request]
* [https://www.youtube.com/watch?time_continue=1&v=FjHAODvHtk4 YouTube Video]

CSC/ECE 517 Spring 2019 - Project E1937. Integrate suggestion detection algorithm.rb

2019-04-27T01:27:51Z

Pjain22: /* Tests */

==Introduction==
=== Team ===
Dr. Gehringer (mentor)
* Sushan Basnet (sbasnet2)
* Jasmine Wang (jfwang2)
* Bill Mwaniki (bnmwanik)
* Pratik Kumar Kundanmal Jain (pjain22)

==Project plan==
===Problem statement===
Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as how many suggestions they contain. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms will be so coded in the future.

===How it will work===

In order to make the API call, the response_controller.rb will be responsible for sending a JSON input to the web service. The input will contain the review comment submitted by the user in the following format:

Below is a sample input
Sample Input:
{
"reviews":[{
"text":"review text here",
"metrics":["problem","suggestion","sentiment"]
},{
"text":"another review here",
"metrics":["problem"]
},{
"text":"more text, maybe a large para or whatever you like",
"metrics":["sentiment", "suggestion"]
},{
...
}]
}

Once the request is send, we expect the output to be in the following format:

Sample Output: (as 'suggestion' and 'volume' as you might expect)
{
"metrics":[{
"suggestion":{
"suggestions_chances":30,
"suggestions":"absent"
},
"volume":{
"total_volume":10,
"volume_without_stopwords":3
}
},{
...
},{
...
}]
}

The output (which is a JSON) will be parsed and the suggestion metrics such as the tone and presence of suggestion will be extracted so the user will be able to view a summarized result of how well their review comments were. In addition, an average score will be computed based on the scores they received for each comment section, and the result will be presented in a colorful format to the user after they hit the submit button.

===Previous work===
[https://github.com/expertiza/expertiza/pull/1308 Fall 2018 pull request]
* They had a functional suggestion detection API call that successfully communicated with the PeerLogic Server and retrieved the output.
* They included their API call in response.html.erb using JavaScript.
* They were able to display the output for each review beside the review. They displayed all of the information returned from the endpoint, which can look clunky.
* Since the code is added in the views, they performed manual testing in the views.

More information about the suggestion detection service can be found at https://www.peerlogic.org

[[File:Prev.png]]

=== Flowchart to Describe Plan of Action ===

[[FIle:x.png]]

== Changes Made ==
* Move API calls of suggestion-detection algorithm from view to response_controller.rb
* Change default review view from displaying analysis for each comment to summarized analysis for all comments
** Do not include comment text in analysis view
** Focus on sentiment_score, suggestions, suggestions_chances returned from API
* Include displaying analysis for each review as a "debug" option
* Ensure that CORS does not need to be enabled for API call to work
* Write unit tests for our method(s) in response_controller.rb
* Fix grammar issues in response.html.erb
* Evaluate how much time this API is taking and, if possible, work a way out to improve it.

=== Files that we changed ===
* '''app/views/response/response.html.erb''' - Refactored and reworked JS methods for the autosave and form submits, added a new hidden button to the response form
* '''app/controllers/response_controller.rb''' - Refactored and reworked methods for the autosave and form submits, added an API method to pass to view
* app/helpers/review_mapping_helper.rb - Adjusted the bar thickness according to desired specifications
* config/routes.rb - Added another route to support the new review confirmation page listed below

=== New files we added ===
* '''app/models/metric.rb''' - New ActiveRecord model added to act as a template for future API usage
* '''db/migrate/20190425194052_create_metrics.rb''' - New table added for permanent storage of the Metric class
* '''app/views/response/show_confirmation_page.erb - The new page added for review confirmation
* '''test/fixtures/metrics.yml''' - In support of the new ActiveRecord model called Metric
* '''test/models/metric_test.rb''' - In support of the new ActiveRecord model called Metric
* '''app/assets/images/lightbulb.png''' - Lightbulb picture for the new review confirmation page
* '''app/assets/images/music_note.png''' - A music note picture for the new review confirmation page

==== Response Controller ====
Lines 359 and 360 are where we will retrieve the input from each review comment found in the form.
* The '''Answer''' model represents the review provided by the reviewer.
* On line 360, answer: v[:score] is the review comment from a given textarea HTML element
* params[:responses] stores the aggregate review data provided by the user

[[File:create_answers.png]]

=== Confirmation Page View ===

=====Student View=====
The program flow is as follows:

# After the reviewer has filled out their review, they have 2 choices: See an analysis of their review or Save the review.
# The reviewer selects to view their analysis by clicking on "Confirm Submission" button
# The program directs the reviewer to the new confirmation page which displays an analysis of their review.
# The reviewer has 2 options in the confirmation page: Submit the review or go back and modify their review.
# If the reviewer decides to Submit their review, the program directs them back to where they started (Create or edit review).

The image below shows the above steps in a visual depiction.
[[File:program_flow.png]]

==== Detailed Popup Information ====
Below we showcase the available information from the API if a reviewer is curious to find more details

[[File:review_response_w_popup_1.png]]
[[File:review_response_w_popup_2.png]]
[[File:review_response_w_popup_3.png]]

==== Conditional Formatting ====
To make the interface more user-friendly, we used conditional formatting to color our text. For the suggestions metrics, anything >50% means suggestions are present while anything <50% means suggestions are absent. Our conditional formatting is set so "Yes (>50%)" is green, 50% is yellow, and "No (<50%)" is red. The formatting is the same for the class average of suggestions metrics.

For tone, there are three options in the API: positive, neutral, and negative. We created conditional formatting in our view file so positive is green text, neutral is yellow text, and negative is red text.

==Testing plan==

=== Travis CI ===
Since we changed the controller and UI in our project to add the redirect view, the current Travis CI test build is failing.
* For TESTFOLDER=features, in the response.hmtl.erb view, we changed the submit button text from "Submit" to "Confirm Submission" in order to accurately reflect the new redirect page.
* For TESTFOLDER=controllers, we modified the save method inside response_controller.rb to redirect according to logic defined above.

=== Tests ===

=== View Tests ===
We have...
* manual tested response.html.erb to verify the Review page outputs the correct message
* provided sample inputs and shon expected outputs using screenshots

==Links to our work==
* [https://github.com/pratikkumar-jain/expertiza/tree/beta Our repository]
* [https://github.com/expertiza/expertiza/pull/1427 Pull request]
* [https://www.youtube.com/watch?time_continue=1&v=FjHAODvHtk4 YouTube Video]

CSC/ECE 517 Spring 2019 E1910 Refactor assignments controller.rb

2019-04-01T22:34:32Z

Pjain22: /* RSpec Tests */

This wiki page is for the description of changes made under E1910 OSS assignment for Spring 2019, CSC/ECE 517.

We have not deployed this project since we did not change or add any functionality that would affect the user.

== Expertiza Background==

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages. [3]

== Description of the current project ==

The assignments_controller has multiple functions with wrong naming convention, they are classic examples of bad function names. Few of the variables names used in the method can also be refactored to make it more relevant and understandable. In addition, functions code can be optimized to ensure that it follows 'Don't Repeat Yourself' (DRY) principle. Also, most of the functions have missing code comments, which should be added to the functions.

=== Pull request link ===
[https://github.com/expertiza/expertiza/pull/1377]

=== Forked Github repo ===
[https://github.com/veehakhanna/expertiza]

== Files modified in current project ==

The only controller modified for this project was the: 
1. AssignmentsController 
2. Assignment_helper

The updated method names in AssignmentController:

- handle_assignment_directory_path_nonexist_case_and_answer_tagging
-- missing_submission_directory
- assignment_form_key_nonexist_case_handler
-- assignment_submission_handler
- handle_current_user_timezonepref_nil
-- timezone_handler
- update_nil_dd_deadline_name
-- update_due_date_deadline_name
- update_nil_dd_description_url
-- update_due_date_description_url 
- assignment_form_assignment_staggered_deadline?
-- assignment_staggered_deadline?
- check_due_date_nameurl_not_empty
-- check_due_date_nameurl 
- update_feedback_assignment_form_attributes
-- update_feedback_attributes 

The thought process behind changing the method names was to make the names shorter and reduce redundancy. There were a few rules that we learned from our mentor; words like ''nil'' and ''nonexist'' are not allowed in method names. So for '''handle_current_user_timezonepref_nil''' we first removed the ''nil''. Then after looking at what the method does we determined that '''timezone_handler''' would be appropriate and tells the user enough at a moments glance. More information is available about the method in the form of a block comment.

Another example is '''assignment_form_assignment_staggered_deadline?''', the ''assignment_form'' bit is redundant, since it is the assignments controller the beginning part does not provide any new information and '''assignment_staggered_deadline?''' is sufficient.

A different kind of naming is '''update_nil_dd_deadline_name''', we removed the ''nil'' but the ''dd'' doesn't make sense. No one would know what that stands for just by reading it. This is why this method was changed to '''update_due_date_deadline_name'''. It is not any shorter but much more useful at a glance.

The '''assignment_helper''' file was added to. Some of the methods in the controller were misplaced and according to the DRY principle these methods are better suited to be in the helper method. The methods that were moved from the controller to the helper were:
- assignment_submission_handler -> updated method name
- check_due_date_nameurl(dd) -> updated method name

We were asked to refactor the '''action_allowed?''' method but after discussing some reafactoring methods with our mentor it was decided that refactoring this method would not promote the DRY principle and the methods created as a result would only be for that one purpose and therefore unnecessary.

== Code Improvements ==

The DRY principle states, "Every piece of knowledge or logic must have a single, unambiguous representation within a system."[4] This project was about furthering this principle and keeping this controller concise and maintainable.

This is a controller that helps instructors, TA's, administrators, and super-administrators create/update/edit/show/delete current and past assignments. We updated the aforementioned method names so that the naming convention follows the DRY principle. Many of the method names were far too long, repetitive or unhelpful in understanding what the method actually does. In accordance with the principle we updated the method names to be simple while also being useful in letting the programmer know what the method does.

Many of these methods did not have any comments to help the programmer understand the logic driving the method. To further help the programmer in understanding what the code does we added block comments at the beginning of each method that we updated.

We cleaned up the controller by moving some methods from the controller into the associated helper file ('''assignment_helper.rb'''). By doing this we made the controller less messy and easier to read while maintaining and furthering the DRY principle. The code is now easily maintainable and all "helper" methods are in one place rather than separated across many files.

The delegation pattern states, "In delegation, an object handles a request by delegating to a second object (the delegate). The delegate is a helper object, but with the original context." [5]

As something extra, the '''create''' method was refactored so that the branch condition would be lower and there would be no repetition. We decided to use the delegation pattern because it serves the purpose of cleaning up existing methods while maintaining functionality. As per this pattern we took a request from the '''create''' method and put it in a helper method called '''update_assignment_form'''. This method handles updating the id of the ''assignment_questionnaire'' and the ''due_date'' and updating the form accordingly. The '''create''' method delegates this task to the '''update_assignment_form'''.

The '''update_assignment_form''' delegated a tasks to the helper method, '''array_traverser'''. This method does the job of going through the array and updates id fields to be strings instead of an integer.

As a result of these changes two code climate issues have been resolved which are stated below in the Code Climate section. Below are images of the way the '''create''' method used to look and how it looks now.

Old '''create''' method:

[[File:old_create_method.png]]

New '''create''' method:

[[File:new_create_method.png]]

===Code Climate===

Code Climate checks to make sure that the code that has been written follows certain rules so that everything is legible and concise. During our refactoring we have fixed the following code climate issues.

- The '''create''' method's Cognitive Complexity was too high. That has been resolved by the delegation we have described above. 
- The '''create''' method was too long with 33 lines of code. That has been resolved by the delegation we have described above. 
- The Branch Condition size for '''assignment_form_key_nonexist_case_handler''', which is now '''assignment_submission_handler''', was too high. This means that there were too many nested if/elsif/else statements. This has been resolved as a result of us refactoring the code. 
- The Branch Condition size for '''update_feedback_assignment_form_attributes''', which is now '''update_feedback_attributes ''', was too high. This means that there were too many nested if/elsif/else statements. This has been resolved as a result of us refactoring the code. 

We have three current code climate issues but after discussing with our mentor we have been told to ignore those.

== Test Plan ==

The code coverage for the controller was 49% when we got the project. The code coverage when we finished was 53.32%.

=== RSpec Tests ===

There were already quite a few test cases for the AssignmentsController ('''assignments_controller_spec.rb'''). The '''create''' block tested just about everything. The two methods we added are private and since we branched out some functionality this needed to be a bit more explicitly tested. There is no precedence for testing private methods and it was frowned upon as per the video ''The Magic Tricks of Testing''. We tested the public method, '''create''', that calls the private method, '''update_assignment_form''' and '''array_traverser'''. We added a test with the context ''when assignment_form is saved successfully but fails to update''.

For the other untested public methods, we found no usage directly in the controller, therefore, we did not test them. These methods are performing the tasks of assigning values to the variables and therefore that is being tested in other methods of the controllers.

No changes were made to the associated views and model file.

== References ==
1. https://github.com/expertiza/expertiza/pull/1377 
2. https://github.com/veehakhanna/expertiza 
3. http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2015/oss_E1553_AAJ 
4. https://dzone.com/articles/software-design-principles-dry-and-kiss 
5. https://en.wikipedia.org/wiki/Delegation_pattern

CSC/ECE 517 Spring 2019 E1910 Refactor assignments controller.rb

2019-03-25T22:23:52Z

Pjain22: /* Files modified in current project */

File:New method 1.png

2019-03-25T22:20:20Z

Pjain22: uploaded a new version of "File:New method 1.png"

File:New method 1.png

2019-03-25T22:19:01Z

Pjain22: uploaded a new version of "File:New method 1.png"

File:New method 1.png

2019-03-25T22:17:34Z

Pjain22: uploaded a new version of "File:New method 1.png"

File:New method 1.png

2019-03-25T22:16:57Z

Pjain22: uploaded a new version of "File:New method 1.png"

CSC/ECE 517 Spring 2019 E1910 Refactor assignments controller.rb

2019-03-25T22:14:41Z

Pjain22: /* Code Improvements */

File:New method 1.png

2019-03-25T22:13:20Z

Pjain22: