CSC/ECE 517 Spring 2019 - Project E1937. Integrate suggestion detection algorithm.rb: Difference between revisions
| Line 87: | Line 87: | ||
* views->reports->_review_report.html.erb - Add a Suggestion Metric column to the Reports table (logged in as an instructor) | * views->reports->_review_report.html.erb - Add a Suggestion Metric column to the Reports table (logged in as an instructor) | ||
* views->response->suggestions.erb - The new view which doubles as a confirmation page as well as showing the suggestions. | * views->response->suggestions.erb - The new view which doubles as a confirmation page as well as showing the suggestions. | ||
* views->response-> | * views->response->response_html.erb - Remove the old javascript code that calls the API. | ||
* controllers->response_controller.erb - Add code for the API calls | * controllers->response_controller.erb - Add code for the API calls | ||
==== Response Controller ==== | ==== Response Controller ==== | ||
Revision as of 21:40, 15 April 2019
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
- 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
Flowchart to Describe Plan of Action
File(s) involved in making API Call: response_controller.rb FIle(s) involved in displaying the received output: response.html.erb
Proposed changes
- 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 Changed
- views->reports->_review_report.html.erb - Add a Suggestion Metric column to the Reports table (logged in as an instructor)
- views->response->suggestions.erb - The new view which doubles as a confirmation page as well as showing the suggestions.
- views->response->response_html.erb - Remove the old javascript code that calls the API.
- controllers->response_controller.erb - Add code for the API calls
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
Anticipated View
Student View
The student will be given a summary of the feedback in a colorful format. The student will not see all the fields of the JSON and only the necessary text fields, whereas the previous pull request enabled the student to see all the fields in the output from the API call. We expect to make the detailed view optional so that it can be used for debug purposes, and this will be available to non-students (admins, instructors).
Production View
In the production server, there will be an option at the top of the page to turn on debug mode.
In debug mode, all information returned from the API call will be displayed beside each review instead of only averaging the essential metrics for all reviews. We are still choosing to omit the "text" item returned in the JSON since it is redundant to display the comment again. Debug mode will be displayed to the right of each review comment.
Files that will change
- app/views/response/response.html.erb: Fix grammar issues, generate view with metrics
- app/controllers/response_controller.rb: Call API here to pass to view
Testing plan
There are two aspects to our test plan: Controller and View testing.
Controller Tests
We will...
- rely on Travis CI automated responses to verify all changes made will not break the system
- ensure that our code coverage does not decrease as a result of our modifications by looking at coveralls messages
- modify Rspec response_controller_spec.rb to reflect the new method(s) added to response_controller.rb
- record and upload a short video verifying our Rspec tests pass
View Tests
We will...
- use manual testing on response.html.erb to verify the Review page outputs the correct message
- provide sample inputs and show expected outputs using screenshots